Agile: Getting Business to "Buy in"

When developers talk to business about Agile Development, they usually tell business about all the "wrong" stuff: pair programming, card walls, continuous integration servers, pulling time from the business to talk with the developers every day, etc.  Do not get me wrong, it is cool stuff -- for developers; unfortunately all it usually sounds like to business is, "this is going to cost me even more money, why should I do this?"

So, what is the "right" thing to tell business first to get them listening?  Tell them about how Agile is going to increase their ROI on projects and how it is going to give them access to that ROI faster.  This is not very sexy to most developers, but it should be!

As much as we developers might hate to admit it, we are not primarily getting paid to play with shiny toys and experiment with new technologies.  We are, first and foremost, getting paid to help the company we are working for make more money.  That usually means developing (or maintaining) software to help keep the company running smoothly, help them streamline operations, and be generally more efficient.  Doing this will save them money, allow them to expand into new markets, and allow them to better compete in their existing markets.  The faster we can do this and for the lower the cost, the better.  (Note that "lower cost" does not mean just the lowest immediate cost, but the lowest cost taking into account how those decisions will affect the business over time.)

There are two areas, that business can relate to well, in which Agile Development does an excellent job of getting the business their ROI faster: the frequency of deliverables and the management of project scope.

Frequency of Deliverables

Waterfall Development typically has an initial period of no coding, during which requirements gathering is performed, the scope of the project is decided, the system is designed, architecture decisions are made, and documentation is created to flush out all aspects of the system.  This period can take weeks to months, depending on the anticipated scope of the project.  During this time, no coding is actually done.

After this initial design and requirements gathering stage has been completed, a small team of developers will be tasked with creating one or more prototypes over the course of 6 months to 1 year and those prototypes usually have limited-to-no production-value use.  Assuming the prototypes have received approval, the full development team is then placed on the project and development begins in earnest.

There will usually be target dates 3-6 months apart, at which various milestones are set to be reached.  These milestones may or may not be accompanied by a limited-functionality production-ready version of the system.  The final version of the production-ready system is delivered at the close of the project (often 1 or more years out from the start of the project), after which the project is shifted into a "maintenance and support" mode.

Agile Development typically begins with a "sprint 0", during which initial requirements gathering is performed, the scope of the project is decided, an initial prioritization of the features is decided upon, and some story cards are written for the first set of features to be worked.  This sprint typically lasts a week at the most.  The requirements gathering needs to be complete enough to ensure that the product owners have a clear idea of what they want out of the project, the business analysts can give them a reasonable idea of what is going to be needed to accomplish those goals, and a budget and timeline can be set.  However, the requirements gathering does not need to be fully fleshed out as in Waterfall Development, as Agile assumes (and welcomes) some degree of emergent evolution of the project.

At this point, development with the full team is ready to begin on the highest priority features.  Depending on the scope of the project, new production-ready versions that include all of the functionality completed-to-date might be delivered every week, every two weeks, or every month.  Typically, waiting longer than a month to deliver a new production version is considered to be "too long" -- a month is even considered "too long" by many Agile developers.

This means that a month or two into the project, the business already has a production-ready version of the system that they can (and are expected) to use.  The business can then start seeing a ROI as quickly as a couple months into a project!

These frequent deliverables serve another, extremely important purpose.  Feedback from the users (the more users the better) will help the design evolve while the project is underway, which means that the project will ultimately more closely resemble what business actually needs than Waterfall typically does.  This feedback results in new features being added to the project, adjustments to the way future designs were going to be handled, and allows for defects that slipped through testing to be detected (and fixed!) early and often.


[Edited 9/5/2011 - Removed section on "Management of Scope" for revision and expansion.  It will be re-posted later as a separate entry.]

Agile Development

This will be the first post of many touching on Agile Development.  As such, it will be more of a general introduction to the environment I have been exposed to and a launching point for later posts.  This is my first time working in an Agile Development environment and I have now been embedded for three months at a client that underwent a transformation to Agile Development (from Waterfall) over the course of the last year.

They went all-out with their transformation and:

• replaced all cubicles with team islands created from tables that are bolted together
• populated the room with a plethora of white boards for use in spontaneous discussions
• discarded the generation and use of documentation (from high-level documentation to commenting in code)
• adopted pair-programming
• adopted the practice of embedding the business analysts with the developers at the team islands
• adopted test-driven development
• adopted "clean code" practices
• adopted the use of card walls for feature and defect tracking
• adopted the use of weekly iterations (commitments, demos, and retrospectives) and monthly deployments to the production servers
• ensured high levels of accessibility to the product owners (members of the other departments for which the products were being written)
• adopted the use of daily stand-up meetings attended by the team and the product owners
• adopted the practice of having value stories from the product owners approved by a steering committee prior to work commencing on those projects/sub-projects
• adopted the practice of allowing the product owners to prioritize story cards (individual features or pieces of features) to be worked at the start of each iteration
• adopted the practice of encouraging the team to continuously question whether every feature/meeting/etc. is truly providing a value to the business that is greater than the amount that would be spent on development

So far, I have a very positive opinion of Agile Development (I think it is doing a lot of things "right" and there are many aspects of it that I think are excellent improvements over traditional Waterfall), but I have seen several weaknesses so far:

• Because the majority of the design is done by the pair working the story card, it seems to require that the team be composed of mostly senior-level developers and for weaker developers always be paired with stronger developers.
• If any team members are unwilling to embrace an Agile environment, the success of the team will be crippled.
• The lack of documentation and comments will likely cause maintenance headaches down the road (2+ years out).