Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: change

Why We Fail to Change

I’d love to get a beer each time I hear a story about management imposing a change on teams and facing strong resistance. Literally every time I’d fancy one, I’d be like, “Hey, tell me your agile transformation story.”

One common excuse is that people don’t like the change. That is surprising given how adaptable humankind has proven to be. I’d rather subscribe to the idea that people don’t mind the change; they don’t like being changed.

Unfortunately, being changed part is the story of oh so many improvement initiatives. And Agile implementations, obviously, are among the most prominent examples of these change programs, of course.

So, how is it really with responding to changes?

First, it really helps to understand typical patterns of introducing change. The model I find very relevant in this context is Virginia Satir’s Change Model. Let me walk you through it.

We start with the existing status quo, which translates to a performance level. We then introduce a new concept, which we call a foreign element.

Then we observe an expected improvement, and they lived happily ever after and all. Well, not really. In fact, whenever I draw that part of the model and ask what happens next, people intuitively give pretty good answers.

After introducing a change, performance drops.

It is kind of obvious. We need time to learn how to handle a new tool, practice, or method. Eventually, we become increasingly proficient at whatever that is, and we start to see the results of the promised improvements. Finally, we internalize the change, and the cycle is finished.

Because of its shape, the curve is called a J-curve.

It is an idealized picture, though. In reality, it is never such a nice curve.

What we really see is something much bumpier. It isn’t a straight line to start with, when we maintain the old status quo. Then, it gets way more all over the place when we start messing with stuff. It’s not only that the rough average deteriorates, but also that the worst-case scenario gets worse, and by much more.

It’s pretty much chaos. In fact, that’s exactly how this phase is called in Virginia Satir’s original model.

An interesting observation we can make is that the phase called resistance is a short one that occurs just after introducing a foreign element. Does it mean that we should expect resistance against the change to be short-lived?

Yes and no. Yes, if we consider only the “I’m not even going to try that new crap” type of resistance. This kind of reaction is typically driven by a lack of understanding of why the whole change was proposed in the first place. There is, however, a whole range of behaviors that happen later in the process that we would commonly call resistance as well.

Some people aren’t ready to see even a temporary drop in performance. Once they face it, they suggest a retreat to the old status quo. When facing a stressful situation, many people instinctively go back to what they know best. Unsurprisingly, the old way of doing things is precisely what they know best.

There are also those who are impatient and not willing to give people enough time to learn the ropes. Curiously enough, the last group often includes managers who initially funded the change.

In either case, the result is the same in the end. More resistance.

Inevitably, we reach a pivotal moment. We’ve been through the bumpy ride for quite some time already, and yet we haven’t gotten better. In fact, we’ve gotten worse. Not only that. We’ve gotten worse and less predictable. The whole change doesn’t seem like such a good idea after all.

So what do we do?

Of course, we reverse the change and go back to the old status quo. Oh, and we fire or at least demote that bastard who tricked us into starting the whole thing.

One interesting caveat of the whole process is that a change is not always simply reversible. When we change specific behaviors and yet don’t get the expected outcomes, reverting to the old status quo may be difficult, if not impossible.

For the sake of the discussion, let’s assume we are lucky and the change can be reversed. We are back to old ways of doing things, and we simply wasted some time trying something new. Oh, and we built a stronger case for resisting the next change. We petrified the existing situation just a little bit more.

One reason changes are often reverted is the perceived risk associated with them.

A pretty good proxy for perceived risk is predictability. Typically, the more unpredictable a team or process is, the riskier it is considered. In this case, the important thing that comes along with a foreign factor is how much predictability changes. Not only does performance drop, but it also becomes much less predictable.

While the former alone might have been bearable, the combination of both factors contributes to the perception that the change was wrong in the first place.

There is another dimension that is particularly interesting here. It is the scale of change. How much we change the existing environment: team, process, practices, etc.

We can imagine a series of small improvements, each modifying the context only slightly. The entire series of them leads to a similar outcome as one big change rolled out at once.

We can describe one approach as evolutionary and the other as revolutionary. If we draw inspiration from Lean, we’d call them Kaizen and Kaikaku, respectively.

