When can agile coaching help you — and how?
Everybody has heard of agile but only few know what an agile coach does and even less know how to interact with an agile coach in order to get the most benefits of such collaboration.
If you own a business, you have a well-tested business case and you are happy with your current customer satisfaction and employee satisfaction, then probably you are one of these exceptions that have reached the desired state, you don’t need to go agile, you are agile already. But what if you have a well-tested business case and you want to improve customer satisfaction? What if you want to be more successful in your very own definition of success? What if you want to improve just a subset of your internal processes? What if you are not the owner of the business? It’s easy to get lost in so much information and misinformation; and so many people following terms blindly! The result is lack of clarity of the desired end state, of the things you can do, of the control you can have in your journey and of the way to start. Let’s see how agile can help you.
To change human behaviour, whether it is about the mindset of the customer or the internal corporate culture, thinking is not enough. It’s tempting to just pick your favorite search engine, search for a term you heard in a discussion around he watercooler at the office; or spend five minutes reading a blog post or even train all employees and expect that the improvement of your Key Performance Indicators is now just a matter of time. It’s tempting because in recent years, as consumers we are used to trade money and time on the web and expect to get it instantly. In management, this is still tempting, too, even though Fred Brooks¹ wrote in 1987 that, contrary to hardware development, “there is no silver bullet, there is no management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity”. But changing human behaviour is not like that, it needs you to take action and usually it is a marathon, not a sprint.
Why you need an agile coach
The first step to mitigate any risks is to have a coach in your journey, someone who has done it again, not necessarily in every step you take, but on a regular basis. The coach knows that everyone has a capacity to change which is not the same for all, it changes over time and can be altered. He also understands the team dynamics. The coach can keep track of the number of experiments introduced in the current month/year, the number of experiments finished in the current month/year, the initial targets, how was the outcome compared to the target and unexpected things you learnt. Similar to a sports coach, who needs to know whether the athlete feels ready to do more this time or feels being at risk of injury, the organization needs to follow the value of “Customer collaboration over contract negotiation“ with the coach by providing enough context.
If the organization of the client hasn’t designed the desired state, and is not aware of the importance of taking action, the coach might start a pilot project, demonstrating success in a way familiar to them, and for that “Responding to change over following a plan” is ideal. More specifically, the client and the coach need to identify a first change that is radical enough to respond to, over following a plan but not in a way so radical that an important plan will get missed. Then, depending on the progress of this low-risk iterative process, the “capacity to change” of the same people might be improved as long as the human factor is always taken care of.
In other words, a more descriptive word than agile for such a process is the word adaptive.
The acronym PDCA for “Plan Do Check Act“ makes it clear that apart from taking action to “do” by implementing a change, you need to “check” which might need more information or people than you used to have and “act” in which case acting is taking action to respond to change and is tempting to skip it as it is the most radical step. However, at PDCA people might plan everything beforehand without trying to identify quicker iterations just because they saw the first letter P which stands for Plan and thus completely missing the whole point of adaptivity.
There are methodologies based on the principle of “Responding to change over following a plan”. One of them is prototyping to test one aspect with departments, vendors or customers. The benefit is responding to the expected change without investing now in the whole thing. Another methodology is estimating in a particular level of granularity. The benefit then is responding to the expected effort of people and resources without having to wait for the whole duration. Another benefit is that it avoids practices that are inflexible, demotivating or even misleading. Both methodologies, prototyping and estimating are trying to put us earlier in the situation of being able to respond to change. However, without experiencing the basic principle in practice, it is easy to miss the benefits of methodologies and that’s a guidance to expect from a coach too.
The above values along with the values of “Individuals and interactions over processes and tools” and “Working software over comprehensive documentation” formed the agile manifesto² signed on 2001 by 17 people known in the software industry along with 12 principles. It’s interesting to note that the term Adaptive Software Development (ASD) was reserved as a trademark by Jim Highsmith since 2000 even though it could more easily describe part of the manifesto with just one word, adaptive. Thus, the agile manifesto is sometimes described through success stories of software companies with a small number of employees due to their inherent ability to adapt to changes and disrupt markets. However, since then, the agile manifesto has triggered the creation of frameworks that target organizations also outside of the software industry that might have many employees. As an example, a company that is neither a startup, nor a software company (nor affiliated with us) and has adopted a scaled agile framework is Outokumpu, the largest producer of stainless steel in Europe.
Agile Frameworks
SAFe³ and LeSS⁴ are examples of scaled agile frameworks, with the first one being more prescriptive and thus with more material and certifications around it which have made it a big success in US. Europe has started adopting it starting from Scandinavia. In the US the public sector has also realized that they can benefit from SAFe. Particularly, the Defense Innovation Board of the Department of Defense even issued a document to “provide guidance to DoD program executives and acquisition professionals on how to detect software projects that are really using agile development versus those that are simply waterfall or spiral development in agile clothing”⁵. LeSS is a framework with less terms than SAFe and it has evolved from the telecoms and finance industries.
But before you start thinking about frameworks, you need a structured approach and you need to think of how to hire people aligned with your corporate values, which are your corporate values, how you apply them daily and how you reinforce them.
At Found.ation, we work with organizations to help them become agile by assuming the role of an agile coach. We follow a structured approach, starting with an assessment of the current business agility, we detect KPIs and key training needs and set an implementation plan template with a low risk case. Learn how we do it and how we can help you.
[1]: Fred Brooks is a computer scientist who got the Turing award in 1999, known as the Nobel Prize of Computing.
[2]: Agile manifesto
[4]: Large-scale Scrum
[5]: Detecting Agile BS
