Impediments - your part in their downfall

Hey Scrum Masters,

I wanted to write to you concerning the issue of Impediments and your part in their downfall.

Every project has impediments. There are two types – the known and the unknown. The more known, the more protected you are against slippages and delays in productivity.

Difference between Impediment and Planned delay.

This is all borne out in Sprint Planning. Let’s use the following example.

QA Tester is testing STORY #A

And it will be ready to test by Thursday.

Today is Monday. So their TESTING STORY #A task will sit in Not Started because it was always planned for the sprint to be tested on Thursday.

However, come Thursday, if the code is not ready to be tested then this is an Impediment. It’s only an impediment when something that wasn’t planned or catered for in the Sprint HITS the sprint.

So what should Scrum Masters do regarding Impediments when they hit?

Call them out.

Sprints are short bursts of development – straight line 100 metre dashes with no need for meetings (aside from standups) and are supposed to go without a hitch. You need to be honest and unflinching about impediments and call them out as soon as they are visible. Anything that will affect the smooth running of the sprint is an impediment. Call it out – encourage and support the team on calling out impediments wherever they may occur –

Various impediment types (there are loads more)

• ·         One of the team is sick
• ·         An external department has screwed with the testing environment
• ·         Estimates for one task weren’t accurate enough which caused a knock-on delay with another task.
• ·         The Leadership team turn up and want everyone at a cake ceremony for half of the day…
• ·         A broken keyboard for one of the developers
• ·         Etc etc

The most important thing to remember when it comes to calling out impediments is that they are not BLACK MARKS seen as negatively scoring the team’s performance. Think of them more as “RED ALERTS telling you that outside invaders are trying to bomb your starship”. [Work with me on the analogy]

Don’t wait for the Red Alerts to sound; go OUT THERE and actively look for Impediments before they become impediments.

So you’ve called them out – now work with the team to remove them.

Your job as Scrum Master is to try and do everything to assist with removing this blockage. When an Impediment is raised you should actively talk about it during standup and ensure sufficient discussion is centred around each impediment. If the team organize themselves in a way to handle impediments then “GREAT” but ensure that their handling doesn’t impact any other higher priority work during the sprint, else you are “robbing Peter to feed Paul”.

Take the examples above – some you can remove some you can’t…This is my reaction to each of these…

·         One of the team is sick – OK you can’t cure them, but does anyone have any time in the sprint to pick up the slack? Has the line manager received an estimate for how long the ill person is expected to be out of the office?

·         An external department has screwed with the testing environment – does this happen often? If it does then factor it into your sprint planning and don’t rely on it as part of your sprint commitment. If it’s unexpected, then Call it Out and proceed to a discussion concerning reducing the scope of your Sprint. I’d be extra diligent and talk to the external departments involved before the next sprint and remind them of my reliance on the environment and the consequences to our progress if delays occur. I’d also doubly ensure that I’ve managed our stakeholder’s expectations.

Meanwhile, if this keeps happening you should be surfacing the impediment up the chain to someone important enough to do something about it; a key part in persuading that person would be to show them the amount of work descoped each sprint as a result.

·         Estimates for one task weren’t accurate enough which caused a knock-on delay with another task. – Discuss this at retrospective and look to use estimation accuracy as a metric to gauge estimates in future sprints. Also, if a delay has occurred to another task you should be questioning whether lower priority tasks should be descoped from the sprint.

·         The Leadership team turn up and want everyone at a cake ceremony for half of the day… Encourage you team to attend and enjoy and descope accordingly….but don’t shy away from communicating the reasons why certain User Stories were descoped. If you knew they were arriving then factor the ceremony into the sprint and reduce the number of manpower time available to reflect the time required for the ceremony.

·         A broken keyboard for one of the developers… Try and secure a replacement right away from IT. Failing that, look around the office for a keyboard that isn’t being used (leave a post-it note with an IOU). Failing that, go out and buy one and expense it.

·         Etc etc – The above examples serve to highlight that impediments come in all shapes and sizes and there are no rules when it comes to removing them.

So these impediments have caused a delay to our sprint? Now what? C’mon!! Descope Descope Descope. Remove all of the lower priority items from a sprint until you are relatively certain that the remainder of the tasks can be completed within the sprint deadline. It’s at this stage that Agile discipline is important. Don’t work around impediments by working longer hours or cutting corners in quality to finish everything on time. Remember the GOLDEN RULE: Agile doesn’t solve problems, it only surfaces them… Working around problems doesn’t remove problems.

