Agile Values in Action
Take a look at this article as a reminder that the Agile mindset begins, not with a framework like Scrum or Lean, but with the Agile values
Join the DZone community and get the full member experience.Join For Free
What comes to your mind when you think of Agile? Is it Scrum or another particular set of Lean processes, or is it a way of thinking and behaving? Many people I come across equate Agile with Scrum – wrong. Many people think that using specific practices makes their teams Agile – wrong. What I’ve come to realize over the years is that Agile is mostly a mindset – a way of thinking differently about software development. I’ve found that sprints, user stories, daily stand-ups, and other process-related practices can still lead to failure – unless we also change the way we think.
Agile, on paper, is simple – the Agile Manifesto’s four values, and 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 mean different things to different people – here is what they mean to me.
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, the best tools and processes in the world won’t save us. Processes and tools are important, it’s just that they are not as important as putting the right people together and helping them communicate and interact effectively with each other, with stakeholders and with others that support their efforts.
Working software over comprehensive documentation. If you ask a stakeholder if they’d rather have a 100-page document describing what you intend to build, or the working software itself, what do you think they’ll pick? People have an easier time understanding something they can see and use, rather than a document describing what they may see in the future. Documentation has its place, but remember that the primary goal of software development is to create software, not documents.
Customer collaboration over contract negotiation. Only our customers can tell us what they want. OK, they may not have the skills to tell us exactly how a system should work, and they may not get it right the first time, and they’ll probably change their minds (several times). Working together with our customers can be hard work, but that’s the reality of the job. 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.
Responding to change over following a plan. People change their priorities for all kinds of reasons. As progress continues on our projects, stakeholder’s understanding of the problems and what we’re building changes; business environments change; technology changes over time. Change is a reality of software development – a reality that our development process has to 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, in summary, 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.
Opinions expressed by DZone contributors are their own.