Agile…what are you liiikkee??

You need to say the title of this blog like someone in Eastenders: “What are you liiiiike, ey, Agile? What are you liiike?”.

Alright, alriiiiight, have a seat on your bottle and glass and and feast your mince pies on this little analogy I have for you.
Over the Easter weekend I went down to Anglesey with my boyfriend and his entire family (it was my first time I’d spent a long time with them all…I was terrified…so many things could have gone wrong…what if I broke their favourite plant pot or got sugar in the wrong coffee?  What if I blurt out some nervous, inappropriate drivel and make them hate me for ever?? It was a big deal!  However, I was very proud of myself for not making a complete butt of myself, so, yey, go me…Anyway, I digress…).
So part of this little holiday involved me thinking it would be nice to make breakfast for everyone on Easter Saturday…I offered to make scrambled eggs on toast.  I’m good at scrambled eggs and people like my scrambled eggs.  I think perhaps because I load them up with butter it goes all like, nom nom nom. It was a safe bet.  Not risky like poached eggs or even fried. Scrambled was goooood. I’m good at toast too.  Toast is also goooood. So, off I went and set to work.  I’d broken the eggs and got working them in the pan and after about 10 minutes of me working, his mum and niece (7 years old), come in and ask me “will you need toast?” “Yes” I say, as I’m thinking “OH NO I FORGOT ABOUT THE BLOODY TOAST! HOW CAN YOU HAVE SCRAMBLED EGGS ON TOAST WITHOUT TOAST??!” Thoughts of how to juggle copious toasting and buttering with stirring scrambled eggs, or worse, getting the synchronisation of cooking eggs and toasting/buttering aligned to avoid cold breakfast elements caused anxiety levels to rise and dominated my thoughts for a few moments as I processed how the complexity of this ordinarily simple task had just sky rocketed!  I’m just not used to making scrambled eggs at this scale.  I’m obviously inexperienced!
Then, something interesting happened.  I turned around and there was hopefully-one-day-mother-in-law toasting, with hopefully-one-day-neice-in-law-or-whatever-the-name-is buttering.  Huzzahhhhh! Result!  We’d self-organised like a proper little Lean team and and made a nifty little conveyor belt of toasting and buttering, then soon after, adding scrummy scrambled egg.  Breakfast is served! High fives all round.  The other interesting thing is that we had all stuck to doing one thing at a time and didn’t get distracted from our tasks.  We had a grown-up working on the hot hob and another on the hot toaster and a child buttering the toast; we used the skills we had in the group to work together to complete the tasks involved to get the job done, just as a Scrum team should.  And when it was done, we had a delicious breakfast!  Apart from the fact I didn’t cook enough and had to start again…Oh well.  Next time I will know that serving 8 people scrambled eggs definitely requires a minimum of 16 medium sized eggs…

The new A-Bomb: The ‘Agile’ Bomb: dropped by Agile Agent Bull

Beware of Agile Agent Bull.  He is armed with little knowledge and is dangerous.  He presents a great risk to your Company and can cost you thousands…

Be sure you recognise an Agile Agent Bull as soon as you encounter him.  He can take many guises, and may take a stealthy attack by using trusted charm offensives, like supplying your teams with endless donuts and squishy brownies to keep everyone sweet and cover up his incompetence. He may strut about with a cool air of confidence in an attempt to deceive the team into believing he is experienced.   Do not be fooled, these are rehearsed tactics.  BE STRONG! You must resist.  The cost of not outing Agile Agent Bull early on is much more expensive than a whole year’s supply of Krispy Kreme.

What can happen if you have an Agile Agent Bull in your organisation?  Well the impact can be literally nuclear because the aftermath of an Agile A-bomb can take a company months, even years to recover and pluck up the courage to take on another ScrumMaster.  Agile Agent Bull is a liability and we must engage our Intelligent Teams (IT) to seek out the enemy before the A-Bomb is dropped.

What’s Agile Agent Bull’s profile?

1)      He can talk the talk, but can’t walk the walk. Bull by name, Bull by nature.  Agile Agent Bull tells everyone he is a Certified ScrumMaster, and that he knows about Scrum and Agile.  Yet, when the team ask what they should do in terms of process in a certain situation, he doesn’t have a clue, or worse, gives some terrible, inappropriate direction. A direction that could cost the team dearly. He doesn’t know what he is doing. A ScrumMaster is an expert and knows what he (or she!) is talking about.  They can be asked anything and will have the knowledge to know how to deal with the question at hand.