Think of reforecasting like a GPS / Sat Nav guide in your car: As soon as you make a wrong turn or an unexpected turn, the guide reforecasts the ETA accordingly. Considering the end point of the sprint will always be fixed, and we don’t want a reduction in quality, then the only thing changeable is scope.

But most importantly…..Learn from all of these impediments. Utilize the retrospective meeting to help the team evolve and learn from all of the stoppages and try and agree some practices that will mitigate against repeat impediments for next time. We never ask for perfect in Scrum, we just ask that you continually improve iteration after iteration.

Thanks for reading, and don’t forget …Impediments aren’t just for Scrum Masters to solve. Everyone can join the fight.

Why most Scrum Masters suck

In my experience, most Scrum Masters are usually:

• Ex-Prince 2 / ex-Waterfall / ex-Dark Side
• Ex-developers who gravitated via Darwin to be a Scrum Master due to having a greater level of social etiquette
• (There's no polite way to say this) Massive wimps

In my opinion, this is what Scrum Masters SHOULD be:

• A people-person first and foremost
• Drenched in emotional intelligence and empathy
• Able to divorce themselves from technical detail
• Thick-skinned
• Willing to stand for the courage of their convictions when everyone around them loses their rationale.

And yet most Scrum Masters are terrible. 

Yep, you heard me right. They suck. 

Why? Because they lack the necessary character traits (shown above) that enable them to be effective in the first place. I know this because I’ve interviewed around two hundred candidates in the last couple of years – and around five or six of these two hundred I’d hire (recruiters hate me).

As a Scrum Master, I work within the Tech department and yet I always tell people that 90% of my job is People orientated and non-tangible. My job tends to do one of two things at all times:

1)     Encourage good development behaviours (from all sides of the Project cycle)

2)     Erect and maintain framework Boundaries.

The two points above are all people related and nothing to do with Tech; they just happen to sit within a Tech industry. Because Techies aren’t great socially it’s doubly important that your Scrum Master is a big personality. More, I’d say you can tell everything about your delivery team and project framework just by interviewing the Scrum Master for thirty minutes. I’ll talk about this at some other point.

You’d be better off converting your confident / big personality team member into a Scrum Master as opposed to converting your Scrum Master into a confident / big personality person. It’s much easier and fifty times more effective (in my experience) to do it this way and yet the opposite is always attempted by most tech teams. This is nuts. Scrum is easy to learn – but it takes the right person to deliver it. Most places aren’t Agile – they just think they are – it’s not the Devs fault and it’s not the product guys fault.

The buck stops with the Scrum Master; this is why they are so important and this is why most of them suck.

What Size Are You? Experimenting with T-shirt sizes in Story estimation

There’s a lot of negative energy surrounding story estimates in most Agile organisations.

Developers tend to fear the process of estimating their work more so than other Agile elements that should in theory be much scarier – such as sacred deadlines or standing up in front of their peers every morning.

When I joined Mind Candy, I noticed that there was too much unnecessary noise focused on estimates – in particular story points.

Estimates are *supposed* to give the product owner / producer a broad steer towards the size of the work required; this additional context allows a firmer sense of priority in terms of product direction.

Unfortunately, estimates are too often treated as contractual obligations that serve to be an imaginary stick hovering mentally over developers’ heads. As a result, you find sprint teams needlessly getting their knickers-in-a-twist. The problem with using days or hours as a unit for estimating tasks is that these units mean the same for everyone and are comparable.

Ben estimates 2 days for a task – Jon estimates the same task at 1 day. Without context, this tells you that Jon is twice as good/quick as Ben. But it doesn’t give the whole story. Ben might have lots of meetings whereas Jon might have a clear run at his desk for a day. Ben might be a junior. Whatever the reasons, time as an estimate metric is misleading.

Story points, as an Agile artifact, was supposed to counter this. You’d estimate a story and assign a numerical value to it – and this number meant nothing other than a relative value to the other stories. For example:

STORY A = Estimate is 2
STORY B = Estimate is 10
STORY C = Estimate is 2
STORY D = Estimate is 100

The above set of estimates are deliberately meaningless – they only serve to indicate the size of a story when compared to the other stories. We can see that Story D is massive – about ten times the size of Story B. We can also see that Stories A and C are roughly the same amount of work.

However, story points prove difficult when you are dealing with cross-discipline teams. You are adding two estimates together that don’t share the same value system.

Let’s say a story requires some Front End and Back End and Design work
Front End estimate = 2
Back End estimate = 5
Design estimate = 4

