Main Menu
SSL SecureMode
Lost Password?
Register now!
ChangeVision Members Map
Entry for hiranabe  Syndicate hiranabe's entries

A tree grows stronger and a river runs longer -- Two types of scaling Agile

Author: hiranabe (7:55 am)
After Agile has been adopted so widely, scaling agility across the enterprise is now a topic for these years.

In this blog, I ponder two ways to scale Agile -- a "Tree" and a "River" as metaphores in the mother nature.

  • "Tree" type, or "Scrum of Scrums" type scaling.

  • This is a natural extension of Scrum from a team to a project of scrum teams or a progam of scrum projects, and maybe to a company with a product portofolio.

    In this model, typically each scrum team has standups everyday and retrospectives after each sprint, while scrum masters form an upper level scrum and have standups and retrospectives after the ones of the sub-teams. Even a company board meeting can be seen as a top level scrum. In this way, tree type scaling shares (and needs) strong synchronization of the teams though out the organization. I assume Jeff Sutherland's Patient Keeper and its Type C Scrum is a good example of this strong "scrum" company.

    A tree shares a rhythm, location, climate, mood and so on as a living thing. It scales strongly but within a size of tree.

  • "River" type, or "Lean" type scaling

  • The other scaling strategy is to connect different teams such as a marketing team, development team, and QA teams with queues between them.

    I would call this a "River" or lean type scaling, where multiple teams
    work asynchronously in their own rhythm and culture using buffers inbetween. Lean is an attitude to make value flow seeing the whole.

    In this "river" type, even the concept of iteration is not necessary. Using kanban or other information-sharing and buffer-management tool, the work flows from upstream to downstream through the whole value stream across the enterprise.

    A river runs through countries sharing a flow, but each country has its own climate, rhythm and culture.

  • My hypothesis

  • When scaling Agile, a company with less than 100 employees, like an energetic startup, can and should use tree type scaling to get a whole company agility and to create value from its teams. It is like a growing tree pumping water and nutrients from the soil, sharing one strong culture and sense of timing in possibly a collocated workplace.

    On the other hand, a big company with different division cultures or a big project with multiple companies, can use river type scaling
    more effectively because each sub-team naturally has different rhythms and wants to move independently from the other teams. It is like a river runs across a continent making a value flow to the ocean connecting different regions.

    Tree scales with a stronger synergy, while a river scales a lot broader.

    Read hiranabe's weBLog | Comments (4) | Trackback (0) | Reads (23170)
    Trackback URL of this entry
    Printer Friendly Page Send this Blog to a Friend

    Poster Thread
    Catherine Louis
    Posted: 2010/4/30 9:28  Updated: 2010/4/30 9:28
    awesome post! You can indeed combine the two models, using a pod of a tree flowing through the river, to make efficient scaling in larger organizations.

    Poster Thread
    Posted: 2010/4/30 11:04  Updated: 2010/4/30 11:04
    Joined: 2006/5/16
    Posts: 74
     Re: scaling
    Thank you, and your metaphore of a pod of a tree flowing through the river is so cute, implying a change agent or a living being of some intention not just floating in an organization.

    Poster Thread
    Posted: 2012/11/24 2:44  Updated: 2012/11/24 2:44
     Re: scaling
    All thngis considered, this is a first class post

    Poster Thread
    Posted: 2012/3/24 6:03  Updated: 2012/3/24 6:03
    Communication is a key aspect in opesnource development. I am not sure it is very tightly related to scrum, but more to how the team is structured (friendship, location, language). But it is definitely true that scrum like the other agile methodologies encourage a lot personal communication. The purist are for real-time, f2f communication, which is something not very applicable in open source.For this reason the issue of loosing a lot of such fluid intra-team communication is real. One idea I am playing with is that an open source community of developers is a communitty a social community. The idea I am working with is that a social network-like site would tremendously help open source development in general, but open source agile development specifically.