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.

Agile for Business Analysts

Posted by Robert Merrill on March 2, 2010 under Agile BA | Be the First to Comment

I finally got around to conducting a half day of training for some local colleagues who bear the title “Business Analyst,” and whose organizations (and in some cases careers) had been shaken up by the arrival of the Agile Methods (most commonly Scrum) in the Early Majority. There were only four of us all together, so it was delightfully conversational.

Here’s what the whiteboard looked like when we were done. (Click for a full-size view).

Whiteboard after a 3-h presentation about Agile methods by Robert Merrill and Q&A with three Business Analysts

We started out by describing our own encounters with various Agile practices and knowledge of Agile methods in general.

I explained my concept of the Load-Bearing Walls, and shared my opinion that the ignorance, or politically-forced disregard, of these is going to lead to the failure of many Agile initiatives in Early-Majority adopters.

This led to a discussion of the concept of technical debt, and how it presents itself to the non-technical parts of the organization. Automated testing is the key to technical debt management on an Agile project, and can be a point of resistance. On the business side, I’ve sometimes successfully countered the assertion that it’s “extra work” by likening it to double-entry bookkeeping. Read more of this article »

How to Sabotage Agile, Part III

Posted by Robert Merrill on November 16, 2009 under Agile BA, Agile Methods | Be the First to Comment

This is the third of three parts on how to sabotage Agile adoption in your company, especially for Business Analysts.

If you want Agile to succeed, don’t do this stuff.

If you want Agile to fail because you’re benefitting from the status quo, good luck with that, too. Just make sure you have each item covered, especially the last one.

• Find like-minded saboteurs at other companies, so you can say, “They tried Agile at BigCo, and it was a disaster!”
• When assigned to an Agile project as Business Analyst (BA) or Product Owner, insist that all communication from business people to developers go through you, “To keep a handle on scope and keep things consistent.”
• As BA, insist that developers ask you all business questions first, because, “You know the business better than they do, and they’re all really busy anyway.”
• As BA, if instructed to coach people on User Stories or Test Cases, call in sick. Or just do it badly (but don’t be too obvious about it). On break, tell the most frustrated-looking person, “The only reason we’re doing this Agile stuff is that the CEO read about it in an in-flight magazine.”
• Hope that your firm’s competitors have people like you in them. When the ship you’re on sinks, proving that the leak wasn’t in your end won’t keep you from getting wet.

In case you missed them, here’s
How to Sabotage Agile, Part I and How to Sabotage Agile, Part II.