You are currently browsing the tag archive for the ‘Scrum’ tag.

I came across a great presentation on using Kanban for video game production on InfoQ, and I have to say it was quite refreshing to watch.  It’s great to see industry veterans like Clinton Keith recognizing the need for continuing evolution in process at a time when many companies seem to have come as far as Scrum but have not quite continued to innovate.  As cost of development continues to skyrocket, there’s an opportunity for effective, Lean and Agile-minded leaders to step up and trailblaze a new path.

Watch the presentation at

First of all, I wanted to announce that the scope of this blog might be growing a bit; I was recently promoted from the Release Manager at Citysearch to Engineering Manager for several teams working on our advertiser platform. A lot of the reason I was promoted was because of my experience in process development, so there will still be a lot of correlation between the original content and where we go in the future, but I’ll definitely be growing and talking about new subjects with relationship to the broader organization.

In that light, I wanted to talk about my experience moving my software teams from Scrum to an iteration-less form of Kanban. My CTO, Christophe Louvion, provided a nice high level summary at based on feedback in a presentation one of my teams gave, and I’m going to expand on the list:

Stand ups differ – going story by story, not based on individuals
The story-based focus, where we start at the right of the board and focus on how to move stories into the “complete” column, has encouraged the team to be more collaborative in analyzing, executing, and testing their story implementations. Previously, the teams were going down the list on the first day of the sprint and assigning items out one at a time in an effort to essentially maximize their work in progress. Unfortunately, this was pathological in that it ensured that only one person knew the implementation for that story (and that you were done if that person ended up getting sick) and that it discouraged the team from swarming around one or two items. Now, everyone on the team is aware of what the entire team is working on and can share the load as needed.

Less Rules: No roles prescribed, More Dynamic
This speaks to the core Kanban idea that the process itself is something that is being engineered and tailored to the team; the team feels that they don’t need to have roles (such as the Scrum Master) that the team has in many ways grown out of the need to have. If they are mature enough to self-organize, they are more than welcome to do so – and they are.

Backlog more Flexible
If you’ve ever worked in advertising you know there are a lot of stakeholders out there and when deals get done they need to be implemented irrespective of any two or four week sprint cycle. The flexibility of the “to-do” list in Kanban allows our product team to reprioritize any work that the team has not already started development on, which in turn gives the product team the ability to ensure we’re always working on the latest requirements from the business. Everyone knows they are working on the latest and most important features and that means real value when we deliver.

Pros: Better Team Focus, Less Meetings More Time to Deliver, More Flexible Work Process
Again, the second two points here speak to the ability of Kanban teams to tailor the process to themselves. The first point, however, is really worth digging in to. In my opinion, the increased team focus comes from the participation of the team in engineering their work process. Prescriptive methodologies such as Scrum, although good general rules for many teams, do not necessarily require the team to understand the why behind many of the reasons that the process is the way it is. In fact, they are designed so that even teams who do not understand the whys can be effective. In contrast, because Kanban drives change from within the team, the team is encouraged to experiment with the process (even making mistakes, as long as there are lessons learned), which results in a team that understands at a very deep level what works for them, and why. On my team Kaizen events have jumped significantly now that the team understands the process and knows that they are empowered to make changes in a safe environment.

Cons: Less Structure Could Cause issues with Some People
This is one item that I’m still learning a lot about. Kanban does seem like, much more than Scrum, it requires leaders at all levels in the organization to drive the positive process change. I’ve been on a couple different teams that were learning Scrum as they went – I’m not sure that Kanban is capable of working for teams at that level. It simply provides too much flexibility to the team and much of the guidance asks you to analyze your specific situation rather than reading out of a playbook. That said, I haven’t actually tried Kanban yet with a less mature team so my data is incomplete here.

How Its Working Out: Feels Good, Increased Our Collaboration, Communication Has Increased, Forces Follow Up to Eliminate Blockers
“Feels good” is another important component. If you saw the last video post I made, you know that two of the major elements that motivate people are autonomy and mastery. Kanban provides these in that it trusts the team to engineer their process in a way that works for them – the methodology is not from “on high” and passed down to them to execute; instead they are an integral part of the process. We hire smart people who are good at engineering software systems, it turns out those kind of people have an intuitive sense for engineering process as well. The Kanban board and metrics provide a visual way for the team to see that things are getting better and to know that they are leading themselves to an increased level of mastery.

All in all, moving to Kanban has so far been great for the team. We’ve only been experimenting with the new process for a few weeks now, but already it seems like things are on an exciting new trajectory. I’ll be updating this blog with more details on how things are going as we continue to learn and grow.

I came across a great article over at the ACM blog regarding how Agile Facebook is and the kind of value they are seeing from using these kinds of processes even though they are well out of startup mode.   A lot of people think that Lean-derived techniques such as continuous deployment, Scrum, and Agile are really only for small, startup-type companies, but just as Lean manufacturing isn’t just for small workshops, Lean software development can deliver astounding results to any company – especially large ones that have become complacent and allowed a lot of non-value producing process to creep into their methodology.


Perhaps the most interesting and revealing aspect of Robert’s talk was the discussion of Facebook’s somewhat unique development process.  At the surface it appears to have the contradictory goals of: minimizing down time, scaling fast, and extremely quick code updates.  First, Facebook developers are encouraged to push code often and quickly.  Pushes are never delayed and applied directly to parts of the infrastructure.  The idea is to quickly find issues and their impacts on the rest of system and surely fixing any bugs that would result from these frequent small changes.

Second, there is limited QA (quality assurance) teams at Facebook but lots of peer review of code.  Since the Facebook engineering team is relatively small, all team members are in frequent communications.  The team uses various staging and deployment tools as well as strategies such as A/B testing, and gradual targeted geographic launches.  This has resulted in a site that has experienced, according to Robert, less than 3 hours of down time in the past three years.