Last two posts of the series (on Kanban Board and on setting up whole thing) were Kanban implementation-in-a-pill kind of story. As you may guess that’s not all since Kanban doesn’t prescribe many things which you can use and, most of the time, you do.

To show the big picture there are two lists: practices we use and these we don’t.

Things we do

• Cross-functional team.
As I mentioned at the very beginning (the_beginning) we have cross functional team which is a great thing. Virtually every action connected with our product in any way is performed within the team.

• Co-location.
We sit together in one small room. That’s so damn great. I wouldn’t change it for private office even if you paid me.

• Roles.
We have old-school roles within the team. Developers who, guess what, develop. We have our commando guy who mixes roles of QA, system administration and maintenance. He could work as our bodyguard too. My role is project and product management which in our case could be called Product Owner as well. We also have a guy responsible for business development. Nothing fancy here. Everyone just knows what they’re supposed to do.

• Measuring lead time.
When I initially wrote a draft for this post this was on the “things we don’t do” list. For some time it wasn’t needed much since with no production environment it wasn’t crucial to know whether specific feature will be ready in 2 weeks or rather 16 days. Now, as we need more precise estimates, measuring lead time emerged as useful tool so we started doing that.

• Continuous improvement.
Implementing Kanban was an improvement to the old methodology. Starting to measure lead times was another. We look for tools or frameworks which improves the way we develop our products in terms of speed, quality, code readability etc. Nothing fancy here – we just try to make our lives a bit easier whenever we can.

• Unit testing.
We write and maintain unit tests. We don’t have 100% coverage though. I trust our developers would write unit tests wisely. Most of the time they add unit test covering a bug scenario as they fix bugs too.

• Continuous integration.
Oh, is there someone who doesn’t do that?

• Static code analysis.
There are coding standards we follow. They’re checked during every build. After a couple of weeks coding standards became native and basically invisible so it’s hard even to say that it’s a real practice.

Things we don’t do

• Iterations.
At least formal iterations. We don’t have sprints whatsoever. To bring some order we group some features and call them “iteration,” but that’s nothing like scrumish iterations. I’ll write a bit more about our pseudo-iterations soon since that isn’t something very standard done by-the-book.

• Stand-ups.
We have permanent sit-downs instead. Whenever something needs to be discussed we just start the discussion not waiting for morning stand-up whatsoever. No-meeting culture works surprisingly well so far.

• Formal retrospectives.
Same as in previous point. We just launch “I don’t like it, let’s change it” kind of chats whenever someone has some valuable input. You could call them informal retrospectives on call.

• Burndown charts.
We have no fixed scope within iteration to burn since we don’t have real iterations. I occasionally draw burndowns for a specific feature (a single sticky note). I do it mainly to check how my well works schedule simulation (estimates plus statistical analysis).

• Code review.
I’m a big fan of code review. I tried to implement it twice in my teams and failed twice. As long as developers won’t want to do code review I’m not going to force them. That just doesn’t work this way.

• Pair programming.
This one I don’t believe in. So do our developers.

• Test driven development.
We write unit tests. We do this after not before. This is another practice I’m not a big fan of and another which takes people who strongly believe in it to make it work.

If I forgot to mention something on either list just let me know what I omitted and I shall provide update.

I encourage you to read the whole Kanban Story.

One of stages of one-afternoon Kanban setup we did was creating our own Kanban Board. We just discussed what we wanted on the board adding columns which appeared reasonable for everyone.

This is what we came up with.

To describe stages:

• Backlog is a big bag where I willingly throw in anything anyone wants our project to have. Now we have the best product around. It will virtually have every feature in the world. I would also be a best Product Owner around. The guy agrees on every feature idea you could possible come up with. Unfortunately he can’t say when the product will have all these features.

• Todo is a short list of current top priority tasks which aren’t yet started. It usually changes every time I come back from a meeting with one of our customers or partners. I keep the rule that whatever is on the top of this column is also the most important at the moment.

• Dev, which comes from development, is a group of two columns: one is ambiguously named Dev, which comes from “in development” and another one states CC from “code complete.” The former groups tasks which are under active development. They make their way to the latter after developer’s tests. This couple is grouped since code complete is just a technical stage to tell us specific functionality is ready.

