I recently read a very interesting article - 'The Art of Compromise: Scrum and Project Governance' by Mike Cohn. In this article, he asserts that agility (Scrum) and project governance, with a few compromises on either side, combined with the set of actions below, can lead to a successful combination of agility and oversight:
Negotiate and set expectations up front. Undoubtedly, the first Scrum project to go through the governance process in your company will have challenges. There will almost certainly be some things they cannot do; for example, a Scrum team cannot provide a thorough design before getting permission to start coding, because design and coding will be done concurrently. The only solution to this is for the team to negotiate with the necessary governance groups in advance. The more support a team has for this and the higher up in the organization that this support reaches, the better. The team does not need to solicit a permanent change in governance policies. The change can be pitched as a one-time experiment.
Fit your reporting to current expectations. The project review boards or oversight committees that provide project governance have existing expectations for what information each project is to provide at each checkpoint. Don't fight these expectations. If they expect a Gantt chart, provide a Gantt chart. When you can, however, try to slowly shift expectations by providing additional, more agile-friendly information. If burndown charts are suitable to show, do so. Or perhaps you want to include a report showing the number of times the build server kicked off continuously integrated builds and the thousands (or perhaps tens or hundreds of thousands) of test runs that were executed.
Invite them into your process. Scrum teams can supplement less-detailed formal governance checkpoints by inviting governance committee members to participate in the regular meetings they will hold. I like to extend the well-known technique of management by walking around into management by standing around. Encourage managers and executives involved in the governance of a project to attend the daily scrums, where they can stand and listen to what is occurring on the project. The same shift from documents to discussions that is created by working with user stories needs to occur with project reporting. Encourage people to visit the team or join its meetings to see for themselves what is being built.
Reference a success. Nothing convinces like success. Do whatever you can to get a first project or two through lightened or reduced governance checkpoints. Then point to the success of those projects as evidence that future projects should also be allowed through.
It's one thing to look at agile software development in a test tube; it's another to experience it in the real world. In the test tube, agile methodologies like Scrum are easily adopted by all members, and the nasty realities of corporate politics, economics, and such cannot intrude. In the real world, though, all of these unpleasant issues do exist. It is rarely as simple as deciding to use Scrum and then being able to do so with no other constraints.
You might also be interested in reading:
How to Implement Scrum in 10 Easy Steps
Scrum Principles & Best Practices
5 Scrum Transition Anti-Patterns
Best Practices in Agile Development Governance
Excellent, in particular the last paragraph.
I'd add that there should be more discussion of the impact on the Agile process when those nasty realities do intrude. Same concept in the end as referenced dealing with governance: start with small, short projects that demonstrate success.
I'd be inclined to get a few of those under the team's belt before inviting governance (or higher managers?) into the meetings. I suppose it depends on the individuals.
Posted by: Steve Kovacs | February 25, 2010 at 12:13 AM
Thanks Steve. Totally agree - nothing gets buy-in more than a few successes under the belt. Focusing on the 'sure-fire' short terms wins in key.
Posted by: Mark | March 04, 2010 at 12:09 PM
Today, with the advancement in technologies employee time tracking software have come into existence that monitors how much time your employees have been actually spending on work. The software automates total working hours for each
Posted by: Project Management Software | June 01, 2010 at 09:04 AM