2)      He can’t make good decisions.  The team need a strong ScrumMaster to turn to when they don’t know what to do in terms of the Scrum process.  As an expert, the ScrumMaster must be able to evaluate the situation, and know how to use Scrum to help the team get through.  He makes great decisions based on what is best for the team.

3)      He shies away from leadership.  Agile Agent Bull is weak.  He doesn’t lead the team and leaves them to their own devices.  He doesn’t tackle threats to the team such as a rebellious little scamp on the team or identify sloppy self-organisation.  He doesn’t have the tough conversations with managers.  He is a wet blanket.

4)      He is a bad facilitator.  He lacks the ability to add value to Scrum Ceremonies.   He lets the stand-up go on for half an hour and allows other meetings to constantly drift off-topic, making long meetings longer.  He does not hold quality retrospectives, impacting the team’s ability to continually improve as a learning team.

5)      He lacks discipline.  He spends his time avoiding matters rather than thinking of ways to tackle them.  He does not protect the team and doesn’t champion Agile to change the culture of the organisation towards its approaches.

Be warned!  Agile Agent Bull is out there.  Be sure to recognise him and diffuse his ticking A-Bomb.

The Power is in the Points

How hard is it to estimate how long something will take? The answer is very hard!  But why is this?  Well, there are a few key factors. Mainly, the problem with time is that in a short space of it anything can happen.  It is unpredictable. Estimating in time is risky.  Secondly, people aren’t actually very good at estimating how long things will take.  How many times have we heard “how long will that take?”, only to hear the reply “how long is a piece of string?”.  Sometimes tasks are so massive, we just cannot begin to get our heads around it.   People are, however, much better at measuring how complex a task is.

Let me explain…

If someone pointed at a messed up Rubik’s cube and asked me “Is that complex to solve?”.  Personally, I am really not very good at those things, so I’d be like “Err, YAH!”.  I don’t need to know much to know it is complex.   Complex doesn’t mean ‘hard’.  It’s not exactly ‘hard’, I mean it’s just moving some squares around, but its complex because it takes a lot of thought, and there are so many combinations to process as I move the pieces.

Now, if the same person then asked me “How long will it take you to solve that Rubik’s cube?” I would have absolutely no idea.

This is why in Scrum we measure complexity of work in story points as opposed to in time.  Once the team understands the concepts around points and planning poker, they get pretty good at measuring complexity.  It turns out it is a much more accurate measure of forecasting estimates than time alone ever will be, and this makes story points powerful.

Education, education, education!

If you are a ScrumMaster or Agile Coach working with a new Scrum team(s), it goes without saying that it is really important to spend the majority of your time at the start of your deployment investing in training the team.  Obviously by ‘The Team’, I’m not just talking about Dev/Test, I’m talking about Product Owners too.  If you don’t do this, you will end up with a confused and frustrated team because they will not know the Scrum process OR what is expected of them as part of a collaborative self-organising team.  You need to be tenacious in delivering a clear, consistent message to your team about what Scrum is about, both as a development framework, and as a culture, and be constantly checking on their development as a learning team.

If you know your stuff, it is much easier to start training your team than you think because there are some fantastic online resources to help you deliver a really great session.  I am a big fan of the CollabNet Agile e-learning training series ( ), and at the moment, it is a major element of my training session’s agenda.  Speaking of which, here is the agenda I use for Scrum Introductory training:

  • Presentation (you should put a few slides together for this):
    • What is Agile, and why did it come about?
    • Definition of ‘Agile’
    • What is The Waterfall Model and why is Agile different?
    • The Agile Manifesto
    • Other Agile frameworks that are around, e.g. not just Scrum, but Kanban, XP, DSDM etc.

I then use the entire CollabNet interactive training series to train the team.  I use the Quizzes and questions provided in the series to ask the room what they think the answer is.  I also take the time to explain why an answer they have chosen is NOT right, and why another answer IS.  This is a really important part of their learning, and means they will have a better chance at understanding the logic to Agile rather than just learning parrot-fashion, but not really getting ‘why’. The session takes around 2.5-3 hours, depending on questions.

If I have Product Owners to train, I run the above session in the morning, and then hold an afternoon session with the following agenda:

  • What is a PO’s role and responsibilities?
  • What makes a great PO?
  • How to be a PO at <the company you are in>
  • Requirements: What is the difference between a granular User Story and sn Epic User Story?
  • Introduction to a real life Product Backlog
  • How to maintain a Product Backlog, including prioritisation of User Stories
  • How to write excellent User Stories and Acceptance Criteria with an exercise. (The group will be split into pairs/small teams and will write  User Stories and Acceptance Criteria for a real project, followed by a discussion)
  • How to Prepare the Product Backlog properly for a Backlog Refinement Meeting or Sprint Planning
  • Q&A

