Hi All,
This week I want to discuss some pointers to being successful with Enterprise Agile from my experience:
Program and Portfolio Planning
First when it comes to Agile Program and Portfolio planning it can be very valuable to align program milestones with team level iterations and releases. This can be particularly valuable when a company or organisation is working with a vendor that uses Agile iterations and needs to align this to their internal program and project milestones. By aligning with Agile iterations and releases communication between the management team and the development team(s) or vendors can be made much clearer.
For example if a vendor will release a mobile user interface in its next iteration, the program and portfolio management teams can align their milestones for delivering mobile access to the upcoming vendor iteration or release. This also allows an organisation to still have their Agile development teams and vendors responsible to certain delivery goals and milestones. This approach also maximises visibility by allowing management teams to track how iterations required for their upcoming milestones are progressing, and increases predictability as a result.
Budgetary Tracking and Estimates
That said, the second pointer I would like to discuss is how to budget and estimate for an enterprise Agile program. Traditional budgeting provides a set amount of money for the delivery of set features in a set timeframe. However, with an Agile program and Agile teams there needs to be flexibility in the creation of product backlogs of user stories, and backlogs of features. If the Agile teams are required to fix all of their features at the start of the project for budgetary purposes, the organisation loses one of the key benefits of Agile which is the ability to respond to the market quickly and flexibly.
In order to respond to the market and retain flexibility a good approach is to budget based on a certain set of features of a certain size (when I mention size I am referring to the Agile practice of
T-Shirt sizing to facilitate relative estimating), but not to fix the exact features in advance. For example a company may budget for 5 large features over the next 6 months. From experience (understanding team velocities and hours spent working on large features) they may know it takes roughly $100k to deliver one large feature. So to deliver 5 large features in the next 6 months they may budget $500k. Or if planning out for the year they may budget $1m for 10 large features over the next 12 months. By planning this way if the company needs to swap a key large security feature for a large mobile feature 3 months into the project their budgeting still remains accurate, while their teams and Product Owners have the flexibility to respond to the market.
Organisational Change
The third pointer is in how to lead an Enterprise Agile program. I have often heard the advice that when an organisation moves to Enterprise Agile, that they should just make all of their Project Managers into ScrumMasters and magically they will have Agile teams. The problem with this is that traditional project management and leading Agile Programs requires an entirely different approach to leadership. While Agile programs require a servant leadership approach (serve through leadership, and lead through serving the teams) traditional project management is generally more command and control.
When a command and control project manager is made into a ScrumMaster, or Agile Program Manager the results are generally not healthy. Instead of empowering teams the ScrumMaster or Agile Program Manager assigns all of the teams’ work and demands that it be finished on an assigned schedule. This takes away any empowerment the team may have enjoyed as a result of becoming an Agile team in an Agile Enterprise (as well as taking away flexibility and agility). A key pointer here is to assess each traditional project manager, and leader in the organisation. Some may adapt well to a servant leadership approach. Others, may not and may need to find different roles, or may simply be more comfortable in a non-Agile organisation. Identifying this early on and shifting people to roles where they will be successful is a key organisational change factor to enable successful Enterprise Agile.
I hope some of these pointers and points have been useful. These are only a few that come to the top of my mind in thinking about avoiding pitfalls in transitioning to an Enterprise Agile organisation. Hopefully food for thought, and useful advice for avoiding common Enterprise Agile adoption pitfalls.
Until next time, Stay Agile!
John.
