Up until very recently agile project management was seen as a great approach to software development……..for small projects.  Even now, especially in the enterprise space (SAP, Siebel other EPR’s), agile is still seen by some as small-fry, a fun approach for building web sites.  I was recently speaking with an old colleague from Deloitte, who is now a Senior VP for a Software Company that we all know – he didn’t even know what agile was.

The larger the project, the more critical it is to the organisation.  This means that more managers want to be in the loop and constantly informed, the project will have a much larger scope, the project will be very time sensitive with delivery dates, it will cost more and will often be spread out across multiple sites.  Of course, the number of resources required to deliver the project will grow need to grow, to a team much larger than the target team size of 7!

Google, Salesforce, Nokia and many other well known organisations have dealt with this issue not by just growing their team, but by building many small, self-managing teams, working off the same product backlog.

Scaling the Product Owner

The Product Owner is one of the most difficult roles on an agile project.  They have many commitments to the actual team such as attending daily standup meetings, retrospectives and are expected to help the team remove blocks and reduce waste.  They also have a huge commitment to the customer, are responsible for managing the ROI and need to carefully maintain a prioritized backlog of requirements.  In order to gather these requirements they must be meeting with stakeholders, customers and keeping a close eye on the competition.  Not an easy job.

Ideally there should be a 1:1 relationship between a team and their Product Owner.  This isn’t always realistic.  We’ve seen it work OK when a Product Owner looks after two teams – but this is the maximum!

A problem with simply adding Product Owners as the scope grows is that the teams and the product owners will start to work independently and may lose the overall vision and direction of the project.  Before this point is reached, it makes sense to build a hierarchy of collaborating product owners – reporting to a “Chief Product Owner” as explained by Mike Cohn, in his book Succeeding with Agile.

The “Chief Product Owner” is responsible for maintaining the overall vision of the product and distilling it to the actual Product Owners who will be working with individual teams.  This can be scaled by adding many levels.

Scaling the Agile Teams

The approach used by many large enterprises is to tackle large projects with many small agile teams.  A side-effect of this is that as the number of teams grow, the dependencies and interfaces between teams grows with them! An approach to deal with this problem is the scrum of scrums.

The scrum of scrums meeting should occur once or twice a week and one or two representatives from each team should be present.  It should be similar to the daily standup meeting, however, it will take a little longer as there needs to be discussions between the group about dealing with dependencies and how remove cross-team blocks.  The scrum of scrum meeting can be scaled by adding more levels to the hierarchy.

One Backlog

Another problem of having many teams work independently is maintaining vision and direction.  An approach to deal with this issue is to ensure that no matter how big your project, you maintain a single product backlog.  This will allow the “Chief Product Owner” to see dependencies between individual stories and if necessary, direct teams to work on different areas.  For example, maybe it’s better for the “HR Team” to stop working on low priority HR Stories and help the “Finance” team with some high priority Finance Stories.

A problem with having a combined backlog is that the backlog can very quickly grow to many thousands of stories.  We’re currently working with a client that has over 6,000 requirements in their backlog.  In order for the Product Owners to understand and comprehend the work, it’s best to group requirements up in themes or build a hierarchy of requirements under epics.  More than a few hundred, high level requirements are virtually impossible to manage.

Syncronise Sprints and Iterations

Our client with 6,000 requirements currently have five independent agile teams with syncronised sprints.  Unfortunately the teams aren’t really self-managing, however, all the sprints start and end on the same date.  This really makes everyone’s life on the project much easier, as everyone is working to the same deadlines.  The project as a whole are in the same rhythm.  Things can get a little crazy at the start and end of sprints trying to stagger playback sessions with the client so people can be in two places at the same time – but teams can generally work it out!

Communities of Practice

Cross Functional Teams are great, as they allow the team to build a single piece of “potentially shippable software”.  A side-effect of cross functional teams are that like-minded people don’t get to spend much time together.  For example, if you’re a Scrum Master, you are kind of left to your own devices.  Mike Cohn introduces the concept of “Communties of Practice” in his book “Succeeding with Agile”.

A Community of Practice is an informal group of people in your organisation who meet up reguarly to discuss things pertinent to their role.  Informally, all of the Scrum Masters in your organisation may have lunch together each Friday.  This could also be more formal, whereby all UI Designers meet twice a week to compare designs.

Enterprise Agile

Agile and Scrum can scale in an organisation.  Like any large change in an organisation, you can guarantee there will be a high resistance from many areas of your team.  Training of the team, sponsorship from a high level and support from peers and direct supervisors is critical to push it through.