Edge of Chaos

Agile Development Blog

Scrum, Lean, Kanban, Visualization, User Experience


Product Backlog: Small Steps vs. Giant Leaps

When reading this Kill Your To-Do List blog post, I thought that managing personal to-do list can be similar to product backlog management. Not in the part that you should totally kill your product backlog, but in the “one thing at a time” part. This is by no means a new thought.  E.g.  Mary Poppendieck was heard saying that product backlog should be eliminated.

So, as in to-do lists, there’s no point in nurturing and moving product backlog items back and forth.  In this case, a lot depends on what is your definition and understanding of product backlog. I’d say backlog is an environment in which a product grows and exists but not a set of components that should be implemented for sure.  Looking further into, what kind of environment is it? Backlog might be a repository of all the slightest shades of ideas that have a very vague chance to be implemented. A chaotic heap. This heap can hardly be called a “backlog” but rather a by-product of brainstorming. OR a product backlog might represent a careful selection of user stories that will be implemented for sure.

Both of these options, as often is the case, have the optimal state somewhere in between. In our production workflow, we’re now using several buffers – the first layer is raw Requests and Ideas (coming from our HelpDesk, or from the PO, or from the team). The second layer is Product Backlog with User Stories (Requests and Ideas are now groomed and converted to User Stories by  Product Owner who decides that some time these will be implemented for sure – based on how many people requested this feature, based on current product development strategy etc.). The third layer is Planned state for User Stories in Kanban board.

Here’s a quick graphical representation of this product backlog upward funnel:
That’s how User Stories lifecycle looks on  Kanban board, from Planned state on:


Backlog is not seen on Kanban board.  When done with their current user stories, developers  pull new user stories from Planned state.

Previously, when we worked with iterations before switching to Kanban, there was no buffer between inception and implementation – so time-boxed releases and iterations have been planned directly from the backlog. With Kanban, the buffering  is done by moving stories to Planned state and prioritizing them.

I’d say that planning with iterations provides less flexibility than planning with Kanban. As you drop user stories to time-boxed iterations, you  commit to implementing all of them within a given period of time. Kanban is way more flexible since user stories can be pulled one-by-one from Planned state and implemented with no time restrictions. I can’t resist citing an analogy here: it’s the same as moving with the smallest possible steps to posture yourself before hitting the ball in tennis. With large steps, you do not have flexibility. With small steps – you’re very agile and flexible to position yourself for the perfect shot.

So, the buffered Planned state in Kanban is like this breaking down into small steps, instead of taking one giant leap and committing to the whole pack of user stories in iteration.

That’s the way it goes for us. You’re better off moving by small steps, taking it one-by-one (this brings us back to the inspiration blog post reference in the beginning :) than with giant leaps.

Agile Conferences: Look To No Epiphany

If we think about conferences in general, the traditional understanding is: people come together to share their knowledge, to learn, to discuss, to network etc.  Some people expect that if they attend a conference they for sure must learn something totally new, something that will change the way they work or even their lives.  Some people come to see who’s out there, to network and to have some fun. In a nutshell, as many people as many reasons to attend conferences :)


I tend to think that with all the  information we’re consuming, it’s very hard to come up with something totally new to a thinking and knowledgeable audience. If you’re engaged in agile community, and if you’re a thinking person, you thrive in the blogosphere and you practice agile  – it’s hardly that something will be totally new to you (“totally” is the keyword).

Recently we attended Agile Central Europe conference in Krakow. I’d say that my #1 enjoyment about this event was live cross-twittering. Broadcasting Agile CE to the Twittersphere has really been fun. I liked tweets by Andy Brandt, Marc Loeffler (aka scrumphony), Pawel Brodzinski and Robert Dempsey (for the two latter, it’s not only tweets, but their presentations that I enjoyed) .  As opposed to most attendees,  I didn’t very much like the closing show by Gwyn Morfey and Laurie Young. The guys have done a great show, but it was more about dramatic presentation of what’s going on in any dynamic agile team :) I’ve seen a bit of those “paper sword fights” :)

After attending Agile 2009 in Chicago, I’ve really got a little bit skeptical on the conferences overall because what I’ve seen was people talking about simple truths but with such an air as if they were uttering epiphanies. So, when going to Agile CE I wasn’t expecting epiphanies. It was more about going out there with our team, watching people and taking every opportunity to enjoy everything that comes up on the way  (including live jazz night in Krakow).

This approach worked better than huge expectations. Strangely, this small cosy conference has become an unexpected source of inspiration.  In a sense,  that it’s not always you have to come up with an excellent new topic or idea no one else knows about. The main thing about conferences is confidence and freedom to express yourself, share your personal experience and absorb experience of others. Somehow someone will find it useful. There’s no need to be afraid to appear too simple. People will listen and admire  even if this is your first experience as a speaker.

