Capitalization of design activities on an Agile project

[Bish...@gmail.com]

Hi Folks,

Thought I would poll you all for some ideas...

My Grand Puba began working with an Agile team recently. Puba was called in because one of the teams owners wasn't getting what they needed. Evidently, this group of owners needs design artifacts and tangible "hold me & read me" items so that they can prove and capitalize the work that had been done. The agile team responded in "we don't create design "hold me & read me's" anymore".

Leaving the purest at home, a business owner has every right to need something. Alternatively, the team has an opportunity to treat the need as a story and deal it in among the other important high prioritized stories. In this story, the business wants "waterfall-like" items and they won't take "no" for an answer...that is unless a career change is desired.

Problem: The business owner needs the following:
- Completed Product design and detailed design in which:
-- needed skills, hardware & software technology are available to develop product
-- design has been confirmed by documentation and traceability to product specifications
-- detailed designs have been reviewed for "shutting down the cash flow" engine risks and those risks and uncertainties are mitigated.
--- detailed program design includes, logic description, file layout, field and report definitions, algorithms, routines that are special and specific arrays of data

Question: You are a agile team in flight, sprint 17 out of 40. You've been found wanting so how do you give this owner what they need?

[Walter Bodwell]

In my experience with capitalization, you need to prove feasibility before you can begin to capitalize.  We proved business feasibility by doing a high level business case.  We proved technical feasibility by doing a high level design.  The high level design was around 20 pages for a work product produced by a team of about 100 engineers.  It laid out the high level architecture and went into just enough detail that showed we had thought through the issues that could make it infeasible.  This approach satisfied our auditors and allowed us to capitalize the work done between the point that these two documents were approved and the point that we went GA.

So for capitalization, you don't need the level of detail that you mention.  More likely it is that they want these things because they're used to having them and they feel that they are at risk without them.  Assuming that's the case, you need them to understand that there are costs for this approach.

By designing up front, you're adding complexity for the things that you think will come to fruition.  Much of what is designed will not be done though.  Things change.  Requirements.  What you think you'll need.  Designs become stale.  Even if that work does get done in the future, it is likely that the design work will need to be redone.  You can do a better design with less effort if you do just enough as you go.  Just enough is a judgment call.  You want to think ahead on issues that could put the project at risk.  But just enough.

If you can convince them that the old way is not free and the new way has advantages, then maybe you can turn the conversation to do they really need it and if so, why do they really need it?  And then try to come up with a different approach that is more in line with agile, but still accomplishes the same goals.

Hope this helps...

Walter

--
http://www.walterbodwell.com
http://www.planigle.com (Planigle, the way to Plan Agile)