You’d add the estimates together and come up with TOTAL = 11. However, you are essentially adding 2 apples to 5 oranges to 4 pears. They are different metrics because the Design team have only estimated 4 compared to other Design tasks.

Recently, we’ve been experimenting at Mind Candy with throwing out numerical values in the Estimate process and replacing them with T-shirt sizes.

Essentially, sprint members are allowed to give a story estimate in one of five sizes:

SMALL
MEDIUM
LARGE
EXTRA LARGE
TENT

How do you measure progress? Well, we’ve trialled drawing a T-shirt on the white-board that corresponds to each story – and when some progress is made – the team member merely colours in a part of the T-shirt. When complete – we draw a smiley face on the T-shirt.

We’re seeing how this goes – it’s very indicative and visual and the teams are responding well to it. We’ve thrown out the burndown chart and just using the whiteboard as a quick visual guide to how coloured in the T-shirts are.

Most importantly, the sprint teams are no longer getting their knickers-in-a-twist.

Curse Of The (Oxy)Morons: Agile Within A Prince2 Framework

After reading the brilliantly inspired Half Arsed Agile Manifesto I was reminded of a recent phenomenon that has cropped up on CVs throughout the land.


"Adept at managing projects using Agile within a Prince2 Framework" - my first reaction is ha ha ha REJECT. Once I've reached the hundredth CV that contains this absurd claim however, it occurs to me that this is more widespread than I had feared.


Impulses tell me that Agile and Prince2 together in one sentence is like asking Christians and Atheists to co-write the Wikipedia entry on Evolution and yet I've had serious discussions with deadly serious individuals in serious organisations who are insulted when I suggest the contradictions at play. Organisations have hounded me to come in and interview for them; they proudly claim they have "perfected" Agile within a Prince2 framework and then we argue back and forth and suddenly they don't want me to work with them anymore. This doesn't mean that I'm some rigid Agile evangelist - but it does mean that I don't want to work for an organisation that fails to spot the inherent differences between the two frameworks. It also means that organisations don't want you if you fail to pay lip service to their lunacy.


Agile embraces change. It intuitively knows that projects will make mistakes and will require alterations throughout their life cycle. It doesn't erect boundaries and procedures to restrict this. It pre-empts change and hones it. It accepts it as a part of life. Prince2 safeguards against change rigidly and tries to deliver to the granular level every item as promised in the Project Initiation Document. When a change is requested, a committee meeting is held to assess the implications. The only thing they seem to share in common is the joint desire to "deliver a project".


What "Agile within a Prince2 framework" tells me within an organisational framework is somewhere that likes rhetoric such as "control" and "safeguard" at a Programme Management level but wants to appear to be cavalier and flair-driven at development level; in essence, it wants to have its cake and eat it. A project is never "finished" in Agile unless the stakeholder declares so - backlogs can always take extra submissions and work can always continue. You can't plan Agile projects using a Gantt chart if you accept that things will change as you go along. All you can promise is what you will attempt to deliver, on best endeavours, over the next iteration. Using velocity, you can estimate roughly how long the project should take, but only based on the current backlog that you have to work with.


Ultimately, what "Agile within a Prince2 framework" REALLY tells me is:


* An organisation who wants to appear Agile to excite potential investors
* An organisation who wants to appear Agile to tempt talented staff
* An organisation split in two - and both sides headbutting the other across the watercooler
* An organisation who doesn't get Agile or worse, doesn't believe in it but is doing it anyway.


I worry about where the industry is going. I feel like Robert Neville at the end of I Am Legend. The book, not the awful Will Smith film.

Agile Subverts The Archaic Corporate Class System

Poll for reasons as to why certain organisations fail to successfully adopt Agile and you'll be confronted with reflex responses that focus on development practices or zero in on the type of industry trying to "Agile" themselves.


I'm not going to launch into technical reasons why certain organisations struggle with Agile and Scrum. Rather, I'm going to focus on the ceremonial aspects of Scrum and why it poses a threat to the tacit Corporate Class System that exists in most mid-to-large scale corporate entities which in turn explains emotively why Agile isn't jumped upon like the latest Groupon Voucher. 


Waterfall
Compare the difference between how requirements are captured for a project between Waterfall and Scrum. Waterfall appeases all of the grandiose notions of a bygone Skyscraper age of big business and protects the status quo. You have some Bert Cooper ("Mad Men") character in his carpet office reading a hefty Project Proposal document that has been toiled over by minions he has probably never heard of. Too important to read the full document - Bert will skip to the part at the end of the 200 page treekiller whereby he will be promised how much the project will cost and how much the project will earn him. He will also be advised as to when the project will be completed.


