Jennifer Bedell wrote recently at PMStudent about testers goldplating projects. Definitely an interesting read. And pretty hot discussion under the post too.

I’d say the post is written in defense of scope. Jennifer points that testers should test against the specification only because when they step out of the specs it becomes goldplating. In other words quality assurance should verify only whether a product is consistent with requirements.

That’s utterly wrong.

It might work if we worked with complete and definite specifications. Unfortunately we don’t. And I mean we don’t ever work one of these. They just don’t exist. What we work with is incomplete vague and ambiguous.

And yes, you can deliver software which sticks perfectly to specs and at the same time is unusable piece of crap.

You should actually encourage testers to get out of the box (specifications) and wander free through the application using every weirdest scenario they can think of. Why? Because your beloved users won’t follow specs. They won’t read it. They won’t even care whether there is something called with the name. This is artificial artifact created to make discussion between product manager and developers easier. Users couldn’t care less about specs.

This means they don’t use application in a way which was specified in requirements, user stories or whatever you happen to create. They use the app using all kinds of approaches, even the weirdest ones. You don’t want to face it unprepared. So forget about damn specs when testing and try everything you can think of (and some of that you can’t).

I’ll go even further: forget about test cases too if you happen to have them. OK, forget about them during the first iteration of tests, because you have more than one, don’t you? The reason is exactly the same as above.

And yes, I can imagine some extreme bugs which will be submitted because of this approach. Bugs which would take years to fix and they are so unlikely to appear in real life it would be plain stupid to fix them. This only means you should monitor incoming stream of bugs, hand-pick these few you aren’t going to fix and throw them out.

This isn’t a reason to consciously decrease quality by sticking to specs during testing.

Kanban doesn’t prescribe much – if you follow The Kanban Story you already know that. Kanban Board which is a key tool in Kanban isn’t pre-designed or something. You need to tailor your own. That’s how we did with our Kanban Board.

We decided to start with something simple and then adjust things as we go. We redesigned Kanban Board because it is meant to be changed. But even then it wasn’t the final shape.

When we left the board last time it looked like that.

What was the problem?

On a general level we switched to more frequent deployments. At the beginning we didn’t have any system in production but it has changed. Sort of. Anyway our endpoint was no longer “ready to ship” – we wanted to see new features live.

Before the change we were marking MMFs as “in production” by throwing sticky notes out. The problem was there was no limit for “ready to ship” station, so features could wait there on a huge stack waiting for deployment. Something rather opposite to what we’d like to see.

The other thing which pinched me was documentation. We had a stage for this purpose but it appeared we were documenting after we’d pushed feature into production. This was perfectly fine since we don’t sell boxes with up-to-date documentation inside and it was no problem at all to have documentation updated a couple of days after deployment. The problem was our Kanban board didn’t correspond with this.

After playing with some ideas we came with version 3.0 of our Kanban Board.

What has changed?

The left part hasn’t changed at all. We were happy with it.

The first change was merging “test” and “ready to ship” columns into one under the name of the former. What we got was testing stage which was separated into ongoing and completed phases. When a feature was tested it was ready to ship. We no longer expected documentation to be updated before shipping since we weren’t working like this anyway.

Another thing was adding “live” column which means feature was successfully deployed. I didn’t like the idea of adding another “deployment” station since deployment is very fast in our case.

Documentation was left as the last but one column and at the end “done” station emerged. After all it is such a nice name for a column.

Limits

Redesigned part of the Kanban Board reflected our workflow much better but required also limits adjustments. Instead of rethinking whether we should add 1 here and subtract one there I wiped out all limits and rethought them from the beginning.

Limits of 3 for “todo” and 4 for “development” had worked well so they got their way back to the board.

