Agile Forest

A number of people have asked me to explain why I feel Scrum has stagnated and fails to continue to grow. I couldn’t simply provide a 140 character reply that would suffice for those that needed a deep and meaningful reply and so this is part 1 of a 5 part series on Scrum over time and an in depth analysis of how “agile” Scrum really has been over the years.

The 5 part series will be broken down into the following:

1. A look at Scrum at a high level
2. The key roles
3. The key activities/ceremonies
4. The key artifacts
5. What is missing

I really don’t want to have these five posts come over as Scrum bashing because I do truly believe there are some damn good elements in Scrum worthy of usage. In fact, I could just as easily do the same analysis for any other software methodology and come out with similar complaints – this is because we are sorely lacking a framework that is both incredibly flexible and is rapidly adaptable directly by the community. As I have said earlier the reason why I have focussed on Scrum is because people have asked me to address it.

So before we get into the detail just a quick overview of how the analysis was done – 5 cuts of data were taken from the internet. These cuts were from June 2003, March 2007, March 2009, September 2010 and a few weeks ago. These dates were chosen based upon major content changes on the websites analysed. Two key sites were analysed for core content – scrum.org and scrumalliance.org which split in late 2009 (capture begins in October). Without doubt these two sites would be the key ‘core go-to’ points for Scrum users.

What is Scrum?

In July 2003 Scrum’s overview was:

An iterative, incremental process for developing software in chaotic environments. Scrum consists of a series of 30 day sprints, each sprint producing an executable. Between sprints, all interested parties evaluate progress and reevaluate technical and business requirements. Work is reestablished and the team enters into another sprint.

The pulse of Scrum is the key to its success … management determines what should be done prior to every sprint, their determination influenced by prior deliverables and requirements. During the sprint, the team is left alone and produces the best software possible : let in chaos, keep out chaos, let in chaos, keep out chaos, let in chaos, keep out chaos … etc.

In March 2007 the pdf was much the same but had some really nice details about it being an empirical process control and what that meant.

In March 2009 the overview read as:

Scrum is an agile software development framework. Work is structured in cycles of work called sprints, iterations of work that are typically two to four weeks in duration. During each sprint, teams pull from a prioritized list of customer requirements, called user stories, so that the features that are developed first are of the highest value to the customer. At the end of each sprint, a potentially shippable product is delivered.

Scrum is made up of three roles, three ceremonies, and three artifacts.

Three roles: the Product Owner, who is responsible for the business value of the project; the Scrum Master, who ensures that the team is functional and productive; and the self-organized team.

Three ceremonies: the sprint planning meeting, daily scrum meetings, and sprint review meetings.

Three artifacts for prioritizing and tracking tasks: the product backlog, the sprint backlog, and a burn down chart.

In September 2010 more detail was added into the overview:

The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them

while providing a framework within which complex products can be developed.

Scrum, which is grounded in empirical process control theory, employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control.

The first leg is transparency

Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. Not only must these aspects be transparent, but also what is being seen must be known. That is, when someone inspecting a process believes that something is done; it must be equivalent to their definition of done.

The second leg is inspection

The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected. The frequency of inspection has to take into consideration that all processes are changed by the act of inspection. A conundrum occurs when the required frequency of inspection exceeds the tolerance to inspection of the process. Fortunately, this doesn’t seem to be true of software development. The other factor is the skill and diligence of the people inspecting the work results.

The third leg is adaptation

If the inspector determines from the inspection that one or more aspects of the process are outside acceptable limits, and that the resulting product will be unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation. There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling,and enjoyable.

Scrum employs time boxes to create regularity. Elements of Scrum that are time-boxed include the

Release Planning Meeting, the Sprint Planning Meeting, the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.

Lastly as at now on Scrum.org:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is:

•  Lightweight
•  Simple to understand
•  Extremely difficult to master

Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

and ScrumAlliance.org:

Scrum Principles

The framework and terminology are simple in concept yet difficult to implement. Successful Scrum teams embrace the values upon which Scrum is based (paraphrased from the Agile Manifesto):

We value

• Individuals and interactions over processes and tools

• Completed functionality over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, the items on the left matter more.

True success with the Scrum framework comes from teams and organizations who understand these values and the principles that form the foundation of all agile processes.

We’ve introduced some new terms in describing the Scrum framework. Let’s look at them in more detail. Scrum is made up of three roles, four ceremonies, and three artifacts.

Results

So what changed in the general fundamentals of Scrum over the years given what we can see of the opening overviews:

• Timebox has adapted from being a strict 30 days to one month or less
• The three roles concept has never changed (covered in more detail in part 2)
• The ceremonies increased from three to five and then back down to 4 (covered in more detail in part 3)
• The three artifacts have never changed (although as you will see in detail in part 4 that isn’t the case under the covers)

Opinion

• The “30 day” rule isn’t a huge deal. I do recall reading in 2004 that you could reduce it down and there was mention as to what the impact would be to the sizing of the other ceremonies but it was something that I had to drudge around to find. If you took it originally as a rule then one may have been disadvantaged but remember back then delivering something once a month was actually a big deal.
• My biggest gripe is that most people now don’t do thirty day sprints. 57% of the community are using 2 week or less sized sprints. Given that only 14% of the community are using sprint lengths anywhere near one month why wouldn’t you just change this to fortnightly. I understand that part of what they are saying is that more than 30 days is unacceptable but to be honest, continuous improvement feedback loops where the sprints are one month are terrible. I have tried four week sprints, one week, two week and daily. I learnt through trial early in 2004 that two weeks was ideal. Most of the community knows this now, why can’t the overview reflect this and not lead new starters to Scrum to believe that 30 days is the right answer.
• It was interesting to see that the ScrumAlliance re-wrote the 2nd manifesto statement – “working software” was changed to “completed functionality”. Part of me wishes they would have re-wrote it even further, but this was a curious change to me. Why not mention “value” anywhere? Software that we deliver should be working, completed, but most importantly should deliver value.
• For my 2 cents the format of the March 2009 overview actually gives the best introduction to someone unfamiliar with Scrum as to what it is.
• I wish most of these statements took out the ‘software development’ bit. Yes it was born for addressing software development process issues, but the reality is the framework applies really nicely for more than that and I would love to see the scope widened further to a broader community including those using it for other purposes.