Ski Lift

So what is ‘agile’?

In this post I take a not entirely serious look at the origins and catalyst of the agile ‘movement’, born in the exciting and daredevil world of software development.

Ski LiftIt was deep into the evening of February 13th 2001. The wind pummelled the cables and towers of the ski-lift, creating an eerie, semi-musical cacophony of creaking metal and whirling wires. The icy snow rattled against the shutters. Behind them, inside ‘The Lodge’, the debate – which at times had raged almost as violently as the storm outside – came to an abrupt halt. The silence lasted a full minute as each of those present grappled with the implications of what they had created. One by one, they realised that the world would never be the same again…

Well I’ve no idea if this was how it really happened, but the date and location and possibly the bit about the raging debate are true, for it was on this day (or thereabouts) that 17 representatives (or “organizational anarchists” as they describe themselves) from a variety of technical disciplines and backgrounds created a “Manifesto for Agile Software Development”. And yes – it has changed the world.

A great many threads, influences and elements were fed into the cauldron during that meeting but probably two things, rightly or wrongly, have emerged from it to dominate first the world of software development and increasingly the wider world of business, over the subsequent two decades: the word ‘agile’ and the framework known as ‘Scrum’.

I will defer the debate about the word ‘agile’ until another post perhaps, but it is worth pointing out that for some at least, agile and Scrum are the same thing.

They aren’t – the former is a state of mind; a way of viewing the world and the latter is a framework – but it is easy to see how that belief persists due to the dominance of Scrum, which I will cover in another post. Throughout my blogs and other activities I consider ‘agile’ in its widest sense, as an umbrella covering a collection of varied principles, practices, philosophies, frameworks and techniques that fit in with the agile mind-set.

To understand this mind-set, and specifically why it has had such a significant impact on the business world, we need to delve a little further back in time to the bad old days of missed deadlines, blown budgets, disappointed customers and… waterfalls.

Once upon a time – before agile – most software products were developed in a sequence of phases using a methodology known as ‘Waterfall’. It went something like this:

Phase 1 – Requirements Analysis

The customer for whom the software is to be built is interrogated under the glare of powerful arc lights to reveal their inner most desires, which are written down in infinite detail to form the sacred “requirements document” – a tome often so large that entire forests are culled to supply the paper.

At the end of this phase, the customer is whisked away to a secret location until the start of phase 4, typically two or three years later, without any means of communication with the team developing their software.

Phase 2 – System Design

The analysts who conducted phase 1, pass the sacred document to a new group of analysts and return to their basement, for their job is done. This new team pore lovingly over the texts, extracting meaning from it all and writing new documents; sometimes embellishing their words with diagrams of great complexity and inner beauty.

When done, they too retire to their corner of the basement, leaving the new sacred ‘design document’ behind. The original sacred requirements document is carried carefully via a trusted cohort of anointed interns to a secure storage facility deep underground and is never looked at again.

Phase 3 – Implementation/Coding

In phase 3 the magicians are summoned. It is their job to mysteriously transform the sacred design document into code. Millions upon millions of lines of code. In fact it is believed that the greater the number of lines of code, the greater the quality of the finished product.

When the entire sacred design document has been transformed, the code is transferred to a special environment for the grand ceremony of User Acceptance Testing. Tradition has it that this milestone in the project should always happen at least 2 months behind schedule – often considerably more. By this stage the budget for the entire project should already have been spent. Twice.

Phase 4 – User Acceptance Testing

At this stage, the customer is brought back from their exile and presented with a partially functioning system. They are expected to remember what it was that they wanted at the start of the project all those years ago and to be wise enough to know how they should test it. Often they cannot remember the original intent, but either way, they have changed their mind anyway. The world is a different place now.

There is no time or budget to fix anything so the things that are most broken are ripped out.

Phase 5 – Operations

In this phase, a new group of technicians with no prior knowledge of the product attempt to install it (in whatever state it is in), into a new ‘production environment’.

The end users for whom it was built are then told of its existence for the first time. They play with it for a short while then spend the next six months generating a long list of suggestions about how it could be made into something useful, after which the machines upon which it runs are turned off and the process begins again.

Ok – to be fair, I am of course exaggerating – many will argue that in some situations a waterfall approach is a sound and effective way to develop software. It does have some great benefits at least on paper but joking aside, there are significant flaws in the concept.

The group of techno-anarchists who met at the Ski Lodge in Utah during the winter of 2001 managed to distil the essence of a new way of thinking that had been bubbling away in various places. They called it ‘agile’.

This essence is about many things but at the core is a set of values and principles that encourage flexibility, reflection, honesty, courage, trust and above all an in-built obsession with continuous improvement. All these things are achieved by replacing the huge, complex, heavily documented monolithic projects with a continuous stream of small steps, each of which deliver something of value to the end user.

These deliverables are released quicky and frequently so that everyone involved can learn about the product, therefore improving the effectiveness of the next small step (or increment) and ultimately delivering a more effective product or service. Due to the small steps, when things go wrong – and they do – the cost is small and the resolution is rapid.