The next one, and the hard part, was limit for “live” station. Remember our pseudo-iterations? Because of this approach we deploy a few features at once. So far there were two or three in each package. However it happened a couple of times that an emergency feature was added during a pseudo-iteration. Since this kind of feature was meant be included in the same deployment package this made a maximum of 4 MMFs possibly being shipped at once. That’s how “live” stage got its limit.

The same reasoning applied to “test” station. Since it was possible to move 4 sticky notes at once to “live” column, they all had to be taken from the previous one, thus we couldn’t set there anything less than 4. We didn’t want to set anything more either, so the lucky number was exactly this: 4.

“Documentation” got a limit of 2 since it’s often convenient to document 2 corresponding features at the same time.

Looks like we get more and more columns over time. I just wonder whether that’s a good thing.

If you liked the post you may want to read the whole Kanban Story.

Last time I wrote about status quo and how it becomes protected value within companies. I could tell you countless stories of people being (mentally) hurt by status quo. I could tell barely a few of these when status quo was defeated.

How to fight with status quo then?

A short answer is: change rules of the game. Until new status quo emerges everything will be different.

To elaborate a bit more, status quo is painful in terms of lost opportunities. Every time some talented and eager engineer hits the glass ceiling or a poor candidate is promoted over a good one or suboptimal organization is sustained the company loses. It loses in terms of productivity, performance and employee satisfaction. At the end it loses money since at the same cost there could be done more or there could be done equally much but at lower cost.

A good supporting question is: who sees all these problems?

Everyone who tried to improve something but failed because reluctance of people happy with whatever it is today. That would be one group. Another one will be made of few people who are high enough in organizational structure to see how things work, but at the same time have no real power, or interest, to change it.

Another supporting question: can these people introduce change?

No, they don’t. They don’t have enough power. They are either too junior or too new or work too far from the core of the organization. Sometimes they would even try to fight the reality just to learn they have virtually no chance to win. Status quo defenders are numerous and powerful and they prevailed many try-outs like this.

If you came to this point you can basically do two things:

• Change behavior of people who defend status quo. To succeed with this you need to open their eyes first. It may be possible but it doesn’t have to. How to do this? Well, bottom-up approach doesn’t work. If it did their attitude would already be different. What you need is someone with respect. Someone who would coach status quo keepers showing them ways of improvement. Make them aware there are different styles of management. Make them aware how they can improve their leadership. Make them aware how much they can personally gain if they enable changes in their teams. If this approach succeeds game rules will start changing slowly but constantly. Unfortunately this would work only when you have managers who were unaware of the problems. If they were consciously maintaining status quo chances are good your efforts would be ignored.

• Get someone experienced and give her power to change things. It could be one of these peripheral managers but as an insider she would be naturally perceived as an enemy by her colleagues. It’s better to get an outsider, someone who successfully cleaned up a company or two. Hire her and give her enough power to allow her to enforce changes over the current organization. Let the outsider change the rules. If you choose your candidate wisely, you’ll go through a number of clashes, some people will leave, other will be fired but in the end organization will work better. Why? Because every significant change in the company, every leaving, creates opportunities for those who want to improve organization and destroys at least a few glass ceilings. Of course you can rebuild every flawed element you’ve just destroyed but after all one of reasons you have your superhero outsider is to prevent that happening.

As I write this I’m perfectly aware how rare are cases when companies decide to undertake such actions. But every time I hear about another management failure which is triggered by defending status quo (and believe me I hear that a lot) I have the same thought: “Why won’t you, my dear execs, do anything to heal your organization?”

I surely am biased but it happens now and then that I believe I have a few recipes which would instantly improve overall performance, let alone some consistent work on fundamentals. After all management isn’t that hard if you have someone to learn from.

What happens when company grows from 10 to 100 people?

Initially there’s a group of highly motivated and hard working people led by one or a couple of visionaries. Everyone knows each other well. Everyone knows what anyone else is doing at the moment. Then some success happens and organization grows. At the beginning it scales up trouble-free. Somewhere along the way teams emerge. Suddenly company needs a few managers. Who is promoted? What a question. Of course those who were in the pack when employee counter was one-digit.

