Pimp my Team

Abstract

From the middle of January 2011, our organization has been working in a new structure. There were different outcomes of this change, one of them was that my former firefighting team has been dismissed, and so has the team introduced in my Kanban Nightmares article. This post is not about their organizational change and its effects, but about the start-up of a new team in the agile world. I’m going to launch my first series of posts in which I’m going share - because sharing is good - the life of my new team in an agile perspective.

The title of the article is influenced by MTV’s Pimp My Ride series, in which talented and creative engineers are customizing cars. The team members and I are the engineers, and our way of working is the car. While watching the show, I got the impression that not every customization is necessary for having a well-functioning vehicle, but if I take away the fancy, unnecessary extras, the engineers are doing a damn well job. This is what we are going to do: customize our car, maybe a little bit too much, and after driving it a little, we are going to add new or remove existing extras in order to have a very good car. The show has the following chapters:

  • Introduction of the car owner, and her situation

  • Meeting, where the engineers discuss the customization - similar to a planning meeting

  • Assembling the car *- short session about how the *engineers are building the car

  • The showdown - the engineers present the car to the owner - explain what they have built and for what purpose

  • Test drive

Before starting the actual post, I would like to thank Daniel H. Pink and Olaf Lewitz for their insights on demo cancellation and rewarding systems, which topics will be presented shortly.

The Introduction

The first time I was thinking about improving the situation was the end of last October. At that time I was busy working in a firefighting team, which was responsible for solving the bugs of our old and new features. Firefighting is a very time consuming activity, so I didn’t have too much time to check on the other teams. The only thing I observed, though, was the amount of demo cancellation mails. Demo cancellation is supposed to be a tragedy in the life of a Scrum team. It means that the team has not completed what it committed to, and cannot or won’t present the result of the sprint to the customers.

I remember my first demo cancellation. I had to explain the situation to a member of the top management, and the whole team was ashamed of their failure. While I was reading the previously mentioned mails, I looked at the teams and didn’t observe any change in their behaviour or their way of working. I accepted this - it took me a lot of time, believe me - and then I talked to team members, who - besides mentioning external impediments - told me that they have quality issues. They found bugs too late, and they didn’t have time to fix them before the demo.

We had several agile corner sessions, and even though the quality issues were discussed, nothing really happened. At least not the things I would have liked to see. As a last resort, I was going to turn to a “motivation by money” solution: in case of a demo cancellation, the team would get less bonus. But luckily, before I did that, I talked to Daniel and Olaf, who pointed out that this wouldn’t solve the current issue. They suggested that instead of having any other similar “bright” ideas - they used a different terminology, I’m just being sarcastic with myself -, I should dig deeper and find the root cause of the quality issues.

I dug deeper, and I believe I have found it. Found them, actually:

