Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Vikas Hazrati on Dec 30, 2009
When a Scrum project grows, so do the team members. The suggested way of managing a growing team is to split the team into multiple teams keeping in line with the Agile recommended team sizes. However, there could be multiple communication and coordination problems when each team starts working in a sprint of their own.
Mike Cohn, suggested that the best way to resolve these issues is by synchronizing the sprints. On one such project, he initially started with staggered sprints but soon found out that it was not a good idea. The biggest problem with overlaping sprints was that there was always more than one team which was partly done with their work and hence the system could not be delivered to the customer for either feedback or deployment.
Synchronization does not mean that all the sprints should finish on the same day. He suggested that the synchronized sprints should end within a day or two of each other.
Allowing sprints to end over a two- or three-day period can make it easier for someone on multiple teams to attend all the review and planning meetings expected of someone on multiple teams. Additionally, it has the advantage in many cases of better accommodating remote team members who may travel into town for these meetings.
Mike further added that having synchronized sprints does not mean that different teams cannot have different sprint lengths. Here the teams could go with nested sprints.
The most common use of nested sprints is when the various teams on the project cannot agree on a common sprint length, with some wanting two-week sprints and others wanting four-week sprints.
Responding to Mike, Angry Poodle added that they had to move to synchronized sprints given the complexity of their product.
In our company where the system we build is very large and complex, synchronization is hard. On the other the size of the system forces us to big bang releases that happen 3 times a year (x3=9, for each supported version). The internal chaos around the release sprints is almost too large to be handled. This is why we’ve had to keep the sprints in sync.
Jeff Sutherland however suggested that in many situations overlapping sprints might be a reality.
According to him, there could be simultaneous overlapping sprints running through a set of development teams. He suggested the need of a MetaScrum to deal with multiple sprints. According to him,
To deal with simultaneous weekly and monthly Sprints, along with quarterly major releases, a MetaScrum was formed at PatientKeeper led by the lead Product Owner. Having the entire company driven by a single agenda out of the MetaScrum meeting has dramatically reduced company communication problems, customer angst, general churn, and confusion. Just as the Scrum meeting has consolidated all decision making for a Sprint, the MetaScrum meeting consolidates all decision making for multiple Sprints.
Similar on these lines, responding to a question, John Clifford suggested the formation of a Product Owner Council.
I find that multiple-team projects work well via the use of a Product Owner Council, consisting of a Chief Product Owner who 'owns' the project/release and individual team product owners who help manage their individual team backlogs, etc. Coordination between the teams is done via backlog management, e.g., if Team B needs a user story from Team A, then the Product Owner Council ensures that the user story is completed before the dependent item comes up in Team B's proposed sprint backlog.
Thus, there are situations in which synchronization might not be possible. In such circumstances, MetaScrum or the Product Owner Council could be an option. However, Mike suggested that sprints should be synchorinzed where possible. He drew the following analogy to support his point,
To me the benefit of this is like one of those families with on-the-go parents and kids who say “Do what you have to but everyone is home at 6pm for dinner.” We all go our way during the day (work, practices, friends, whatever) but it all comes together once per day (sprint).
Case Study: IBM's Agile Transformation
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
No comments
Watch Thread Reply