KanBan for Management

Finally, a post on KanBan 🙂

I’ve been running teams who have been using KanBan for a few years. We find it is a really useful methodology to use, especially for our maintenance and dedicated testing/ release teams. Being a little lighter than Scrum, it enables us to quickly re-prioritise backlog items; ideal when you don’t know when the next Showstopper bug is going to come in.

Recently I’ve started to take things a little further with a pilot in my management team, which consists of test managers, defect managers and product owners who are driving various software projects to completion, mostly in the maintenance and productisation phases. The pilot involves using KanBan to run the team and prioritise the various actions and items that we need to drive forwards.

We wanted a lightweight approach to the toolset, so rather than go for a heavy tool, or something online (company policy – nothing on 3rd party servers), we picked SherePoint. Daniel Roots excellent guide on how to setup a KanBan board in SharePoint has been invaluable and what we have now certainly fits our need. OK, so you may not want to use this to run a detailed software project without some adaptation, but for prioritising and driving the management backlog then it works just fine, especially when tasks are sync’d with Outlook.

Changing our way-of-working was, as usual, initially difficult, but quickly the benefits of being able to see what everyone was working on and where it was in the cycle became apparent. Figuring out the work in progress limits for the team was a challenge, given the varied nature of the different roles, but we found that, more often than not, our tasks relied on each other, and therefore our ‘internal’ WIP limits did too. This meant that the team did have a natural velocity and this could be used to set WIP limits accordingly.

You may wonder whether this approach sounds a little heavy-handed? I’d argue that it does not, simply because you always keep an action list or backlog for a management team. Maybe you have tried to colour-code it or tabulate it, in order to make it more visible? You are halfway there. Why not go the full way and try KanBan for it instead?

Managing Your Stakeholders

I’ve just qualified at Practitioner level in Managing Successful Programmes. MSP is, (in the UK), the preferred approach to programme management, and the normal next step after getting the relevant project management qualification PRINCE2. As well as being a very hard week of training and exams, and very useful for me and my career, what can it teach us when applied to the software testing area specifically?

MSP teaches us to take the programme approach to controlling groups of projects, gives the bigger picture, vision and framework in which to run them, and most importantly for me, it teaches the importance of your stakeholders. I’ve found during my career so far that this is one of the most important areas that a test manager can focus upon. I’ve managed projects and groups of projects, programmes if you will, and the most common problems I see are always related to lack of buy-in, understanding, or focus on rolling out changes and embedding them in the groups that need them. That’s not the technical test methods and techniques, the dashboards required to track progress, and the planning that needs to be done; this comes easily. Or if it does not then you make sure there are people in your group to whom it does. But overall management of the stakeholders falls to you, as head of the group, senior test manager, programme test manager, (or whatever job title you have). You have overall responsibility.

MSP gives a good framework in which to manage those stakeholders, encouraging regular communication and follow-up, focused planning of stakeholder engagements and close cooperation.

It’s easy to get stakeholder engagement wrong. It’s not easy to do, it’s sometimes not nice to do. You believe in what your programme is trying to do, why the need to convince others? But ignore stakeholder management at your peril. This is especially important in testing where you often have to fight for your budget and your resources more than other disciplines. Being able to provide the right vision to secure initial buy-in, to follow this up with the right targeted communications to the right people, and give the required and regular continued communication means that your life can actually become easier.

Where should you focus when considering test management stakeholder engagement? Start with identifying who the stakeholders are. Do you need to roll out a new testing process in many teams and projects? Do you also need to introduce new tools and new teams, possibly off-shore? You’ll need to focus on different people and you need to know who these people are and what stake they have. Then think about a vision of the future, paint a picture where testing brings higher quality to the products, through better process or tools. Talk in terms of money saving, of shorter release cycles, and of long term quality. This will be high level so target this further towards each individual stakeholder; think about what each one will care about. Are they a ‘money guy’ or a ‘people guy’, are they fascinated by the process or the tools? Tailor the message to each one and you have a much better chance of success.

Then don’t stop. You need to be communicating to these people regularly. And don’t stop once you have delivered something; keep talking to them as the new processes and tools are rolled out and become operational. They will have questions and they often won’t want the changes. It’s here that stakeholder engagement often fails; people stop it too early, leaving stakeholders un-happy, and expensive new processes and tools unused.

Ultimately you hope to win over some of the doubters, those who do not see the value that testing brings. You want to ‘push the right buttons’ to do this. And if you can do this, whilst letting the rest of your team handle the individual projects where testing is taking place, then you have proved your value at the programme level.

Do Testers Take Themselves Seriously Enough?

The argument over the importance of software testing, and how software testing should be taken more seriously, is as old as the hills. “Software testing is seen as a second rate career” is the most common thing testers have to fight against, with various degrees of success, normally dependent on the company they are working for and that company’s approach to quality. But do testers really help themselves?

Over the years I’ve been a tester and managed a lot of testers and others involved in QA. More recently I’ve also started to manage a development team, and when talking about careers to developers and testers, the difference are sometimes startling. Most developers had a plan from college onwards, most still have a plan, and it’s been coding. It’s rare you find someone fell into software development by accident. Now compare this with the testers. Some have a plan, some have stuck to a plan but a majority have not. It’s been a case of falling into testing, often from totally different careers or training. Think of it as being in the right place at the right time 🙂

This got me thinking – is it an issue that developers have a plan and testers just found their way into their chosen career? Does this in fact mean that testers have a more broad experience and that actually makes them more rounded individuals? Does this make them better testers? Does it just demonstrate the lack of formal test training in schools and universities? Do we need more certification to be taken seriously? (joke – we really don’t).