• Test is what it sounds it is. Testing. Checking whether we could deploy version if we wanted to. Finding bugs and fixing them. On and on.

• RTS comes from ready to ship. For the moment we set up the Kanban Board we weren’t planning to have regular deployments in production environment so we just wanted to have versions which would be possible to ship if we needed that. Whenever something reaches RTS column the work is considered to be done.

Then, we wrote down all tasks which weren’t yet completed, including these being under development and these which were in plans only. Every task was written on a single post-it note and was posted under relevant column.

We ended up with a post-it in Todo, two in Dev, one in CC and six in Test. The overwhelming rest was in Backlog. And yes, long Test column made our problem with finishing tasks painfully visible.

When we were done playing with sticky notes it was time to set limits for each column.

• Backlog doesn’t have any limits. That’s natural. Hey, I don’t want our product to lack any feature. Give me all of them. And I mean all.

• Todo column was limited to 3. I think this is good maximum queue length – it makes clear short-term perspective. As it appeared later quite often it was hard to decide which sticky notes would make their way to Todo column and which would not. And it wasn’t rare when something was going back to Backlog before guys here were able to start working on this.

• Dev was limited to 4. This included sum of both Dev-Dev column and Dev-CC. Basically we came up with the number assuming it’s still acceptable that each developer has one task completed (CC) and another one started (Dev).

• Test was a biggest problem. We finally set the limit at 4. We knew 6, which we had in Test at that moment, was too much. On the other hand we didn’t have any clue what should it be. I was far from setting there a number which is too low and supporting fiction. So we used some guesstimation and use 4 as our lucky number. And it created an instant incentive to work hard on cutting this queue a bit.

Finally our first version of Kanban Board looked like that:

This is by the way much simpler board than Henrik Kniberg proposes as a kick-start example. Personally I encourage you to start as simple as possible. You’d adjust things later on. Henrik’s proposition is too complex for the team which isn’t familiar with Kanban. It pushes too much detail to the board which makes it hard to read.

Read the whole story from its boring beginning up to this point, where things hopefully become interesting enough to keep you irresistibly waiting for the next chapter. Check also version 2.0 and version 3.0 of our Kanban Board.

So you want a story about the most painless implementation of new software development/project management methodology in industry history? Here it goes.

There was nice afternoon, sun was shining and air-conditioning was silently humming. One of our engineers asked me what about this new methodology we were talking about a couple of weeks earlier. So I described them how it works in details telling basically nothing more than could be found in great Henrik Kniberg’s article on Kanban I mentioned earlier. It took definitely less than a half of hour, including Q&A.

Then we drew our Kanban Board discussing which stages we wanted to have. More about creating our Kanban Board in the next post.

The very next problem we have to solve was what exactly we want to move through out Board. We couldn’t decide on a color of sticky notes. I thought classic yellow would emphasize our respect for established rules of software craftsmanship while there were opinions that green would be better since it corresponds with stability of our software and flawless builds we get on our build server… OK, just joking here.

Actually the problem was what granularity we’d use on sticky notes. MMF (Minimal Marketable Feature) is a nice concept but sometimes too vague. Generally we try to use MMF whenever it makes sense but sometimes we use non-marketable features as well. Example? When we had screwed something in database structure we got “fixing up a database” post-it. Unless you freaking darn good marketer this isn’t “marketable” at all, but pulling flawed database with the product all along the way would be kind of a pain in the ass. Fixing it later would cost far more than doing it fast. This substitutes being marketable if you ask me.

To simplify things a bit we dropped using user stories. We decided using inside-out approach which in Tyner Blain article on agile prioritization is described as wrong one. The reason was most of the time splitting tasks in a way which was convenient for our development team created results which were identical with these achievable with outside-in approach (splitting tasks in a most convenient way for a customer). In these rare moments when it did not I could live with that and for me it maked development cycle more reasonable. Yes, I sure am biased with my past experiences as a developer or trying to play as someone like that.

Anyway we ended up rather with old-school features describing (hopefully) fine-enough-grained functionalities rather than scenarios describing how user would interact with the application.