First hierarchy self-emerges. No one really thinks about this much. After all it’s all about a couple of teams, not full-blown organization. Then the company grows further and by the time it reaches 100 people there are probably at least two levels of management. First managers add new folks to their teams to the point they need middle management to deal with their 30-something people.

Note: at that point there still isn’t much planning when it comes to organizing company structure. It is created in the meantime while people aren’t focusing on their work.

What happens when company grows from 100 to 1000 people?

By the time organization has 100 employees self-emergent structure becomes suboptimal. It is no longer a bunch of people working toward common success. If you don’t hire great candidates only, and let’s face it: you don’t, there are some people on board who just work there and don’t really care for anything beyond their paycheck. There are also few managers who shouldn’t become managers at all but should stick to engineering. To add some spice the company still grows at constant rate.

The bigger it grows the more power management gets. Execs no longer work with line employees most of the time. They work with excel sheets and if they meet someone they are other execs or senior managers at best. Real power is moved one level down – to managers who make hiring decisions, promote employees and deal with all people-related issues. Who are they? Remember this few veterans who were around from the very beginning and become very first managers in the company? Well, now each of them leads one of multi-team departments with close to 100 pairs of hands each.

Sure, there are reorganizations but most likely they happen out of the center of the company. Core remains unchanged. Why? Well, that is damn good question.

A short answer is: because big organizations are great in maintaining status quo. I don’t want to argue whether a few hundred people make a company big (it does not) but somewhere between 100 and 1000 people this attitude appears and it is there for good.

And here’s a long answer.

• Think about management skills of early-managers. Most likely it is their first management job. Most likely they were engineers initially. I’ll be brutally honest: chances are good they doesn’t really suit management job. The problem is they don’t even know that. They can’t. They may even do their best and still suck as managers. If they have grown with the company they may lack just good role-models in management. I could bet my money against their management skills in this situation and, on average, I would win.

• Now, put yourself in shoes of these veterans. They are with the company from the beginning. They career seems to be well-earned. They aren’t aware they may suck at what they do. When they were engineers they had simple verification of their work: test passed, client didn’t complain thus everything was good. With management it isn’t so easy. Their team won’t come to them to say they suck. Hey, you just don’t go to tell such things to your boss. We can even consider managers are aware they suck a bit. And what would they do? Resign to leave a position for someone better? You must be kidding me.

• So what do execs do with this? Pretty much nothing. They’re chewing through their Excel sheets and as far as numbers are fine everything else is too. And if numbers start to stink who would they talk to anyway? Well, managers I guess. They’re disconnected with most of the rest of people for a long time already.

Maintaining status quo is a safe choice for everyone who has enough power to make any important decision in the company. Those who see problems and would like to change something are either somewhere on periphery of organization or very low in hierarchy structure. The former aren’t taken seriously the latter hit the glass ceiling.

What more, existing status quo propels the same behavior all over again. If the company promoted three out of four engineers from early setup to senior management the fourth one pretty much expects the same. And most likely he will get the promotion, no matter whether he was the best candidate or not.

Of course you can find counterexamples. I don’t say every company works that way. I guess when Google hit 500th employee mark they were still nothing like that. I know startup where all 3 co-founders had experience in management so they aren’t likely to hit this reef either. I know companies which will never make it past 50 people so they definitely shouldn’t care about these issues.

Anyway more often than not defending status quo is a problem. I’ve seen it at all stages from few dozens to few thousands of people. And it always looks like decision-makers weren’t aware of the fact or, if they were, like they didn’t care. When company grows to specific size it is just easier that way.

In the next posting I’ll give an idea what can be done to change the situation. Stay tuned.

I have a small task for you. Think about a few people you know and you consider them as great professionals. Don’t limit yourself to any single role – choose anyone who is great no matter if he’s a manager or a developer or a dustman. Got them? Fine.

