Feeds:
Posts
Comments

Archive for August, 2011

The sparkling new Scrum Guide

 

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.

Read Full Post »

Bootcamp coaching

Just do it!Six years ago I was in a fitness craze trying to return to pre-baby body shape. I would go to the gym and do a number of classes, lift weights, cardio etc and probably did about 10 hours of gym work a week.

A friend wanted to give Bootcamp a go and despite me already feeling very fit I somewhat reluctantly agreed to go along at least give it a try. Ca-ching from my purse I set off for my tri-week bloody early sessions. These sessions started at 5 am which in itself was a dedicated committment given how much I love sleeping in. But the thing that got me out of my bed to do it, session after session of absolute agony, was because I was paying a lot of money for it; I had a financial investment that I wasn’t going to waste.

Now despite being able to do several cardio workouts at the gym without too much stress I was amazed at how unfit I felt whilst doing those first few sessions. I remember vividly on the first run that I was constantly on the verge of throwing up. I remember thinking how loopy I was one session for being part of a man made car – two people in the front holding a large Koppers log, two in the back doing the same, connected by rope and holding up three tyres whilst jogging – CRAZY!

I did things I never thought I was capable of. For the first time in my life I was able to jog; and not just jog, but being able to do it without a limit.

Why was I able to go beyond bounds of what I thought I would ever be able to do? Two words – my coaches. When I was tired they pushed me. When I wanted to give up they pushed me. When I wanted to take their skinny little throats and squish them for pushing me they pushed me. They weren’t the in your face type of coaches that are stereotypical when you think of bootcamp and associated it with an army training corps. They were supportive whilst never giving you an inch to give up. They encouraged and they cheered you on when you thought you couldn’t take another step.

So how does this relate to Agile coaching? Many people think that Agile coaches should not be evangelists, they should be pragmatic. The ten year Manifesto re-union had the authors wanting to only change the manifesto to say ‘And we really mean it’.

What can we take and apply from Bootcamp coaches?

  • Never let your team give up, even if they want to
  • Have a driving passion for Agile that invigorates all of those around you. This doesn’t mean you have to be a zealot, it means that your passion is contagious.
  • Encourage, encourage, encourage!
  • Celebrate when your teamies obviously are stepping out of their comfort zones and are being successful at applying your lessons
  • Measure success. Measure where you were and where you are now.
  • If all else fails, drive behavioural change fiscally. If a leader, for example, really wants to change something like ‘Stop finger pointing’ then have them commit to put $5 into a team jar each time they exhibit that behaviour and let the team know of this challenge. They will learn quickly to change when it hits the hip pocket.
  • Let converters tell their stories to others. Did this blog just make you want to get fit again?

Read Full Post »

What would 17 peeps do in a Jacuzzi you think?Ten years ago some smart guys got together to find what they had in common despite being to some extent competitors to each other. I like to think that whilst at The Lodge at Snowbird ski resort that they jumped into an extra large jacuzzi and sorted their differences to find their passions that aligned.

At the end of their bubble bath they had reached enlightenment and defined the Agile Manifesto and named themselves the Agile Alliance.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software 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, we value the items on the left more.

I was greatly anticipating hearing where the Agile Alliance group would say as part of their 10th anniversary re-union at Agile 2011 Salt Lake City. Admittedly my information was limited to second person discovery or tweets and I didn’t expect anything dramatic, but some contention or even one person standing up and having the courage to say ‘Hey maybe we could have fixed the wording a little to suit audiences other than software developers’ would have been good.

So for a lack of seventeen people taking the stance that there could be an element of imperfection (or dare I say it taking an iterative focus to constantly refine it) then I am going to give it a crack:

Manifesto for Agile Solution Delivery

We are uncovering better ways of delivering solutions and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working solutions over comprehensive documentation and meetings
Customer and team collaboration over SLAs, KPIs and contract negotiation
Responding to change over following a plan

Constantly reflecting and improving the way we work over following a process without understanding why

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

Why the changes?

  • Agile isn’t just for software development. It’s application has now broadened to include other areas of IT including hardware, services, process improvement and for a large number of people it is being applied outside of IT into other domains. I can appreciate its origins, but some of these origins are in Lean and blending Lean and Agile together has given us a really strong framework.
  • This framework has broadened the practices, techniques and tools that we use to implement Agile. Each month it alters a little and I think that is a great thing. I don’t see Lean broadening itself to take on other approaches. In some way it risks diluting the original purpose of Agile. In some way it can be debated whether this dilution means we are following Agile or something else altogether. For me, it is about bringing the right tools for the problem. I don’t care what it is called, but for the moment let’s stick with Agile being an umbrella term. The new added manifesto item for me is this constant refinement – not just of Agile itself but of how we apply Agile. I know it isn’t worded right, but the concept I am trying to get across is that we are dealing with Complex Systems and thus the only way to improve is through a reflective improvement framework. Alistair Cockburn said it best with his Oath of Non-Allegiance - it’s about finding the best solution for the current situation.
  • Team collaboration is just as important as customer collaboration, but I guess this could be covered off by the Individuals and interactions over processes and tools statement.
  • Only a small portion of the development community have any relationship or reference to a contract, so I expanded it to include SLAs and KPIs/KRAs
  • Change of wording for software -> solutions
  • Change of wording for development -> delivery
  • Addition of something about meetings. All too often I see teams complain about Agile because of the sheer number of meetings with perceived low value. Collaboration is important but not at the risk of reaching consensus perfection. Get your 80% value from the meeting and then shut it down.

Should the Agile Alliance take a step to re-write the Agile Manifesto?

If you are interested in other variants take a parody focus of the Manifesto for Half-Arsed Software Development or Manifesto for Software Craftsmanship.

P.S. Sorry for the delay in a post. Computer failure, followed by a cold, followed by a brief holiday, followed by many podcasts for Agile 2011 are poor excuses but I am using them.

Read Full Post »

Follow

Get every new post delivered to your Inbox.

Join 920 other followers