Guest post by AgileBill Krebs of Agile Dimensions
Some teams – such as sustaining engineering teams – are fine with Kanban. This method shows work on a taskboard as it progresses from waiting, to doing, to done, with an eye toward cycle time and focusing on a few things at once.
Some teams are fine with traditional Project Management Body of Knowledge (PMBOK – from the PMI) – as in special client engagements. This covers key project aspects such as cost, procurement, communications, and may use a Gantt chart to plan jobs of known but varying sizes. Unlike most of our agile projects, this will assume there is little likelihood of change.
Some teams are fine with Scrum development. Two-week iterations and sprints give vital visibility into progress, and also windows for change. Teams learn empirically and use these iteration windows to tune and adjust their product and procedures. Extreme Programming (XP) plans in a similar fashion, but adds some technical practice to build quality in.
These teams often have nine or fewer people, with three to six months for work. But what if the project or product you deliver has 40 people? 100 people? 300 people?
Projects like these would require scaling up your agile. Authors such as Jutta Eckstein, Scott Ambler, Kenny Rubin, and Dean Leffingwell have all described ways to do this.
Using such concepts in practice with dozens of teams has shown six key areas:
1) Roll-out – does management and the teams know agile at scale is different? Are they committed to doing it, and have they had some training on multi-team agile? Do you have someone prepared to program manage a team of teams?
2) Common language – one team can use whatever terms they wish. But when team of teams (aka, Scrum of Scrums) forms, it quickly becomes a mess where some say ‘Feature’ and some say ‘Epic.’ Pick a scaled agile methodology and vocabulary, and make that your organization’s common language.
3) Features – it helps organize larger projects to use the ‘parent’ of a story. Let’s call this a ‘Feature’ (like Dean Leffingwell’s Scaled Agile Framework® or SAFe™). While we still use small Stories, it becomes more important to plan ahead using larger Features so other teams can know when to depend on our output. This also helps stakeholders gain a picture of our product even as the number of Stories multiples as the team grows in size.
4) Align the business – with larger projects, it becomes even more important for business-facing parts of your organization to connect with your scaled agile process. Planning at higher levels such as portfolio (multiple products) and program (multiple teams) becomes more integral to how we work. But working with our market experts is harder if they do not understand our terminology and approaches to delivering at scale. Other areas such as accounting and your project management office may need to understand your scaled approach as well.
5) Kick off each release – spend a little more time before each release to look for dependencies between high-level features. Let teams know what’s coming, and have them discuss how they will deliver together.
6) More than a dozen teams – it makes sense to forge four or even 10 teams into a group that delivers a product. But if you product requires more than a dozen teams, that will be big enough to demand another sub organization with its own program manager.
Agile development has been used in many projects, large and small. Keeping these six factors in mind will help with your enterprise-strength projects. Taskboards may be sufficient with smaller projects, but larger projects benefit from tools designed to see things at more levels – portfolio, program, and team.
What steps can your project take to work smoothly between teams?
“AgileBill” Krebs has over 20 years of programming, performance, project management, and training in the IT industry at 5 IBM labs, banking, telecom, and healthcare. He has used agile since 2001, and taught it to over 2,000 people worldwide. He has presented at agile conferences, IBM Research, and conferences on education. Bill’s certifications and groups include SPC, PMI-ACP, CSP, ICE-AC, and others. He hosts the Distributed Agile Study Group and is a member of ALN, the Scrum and Agile Alliances, ACM, AERA, PMI, and more. He is pursuing a graduate degree in education technology, while working as an enterprise agile coach in the healthcare IT industry.
Scaled Agile Framework is a registered trademark and SAFe is a trademark of Scaled Agile, Inc.