Agile Zone is brought to you in partnership with:

Dave Rooney is a veteran Agile Coach and co-founder of Westboro Systems. He has over 20 years software development industry experience and has been involve with the Agile community since 2000, working with organisations from pre-funding startups to the Fortune 15 improve their software process. Dave is co-founder of the Agile Ottawa Group, and an active write, speaker and advocate of agile methods in Canada. Dave is a DZone MVB and is not an employee of DZone and has posted 32 posts at DZone. You can read more from them at their website. View Full User Profile

Analysis and Design in Agile

08.21.2013
| 3492 views |
  • submit to reddit
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?
Published at DZone with permission of Dave Rooney, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Peng Mei replied on Fri, 2013/08/23 - 4:13am

随碟附送

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.