Now a second step – try to name one attribute which is common for each of them. Something which isn’t, by definition, related to specific role or specific job. Depending on variety of people you’ve chosen this can be pretty hard, but try for a while – there must be something. Got it? Great.

What you’re trying to achieve here is finding a kind of success factor. Something which would differentiate good from great, but at the same time probably not something which would guarantee a mediocre person to become a star. That just isn’t so easy.

What have you chosen?

My choice is: urge to learn.

This is something which constantly pushes us ahead, out of our comfort zone. Even if we err along the way the overall result is positive. As the time passes we get better and better since, well, learning is all about getting better. We grow to the point when someone thinks about us when asked the question from the beginning of this post. We’re not likely to get there though, so chances are good there’s still plenty of room for self-improvement.

Learning can be a part of your job – in this case you should be pretty happy with it. You can also do a job which doesn’t develop you much at the moment, but it is a lame excuse to stop learning. There are tons of great places to get better at whatever you do or learn something completely new. If you stick with whatever you already know you’re heading to side-track.

I have great news for you: if you reading this, odds are you have this urge. If you take time to look for content discussing personal development in context of your domain (I don’t expect many dustmen here really) you’re well ahead of the rest of the pack. You’re here to learn something new. Otherwise why would you spend your time reading this?

If you’ve chosen something else than urge to learn tell me what is your choice and why.

One of reasons why I like Kanban so much is because it doesn’t force you to formalize your process. You don’t need to set strict time-boxing for example. If you want to – fine do it, but if it doesn’t suit you fine no one forces you.

If you happen to work in environment where priorities change very often, and we do work like that, you’re likely to reject time-boxing since this approach doesn’t reflect process you follow. We didn’t want time-boxing and this was one of main reasons we rejected Scrum initially.

Iterations were bad. At least that’s how we thought.

After some time I realized we basically had iterations. Sort of. We didn’t set time constraints like “we’re going to do features which fit 2-week period.” But we started grouping features into releases like “stories A, C, E and F which are top priority at the moment are going into the next release.” It was taking as much time as needed to complete a group of stories so it wasn’t time-boxing really but still a small and (mostly) closed set of work items to do.

Why we started doing that?

• To make releases easier to plan. As I saw sticky notes moving from the left to the right I could estimate when we were going to deploy new set of features in production environment.

• To have more frequent releases. With no real release planning we ended up with not very frequent deployments. At least not frequent enough for me. When we added some planning we set some boundaries for our work and made it easier to deploy more frequently.

• To make version control look less like hell. We don’t use distributed version control so every time we want to release we need a branch in our code repository. If we had a few branches actively used bugs would have to be fixed in each of them, so we’d like to avoid having plenty of active branches. If we had only one branch and we wanted to release only completed features, leaving those under development aside, it would be quite a challenge. Having small feature sets going into development and adding a branch every time we start new set brings an order to version control.

So we ended up having pseudo iterations. Not as strict as in Scrum but still. I can’t say how long the next iteration would take but it most likely won’t take more than 3 sticky notes. I can’t promise I won’t add anything to the scope during the iteration but if it happened I had good reasons to do it (e.g. adjusting the app which would stop working after deployment to take latest case).

Seems like iterations aren’t such a bad thing after all.

Check out the whole Kanban Story.

When you read about Kanban the thing which usually isn’t described in details is what happens with sticky notes which make their way to the right side of the board and are in the last column of your Kanban Board (however you call it).

To be honest I didn’t put much thought in that when we were starting with Kanban. Our sticky notes were just stacking up in ready-to-ship column until we no longer could read them easily. And it was just a matter of time when they were going to come unstuck and fall being trashed by cleaner and forgotten forever.

What we decided to do is to file a sticky note when a feature is actually shipped.

