These days most tech leaders know what Agile software development is and are familiar with its two of its most popular forms Scrum and Kandban. However, I’m not sure everyone knows what it means for their wider organisations. In the past I have not always realised this myself and subsequently I have missed out on some of the real benefits of being agile.

"If your chosen agile approach isn’t disrupting your organisation, then you are probably not doing it right."

As tech leaders, we have mainly adopted Agile software development to improve productivity. There are many advantages of Agile, but the main driver is to get better products and services to market quicker, ideally at a lower cost.  

However, few of us take the time to understand the impact of an agile approach on our wider organisations. Before I explain what I mean by this, I need to give some detail about Agile and Scrum for the uninitiated. Feel free to skip over the next section if you understand these terms.

Agile Overview

The agile movement started with the Agile Manifesto, which was produced by seventeen experience software developers in February 2001, with the aim to make software development better. It is not a methodology, but a set of four values and twelve principles, which these developers believed led to better software development. If you get a chance to read the manifesto you will find it is hard to argue against these values and principles.

For most, the main take away is that software is better developed in small increments so that changes to requirements can be accommodated. The point being that, most people don’t know what they want until they have seen it, so it best to show them something quickly.

The aim of Agile was to move away from traditional engineering practices (e.g. Waterfall), adopted from building bridges and buildings, to practices that fitted the realities of software. The Agile movement was not the first to do this and I’m sure it won’t be the last.

What confuses some people is that Agile is not a methodology, there are no rules, no steps to follow. However, a number of methodologies have been created from its principles, the most well know being Scrum. Scrum formalises the Agile principles into a framework that you can follow. The other popular methodology is Kandban. Neither actually call themselves methodologies. To be precise, they are frameworks, from which you can construct specific methods, for a specific situation. The frameworks describe key roles, key events (meetings) and key artefacts (documents). The method that is followed is built from these and is meant to evolve to adapt to circumstances.

In Scrum, potentially deployable product is released by the development team at the end of each development cycle, known as a sprint. Sprints can be any length but are typically two weeks. The sprint process is overseen by a Scrum Master, they are a bit like a project manager at first glance but they are not. Requirements are given to a development team by a Product Owner.

Agile Impact

The question I posed is, do leaders understand what Agile means to their organisation? In my experience four elements of Agile/Scrum really challenge organisations and their leadership. These are:

• Self-organising Teams
• True Product Ownership
• Accepting Failure
• Delivering shippable software at the end of each Sprint

Self-Organising Teams

The Agile Manifesto states “The best architectures, requirements, and designs emerge from self-organizing teams.” And this is a key tenant of the Scrum framework. The idea is that as leaders, we put together teams with the right skills and then let them organise themselves, divide up the tasks to be done. They decide who does what, what roles people take. Even leadership in Scrum teams is meant to emerge naturally, not be imposed.

I find, as leaders we want control over how teams are organised. We like to hire into roles and know that people are performing in those roles. So, we struggle to let teams truly self-organise.

Why is it important that teams are self-organising? One key factor for productivity is motivation and key drivers for motivation is empowerment and responsibility. Studies have shown these are far better motivators than money.

Many tech leaders assert their control over teams through the Scum master and see them as a project manager. Someone who tells the team what to and how to be organised. In a development that is truly agile, the Scrum master is a coach and enabler not a manager at all.

To enable teams to be self-organising we have to trust people. This is where, I think, a lot of organisation struggle. One comment I’ve heard is, my people are not good enough to be trusted. I see two issues here. One is that people won’t step-up if you don’t motivate them and trust them. The other is recruitment, do good people want to work in organisations that don’t trust and empower their developers.

True Product Ownership

The next area I don’t think a lot of organisations understand is true product ownership. This is about empowering someone, typically a product manager, to truly own the product they are producing. Once again it is trusting them. The product owner is the person the development team turn to, to understand the requirements of what they are building. If the product owner is required to constantly re-validate all their decisions with key stakeholders, they won’t be able to make timely decisions for the team.

The wider organisation needs to trust the product owner, but also allowed them room to fail. If a product owner is not trusted by an organisation’s leadership then it will be difficult for them to succeed. If trust can’t be established then the issue may be with training or hiring.

My comment about room to fail takes me to my next point.

Accepting Failure

One of the great things about an agile approach to development, if done well, is its ability to handle failure and to handle it quickly. As the saying goes fail often but fail fast. None of us have prefect knowledge, so we all get things wrong and the best thing is to discover those mistakes quickly and learn from them. The rapid iteration of agile allows just for that. Most of what we do and ask for is wrong so success comes from constant course correction.

"If we fear failure, that fear will percolate through an organisation, stifling innovation."

Organisation needs to be willing to accept failures in a positive way, not only accept perfection. Some organisations, even ones who believe they are embracing Agile, think constant management driven planning and requirements reviews will remove failure and mistakes. In the end, they mostly drive delay. If we fear failure, that fear will percolate through an organisation, stifling innovation.

Delivering shippable software at the end of each Sprint

With a Scrum based development, a release should be made every sprint, which are typically two weeks. This release should be good enough to go to customers, that is shippable.

What I’ve seen first-hand and heard from others is we often don’t enable the Scrum teams to do this. A Scrum team will finish development at the end of their sprint and then hand it over to a test and integration team who will then spend a further two weeks, or more, testing the product. What I’ve seen is the test and integration team will find problems that have to be fed back into the development team to resolve in another sprint. Quite quickly that two weeks to release working software ends up being three months. The organisation ends up thinking that the problems found by the test and integration teams proves they are needed. Though what it actually proves is the scrum team were not given the resources to fully test within the sprint, which typically means they need some form of test automation.

I’m not saying that every sprint must lead to a deployed product, that should be the product owner’s decision. But a sprint team should be enabled to deliver deployable product every sprint only then can Agile/Scrum deliver it’s promised value. If this seems impossible, then it is time to re-evaluate your organisation to see what it would take to make it possible.

Conclusion

If your chosen agile approach isn’t disrupting your organisation, then you are probably not doing it right.

Many organisations have shifting to Agile/Scrum software development to improve productivity, but with a lack of courage and commitment, they miss out on the transformation that Agile can offer. What is really needed, is for the organisations to transform, with Agile development as part of the overall transformation.