Over the weeks we have had considerable deep dives into Scrum and how it has evolved over the last ten years. The first week we looked it at a high level, then we had a look at the roles, ceremonies and artifacts.
Now we have the opportunity to see how it has not evolved. It is important to note that Scrum is a Project Management Method (purists might argue it is a framework). It is not, nor has it ever said it was a methodology. Nor has never said it was a method for improving the capabilities of software developers.
It was created and in use prior to the name “Agile” ever being associated with it. It was one of the many “light-weight” methods that were contending for attention away from Waterfall. When Jeff Sutherland, Ken Schwaber and Mike Beedle joined fourteen other signatories in Salt Lake City there was little that they could agree with other than the manifesto. Despite this, the manifesto propelled the light-weight methods into the limelight and was a vocal enabler for a new future.
Some IT people have never experienced Waterfall or even RUP. They don’t know what it was like in the old days. Maybe the problems were due to commercial issues rather than method issues, but even with all the hoopla over Agile or Scrum not working or dead I remember what it was like in those days and we are certainly better off for those signatories creating the manifesto and propelling our focus.
But like Waterfall not being a comprehensive methodology Scrum certainly is not. This means that when people are trying to apply Scrum they are only applying a single piece of the puzzle. Many believe that Scrum = Agile. Those that know better are left in a minefield of information overload having to gleam which other methods they need to apply and how it will correlate with their existing process. In essence, Agile is like a toolbox. 
There are many tools that you need to use to fix the problems you have. Some tools won’t be the right tools for your problem. Arguably if you have no problems then don’t use any tools… as long as you aren’t fighting Ostrich syndrome.
Scrum has just a few of these tools. Over the last ten years it is evolved minutely to the problems and the new tools that are required in our box. Evolution did include the addition of retrospectives, intellectual property that was owned elsewhere. Even the origin of Daily Stand-ups was IP from elsewhere. Nothing is new, concepts are just re-played and re-packaged. Some might argue that the reason Scrum did not evolve was primarily due to IP concerns. But maybe, if the upper echalon of Scrum had listened to the voices of the community they would have had the opportunity to incorporate these new ideas and thoughts.
So what has evolved in the Agile community over the last ten years that Scrum has ignored:
- How to apply Scrum to teams that have multiple customers that additionally have to support (ie potentially hotfix) production environments
- How to identify constraints in the flow of the system
- How to ensure that the work the Product Owner comes up with is the right work
- How to incorporate feedback loops in order to verify benefits realisation
- Stories, Epics, MMFs, MVPs, Themes, Parking Lots/Feature Progress Charts, BDD
- How to estimate (eg planning poker)
- How to understand what is more important – scope, cost, time or quality? eg Rob Thomsett’s Success Sliders
- How to create a backlog in the first place
- Who has the money and what visibility should they have?
- Mastery practices, arguably owned by XP, eg pair programming, TDD, Continuous Integration; or even simply where design and architecture fits in
- Where management, leaders, Project Managers and Business Analysts fit in
- Where business cases, governance, procurement and commercial reality fits in
- What tools to use to support the cultural change that goes along with implementing Scrum
- How to create effective walls and other visualisation techniques
- How to deal with the distribution problem (this is huge and only going to get worse)
- How to apply it to anything other than software development
- How to scale it to large organisations where team members are working on multiple projects at once or significant dependencies exist
- How to get any form of metrics on effectiveness of the change including temperature checks of people’s comfort levels of the change
- Incorporating all elements of the project and not just thinking of software development only – ie communications, training, process re-engineering
Maybe I am just asking too much. Methodologies seem to be dead, disparate ideas spread everywhere seem to be the norm. If complex systems are so hard why are we making it harder as a community to find the answers?
Agile Forest 
Good blog. Interesting stuff.
You’ll probably call me a “purist”, but the reason you may see Scrum as stagnant is because it’s simply a framework and as a framework it has resisted pulling in many of the valuable techniques you’ve listed. Why? There are a couple of reasons.
One is that Scrum isn’t just for IT. If Scrum were to incorporate TDD, it wouldn’t be so applicable to non-IT work. This doesn’t mean that IT developers using Scrum shouldn’t use TDD….they should. There is nothing incompatible with any of the practices and Scrum.
Another is that Ken Schwaber’s vision was to avoid the inevitable bloat that impacts methodologies. Look at what happened to Six Sigma, RUP, etc…
At its essence, Scrum is about people. We all get hung up on the practices, roles, artifacts, etc. The best Scrum teams I’ve seen have changed everything they do. All that remains are the values…probably can’t even call it Scrum anymore, but the point is not to “do Scrum perfectly”. It’s simply a starting script for exploring better ways of making things.