We don’t ship every MMF separately although there are some who do that. We rather look for a complete set of features and ship them in a package. That’s why out “done” column was named “ready to ship” since it is one thing to have some feature ready and completely separated to implement it in production environment. At least it is so in our case.

The key thing for our team is to have feature ready to deploy as soon as possible, not to have it live as soon as possible. It is so because due to a bunch of external dependencies (interoperability) deployment is pretty painful and rather long process which we definitely don’t want to do twice a week.

However when we decide to ship something – there comes everything which is ready at the moment. This is the operation which empties our ready-to-ship column. I take all sticky notes which were in the column and add them to the stack stored in my drawer. After all we need some documentation, don’t we?

Read the whole Kanban Story.

I really liked Scrum versus Kanban session I made along with Piotr during Engineering Academy “Diamond Polishing” (both sites in Polish only). The theme of my part of presentation and the following discussion was the sentence I took from Henrik Kniberg must-read article on Kanban:

“I don’t know, experiment.”

– What kind of columns I should have on Kanban Board?
– I don’t know, experiment. Our team’s Kanban Board looks like that. But don’t take is as a universal schema.

– How many columns should be there?
– I don’t know, experiment. See our board as example but don’t treat it as a bible.

– What limits should I set?
– I don’t know, experiment. Have I shown you our board we came up with? You know, that’s the result of our experiments, yours will be different.

– How big should be the team to make Kanban most effective?
– I don’t know, experiment. There are 5 of us, but your team is different I guess.

– Should we put bugs along with MMFs on Kanban Board?
– I don’t know, experiment. We don’t. Others do. How about you?

– How long should we experiment before Kanban Board is ready?
– I don’t know, experiment. We do it all the time because I’m never 100% happy. If you think yours is perfect than stop. If you change your mind then start again.

If there’s one universal advice applicable basically to every light-weight method it is “I don’t know, experiment.” Light-weight methods leave many things flexible – you can apply them this way or another or don’t apply them at all. This creates a place for experimenting with what works well and what doesn’t.

The less the method prescribes, and Kanban prescribes close to nothing, the more you can, and should, experiment. Especially that little prescription means you need to add some practices to run projects reasonably.

Check out the rest of Kanban Story.

Recently I had a lot of occasions to discuss Kanban with other people, the coolest one being last meeting of Engineering Academy “Diamond Polishing” (for you who speaks Polish there’s video recording available online). One of things which I stressed during these discussions is that Kanban is not enough to manage a software project.

I already shared practices we employ and those we don’t. But it is important and worth stressing: you can’t just base on three simple rules of Kanban (limit WIP, visualize workflow, measure lead time) alone. Without best engineering practices your product would suck even though you rigorously followed the rules. That’s not the problem of Kanban only – the same is with Scrum. Kanban is here just to help you to organize work better. If you do crappy job it’s still going to be crappy, just organized a bit better.

What more, while heavy-weight methods enforce some order because of specifying scope of work up front, using formalized acceptance tests etc, Kanban leaves it all open. In other words doing Kanban wrong way you can do much worse than doing Prince2 wrong way.

We set up a list of practices to avoid the problem. When I think what results we would achieve if we had no continuous build, no unit tests, no knowledge exchange in terms of learning other developers’ code and no coding standards I’m scared. We’d probably land in never-ending loop of dirty-fixing old dirty-fixes to old bugs just to get anything done.

All these practices sound very natural now but, to give one example, I confess that’s my first successful approach to unit testing since I manage software development teams.

So no, don’t treat Kanban as a silver bullet which fixes everything in a second. It’s just the part of the job. The rest isn’t enforced, but you have to figure out right pieces by yourself. Continuous integration and automatic testing are rather mandatory if you care about quality and want to ship often, but there is no universal way which works for everyone.

Read the whole Kanban Story.

If you like the story or hate it or just want to win signed copy of Scott Berkun book Confessions of a Public Speaker leave some feedback here.