Big Agile: It’s not just for small projects anymore | Jesse Fewell Big Agile: It’s not just for small projects anymore – Jesse Fewell

Big Agile: It’s not just for small projects anymore

By July 16, 2012Blog, Uncategorized
elephant leans precariously over a moat to get a peanut

elephant leans precariously over a moat to get a peanut

One of the stereotypes for agile approaches is that they only work for small projects. Ten or 15 years ago that might have been the case, but things are vastly different today. Agile techniques now are used as part of the day-to-day project operations of major organizations around the world. Over the last two years, e-commerce giant Tesco.com has implemented agile approaches across all its technology initiatives, from internationalization to mobile. A Chinese telecom recently used a blended approach of agile and enterprise methods to execute a project involving 40,000 team members. Salesforce.com transformed the whole 6,000-plus-person company to agile approaches as the official company standard. How do they do it? Here are the most popular techniques for scaling agile approaches beyond a single-team project.

Get it right at at the team Level. For the last several decades, management science has told us that the ideal size of a single team is seven people, plus or minus two. Teams of four or fewer don’t need the overhead of a dedicated team leader; anything more than nine, and the complexity curve flies off the chart. With that in mind, it would be ideal to decompose a project of 700 people into a collection of seven-person teams. Each team needs to implement an agile approach with discipline and intention in order to consistently produce a high- quality deliverable every few weeks.

Firm the big picture, and Flex the details. The larger the project, the more moving parts you have—and the more critical it becomes to get every- one aligned to the big picture. From product vision to solution architecture to work culture, the program manager needs to over-communicate the constraints of each team’s work. If we can prevent each team from going too far off course, they can be given more discretion on the details specific to that team. For example, a weekly cross-team technical committee would feature a rep- resentative from each team and be chaired by the chief project scientist or chief technical officer. The committee chairperson would broadcast the high-level con- straints and direction for the project. Then each team would implement its own detailed approach for building the deliverables within those technical and func- tional constraints. Sponsors often use this kind of committee to convey business decisions across teams. It also can be critical for the project manager to address team coordination issues.

Encourage a culture of organic coordination. Formal artifacts and ceremonies are not enough—nobody can design an organizational system for every little detail that comes up. Instead, larger programs will achieve agility only if there is a culture of on-the-ground collaboration. To achieve this, many organizations implement monthly communities of practice (CoPs) that discuss role-specific topics. The Scrum master CoP, the business analyst CoP or the engineering CoP can provide knowledge sharing and mentoring support to colleagues from other teams or even other projects. Finally, the project manager should make it clear that every team member is expected to inform someone, collaborate with a cross-team counterpart, and track down a solution.

Most agile mindsets provide a well-structured approach for small individual teams. However, if you supplement that approach with some forsmal and informal enterprise techniques, you can grow from small agile to big agile.

[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]