Let’s start by understanding what comes to your mind when you think of Agile. Is it Scrum or a particular set of lean processes, or is it a way of thinking and behaving? Some people equate Agile with Scrum, which is incorrect. Some people think that using specific practices makes their teams Agile, which is also incorrect. Then, how do we define agility correctly? What we have come to realize over the years is that agility is really a mindset – a way of thinking differently about software development. Sprints, user stories, daily stand-ups and other practices can still lead to failure, unless we also change the way we think.
Agile, by the books is simple – it is expressed in the Agile Manifesto’s four values and the twelve principles that accompany it. In practice, however, learning to think and behave with agility can be more difficult. A culture of agility means embracing ideas that many of us are uncomfortable with, or even fear.
The Agile values are perceived differently by many of us; let’s elaborate.
1. Individuals and interactions over processes and tools:
Teams of people build software, and to do that they need to work together effectively. Two critical factors in successful software development are the people on the team, and how they work together. If we don’t get this right, even the best tools and processes available will not make us succeed. Processes and tools are important, but putting the right people together and helping them communicate and interact effectively with each other, with stakeholders and with others that support their efforts is more important.
2. Working software over comprehensive documentation:
When a stakeholder is asked to choose between a 100-page document describing what we intend to build, or the working software itself, they are likely to pick the latter. People have an easier time understanding something they can see and use, rather than a document describing what they may see in the future. As important as documentation is, the primary goal of software development is to create software, not documents.
3. Customer collaboration over contract negotiation:
Only our customers can tell us what they think they want, but they may not have the skills to describe the most efficient or user friendly functionality. Working together with our customers can be hard work as they may not get it right the first time and they’ll probably change their minds several times, but that’s the reality of software development. Having a contract that specifies everyone’s rights and responsibilities may be needed due to corporate governance, but a contract isn’t a substitute for good communication and collaboration. Successful development teams work closely with their customers and they invest enough effort to find out what their customers really need.
4. Responding to change over following a plan:
Customers change their priorities for many reasons. As progress continues on our projects, stakeholder’s understanding of the problems and what we’re building changes, business environments change and technology changes over time too. Change is the reality of software development – a reality that our development process must reflect. More often than not, change happens because someone discovered a better way to do something. Why wouldn’t we want to incorporate changes for the better into the software we deliver? Agile embraces change!
So, while Scrum, Kanban and other framework practices are important, practices alone can still lead to failure. The Agile values are generally harder to incorporate into our development efforts, but they are the core of agility, they make Agile more sustainable in the long run and they help maximize the tremendous benefits Agile has to offer.
Do you agree that Agile Values are beneficial for software development? Share with us your thoughts with us.