Posts Tagged ‘agile’

The light at the end of the tunnel is a rainbow, not a train.

Thursday, August 11th, 2011

Ever hear the expression “the light at the end of the tunnel is a train”? Well if you’re a project manager faced with a transition to Agile, it probably feels like that! The good news is that it’s not a train, it’s a rainbow.

Transitioning to Agile is a change. A big change. Change produces anxiety because our brains are hardwired to resist change. And if you’re a Project Manager who sat through a Certified ScrumMaster or Certified Scrum Product Owner class, you probably noticed that there are no PMs in Scrum. Not only that, the responsibilities of the PM are divided up between ScrumMaster, Product Owner, and Team. So now you’re probably wondering, “Will I still have a job?”

Yes, you will. Not only that, your job will change in wonderful ways, hence the “rainbow” instead of the train. Agile in general and Scrum in particular will allow you to focus on what you do best. The catch is that you will have to transition to a ScrumMaster, Product Owner, or Agile Program Manager. Which one is best for you?

The ScrumMaster helps the team help themselves. As a ScrumMaster you will facilitate the Scrum ceremonies (Sprint Planning, Daily Scrum, Sprint Review, & Retrospective), assist the team in removing impediments, create big visible information radiators, and coach the team on Scrum and Agile techniques. Instead of asking the team to do things for you, you’ll focus on how to help the team. This role is great for PMs who like to help people do the best they can do. Many ScrumMasters go on to become coaches.

The Product Owner is the sole representative of the ultimate end users. As a PO you lead the ongoing requirements discovery, elaboration, review, and acceptance processes. You will prioritize features and determine the contents of the release based on team velocity, value of features, and budget. PMs who are great at managing budgets and stakeholders do very well as Product Owners.

ScrumMasters and Product Owners work closely together. The SM is team-focused while the PO is stakeholder focused. But what about large multi-phased projects involving multiple teams, especially non-technical teams like Manufacturing & Distribution? This is the natural space for the Agile Program Manager.

Do you like bringing together disparate teams to deliver a single solution, i.e Concept-to-Cash? Working with product development, marketing, manufacturing, IT, help desk, sales, finance, legal, etc.? Then you are exactly what is needed for Agile Program Management. While the PO is working with stakeholders and the ScrumMaster with the technical teams, you’re the one to bring it all together. You’re also the one to keep an eye on the production support processes and training.

So which role appeals to you the most? In my experience, PMs already have a natural inclination towards one of these roles. There are PMs who dread dealing with stakeholders and would rather just work with engineering. I’ve known PMs who handle stakeholders effortlessly but struggle with developers. And I’ve known many PMs who are natural integrators that can see the whole better than those around them.

Given that most if not all of us, already have a natural disposition towards ScrumMaster, Product Owner, or Agile Program Manager — why not go through the tunnel and work in the rainbow? Life’s much better over here.

If you’ve read this far, you deserve a reward. When registering for any Agile Raven class, enter coupon code “Rainbow” and get an immediate $25.00 discount. Just my way of saying thanks for reading the entire post. You did read all of it, right?

Scrum — it’s not just for software anymore

Wednesday, September 16th, 2009

Is Agile only for software development? Or perhaps only for product development? At Agile2009 in Chicago, Jeff Sutherland and his wife Arlene presented two papers on adopting Scrum, one at OpenView Partners Venture Capital and the other at a number of Unitarian Churches.

I attended Agile2009 in Chicago and there were two presentations about implementing Scrum in non-software development organizations.  “Scrum in Church: Saving the World One Team at a Time,” by the Rev. Arline Conan Sutherland, Jeff Sutherland, Ph.D., and Christine Hegarty as well as “Take No Prisoners: How a Venture Capital Group Does Scrum,” by Jeff Sutherland, Ph.D. and Igor Altman. I had first heard about these parallel Scrum adoptions from Jeff Sutherland himself in early 2008 and was eager to see the papers once they were formally presented. I was not disappointed.

The abstract from “Scrum in Church”:

