They just want to make sure they don’t waste any water.

We’ve been doing Scrum and 2 week iterations for almost a year now. We win some/we lose some…it’s really been no big deal. Overall our PO’s pretty satisfied.

We are going to try Kanban though still because we feel like things are getting a little stale. Sometimes it just depends on the nature of work that we’re doing and how it splits up.

In general, I think the idea of imposing any of these imaginary constraints is a powerful exercise. Whether it be WIP limits, time boxes, forcing yourself to write a failing test before you write production code, forcing yourself to pair up with another programmer or tester. Just keep an eye on the bigger picture and cycle through these ideas often enough to figure out where and when they fit. And while you’re at it, try to invent some of your own and share them with the world.

I feel that going into something new thinking it will be a cure for what isn’t working will only be a temporary feeling. The “Real Cure” will come from building trust and skill on the team as you continue to frequently deliver value and tune your team’s methodology. It may be that those are just side effects of switching from one cloud to the next, and maybe even back again.

Retrospectives: I recommend they schedule reoccurring retrospectives since courage and communication is the most important thing we do. It also lets us focus on the positive and the things we need to adapt/improve on. I recommend having a retro kanban board that should be reviewed during the retro’s. This doesn’t mean you can’t also trigger (signal) a retro in addition to your regularly scheduled one. Lets say we have a retro every 2 weeks. During those two weeks, if 3 new retro cards hit the new queue on the retro kanban board, then it’s time to have a meeting – don’t wait until the cadence meeting.

Backlog Management: I do recommend that backlog management become triggered. It’s a pull situation, if we have constraints downstream; there is no point in honing the backlog. That doesn’t replace regularly schedule meetings with your customer – that should also be on a cadence. Again this vary’s on the size of shop and customer proximity.

Show & Tells: I recommend these are triggered. What is the right amount of software to demo, some iterations may have 20 things to show and the next 5. My experience has led me to believe that once people see 5 things demo (or no more things than I can see in 1 hour), they lose interest, as most meetings over an hour do. So, I would rather trigger this and have the meeting when necessary to keep the goal of the meeting at the right quality level. Another approach is to have one when a feature set is complete.

So, if you tried my recommendations, the iteration begin & end happens on the day we do a scheduled retro, say every 2 weeks. I guess my real view is that “an iteration” as just another trigger, time is the trigger.

Here’s a quick story of my experience. I originally blogged this experience at http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/

My team were suffering from repeated failed iterations for the reasons you describe. PO wanted higher productivity. I (as ScrumMaster) wanted to stabilise velocity. Pressure. Tension. Low satisfaction all round.

Moving to Kanban resolved the issue. Or did it just hide the issue? I believe it resolved it for the following reasons. Satisfaction increased all round, including the Product Owner. The team started delivering what the PO wanted in a time-scale he was happy with. I believe that a significant cause of this was that removing the time-box removed the cause of the tension, and enabled the PO to become part of the team.

Does this make time-boxes bad? No. But we found an alternative means to improve.

Karl

My post (and feel free to weigh in on the debate):

http://tinyurl.com/lcr3xl

Love your blog name, BTW. Named for the ship, or the original Kzinti device?

I think that you´re missing the “order point” in this Kanban implementation that you describe. In manufacturing, an order point is an inventory level that triggers a process to order new materials. Here, as we pull items from the backlog to be processed, the backlog will diminish until the number of items remaining drops below the order point (2 user stories). When this happens, a notice goes out to the responsible parties to organize the next planning meeting. This “resupply” process should include a retrospective and everything that provides a rhythm.

In the kanban implementation that I´m helping to implement here in the company, whenever we put new itens in the initial queue (ie. “the backlog”, limited to 8 user stories) if there isn´t already a “retrospective” story in this queue we add one at the first empty space. This way, we always do a restrospective after some time. We just don´t do it after a fixed time (ie. one week), “interrupting” the development. Also it´s not always at the same day and with the same people of the planning meeting (ie. the meeting that puts more itens in the first queue), depending on what problems we faced and how we want to tackle them.

It may be important to note that, keeping this rules, when everyting flows smoothily, we have a planning and retrospective meeting exactly on the same day and with every member of the team in both meetings after a “2 week sprint”. The diference is that when we have technical problems or the business priorities change, the meetings are “automatically” rescheduled or the work reprioritized without anyone having to scream “Abort the Sprint!”. Our flow, velocity and impediments are also much more visible to everybody, as delays are visible daily, detailed by backlog item, not only at iteration boundaries.

I still think that Scrum/XP deliver a good set of product management tools and they shouldn’t be thrown away that fast.

I see Kanban as a good way to organize the work, but I still think that estimating the work and having a backlog as necessary in my current environment.

On my past commission we (…well ok, it was me) started scrum the guerilla way. Not much was agile at this place. But after some time we all stood by the whiteboard. One of the problem we had was that we have this SLA-agreement with the customer. The contract we worked under made sprints not working very naturaly.

So, it was the stiff context that forced us to switch to Kanban.

A good thing with Kanban was that we could answer to the SLA more natural way. But like you write [Ron], I got the bad feeling of a never-ending flow. I missed the sprint-goals!

Now we have gone back to Scrum. We still limit the work-in-process and all that, but we need the scrum-framework to measure results, evaluate tools and improve our processes. We handle the SLA by removing time from developers availability when planning the sprint.

If we would not manage the delivery, and this is seen halfway through sprint, then I would not switch to Kanban. I would see that as something we need to learn from in future. (I guess that how we take action depends on the situation.)