Quality: Testing related:

  - Colleagues with testing skills do [*checking*](http://www.developsense.com/blog/2009/08/testing-vs-checking/) in 95% of the sprint, they do actual testing in 5%, which eventually leads to finding bugs at the end of the sprint

  - Sometimes the teams were doing *checking* only at the end of the sprint, or in the next sprint

  - The team is occupied with writing high level test cases (similar to [BDD](http://behaviour-driven.org/), but more complicated and fragile), which consumes a tremendous amount of time, and leaves practically no time for [exploratory testing](http://en.wikipedia.org/wiki/Exploratory_testing)   Craftsmanship related:

  - Lack of discipline. On paper, we are following [eXtreme Programming](/blog/tag/xp/) engineering practices, but when the deadline is close, no more XP

  - A small group of developers don't want to do *testing*, not even *checking*

  - Lack of professional knowledge

Organization related:

  • Interesting team setup. One large team for a feature consisting of two virtual teams for one feature. This leads to the scenario when “the **left hand doesn’t know what the right hand is doing”

  • Priorities are changing almost on weekly basis, it is hard to handle them

  • Different kind of work items from different independent sources

  • Unnecessary pressure from management

Turning back to the pimping metaphor, this car definitely needed customizing. At that time I had less influence on them, although I had some ideas on what needed to be changed - not the rewarding system of course. Unfortunately, the teams were busy with different activities, and there was no time to stop for a moment and do the customization. Fortunately, the reorganization made it happen: there is only one team now, which forming team consists of senior developers, developers, testers and new colleagues (local and foreign). I still believe that every beginner/forming team needs a start kick, but afterwards, the team itself is going to customize its way of working. Let’s start the pimping.

The Kick-Off Meeting

The team is in a bad situation. Its current way of working, which is Scrum, does not provide the necessary tools for handling the quality and organizational problems at the same time. Scrum isn’t the only practice available, we could also use Lean (Scrum wouldn’t disappear completely, we would keep doing demos and retrospectives). It may help us solving the organization related issues, but we need something for the quality issues as well. On paper, we are doing eXtreme Programming, why not continue it and do it correctly?

So, Lean and XP. Lean has great principles and practices, but we need a system which puts together these principles and practices with the software engineering practices of XP. Kanban seems to be a good choice, so we’ll go with that. It will show us and others our workflow, will helps us limit our resources, and deliver results faster and in better quality.

I’m talking about my Scrum -> XP+Kanban transition in this post.

The Assembly

The assembly in our case starts with education. It is really hard to do something when crucial lexical knowledge is missing. I observed that even if someone had the desire to learn something new, the next step, such as actually starting learning, did not happen. This has been a problem before, and since that mentioned lexical knowledge is really necessary for our success, we are going to do guided education. This means that there are certain articles that the team members will have to read, certain videos they will have to watch and certain exercises they will have to do, until that desire turns into action. I think eduction will make more difference than taking away the bonus or punishing the team with different old fashioned corporate methods.

Now we have a **three plus seven rule **(rules in agile, it is an interesting contradiction). This means that every single team member has to read three technical or agile related articles and do seven coding katas in a month. I admit that it is a bit harsh, but we’ll see on the next retrospective how the team members like this idea.

Additionally, every new concept such as system thinking, lean thinking, delivery on demand, etc. is going to be explained and discussed, if necessary, several times, until everything is crystal clear to everyone.

For example, we’ll watch the following presentations together in order to have an idea on the new methodologies:

Additionally, everyone has to read the eXtreme Programming Explained book by Kent Beck, or the wikipedia version. We are going to do XP, so we have to know what  it is about.

Eduction is not a one time only thing for us. We’ll do it continuously.

The next step is the mindset change. You cannot change people, they have to change themselves. However, you can change the environment, so that they have adapt to it, which induces that they will change themselves. The previously mentioned Lean principles are a great start for such a change. Mary Poppendick and David J. Anderson describe why changes are important in order to be better at what we are doing. I won’t repeat their thoughts from the presentations above, but I’m going to pick a couple of them which we are going to use:

  • Train ourselves in order to reduce waste (only do what needs to be done at the moment, have the smallest inventory possible, only work on items, which are known 100%)

  • Remove impediments as soon as they show up (for example: we won’t ignore a failed build, or take care of bugs later)

  • We’ll take care of each other, the product, and follow our disciplines

The components are here, now all that left is to assemble them into a customized (pimped) Kanban board:

The Showdown

The Kanban board looks very complicated, and actually it is complicated. Due to the nature of Kanban systems - they require an existing process -, they are as complicated as the underlying processes. The team has to handle several scenarios, but I’m pretty sure that later on our board will be less complicated than it is now (it happened with my former firefighting team, where we started with 3 different Kanban boards, and about 13 columns, and ended up with one Kanban board and 6 columns).

The Kanban board has the following small customizations:

After removing a couple of cells and columns from the Kanban board…

…it seems less complicated. Usually, Kanban boards have columns, but there is nothing against having horizontal columns, in other words: swim lanes. They fit better into our way of working at the moment.

So the swim lanes indicate that the team has to…

  • …solve feature bugs, usually introduced by the team during development

  • …do development work -  sometimes fix legacy bugs, this case we won’t differentiate between these two

  • …do work which is completely unrelated to development, like setting up servers

The Lean principle requires that we eliminate every possible problem when they show up. The team wants to focus on the bugs, because there are many, and these bugs were in fact what started the whole story: remember the demo cancellation? It was a long time ago, wasn’t it? So if a bug shows up, the team will handle it as a top priority.

Since the team is a development team, it is supposed to do development, and expend less effort on non-development related matters. Of course a non-development item can be an intangible item, in which case it can be handled with a higher priority.

Let’s have a short interruption. An intangible item is a class of service type, and it has been introduced by David J. Anderson. It has no immediate or customer value, but a couple of them can have a huge effect on lead time. For example, a build system improvement is an intangible item, but after implementing it, a faster build can reduce lead time, which means that the team can release faster and earn more money.

Every swim lane has its WIP limit, and the whole system has a separate limit: 7. There are 9 members in the team, and they don’t want to do a lot of context switching, so the overall capacity of the team is limited to 7 ongoing items at one time. For example, the team members are working on 2 bugs, 2 non-development items, and 3 development items. In this case, even though the development WIP limit is 4, nobody can start working on development, because 2+2+3=7, in other words: the team has got a full plate.

The Test column has the limit 1. We had problems with testing and quality. Now the goal is to do a lot of testing, which hopefully will reduce the number of bugs found after the demo or release. The idea is that the whole flow needs to be blocked until the latest item is not tested. And that the WIP limit will guarantee. Let’s assume that we allow 2 items in this column. It can happen, then, that one of the items remains there, and starts ageing. We don’t want to let that happen. After learning more discipline, this strict limit won’t be necessary, but it will be just fine for the moment.

The phases of the Bugs swim lane is pretty straightforward, unlike the phases of the Development swim lane:

Another swim lane showed up: Active items with a WIP limit 2. This limit does not count into any previously mentioned WIP limits. It just limits the number of large items the team is working on. In the example above, there are two large items: ‘A’ and ‘B’. Large means that the item cannot be finished in 5 days. For example an epic user story is considered a large item. Besides its WIP limit, the Active items is just a visualization aid.

The life-cycle of an item will help to understand the separate columns:

  1. When a new work item enters the system, it is placed in the Queue column

  2. If it is a development item and somebody can work on it (the WIP limits allow it), that person will put it into the Dec./T.P column

Dec. means Decomposition, and T.P. means Test Plan

  1. During decomposition the team checks the new item, we understand what the work is about, and if necessary, break down the item into smaller items (in scrum terminology, splitting into smaller user stories), that can be done within 5 working days (inspired by Chris Matts’ Kanban board from Mattias Skarin’s collection). For example: A = A1 + A2 + A3 + A4 + A5

  2. When we know exactly what the work is about - remember: we start working only on those items which we know 100% -, we will plan how to test it: acceptance test cases, BDD test cases, Junit test cases etc. This will be the ‘+1’. We also plan which regression test cases need to be executed, they are the ‘N’. *For example, if the *item changes a certain dialog, we won’t execute every test case during development, but only those related to that dialog

  3. When the work item is decomposed and a test plan is available, we put it into the Development Queue. *The contents of the *Dec. / T.P and Dev. Queue columns do not count into the WIP limit the development swim lane, because they haven’t been started yet. From this point we do our coding on a developer branch

  4. Green b. *means *Green base. We are doing green to green integration, which means that all the test cases we have are green before we start to work on something, and after finishing it, they are still green. This ensures that the new functionality doesn’t break the old ones. In this step we run the ‘N’ test cases, planned during Dec./T.P.

  5. XP Code is Extreme Programming coding. This is the only column where actual development is done. The name of the column is a bit misleading, but it indicates that we are seriously doing the XP techniques in this phase. We also develop the ‘+1’ test case(s) in this phase. If we find out that our change has effect on other parts of our application, we extend the Test Plan with ‘M’ test cases

  6. Refactoring is straightforward. We refactor our changes in order to improve quality

  7. Green b. again. This is the …to green part of green to green. In this phase we execute the ‘N+M+1’ test cases, and if they are green, then we have made sure that the new functionality is working (+1), and it hasn’t broken the old ones (N+M)

  8. In the Merge phase we merge our development branch to our release branch. The new functionality is ready for more testing

  9. In the Test phase, we run the ‘N+M+1’ test cases again. It could happen that another item had been finished earlier, for example ‘A2’ before ‘A1’. In this case, the ‘N+M+1’ for ‘A1’ is no longer valid, because ‘A2’ changed the underlying system. We have to extend the test cases of ‘A1’ with the appropriate test cases of ‘A2’. Additionally we do exploratory testing in this phase.

If we find a new **bug** or a missing functionality during development, they will be written as a new item, put in their proper queue **and prioritized accordingly**. **Bugs go to the main Queue on the left, and missing functionality items into the Dev. Queue in the middle. Every discovered thing deserves its separate item**.

There is a red border between Refactoring and Green b. If someone worked on an item on the left side of this border - mainly planning and implementation -, she is not allowed to work on it on the right side - testing. This move ensures an objective testing perspective. This is also valid for code review. No one is allowed to review or test the item she had been previously working on.

Again, it is complicated, but it will be less complicated after a couple of weeks or months.

The first Kanban board picture has three cells, which haven’t been discussed yet:

  • Demo ready

  • Demo queue

  • Other

The Other is easy. A small place for notes, placeholder for pens etc.

We present our results to our customers, managers and colleagues. One of our main goals is to show only working and bug-free items to them. After doing our complicated development flow, we want to do more testing. The plan is to have demo meetings every three weeks. This is our release cycle. Every item integrated one week prior to the demo meeting goes to the Demo ready cell. Those which are implemented during the week just before the demo go to the Demo queue cell. We won’t bring them to the demo meeting, because we are going to do another exploratory testing session on* the content of the *Demo ready cell. Bugs discovered during this testing session have the highest priority, because the product is integrated, and we’ve missed something important even with our complicated development workflow.

The Demo queue cell is for the items finished during that one week period before the demo. After the demo meeting, its content is moved to the Demo ready cell, and the cycle continues.

We have continuous integration build, which executes a static code checker, builds the source code and runs the unit tests. When this build fails, we put a paper on the Kanban board with the text: build failed! like this:

We are following the 5th principle of TPS: if the build fails, we stop doing whatever we are doing at the moment and fix the build. The paper indicates the problem, and since it is all over the board, it makes it difficult to change its contents.

Test Drive

Let’s do a test drive with our new car:

The team has two development items: ‘A’, ‘B’ and one non-development item ‘D’.

Two of the team members have started decomposing and test planning item ‘A’. ‘A1’, ‘A2’ and ‘A3’ have been created.

‘A1’ has been implemented, integrated and tested, so far so good. But a bug - ‘A21’ - has been found, while refactoring ‘A2’. ‘A21’ has been moved to the top of our Queue.

‘A2’ remains where it is, because it is blocked by ‘A21’. Two of the team members are working on ‘A21’, meanwhile the third member starts decomposing ‘B’. She has chosen ‘B’ over ‘A3’, because she is familiar with ‘B’ and has the feeling that if ‘A2’ is problematic, this may mean that ‘A3’ is also problematic. If she started working on ‘A3’, then her implementation efforts might be wasted.

‘A21’ has been solved and tested, ‘A2’ can move on. Meanwhile, the decomposition of ‘B’ has been finished: it turned out to be a small item, so there is no need to split. Additionally, two team members have started to work on ‘A3’. Unfortunately, a bug has shown up with ‘A2’ during Green b: ‘A22’. It is placed on the top of the Queue. ‘A2’ is stopped again.

Two members are fixing ‘A22’, ‘A3’ is continued by one member, and ‘A2’ is still stopped.

Now you can have an idea about how this works.

Closure

Again, I have to admit that our new way of working is really complicated. I put a lot of trust in the education, and hope that things like green to green integration and lean principles will become a part of our daily lives, and we won’t need complicated processes forcing ourselves to do them properly. Kanban and XP will help us to solve our quality issues (see the root cause collection at the beginning of this post), and the Lean thinking will solve the organizational ones.

James Shore and Arlo Belshee describe a similar setup in their Single Piece Flow in Kanban presentation. Actually, I felt that I’ve reinvented the wheel after watching the presentation. I liked what James and Arlo have presented, but we need more time and practice in order to do everything the way they say is right. So we are going to stick with the way of working described in this post for a while.

We are living our lives with this setup for almost three weeks now, and there have already been a couple of small changes and new ideas, but those I’m going to share in a different post. I hope you’ve read some useful ideas. If you have any thoughts on the subject, please use the comment section for sharing them.

comments powered by Disqus