If you do this, you will get everyone in the Scrum teams off to a great start.  However, it is also really important to keep their knowledge up.  I hold fairly regular ‘open desk’ sessions, where I block out some time and invite people to come and talk to me and ask me anything about Agile.

Finally, teach (theory), demonstrate (real-life application), repeat.  I cannot stress enough the importance of reiterating a constant and consistent message. At the Scrum Board, in the stand up, at the retrospective, one on one, in training session, all the time.  Being consistent with your approach allows familiarity and the team encourage the team to trust that you are serious about what you say and you won’t also move the goal posts for whatever reason.

Story Time! Yey!

Do we like story time? Of course we do! Story time is great! We also like this name far more than ‘Backlog Grooming’ which just sounds wrong…

So what is so great about Story Time? Well, are you sitting comfortably? Then I will begin…

Once upon a time there was a meeting called the Sprint Planning Meeting and that was held at the beginning of every sprint in a faraway place (it seems far away to a developer if it is not at their desk…) in a land called ‘Meeting Room’ and it took a lonnng lonnng time. The Sprint Planning Meeting had a very looonnnng time box (8 hours for a month sprint, proportionately less for shorter sprints) and it made the Scrum teams very very tired and not want to go anymore because it was soooo lonnngggg…

Ok, so you get the picture, Sprint Planning can be boring and take ages…So, as a ScrumMaster, what can you do about it and what is Story Time anyway?!

Story Time is also known as the Backlog Refinement Meeting, or Story Elaboration Meeting and it should be scheduled to occur a day or so before Sprint Planning. The point of the meeting is to get the dev/test the team together with the Product Owner (PO) to go through the top priority backlog items that are candidates for the next sprint. The MAIN PURPOSE of this meeting for me is to make sure the whole team understand the requirements of the product Backlog Item (PBI) in question, and provide a gut feeling as to whether it is possible to complete it in the sprint. I know, right?! Gut feelings as opposed to knowing for sure? This sounds like fiction! Especially to all you command-and-control traditional Project Managers out there (naw, bless….sucks to be you).

It is important to stress that the team do not commit to anything in the Story Time meeting; they are just assessing what could be possible to get done in the next sprint. There are two reasons why I find this meeting is great: Firstly, because by the end of the meeting, the PO and the team are on the same page when it comes to the requirements for the top priority backlog items, and secondly, it shaves time off your lengthy Sprint Planning Meeting because the team are already familiar with the story and the requirements. For a two-week sprint, I keep Story Time to a two hour time box. This is not too little, not too much, but is just right to keep the team focused and engaged and most importantly, clear on the requirements for the top priority backlog items.

For a great video on Story Time, see Andrea Druckman’s 60 Second Scrum YouTube video:

A really useful sprint planning agenda!

The first sprint planning meeting for a team new to Scrum can be challenging. There is bound to be lots of questions from people, and perhaps uncertainty about what to expect or is expected, especially at the beginning of the meeting. Therefore it is important to deliver the meeting with conviction and confidence, but also get out of it what you need in order to set the team up for a great sprint.

If you are a ScrumMaster about to facilitate a team’s first sprint planning meeting, here is a good agenda to follow to make sure you cover everything in the timebox (Note: I always hold a Backlog Refinement meeting in advance so the team are already familiar with the stories…this really cuts down time needed in Sprint Planning).

1. Write out the agenda on a separate board or flip chart page. Tear it off and stick it to the wall. Tick off items as you go through them. This will help your team stay focused, and know where they are during what can be a long meeting for them.

2. Establish whether there is any leave coming up within the team

  • This will help you plan your capacity. Out of a 7.5 hour working day, I estimate each person to have a capacity of 5 productive hours. If your task’s cumulative estimates end up exceeding your capacity, you can address the impact and even remove stories if necessary.

3. Explain what a sprint planning meeting is and what it is for

  • You should have done some basic scrum training with your teams, but I find ‘setting the scene’ this way gives your team confidence that you know what you are doing and why. It also discourages the team from questioning why they all have to sit through it all in the first place (even if you do but them cookies and donuts)!

4. Explain story points as a measure of complexity, and introduce planning poker

  • Explain very clearly how points is a measure of complexity, NOT a relative measure of time (i.e. 3pts=1day). They need to be clear on this in order to understand the concept of Planning Poker

