Agile Software Development sounds desirable yet at the same time a bit like wishful thinking. All that talk about delivering excellent products that delight the end-user and about being fun for you too, working with a great team…
Is that really possible or is it just a dream? Is going Agile worth the effort? Will Agile tools and techniques work for you and your business? Well, let’s dig in.
Agile is a mindset based on a set of values and principles. Agile Software Development is anchored in those and values the following.
Back in the 80s and 90s, the predominant project management method was the waterfall model. Widely used in construction and manufacturing projects, it required lots of paperwork, a fixed design, and release of the end product only at the end of the build phase.
Because software development is a complex activity instead of a complicated one like construction and manufacturing, many software projects went over time and budget and failed to satisfy the customer’s intentions and requirements.
A prime example was the UK’s National Health Service IT project which cost over £10 billion and didn’t work.
Something had to change and several different approaches sprung up in the late 80s and 90s.
Such as prototyping, Dynamic Software (or System) Development Method, Scrum, Extreme Programming (XP).
Then, in 2001, a group of 17 argumentative but successful software developers gathered to discuss better methods of software development.
They agreed software development needed to be adaptive to change, customer-oriented and value-driven. They summarized their discussions in a manifesto listing 4 values and 12 principles essential for successful software development: the Agile Manifesto.
The 12 principles are common-sense guidelines about what it looks like to deliver on one or more of these values. You can read all of them in this infographic.
Agile is about choosing to act according to values and common-sense principles that deliver value in a way that’s sustainable for everyone involved.
CEO Anthony Fox-Davies explained it as looking for ways around obstacles, seeking solutions that deliver excellent quality.
To do that, you need to foster collaboration and meaningful interactions. And that demands focusing on humans and fostering respect and trust to improve everyone’s life: including the customer, the end-user and the developers.
Applying that mindset to working in software engineering promises to deliver results like these:
Getting there takes intentional effort and is not always easy to stick with.
The project skills used in Agile Software Development transfer easily to other kinds of product development. Rudi Schenker writes on its application to other engineering fields, including chemical, electrical, control and instrumentation, amongst others.
The Agile Software Development Life Cycle starts with a customer wanting to solve a problem with new software.
The team or teams that’ll develop the software will collaborate with the customer’s business professionals to work out what the end-users need the software to do.
Together, they map out and prioritize the product’s required features and decide on the features that will make up a minimum viable product — the features essential to delivering in the first release.
After that it’s onto iterative and incremental development for the life of the product.
Most organizations start their agile journey by shortening the waterfall to their iteration length. Basically, they’re executing mini-waterfalls in short succession.
True collaborative agile is different. It does away with traditional waterfall phases (analysis, design, implementation, testing, delivery, and operation), but it doesn’t do away with the activities performed in these.
In true collaborative agile, a team takes on a single work item together. They hash out design, acceptance criteria, etc. for both the user and the operators together and then implement what they decided in smaller groups, for example using pair programming.
This can all seem like a huge waste of resources people’s time to anyone new to agile.
However, it’s more important to focus on the baton than the runners in a relay race — an analogy used in Lean manufacturing and software development. Getting the work to “done” and therefore the value to your customers sooner is more important than keeping everyone busy at all times. It generates more value for the business in the long run.
Getting the customer, or a customer representative, actively involved in and easily accessible to the team all the time will go even further in ensuring more value delivered sooner, as they can keep the team from going down feature rabbit holes that sound good, but don’t actually deliver any business value.
While agile is focused on delivering customer value sooner, that doesn’t mean cutting out good engineering practices. Yes, in the short term, that may speed up value delivery, but it’ll trip you up in the long run as the code “rots” and quickly becomes harder and harder to change.
This leads to more errors, more bug reports, and more time spent on fixing problems than delivering new value.
That’s why every agile framework or methodology needs to incorporate good development practices. For example through adopting Extreme Programming — the “Developer’s Agile.”
Speeding up doesn’t come from making people work harder or faster. It doesn’t come from cutting corners. At least not in the long run.
Becoming agile is like going to the gym: it’s about cutting the fat out of your process.
It’s why many agile frameworks, for example LeSS and SAFe, have taken a page out of Lean Manufacturing’s book and taken on flow management and queueing theory to help you make decisions about your process.
Waterfall is phase oriented and every phase builds on the previous one.
Each phase concentrates on a single activity — business analysis, functional design, technical design, programming, testing — for the entire product.
You can’t see anything working before everything has gone through the phases preceding actual programming and at least some features have been programmed. Course correcting in any phase means redoing a lot of work from the preceding phases.
Agile is value- and product-oriented.
You deliver working software right from ‘go’ and can see the product come to live as it grows. This allows much earlier feedback and course correcting as you go with minimal waste.
Teams still perform the same activities as you would in a waterfall process, but they do them collaboratively and for one small part at a time. This concentrates the back and forth between for example analysis and programming in a small period of time and benefits from the fact that everything is still fresh in everyone’s mind.
When you look into any agile framework, you’ll recognize the following key roles, though they may go under slightly different names.
In many agile frameworks, line managers and project managers don’t have any role. It’s why you can expect open and not so open resistance unless you help them redefine their role and value in an agile environment. LeSS has specific advice for you on this.
A delivery cadence is how often you release a new version to your customers. An iteration, or cycle, is how long a team works before pausing, reflecting, and planning the next steps.
Meetings in agile serve specific purposes, though they can go by different names in each framework. The meetings in an iteration are:
There may be similar meetings to coordinate the work of many teams, especially when the delivery cadence differs from the iteration length.
There are many other frameworks, tools and techniques used in agile working, and new products appear all the time. Try these newsletters to keep up to date.
Agile doesn’t work for everyone. Even Google still uses some waterfall methodologies and Amazon is described as Lean but not agile. But you can learn a lot from the pitfalls that sometimes cause agile to fail.
The biggest reason for agile failures is when people go through the motions. E.g. conducting prescribed meetings, but not, or not fully, adopting the mindset, the values, and principles. Sometimes not even good engineering practices. This is known as ‘doing’ agile rather than becoming agile.
You need management on board and participating in the processes. No management support is a sure way to disincentivize everyone to fix the obstacles to agile working.
Teams do not become agile or self-managing by declaring them so. Failure to help a team in this process is a common pitfall.
Though agile and compliance are not mutually exclusive, highly regulated systems such as healthcare don’t easily lend themselves to agile working.
The key to becoming agile is adopting the mindset and practices that make it easy to deliver a valuable product and keep it in shape so you can quickly respond to change in your customer’s requirements, business environment, and end-user’s needs.
Getting there is a journey and winning hearts and minds is key to keeping you going. Here are some steps to get you on your way.
Digité offers both Agile training and consulting services and can swiftly help get you and your team up to speed.
As an accredited trainer with the Kanban University, Digité’s training services include specialized training and certification on Kanban.
ICAgile offers accreditation
Both Scrum.org and Scrum Alliance offer certification courses.
Here’s a quick guide to agile terminology (which can be very confusing for newcomers).
The agile mindset is a way of thinking about (software) product development based on the agile values and principles laid down in the Agile Manifesto.
Agile Software Development Methods are another way of referring to the methodologies, techniques and practices used to develop software in an agile way.Some people refer to the use of agile methodologies or techniques as methods.
An agile Methodology consists of the practices that a team uses to deliver a task. Every team draws on different frameworks, techniques, tools and practices to develop its own methodology for a particular project. Drawing on a range of methodologies helps you become agile without reinventing the wheel. For more information, read What is Agile Methodology.
Frameworks tell you what to do, but don’t say much about how to do it. Teams and organizations have to fill out these frameworks with good practices for all the activities in software development.
Agile software development is desirable and it is not wishful thinking.
Despite the failures and disappointments that you can read about, there are many companies reaping the benefits.
Just bear in mind that you don’t become agile overnight.
It’s a process. There’s a lot to learn and a lot to unlearn.
But there’s also much to enjoy.
Working collaboratively, you feel supported. You know how to get help. You can have fun and work together. You trust the process and your colleagues. You love how you deliver more value sooner. You feel so much more productive and proud of your achievements.
So, go for it!
Start your journey to become agile. Get into the Agile Mindset and work toward happier, more productive teams who can sustainably be more responsive to your customers.