Scrum Rollouts - Critical Success Factors

In a previous role, it was my dubious pleasure to pilot the implementation of Scrum in the organization, taking on the Scrum Master role. More than a year later, Scrum was a core business process at all levels of the company. However, we still had to learn some lessons along the way. Although in no way comprehensive, I've summarized the critical success factors for various project stages below:

Project Inception

1) Introduce a single empowered business owner for each group of stakeholders

There are two reasons for this:

• A single owner should hopefully lead to a single list of priorities at the start of your sprint. The team can then work through these in order without needing to explain the delivery order to unconnected stakeholders.
• Also, by empowering a single person to run triage between the business cases for various backlog items, the product management and analysis resources can spend more time on delivery and less time rushing around trying to keep everyone happy.

2) Visibility of emerging requirements (a "Fuzzy List")

This allows breathing space for pre-planning in previous sprints, enabling the team to highlight expected blockages to the Scrum Master and the business before they have an impact on delivery.

3) Visible priorities for the next sprint

Similarly, if the team has an idea what's important for future delivery they can use any "free time" they have in the current sprint on constructive activity towards these future goals.

4) Visual capture and display of business priorities

This makes it easier for the team to keep these in mind throughout the delivery cycle. This can have a similar effect to displaying product flow diagrams of the project critical path in structured methodologies.

Elaboration

5) Factor support work and Quality Assurance into estimates

For Agile development to be successful it must always be possible to de-scope new functionality to keep time & resources fixed.

However, if overheads on the critical path to deployment are not factored in, by the time you realize the impact, it may be too late to de-scope functionality to meet deadlines. This can throw off the whole process.

Another advantage of keeping track of time spent support work is that you can get a clear idea of burn rates.

6) Have dedicated analysis resource

As discussed above, if a team has the capability to ensure requirements are sufficiently accurate and detailed, planning and productivity can only improve.

7) Maintain an open, visible task list for product managers and analysts

When Agile methods are sold into most organizations, the key selling point is that requirements can be captured at a high level and on a piecemeal basis, just-in-time for each feature to be developed – but without losing productivity.

However, the key thing about just in time is that it also means not too late. It’s often all to easy to focus planning on what the delivery and QA teams should be delivering, rather than ensuring they have enough detail to finish the job.

Allowing team members to maintain a visible task lists for product teams not only makes them visibly accountable for the level of detail, also but helps to ensure the right questions get answered.

8) Estimates in 1/2 days

This is a personal preference. Generally, it’s much easier to say "Could you finish this before lunch” than to take out a stopwatch during every coffee break, especially for teams who aren’t used to estimating.

With half days as a starting point, you can often get a good idea of whether estimates in hours are really worth the effort, as the team will have more breathing room and may need less detail during planning.

Construction

9) Use sensible change control, and be prepared to drop scope

In order to work in a truly Agile fashion, it can be critical that the business provides a mechanism for de-scoping if sideways issues come through half way through development. Assuming you do have a single business owner, he/she will need to be empowered to make trade offs between work for different internal customers.

If this mechanism is not provided, it becomes impossible for the Scrum Master to protect the team from external interference, because they will be held accountable for non delivery of previously promised work.

Once this control is in place, collaboration with the business will see a clear improvement, because the team can openly talk with the business without exposure to extra work during the sprint.

10) Have a sensible iteration length (with an end to each iteration and a set time for retrospectives)

A good way to start is to ask yourself - how long can this business go without changing its priorities? Even with a change control process in place, if a sprint is too long you may find yourself constantly revising your backlog, parking work in progress and regression test rollbacks to deal with altered priorities. If you can get this right, the expectations of the business will become much easier to manage. Another key benefit of a set sprint length will be better estimates by the team, as they get a better feel for what can be achieved in the available time.

11) Don’t blur lines between roles

The key thing here is the difference between inward and outward facing roles.

• The Business Owners focus is defining an satisfying a business case. His time will be spent managing their expectations and promoting ROI. He shouldn’t be assigning tasks to developers.
• The focus of the Iteration Manager/Scrum Master should be the team, promoting self organization and removing obstacles to progress. He shouldn’t have to prioritize the project backlog and define the business case or product road map

You may be hard pressed to find anyone who can do all of the above simultaneously without letting someone down or working a 48 hour week. This will be magnified by the level of authority of the stakeholders he or she deals with. If a Project Manager has regular meetings with the board, any developers waiting for him to write up his meeting notes may be waiting a long time.

12) Focus on what’s left to do rather than what’s been done

The team should always concentrate on meeting outstanding business goals. Any finger pointing should be saved for retrospectives (see below).

13) Have a clear definition of "Done"

In a multi disciplinary environment, it’s surprising how many answers you can get if you ask each individual if a particular feature is “Done”. However, if you ask "Is this feature ready to be shipped?" the answers can become much more informative. By working out a clear definition up front, you can ensure that everyone has a clear view of progress. See this post http://www.scrumalliance.org/articles/37-are-we-there-yet

14) Make the team full time equivalents

A little knowledge can be a dangerous thing. The following scenario is all too common:

• In a legacy system environment, a developer "Bob" is the only one who knows anything about one subsystem (however limited).
• When any issues appear in this area, Bob is instantly assigned to fix them (no-one else knows how)
• Bob gets visibility from the business for being the goto guy for issues this subsystem. He is all but forbidden to work on anything else.
• Bob eventually gets bored, because no business owners allow him to work on anything new
• Bob quits, leaving no documentation because he was too busy fixing the same issues over and over

The alternative is to use of pairing, knowledge transfer and peer reviews to get the whole team up to the same level. The team will work better together, produce better estimates and will require less supervision (as well as start policing slackers).

Transition

15) Start deployment requests as early as possible

Two key reasons for this.

• While development teams can take an Agile approach to project completion, most operations and QA teams will usually need advanced warning to do anything non routine.
• This can focus the team on producing shippable functionality by the end of the sprint, including deployment instructions and post launch testing.

16) Maintain a suggestion box for retrospectives

Even when regular time slots allocated for retrospectives are allocated, there may be limited time for all players to have their say. Creating a mechanism for collating these during the sprint can give retrospectives a clear agenda, and ensures everybody's concerns have a chance for consideration.

17) Use collaboration technologies to track progress (Webcams, Wikis, Sharepoint)

Aside from facilitating distributed development, this will allow stakeholders who cant make the meetings to keep track of progress in real time, and encourages everyone to gain an understanding what other stakeholders are after too.

18) Don't run before you can walk (and if it ain’t broke, don’t fix it)

As with anything new to an organization, try to start on a scale where you can show demonstrable benefits to the business. You will notice that the first thing in the list above is the hardest - ensuring the right people are empowered to make decisions. Start by working around existing regular activities in the organization to make sure the key stakeholders are available when you need them and work from there.