5. Play planning poker on previous stories using the a consistent scale (e.g. Fibonacci)

  • The team can then refer to these stories as a reference for when they play planning poker on their new stories.
  • Choose a few examples of previous stories the team are very familiar with working on. The examples should include a very easy story e.g. 1 or 2 points, a mid range story of about 8 points and a larger story, perhaps around 20 or 30 points. This way, when the team use the examples as a reference you can help them by asking whether a new story they are trying to estimate is more or less complex than the (X point) example
  • Use the same scale for every sprint planning meeting
  • When the team have found a fitting example, write the story name on a board or flip chart.

6. Discuss the next sprint stories one by one and play planning poker on them
7. Go through the stories and assign tasks

8. Go back to the story points and ask whether the team feel their original estimates are still accurate

9. Commit to sprint goal(s)

  • Write down the sprint goal(s), then read it out. Keep altering the wording until everyone agrees with it (including the Product Owner…very important!) as subtle changes make a difference

The Agenda in a nutshell:

1. Write out the agenda on a separate board or flip chart page. Tear it off and stick it to the wall with blu tack (tick off as you go through them)

2. Establish whether there is any leave coming up within the team

3. Explain what a sprint planning meeting is and what it is for

4. Explain story points as a measure of complexity, and introduce planning poker

5. Play planning poker on previous stories using the a consistent scale (e.g. Fibonacci)

6. Discuss the next sprint stories one by one and play planning poker on them

7. Go through the stories and assign tasks

8. Go back to the story points and ask whether the team feel their original estimates are still accurate

9. Commit to sprint goal(s)

The Scrum/Kanban Killer Kombo

Most projects require input from your infrastructure team, and this one team can be responsible for supporting possibly several on-going projects. How can Scrum Masters and Product Owners (PO’s) make sure this team are doing what is actually the most important thing as opposed to being reactive to whichever project shouts the loudest (especially if your organisation still hasn’t conceded to the fact that Project Managers do not have a role in Scrum)? On the flip side, how do they stay flexible enough to expedite emergency items?

A great combo that I have seen work really well is when the Infra team run off Kanban, and your project teams run off Scrum. When the Project Teams are in Sprint Planning, you should bring in a representative from Infrastructure so that a) they are familiar with the Infra requirement b) they can be notified of a ‘due by’ date that they can integrate into their Kanban backlog ‘stack rank’ and c) because the project’s scrum teams are sprinting, your Infra guys know when the release date, or dates will be, which may be their ultimate ‘due date’. It is really important that Scrum teams are honest with Infra about due dates because it will dictate to a large extent the stack rank of the Infra team’s Product Backlog. Other things that will play a part in the stack rank are technical dependencies, or expertise availability (someone may be on holiday). Other pre-requisites for the Scrum teams is that they are realistic with any due dates that they expect of the Infra team, and don’t put the team under unnecessary pressure to deliver a Product Backlog Item (PBI) in the first week of their sprint when in actual fact it is not really needed until the second (or third, or fourth!). They also need to make stories/requirements clear so that your Infra guys can come up with the best solutions. The Scrum teams should also keep the Infra guys well aware of any change in requirements so that they are not continuing to commit to delivering unnecessary and therefore wasteful items. To help prevent this, the Scrum Masters should attend the Infra stand ups as a chicken and keep an eye on their backlog items. They should listen to the conversations going on in the stand-up (yes, as technical as they may be, stay with it Scrum Masters!) and any concerns should be raised early.

The Kanban limited Work In Progress (WIP) work streams lends itself really well to infrastructure teams, because a lot of the tasks they do will be the same or similar variations of work they have done before. To get full buy in from the whole team, ask THEM what they think the work streams and their limits for each should be (as well as the Definition of Done for each). They can always change it later if it doesn’t work. You are still required to inspect and adapt with Kanban! In the past I have seen a flow similar to the below work really well:

Infrastructure Kanban WIP Work streams

  1. Backlog (always stack-ranked). Contains user stories with defined requirements and acceptance criteria
  2. Analysis. The design and approach is established by whoever picks up the story
  3. Analysis Review: The design and approach is peer reviewed
  4. Development. The code is implemented
  5. Test. Tests are run, bugs raised etc.
  6. Ready for release: If the code is to be released at the end of a Scrum team’s sprint
  7. Done. The Definitions of Done are met and the PBI goes on the ‘Wall of Done for all to admire.

Make sure you have regular retrospectives with the Kanban-ers because like XP, it is fast paced and therefore is very important to address issues and make any changes to avoid conflict, promote best practice and most importantly, prevent burnout.