Fundamentally, the J-curve in both approaches would be shaped the same. The big difference is the scale. The revolutionary change means one big leap and rolling out all the new stuff simultaneously. This means a single big J-curve.

The evolutionary approach introduces a lot of tiny J-curves one after the other. In fact, it is possible to have a few changes run concurrently, but let’s not complicate the picture any more.

What are the implications?

Let’s go back to the scale of the risk we undertake. With Kaikaku, the unpredictability we introduce is much higher than what we’ve seen in the late status quo.

Kaizen, on the other hand, typically suggests changes that are small enough to avoid destabilizing the system nearly as much. It is pretty likely that unpredictability introduced by each of the small changes will be almost invisible, given that we don’t deal with a fully predictable process anyway.

The risks we take with an evolutionary approach are much more acceptable than those we face when rolling out a single, large change.

That’s not all, though.

Another consideration is the duration of the destabilization. In other words, the cycle time of change.

A big change, naturally, has a much longer cycle time, as it requires people to internalize many more new behaviors, practices, techniques, etc. It means that exposure to the risks is longer. Given that the risks are also more significant, it raises the odds that the change will be reverted before we see its positive results.

With small changes, cycle time is shorter and so is exposure to risks. Again, not only are the risks much smaller, but they are also mitigated much faster.

One last thing worth mentioning here is that, so far, we optimistically assumed that all the proposed improvements have a positive outcome. That’s not true.

With the evolutionary approach, even if some of the changes don’t yield expected results, we still gain from introducing others. With a revolutionary approach, each part that doesn’t work simply increases the likelihood of reverting the whole thing altogether.

It is not to say that Kaizen is always superior to Kaikaku. Both evolutionary and revolutionary approaches have their place. We need Stuart Kauffman’s Fitness Landscape to explain that.

Imagine a landscape that roughly indicates how fit for purpose your organization is. It should simply translate to factors such as productivity, responsiveness to the changing business environment, etc. The higher you are, the better.

The simplest and safest way to climb up is to take small steps uphill.

While the approach works very well, eventually we reach a local peak. If we continue our small steps in any direction, it would result in lower fitness for purpose. Simply said, we wouldn’t perform as well as we did at the peak.

If we look only at the closest terrain, we might as well say that we’re already perfect and there’s no need to go further.

Obviously, that would be naive. Or stupid. Or both.

The solution becomes apparent when we take a broader view. If we moved to the slope of another hill, we could eventually reach even a better position.

That’s exactly when we need a big jump. It doesn’t have to automatically land us in a better situation than the one we were initially in. The opposite would often be the case. What is important, though, is that we land on the hill that is higher. That translates to bigger potential for improvement.

Once there, we can retreat back to the good old strategy of small steps that allow us to climb up. Eventually, we reach the peak that is higher than the previous one. Then we can repeat the cycle by looking for even a bigger hill.

Similarly, to the case of J-curves, the picture here is idealistic, suggesting that each change, whether small or large, is considered successful. In reality, it is more the result of experimentation. Some of the changes would work, while others would not.

As you might have guessed, small steps here represent the evolutionary approach or Kaizen. A big jump is equivalent to revolutionary change or Kaikaku. Depending on the context, one or the other will be more useful.

In fact, there are situations when one of the strategies will be basically useless. That’s why introducing change without understanding the current context is simply begging for failure.

One more implication of the picture is that, given the lack of any other guidance, the evolutionary approach is both less risky and more likely to succeed. That’s why I prefer to start with Kaizen when I’m unsure about the context within which I’m operating.

One last remark on Fitness Landscape. What you’ve seen here is a heavily oversimplified view. In reality fitness landscape wouldn’t be two-dimensional. Stuart Kauffman discussed it as a three-dimensional model, although I tend to think of it as a multi-dimensional one.

It means that each change can improve our situation in some dimensions and have an opposite result in others (think: we’ve improved quality, but we are slower). We will have different combinations of effects in different dimensions—some more desirable and some less.

