Friday, March 29, 2013

AgileFest 2013 Planning Retrospective



We were invited to Thomson Reuters for our AgileFest! 2013 planning retrospective.  Derek and Modesto did a wonderful job designing a metaphor board.  We had fun filling it in with concepts, ideas, feelings and reflecting on 3 months of work.  That work resulted in a great day of learning.

Get Silverlight and view a PhotoSynth of the Retro board and space.


Derek raises an eye at that comment
Modesto can see with eyes shut


AgileFest Lessons Learned Review

Wednesday, March 13, 2013

Scrum Team Metrics (necessary and sufficient)

What metrics would a great Scrum team want to generate and track the trend?

Is the necessary and sufficient set of metrics just velocity?  No - I don't think that is enough.  Can you help me define a short list of metrics, and the reasons for tracking them?

First let's lay out some ground rules.  Who is responsible for generating the metrics?  Are all metrics treated the same, e.g. should each metric have the same visibility?  I'll state the the team is responsible for generating the metrics.  This ensures that the metric has some minimun level of veracity.  When the team believes that the metric does not tell the truth, they should make that visible and change how it is generated.  This is process improvement.  However not all metrics need be treated the same.  Some should be published, some could stay internal to the team.  As the level of trust and autonomy of the team increases the visibility of metrics should naturally become more transparent.

Here's a rough draft list - to get the conversation started.  Add your comments and additional metrics.  We will see if we can crowd source a great list.

Metrics for the Team
  • Story point velocity per sprint
  • Projected capacity (in person-days) of next sprint
  • Projected capability (in story points range) of next sprint
  • Planned capability of the sprint (in story points)
  • Story points done and accepted by PO of the sprint
  • Story's started but not done (in story points and stories)
  • Discovered work added to the backlog (in story points and stories)
  • Scope increase/decrease during the sprint.
  • Technical debt incurred this sprint (in story points)
  • Cost of sprint
  • Impediments discovered/removed/escalated
  • Sprint - pass/fail

Metrics for the Program
  • Release burn up (in story points)
  • Scope increase/decrease (and reasons for change)
  • Projected completion date range (optimistic & pessimistic)
  • Impediments discovered/removed
  • Risk mitigated, (unknown) risk realized

Metrics for the Organization

See Also:  a follow up post Metrics for the Scrum Team

Visualizing Agility: Agile Metrics that Matter by Jay Packlick


Thursday, March 7, 2013

Results Oriented Web Conference - April 12 - Dallas


I am speaking at an upcoming conference on April 12 in Dallas, titled: 'The Marshmallow Design Challenge'. The 2nd Annual Results Oriented Web Summit focuses on the core disciplines for online success - content, design & user experience (UX), marketing and project management. The conference is organized by community leaders bringing together top experts in their field.


I want to personally invite you to this unique event by offering you a 50% off discount code that is good until Friday, March 15. Go to http://resultsorientedweb.com/register and use the code ROWFRIEND.

Saturday, March 2, 2013

Which Agile Process Should You Choose?


There are many processes that will help you achieve Agility. How will you select one that is best for you?

Agile is not a process; it is a philosophy.  It's a philosophy that describes a comparative value system and a set of 12 principles designed to discover better ways of developing products.

There are many agile embracing processes or process frameworks.  Which will you choose to use?  This will depend upon many factors that are context dependent.  One shoe will not fit all feet - and all feet do not need shoes.

On a spectrum from 'prescriptive' to 'adaptive' where do various agile processes fall?  Henrik Kniberg did this analysis for us.  He bases his measurement on the number of 'rules' stated in the process descriptions. For example:  RUP 120 rules; XP 13 rules; Scrum 9 rules; Kanban 3 rules.
by Henrik Kniberg

This chart provides a high-level view of Agile frameworks on a scale of prescriptiveness to adaptiveness. How many rules do you have to follow to be able to say you are using a process? How many rules are necessary and sufficient for your organization's culture?  If this is an interesting question for you, then you will enjoy Michael Sahota's Agile Culture, Adoption, and Transformation Reading Guide.

As one moves to the right on this spectrum there is an increasing need for self-discipline. Just because you are at the right end, "Do Whatever" doesn't mean your group has the ability to effectively achieve your goals. Perhaps, you can improve the effectiveness you desire by moving toward the left.  In my experience, it requires a very mature organization to move toward the right on this spectrum.  Moving toward the left creates a rigid structure and can have severe consequences on team dynamics and motivation.

I've observed that many of the teams that say they are doing Kanban are only doing 1 or 2 of the 3 prescriptive rules. Few, in my limited experience, are actually doing the continuous improvement via scientific methods. I don't intend to disparage the process (if it could be called a process). I believe it is wonderfully simple and can work for a very mature organization, such as organizations that are already a learning organization. Most of the teams I see using Kanban don't even begin to have Senge's Personal Mastery concept (the first of Senge's 5 disciplines).  At this end of the spectrum, these disciplines are required.

I've also never see a team doing Scrum and delivering working, tested software frequently without doing many of the engineering processes defined by XP.

So, I guess my view is that the sweet spot is somewhere between 8 - 15 rules. With only very mature and disciplined teams being capable of removing some of these. Therefore, just like when the doctor tells you to take all of the antibiotic, regardless of how much better you feel after day four, you must finish the course of antibiotics. There is a need for you to follow all of the prescriptions of the process if you want to reap the benefit.

process spectrum