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
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
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:
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.
This post has been moved to my company blog at Growing Agile – you can read it here:
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.
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.
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
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
I recently stumbled across this in my blog drafts folder, and thought it was about time to finish it, since we are contemplating a new event this year.
As one of the organisers of the first South Africa Scrum Gathering in September 2010, I decided to blog about the experience. Hopefully fellow User Groups around the world who are considering a Gathering can learn from this. Read more