Introduction

Warning – This is a long article! It was originally a paper I wrote back in 2018 in response to a question posed by a Scrum Master, which I took a little too seriously at the time.  

The questioner is looking for ways to improve adoption of the Agile Principles and Manifesto in everyday activities. This attempt at an answer aims to look somewhat deeper in search of a response to see if it’s possible to align one’s own core beliefs with the Manifesto and Principles, which in turn may provide a stronger and more lasting connection.

Why adopt Agile?

To get to the how, we must first understand the why. So why do we want to adopt the Agile Manifesto and the 12 principles in the first place? 

To get to the why we need to understand the basic needs driving it. One must not lose sight of the overarching goal. Agile is a methodology with the purpose of achieving an end goal. 

What is the goal?

• Better software?
• Greater productivity?
• Larger profits?
• Faster delivery?
• More customers?
• Happier customer?
• All, some or none of the above?

The list can go on and on. Goals depend on your perspective, experience and where you sit in an Organisation. A Company Director may be less worried about Software Quality (at least directly, indirectly this could be a factor if there is a perceived quality issue) and maybe more about Balance Sheets and profitability, whereas the reverse may well be true for a Software Engineer. But there must still be a common thread tying all this together. 

Choosing the goal of Customer Satisfaction, as we can likely assume most of the items on the list (and beyond) can stem from this. Like a chain reaction, if the customer is happy, their business can be retained, and they are more likely to purchase products and services and even recommend them to others. By delivering great software on time we can strive to maintain and increase this positive situation. It’s not to bold to then say that Customers are at the heart of the Company’s goals, as without them there is no Company. Now we have defined this, everything else can be considered downstream of this goal and should therefore always be able to relate back to this (backwards compatibility).

Achieving the goal

With a focus on Agile, how do we make Customers happy? The inverse can also be examined as it is just as important to know what makes a Customer unhappy which we will examine later. 

For a software project, a non-exhaustive list (in no order) of what might contribute to a Customers overall satisfaction could include the following;

As a Customer I think I’d be happy to be given what I wanted on time and on budget. I’m even happier when I get more than I expected – so if I’ve been given what I asked for there can be no complaints right? 

Well maybe not. For starters IT/Software projects have a history and reputation for being anything but on time and on budget, but let’s park this for a moment (and assume we are on time and budget) and focus on ‘Delivering what was asked for’. Great, you have got what you wanted – Happy? No! why not?

For one, the requirements may have been misunderstood or misinterpreted leading to conflict.In addition to this possibility I do believe that Customers, and in more general, Humans more often than not, just don’t know what they want. A great quote from Henry Ford on the Model T Ford…

“If I had asked people what they wanted, they would have said faster horses.”

Henry Ford (apparently)

(There may not be any evidence he said this, but I’d like to think he thought along these lines).

Also, take the iPod, no one was asking for a device that could store 1000’s of songs, we had the Walkman, it played music, it worked. Now look at where the iPod and in more general terms the Smart Phone has taken us over the last few years – That could never have been planned and asked for up front.

Creativity

Contrary to popular believe creativity rarely (if ever) comes from a one person or a eureka moment. Sure, one person often takes the credit and may make a significate leap or contribution (or practical application), but in reality, any great innovation has a long history of many people working collaboratively and building on each other’s work over time.

I recently read a fantastic book, “The Innovators” by Walter Isaacson which looks at the dawn of the Digital Revolution. Looking at the history of the Computer what became apparent to me from reading this book is that a Computer didn’t just appear, nobody asked for it and at the time people thought they didn’t need it (now we can’t live without them). It was a culmination of thousands of people, working together over 100 years to bring about a computer. This then continued to evolve into what we have today and will continue to evolve yet further and no doubt in ways we are yet to anticipate.

So what conclusion can be drawn from this?

1. People don’t always know what they want – Some requirements are unknown
2. The best ideas are the product of many different sources – Collaborative 
3. Ideas evolve over time, with co-operation and constantly evolve – Iterative

So, back to the question, how do we make Customers happy by delivering what they want, when they don’t know what they want?

One possible answer is to create an environment based on the 3 statements above.

• Accept there are unknowns and that we may end up in a very different place to where we thought
• Involve different people with differing perspectives (Customers – From Shop Floor to Director level, Stakeholders, Dev Ops, Test Engineers etc.)
• Accept that version 1 will not be the finished article, and that a product may never be truly finished.

Environment for Creativity 

So how do we establish this ‘creativity rich’ environment? Well we could start by constantly talking to Customers, Stakeholders, and End Users within our Organisation, showing them what we have done, getting feedback and altering course as requirements reveal themselves and sparks of creativity fly from all parties. 