Having this done we filled the Kanban Board with sticky notes showing what we were doing at that moment, what were planning to do and then we set up limits for each column. Again, more on this in another article about Kanban Board.

Basic setup of tools was completed. The rest was to follow few simple rules, limiting WIP (work in progress) being the most important one.

Basically Kanban was implemented and it wasn’t even a time of sunset, which we wouldn’t saw from our window anyway. We turned off air-conditioning and went home.

I know things start to look interesting barely now but feel free to check out the first few parts of The Kanban Story.

Meetings are boring. Most meetings are irrelevant. There are too many meetings we have to attend.

A confession: during past half of year I organized exactly two meetings with engineers in my team. Both were mostly about organizational issues regarding whole company, not just my team.

How did I do that?

Let’s start with why meetings are organized. Most of the time meetings happen to enable communication between people. Why don’t people just go to meet each other at their desks? Well, because they sit in different places, have different things to do and, often, have little free slots in their calendars. Sometimes they need to prepare themselves to say something reasonable and invitation to the meeting gives them time for that.

Basically all these reasons become non-existent when whole team sits in one place.

You don’t have to busily gather people from different places because, surprise, surprise, everyone is there.

You don’t have to wander what people do at the moment since, well, you just see it in a glimpse. You can make your call whether it’s a good time to interrupt them at the moment or you should wait for a quarter.

You don’t feel urge to finish in planned time slot even when the discussion is great and you’re solving problems like crazy. Neither do you feel this funny feeling when everything was said but no one hurries back to work and you just spend your time on chit chat because a meeting room is reserved for another half an hour.

You can even allow starting talking with folks on subjects they aren’t prepared to. You can because whenever they need to prepare they’ll tell it and a discussion will be restarted later. This is like instantly starting a meeting instead of sending invitations. Odds are everyone is ready and you don’t waste time. If they are not it works similarly to invitation with agenda but better since you start meeting as soon as everyone’s ready.

You should still think how improve transparency and communication flow but, believe me, once you start talking about almost everything in front of your team, even though you’re talking with a person next desk, people will know way more than they would otherwise. It would work that way even if you reported all your workweek on 4-hour long weekly summary with your team, which would be a candidate for the top dumb management practice of a year by the way.

And the best thing. With this approach you magically clear everyone’s calendar. Finding slot when everyone is free becomes the easiest thing under the sun because everyone basically stopped attending meetings.

A cherry on the cake: finding free conference room doesn’t bother you anymore.

Downsides?

It won’t work for 50 people. As far as teams aren’t bigger than 10 people it should do well. Vast majority of teams fall in to this category. Sometimes you need to focus and you don’t care about architecture discussion happening over your desk. You can take a break or try to isolate yourself with headphones. Either way it is a cost, but on average it’s significantly lower than it would be if you switched for old-school meeting approach.

This applies only to team-related meetings. If your people have a lot of cross-team meetings and spend long hours on company-wide roundups filled with jabber this doesn’t have to be huge improvement. But then you’re doomed anyway. One of my engineers attended a few meetings on coding standards beyond these two I organized.

The approach works best for engineers. Project managers and business people will meet other people more often that once per quarter but it should be still an order of magnitude meetings less than it used to be.

I wouldn’t get this kind of crazy idea but it happened so my whole team is collocated and it’s the best organizational thing which could happen. If you think it’s drastic, you’re wrong. Meetingless environment comes naturally. Maybe it so because this way you possibly are all time at the meeting, but at the same time you “meet” people only when it’s really needed.

Try it. And tell me what happens.

In the last chapter: A small team was built and they tried to set up a methodology for building their projects. After establishing a set of techniques and trying them against first couple of projects they faced a list of issues. They realized they needed something more. How would they deal with the problem? What would be their choice?

When I read Henrik Kniberg’s article Kanban vs Scrum it was first time when I thought I get the whole idea. I even thought it might work for our team but if you know me a bit you know I’m very reluctant to drop anything we’re currently doing just to try out this new cool idea I’ve read about yesterday. This is by the way the most important reasons why a few engineers with great potential I know will never fulfill this potential. They just can’t hold their horses whenever they read about new jazzy technology. And it doesn’t really matter whether it does any sense to implement it.