Whatever you feel about it, it’s clear to me that only be recruiting sensibly, by inspiring people to become career testers, and by continually sharing and demonstrating that software testing is worthwhile will we swing the balance. Those in the software testing profession should be focusing on those at the start of their careers, not just focusing on test process and continual improvement. I hope to be able to find more testers in it for the long run, and in the middle of a longer term plan for their software testing careers.

My Thoughts on Exploratory Testing (a.k.a. Steve discovers SBTM)

The group I manage make regular use of Exploratory Testing. We even took training, way back in the day (well a few years back anyway), we know about our test charters, we know where to start and where to stop, we understand it’s place in our strategy. It forms a corner stone of this strategy, which we have to enable quality within our projects. Yet to some of us there seemed to be something missing.

As a tester it’s great. We make a thing about exploratory test sessions. There’s coffee and if you are lucky then there is cake too. You turn up, you pick your area and you fill in your charter. Start the clock and go; testing begins. Stop the clock and testing stops, bugs are added to our database and charters are filled in. Coffee is drunk and cakes are eaten and we go home…..

…..leaving a large pile of pieces of paper which are subsequently bundled in a drawer and forgotten. You might argue this is ok, after all “the bugs got raised didn’t they?” This is of course true but as the Test Manager then I miss the ability to learn from the experience, to review the metrics and to understand how to make the next sessions even better.

So recently I discovered Session Based Test Management, James Bach’s take on ET. I know, late to the party again, by about 10 years, but I work for a large multinational telecoms vendor and change doesn’t come easy to us (awful excuse of course). But thankfully we’ve now found SBTM. I love it, you get the metrics you need, the visibility and the control that allow ET to really come to life. We’re focusing on it more now than ever before.

(One tip if you do take SBTM and James Bach’s tools – also use Session Creator; it just makes things so much easier for the testers.

Is Testing Like Table Football?

At work we do a lot of testing, and we play a lot of table football. Up-time and down-time; you can’t stare at a screen or a handset for too long before your mind goes blank. Everyone needs a break sometime….

But are the two activities so different? Can testing learn from table football, or can table football learn from testing?

Those of you thinking “of course not”, consider this:

  • If you are playing the defender and goalkeeper then you’re trying to stop something (the ball) getting in (to the goal). 
  • As a tester you are trying to stop something (bugs) getting out (to the wide world).
  • To be great at table football you have to play as a team. It’s difficult to play table football with only one person per side.
  • Try stopping all the bugs as a tester on your own.
  • The success of a team at table football is decided by who uses the best tactics, the best techniques and the best skills.
  • Testing is the same – you can’t catch the bugs simply by hoping you’ll find them.
  • Sometimes just hitting the ball as hard as possible gets a goal.
  • In testing, sometimes just hitting the product with all your skills, probably via Exploratory Testing or Session Based Testing can find the bugs.

So, maybe our up-time and down-time activities are so different after all 🙂


Today I don’t feel inspired. Something’s just not sparking the creativity. But it has got me thinking; more specifically about inspiration and that spark when software testing.

When someone is testing and they are inspired you can see that. If it’s you then you can feel it; somehow things go quicker, those small problems remain small, and your day goes quick. If you manage testers then you can see it in their eyes, the way they move around (does this sound a little like spying? I hope not), the way they talk.

But how can it be that the thing that inspires us one day doesn’t inspire us everyday? What’s changed? Maybe it’s that 400 page test spec to run through, maybe it’s that software that just won’t even boot, maybe it’s the defect that got returned or ignored again, even though you know it’s important. But as someone once said “the bad things are what make the best things better”; so for all the mundane and boring, there is also the excitement of that new bug, that near darn perfect test cases, and that feeling of pride when a product ships. Take the rough with the smooth some days.

Hmmm – maybe inspiration is coming again……

Test Manager in the Agile Wilderness?

2 years ago the company I worked for decide to ‘go Agile’. Vast amounts of money were spent, many people were trained, and whole groups were reorganised. As managers, we all took a look at our groups, assessing the impact, assessing the likely damage 🙂 and trying to figure out exactly how it affected us.

I run a test and quality assurance group so the changes affected my teams a fair bit. We needed to figure out the best testers to put in the relevant scrum teams, those who were best suited to a more regression focused role, and those that we could train to move nearer development or into our automated testing stream. So we sat down, we thought, we planned, and it was all going well. Until……

The Test Manager stood up. ‘I’ve been thinking’, he said, ‘Where do I fit in this?’. And he had a point. We’d allocated the people doing the actual technical testing to the scrum teams. We’d trained, we’d supported, and we’d nigh on forced, the product owners to take the responsibility for quality. We’d put in place a framework which enabled them to plan and deliver their fully tested code to the relevant code branch. Had we done our Test Manager out of a job?

Well….stopping and thinking, we looked further. What does a Test Manager do? Planning, coordinating, ensuring test activities take place on time, on budget, are visible, and most importantly they take are effective, resulting in a quality product. Does the need for this change in an Agile environment? Maybe it does, but the cornerstones of a Test Managers’ role do not. I still require someone with their eyes on the testing. I still require someone who can give me the latest execution status, the latest defect count and the latest plans for testing. I still need someone ensuring effective coordination across the teams, both in process and in test execution.

So the role of the Test Manager changes. In small steps, but with similar goals to before. Make sure the results and status of testing is visible, make sure that the processes used are understood and actually used. And ensure ultimately that, at a programme level, the whole group produces a quality product.

So, we hadn’t abandoned our Test Manager to the Agile wilderness, but he’d had to change, like we had, to suit a new way of working.

Keynote speaking, technical leadership, coaching, training and presenting