Tuesday, January 24, 2012

Feb 6th - Agile NJ Speaking Engagement



I am giving a talk, with another speaker, at Agile NJ on Monday, February 6, 2012.   

I will discuss a framework for approaching mid-to-large transformations based on recent experience standing up 15 Agile teams in 6 months.  I will share techniques to run your transformation like an agile project and ways achieve executive buy-in, alignment of product roadmaps, as well as support mechanisms like Scrum of Scrums, Impediment Removal Team.

The event is being held at:
Medco – 100 Parsons Pond Rd, Visitor Lot #5, Franklin Lakes NJ  (see Google Map)

The schedule is as follows: 
  • 6:00-6:30 - Networking and refreshments
  • 6:30-6:45 - Introductions and updates
  • 6:45-7:15 - Growing Hyper-Performing Teams - Brian Haughton 
  • 7:15-8:00 - Rolling out Agile to the Enterprise - Ilio Krumins-Beens


There is no cost to attend, but guests must be
pre-registered in advance. 


Monday, January 23, 2012

Considerations For Running Your Transformation Like an Agile Project


In my earlier post, Eat Your Own Dog Food, I suggest to run any mid-to-large transformation like an agile project.  Several people have asked me to explain the differences between an agile software project and facilitating a transformation like an agile project.  I believe there is more value in focusing on similarities when working with teams, but the following will be helpful to those who are interested in managing a transformation effort like an agile project.

It maybe obvious, but the output of a software team and transformation team is quite different.  Software teams deliver working (“potentially ship-able”) code every sprint. A transformation team may deliver training sessions, provide coaching support, write best practices documentation, define and collect metrics, work to improve alignment between agile teams and the rest of the organization, or a multitude of other activities during a sprint.  What may not be as obvious is how these differences play out.

Fractional Resources
I often have fractional resources (someone who is on more than one team) as part of a transformation team, where as I am against it on a agile software team.  It is not because, most organizations under invest in the resources required to initiate and sustain a large transformation.  A successful transformation requires many different skills beyond those proficient in coaching agile practices.  

If possible, I like to get representation from Project Management Office (PMO), Human Resources (HR),  Communications, and Finance on the transformation team.  This is for several reasons:

  • being part of the transformation team allows these people to learn about agile practices first hand (because you are running the project like an agile project).  These people will act as force magnifiers for the agile transition with their colleagues
  • if you are on a team (and feel part of that team) you will be much more invested as compared with spending X% of time supporting another person’s initiative it allows me to leverage the specialized skill set and experience the person brings with them 
People from shared services Finance and HR often have unique and valuable perspectives on the organizations culture.  They can provide a helpful perspective in considering how to approach your transformation.  

Sprint Planning and During the Iteration
On software teams, I advise product owners to present a sprint goal so the team can rally around building a set of related features.  On a transformation, the team is often working on many different efforts, so having a singular sprint goal is less valuable.  It is a MUST however to have goals for release planning and clearly defined objectives when creating your transformation road map.

In sprint planning, I also have found it helpful when members of the team select which stories they want to work on during sprint planning.  Having a point person see a story through maintains continuity and helps manage external dependencies. Sometimes transformation team members select stories in-line with the expertise that that person has, but frequently another person will ask to work on it, so they can get experience in that area or to balance out the distribution of work.  Every sprint, however, we find that multiple people collaborate on tasks within that story.  This is due either to one person having extra capacity, or someone having too much on their plate.  This happens informally, but also during our daily scrum if we're trending behind based on our sprint burn down chart.  

When working with a software team, I tell them to limit the Work in Progress (WIP) and focus on completing the highest priority stories in the sprint backlog first.  The stories in a transformation backlog often have dependencies outside the team, so I find the my transformation teams will have more a higher percentage of open stories a few days into a Sprint than a typical software team.  

Preparing for the Sprint Review
Transformation teams may need choose what they present at the sprint review and spend more time preparing the presentation than a software team.  I advise software teams to show all the features they completed in a sprint and spend as little time as possible in preparing fancy power points for the demo, because the working software they build should be the focus of the Sprint Review.  The general rule of thumb I give to software teams is NOT to spend more than 2 hours collectively preparing for the demo.  It is important to make sure participants attend a well run demo, but completing the features prioritized by the product owner according to the team’s definition of done is the team’s top priority.

I have found that transformation teams cannot present everything they work on in a sprint at the demo.  Transformation teams work on meta-stories that require being creative about the best way to show them at the demo.  On average, the transformation team that I am working with completes between 20 and 25 stories a sprint.  If we were to try and demo each of these, the sprint reviews would be 4 hours long and my team would have to spend an inordinate amount of time preparing for the demo.  Instead, we select a few stories that we want to highlight at the sprint review and tend to spend slightly a bit more time preparing for our demos than the typical software development team.  

A few days before the end of the sprint, my transformation team will take 5 minutes after a daily scrum to indicate which stories be believe should be shown in the sprint review.   We do a silent vote, where each member gets three votes and they can apply 1 - 3 votes to any story.  The stories with the highest votes are usually are the ones we demo.  As product owner, I reserve the right to select other stories to demo, but most often the team selects the stories that I think are important to show.  Furthermore, hearing why team members believe a specific story is valuable to highlight often convinces me.

We rotate demo deck duty, and the primary person who worked on the story prepares how to demo the story at the sprint review.  S/he will create the materials for the sprint review and send to the person on demo deck duty who compiles everything in one presentation.  We do a run through the day before the sprint review and each person who is presenting explains what they want the audience to take away from their presentation.  The team gives each other feedback and we fine tune the presentation prior to the sprint review.  

Our sprint reviews are scheduled for an hour and often run that long.  I email  a brief description of what is going to be covered the day of the demo to key stakeholders and typically 10 - 25 stakeholders show up.  At the start of the demo, we display a list of all the stories we worked on in the sprint and with a different color font indicate which ones we plan to present.  Anyone in the audience can request that we speak to a story that is NOT selected for the demo.  After that, the team takes turns demoing what was selected to highlight.  Often we get feedback during the demo or suggestions on things that we can work on in future sprints.  We always speak to the progress we are making in the transformation and cover how we are doing against the transformation roadmap and release goals.  The Sprint Review follows the same agenda that our software teams follow.

Summary
Overall, I try to run an transformation as similar as I can to an agile software project.  Sure, the output of a software team and transformation team are different, but the basic principles behind why agile works applies to both.  If you try to run a mid-to-large transformation like a waterfall project your chance of success is much less.  You need to have a motivated team that is focused on delivering highest value, able to respond to the changing needs of the organization, focused on quality, and that is continually reflecting on how it can get better.

Although fractional resources are part of the transformation team, asking them to present their work often makes them an extremely invested members of the team.  All the members of my transformation team take our sprint commitments very seriously.  We are ruthlessly transparent when we don’t complete stories.  There is a temptation to alter the acceptance criteria to count stories as being complete before the review because transformation stories often have external dependencies.  I advise that you stick to the initial acceptance criteria discussed in sprint planning and use the sprint review to surface the blockers that prevented the transformation team from completing the story.  By showing your incremental progress against  the transformation roadmap and release goals, the team proves that it is delivering value.  Holding a consistent sprint review creates a feedback loop with your stakeholders.  By working in iterations or sprints, you can adjust the stories planned for the next sprint to address issues surfaced in the demo or to address the highest priority issues.

There are a few differences when you closely examine how an agile software team and a transformation team running their initiative like an agile project.  The important thing is that stakeholders seeing that you follow the same guidelines that you prescribe to your software teams.  Besides, when done right Eating Your Own Dog Food is extremely satisfying.
Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.