What does agility mean? Why do many software projects use Scrum or Kanban? Does it work for every project or team?
Browsing through different business networks or job ads, you read a lot about agile roles, collaboration, communities, mindset, methodologies, etc. Or take a look at tenders. Even organizations you never expected to do so want to use agile methods for their projects - sometimes without realizing what this means regarding necessary circumstances for the development team and a successful agile project.
That is why we want to share our insights from the practitioner’s point of view. No new inventions. No fancy new methodologies. Just an invitation for more awareness.
In this article series of three, we will look back at the past, starting with an important aspect: The reason why agile has evolved to that extent. Part two will evaluate the agile umbrella and how frameworks and methodologies reflect the values and principles. The third and final article will share insights into what can go wrong in Scrum projects since the Scrum framework is widespread.
Part 1: Doing agile
Many of us have an idea of what Scrum is about. There are events, roles, and artifacts. In most cases, we follow the process described and focus on our daily business.
Why does it perfectly work out in some cases? And why is it far from success in others? Isn’t the retrospective, for example, doing its magic? Does it just consume valuable time in which the team could finish other important tasks? After all, the Scrum guide describes each event. But why is it causing refusal or frustration? Because it is not just about knowing the mechanics but also about awareness of the goals when applying certain events.
What is agile software development?
In our professional life, we face various issues, impediments and challenges. We also find ways to overcome them.
That is what happened in the evolution of agile software development. Agile was not the one invention that suddenly appeared. It has been evolving for over 30 years. And it is for sure not a synonym for Scrum.
Back then, the field experience with classic waterfall projects identified room for improvement. Teams should be able to
- develop a contemporary product - not like it was designed years ago in some specification
- react to changes in the market
- improve in communications
- cope with uncertain product goals in the beginning
- respond to risks
With the commonly used approaches, that was hard to achieve. So, many smart people started to try things like Crystal, FDD, ASD, and Extreme Programming. The observations and learnings made ‘Continuous Improvement’ the heart of agile software development. Small steps were defined, applied, inspected and adapted to improve existing processes, thus enabling teams to fail fast and try again.
From a practical perspective, users don’t focus on the mere execution only but on evaluating activities. When realizing that the effort of refactoring is immensely high after finishing a product, you might try to find ways to tackle it earlier in the process or reduce the effort by defining coding agreements, and the team follows. And always remember: sometimes it takes more than one shot to hit the goal.
The advantage of continuous improvement is that, in most cases, the changes are small and still impact the overall approach. And this brings us to the literal meaning of the word “agile” so often used.
Agile is, in the field of software development, an umbrella term for approaches that share common values and principles. Those have their roots in the “Manifesto for Agile Software Development”.
The Manifesto for Agile Software Development (a.k.a. Agile Manifesto)
In 2001 in Snowbird, Utah, 17 software practitioners formed the Agile Alliance and wrote the “Manifesto for Agile Software Development”, documenting four central values of agile Software Development.
Side note: it is named the “Manifesto for Agile Software Development”, not the “Agile Manifesto” because the intent is to make software development more flexible, not the manifesto itself. This denomination, funnily enough, already indicates what the third article of the series will be about.
Back to Utah and the Agile Alliance. When looking at the website Agile Manifesto, you find four values.
4 values of agile software development
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Those values were no new inventions. They promote a baseline for collaboration, quality and customer satisfaction.
One drawback is that with these four values, you still have to worry about how to interpret and apply them. As practitioners, we often experience misunderstandings arising even at this stage. In the heat of the moment, e.g. one misinterpretation can come up: The right side of the statement has no value at all.
The cause for this interpretation might be that the introduction on the first page (“That is, while there is value in the items on the right, we value the items on the left more.”) is ignored.
Still, the left side of the statements is valued for good reason. But what would happen if e.g. you wouldn’t value processes and tools at all? You could end up with a Wild West scenario that makes collaboration very difficult. You can evaluate every value and think about scenarios in which ignoring the part on the right would be a bad idea.
The Agile Alliance and the respective website does not end by outlining those values. Furthermore, they formulate 12 principles. They are less abstract and describe more precisely how to meet the values.
12 principles of agile software development
- Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
The 12 principles help to create a work environment mainly focussed on communication, quick response to user needs, and market changes. Thus, the development teams and IT departments are enabled to improve on the pains of traditional waterfall methodologies.
Specific methodologies and frameworks further formalize many or all of the ideas presented in the Manifesto. The ‘agile umbrella’, a commonly used metaphor, captures the introduced ideas.
Find out what the agile umbrella contains and follow a concrete example how the Scrum framework applies values and principles in the second article of ‘doing agile & using Scrum’.
Claudine is a Scrum Master at Karakun in Dortmund. She is committed to agile ways of working. As experienced Java developer, she is aware of the technical and methodical perspectives of agile development. She serves teams and projects, facilitates workshops and fosters improvement in collaboration with enthusiasm and her experience.