If that wasn’t enough, the entire landscape is dynamic and continually changes over time. In other words, even after reaching a local optimum, we will need further continuous improvements simply to maintain our fitness for purpose. The peak will be moving over time.

I know the post got long by now (thanks for bearing with me that far, by the way). This, however, is only a starting point for discussing why introducing the change often triggers resistance.

I believe it provides a pretty good explanation of why so many improvement initiatives fail. This is also one of my answers to the question of why many Agile adoptions are doomed to fail from day one.

Attempting to significantly change an organization without understanding its underlying mechanisms is simply begging for frustration and failure.

Finally, understanding the change models will influence the choice of the methods and tools we’d use to drive our change programs.

And if you chose a journey of a change agent, good luck! It can be as challenging as it can be rewarding.

February 24, 2015
Kanban: The Culture Challenge
My focus for past months drifted a bit away from the core of Kanban. I either focused on more enterprisey applications of Kanban in the context of portfolio management or on what’s blood of every company, which is organizational culture. Every year though I use Kanban Leadership Retreat as a perfect occasion to reset my focus a bit. It wasn’t different this year.

Those of you familiar with the method please forgive some of the basics in the post.

The classic definition of Kanban Method is as follows.

Principles
- Start with what you do now
- Agree to pursue incremental, evolutionary change
- Initially, respect current roles, responsibilities and job titles
- Encourage acts of leadership at all levels
Practices
- Visualize
- Limit Work in Progress
- Manage flow
- Make policies explicit
- Implement feedback loops
- Improve collaboratively, evolve experimentally
A side note: a super-common observation is that teams would understand and know the practices but would be almost completely ignorant of the principles. This is a pattern that leads to very shallow implementations that don’t yield sustainable improvements and typically stop at just better work management.

Another perspective we may use to define Kanban is through its values. The approach was proposed by Mike Burrows. What Mike achieved was translating the original principles and practices to more generic values.

The end result is a following list.

Kanban Values
- Understanding
- Agreement
- Respect
- Leadership
- Flow
- Customer Focus
- Transparency
- Balance
- Collaboration
Since the values originated in the principles and practices there’s also an interesting exercise you can do to map one to the other.

The important part of this perspective of looking at Kanban is that it describes what values should be embraced by an organization so that Kanban implementation will have deep and lasting impact. In other words if an organization doesn’t embrace for example transparency or respect I would expect resistance during the implementation, rather ephemeral improvements and very limited sustainability.

Now, let me share yet another perspective of describing Kanban, which is Kanban agendas. Just to tease you there are three agendas: sustainability, service orientation and survivability. One nice thing is that the agendas nicely fit the values. Each of the agendas covers a few values.

Sustainability
- Transparency
- Balance
- Collaboration
Service orientation
- Customer focus
- Flow
- Leadership
Survivability
- Understanding
- Agreement
- Respect
Now we have a frame for further discussion (and some of Kanban 101 in a pill too).

Why I would bring this up, you may ask. One session that I attended at Kanban Leadership Retreat was about reintroducing an idea of maturity of Kanban implementations in the context of values. The workshop and the exercise we run there is a topic for another story. The important bit in this context is that Mike, who unsurprisingly run the session, decided to put Understanding, Agreement and Respect aside for the purpose of the exercise.

We may look at it from at least a couple angles. We may say that Understanding, Agreement and Respect, since they all were derived from principles and not practices are much more difficult to assess than the rest.

We may point that they are some sort of prerequisites for starting with the whole rest and thus we base on an assumption that these values are already in place.

Both of these points of view are, in fact, valid. I see a big problem here though.

First, this is a bit like saying that Understanding, Agreement and Respect are second-class citizens in this picture. The whole focus goes to the other six values. Now, let me remind one thing. The second-class values are derived from principles not practices. In other words it means petrifying the situation we have, where we discuss practices all the time and principles are relatively ignored.

Second, Understanding, Agreement and Respect all belong to survivability agenda, which puts that very agenda at risk. What does it mean?

If we get service orientation right this translates to doing things right and doing the right thing (at least as far as Kanban covers that part). If we get sustainability right it means that the evolutionary change is feasible. The problem is that without survivability it simply won’t last. We’ll see a pattern that is pretty common across Agile and Lean adoptions. Promising results and early success that is followed by systematic reversal of the change.