The minions, fuelled with an increase in self-worth due to playing a part in this document, feel integral to the machinations of the big Corporate power wheel and treat the proposal as a sacred artefact; they'll argue amongst themselves as to wordings / sections and seek appropriate cross-departmental sign-off for every detail, to the most granular level. After all, Bert is reading this and signing if off. Also, stealth stakeholders claiming to have a vested interest in the project all jump out of the woodwork - demanding to read the proposal and red pen it before it reaches Bert. This document diminishes their hierarchical importance within the organisation if they don't have input into its content.


Bert might have a committee of Yes Men underneath him (The VP Berts) who will advise him accordingly, but ultimately he signs the cheques and therefore signs the Project Proposal - thus greenlighting it. His underlings will be sent turgid and regular reports as to the progress of the project whilst Bert plays golf in his office. They will also meet to frigidly protect the project from any flaky changes to the project. These changes are too trivial to annoy Bert with; underlings dream themselves of being Bert one day and do not want to deal with such small fry matters when they are in charge - so why would Bert?


Eventually the project drifts or the costs spirals or the requirements change or the dynamics of the industry itself changes...but it's too late to change / save the project now because look at the vast manpower and effort invested. The Software Engineers are probably to blame as the requirements were LOCKED DOWN in the project proposal and everyone signed it off then and had a chance to voice objections, so what's the difficulty now? And why the hell are so many changes required for this project? Why wasn't this thought of at the beginning? "That Project Proposal was a CONTRACT Goddamnit!"


The original sponsor of the project has left by now anyway as it was proposed X months ago and his/her replacement doesn't want to be politically associated with this failure. Bert and his VP Berts have already forgotten why the project was started in the first place and what the intended benefit was. No one can remember exactly, because the "fall guy" has already left. One thing is guaranteed, no one is going to read that two hundred page document again because they are "too busy."


By now, more projects have been commissioned anyway and Bert, flexing his muscle, removes the Technical Lead on the project due to the their incompetence of this failed delivery. The Project Managers, blinking out traffic light statuses throughout this failure, are contract only anyway and they take a job elsewhere with a higher daily rate. Working on one of Bert's projects looks good in their portfolio. Bert's rivals don't want to be outdone and so these Project Managers are snapped up after a twenty minute interview.


The next project proposal is four hundred pages long because no one wants to be the next fall guy and therefore a further level of detail and sign-off is required. Everyone is weary of Bert's trigger-happiness. 


Scrum
Transplant this set of characters to Scrum and you have a different story. Rather than a project proposal being scrutinised, the product backlog is stored in a central location and transparently available for everyone to see. No one but the most vested stakeholder contributes any requirements or user stories. If it's freely open for everyone to contribute then it cannot be important, surely?


One of the VP Berts is begrudgingly "demoted" / elected as product owner. They'll chat to Bert when he is in the country to work out what his priorities are for quick value and incremental release. Bert will be frustrated that he has a loose spreadsheet of "stories" serving as his requirements document as opposed to an important looking treekiller document and continually wants to know when the project will be finished so he can sell it to customers.


The VP Bert Product Owner resents having to "stand up" at a meeting with the lowly developers on a daily basis (don't get him started on the clapping for when a task is done! Business and Money are SERIOUS) and doesn't like having to wait till the end of this hippy new-age ceremony before he can ask questions to the developers. Also, why the casual office attire? What's wrong with chairs at a meeting? Furthermore, he cannot attend every standup due to "more important meetings" and so needs the developers to inform him when a "meaty" standup is coming so he can be sure to attend. But he needs notice.


Consequently, and to VP Bert Product Owner's dismay, this Project is like a needy girlfriend constantly requiring feedback and sampling. Every few weeks, the VP Bert Product Owner has to make ACTUAL CHOICES that shape and guide the product. Furthermore, if he is too busy to provide the feedback, the developers SIT AROUND AND DO NOTHING! 


"Surely someone was paid to shape the requirements at some PMO level when the original idea was conceived? With no weighty documentation and contractual sign-off process, suddenly the development cycle seems flaky and lacking structure. Also, you're telling me that in order to understand how the project is going I have to tell Bert to 'turn up to standups' rather than send him some metric-guided report on a frequent basis? Now I see from the retrospective that those lowly developers are blaming my lack of involvement in the product as to why it is slipping! I told them I had board meetings. Maybe we should regain control using waterfall - I'm too important  busy for this"