Making Agile work for you. Why two pizzas may not be enough.
Over the past year, I have been fortunate to help drive the agile transformation of a digital programme. This transformation was — unintentionally — realised in two phases. In the first phase we moved from a waterfall to an ‘agifall’ model, also commonly referred to as ‘agifail’. We were ‘doing agile’ and we had all the agile ceremonies and roles. However, we weren’t ‘being agile’ and were still delivering in the waterfall mode we had always known. It wasn’t until the second phase, where we fully adopted an agile mindset and culture, that we could reap the anticipated benefits; a happier team, improved efficiency and productivity, and a better product for our customers.
During this transition, we learned that there is no ‘one size fits all’ approach to agile. As Dan North’s theory describes, we ‘ SWARMed’; we Scaled Without A Religious Methodology. According to Dan North, packaged agile solutions — like SAFE or the much coveted ‘Spotify model’ — are ‘ neither necessary nor sufficient for successful agile transformation’. Instead of blindly following an existing model, we chose to do what is right for us as a team and our product. We took a pragmatic approach and applied common sense. Moreover, we stuck to the basics of the agile manifesto, even when this meant we were doing things that weren’t — according to the theory — specifically considered agile. Here are some examples.
Size matters
For a team to be truly agile, it is imperative that they are able to deliver a product ‘end-to-end’, from vision to taking a product to market. Agile theories — rightly so — encourage team size to be as small as possible. Jeff Bezos at Amazon came up with the ‘two pizza rule’. If a team couldn’t be fed with two pizzas, then it was too big. Our team, however, is made up of 25 people distributed over two locations. Although this team size requires additional coordination and oversight, its size is necessary in order to have the level of expertise to deliver a digital product ‘end to end’ across multiple platforms. In addition it is also necessary to have sufficient capacity to support an iterative release model, delivering value to our customers on a monthly basis.
Agile planning
For agile purists, putting agile and planning together is like rocking the boat. I have news for you; agile teams do have a plan. The big difference with waterfall is that this plan is flexible. It takes into account that unforeseen things happen and that product delivery is no exact science. It also takes into account that the level of certainty over your plan significantly decreases the further you look into the future. In my experience, a mature agile team with a well-groomed backlog and consistent velocity should be able to look up to three sprints ahead with a reasonable level of certainty. Beyond these three sprints (or six weeks), ‘release goals’ can be defined stating the top priorities for the next releases. These goals are then refined as sprints evolve. The difference with waterfall is that these goals should be seen as an intent — something the joint team are striving towards — rather than a fixed commitment. Goals give the team guidance and direction. Nevertheless, the team still has autonomy over how they are achieved.
The art of effective communication
Compared to a waterfall delivery model, one of the most positive outcomes of agile is an increased ability to respond to change. The speed and pace of delivery in agile by far exceeds that of waterfall delivery methods. However; due to this flexibility and speed, there is an even bigger need for consistent and timely communication. The amount of effort this communication requires significantly increases with team size. In organisations with large teams and interdependent deliveries, this soon becomes a mammoth task. Following our agile transformation, time spent on communication in various forms significantly increased, both internally within the delivery team and across both locations, and to wider stakeholders including vendors.
The conundrum of the agile programme manager
According to agile theory the role of an agile programme manager doesn’t exist. Theory states that such roles and responsibilities are shared amongst the scrum team. However, in large teams and more complex organisations there is a need for someone who maintains oversight, communicates, coordinates, and manages any risks, issues and dependencies. It is important to note that an agile programme manager role isn’t a ‘lift and shift’ of its waterfall counterpart. Its main purpose is to support the team. In addition, the programme manager works hand in hand with other agile roles, such as the scrum master and product owner. A programme manager removes noise and helps to maintain oversight, enabling the product owner to focus on the product and the scrum master on supporting the development team in the sprint. Does this mean every agile team needs one? The answer is no. As long as the team is empowered to do what is right for them, and sticks to the basics of the agile manifesto, they are set up for success.
