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…

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.

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:

Fixing Bugs in Scrum

The following post is inspired by an email I sent to our teams recently due to some confusion about when to fix bugs in Scrum.

It generated 2 responses:

1) Complete support from some (senior developer, architect and CTO) and

2) Debate and disagreement from others (Product Owners)

I will leave it to you to decide what you think. Keen to hear comments from either side. Warning: no one has swayed me in the other direction yet!

The email below….

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.

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.

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.

Scrum Puzzle #1

It seems it has been a very long time since I did a blog post. I have good reasons. Since my last blog post I have:

• Attended my first Agile Alliance Conference: Agile 2011
• Presented 2 talks at Agile 2011
• Had my first official paper published as part of the Agile 2011 conference proceedings
• Helped Organise the second South African Scrum Gathering in Cape Town and Johannesburg
• Co-trained CSM/CSPO courses in 3 continents
• Submitted my CST application (waiting anxiously for feedback…)

In the last 3 months I have learned a lot of new stuff about Scrum and Agile. I have also been faced with the reality that many people in South Africa have not had the opportunities I have had to be exposed to all these ideas and thinking. I see a lot of people doing Scrum (or at least trying) and not understanding the reasons they do the things they do. This brings me to my latest idea: Scrum Puzzles. One of the best ways to learn is to apply your knowledge to concrete examples. I will create some scenarios which I commonly see in teams and post them. I’ll let you mull over them for a week. You can post your solutions and reasoning in the comments. After a week I will post my solution focusing mostly on the why. I don’t claim to be the expert or that my solution will be the only one, but I do want to expose the reasoning behind why that would be the approach I select. Not sure how many puzzles I can come up with, and how long I’ll continue this for, but if you like the idea, leave a comment so I am encouraged to continue 🙂

And so, Scrum Puzzle Number 1: