Skip to content

Train your teams in Scrum

Often companies get someone to train their team when they adopt Scrum, but a few months or years later, new staff have joined, others have left, and very few people remain who have received formal Scrum training. As a result companies suffer because people understand the mechanics of Scrum but not the principles and values behind it. This prevents them from effectively inspecting and adapting.

It’s not always feasible to get an external trainer to train your teams on an ongoing basis. I have a solution! Train them yourself :) Before you tell me you can’t, take a look at this book: Growing Agile: A Coach’s Guide to Training Scrum. It contains everything you need to run a Scrum training session from 1 hour to 2 days. Workbooks, slides, simulation, the works!

Scrum Masters in Black

I’ve been asked a lot about how to recruit good Scrum Masters. There is a shortage of experienced  Scrum Masters in South Africa and as a result many companies are looking to hire people without experience but who are a good fit for the role. The tricky part is identifying what those people look like. Then I rewatched Men in Black… Read more

Test Plans in Agile

Talking to a test manager recently he mentioned that he often gets asked, “When do you do test plans in agile, if ever”. Since it is a common question I thought a blog post would be useful.

First let me clear up a common misconception. Agile does not mean NO documentation, the agile manifesto says “while there is value in the items on the right, we value the items on the left more.” So documentation is valuable, but working software is more valuable. But you also have to ask what goal the documentation is serving. Read more

Scrum Puzzle #5

Forgive me Scrum Puzzlers for taking so long to post a new puzzle. I’ve been busy with a side project which will very soon become a lot more than a side project. In exactly 2 weeks I will be self employed! I have started Growing Agile with my good friend and fellow agile enthusiast Sam Laing. We are looking forward to a whole new adventure next year, which I imagine will inspire quite a few Scrum puzzles. Anyway onto my solution to puzzle #4:

Read more

Scrum Puzzle #4

Most people seemed to get the concept that the team own the task board in the responses to Scrum Puzzle #3 but a few wanted to be helpful to management by allowing for some consistency or a key to make the board more understandable.

My approach is a much less forgiving. I think that the task board is only there for the team, and does not need to communicate anything to management or anyone else. There are other mechanisms in Scrum for management to know how the team is progressing and how they can help. The problem with giving in to this request, is that it opens the door for abuse, even from the most well intentioned managers.

Read more

How to Calculate Capitalisation Costs in Scrum without Timesheets

This post has been moved to my company blog at Growing Agile – you can read it here:

http://growingagile.co.za/2012/10/how-to-calculate-capitalisation-costs-in-scrum-without-timesheets/

Scrum Puzzle #3

Well looks like everyone got that changing the sprint length is a bad idea. Here are the key learning points for me in Scrum Puzzle #2:

1. Velocity is not linear, all it tells you is how many points a team usually complete in a fix period. As soon as you change that period you no longer have data to make any prediction. You cannot assume that if a team do 30 points in 2 weeks, that they can do 15 points in 1 week. The team may for example do all the coding in the first week and all the testing in the second. So after one week they would deliver 0 because nothing is tested. I’m not saying this is how all teams work, or even how teams should work, all I’m saying is that knowing only the velocity for a 2 week sprint you cannot know anything about where the team will be after 1 week.

Read more

Scrum Puzzle #2

Wow, I’m overwhelmed by the great response to the first Scrum Puzzle. I loved some of your responses. I especially liked Matthew’s example of moving the boulders. That’s a great way to teach the principle.

Here is my solution:

There are 2 key learning points in this puzzle. Number one is the value of small batch sizes. There are numerous exercises to demonstrate this. Check out the penny game as an example. Most of you got that the stories really need to be broken down smaller. This is often difficult for new teams, but there are techniques you can use to do this. See my previous post on breaking down user stories. If we don’t have small batch sizes, then it takes longer to complete work, progress is less transparent, feedback cycles are longer. All of these are things we are trying to avoid in Scrum, so any solution which makes the batch size larger is generally not a good idea.

Read more

We do Agile, but not Scrum

I often hear people saw “we follow the Agile Methodology”, or “we don’t do Scrum but we do Agile”. As if it is a thing I should know about. If you have done this then please note, there is no such thing as the Agile Methodology. My husband describes it best. Agile is an abstract super class. It has no specific instantiation. For those of you who aren’t OO geeks, that means Agile is just a word which groups a number of approaches together, it is not a methodology in itself. Read more

Training Exercise: Scrum Simulation

Recently while co-training a CSM (Certified ScrumMaster) class with Peter Hundermark we found ourselves with a polarised class of people who had only just heard about Scrum and people who had been practicing for months or years . Inspecting and adapting as we do, Peter and I decided to split the class. I invented a new exercise during the lunch break for the beginners, to help them grasp exactly what all the Scrum meetings are about, how they fit together and how the artefacts are used. It turned out to be a very successful exercise for teaching the concepts to newbies, and took about 90 minutes. I have given timings below of what I would time box each section to in future, being a new exercise I didn’t timebox well, as I had no idea how long it would take, and so we ran out of time near the end. Read more

Follow

Get every new post delivered to your Inbox.

Join 47 other followers