Where To Start Part 3: Team Evolution

Part three of my where to start with BDD post. The first two parts can be viewed here:

So at this point your team has started using WIP limits and BDD.
Does your team now have a surplus of one role, maybe there are 2 or 3 testers who are not covered in you WIP limits as they are not developers.
Maybe its time to evolve a little and try blur some of the roles, or how about experimenting with your WIP limits?

Let’s talk through these two ideas.


In an earlier blog I talked about having WIP limits set to the number of developers in the team. So when a story is in test the developer is in slack time.

This is where we can start blurring the roles a little bit. Personally I like to invite the developer to test along with me. If our examples have already been automated then we don’t have to worry about testing them. Now we get to do some fun creative exploratory testing, this is great as a paired activity. Once developers see how you are thinking, they can then start doing it themselves.

For exploratory testing I tend to think of the least technical person I know and pretend to be them using the system. This is my dad (sorry dad). He has managed to find the most interesting bugs and get the best viruses over the years, and his answer is always the best for a tester, “Ohh yea I clicked on that cause I could”. If your system has a flaw no matter how small or silly you think it is, a user WILL FIND IT.

But pairing works both ways. After the 3 amigos session when a tester is in slack time, why not pair up with the developers. You could start doing a joint TDD exercise. The tester writes the tests and the developer writes the code to make the tests pass.

Eventually you could swap that up completely and have the developer write the tests and the tester write the code. You will have a true multi-functional team, where everyone can do everything.

So how does experimenting with your WIP limit work?

Well how about decreasing it. So if you have 4 developers, make the WIP limit 3. This frees up a developer to help the team. This means someone is always free to jump on code reviews, or to do some of that tech debt you can never find the time to get to. You can swap up that developer each story. It also encourages more pairing, as two developers can work together on a story.

There are loads of different things to try, use retros to see how they are working. Just don’t make too many changes at once, it will be hard to know what worked and what didn’t. (I’ve made this mistake before)

If you have any suggestions, or have run some experiments on your teams let me know.

Just make sure your team keeps evolving by trying new things. To quote Eddie Vedder, “It’s evolution, baby…Do the evolution”