What is Best, Scrum or Kanban?

I have for some time been thinking, what is best, Kanban or Scrum. I can't make up my mind so I decided to write an article in two parts, one where I wear the "I love Kanban" hat and one where I'm wearing an "I love Scrum" T-shirt.First I would like to tell you shortly what Scrum and Kanban is.Scrum in 1 minuteScrum is about getting back to the time when the company was small and everything was easy and ran smoothly. Back then projects were small, teams were small, releases were small and communication was easy. Best of all, we were efficient.In Scrum we split our big project into small projects as we work on timeboxed iterations called sprints. We split our big team into small teams (still with all the skills we need) and launch often. If we are more than 20 employees we probably have a problem knowing what the other departments and customers are needing so let's bring someone into the team that can represent them. To help communications from the team to the rest of the company we have our plan and current status visible. The plan is called the sprint backlog and the status is shown on the scrum board. Here is an example: The person we brought in to represent all stakeholders is called product owner and is responsible for prioritizing a list with features that will be developed for the product in the future. This list is called the product backlog.To make Scrum a process we add some small but necessary meetings: a planning meeting, daily synchronizing meeting and meetings to improve product and process. We decide the length of our iterations and aim to deliver something valuable after each iteration.

Kanban in 1 minuteScrum is simple but Kanban is even simpler. Just visualizing your workflow and limiting demand to capacity is enough to call it Kanban. Let's start by looking at the roots of Kanban. It's a way, invented and used by Toyota, to get a good flow of parts to their plants. Kanban is just a card attached to the part and when the part is used the Kanban is sent as a request to the supplier for more parts. The physical card is actually sent to the supplier who is attaching it to the next pert sent. Since the cards are re-used and no new cards are entered in the circulation Toyota limits the number of parts in stock and at the same time make sure new parts are ordered as soon as they are needed.

In software development Kanban is a limited promise of work. A Kanban board is a number of placeholders for work to be done. A typical Kanban board can look like this.

