Software Estimation Series on

Posted by Robert Merrill on October 19, 2011 under Estimation, Project Set-Up | Be the First to Comment

Thanks, In Business Madison, for running my blog series on the software estimation problem and how to work around it, for both the customer/sponsor and delivery side.

Software Estimation—The Brutal Facts (18 October 2011). Why software estimates are inaccurate, why they’re not likely to get better, and why it’s a business problem, not just an IT problem.

Software Project estimates—and Targets and Commitments (8 November 2011). Why “estimates” often aren’t, and how learning two new words can make everything a lot clearer, and more successful.

Guidance on Agile Project Set-Up from the Agile Expert for PMI’s LEAD CoP

Posted by Robert Merrill on October 3, 2011 under Agile BA, Agile Methods, Business Analysis and Requirements, Project Set-Up, Software-Intensive Businesses | Be the First to Comment

Those who wonder how to mesh Agile with a portfolio management or gating process will find some help in Agile Idea Qualification and Project Initiation, an engaging, 50-minute webinar by Sally Elatta.

Sally highlights the similarities between Agile and Lean. I wholeheartedly agree with her that the jelled, multi-functional team (BA, DBA, UI/UX, programmer, QA), not the individual “resource,” is the real unit of value creation in the software-intensive business. Rather than assembling teams around projects, flow work to teams.

In the early days, Agile started with, “in the beginning, there was the Project.” Sally backs up a couple of steps, to the Idea Qualification stage, which proceeds even Project Initiation. Tom Koulopolous teaches a lot of the same concepts. There are many more ideas than there is capacity to implement them, and that’s a good thing. Ideas are the gist of the innovation mill. There must be a central clearing house for idea evaluation, and it must be transparent and respectable. Though the norm, WSTL is just another form of the curse of local optimization.

Idea Qualification can, and must, be quick, both low effort and short cycle time. Sally recommends qualifying ideas by asking:

  1. What is its basic value proposition (make money, save money, improve customer satisfaction, improve competitiveness, stay in compliance, or KTLO—Keep The Lights On)? How can its success in delivering that value be evaluated? Qualitatively is better.
  2. Is it aligned with strategic direction? [Or, Iwould add, “Is it such a breakthrough idea that it represents a change in strategic direction?” This should be uncommon.]
  3. Does it have an empowered, engaged, knowledgable sponsor who is willing to see it through to Done and then take responsibility for the value created, 3-6 months after Done?
  4. Is it Feasible? (Do we have the time, money, know-how, and access to the necessary information and technology)?

Sally wisely recommends the use of a Kanban wall (visual representation of tasks and queues, with a limit on WIP—Work In Process—for every step) to manage Idea Qualification. Her explanation of a Kanban wall starting at about 28:45 in the webinar is very helpful. In addition to being Qualified, Ideas that are forwarded on to the next step, Project Initiation, must be prioritized. The Lean/Agile principle of minimal cycle time/WIP processes executed by standing teams off of a prioritized backlog, is used everywhere.

During Initiation, a portion of the implementation team, and the prospective sponsor, revisit the vision, measurable value, and feasibility (cost, skills, and technology) from Qualification, and add high-level requirements and costs, alternative solutions, a roadmap, and a bit more detail about how and when we will measure value. Projects that are approved to move on must also be prioritized. As Sally cleverly illustrates with the “Name Game,” starting at about 8:30 in the webinar, starting more projects than you have capacity just leads to multitasking which slows everything down.

Sally’s webinar provides a lot of help for business-side sponsors of software projects, which delights me because I think this is the hardest role and also the one with the greatest ability to affect significant change for the better. Starting at about 46:15 in the webinar, she provides a six-step process for evaluating value.

  1. Confirm (it should already have been identified) the value driver (revenue, cost, etc.)
  2. Identify the measure
  3. Gather as-is data (using the Lean principle of Go See)
  4. Define target measures—To Be—a valuable insight is to make this multiple thresholds, with a stretch goal and a target as well as a failure threshold; she also introduces probabilities or percentages, which is something I harp on when it comes to cost estimation
  5. Plan for and commit to measurement of actual outcomes

The higher the overall trust level in your organization, the better this will work. But even in a low-trust organization, there will be benefits, if you have the courage. One of the first gifts of Agile is transparency. Following this process of idea intake, qualification, initiation, and closing the loop with post-project measures, will reveal sources and sinks of trust.