Scrum Project Management as a Simple Rules Framework
“Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves” – Ken Schwaber and Mike Beedle, Agile Software Development with Scrum
The Scrum methodology is elegant in its simplicity. It teaches us that when processes are not stable, and outcomes cannot be predicted within sufficient tolerance, we cannot use planning techniques that rely on predictability. We must rely on observation. We must adjust the processes as we go and guide them to create our desired outcomes. Using this philosophy as its basis, Scrum is founded on three simple principles: make everything visible, frequently inspect outcomes, and adjust the process as necessary.
People really like simple messages and Scrum delivers in spades. Scrum is easy to communicate and the practices are rather straightforward and easy to implement. You can put a single diagram on a single page and talk someone through pretty much everything you need to know. There is power in the simplicity of the message and that has been a major factor in Scrum’s rise as the de facto agile methodology in use today.
The simplicity of Scrum can be deceiving. That simple, straightforward message comes at a cost. Scrum is not all there is to software development and it’s not all there is to good project management. If we are fortunate enough to have a group of really great developers, a fully engaged product owner, and a team that can operate with some degree of independence from the rest of the organization; the simple messages of Scrum are a great way to lead a project. The quality of the team allows you to get away with a barely sufficient methodology.
What about when our context is not so simple? What about when we have to develop complex systems architectures or work with a tightly coupled legacy system? What about when we have multiple teams distributed across the globe? What about when our product is an integration of several different products, each with their own product owner? What about when we have to deal with procurement or complex human resource concerns?
Scrum is silent on these issues.
Scrum abstracts these answers behind the team’s ability to “devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves”. While we are beginning to answer some of these questions, Scrum doesn’t really give us much guidance on how to pull it all together. There is clearly more to the story than Scrum is prepared to address.
You know what though? That’s okay.
It’s okay because Scrum is broad enough to provide simple rules for one set of problems and a framework to handle more complex issues (and incorporate more complex strategies) as our teams need them. The simple rules of visibility, inspection, and adaptation don’t break down. They have no geographic boundaries. They don’t care about the size of your team or the expertise of your team members. They are about how we are going to control our projects in the face of uncertainty.
Scrum is a barely sufficient, simple rules framework for developing great products. It gives us space to apply our knowledge and skills and the freedom to adapt to our surroundings. We just need to be aware of what Scrum leaves out and be prepared to fill in the blanks. That said, I would rather be given a framework for adaptation than a heavyweight methodology. Very seldom in software is there one best way to do everything. Our processes should not assume otherwise.
Comments (4)
joapen
hello,
reading your post I have to recognize that in the past I worked following some of these rules without knowing them in internal projects where we need to go one step ahead in technology. Right, it was thanks to the Sponsor of the Project was comfortable with the scenario and resources selected for that execution.
Now I have a question, how can you define goals & baselines for measure the Project success for a external Client: KPIs, agreed baselines, definition of deliverables…
What could be the best ones?
Best Regards
Mike Cottmeyer
joapen,
Thanks for taking the time to comment on my blog. Your question reflects a problem that is challenging many agile teams. We want to talk about trust and empowerment, but what about when we have external clients that want contracts and accountability? What about when we have clients that are making us prove we’re on schedule and spending their money wisely? What about when we have hard deliverables with no flexibility?
I don’t think the answers here are easy and they are definitely not one size fits all. The approach you take will depend largely on the relationship you have with your customer.
I built contracts with an offshore vendor that specified no hard deliverables. We agreed that we would meet every two weeks and decide what work would be completed. The contract specified that once the “two week” contract was established, they had to deliver at least 95% of what they agreed to.
I was at a presentation with Jeff Sutherland a few weeks back. He advocated creating agile contracts that allow the customer to review the product at the end of every sprint and decide at any time the project was over. They would have to pay Jeff’s team 20% of the remainder of the agreement if it ended early.
This is built on the premise that 60% of features are never used. Once the customer is satisfied that the project has delivered sufficient value, they get to pull the plug early. It created a financial incentive for the customer to work in an agile way.
As for metrics…
When I am managing teams, I tend to rely on a high level release plan and a key set of date driven milestones. They milestones are less to manage the team and more to give me an idea of where I am against our original plan. I also start my project with an expected velocity. While this might not feel very agile, it gives me an idea of where I will need to be in order to deliver to my customer’s expectations.
Those indicators become my baseline from which I assess the teams progress and capacity to deliver product. Very quickly in an agile project, I will learn how the team is really doing and what they are really capable of delivering. This allows me to work with the customer early and adjust if necessary. I have found that if you manage expectation appropriately up front and communicate often, you can work together with you customer to guide the project into an acceptable outcome.
If you are dealing with a customer that is intent on fixing time, cost, and schedule… you are going to have trouble and better have added enough room in your fixed price contract so that you can be successful. This is project physics 101… you cannot fix time, cost, and schedule. If you choose to do this, or you have it done to you, there is nothing Agile is going to do to fix it for you.
joapen
Great,
I see the roadmap you have defined with these examples and the contract scenario you present.
For the metrics and perhaps for the contracts I suppose you also play with quality baselines or KPIs that allows you to measure the success or client satisfaction.
I see, I need to do work a lot of work before to start making the triple constrain flexible.
Thank you so much for sharing your thoughts.
Project Management Software
The initiation processes determine the nature and scope of the project. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’ needs.