Analysis and Design in Agile

A long time ago in a galaxy a dozen or so miles away, I learned about Extreme Programming.  I was actually doing Pair Programming when I heard about this crazy XP concept, so it wasn't really a stretch to do it on a regular basis.  Similarly, writing tests for my code seemed like a reasonable thing to do, although it took a few months to really wrap my head around Test-Driven Development

Within a year of that first contact, I was an outspoken advocate of using XP.  I successfully convinced a manager to try it out and it worked wonderfully for that group.  I started talking to more and more people, and in doing so started to encounter the first myths and misconceptions about what XP did and did not do.  That was 2001, and in 2011 I still hear many of the same things.  So, let's deal with a few of those myths now.

Let me go back to what I read in XP Installed, XP Explained, the C2 Wiki and on the XP Yahoo group in those days.  The 'genesis' of XP started when Kent Beck was faced with leading a restart of the Chrysler Comprehensive Compensation project in 1996.  As I understand it, Kent was a reluctant leader and knew that he had to do something different.  He reflected on everything and anything in his career that had 'worked',  and reasoned that if a practice worked you should amplify it, i.e. take it to the extreme.  To wit:
  • Planning is good, so do it all the time (Planning Game)
  • Analysis is good, so do it all the time (Planning Game)
  • Design is good, so do it all the time (Planning Game, Test-Driven Development, Pair Programming)
  • Testing is good, so do it all the time and automate it (Test-Driven Development, Customer Tests)
  • Keeping the design clean is good, so do it all the time (Refactoring)
  • Integrating completed code is good, so do it all the time (Continuous Integration)
  • Feedback is good,, so do it all the time (Short Iterative Development)
  • Releases to production are good, so do them all the time (Small Releases)
  • Contact with the people for whom you're building the software is good, so do it all the time (Whole Team)
  • Collaboration between team members is good, so do it all the time (Whole Team)
  • Code inspections and reviews are good, so do them all the time (Pair Programming)
  • Avoiding silos of knowledge is good, so do it all the time (Whole Team, Collective Ownership)
All of these are aspects of what was and is considered good software delivery practice and all are present in Extreme Programming.  They may look different in practice, but they are all indeed there.  What you avoid is the waste of speculative work that results in mistakes or following the wrong path because of an expensive prior decision that people don't want to undo.  Only enough work is performed in order to suit the current needs of the team and the Customer.

The key word there is "enough", which is very context dependent.  A smallish web application may not require much analysis, design and planning beyond a few iterations or outside of the current release.  The anti-lock brake management system for a car would likely need more.  A constant very-high-volume system like Twitter would have different parameters for "enough" than an eCommerce application handling a few dozen paying customers per day.  One lost tweet is no big deal, but a customer losing their cart on that eCommerce site could be lost business for that small company.  Conversely, the eCommerce site need only handle a few concurrent users whereas Twitter must handle thousands.  In the end, you always must be mindful of what constitutes "enough" in your domain.

Activities such as analysis and design happen in increments ranging from a couple of minutes to possibly as large as a couple of weeks:
  • A pair of people may spend a few minutes at a whiteboard sketching out the work they're about to do to implement a story.
  • A pair of people will use tests to guide their work and the design of the code while using Test-Driven Development.
  • A team will spend a few hours to a few days doing Release Planning to map out work for the next few weeks to months.  This will include an overall view of the design vision of the system.
  • A team will spend a couple of hours doing Iteration Planning to map out work for the next week or so. This will include breaking the work into much more detailed tasks, and further refining the design.
  • A large group of people may spend multiple weeks working through the business problem, usage scenarios, personae, use cases, and overall high-level design for a large enterprise system.
  • A small startup may iterate on multiple small experiments per week in order to quickly get validated feedback on their business direction.
  • A team of any size on any project in any domain may hold ad hoc sessions to discuss and refine the design as required based on any new learnings or refined understanding of the business problem.
So, please remind me again why you think that Agile/XP means no analysis, no design, no documentation, no planning and just random hacking that will collapse after 3 iterations?


Unknown said…
Nice job Dave. This is tricky thing for people to get a grasp on and I like how you've outlined the different options. I had two or three conversations this week on this topic.
Dave Rooney said…
Thanks, Steve! I've had the same comments this week... this month... this year... which prompted me to write the post.
Kelly Waters said…
Great post Dave, really good to remind people that agile is not cowboy coding!

Kelly Waters