Runtah

Ive said publicly at conferences and other gatherings that my passion for agile and lean began years ago after a particularly troubling project that tried to be agile.  While that project had a strong team and eventually delivered a product, it had trouble with quality, scope and budget.  In retrospect the biggest problem was that we had little knowledge of what it meant to be agile - our process was flawed.  As a leader of that team, I took responsibility for the result and began a search to understand agile.  Borrowing a phrase from the agile manifesto, I wanted to uncover better ways.

After implementing several changes to our process, my projects over the years seem to have improved significantly.  But how do you measure this?  While no metric should stand alone, here is one quality metric that Im experimenting with:

((# of high defects * 5) + (# of medium defects * 3) + (# of low defects * 1) / Total project hours * 100.

The troubled project had a score of 18.7.  My most recent project score was 1.2 which is almost a 1600% improvement on quality. I think Ill keep doing this agile thing.

P.S.  Im heading to Agile2010 this summer.  Give me a shout if you are going and we can find ways to de-brief together over lunch or dinner in Orlando.

I ran into Kevin Brennan tonight at #agile2011. I was glad for the chance to talk to him because Ive received quite a few questions from BAs in Winnipeg about how their role will change when they work on agile projects and Kevin has been doing a lot of work with the agile extension to IIBAs BABOK.

Here are is a summary of our conversation:

• How many BAs can articulate the goals and objectives of their company, team, or project? Start here if you cannot.
• Even if you are able to articulate the goals and objectives - can your team? Without understanding the project goals and objectives the team doesnt have enough information to help them make decisions about scope and priorities and often makes decisions based on Is this helping somebody? which can increase the scope of the project.
• BAs can help facilitate the alignment of priorities and goals - enabling the business to speak to the development team with one voice.
• Facilitate requirements and a common understanding of the proposed system through inclusive modeling techniques (eg. user story maps, silent brainstorming, product box - see more here)
• Facilitate the acceptance of change (rather than the restriction of it).
• BAs dont do any less analysis, but they will end up doing less documentation. This reminds me of this tweet:
  

  “Documents we write communicate our good thinking. You can write one without thinking. You can communicate good ideas without a document.” – Jeff Patton (Jan. 19, 2011 - twitter)

• As a BA, if you need to create a document, it will more likely be after the story is complete rather than before creating the story. Some additional guidelines for documentation on agile projects can be found here.

Plus, here are a few more that I thought of after our conversation:

• Collaborate with testers who share many of the same concerns about priorities, goals, scope, and requirements.
• One thing that doesnt change is the need to work with the business as any software produced by the team may change the business processes. Even with iterative delivery, there will be adjustments to be made.

If you have others to add or even disagree with some above - please comment or find Kevin or myself during the conference and well chat.