lean
There are various ways to support agile team retrospectives. We’ve used all of them, so let me share our experience.
Cadence (usual retrospectives)
If you have iterative development like Scrum or XP, it is very convenient to run usual retrospectives meetings. For example, with 2-week iterations you have such meetings every other week, discuss issues, what worked, what not, brainstorm solutions and new things. We’ve tried mood boards, various formats for issues gathering and for action items tracking. We’ve tried a whole lot of things in 2 years. In general, it worked. But then we switched to Kanban and somehow retrospective meetings faded out…
Is there a better way to improve development process?
Stop-the-Line
We tried to apply stop-the-line practice. It states that as a mistake or malpractice is discovered all responsible people should immediately hold a meeting to resolve/prevent this specific problem. There were several stop-the-line events, but this practice did not survive. Why? There are two main reasons.
- It is very disruptive. People are working on various unrelated tasks and are in the flow. Suddenly they should switch to a problem resolution brainstorming. Many people don’t like to do that.
- It may take too long. Sometimes the problem is very hard and it takes much time to find a good solution. People impatiently drink coffee and want to get back to work.
So we dropped stop-the-line practice and replaced it with a pure pull system.
Pull / Issues Board
Issue Board is a very simple concept with 3 basic rules:
- Every person in a development team can write a problem or a new idea he wants to discuss on a whiteboard (Issues Board).
- There is a limit of 3 problems on the board.
- When there are 3 problems on the board, we have a retrospective meeting right after a daily meeting.
We have been using this approach over the last several months and I like it most. It leaves off some problems both of the stop-the-line approach and the cadence approach. First, if there are no issues or ideas, there’s no need to have a meeting :) Second, no interruptions, since daily meeting is interruptive by itself, so it is just natural to have a retrospective meeting right away.
If you have other approaches to retrospectives, go ahead and share them!
Many interesting posts and discussions about Scrum and Kanban published last weeks. Someone even called this a war :) I don’t think it is a war, but some posts indeed may drive such feeling.
- Ken Schwaber bashed Kanban. “I was told that Kanban is frequently used when an organization cannot readily adopt Scrum. Many of Scrum most difficult aspects are then sidestepped. Managers are still in charge of telling people what to do. People can be interrupted at any time. People are still work in functional silos, preserving the jobs of functional managers. People are not allowed to work in containers, sharing skills and knowledge to bring complexity into solutions – instead they are worked on a pull (more sophisticated than push) production line.”
- Karl Scotland discusses Scrum and Kanban difference as Intentional vs. Implementational approaches. Interesting perspective in fact. Karl thinks that Kanban can be used with Scrum to reveal even more problems in development process.
-
David J. Anderson posted the most rational article about Scrum and Kanban difference. I like it a lot. Some phrases are true gems: “Kanban is not a project management or software development lifecycle method. It is an approach to change management – a framework for catalyzing change in an organization.” and “Kanban uses a WIP limit as a change agent and Scrum uses commitments. This is a fundamental difference in approach.” David also posted some reflections later with interesting thoughts about anarchy and science.
- A year ago Tobias Mayer didn’t believe that it is possible to use Kanban at all. “I fundamentally disbelieve that there is any such thing as a “value stream” when you are working in a complex environment, in a creative process, building new products or generating new ideas.”
I think Ken is wrong. His arguments against Lean and Kanban quite ridiculous. Sure there is no intention to treat software development as a factory and apply lean manufacturing principles blindly. Of course there are people who will try (or already tried) that and fail. But vast majority of lean community in software development do understand the difference and working on concrete practices. Lean philosophy is great, but tools and practices can’t be taken from manufacturing directly.
Pull system is more complex than Push? C’mon!
David has wise arguments and perfect position. I think Kanban will be more popular than Scrum in long-term perspective, but it will take time. Visualization is a key thing to manage complexity, and software development is a complex system.
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.
There’s so much room for observations and analogies in the evolution of production trends. Analogies are not merely a candy for the brain. They bring along a deeper understanding of phenomena and ultimately are one of the greatest aides to align (or misalign) with mainstream.
If we look back, to the 18-19th century – mass production was a dream. The philosophy was: produce more. Lavish architecture designs, garments, gardens – everything created by people was about going more massive and taking much space. Standards of innovation have been changing over the centuries - what’s been innovative and massive, has been becoming obsolete. Minimalism is the new innovative. Is it because humans subconsciously feel they’ve taken too much terrain and sky on this planet for industrial experiments and now are trying to compensate for that by being minimalistic in everything? Or simply finding ways to fit in?
Hardware/software as well as visual designs and interfaces are meekly following the same trend. This just shows how subtly the “new innovative” standards are taking over. We remember huge PCs. Now we’ve got all kinds of minimalistic devices the names of which start with “i“. We remember waterfall. CMMI standards with their tons of rigid rules, regulations, documented processes. Now we’re going “lean” and “agile” – the same minimalistic tendency.
People have managed to stuff the overproduced artifacts not only all over the planet but all over themselves. Fatness is the problem. Again, what a shift in standards – as late as in the beginning or even middle of the 20th century it was considered trendy to be fat. Well, not obese, but hearty fat. Now, we’re all about lean. Off with plump beauties. Straighten up now, lean is the philosophy of minimalism in production.
P.S. I truly believe that all the fat folks are hiding the “lean” insignia deeply inside them. It just takes some effort to peel off the layers :)
I’m digging into Lean Manufacturing and it’s so interesting to learn manufacturing history and its trends. There are so many parallels between manufacturing and software development. Of course they are not direct, but a curious mind can draw them quite easily. Let’s take Cellular Manufacturing as an example.
Cellular Manufacturing is a workspace organization technique. The main principle is to organize production of a single product in a small dedicated unit (cell) that consists of several people and several workstations. The benefits are surprisingly huge:
“The result is very fast throughput. Communication is easy since every operator is close to the others. This improves quality and coordination. Proximity and a common mission enhance teamwork.”
It is a significant improvement over the functional space configuration, when you have large queues and long transition time.
Now, if we think about software development, it is becoming clear why distributed teams have problems and why functional departments will not survive in the near future.
Cellular manufacturing applied to software development directly leads to cross-functional teams that work on a single project. Cell is a single team that has its own inventory and cross-trained people. Expanding it further, it means that developers should be able to do testers’ job, and vice versa.
From lean perspective, managers job is to setup cells configuration efficiently. It is not required to track individual work, but to track cell work instead. It brings process optimization to a higher level and powers system thinking.
It is really amazing how much we can extract from lean manufacturing and adopt this knowledge to software development…
I got this insight on lean and agile techniques in military context when reading “Ideas Made to Stick” book. The workflow of the military was described there as an example of how important it is to make messages as concise as possible to accomplish tasks.
The evolution of the military strategy with dates and sources is not a subject of this blog :)
With no extra details, here’s the core of the point I’m trying to make:
First the Army’s approach was to make sure that every single action is planned down to smallest details. But, as they found out, “enemy bears no plans”. An unexpected move could destroy the whole set-up so “all king’s horses and all king’s men” could not make the Army function again. Effectively, I mean.
So, they reverted to something very similar to agile technique of creating user stories – Commander’s Intent. Commander’s Intent is “the commander’s stated vision which defines the purpose of an operation, the end state with respect to the relationship among the force, the enemy and the terrain; it must enable subordinates to quickly grasp the successful end state and their part in achieving it”.
Do you see the resemblance? It’s a replica of lean production principles, only in military, not in civic, context. And it’s exactly like the agile principle of engaging people and encouraging their creativity to achieve one common goal.
I will not go into quoting sources on the web on Commanders’ Intent and military doctrines to find more analogies and similarities in military setup and lean/agile methodology. I just outlined the idea.
There’s a misconception related to this topic: Some people think that agile works all OK for lazy folks. It’s all about freedom, about looseness, no obligations. Not at all. Agile is less conventional, it does not care about being in the office at 9 am sharp, or about wearing a tight business suit. But agile projects do have their Commanders’ Intent and they require genuine responsibility and engagement from the team – the soldiers.
Now, as the Army follows agile principles, would you need any better proof on the effectiveness of agile and lean methodology?
In previous post I mentioned 5 wrong reasons to apply Kanban. Tobias Mayer asked to blog about 5 right reasons :) Obviously there should be right reasons, otherwise Kanban adoption would fail everywhere. So there they go:
#1. Ability to release anytime
In Scrum or XP you can’t release in the middle of an iteration. In Kanban you may release anytime. When user story is ready, you may release it. Definitely it is a challenge to setup development process this way. It is required to have “branch-by-feature” source control policy, merge often, integrate and test often. But it gives you an ability to release often. That is something worth to fight for.
As a PO I like this ability very much. An important user story implemented? OK, let’s release it tomorrow in v.2.15.2. Our customers may benefit from this release as soon as possible. Lead time is faster — customers are happier.
One thing to mention — you need to have a good automated test suite, otherwise it will be problematic to make small releases with a good quality.
#2. Ability to change priorities on the fly
In Scrum you can’t add stories on the fly into sprint (usually). At least it is not an easy process and development team often resists to replacing a story from Sprint backlog. The story has been discussed, estimated etc. A new story may be discussed in a hurry, some details will be missed and as a result significant re-work will be required. So in general iteration or sprint should be frozen.
In Kanban if you have an urgent request to implement or a really important user story, you can just put it on top of the queue. It will be taken as soon as a free slot is available. It is simply a Product Owner’s dream :)
#3. No need in iterations
Why you need iterations? Initially iterations help to reveal real problems in the development process quickly. Further on they establish a project rhythm and rituals. However at some point in project I think you no longer need them.
My vision is that you need to iterate first, then flow. Our backlog is fuzzy now, plans change often. We learn how to do agile in general and iterations are not helpful there anymore. Without iterations there is no need in iteration planning and iteration demo meetings. They are waste. Instead we have more smaller just-in-time meetings with people in a feature-team before starting the development for each user story. It works perfect.
Some people are missing the rhythm, but I think it is more to habit. Kanban establishes more complex rhythm and it may take time for development team to recognize it. Still stable rhythm may be the only reason to keep iterations in the late phase of product development, in my opinion.
#4. No need in estimates
Why you need estimates? In iterative development you need them to predict how many stories you may take in the next iteration. You may even predict a release date based on estimated backlog and iteration velocity. The other reason is that PO wants to know how big the user story is. If it is big enough, PO may consider moving it to the next release. If it is small, PO may decide to put it into the next iteration.
Obviously, iterative development is hardly possible without estimates. But if you drop iterations, it is not a problem anymore. Can Product Owner live without estimates? Well, yes. In our company we don’t estimate user stories. Why not? Because I as a PO don’t need them and we don’t use iterations. All I may ask is a very rough estimate like normal, large, very large.
In our situation (I stress that, in our situation), estimates are waste. We don’t spend time on estimates. We have a prioritized backlog and just take the most important user story and implement it. It may not work in some conditions, but we have quite a mature product and hundreds requests from customers. There is no clean field development, so normally we don’t have any defined release date. We release when it is ready (I understand that many companies can’t do that, but we have this favor).
#5. Perfect flow visualization
Kanban Board provides a very clear view on current work in progress. It visualizes flow and enables fast planning and tracking. It is really a great tool, we love it.
Kanban is becoming a popular agile tool. Indeed it is very good for software projects of certain types. However, there is a danger of false reasons behind Kanban adoption.
#1. User Stories Diversity
“Our stories vary in size a lot from 1 point to 40 points. Large stories just do not fit into an iteration”
It is very easy to say you can’t split user stories, thus iterations should be abandoned. An easy solution is not the best one. There is something important behind the fact you can’t split stories. Most likely you don’t know how to split stories right. It is quite hard from the beginning and demands creativity.
Moreover, according to Queueing Theory, it is better to have small stories with roughly equal size. Small batches with equal size improve flow (and you have a better and more predictive cycle time). So in Kanban you still have to split stories to smaller stories and try to make them equal size.
#2. Failed Iterations
“We can’t complete most stories in a single iteration”
There may be many, many reasons behind. Mini-waterfall approach, velocity greed, large stories, manual testing, poor stories description, etc. You may even have a wrong iteration length. For example, in large projects 1 week iteration may be an overhead with a huge transaction cost. So 1 month iteration may be much better in this case.
You need to analyze true reasons, the roots of the problem.
#3. Failed Retrospective Meetings
“Retrospective meetings are waste, they do not help in process improvement and we want to remove them”
You just don’t do these meetings right. One popular failure is no Action Items after the meeting. Without action items a Retrospective Meeting is just a kind of informal chat that you may have over a glass of beer. You meet, chat about your problems, and get back on the same track next day. Rule #1 is to collect and write the list of Action Items that you will try to accomplish during the next Sprint [or any other time box].
One more common pitfall is to skip action items execution. You may collect them, but not really try. You may even try them, but abandon too quickly. Almost all new rules or practices put you off the comfort zone. It takes time to learn them, use them and like them (or dislike), but it should be an expert opinion, not just a gut feeling.
If you expect that you will replace failed retrospective meetings with a nice and simple “stop the line” rule, you’ll fail, since it is even harder than scheduled regular retrospectives and demands even higher level of self-discipline.
#4. Shared People / Functional Departments
“We have a single pool of developers and share them between projects. We can’t form stable project teams”
Do you really think that Kanban will solve your social and organizational problems? C’mon! It helps to visualize flow and find bottlenecks, but if you don’t have a cross-functional team — you have hard times. It is proven in so many sources and researches that cross-functional teams perform better, produce better results and better software.
If you are experiencing difficulties planning sprints with shared pool of developers, try to fix the root of the problem first – switch to cross-functional teams and eliminate multi-tasking.
#5. Simplicity
“Kanban is so simple! No plans, no estimations, no iterations, no overhead”
Indeed Kanban looks simple. But it provides nothing interesting by itself. To ensure a successful Kanban adoption, you need to apply Lean principles first. This new buzzword may sound like a silver bullet, but obviously it is not. Hard work, discipline, target on perfection and constant improvements – all that is required to apply any agile methodology.
Don’t get me wrong. I am not saying that Kanban is bad. We use it within TargetProcess and I personally believe it works way better than iterative development (for us). I just want to make a point that you’d hardly resolve all your underlying problems as you switch to Kanban.
P.S. I usually don’t read posts like “10 reasons to …” Can’t believe I wrote such post myself! :)
P.P.S. Read next post 5 right reasons to apply Kanban.
Lean and Kanban software development adoption is growing. More and more companies setup Kanban Boards, limit WIP and eliminate Muda.
This collection of links will help you understand all that buzz around Lean/Kanban and decide whether it is worth trying. I’ve read all the articles and posts below, so this list is a truly selected thing ;).
Articles and Blog Posts
- Lean Software Development. Wikipedia summary about lean software development. It is a good start to digg into the topic (as usual).
- Kanban Development Oversimplified. Most likely the best article to start with Kanban. Very clear, very detailed. Good work!
- Kanban, Flow and Cadence. This blog post with many nice pictures describes three important properties of Lean: Kanban – Controlled Work, Flow – Effective Work, Cadence – Reliable Work.
- Scrum-ban. Interesting attempt to mix Scrum and Kanban, taking the best from both worlds. Kanban with iterations is possible.
- Beyond Scrum: Lean and Kanban for Game Developers. Article describes real Lean/Kanban implementation for game development industry. The section on how to improve The Flow (3 strategies: Time-boxing, Levelling workflow, Reduce waste) is especially good.
- Adventures In Lean. Series of posts about Lean approach with focus on real problems solving (handling bugs and emergency fixes in Kanban, setup pipeline, bottlenecks, etc.).
- Lean and Kanban. Several posts on the topics in this blog.
Presentations
Lean/Kanban Blogs
- Agile Management Blog. Lots of interesting posts from David J. Anderson (well known engine of Lean software development :)
- Richard Durnall Blog. Pull and Push systems, interviews, lean roots and principles. Nice reading with hand-drawn diagrams.
- Lean Software Engineering. Corey Ladas and Bernie Thompson are blogging about Lean, Scrumban and Kanban, Theory of Constraints, software development and other topics you did not even hear about.
- AvailAgility. Karl Scotland’s posts are very interesting (and helpful) to read. Isn’t Kanban just a Task-board? Check the blog to get an answer.
- The Agile Executive. Many insights into Kanban and summaries from the first lean conference.
- Software Just in Time. Lean concepts and real lean applications posts by Alisson Vale.
Lean/Kanban People in Twitter
- David J. Anderson. Lean/Kanban software development pioneer.
- Corey Ladas. Product development methodologist. Author of Scrum-ban book.
- Henrik Kniberg. Optimize, debug & refactor IT companies. Author of Scrum vs. Kanban presentation (which is very good!)
- Karl Scotland. Agile Coach. He runs AvailAgility blog with great insights into Lean and Kanban.
- Rob Lally. Renaissance Technologist.
- Alisson Vale. Alisson implemented outstanding Kanban process in his company.
Tools
There are just several Kanban tools on the market. To be honest, I don’t like TRICHORD UI. LeanKit: Kanban looks much better, but it can work for small teams only on my opinion. Anyway, it seems Kanban tools vendors’ race just began.
If you know other tools that support Kanban, drop a comment and I’ll happily include them into the list.
- TargetProcess. Customizable Kanban Board and other vanilla.
- Zen. Good tool for small teams.
- LeanKit: Kanban. In beta so far, but looks quite neat. Maybe useful for small teams.
- TRICHORD. Desktop project management application with Kanban boards.
- Radtrack. Registration does not work, but I found the screenshot via Google. Looks like LeanKit so far.
Did I miss something interesting? Drop a comment!
. Detailed presentation about Lean and Kanban. Focuses on many problems and solutions in a software development process.