Are You Forgetting Your Agile Values?
Just in case you needed a reminder, here is a brief litmus test to see if you are implementing your Agile framework the way its originators intended.
Join the DZone community and get the full member experience.Join For Free
A while back I wrote why sometimes Agile will fail. In this post, I will focus on the specific misunderstandings of Agile values. When people ask if you're Agile, they basically think:
- Do you have stand ups?
- Do you have retrospectives?
- Do you have stories?
- Do you use yellow Post-Its?
Such ideas belong to an Agile process called Scrum which is the most popular Agile process, but not the only one. There are other processes, such as Kanban, RUP, and XP. You don't necessarily have to be Scrum.
For me the most important thing that came from Agile was the actual manifesto. It should be read by everyone working in software at the beginning of every year and at the beginning of every project. Then it should be discussed with team members and people should be encouraged to give specific examples they have of the values and principles detailed in the manifesto. In this blog post, we'll have a look at the values.
8 Values, With Emphasis on 4
There are four points which detail 8 values in the manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Then there is the very important sentence: "That is, while there is value on items on the right, we value items on the left more." It is worth saying that sentence twice. Maybe three times...four times...whatever it takes so you never forget it. Why? Well let's take them one by one
Individuals and Interactions Over Processes and Tools
So does this mean if you are Agile do you stop worrying about process? No. No project can ever be successful without process. From an Agile perspective, it means you value process. But, you value individuals and interactions more. For example, say you spend lots of man hours in a process that isn't really adding value to the project or customer. When you look at this critically it is because developers and testers don't talk to each other. Instead, they have a convoluted process so they think they can blame each other when a production defect happens. Lots of man hours goes into this. But, it would be much more efficient if they talked regularly to each other which then negates the aspects of the process which are making it convoluted. So the challenge is two fold:
- Ensure people talk to each other regularly
- Ensure your processes are efficient
So for example, it makes more sense to have a regular show-and-tell than no interaction whatsoever and a massive delivery at the end where you are hoping you will get customer satisfaction because of some long complex process. Aim to make individuals and interactions in the heart of your processes.
Working Software Over Comprehensive Documentation
This is a classic misunderstanding. Somebody wants comprehensive documentation for some complex functionality and a developer retorts: "Hey Dinasour, this isn't waterfall, there is no need for detailed documentation." Wrong. Documentation is still required. The point here is that with Agile you shouldn't be spending massive amounts of man hours on documentation when your software is riddled with bugs. It is more important that your software works. This means more time should be spend on excellent automated tests that have sufficient functional coverage. This isn't always easy to do but you should ensure this is done.
Customer Collaboration Over Contract Negotiation
Thirdly, do you stop doing contracts agreements with customers on your projects? No. The point here is you spend more man hours with meetings collaborating with customers than you do teasing out a contract with lawyers. Instead of spending a massive amount of time to get sign off on a massive project, you should collaborate through the life cycle of the project, breaking it up into small increments, taking on board feedback, and working together towards a common goal: project success.
Responding to Change Over Following a Plan
Lastly, do you stop planning? Of course not. But again, what is the point planning down to the nitty gritty if you cannot even respond to change? Could you imagine a customer asked for a tiny change to how a UI was displaying data and the developer team respond with, "Sorry, that wasn't in our 6 month plan"? It is paramount that architecture facilitates reasonable change and if it can't the project will struggle to really embrace an Agile philosophy.
Agile is actually about putting more constraints on your software methodology. As an analogy, the REST architecture style puts constraints on your architecture like the uniform interface, statelessness, and caching capabilities. The idea is than by sticking to these constraints (and that's a technical challenge), you get benefits. In the case of REST, your architecture will be more scalable, extensible and lead to much higher developer productivity for API consumers. In the case of Agile, by sticking to the constraints of valuing 8 key concepts but putting even more emphasis on 4, your project will have greater chance of success.
Published at DZone with permission of Alex Staveley, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.