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:

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.

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.

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.

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.

How To Organise A Scrum Gathering

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.

Training Exercise: Scaling Scrum

It’s been a while since I blogged, but I have a good excuse… I have been working hard co-training CSM (Certified ScrumMaster) and CSPO (Certified Scrum Product Owner) classes with Peter Hundermark. I am hoping to become a CST (Certified Scrum Trainer) myself, and the best way to learn is co-training with other trainers.

Over the last few weeks I had the pleasure of co-training with Gabrielle and Robert Benefield. During a discussion about sharing different training exercises I thought it would be great to blog about some of the exercises we use in training; to share them with a larger audience and get some feedback from how they work for other people.

I’ve already had great feedback on my estimation techniques post which explains a session you can run with teams to help them understand different estimation techniques. It seems likely that more training exercise posts would be helpful. The first topic is an exercise Gabby used to teach Scrum scaling patterns.

A Development Manager’s Strategy

It’s the end of the year and as a software development manager I find myself thinking about strategy. I’ve been in this position for 5 months now, and I think it is time to start consciously working towards a strategy rather than just doing what I think is right. After a few discussions with others I think I have the foundation of something that really resonates with me, what I believe, and what I hope we can achieve. I thought I’d share it and see what people think.

I believe there are three things that our board and executive team expect from product development. These are the 3 key goals or objectives for me for the year: Predictability, Quality and Value.