When executed ‘properly’ this process has benefits for everyone concerned. The customer sees value almost immediately and receives a product that meets their real needs even when those needs are changing on a day to day basis. The timescales for delivering significant value are reduced considerably as are the budgets. The developers are empowered and trusted to ‘do what is best’ and to continually improve in all dimensions of their role, resulting in an improved quality of working life.

The only downside is that achieving the necessary agile mind-set, especially in larger organisations that are still organised with an industrial, ‘command and control’ mentality, is challenging and especially difficult to sustain. But the rewards are immense. I believe there are similar challenges facing adoption of an agile way of life in education but there is a similar scale of potential benefits. Potentially even greater.

I will explore this educational potential in further posts – but until then, why not join the Agile In Education UK Meet-up Group at https://www.meetup.com/agile-in-education-uk? You will be most welcome.

References:
The Manifesto for Agile Software Development: https://agilemanifesto.org/

The start of the journey

The start of the journey

In my first post I tell the story of why I have created the Progressive Education web site and the Agile In Education community group. What do I hope to achieve with the project?

Young boy with rucksackWhy am I so convinced that a progressive, agile way of thinking could have a profound impact on the education of todays young people? Why do I think it’s important?

I’m an IT geek. I’ve worked in computing for all of my adult life but for much of that time, training, coaching and helping others to understand and make the most of technology has been central. With a family full of teachers and educators I guess it’s seeped into my soul.

I was introduced to agile thinking in the form of Scrum just short of 10 years ago, although I’d been aware of various elements such as evolutionary delivery previously. It had probably occurred to me at some point that this would be a brilliant framework to introduce into education but it wasn’t until I read Jeff Sutherland’s excellent bible “Scrum: The Art of Doing Twice the Work in Half the Time” that I learned of Willy Wijnands.

Willy is a science teacher (or was – he retired from teaching last week) at Ashram College in the Netherlands. In 2011 he began experimenting with using Scrum in his classes and eventually formalised an education friendly version of the framework called eduScrum. Not only is this now well established in schools in the Netherlands but it has spread to 30 other countries including Russia, China, India and the USA. Another agile based approach to education is taking off in Australia with wide participation.

So back to the questions. Why does anything need to be done?

The simple answer is that education of our young people is no longer fit for purpose – not a situation that is the fault of teachers, may I add. The current system, at least in the UK, has its roots back in the 19th century and particularly in recent decades, has effectively become a funnel leading to a narrow-minded focus on examination results.

Try a simple experiment. Ask the next 10 people you meet whether, since leaving school, they’ve used anything that they learned in order to pass their school exams. The school system trains people to pass exams. A skill that in the majority of cases is of little or no direct benefit to them when they get out into the real world. Teachers need to be better empowered to support and facilitate genuine learning in their classrooms. Children need to be more engaged in their learning and better prepared for their future. Businesses need young people better equipped to help them survive in a rapidly, perpetually evolving landscape.

We need to replace the existing system with something more flexible – something that equips young people with the skills that they need to survive in a world that is radically different from the world of 100 years ago. A world that requires flexibility, initiative, creativity, trust, openness, respect, courage, teamwork, collaboration… and failure.

Failure is good. Failure is how we become better people. We (and our children) need to learn how to embrace failure and use it to our advantage. This is what businesses expect (because of agile thinking). Is it fair on our children to raise them without giving them the skills that they will need in the real world? Education should be about more than accumulation of subject knowledge – it should be about making us more effective (and happier) individuals.

I believe that learning to adopt an agile mind-set, through Scrum or a similar framework can provide the answer for our education systems – and there is a growing movement around the world that believes the same thing. The journey getting there is not going to be easy – there are enough ‘agile’ failures in the business world to tell us that – which leads me to one final point in my tirade.

‘Agile’ is not a magic bullet – a one-size-fits-all tick list of actions that if you follow will immediately solve all of your problems. Agile, or perhaps ‘agility’ is a mind-set; a way of thinking. The businesses that fail in their transformation journey typically ‘do agile’. The ones that are successful become agile. They take small steps. Sometimes they fail but always they reflect, learn and improve. Continuously. That is being agile.

So what do I hope to achieve?

Of course, it would be fantastic if after reading this, some high powered influencer gave Boris a call and triggered a revolution resulting in the immediate redefining of the entire structure, operation and meaning of education in the UK to the ultimate satisfaction and happiness of every man, woman and child in the country. I’d accept that, of course, but more likely…

If I want agile to succeed, perhaps I should treat the challenge with an agile mind-set. That begins with a small step. Any step. We’ll see what happens, learn from it and take another step that will hopefully get us closer to our destination.

That first step is the creation of an online community at https://www.meetup.com/agile-in-education-uk to explore the whole arena of agile thinking in education. Through the community I hope to build awareness and an appetite to take other first steps on new agile journeys.

If I can influence one teacher who in turn improves the chances of one pupil to be happy and successful in their life, then every moment I spend on this mission of mine will be worth it.

I hope you will join me on my journey.

Andy Bleach