Anyway I finally decided to give Kanban a try since I believed it would solve both of our main problems. First Kanban limits work in progress (WIP) by design. Second having open backlog where I could put any incoming idea should help me with dealing with all different threads happening around our group and at the same time I should be able keep modifying priorities pretty easily.

What more, Kanban shouldn’t put on us much of constraints which would be invited by most of other methodologies. As lightweight as possible, as little bureaucracy as possible. Kanban suited well.

I checked team’s opinion about starting something new which would help us. When I described Kanban and prompted for feedback I got green light although I can’t say they were enthusiastic whatsoever.

A decision was made.

Read the whole Kanban Story.

A lot of interesting discussions today. During one of them we went through co-location and its influence of team productivity.

I’m lucky enough to work with all my team in one room. I’m aware of all disadvantages of grouping people doing different things in one place but I’m still saying I’m lucky.

• I know development requires focus. I know that grouping a bunch of people in one place generates some chit-chat which distracts people trying to focus on their tasks. I know occasional phone calls do the same. I accept the fact. Hey, have I just said I accept lower productivity of our developers? Bad, bad manager.

• I know most people would consider a private office as a huge improvement from open-space. I wouldn’t offer that to my people even if I had a chance to make them this kind of offer. Ops, I’ve just admitted I wouldn’t make my people happier even if I could. How come?

It just about trade-offs. While putting people together invites costly context switching because of distractions it also brings huge values in terms of team work.

• Instant problem solving. It’s enough one person to ask another one about some issue to see insightful discussion emerging virtually instantly. You don’t need to think whether PM should join since he’s here and he joins as soon as subject appears interesting for him. Solving problems as you go is much more efficient.

• Communication improvement. Communication issues are probably number one issue when it comes to visiting dead-ends, doing the same job twice or banging the wall hard with your head. When I think how much effort is wasted just because a couple of people didn’t talk with each other I believe every method which improves communication is worth considering and most of them are worth implementing. Co-locating people is one the most efficient choices here.

• Reducing number of meetings. Many meetings aren’t even needed. However they’re scheduled because they’re considered as the easiest way of communication between more than two people from different rooms. Remove walls and you’ll automatically remove many meetings. People will have more time to do the real work.

• Atmosphere building. Try to cheer up person who sit next to you. Tell a joke or something. Succeeded? Great. Now do the same with the person sitting on other floor. It takes walking and other tiring physical activities. It’s harder. You won’t do it so often.

• Getting to know people. You’ll know better a person after sitting with her in one room for a month than after working in different locations for a year.

And yes, I believe these compensate reduced productivity and happiness. Actually not only compensate but add more too. Net value is positive. That’s why co-location rules.

So we were doing great, everyone was happy and we were delivering on time on budget and on scope. Except it wasn’t exactly how things really looked like.

First two projects were late. Not much but still. It was expected since these were our first estimates in the team and at that time we decided not to do anything about that yet. Slips were reasonably small, which was a good sign when we talk about our developers’ estimation skills. Nothing to be worried about.

Another issue however appeared to be a real pain in the ass. One of applications got stuck somewhere in the middle of first iteration of tests. It looked like there was always something more important to do. Everyone was doing high-priority things and the application wasn’t touched even with a stick. There was no mechanism which would add an incentive to finish things and not leave even less-important tasks for later.

We also had a problem with our Product Owner. The guy was trying to catch many parallel threads and organize team’s work but unfortunately he was pushing in a bit too many new things. At the same time he was losing some of nice ideas on the way. Before some of them could be implemented guy was coming back from another meeting with a client bringing new, better and higher-priority tasks and the old ones were fading into oblivion. For those of you who can’t wait to ask who this crappy Product Owner was the answer is: yes, it was me.

A general conclusion was we need some more organization not at project level but at team level. Something which would help us finishing things and limit chaos generated by rapidly changing business environment. Specific of our team was we were doing a number of very small projects simultaneously so coordinating these projects was crucial to avoid falling into chaos.

We were about to do first process improvements…

Read the whole story.

You already know how our team looked like and what concerns I had with implementing plain old Scrum. You also know we chose “take this from here and take that from there” kind of approach to running our projects. Our base method was Scrum but we were far, far away from accepting it the orthodox way.

