Mục lục bài viết

Overview of Agile Software Development

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.

Brief Overview

Agile is a mindset based on a set of values and principles. Agile Software Development is anchored in those and values the following.

Value-based: deliver value to your customer.
Putting people and their interactions first: work collaboratively and oriented towards the customer, to end up with happy customers, users, and development team.
Trust is essential. Not just within a team. Management needs to trust that everyone wants to do a good job and let the team manage itself to deliver results.
Communication at all levels of the team is vital. Regular feedback from customers and stakeholders keeps the team on track.
Working software as soon as possible means delivering value right from the beginning.
Incremental and iterative working means you take small steps forward and you course correct when the customer realizes a change is needed — usually thanks to seeing the growing product in action.
Fast results: breaking the end product down into bite-sized chunks and working on those chunks means the whole team gets to see working results within the first few weeks and cuts out finding you’ve failed a couple of years later.

Brief History

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.

This all makes sense doesn’t it? So why is Agile even a thing?

The 4 Agile Values are:

Individuals and interactions over processes and tools
Individuals and iWorking software over comprehensive documentationteractions over processes and tools
Customer collaboration over contract negotiation
Responding to change over following a plan.

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.

How does it work?

Everything starts with the Agile Mindset and the promise it holds.

The Mindset

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.

As Aristotle already said:

“Pleasure in the job puts perfection in the work.”

The Promise of Agile: Solutions to Problems

Applying that mindset to working in software engineering promises to deliver results like these:

Better alignment with (customer’s) business goals
Higher productivity
Higher quality
Reduced time to market
Improved customer/stakeholder satisfaction
Increased job satisfaction for the developers
Best results for the end-user

Customers and developers alike love it!

Getting there takes intentional effort and is not always easy to stick with.

The Wider Agile Picture

Extension to DevOps and DevSecOps

What it takes to operate a software product is often overlooked during development, making it awkward to keep the software running smoothly for its users. DevOps — Development and Operations — seeks to address that by putting developers and operators together in a team. By working collaboratively, they can reduce deployment time, fix bugs more quickly and extend the product life. On top of that, DevSecOps adds security experts to a team to keep your product’s security up to par with explicit security measures and helping developers avoid software constructs that could be exploited by hackers.

Agile Project Management

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.

Agile Corporate Cultures

The Agile Mindset does well in disciplines other than (software) engineering. Your marketing team, vendor management team and sales team can all apply it to their activities. Just about all regular corporate departments can benefit from becoming more agile.

Agile frameworks such as Disciplined Agile, SAFe, the Crystal Method and Kanban are suitable tools to help a corporation become more agile. They offer ways to optimize corporate organization by integrating agile and waterfall methods of working.

For more on this, read “Here’s Why (And How) Non-Software Teams Are Adopting Agile Methodologies.”

But let’s get back to agile software development.

Agile Software Development Life Cycle

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.

Iterative and Incremental Development and Delivery

Development and delivery in agile is iterative. Work gets done in short iterations, usually lasting 1 or 2 weeks. Sometimes up to 4. It’s also incremental because in each iteration you build small slices of working software that can stand on their own two feet.

Here’s more on this process. Iterative and Incremental Development: Refuse to Choose

Mini Waterfall Are Still Waterfalls

Most organizations start their agile journey by shortening the waterfall to their iteration length. Basically, they’re executing mini-waterfalls in short succession.

While there are benefits to doing this, there are also many drawbacks:

It keeps people locked in their traditional roles.
It maintains the waterfall phase gates, leading to a lot of (wasted) wait time and inventory queues of unfinished work.
Cooperation between people with different roles is generally better because the topic is still relatively fresh in the previous person’s mind, but it’s a far cry from true collaboration where people work together on addressing a work item.

Collaborative Agile

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.

Keeping Up the Pace

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.”

Cutting Waste to Speed Up, Sustainably

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.

Consider these examples.

Why produce documentation when you can create code in a self-documenting way and be testable in an automated manner at the same time?
Why produce designs when designers and developers can collaborate on implementation?
Why produce hefty user guides, when you can design a self-documenting interface with in-place explanations?

Similarities and Differences

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.

Key Roles and Responsibilities

When you look into any agile framework, you’ll recognize the following key roles, though they may go under slightly different names.

The Customer, or a representative, who contributes the business perspective.
The Product Manager, who acts as the link between customers, users, and teams. Teams still work directly with customers and users to clarify what they’ll create next, but the product manager brings them together. By not getting into the weeds, the product manager is free to do more forward looking work.
People from different disciplines work together on (a part of) the product in the Team. A team always includes the people actually producing the product, i.e. developers, designers, analysts, testers, and may include others.
The Coach helps the team and all its stakeholders to adopt the Agile Mindset and values, and work according to the principles. Some distinguish between team coaches and agile coaches, where team coaches focus on 1 to 3 teams, and agile coaches help the wider organization. The Scrum Master role in Scrum is defined doing both, but in practice the Scrum Master is often seen as a team coach.

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.

Key Meetings, Cycles, and Delivery Cadences

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.

