Agile Forest

 

With the advent of Scrum.org releasing their new Scrum Guide I wanted to take the opportunity to give it some academic and opinionated discussion. I’m going to start with the notes related to the update. They start by outlining the major change to Guide that has resulted in a good portion of content being removed from it. A nice little analogy is used relating it to a game and how Jeff and Ken wanted the Guide to no longer be a strategy plus a rule book and just focus on the rules.

I am going to probably do one of my few positive reactions to this, in fact I applaud it. Most of the process driven Agile community has known for a very long time that there is a key difference between a process, a practice and a technique. The notes even hint at that a little down by dropping the analogy and specifically referring to practices and techniques.

So, and here begins my major issue, if the Scrum Guide is now no longer a bit of everything and is more closely aligned to a set of rules, then why call it a guide? Guides are something that you can follow but it is not considered mandatory. And yet rules are things that are finite and mandatory. This would have been better called Scrum Rules, or better Scrum Process or Scrum Framework. If you have a look through the actual guide what you may see if you have a strong process background is an overview (model), some key principles that feel a little out of place, roles and responsibilities, activities (sneakily called events) with alternate scenarios, FAQs and artifacts. It is a serious hodge-podge of information that makes me want to beat my head on a wall. It wouldn’t be so bad if it was logically set out in those groupings but it bounces around which would confuse a reader unfamiliar with Scrum. Audience is very important when writing and I don’t believe they have been taken into consideration here.

Anyway, as a general rule of thumb a process will always have an overview, roles and responsibilities, activities, artifacts related to activities and alternate scenarios. FAQs are usually separated out. So as you can see content wise it aligns very strongly with a process document. I suspect Jeff didn’t want to call it a process so as to get around the whole big problem of “Individuals and interactions over processes and tools” debate. If you call Scrum a process then people will feel that they can ignore certain activities due to the manifesto rule and if this guide should be considered a rule then there is a direct conflict of beliefs.

Back to the notes I want to go through some of the major described changes.

The team of people performing the work of creating an Increment is the Development Team. Regardless of the work performed by individual team members, they are known as Developers.

Okay, so what this is saying is continuing the belief that there should be no specialization within the team and everyone delivers working software. This is specifically outlined in the second bullet point of the Development Teams Roles and Responsibilities section of the Guide. More than ten years down the track where for so long Scrum pushed and pushed people into this cross functional mould where Project Managers were obsolete, where Business Analysts were obsolete and then testers were obsolete. Any Agile Coach who has been applying Agile for a very long time now, including pure Scrum implementations would tell you that this single minded focus on generification is just not working, is unrealistic and is starting to get be strongly pushed against by Kanban’s recognition of specialisation. Furthermore, when you apply Scrum to a non Information Technology domain it just doesn’t make sense to call team members Developers.

Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team  creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.

I am not sure how I feel about this one. Basically it is saying the team is never committing to anything. From a customer expectations perspective try and sell that one. And yet, things do crop up that means delivery isn’t to expectations. For me I bring this back to a stable Sprint velocity – sure it won’t be exactly the same from Sprint to Sprint but it should be somewhere in the ballpark to make a commitment.

Scrum does not mandate a burn down chart to monitor progress. Scrum requires only that: Remaining work for a Sprint is summed and known on a daily basis; Trending toward completing the work of the Sprint is maintained throughout the Sprint.

Okay so a mandatory activity is now an optional activity, which is nice because this is one of those activities that I felt added little value and preferred tracking as a burn up of each sprint’s velocity. I know that the point of this is to give a definitive metric regarding where delivery is against expectations within the sprint but really it is a simple feel that you can get looking at the cards visually on the board against flow. You don’t need a chart for this when you can visually see it in front of you and ask the questions based on that.

Release Planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself.

OMG. Seriously? Deep breath…. seriously? I recall how I cringed in CSM training when Jeff talked about the backlog and never explained how on a greenfield project it magically came into existence. To get a well formed backlog into place is an art form. So the above statement isn’t saying it is not important, just that it isn’t important enough to be a rule officially part of Scrum; so sad.

The Sprint Backlog is the Product Backlog items selected for the Sprint, plus a plan for delivering them. There is no longer a required concept of “Sprint Backlog items” although that technique can make a great plan. A self-organizing Development Team always has a plan.

Err okay. I think the test underlying this change may have been flawed. They way it is described as a test is confusing and misleading (what are those ‘to do’ items – stories? tasks?). This decision is probably what has resulted in the removal of a sprint commitment. No sprint backlog means no commitment. Let’s say you have 53 stories in the backlog – that’s your product backlog. The team plans to deliver the first twelve stories. That twelve is then your sprint backlog; there isn’t any magic or trickery behind it; it seems bloody simple. It almost seems like this is being done to soften the ‘no changes are made that would affect the Sprint goal’ rule.

The Product Backlog is “ordered”, instead of “prioritised” providing flexibility to the Product Owner to optimize value in his or her unique circumstances.

I had to look up the detail behind this one. It reads quite well and you can almost be convinced. And then you take into account some of the more recent graphs coming out of Alistair Cockburn (sorry I tried to find a cite, but the structure of the site is a mess) showing that at the start of the project, whilst you don’t have the building’s framework setup you need to prioritise in accordance with risk rather than value, but the curve changes as some of that risk is mitigated and there is a point where value trumps. The reality is likely that ordering a backlog will take the risk vs value aspects into account and order in accordance with that. So, is the change because of the understanding of this graph or is this change because value isn’t always trumping and so they wanted to create a new paradigm to address it? I guess I shouldn’t care as long as there is an ordered backlog and it is ordered with a balance of risk and value in mind.

Lastly /goodbyewave to “Ham and Eggs” restaurant.