What we finally agreed on within the team can be described in several rules:

1. Planning
For each application at the beginning we were deciding what we want to see there in the next version. We were trying to limit a number of features but didn’t set any limits how long development should take. The longest cycle was something between three and four weeks.

2. Requirements
When we’d known what we wanted to do we were creating user stories and non-functional requirements. Each session took whole team, even when someone wasn’t going to develop that specific application. As it usually happens the scope was being changed as we discussed different aspects of planned work. We were adding (more often) or cutting off (less often) features. We were building a coarse-grained architecture as we discussed non-functional requirements. At the end of the day we had a whiteboard full of stories which were a starting point for development.

3. Tasks
Since user stories were rather big we were splitting them to smaller pieces – development tasks. This was changing view from feature-wise to code-wise. Development tasks were intended as small pieces of work (possibly not bigger than 16-hour long) which were a complete wholes from a developer’s point of view. Ideally a single user story should have several tasks connected to it and single development task should be connected with only one user story or non-functional requirement. It wasn’t a strict rule however and sometimes we had many-to-many relation since specific changes in architecture (single development task) were affecting many usage scenarios (many user stories). Development tasks should make as much sense as possible for developers so they were defined by developers themselves and by those who were going to do the job. Tasks were stored in a system which was used company-wide.

4. Estimation
At the very beginning we had no strict deadlines but we were estimating anyway. There were two goals: learn to estimate better when there aren’t huge consequences for being wrong and getting into a habit of estimating all of planned work. Our estimates were done against developer tasks, not user stories. The main reason why we went this way was that tasks were smaller so estimates naturally were better than they would be if we did them against user stories. A specific, pretty non-agile, thing we were doing with estimation was a rule of estimating each task by a developer who would be doing it. More on this in one of future posts.

5. Measuring progress and work done
Current progress could be verified by checking actual state of tasks connected with a specific app. Nothing fancy here. The thing which was important here was writing down how much time it took to complete the task. When completed each task had two values – estimated time needed to complete the task and time it really took to do it. At the end of the day we knew how much our estimates were flawed. The important thing here was official announcement that no one is going to be punished in any way for poor estimates.

That was pretty much all. No stand-ups since we were all sitting in one room and we discussed issues and work progress whenever someone felt like it. No Scrum Master since, well, we weren’t doing sprints and within specific project things were rather self-organized. A kind of Product Owner emerged, impersonated by me, as we needed a connector between constantly changing business environment and the team working on different projects. You could say we needed one to bring some chaos to our work which would be equally true.

We were going to build a few small projects that way. At the same time we were prepared to improve the way we create our software as soon as notice flaws and find a way to fix them.

Keep an eye on the whole Kanban Story.

So I found myself in this small team, part of a bigger company but working pretty independent of the rest of people here. Kind of start-upish environment. I knew every single person I worked with. Well, actually I’d chosen most of them and hired them here. The team was great (if you guys are reading this: no, it is not a reason to come for a raise) and personally I didn’t feel an urge to strictly control everything. On the other hand some order is always a nice thing.

Initially I gave a lot of thought to project management practices and didn’t come with a solution I was happy with.

I rejected PMP-based heavy-weight process which works for many projects in the organization. We didn’t need all the hassle they bring. At least not at that stage. A natural idea was Scrum which I didn’t like either. Scrum is pretty formalized methodology too and I wanted to avoid formalisms as much as possible. Actually with a lot of R&D work, pretty much prototyping and priorities changing all the time I needed something more flexible.

I didn’t want to be time-boxed since we were planning to work simultaneously on a few independent small projects which would be hard to synchronize if we wanted to put them all in one team-wide sprint. Creating independent sprints for each of projects was a complete overkill since you don’t really need Scrum sprint for a one-and-a-half-person project.

Actually I’d say we were at the point where we were too flexible for agile methods. Now, go burn me in flames for being iconoclast.

After some discussions we collectively agreed we wouldn’t adopt Scrum as a whole but would use some of techniques used there and some other ideas we thought were good. In the next post in the series you’ll find more details how we initially organized our development.

Keep an eye on the whole story.