Third, there’s one of my recent pet peeves, which is organizational culture. Obviously the culture relates to all the values by definition. However, Understanding, Agreement and Respect summarize the most common missing bits of culture. Also, these bits are least related to specific solutions we have in our toolboxes which means it is much more difficult to influence the change in these areas than it is in the rest.

Finally, the assumption that we have Understanding, Agreement and Respect in place before we start with Kanban is simply not true in my experience. We wish it was, but that’s not what I see. Sorry. It is a common case with pretty much any method that reaches a specific level of maturity by the way.

It all boils down to the challenge I teased in the title of the post. The challenge is to think about methods that aim to change or improve how we work from a perspective of organizational culture. A starting point would be answering a few questions.
- Do we understand the existing culture of an organization?
- Is the existing organizational culture well-suited to support the change we want to introduce?
- Which elements (behaviors, values, beliefs) of the culture are missing?
- How can we influence the culture so that it evolves toward the expected state?
Before we can answer these questions in a meaningful way introducing a major change is simply gambling. And the odds are against us. Bad news is that in majority of cases the answer for the very first question would be negative and the further we get the sadder the answers would be.

A good thing is that, at least as long as it comes to Kanban, we advance our thinking toward better understanding of what it takes to make the change survive. It should help to shift the perception of Kanban from a simple, light-weight tool that can help you with organizing work in one’s team toward deep and sophisticated model that requires understanding of quite a lot of related concepts.

A word of warning: don’t expect the end results of the latter if you treat Kanban as a former.
June 27, 2014
Don’t Ask For Permission

“It’s easier to ask forgiveness than it is to get permission.”

~ Grace Hopper

As a leader of more than a hundred people I often get asked questions that I don’t really know how to answer. Well, I probably could answer pretty easily, although I don’t think “who, the hell, even asks such questions” or “maybe I could come up with some random piece of advice if you really need one” are really the type of answers they are looking for.

On such occasions my default answer is Grace Hopper’s famous quotation.

Don’t get me wrong, I’m not a fan of total anarchy. I do appreciate some order and asking for permission is an integral part of most of orders I know, if not all of them. However, when in doubt just take the advice from Grace Hopper.

You may wonder whether this approach backfires on me sometimes. Oh yes, it does. I guarantee you this. Not very often, but pretty regularly. On such occasions, for a brief moment I wish that guy had asked what to do and had not simply done as he liked. But then I realize how much of a bottleneck I’d be with this attitude.

Heck, not only would I be a bottleneck but also I’d restrain many of the great initiatives my teams pursue. I would tell them over and over again how much they’re begging for failure. Or even better – I’d keep them from failing. Except, eventually, they don’t fail. Damn those guys, they just don’t want to fail even though I predicted that.

Actually, even when they fail, it is still better. After all, a failure is the best teacher and, as a bonus, I can use my clairvoyant hat: “Told you, but you wouldn’t listen.”

When you think about it, the worst thing which can happen is that you might need to explain to a few very important guys why your team did what they did. And believe me, it doesn’t happen very often. It’s a pretty low price for all the great initiatives people pursue, the results they achieve, and the culture you all help to create.

On a side note: when we are on the subject of culture, it probably is a cultural thing, but I find it interesting that we actually need to encourage people to go beyond hierarchies, procedures and rules. Otherwise many of them are naturally inclined to preserve the status quo.

Status quo is likely nothing you’d like to preserve.

So next time you have any doubts, just do the goddamn thing and ask for forgiveness. If you even need to do this after the fact, that is.

Yes, I am well aware that quite a bunch of people from my team are going to read it.

Yes, I know that some of them will take the advice to heart.

Yes, I am pretty sure that they will use it in a way that (on occasions) will kick me in my butt. Hard.

And yes, I am still happy with that. This is a tiny price for what I get in exchange.

After all, if your butt isn’t kicked at all, you’re likely failing as a leader.

