About 9 months ago, I decided that I wanted to build a fish pond in my garden. I researched the various options and finally settled on a strong cemented pond. I spent every weekend building my pond – digging, laying bricks, plastering, water proofing, building a rockery, and planting plants in and around the pond. Once all the hard work was done, I let the water settle for a few weeks and then added some small Koi and Comet goldfish…Happy days. I was very proud of my pond. I enjoyed cleaning it, feeding the fish, and just sitting and enjoying it peacefully. My two sons and I had named all 12 fish; Silver Surfer, Brownie, Monster were but a few. We grew quite attached to them; feeding them, talking to them, making up stories of what they were doing in the pond while chasing each other and hiding in the reeds.
One morning, after a rainy night, we followed our usual schedule of going outside to feed the fish and clean the pond. On approaching the pond, I noticed that some fish were floating. I asked my sons to wait while I checked on the pond. To my horror, all 12 fish were dead. What had
happened? They were all coping so well; feeding and swimming happily, and all of a sudden one night of rain and they’re all dead? The only theory which made sense was that the rain had washed some of the surrounding plant matter into the pond and caused an imbalance in the pond, or poisoned our fish. Could I have avoided this?
Whenever there is a change in a system, no matter how small, there will always be changes to the greater system. What changes did I not plan for? If I had planned for these changes, could I have managed them better? Some changes will be positive, some less so. Regardless, understanding who the changes may impact and getting their buy in is essential. I certainly hadn’t planned for the rain causing any disturbance, but if I had, I could have avoided this tragic outcome.
Agile adoption follows a similar pattern. Organisations will start with introducing Agile at a team level, and normally focus on the practices and tools. Very few organisations will consider the wider impact on the organisation.
A ‘new way of doing things’ might seem like mere rhetoric to a seasoned (and maybe even jaded) company executive, until you explain how it supports a strategic goal. Agile holds immense promise when it comes to effecting positive organisational change, but it remains impotent until executive endorsement, and hands-on management are aroused.
The fact that Agile is not yet at the stage where a chair has been pulled out for it in the boardroom, keeps senior management in the dark as to its largely untapped value. A strategic discussion around Agile will also reveal its relevance to the wider organisation – for e.g. how communication from the business may have to change with regards to the team(s) that has adopted Agile.
It’s in the absence of this level of cognizance that Agile is often treated as the ugly stepsister – taking the rap for failed projects. Also, a lack of proper management of the process, from the start, will impede the full adoption of Agile into the operations of a team. Teams endure considerable change during this adoption, as well as a marked reduction in speed at the beginning. But efficient management of the process will not only have prepared the team for this change (and those reliant on its output), it will also help everyone respond with context.
Robust strategy will interrogate critical issues like the impact of the team(s) that has adopted Agile, on those that haven’t. One of the key advantages of Agile is delivering value quicker. If the team, for example, are not in control of their own deployment, then the question is, are they actually able to deliver value quicker? I have worked with a team which had new features in QA for 5 months. Because of internal processes, they were not able to release these features. What change needs to be considered in order to take advantage of the more effective way this team is working?
From experience, it is easier to get a team to adopt these new practices, than the values and principles. The values and principles underpin the practices and tools, and without adopting them, you risk having a number of meetings and a board with sticky notes – void of any real value. It’s challenging for the team to adopt the values and principles, as they extend beyond the team itself. And to support the adoption of the values and principles, the changes required need to be managed and the team needs support from all levels of the organisation.
Individuals and interactions over processes and tools: Agile encourages people to have face to face communication. While the team understands this, the organisation change required to support this value is not managed. In reality, getting the value right first, before even looking at the practices is far more important. To achieve this, you need everyone in the organisation, or business unit, to understand the change required to adopt this value. How can senior managers support this change to encourage individual interactions? We need teams to be co-located but often red tape and policies prevent this from happening, or at least happening in a timely fashion. We need the product owner to be available for at least 80% of the time. In most organisations, senior managers will still expect the Product Owner to do their normal full time job. Getting a Product Owner to actually sit with the team, in some organisations, can be near impossible. Often organisations will dictate a certain tool to be used to capture requirements. How does this encourage face to face interaction? I have seen a number of times work completed based on information captured in a tool, is not what the business believe they had asked for. A face to face conversation could have prevented this waste of time and re-work.
Working software over comprehensive documentation: What documentation is still valuable? How long is delivering value delayed due to heavy weight documentation and out-of-date policies? How many of these documents are actually read? How much time is wasted on these documents? In order for the teams to focus on delivering working software, what changes could senior managers help with in order to facilitate this? If senior managers encouraged the business to focus only on producing those documents which add value, and not just continue producing document after document, “because we have always done it that way”, then the business itself becomes more agile, and value is realised sooner. I often find that lack of understanding of Agile document requirements compels BAs to keep following an old policy.
Customer collaboration over contract negotiation: This is one of the values which would be most certainly out of the team’s control. Part of adopting a new way of working means that senior managers will need to understand the value of collaborating with customers, and therefore be open to working with customers in a new way. This could mean that they need to take the initial risk to help the customer understand this new way of working which enables the customer to realise value sooner, and to pay only for the features that deliver the most value.
Responding to change over following a plan: Even in an Agile environment, some senior managers still expect a project plan with timescales, scope and a budget. Do the senior managers, project managers or any other stakeholders outside of the Scrum team really understand how scope, time and budget are handled in Agile? How has that change been managed? Planning is still important, and with Scrum, for example, there are many levels of planning. Project plan, release plan, sprint plan and daily plan. The agreement is that these plans are important and they can change because we value customer feedback. If businesses don’t understand this change is required to support this new way of working, they will continue to work in the way they have always worked. Change needs to be encouraged and managed from the top, and people need to understand how the rest of the organisation is affected by the way the Agile team is now working.
Also, in Agile, we encourage teams to be self-organised – to commit as a team, and to share the accountability as a team. However, we still measure people on an individual basis. Perhaps it’s time for senior management to help HR change their policy, so that team work – rather than individual – performance is measured, and rewarded?
This not always the case though. I have been involved in large organisations, in which teams in certain areas have had the full support of senior managers. The leaders have been part of the adoption – right from initial training, to assisting with implementation. Leaders are present for the planning and they dedicate the people required in order to make the adoption a success. Changes required are identified and they assist the team in making these them. In other words, change is highlighted as an integral part of the team, and Agile’s success. The change is planned and executed with the same, if not higher, priority as the adoption of Agile itself.
Agile is more than a change in a team. Agile adoption is a change in the way the entire organisation will function and this has to be managed with full support at all levels. It’s never too late to execute a change plan, and to identify where buy-in and support are needed.
The experts say that it’s critical to find the right moment to raise your ideas. That moment might be when organizational priorities shift, when certain players leave or join the company, or when a boss’s preoccupations change. Point is, though, the time for adoption and executive endorsement of Agile is now.
I learned a lot from my mistakes with my pond. I failed to managing change and the impact that this change would have on the fish and the surroundings. In business, mistakes will be made and that is ok, as long as we learn from them. If senior management are not supporting and facilitating the change, then theses mistakes may not be seen and lessons not learned.
You may be happy to know that my fish pond is going well, and the new fish are very happy.