Agile Coaches' Corner Concepts Around Agile: Common Misunderstandings and How to Correctly Apply the Agile Manifesto Principles
Today on the podcast, your host, Dan Neumann, is going to be exploring concepts around Agile. This is a very important topic as a lot of times we go into an organization and find that there’s a lack of clarity or a lack of common understanding about what agility really is. Often, it’s the agile itself that is confused with a popular framework on the market, or, it is seen to be implementing a different methodology than what they already have.
In this episode, Dan will be exploring a couple of these misunderstandings around implementing agility, what exactly defines agile, and some of the principles behind the Agile Manifesto and how to correctly engage with them
Download the Manifesto for agile software development and principlesKey Takeaways
What defines Agile:
As the Agile Manifesto states: “We’re uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:
- “Individuals and interactions over processes and tools
- “Working software over comprehensive documentation
- “Customer collaboration over contract negotiation
- “Responding to change over following a plan
- “...While there is value in the items on the right, we value items on the left more”
- I.e. while there is value in processes, tools, documentation, contracts, and plans, the Agile Manifesto simply places more value on individuals and interactions, working software, customers collaboration, and responding to change
- These agile values have allowed the agile approach to be more successful and a better way of delivering software than many alternatives
- Agility is not binary; it’s not that you are agile or you are not agile — think of it more like a spectrum
Common protests and misunderstandings about Agile:
- Sometimes the phrase, ‘it’s not agile,” is thrown around like a weapon — but in the manifesto itself there is nothing about how the plan is to be displayed; it’s up to the people doing the work to determine how much documentation is appropriate
- Some argue that agile is simply hip and trendy for websites or that it only makes sense for delivery of a certain type of system, yet, amongst the names of the signatories on the Agile Manifesto there are people that do a variety of work (from extreme programming to Scrum to embedded software to financial systems)
- A common protest is: “We can’t be agile because we do _______,” but regardless of the type of work you do, you can still place value in the items on the left over the right
- You don’t have to be doing Scrum or paired programming to be agile
Three of the twelve principles behind the Agile Manifesto and how to correctly engage with them:
- The second principle: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
- How to engage with it: In some organizations, change occurs simply because their opinions change — but it’s key to really ‘welcome change’ when there is a substantial positive benefit from making it
- The sixth principle: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
- How to engage with it: though you can email and use messaging out of convenience, it is really important to engage in face-to-face conversation whenever you can (especially when communication seems to be going off the rails)
- The tenth principle: “Simplicity — the art of maximizing the amount of work not done — is essential.”
- What this principle means: Software development tends to be laser-focused on getting the requirements from the customer and doing all of the things that the customer needs… but the team tends to take an architecture mindset forward and overbuild (all these extra complexities create a lot more code to maintain and defers risk); AKA ‘gold-plating’
- How to engage with it: If you want to pursue more agility, one way to do that is to start looking with a critical eye at what’s being asked for and take a look at how you’re implementing it and really try to figure out where there are opportunities to not do something or not do something yet
- Remember: Delivering working software for your customer is the highest priority rather than serving the architecture
Mentioned in this Episode:
Principles behind the Agile Manifesto
Dan Neumann’s Book Pick:
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!