Doing Agile After Layoffs

Posted by Mark Levison on Jan 07, 2009

Sections

Process & Practices

Topics

Agile ,

Agile in the Enterprise ,

Change

Tags

Scrum

Adrian Carr writes about adapting his team's implementation of Scrum after layoffs. Originally, the team was a group of four developers, a tester, a Product Owner and the Scrum Master. After the cuts, the team has been reduced to four members with Adrian as part time Scrum Master and no dedicated Product Owner. The business unit has the same staffing issues as the development group and so is only able to provide a "senior point-of-contact person who understands the business and is authorized to make decisions on the project". So the question he was left with is: what parts of Scrum to keep? Adrian's first pass included:

• Keep just the parts of Scrum that make sense in a smaller group: daily standups, short sprints, reviews, retrospectives, visible project burndowns.
• Everybody on the team takes on some of the Product Owner role meeting with stakeholders, end-users etc, but Adrian will maintain the product backlog and make final decisions etc.
• Eliminate waste
• Keep things as simple as possible.
• Take credit for story points only for features deployed to production, the expectation is that this will force the team to create smaller more manageable features. This should lead to a reduction in cycle time and provide more feedback.
• Work in very small batches of work - only two to three items at a time
• Focus on delivering the highest value items first.
• Know who the software is being developed for. Know their names, their roles and why they the things they do.
• Watch for external factors that slow the team down and hammer away at them.

Robin Dymond, of Innovel, has one major concern: the lack of a dedicated product owner. He says that for a developer to take on the role he will have to become a business subject matter expert, taking away from the time he has to do development. Instead he recommends:

If the business people are pressed for time then the dev team can have frequent short meetings with them, they can approve acceptance criteria as opposed to writing it, and they can focus on the priorities. However they need to own the role, and own the responsibility. The team can't own this for them, because the team will inevitably interpret things differently, choose different priorities, and make different decisions than the business would.

In Mary Poppendieck's opinion (author of Implementing Lean Software Development), the Product Owner isn't always necessary or even desirable, as she considers that if the developers understand what the customer wants the product owner adds another layer and there is likely to be information lost due to handoffs. For Mary, the key is having a good simple measurement that everyone agrees on as the goal, then all features can be measured against the value they deliver for this goal.

Ron Jeffries warns against the possible lack of clarity between the team, as Product Owners, and the Business Unit. If the product turns out not to be exactly what the customer needs, the business is likely to turn around and blame the development team for their decisions. Ron points out that one of the advantages of the traditional Product Owner/Customer role is that the business unit then has no one to blame but themselves, if the product doesn't meet the end user's expectations.

• Older >