In this spirit we now know and accept that requirements are not fully fixed, or all known upfront, as we will constantly be reviewing what we have done and what we will do base on new information and ideas as they become available.

If we accept that version 1 isn’t the finished product, then we can do lots of small releases (iterations) and be proud of each small change, knowing each one adds to the overall value and above all else know that it is current, relevant and not out dated.

Starting to sound familiar? If we agree and truly believe this is a good approach to increasing Customer satisfaction and that indeed is our goal, then every decision (large and small) we now make should support that goal – i.e. we now have some core beliefs and values to guide us.

The Opposite Approach

Let us just pause and look at the inverse of the above. Just assume for argument sake we don’t agree with the 3 statements, so they may read more like this;

1. Customers know what they want (or we do) and requirements are generally fixed
2. A handful of people have most or all the answers
3. We must deliver perfect finished software to meet all known requirements

We could follow the requirements to the letter (based on our interpretation), deliver on time and on budget, the Customer may even be happy with the result. But, just stop to think for a moment….

Have we missed a great opportunity? 

Have we removed large amounts of creativity by not working collaboratively? 

Have we now downgraded a sense of unity and synergy between Us, the Customer and Product?

It’s a very formal and clinical approach. You asked for it, you got it. 

Yes we delivered it, but could we have done better? Or did we just scrape home?

This of course assumes that we were able to accurately estimate and deliver the ‘known’ requirements in the first place.

This will possibly be viewed as a dig at Waterfall. Well maybe Waterfall is not what you think it is (or as originally intended). The original author of the white paper – ‘Managing the Development of Large Software Systems’ by Winston W. Royce for which Waterfall is widely accepted as being based upon suggested that the tradition elements of Design, Implementation and Test etc should all be done in as small a feedback loop as possible (hold on that’s Agile isn’t it?). Waterfall has possibly been mistranslated over the course of time and is now done in a way not necessarily intended from its roots.

I believe in this concept, but the implementation described above is risky and invites failure.

The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced. If these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. 

In effect the development process has returned to the origin and one can expect up to a 100% overrun in schedule and/or costs.

Core Beliefs 

Back to the ‘why’ and the Agile principles. The 12 principles are simply a set of beliefs that we can turn to in various situations to underpin achieving our goal. If we truly believe our goal and equally important, the way to achieve it (collaboration, feedback etc), then we now have a basis of the Why.

Why do we want to adopt the Agile Principles? 

Because they enable us to reach our goal.

Beliefs are a product of many external factors made up over many years and these can change over time depending on experiences. 

Assuming we agree our goal and broadly how to achieve it and if we believe the 12 Agile Principles support this, then the ‘how’ now becomes much easier. The hardest part is winning over the hearts and minds of people to adopt these principles in the first place. If people do not believe or commit to them, then the how becomes rather difficult as there may well be a lack of commitment, drive or will to carry them out.

The Power of Habit

Another great book, “The Power of Habit” by Charles Duhigg is well worth a read. We don’t think in detail about how to walk or drive a car. We can end up at a destination without really knowing how we got there – How? Habit. These complex actions are committed to the subconscious brain like sub-routines. To make a programming analogy, these sub-routines are performed by background threads in the brain, allowing the foreground tasks to going unimpeded. 

If we had to think about all the actions involved in driving a car we would never be able to do it, just like our first driving lesson. The conscious brain just isn’t capable of performing complex tasks with ease. Only when its committed to our subconscious brain can we do it with relative ease. 

So how does this fit with Agile? Well in a nutshell you’ll never be good at it until it becomes habit. The only way to make it habit is to do it every day until it’s programmed in the EPPROM (I mean brain). At first it will be hard to do and very slow, so it may seem not worth the effort, maybe you’ll think it easier to go back to the old default way. Of course, the default way was once hard and slow, but guess what – it has become habit so now is easy (well, easier maybe).

Read the Manifesto, read the Principles, and start putting them into practice. Take one principle at a time and focus on it until it becomes habit, then move onto the next.

In Conclusion

The only way to create a habit is if you want to do. You will have to make that conscious decision yourself and work towards it. The desire must be there, or it just won’t stick. Which goes back to the overall goal and what we perceive as the best way to achieve it.

In summary it is all about what you believe in. If you believe in something and you trust in it, then you do it. 

Use Agile to help adopt Agile. Make small incremental changes that add up to a greater lasting change (marginal gains), have a review periodically (Retro) to take stock of what you are doing and what you would like to keep or change, but always keep slight of the WHY.

Appendix A – Agile Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Appendix B – The 12 Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.