From 2005 – 2009 the author led Scrum teams in churches in Massachusetts, Connecticut, Florida, and Delaware. Scrum was designed to increase productivity and improve quality through teamwork. This experience report shows how Scrum was implemented in non-profit organizations to break down silos of knowledge and activity, encourage communication and collaboration, improve the working environment and personal relationships, and drive higher velocity and quality throughout the organization. Non-profits have impediments that are difficult to overcome – part-time and volunteer workers, narrow specialization, little to no experience with project teams, and political problems whose roots can go back as far as 1692. Scrum as an institutional change agent is invaluable to a church.

The abstract from “Take No Prisoners”:

In 2007, OpenView Venture Partners decided to adopt Scrum as best practice in software development in its portfolio companies and Scrum as the standard practice in internal operations. It is one of the first high-performance non-software Scrums that delivers twice as much value in fewer working hours. The model at OpenView provides data and a working manual on how to do Scrum outside of software development. Their aggressive removal of impediments (take no prisoners!) distinguishes them from Scrum implementations that are unable to remove institutionalized waste.

My take-aways:

The Scrum methodology is to be adapted to the environment. One size does not fit all. Arlene wrote “each and every time Scrum is introduced into a system it has to be adapted.”

Biggest gains in productivity came from:

  1. Creation and active management of a product backlog (20% or more new features, 80% maintenance, & aggressively remove low value stories & projects)
  2. Clear definition of “done.”
  3. Creation and aggressive management of an impediment backlog combined with root cause analysis.

People who are used to working as a team generally don’t resist the Scrum method as much as those who are very independent. In fact some people are too independent to be part of a team.

When stories are broken down into tasks, it is easier to see how team members can help each other out.

Interruptions and emergencies are a fact of working life and do in fact interrupt sprints [Church]. My response to this is that the key then is to carve out chunks of protected time (c.f. Covey’s 1st things 1st and Cirillo’s Pomodoro Technique.).

Vocabulary can be a stumbling block. I think this is because vocabulary is dependent on the culture. There have been a number of blogs on the topic Agile adoption being a culture shift with the inevitable culture shock. Those of us who look to implement Scrum and Agile in non-software organizations should watch our vocabulary. We should balance explaining concepts in a language the local culture understands with retaining those parts of the vocabulary that are different enough to be retained. For example, it’s safe to call a sprint an iteration or even a fixed schedule release. Back in the late ’90s we called this a release train.  Daily Scrum, stand-up, or daily status?  Whereas impediments are impediments because they are those things which impede us from achieving our goal.

What’s also interesting is that all the teams mentioned were most productive with one-week sprints. This contrasts sharply with the accepted wisdom that novice teams start off with one-month sprints and eventually settle on two-week sprints. I suspect that the difference is mostly due to the nature of the work. In both papers the teams are not creating products, software, or any system. In fact most of their stories are so small they resemble tasks. I’m reminded of Stephen Covey suggesting focusing one week at a time instead of one month at a time. The take-away here I believe is the sprint duration must be sized to the project at hand.

While not mentioned in the Church paper, the Take No Prisoners papers discusses at length the pitfalls of estimating in ideal hours instead of points. The biggest impact is that velocity remains flat as teams become more productive. Whereas using story points shows that the team can deliver more story points over time. By focusing on ideal hours, the team has to make some guesses on increased productivity (focus factor) in order to understand just how much their capacity really is. This strikes me as a compelling argument to avoid the temptation all of us faced when first confronted with estimating in ideal days versus points. This also speaks to predictability which is critical when trying to plan a release.

At the 10,000 foot level it comes down to Four Focus Areas:

  • Direction (the backlog)
  • Speed
  • Quality
  • Sustainability and Predictability

and avoiding the “5 Dysfunctions of a Team” by embracing:

  • Trust
  • Openness to conflict
  • Commitment
  • Accountability
  • Attention to Results

Do you have any experience applying Scrum and/or Agile in a non-software development team or organization? Please let us know. We’d love to hear from you.