Delivery cadences vary a lot. From quarterly deliveries, for example in many scaled agile frameworks, to continuous delivery and continuous deployment where users receive updates even as they’re using the product. In many organizations the delivery cadence is equal to the length of their iterations.
Iteration cycles tend to be 1 to 4 weeks. Most Scrum teams prefer 2-week Sprints, Kanban and Lean often work to the tune of a single week. Generally, the longer the iteration, the fewer benefits from learning and adjusting and getting better at practising agile.

Meetings in agile serve specific purposes, though they can go by different names in each framework. The meetings in an iteration are:

Refinement meetings to clarify what needs to be done for the work that’ll be taken on shortly. Some frameworks see this more as an activity than a meeting.
retrospective meeting to look back and learn, and take steps to improve your process in the following iteration.
A planning meeting to decide what the team will work on in the upcoming iteration and resolve any outstanding questions. The planning meeting for the next iteration should ideally come after the retrospective so that any lessons learned can be applied immediately.
An inspection meeting where the team presents what they’ve created during the iteration and receives feedback from customers, product manager, and other stakeholders.
A daily check-in meeting to keep the team focusing and moving forward to the goal of their current iteration.

There may be similar meetings to coordinate the work of many teams, especially when the delivery cadence differs from the iteration length.

Methods and Techniques

There are many frameworks and methodologies available that’ll help you on your agile journey. For example, Scrum, Kanban, Lean Software Development, and Extreme Programming.

You’ll also find frameworks to help scale agile to multiple teams and even throughout your organization. You’ll find a comprehensive but succinct overview in “6 Scaled Agile Frameworks – Which One Is Right For You?”

Here’s a quick look at some well-known techniques.

User Stories and Story Mapping to create a vision for the product, identify the individual requirements, and prioritize them in several releases.
Behavior Driven Development to facilitate communication and collaboration with your customer and produce a product that can be verified in an automatable way.
Test-Driven Development, which stands alone but is also a part of Behavior Driven Development, to inform the design of your code create a safety net around it that’ll reduce anxiety over breaking anything with a change.
Refactoring is a technique used in Test Driven Development and strongly advocated by Extreme Programming to keep your code amenable to change.
Another method strongly advocated by Extreme Programming, is Pair programming, or pairing. It’s a means of collaboration, training, and preventing bugs (two see more and know more than one).

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.

Common Pitfalls: Why Agile Doesn’t Always Work

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.

Doing agile

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.

Lack of clear direction from the top

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.

Inadequate coaching

Teams do not become agile or self-managing by declaring them so. Failure to help a team in this process is a common pitfall.

Not everyone is suited to agile

Though agile and compliance are not mutually exclusive, highly regulated systems such as healthcare don’t easily lend themselves to agile working.

Vested interests

The agile way of working demands radical change that often is at odds with vested interests and long-standing organizational structures and reward systems. Often especially so in large corporations and governments used to rigid contracts and top-down direction.

Remember, you can still use your Agile Mindset and some agile frameworks even if a customer insists on a waterfall approach such as fixed costs and fixed delivery times. For example, here’s how Kanban can help.

Getting Started

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.

Above all, develop and use your own Agile Mindset.
Employ agile coaches to get you started and keep you on track.
Identify agile leaders within your business to ensure understanding and sponsorship.
Train managers as well as your software developers so they don’t talk past each other.
Get enthusiastic key people certified in agile methods and frameworks.
Get enthusiastic key people certified in agile methods and frameworks.
Invest in suitable IT programs that support your agile working.
Identify the opportunities for more agility in your current development methodologies.
Introduce frameworks that will work in your business.
Look at tools like Kanban to set your goals, monitor progress and achieve results.
Introduce change incrementally so that it is not overwhelming for all concerned.

Recognize that it will take time to make all the changes needed to move to a fully agile business model. Depending on the scale of the Agile adoption in your enterprise, there are several tools available that will support your journey – you can see Digite’s tools here https://www.digite.com/products/

Books and Articles

Coaching and Training

Digité offers both Agile training and consulting services and can swiftly help get you and your team up to speed.

Certification and accreditation

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.

Untangling Some Agile Terminology

Here’s a quick guide to agile terminology (which can be very confusing for newcomers).

What Is The Agile Mindset

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.

What Are Agile Software Development Methods

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.

What is Agile Methodology

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.

What Are Frameworks

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.

Champion Agile 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.

FAQs

What is Agile Software Development?

Agile Software Development is the process of creating and maintaining software using an Agile mindset and practices, particularly iterative approaches.

Why is Agile so popular in the software development space?

As The Agile Manifesto was created by software developers with the software development process in mind, it is widely adopted by software companies worldwide.

What is an SDLC?

SDLC stands for Software Development Lifecycle. This is the set of practices, or steps, that a software company uses to create and maintain their products.

What are the steps in the Agile software development life cycle (SDLC)?

Companies tend to take different approaches to their SDLC. Typically, the steps in Agile SDLC include Conceptualization, Inception, Iteration, Release, Maintenance, and Retirement.

What are examples of Agile Software Development Frameworks?

There are many Agile frameworks that software developers can use. Some examples are: Scrum, eXtreme Programming (XP), Adaptive Software Development (ASD), Lean Software Development (LSD), and more.

Agile Software Development: What It Is & What You Get Out Of It