Each team has decided their limit and drawn as many squares as the limit allows them to. Whenever a task is done it will be moved to the next group if and only if they have free Kanban squares. Else the task is stuck. If there is nothing more to do we have a problem with the flow and we need to work together to solve what is stopping us. While Scrum is focusing on delivering on commitment Kanban is focusing on getting a smooth flow. In common for Scrum and KanbanThere are a lot of similarities between Scum and Kanban. Some examples are:
A strict prioritization (it's obvious what to do next)
Self-organizing teams (see below)
Transparency (show what you've done, your current status and what's next to do)
Inspect & adapt (improve your product and process based on facts)
Pull scheduling (see below)
Good communication and collaboration Self-organizing teams is when the team themselves are supposed to figure out how to solve problems, remove impediments and optimize their process. They should base their decisions on facts to inspect and adapt accordingly.Pull scheduling means the team is pulling work instead of having it pushed. This will limit work to capacity and lower stress, which is bad for both health and quality.This is why I prefer ScrumSo, now that you know what Kanban and Scrum is, it's time to decide which is best.
I start by putting the Scrum T-shirt on. Look further down if you like to read the part where I love Kanban.I concentrate on some areas where Scrum and Kanban differ:
Iterations - In Scrum you work in iterations. Kanban sees development as a forever ongoing flow of things to do.
Commitment - In Scrum a team commits to what they will do during a sprint.
Estimations - In Scrum you need to estimate to be able to have a velocity. In Kanban it's optional since focus is on time-to-market.
Cross-functional teams - That's one of the pillars of Scrum. For Kanban it's optional. Efficiency driven by commitmentBy asking a team for a commitment they will get a positive stress knowing that people from outside will see if they can do what they committed to. It also gives an energy boost at the end of the sprint when the team has the goal within reachable distance. After the sprint, the team can feel relaxed and gather some new energy for the next sprint. It's psychologically nice to not feel you are in the middle of a never-ending stream of things to do. Instead Scrum concentrates on one sprint at a time and allows you to focus only on those things you have decided to take on in the sprint. By working in fixed length iteration you get a nice rhythm the whole company can feel and adapt to.The value of estimatingEstimating is not a waste of time since valuable information is transferred from the product owner while the team asks what they need to know to be able to estimate. The same thing applies to commitment. To be able to commit team members need to know what they are committing to. They simply have more interest in getting information from the product owner so they listen more carefully. And they are just asking for the information they need which makes the meeting very efficient.Even though you can predict when a project is done, just by counting stories left, it is more precise if each story is estimated as well. Prediction is important when more departments, like marketing, are dependent on your work. It gives a more serious feeling.Slack at end of sprintsIf there are some time at the end of a sprint that's valuable even if the time is not big enough to start developing new features. This is time developers can use to improve code quality or the development environment. Both will give better efficiency in the long run.Build teams with cross-functionalityWorking together in a cross-functional team is a psychological thing. You are able to go the whole way from concept to released product together as a team without dependencies. You are not just a cog in the machinery. It's also fun and helps you grow as a person. By helping each other, knowledge is spread which lessens dependencies on each person. It also helps prioritize since features can be built without considering which knowledge is available. To coordinate between people with the same skills who are sitting in different teams you can have virtual team meetings as often as needed.Scrum is best for beginnersI know, you can do all those things even when doing Kanban but they are optional and since they are optional you might just not do them just because you are too lazy to challenge the usual procedures or structures of your company. If you are new to Agile development it's better to have a method guiding you to do the right things. Just read the book and implement it. Later when you get used to it you can start experimenting and eventually get better performance. If you start experimenting too early you might end up with waterfall or chaos but still calling it Agile. Kanban is more advanced because you need to make a lot of decisions without having many facts.This is why I prefer KanbanNow it's time to take off the Scrum-T-shirt and put on my "I love Kanban"-hat.
Kanban is based on Lean principlesKanban is Lean and has been around for 50 years and has shown to be successful. Things are seen as a flow without iterations. Not many rules. It's just a focus on reducing work in progress, strict prioritization and limiting demand after capacity. Besides that you have the normal Lean principles of:
Quality
Just-in-time (decisions and facts just when they are needed)
Short lead-time (quickly from concept to cash),
Kaizen (continuous improvement)
Minimizing waste (everything that is not adding value to the customer) No meetings if it's not adding value to the customer. Most of those things are fine with Scrum but I can sometimes think Scrum has some waste. Here I will mention some areas where Scrum practices might be waste.Estimations might be wasteIf a product owner knows what needs to be done and the only goal is to have it done as soon as possible, why spend time on estimating? In Scrum, estimations are needed for a team to know how much to commit, to calculate velocity and for the product owner to decide on prioritization. If none of this is needed, it's waste and we shouldn't do it. If you like to measure velocity you can instead count the number of stories done per week or month. While talking about measurement why not look at something the customers are interested in, lead-time. That is, the time it takes for the customer to get what he or she ordered.Constant flow If the team is done with a story and there is not enough time left in the sprint to complete the next, it's likely no one works hard the remaining time and that's waste. Kanban is trying to get a steady and non-stressed but high flow of work running through development.Sitting with people that can help youIn Scrum a team is cross-functional and sits together with the people working with the same project and not with the ones with the same knowledge. Let's say you work with sound effects for a computer game. Then it's not much help to have a java-programmer beside you. It would be more valuable to sit with people doing the same things as you do who can help you with tools and practices.

No possibility to commitIn Scrum, the team commits which does not work very well for a team with support issues. They get a lot of disturbance and commitment is not worth anything since the ones disturbing them don't care about commitment. A commitment you can't control gives either frustration and stress or demotivation.Kanban for support and operation teamsSupport and operation teams are often interrupted. It's part of their job. Frustration comes when interruptions are happening just because there were no time for pre-emptive work. Just by having the pre-emptive work on the board gives focus to fix the hardest problems one-by-one, which gives less interruptions and more time to work pre-emptively. It becomes a good circle. A Kanban board for an operation team can look like this:

Most important are the urgent problems that arise. Secondly, daily duties must be done. Then the team members can take care of other projects, usually to improve stability in the operation environment. The limitation on the number of parallel tasks gives focus to be done working on improvements, not just starting them.Many options gives freedomKanban is simple with few constraints, which gives you freedom to change your process step by step. Either you go from waterfall or chaos, your first step is to visualize and limit your flow with a Kanban board. When you have your flow visualized you add whatever work is needed to thrill your customers. Your improvements might be decided during a monthly retrospective meeting or on a daily meeting. ConclusionI still can't make up my mind if I like Kanban or Scrum the most. My conclusion is, not very surprisingly, that it depends on the situation. See them as two different tools and find out which tool is the best for your situation. Maybe you start with Kanban and end up with Scrum or maybe you don't. Maybe you'll start with Scrum but change to something more like Kanban. Whatever you do, just make sure you do what is best for your customers.

Ref:

http://www.agilejournal.com/articles/17-articles/1737-what-is-best-scrum-or-kanban

Agile Methods and Virtual Distributed Teams

By Dr. David F. Rico, PMP, CSM

Are Agile Methods and virtual distributed teams compatible? Aren't Agile Methods and virtual distributed teams polar opposites? Aren't they incompatible? And, if they are compatible, what are the specific techniques for making Agile Methods work for virtual distributed teams?
What does all of this mean? What is this controversy surrounding Agile Methods and virtual distributed teams? Why wouldn't Agile Methods be compatible with virtual distributed teams?
Well, all of this is related to the principles and values of Agile Methods as defined by the Agile Manifesto (http://www.agilemanifesto.org/). The sixth of 12 major principles is as follows, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." It relates to two of the four major values of Agile Methods: (1) individuals and interactions and (2) customer collaboration. So, taken at face-value, no pun intended, one would be omitting half or 50% of the values of Agile Methods if one didn't use face-to-face conversations with customers and team members. Or, would they?
Face-to-face communication is contextually-rich, and is the preferred method of communication in Agile Methods. In Traditional Methods, statements-of-work, requests for proposals, contracts, requirements, and designs are considered contextually rich. But, nothing beats good old face-to-face communication when it comes to interacting with customers and team members. The creators of Agile Methods realized this and etched face-to-face communication in stone as one of their 12 commandments.
Okay, now, so anyone who can read a book on Agile Methods knows that face-to-face practices are mandatory. That is, anyone except those who are trying to make money in the global software industry. The global software industry is all about connecting or automating the supply chain of goods and services using products from China, computer programming labor from India, project managers from North America, and researchers in Europe. Well, that's simple, just co-locate everyone. Not so fast, why can't everyone stay exactly where they are and use electronic means to communicate? Well, that would involve violating the principles and values of Agile Methods, wouldn't it? In fact, if a team is not face-to-face, it's using Traditional Methods, not Agile Methods. Or, is it?
The creators of Agile Methods had part of the equation correct. Face-to-face communication is contextually rich, and is therefore superior to virtual distributed communication or software documentation in certain circumstances. However, the North American creators of Agile Methods failed to anticipate or acknowledge that 95% of the world wasn't collocated with them, and that North America wasn't even the predominant computer programming market. Didn't they heed the warnings of Ed Yourdon who said that the Indian software market was skyrocketing or how about Michael Cusumano's warning that Japan's Software Factories were taking over the planet? Perhaps they were caught up in the euphoria of Microsoft's and Intel's instant success in the 1990s. Or, the Internet Gold Rush convinced them that North American information technology dominance was here to stay?
I think the only ones who didn't believe the creators of Agile Methods were the 70 or so other countries besides the United States, who benefited from the Personal Computer and Internet revolution as well (along with any enterprising capitalist who wanted to make a quick-buck interconnecting the global supply chain).
The problem is that 99% of the population who knows anything about Agile Methods believes that one isn't being Agile if one isn't using face-to-face communication and all of the associated trappings (e.g., onsite customers, pair programmers, daily standup meetings, etc.).
Well, hang on to your seats, because the world is changing as we speak, and virtual distributed teams for Agile Methods are here to stay. We all have the benefit of being on the leading edge of this phenomenon as part of the next phase of software engineering evolution. I bet most people who are delving into Agile Methods didn't even realize they were on the cutting-edge of software engineering when they endeavored to use Agile Methods? Let's take a look at some of the evidence.
The folks at British Telecom have devised a set of practices for making Agile Methods work with virtual distributed teams (Cannizzo, Marcionetti, & Moser, 2008). They've identified four major practices to help marry Agile Methods with virtual distributed teams: (1) maximize project status visibility to all stakeholders, (2) ruthlessly automate as many development and management processes as possible, (3) ensure effective communications to the maximum extent possible, and (4) provide immediate feedback on every task performed. They use Eclipse IDE for writing code, Fitnesse and Selenium for acceptance testing, CruiseControl with Ant as a build tool, Danube ScrumWorks for user stories, Subversion for version control, and Atlassian Confluence Wiki for document sharing. Other tools include Visual Studio, NetBeans, Capistrano, Live Meeting, Communicator, Meet Me, and a variety of team building tools.
The folks at Yahoo! (Drummond & Unson, 2008) suggest mandatory meetings within time zones, periodic face-to-face meetings across time zones, overlapping virtual distributed meetings where possible, periodic synchronization between international Scrum Masters, the use of Wikis to share photographs of user stories on Post It notes, and ensuring that virtual distributed teams maintain the rank-ordering or priority of user stories. Furthermore, Yahoo! says to emphasize individuals and interactions over processes and tools as much as humanly possible, factor in the needs of the global workforce over individual practices of Agile Methods, and ensure that accurate information is shared in a timely fashion.
The folks in Canada (Robarts, 2008) say to have periodic face-to-face meetings as much as possible (especially during project kickoff), periodically send people back and forth from one country or location to another, ensure domain experts periodically visit one another, ensure delivery teams occasionally visit one another face-to-face, hold virtual distributed daily standup meetings between people in the same time zone, exchange informal notes such as PowerPoint presentations as meeting minutes, and ensure Wikis and other automated tool content is constantly up-to-date. The Canadians remind us to emphasize the use of Agile Methods practices like User Stories (instead of specifications), use video conferences as much as possible, and use portable information technologies such as laptops, cell phones, and personal digital assistants (e.g., BlackBerries). More importantly, proper schedule management is of utmost importance, especially when it comes to building in management reserve, accounting for international Holidays and unplanned events, and keeping the schedules current as well as communicating them. Interestingly enough, we're advised to allow enough latitude for differences in individual Agile Method practices across international boundaries.
The list goes on and on, as the Indians recommend automated dashboards and wikis (Shrinivasavadhani & Panicker, 2008). The Americans emphasize WebEx Meetings, periodic virtual distributed meetings between international Scrum Masters, and a variety of techniques such as balancing power, allowing for variation in practices, detailed User Stories, empowerment, sharing vision statements, executive commitment, and as much communication as possible (Therrien, 2008). Another Canadian team says to use nearshore resources, maintain strict communication plans, share electronic workspaces, use synchronous communications only in adjacent time zones, and use asynchronous retrospectives (Vax & Michaud, 2008). Finally, a group of Americans and Canadians recommend instant messaging, synchronous communication mechanisms, video conferencing, face-to-face virtual distributed meetings, virtual distributed standup meetings, and the list goes on and on (Young & Terashima, 2008). You don't want to skip this last paper, because it contained a lot of helpful advice.
So, what's the bottom line? The creators of Agile Methods had it right, face-to-face communication is contextually rich and face-to-face is the preferred method of communication. And, a lot of face-to-face communication is a key, if not the key, to project success. I speak from experience on this one, because one of the most difficult projects I've ever managed, was success due to frequent, unscheduled face-to-face communication to break down the barriers to personal trust. Once the barriers to trust had been breached through frequent personal interaction, then the project completed successfully. We were given an award by a customer who had never given an award to a consulting firm before. You just don't find that kind of advice in your typical textbook on Traditional Methods. So, how do we duplicate the benefits of face-to-face interaction in virtual distributed teams? Communicate, frequently and often! Outside of video teleconferencing, telephone calls have been one of the best forms of communication over the last century. It's the "unscheduled" telephone calls that provide the most return-on-investment (versus regularly scheduled telephone calls that just don’t seem to have the same effects). Ad hoc telephone calls help alleviate anxiety instantly, as opposed to scheduled phone calls. Intimate, personal communications break down barriers to trust and ensure project success almost every time.

REFERENCES

Cannizzo, F., Marcionetti, G., & Moser, P. (2008). Evolution of the tools and practices of a large distributed agile team. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 513-518.

Drummond, B. S., & Unson, J. F. (2008). Yahoo distributed agile: Notes from the world over. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 315-321.

Robarts, J. M. (2008). Practical considerations for distributed agile projects. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 327-332.

Shrinivasavadhani, J., & Panicker, V. (2008). Remote mentoring a distributed agile team. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 322-326.

Therrien, E. (2008). Overcoming the challenges of building a distributed agile organization. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 368-372.

Vax, M., & Michaud, S. (2008). Distributed agile: Growing a practice together. Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 310-314.

Young, C., & Terashima, H. (2008). How did we adapt agile processes to our distributed development? Proceedings of the Agile Conference (Agile 2008), Toronto, Canada, 304-309.