And.. it’s great that there’re many more agile conferences to come :)

Going Agile From Within

“You can’t apply Scrum without an external expert”
“You can’t apply Scrum without a Certified Scrum Master”
“You can’t apply Scrum without XYZ”

You can replace Scrum with any other buzzword. Is it really necessary to have an agile coach on board to join agile camp? Is it really required to send someone to CSM courses and delegate Scrum adoption to this brave knight in a shiny armor? I believe it is not the only way to go, and there are 2 reasons that support my vision:

  1. I did not attend any courses, conferences and other events, but I did learn agile and became an agile expert.
  2. We implemented agile process in our company without any external help.

To me it looked (and still looks) natural to improve development process internally. It was an ad-hoc agile adoption  in our company. There was no defined structure, but on-going learning. People have been reading books about agile development which I recommended. I’ve been making some presentations about agile history, main processes and so on. People have been reading articles and discussing new ideas. It worked out, finally. Even with such an unstructured approach you are able to set up an agile company. But are there better ways?

Agile Coaches

What’s wrong with external coach/trainer/consultant? Nothing, actually. You pay someone to teach you. You pay someone to inject agile culture into your company. You pay someone to get it faster.


The problem is that this process is so slooow. It is inevitably slow, because all the mindset changes are slow, and you can’t speed them up greatly. My estimate is about 1 year as a minimum (no proof, sorry, just personal experience). You can’t absorb all the agile spirit in a shorter period of time (maybe some geniuses can, but they don’t need coaches anyway). I do believe that a good agile coach can speed up agile adoption, but not as greatly as often advertised.

OK, so changes are slow. It is absolutely required to manage the change over a long period of time. You can’t setup something, run it for a couple of iterations and leave. There is a high chance that development team will degrade and slip back to old-and-oh-so-known practices quite fast. It leads to several possible conclusions:

  1. If you hire agile coach, it is better to have about 1 year contract.
  2. If you hire agile coach for just 3-6 months, setup internal learning/change process as fast as possible.

The main idea of agile adoption is a paradigm shift. People should change their habits, rituals, working patterns and activities. It is SO hard! Some people just can’t accept it and leave the company. The goal of agile adoption is to change mindset of as many people as possible and let rock-hard minority go.

So why I personally don’t like the idea to hire someone who will teach us agile? It immediately puts our intelligence to question. Are we really not able to learn ourselves? Can’t we read some books, discuss them and try, for example, Scrum in a single dev. team? If we want to hire someone, to me it looks like we’ve already given up and can’t do anything cool without external help. It looks like we got exhausted and now need a power recharge. It is similar to an external CEO hired in a desperate attempt to save company.

Don’t get me wrong. Agile coach can help greatly. But I don’t buy the paramount idea that development team can’t go agile without external help.

Problems and Solutions

I like challenges and like to solve problems without external help. What I like is a full team involvement and participation. It is so cool when people discuss problems and generate solutions. If I ever hire an external consultant, it will be a person who will teach how to solve problems. Problem solving is the MOST IMPORTANT skill (can I stress it more?) for any good developer/tester/designer/you-name-it.

Here I see a major flaw of Scrum as a methodology (so far?). It does provide a framework, but it says nothing about problem solving. OK, you should have a retrospective meeting every other week. You should identify problems, generate ideas and write action items. You should execute action items and retrospect in 2 weeks. Sounds good. But HOW to identify problems? HOW to generate ideas? Scrum says nothing about that, but I believe this should be the core of any agile process.

That is why I pay more and more attention to lean and other problem solving techniques like 5 Whys, TRIZ, etc.

Knowledge From Within

There are various ways to ignite the team and solve problems internally, but you can’t solve problems effectively without knowledge. Study Groups could be the most promising way to educate people. To be honest, we did not try it. As I mentioned, we did not have any structural approach so far, but intuitively came to something similar to Study Groups.

Study Group is a small group of people (4-6) that have cadence sessions e.g. weekly. There’s no distinct leader, they rotate with every session. People should be really interested in the domain. For example, if you have Study Group to learn TDD, all the members of the group should be passionate about TDD learning and actively participate in discussions.

Why I think Study Group should work? First, there’s no Boss inside. People can freely discuss various problems without pretending that they know everything. Second, there is a clear focus. You should not form a group with a goal to solve all the development problems, instead it is better to form groups to study UX, study TDD, study Scrum, study Lean. Once again, Study Group is not a problem solving technique, but it helps to educate people. And it is absolutely clear that educated people will generate better solutions faster.

Here is the nice summary about Study Group. And here is the list of other learning methods that every agile team should pay attention to.


Agile Project Management Software

for Scrum or Kanban

Take a Tour!