I don’t think I can fully communicate the value of co-location.
Any time I have been asked to help a company in recent years, the engagements have started out with an assessment. I don’t believe that I can provide sound advice unless I understand what the problems are and what the organization’s capabilities are.
One problem that EVERYONE has had so far is the absence of an effective place for their teams to work. Software development is a highly creative endeavor that requires (usually) a significant amount of collaboration between teammates and it constantly surprises me how organizations build terrible places for teams to try and achieve this!
When we started out with the client whom all of these Success Factor posts are about, the development team was spread out across ½ of a floor in an office tower and there were 2 members in a different city. Check out my hand-scribbled floor map with the initial, planned layout of the team members.
This is actually not bad compared to many companies I have observed, but this is far from optimal. The deficiencies that aren’t obvious from this floor map include:
- No team-specific collaboration space. Had to book meeting rooms and hope one was available.
- The Devs and PM have no whiteboard space. They are in cubicles.
- The BA, TW (Technical Writer) and CSM (ScrumMaster) were packed into a large office with minimal whiteboard space.
- PO (Product Owner) and HW (Hardware guy) were alone in their offices.
- There was no place to have daily stand-up meetings or to have our card wall up where everyone could see it.
- The sponsor was on the opposite side of the building.
For a team that is intending to collaborate frequently and intensely, this is a very poor setup. Our sponsor was spending in excess of $100k/month on the team in that room and he wanted to make sure we had every advantage to maximize that cost. So before we even kicked off the project, we made a rather bold request to have a board room near the sponsor converted into a team room. And our request was granted!! The facilities people were a little scared that we’d damage the boardroom table that was in there, so they had that taken out quickly, but the resulting floor plan looked like this:
Now we were excited! We had a room that could hold everyone. There was room for everyone but the PM and HW guy, due to the nature of their roles, didn’t need to participate as intensely as the rest of us, so they maintained their offices. And since our PO was also maintaining some business workload, she maintained her office as well. But all three team members attended all the meetings that we had in the team room and would often drop in to see how things were going. Let’s take a look at the team room.
I have to say, this is the best team room I’ve ever had the pleasure of working in. We had wall-to-wall whiteboards on the West and South walls, and the North and East walls where covered with large PostIt notes. The SE corner of the room had a projector screen and the projector sat on the SE corner of the team table. The computer on the East wall ran Skype and TeamPulse, the Agile Project Management Tool that we used on a daily basis (from Telerik). The room had a Skype account that was always logged in and you could call up that account and it would always auto-answer with video and put the caller on the projector. There were two microphones in the middle of the big table that would allow everyone to talk from where they were sitting with whomever called in.
I can’t say enough about the sheer wall space in this room. It was fantastic. On the wall-to-wall whiteboards, we had everything from architectural diagrams, to class diagrams, server layouts to retrospective results. We had everything on those whiteboards and they would be able to stay up for as long as needed for the team. We would write our retrospective notes up there, and leave them for the entire next sprint. Then the that sprint’s retrospective notes we be put up, and compared, and discussed. Then the former sprint’s notes would be erased. We had a constant rolling reminder of how important continuous improvement was to us.
The PostIt notes were used to keep less volatile things like our value statements right up in front of us. Also, team policies like our Definitions of Done, or our Prioritization logic where up there for everyone to see. There was never any doubt about how we wanted to work when you were in the team room.
We were creating a mobile system that included on-board tablets in trucks and we had our QA station right there behind our QA professional team mate, our PO and our BA! They could check specs, and then turn around and try it out right there in the QA environment. And if there was ever a problem, the developers could (and usually would) hear about it right away. That was one great aspect of our room that allowed our quality process become pervasive of everything that we did in that room.
I can tell you about a time that our QA lead was working on a test script in Microsoft Test Manager. Then he turned and tried the test step on the tablet and discovered a bug for a feature that was in the iteration. He called the developer over, who saw the defect right away. The QA lead logged the bug and the developer, whom had luckily just finished up a task, was able to pick up the bug and fix it right away. Our QA process was such that we could fix a bug, submit the code, all the automated quality checking mechanisms would run and then we could push the passed build up to the QA tablet where the bug had been fixed. In this particular case, the whole process took less than 1 hr. Discovered, Logged, Fixed, Built, Deployed, Re-tested, Passed. It is very rare for me to see a team perform this well.
But I totally believe that a big contributor is the team room that we’ve built for this team. Every team member feels the others pain when something doesn’t go right. This causes us to behave differently. Less selfishly and with a much more holistic approach to building the software solution.
And that was a known feature. The benefits of having the Product Owner, Business Analyst and Sponsor all within 20 feet of the developers is unbelievable. When anyone has a question about a feature or an idea that we’re trying to make real, the entire stack of business-focused people are right there, immediately available to answer the question. The only time that this team ever builds the wrong thing is when we are building something for someone who isn’t in the room. And you can bet that we escalate that immediately to our sponsor. Because he is 15 feet away.
And he just drops in all the time!! If he has a problem, he tells us. If he is curious how we are doing, it pokes his head in. He will see us working on a problem with our process and lend a hand if he can. And you can bet that this closeness has made the team much more aware of his concerns and challenges. It never feels like Big Brother is watching because there is so much transparency on the team that it is always about trust and helping to get the job done.
I could probably go on and on about all the benefits of this team room but I’ll wrap it up for the moment and leave the rest to your imagination so that you can think about what the benefits of this team room would do for your team.
A question that I often get while speaking with people is:
What is the difference between Kanban and Scrum?
I know this topic has been explored at length in many places on the internet and also with a variety of different answers, but I’m going to put my thoughts down and share them with you because:
- I still feel there is a lot of misunderstanding on this topic and I think I have something to add to the conversation
- People still ask. The more of us who can blog and promote conversation on the topic, the better.
- Getting my thoughts out and in a more concrete form that I can reference (and send people to reference) should promote better conversations as well.
So. Here it is. Kanban Method. Scrum. I imagine I’m about to step on some toes but I hope we can have some good debates and not conversations filled up with rhetoric.
At their hearts, both methodologies are attempting to do the same thing. They are attempting to advance the state of the art in work management predominately (but not only) in the area of knowledge work.
Both are heavily influenced by value-systems. Scrum is primarily influenced by the Agile Manifesto which describes the “Agile” value system. The Kanban Method pulls a great deal of its values from a Lean value system. There isn’t really a “Lean Manifesto” but the works of Taiichi Ono and W. Edward Deming contribute to a common understanding of what it means to be a lean thinker. They are not the only contributors but have made the most significant impressions on the Lean/Kanban community. The Kanban Method is also influenced by the Agile Manifesto and the values inherent within it.
Both methodologies believe in delivering software incrementally to maximize the opportunity to get feedback and capture ROI. Incremental delivery of software also mitigates risk and maximizes the opportunity to learn from a business, process, and technical perspective.
Both methodologies are striving to make people a central aspect of the system, which they should be. 😀 Scrum strives to “protect” the development team from the influences of “traditional” project management tactics. Kanban suggests that we need to allow solutions to problems emerge from the people in the system. Kanban also believes that changes should not be forced on people, but that people need to own the changes and be supported throughout the transition. Both systems try to give people the time and space required to improve.
Similarities with Significant Differences
Both approaches promote an intent to learn and improve. In Scrum this is primarily achieved through the retrospective tactic which is an Inspect and Adapt-based tactic. The team will get together (frequently) to discuss processes and tactics that have been going well and should be continued, things that haven’t gone well and should be changed for the next sprint. I do not believe that Scrum teams put sufficient emphasis on this aspect of Scrum and that the common understanding of Scrum doesn’t promote this aspect strongly enough. I also believe that the scope of the area under review primarily focused on the team. Again, this may not be the intent but it is, in my experience, the way it is implemented.
The Kanban Method has learning at the core of the methodology. There are several reasons for this, but the primary reasons for this are:
- Do nothing without understanding the current situation
- The current situation is always changing
- New challenges (technical and business) are always arising
- People, who are at the heart of the system, need to be learning constantly in order to be improving themselves and the system continuously
- Without a learning approach to improvement, you can’t use experiments to test improvements
The Kanban Method uses more of a Plan – Do – Study – Adapt (PDSA) approach to learning and this is different from a Inspect and Adapt approach.
Scrum prescribes a cadence and that all activities happen within that timebox. If you didn’t guess, this cadence is called the sprint duration. Sprint is just another name for the resulting timebox.
The typical Scrum cadence now a days seems to be 14 days (2 weeks) and follows the following sequence of:
Sprint Planning -> Execution (daily Scrum meetings) -> Iteration Review -> Retrospective -> repeat cycle
Scrum’s Sprint duration is a great innovation over the traditional approach to managing work. Because the guidance on duration has never been longer than 30 days, Scrum teams have always been guided to strive for shorter feedback cycles than traditional projects. Scrum teams have also been guided to produce increments of software at the same rate. In order for Scrum teams to do this, work has to be decomposed and understood by the development teams. Work gets prioritized more frequently and this prioritization allows these teams to be agile from a business perspective. Risk can also be explored and mitigated within the sprint and that knowledge feeds back into the prioritization loops of the team.
In the Kanban Method, cadences are just as important as they are in Scrum. Many Kanban teams have a Queue replenishment cadences. This is effectively the same as the Sprint Planning activity in Scrum. Many (most?) Kanban teams have a daily stand-up meeting where the team discusses the current state of the kanban system, looking to remove impediments and manage work at risk of taking longer to deliver than expected. Many Kanban teams will have product demos (iteration review) that coincide with an opportunity to deliver or deploy the product being built. And many Kanban teams will have Operations Reviews which are an opportunity to discuss the Kanban teams progress and improvements with the rest of the organization.
The significant difference between the two systems is Kanban does not typically use timeboxes and all of the cadences in a kanban system can happen when it is best for the organization to do them.
Timeboxes are a mechanic that Scrum uses to minimize disruption to the development team. In Scrum, changes to the Sprint plan are strongly discouraged. Plan the two weeks, then let the team work uninterrupted. This has allowed for great improvements in productivity in software development, but what if we could apply that protective attitude to a single piece of work. So while a team was working on an item, they were not disrupted but they could be counted on to pull the next highest priority item on the queue as soon as they were ready to pull some work. The business could prioritize as much as needed while the team had work in progress.
Timeboxes are also used to provide a consistent interval that external parties can interact with the Scrum team. Business can plan around a 2 week cadence to injecting new requirements into the system, and downstream partners (IT, Sales) can count on getting new work or increments of software every 2 weeks as well.
In Kanban, the cadences that are most appropriate for the external partners can be allowed to emerge and do not need to be enforced (or tied together) by the development team. There are advantages for shorter cadences, but what if we could get all the way down to Just In Time and we no longer had cadences on replenishment and delivery? We can still have cadences on Ops Reviews or any other ritual that benefits from these cadences. What if replenishment happened every week, or daily, and delivery happened every 4 weeks? Or on the 25th day of each month? That is an advantage that many organizations benefit from when adopting a kanban system as a way to manage work.
Pull-based , WIP Limiting Systems
Both Scrum and Kanban ARE Pull-based, WIP Limiting systems. Scrum uses, in many senses, a kanban system at the heart of how they manage work. The Scrum team PULLS only the work they can manage into the iteration. The iteration planned work is the maximum amount of Work In Progress (WIP) that the Scrum team will be expected to deal with. The limit of the amount of work in the iteration is set by the team’s previous velocity measurements. But then we will start to encounter the limitations of the Scrum work management system. Scrum teams can still start a lot of work and suffer from the inefficiencies of multi-tasking. Having a lot of work in progress (started) but not finished is a significant source of waste in our industry. Humans cannot multi-task, we context switch and we all know that context-switching is expensive. Scrum does not have specific guidance to limit multi-tasking within a team. (Note: Please correct me if I’m wrong here. Haven’t read the Scrum Guide recently)
In a Kanban Method implementation, the focus is to limit WIP at a more granular level. Preferably at the work item level but we can also let the most appropriate granularity emerge by leveraging the learning aspects of the method. We use WIP limits to guide our intent to finish work before we start more work. We also use WIP limits to reduce overburdening. WIP limits are a great way to fine-tune your Kanban system and how and what to set them to would require a lot of explanation. Suffice to say that Kanban’s WIP limiting tactics allow for significantly more tuning that Scrum’s Sprint Planning tactic.
Scrum teams tend to categorize work into two types, User Stories and Bugs. Both can be decomposed into tasks. Scrum actually provides guidance that there are “product backlog items” and that User Stories and Bugs may be types within that backlog. Additionally, Scrum allows work items to be of the same type but vary in size. This size is often described in Story Points. So one User Story may be 3 points, another may be 13 points. And there is no common interpretation of a point between different Scrum teams. What a story point actually means is specific to a Scrum team.
Kanban Method teams tend to have numerous types of work. Requirements, User Stories, Use Cases, Bugs, Defects, Improvement Activities are all examples of work items I’ve seen on Kanban boards. Whatever makes the most sense for the organization. Kanban differs from Scrum in that it generally does not try to categorize work by a size. The size of the work items in a Kanban system don’t really matter from a management and monitoring perspective. Once the item has been committed to by the Kanban team, they should finish it within the expected timeframe given how big they think it is when starting. It is when it starts to exceed expectations that the Kanban team should start to pay closer attention to it and take corrective actions if possible. But other than setting an expectation when the work is committed to, sizing isn’t important from a work management point of view. It should be noted though that smaller work items are usually easy to manage from a development point of view because the larger a work item is, the more likely that item is to contain significant unknowns and lots of uncertainty.
Both Scrum and Kanban use metrics to help drive behaviour and decision making.
There is really only one metric in Scrum. Velocity. Teams will assign a estimated value to a work item that is used to indicated how “big” it is. The team will work as many items as they can in a sprint. Once the sprint is completed, the values of all completed work items will be summed up and that was the teams velocity for the sprint. This velocity will be used to determine how much work is pulled into the next sprint during sprint planning. You can create burn-down or burn-up charts based on the velocity metric as well. Typically, this is as scientific as a Scrum team will get. The summing of a subjective measure of size on a work item.
In The Kanban Method, all measurements are intended to be quantitative. Something that is measured and the value is (usually) not really debatable. In Kanban, we tend to measure time (lead/cycle) and quantities of things (work items) at various points in the workflow. These are all concrete, measurable attributes of work in the system. All that is needed is start and end-points and you can now start the clock when work gets into a state and then leaves the state. This can be as simple as started and finished or much more complicated with numerous states and parallel activities steams within a workflow. We also measure how many of something are in a particular state as well at a time as well. Ultimately in Kanban, we measure how long it took something to get somewhere. With these measures, we can determine rates, quantities, and speeds of work items and establish a deeper and more meaningful understanding of the system.
Generally speaking, Scrum prescribes a set of activities that are performed within a Sprint. There is not any guidance on particular daily development activities but generally you should be analyzing, developing, testing, user acceptance testing throughout each day as applicable. But most Scrum teams will always do Sprint Planning, Development for the rest of the sprint, Iteration Review and Retrospective.
The Kanban Method does not prescribe any workflow. The workflow that you model in your Kanban system should be YOUR WORKFLOW, and it should evolve as required based on things that are observed and needed by the organization. A kanban system is expected to evolve and change over time as the organization (and it’s needs) change over time.
This also includes cadences. Scrum generally prescribes that the workflow happens within a cadence. Kanban does not prescribe cadences. It does appreciate the value of cadences but feels they should emerge where needed and the interval should be as long as needed, but Just-In-Time as much as possible.
Kanban does not prescribe any roles. Roles and responsibilities (and changes in them) should emerge based on the organizational maturity and understanding of the development process.
Scrum generally prescribes three roles, Scrum Master, Product Owner, and Team Member. If you’re on a Scrum team, you’re normally categorized as one of these things. I think that this can be a good thing, but it can also backfire as people try to find their place on the team. The individual esteem system of a person is influenced by what they think their place in the world is. Changing that place in the world can shake a person’s esteem and confidence, which tends to diminish their acceptance of a system or change.
Most people’s interpretation of Scrum is team-centric. This isn’t a necessarily a bad thing, but at some point it may become a limiting way of thinking when trying to scale Scrum or work with upstream and downstream partners of the Scrum team.
The Kanban Method takes a system thinking approach to process problems and expects the impact of changes to ripple throughout the entire workflow of the organization as business need/idea goes from inception (idea) to realization (software). Generally speaking, the kanban system is intended to protect the “work” (and therefore the team) from being disrupted so we don’t have to have a team-centric view of things. We can take a system thinking view of things and understand that every interface to our “team” system is actually an interface with a larger system that could benefit from The Kanban Method implementation.
This post has been much longer than I expected and I’m not sure I’m even done, but I think I’ve covered off what I think are the similarities and difference between Scrum and Kanban.
What I want to leave you with though is that neither approach is wrong, nor do they need to be exclusive of each other. There are teams that have started with Scrum and arrived at a Kanban Method implementation, and there are Kanban Method teams that have arrived at a very Scrum like (or Scrum exactly) implementation because that set of tactics and tools were the best way to manage work for that organization. It should never be a Scrum vs. Kanban conversation, but rather a question of what is the best from both methodologies that I could use.
I believe there are aspects of The Kanban Method that Scrum doesn’t adequately address in our quest to better manage knowledge work workflows, so I do think that while you can always have a system with “No Scrum”, you should never have a system with “No Kanban Method” in it.
Thanks for following along on this rather epic article. I hope to hear from you, both positive and negative comments are welcomed.