September 11, 2012
Kanban and Behavioral Change
One of my favorite and yet most surprising things I learned about Kanban over the years is how it steers change of behavior among mature teams. It shouldn’t be a surprise that at Kanban Leadership Retreat (#klrat) I ended up facilitating a session covering this area.

Those of you familiar with #klrat format would understand me when I say I didn’t have any specific expected outcome of the session. I wanted to start with exchanging stories and see how it goes. Maybe we would be able to observe some patterns of behavioral changes steered by Kanban and learn from that.

Fast forward to what we ended up with. For me it is still work in progress, so will see more on the subject soon. Anyway I pushed my thinking forward in terms of how we can stimulate our teams to improve.

One thing you instantly notice on the picture with the session summary (click to enlarge) is that there despite the fact we were gathering unrelated stories we started building a chain of dependencies. Another observation is how frequently visualization pops up in different examples.

What I believe we will be able to build is sort of a graph showing what kind of behavioral changes can be influenced or even incentivized with adopting specific practices. What more, I don’t want to keep it purely about Kanban. Although at #klrat Kanban context was set by design I’m pretty sure we can, and should, go beyond this context.

A few highlight from the session, basing on stories we’ve shared:
- Visualization combined with WIP limits and daily meetings around the board improve general team-wide knowledge about what’s happening. In short term this influence how people deal everyday tasks, encouraging them to get involved in work done by others, thus removing personal queues. As a result it pulls people toward generalization as they’re involved in many different tasks.
- Visualization and measuring flow improves understanding of work. It makes people to focus on pain points and incentivize them to improve problematic areas. As a result a team takes more responsibility for how the work is done.
- Rich visualization along with slack available to people results in better decisions and better use of slack time. It bases on a notion that rich visualization derives more meaningful data so whenever people decide what to do, especially when they aren’t constrained, e.g. when they’re using slack, improves the quality or potential outcome of these decisions. The final effect is building team’s collective intelligence both in terms of what they do and how they do it.
- Making visualization fun fuels viral adoption of the method. It bases on a fact that people like having fun with tools they use. More fun means more people trying to find out what this cool thing is and how to use it. Eventually you get more people willing to introduce the method and better attitude toward the adoption.
- Measuring flow (again) and understanding and visualizing (again) the nature of work can have impact in a multiple ways: creating incentive to change, building trust to a team and getting rid of 100% utilization. A simple fact that we were able to address so many effects to improved understanding how we work is a strong indicator that we do have problems with that. We might be onto something here.
- Avoiding 100% utilization and slack time, which is generated this way, may be a tool to build leadership among the team (people are free to make decisions on what’s being done) and at the same time can improve fun factor (people can choose to work on fun stuff). In both cases we strengthen our teams and develop people.
By the way: if you add a real story to each of these highlights you may imagine the experience we exposed ourselves to.

In retrospect, one thing that is definitely worth stressing is how little we seem to know about nature of our work. Actually if you think about it, Kanban deals with this issue in a very comprehensive way.

Visualization vastly improves information availability so we know better what is happening. Explicit policies force us to define, or agree on, the way we do work. Without explicit discussions on that we often believe we know how exactly how the work is done even when it’s clearly not true. Then we have flow management with a focus on measures that can change our perception of work highly. It’s a common situation when, being an outsider basing on a handful of simple measures, you can surprise a team showing them specifics of their work.

If that wasn’t enough we get WIP limits that steer changes in the nature of work and give us an important lesson about nature of work in general.

Anyway, leaving tools aside the lesson is to invest more effort to understanding how we work. It will pay off.
June 23, 2012
Implementing Change

The other day I was asked to discuss how we can improve the way one of our software development teams works. Well, actually it was rather something like “Pawel, help us to implement Kanban” but, as it soon appeared, it wasn’t that simple.

A typical discussion about implementing Kanban

Me: So where do we start?

Colleague: Um, I’m not really sure if Kanban is really for us. Convince me.

Me: I don’t want to. If something doesn’t suit your team I’ll be the last person to convince you to implement it.

Colleague: So where do we start?

Me: Maybe with problems you and the team have. I guess there are some otherwise we wouldn’t be talking now.

It isn’t about applying recipes

The discussion changed its course. We immediately switched from discussing Kanban to talking about issues and looking for a solution which would be suitable in each and every individual case. If one of problems is people don’t want to have yet another place to do task management, and they can’t abandon either of current systems, introducing Kanban board may not be as great idea as it initially appears.

If you start discussion with the conclusion already fixed in your head you will not only miss opportunities to improve but you also risk applying the wrong cure and making the situation worse.

It is OK if you just don’t know

A couple of times through the discussion I came up to the point where I had no idea what the right solution might be. And this is perfectly OK. It’s not about playing knowledgeable person. It’s about giving the good advice or not giving any advice at all.

What more, admitting that you don’t know the answer is just a starting point for digging deeper. Each of these moments triggered some changes in our analysis. If we can’t go further here, maybe we should try there. Let’s stop talking about techniques which may or may not work and make a fast-paced Q&A session about potential issues the team may face. Or maybe let’s do mental walkthrough of processes the team covers.

As it appeared each time we admitted that we don’t know helped us with coming up with a reasonable conclusions at the very end.

Adjust tools for people, not the other way around

When you know some method or approach and it works fine for you, you are always tempted to apply it in other environments too. The problem is other environment means other people. As a result your approach may not be so great anymore.

But who said you can’t change the approach? Are methods we use some kind of dogma? Actually choosing a subset of techniques or practices from any given methodology is usually better than not using them at all. And if you choose wisely even a couple of small changes may yield significant improvements. So yes, do adjust methods before applying them.

That doesn’t mean people shouldn’t change ever. Of course they should. But motivation to change should be intrinsic and not enforced from outside, i.e. because manager told so.

A funny thing is that with this approach you can end with similar conclusion to the one you started with. The difference is now you are more likely to succeed as, even though you aim at the same target, you will choose different way to get there.

And in case you were curious, yes, we eventually came back to Kanban.

September 1, 2010
Choose Your Battles

Organizational changes are hard. The bigger the company is the stronger it defends its status quo. Humans wearing their employee hats aren’t so much different from those wearing their user hats – they like what they know, thus they don’t like changes. But there’s often someone who isn’t happy with current state.

So you are the one. You aren’t happy with the way your company works. You know what to change. You are even willing to spend significant amount of time and effort to implement The Change. You visualize the new, better, version 2.0 of your organization which will be there once you’re done. And then you rush to convince everyone to subscribe to your vision and fight with those who reject to follow you.

Stop.

That’s an easy way to lose, become frustrated, get fired, struggle to find another job and die in misery. Oh, I might have exaggerated with the last one a bit.

Every organization, even a small one, has its status quo defenders. If you want The Change you, along with your supporters, are likely outnumbered. Trying to fight every single battle will make your group non-existent, which I guess isn’t the best tactic under the sun.

I’m not saying you should sit there silently waiting for the miracle to come. Try to drop few ideas and observe how people react. It doesn’t take much of perception skills to notice who can support your ideas, who will fight you to the last breath and who doesn’t give a damn.

You will quickly notice that tiny group of your supporters and crowd of opponents. But then you at least know your situation. And you are able to choose your battles in a way which maximizes your outcome. You quickly learn which discussion can be ignored since they aren’t important. You become aware when discussion turns into flame war and it doesn’t make any sense to continue it. And finally you become sensitive to those small signals of support from people whose opinions you care about.

You learn to choose your battles.

If you choose them wisely you win more often. Way more often. And somehow people tend to care about those with a good track record.

Does it mean you should start a discussion only if chances are good for you to win? No. Sometimes you enter battleground being aware you’ll likely lose. But don’t make it a rule. If there are poker players, who never let it go, they are broke. But at the same time they play, and lose, crappy hands from time to time. That’s just cost of learning.

If you followed the article you will enter the battlefield at least knowing who you will have to face. You will be prepared. Folks on the other side probably will not. Oh, unless they read that too, but it is unlikely. Why? Because people don’t listen, don’t read and don’t learn, remember?

June 21, 2010
The Kanban Story: Implementation of Kanban

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.

November 16, 2009