Trying to see the big picture with Kanban

Awesome start at work!

I’m in a team of four very experienced and smart people, we have a product owner who is tech-savvy, knows what he wants and sits in our team room! On top of that we have an excellent room where single every wall is covered with material that you can pin stuff into. We have been given control over our tools and we are given a lot of trust (which is as it should be ;) ). We agreed to start with kanban as our development process and that made me extremely glad since I haven’t been able participate in a real kanban project yet!

We are now roughly two weeks into our green-field project. We started out with a simple three swim lane kanban-board where one swim lane is for product backlog stories, one lane for team stuff (environment, tooling, etc.) and one lane for the PO. Almost all work flow states have a WIP limit of 2, one has a limit of 4. At any time only two user stories can be under work. your basic kanban stuff.

We have the categorised the product backlog stories and pinned them on the wall. They form a vague big cloud, a chunk of things, that we are supposed to make. And this chunk is annoying since it does not provide a coherent vision, idea or goal for the team. Well, of course the goal is make the whole product, but that doesn’t really help in daily work. The team needs a short-term goal and a vision to support its work. The vision could be described as an epic, a collection of stories. Simply put, we need to know where to aim at on a shorter time interval. Our initial kanban board didn’t give this vision but our PO had already defined it and written it down on one of our whiteboards. So it was there for us but it wasn’t part of our kanban board. How could we incorporate it with our board?

I devised a kind of a funnel, a new stage if you will. Epics are pulled from the Big Cloud and placed into a funnel. It will be the teams goal and provide a clear path for us to work with. The contents of an epic are coherent and we can easily see, for example,  interdependencies between stories. It is also extremely useful when we manage to get some data about our lead time to help us estimate when a certain product increment is ready. This can then be conveyed to the stakeholders and business people. We can estimate and tell them when to expect a set of features instead of the whole product or just a single story.

To put it short, we now have three stages in our kanban wall. From the backlog cloud the PO can envision an epic for the team that will guide us to the next composition of increments. From the epic stage we pull stories to the kanban board for the teams daily work.

To some of you this may feel like we are aspiring for things that Scrum gives you out of the box. Well, we are but rather than restricting us with Scrum we are doing things that we feel benefit us and our stakeholders. We have retrospectives, we are going to show (or demo) what we have achieved and we are going to estimate the big chunk of stories. But we do an activity only if it will bring value. For example, if there is no value in estimating the backlog, we won’t do it. But we are going to try things that are deemed valuable either by the team or the stakeholders. And remember that the epic can be withdrawn at any time as it is not taken under work, we still do work only on story level!

I am eagerly waiting how the process will evolve and what is the direction it will evolve?

(picture by cantoni)

Scrum – is there a role for tester?

Simple question, heard quite often though, has a simple answer, yes, there is a role for testers in Scrum.

In the following I try to clarify why.  And as a prerequisite a assume that we are talking about an intelligent tester, not just some simpleminded clerk who can execute ready-made scripts.

Why a tester is an asset?

1. Scrum team should be omnipotent. Erm, omnipotent when it comes to delivering functional software. You need testers to have a cross-functional team.
2. Testers have a different state of mind. They approach the problem from complete different angles than the developer. Tester is able to approach the System Under Test (SUT) from multiple perspectives, including but not limited to, system, functionality, user and exploitatory point of view.
3. Test automation. Yes, even though TDD is a big thing, and anyone can automate test,a capable tester is a huge asset for any Scrum team. Testers have usually invested quite much in their skills regarding test automation and they know how grab the low hanging fruit for any SUT and proceed from there.
4. Tech savvy testers provide valuable feedback about erroneous systems. I have experienced quite many problem cases which I could not have been able to correct had there not been a skilled test engineer to tell me how and where the system is broken.
5. A human equipped with a tester mind set, given the time needed and tools required to perform exploratory testing can save you from so many problems. Not to mention money saved.
6. Good testers will educate developers.
7. Good testers will become excellent developers.
8. Good testers can question the functionality in a different way compared to a developer.

Many of these traits are found in a tester. So, if you get a capable tester, hold onto her with every possible way you can.

What not to do with testers in your team

There is a catch too. You can easily expel a tester, make them useless and feel outsiders and ready to leave the company. They need the same care, nurturing and attitude as your ordinary developer. You should treat them equally.

And what is really important, this same goes with your developers without saying, do not tell them what to do.  Whether you are within the team or outside the team, do not place any pressure on your testers either as you wouldn’t place it upon your developers. But the most important thing is, don’t put any  external responsibilities, like feature acceptance gate responsibility upon them. Trust the whole team and only the team to give you the green flag.

Testers are after all a part of the team and have so much to give. Love your testers as you love your developers.

My first training pt. II

It’s getting closer and I am excited. We, meaning me and my partner in crime, have prepared close to 130 slides for the 2,5 day training. That may sound like a lot comparing to the simplicity of Scrum. This is not just a Scrum training. We are presenting our way of doing things. What has worked for us during the year and a half of transformation and what has not and what are the issues we are still struggling with. We present an example how it can be done.

First we will go through the idea of Scrum presenting the manifesto and principles of Agile. Then we will continue with the artifacts and roles present in Scrum process. We will have hands-on practices which will yield working agreements, definitions of done and a rough schedule for their sprints. Product owners will learn how to do release planning with Scrum.

During the second day we will concentrate on breaking down what work Scrum actually contains, what kind of work and objectives there is. We will have sessions for grooming the backlog and planning the sprint as well as for demoing the results of a sprint and having retrospectives, inspecting the past and adapting.

The half day will then be spent on visual management which aims to satisfy the upper level managements needs for seeing progress in some reported form.

But, then I have 5 hours just for myself. I will be giving a primer in Test-Driven Development. Being a newbie myself I hope that it will work out at least on some level and that I don’t screw it up :-P But that remains to be seen.

I also hope that I am able to affect these people and leave  a positive mark in their minds. Hopefully some of my enthusiasm stays behind and infects them with a yearning for improvement!