I really love the way Agile is growing in South Africa, and particularly in Cape Town. We have a passionate, involved community, and some top notch Scrum Masters. The Scrum User Group SUGSA does awesome work – well-attended monthly talks & workshops, and plenty of extra activities from coaching to conferences.
But Scrum alone is not the full extent of being Agile. Scrum is a fabulous set of structured activities that help to manage software delivery (and other types of projects too). Scrum makes work visible and enforces appropriate communication.
But Scrum does not address software quality directly.
I think our Agile community is too focused on being good at Scrum. We need to broaden our focus to include a minimum of Extreme Programming (XP) practices too. My “must haves” are test driven development and pair programming, and anything and everything we can do to improve software design.
First, a stirring paragraph from ExtremeProgramming.org:
Extreme Programming improves a software project in five essential ways; communication, simplicity, feedback, respect, and courage. Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. Every small success deepens their respect for the unique contributions of each and every team member. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology.
I don’t really need to write any more. That’s it! The full story! But in case you missed the important bits, let’s go into a bit more depth.
They keep their design simple and clean. Hugely important, because most software is burdened by overly complex design and lacks good structure. Not easy, but XP has shown us that a big benefit of pair programming is better design. Did you know that?
The earlier you get two heads considering the design, the more chance you have of a much more structured, understandable, simple design.
They get feedback by testing their software starting on day one. Test driven development (TDD) is a mantra for many of us, and most Agile teams do some level of TDD. This is an XP practice that was built in from the start, and our Scrum teams aren’t always getting this right. Some Scrum Masters also see TDD as being only about the testing, so let’s talk about that.
At KRS, we see TDD as the foundation that will assist us with better design (see 1 above). In order to test your code, you have to break it up into the kind of chunks that can be tested. That means you have more manageable, understandable, simpler chunks of code. And you have tests, but that’s almost a side benefit (I’m being a bit tongue-in-cheek to emphasize my point, we really love the tests too).
XP folk believe that software “rots”! You leave it long enough, and that code gets smelly! Of course, the reality is that code is always being modified for changing requirements, and the better you get at absorbing change through Scrum, the smellier your code gets. A critical benefit from TDD is that code can be refactored. Refactoring is the art of cleaning code up as it changes, so that you don’t leave a smelly “big ball of mud” behind (also known as spaghetti code!). Having the tests allows you to refactor without breaking code or introducing new bugs. Big win.
Extreme Programmers are able to courageously respond to changing requirements and technology. Scrum also promises us the ability to respond to changing requirements, but it lacks the emphasis on changing technology that is built into XP. Technology is changing at a dizzying pace, and this is no small promise from XP.
The reason that XP can include technology is based in the deeper focus it has on code: sharing knowledge of code through pair programming; getting the design simpler means it’s also more portable to other environments; and TDD means we really know that the code will work, across most technologies. In fact, KRS will reject technology if it doesn’t support TDD – why go backwards?
So here’s the pitch – KRS is offering 2-day advanced Agile Developer training. Developers will learn (in hands-on, practical sessions):
- Pair programming: theory & exercises
- Behaviour driven design (BDD): Stories and Scenarios
- Test driven development (TDD): Red, Green, Refactor
- Domain driven design (DDD): in-depth and code-intensive
- Work collaboratively on designs over 2 intense days that will leave you exhausted and inspired!
Please email me if you think we should include any other key XP practices? KRS lives by these practices, and we’re ready to share our experience with the Agile (or wannabe Agile) community.
We have a launch course running as part of Software Week in 2012, and quarterly courses thereafter (hosted in Cape Town).
Looking forward to your thoughts about getting truly, technically Agile.