I think we can all agree that agile is an over(ab)used buzzword and a misinterpreted concept these days. Similar to that other popular concept, productivity.
Well, inspired by some of the thought leaders in the field, I think and dare say that agility is a way of approaching work (and also life, why not?). So, bear with me and I’ll explain why.
Building Software in an Art
Building software is more like creating a work of art, it requires creativity in design and ample craftsmanship to complete. Software remains malleable, often illogical, and incomplete forever. Agile software development is based on fundamental changes to what we considered essential to software development a few years ago.
There is NO such thing as Agile Methods or Process!
Well, surprised? The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile.
For any organization the way teams works together is far more important than any process defined. While a new process can easily improve team productivity by a fraction, enabling your team to work effectively as a cohesive unit can improve productivity by several times. Of course to be eligible for such a big improvement you must be working at a fraction of your potential now. Unfortunately, it isn’t that uncommon in most of the organizations.
You need an environment where team empowerment and collaboration thrive to reach your full potential. Agile practices focus on giving teams and individuals ownership of their work and accountability to the team and organization, so that you can care to make things better.
We’ve never been disappointed by hiring someone who is less technical but is a great human who cares for others. We can teach tech pretty easily. But we have seen people who are strong technical people with toxic attitudes destroy a team.
Customer First
A great agile customer trusts the Development Team to find a solution for his ‘problem’. They are the experts with the used technology and have experience with building the product the customer has in mind. It’s essential to make the customer, the one who funds the software development, a valuable and essential team member. When the dead line gets close a traditional approach to reducing scope is to let the developers decide what will work properly and what won’t. Instead let the customer make scope decisions a little at a time throughout the project.
When your customer, or domain expert works directly with the development team everyone learns something new about the problem. True domain expertise and experience is essential to finding a simple, elegant, correct solution. A document can have plenty of information, but real knowledge is hard to put on paper.
Left alone programmers must assume they know everything they need. When asking questions is difficult or slow the knowledge gap grows. The system will get built, but it won’t solve the problem like one guided by an expert on a daily basis.
Changing Requirements
Perhaps the biggest problem with software development is changing requirements. Agile processes accept the reality of change versus the hunt for complete, rigid specifications. There are domains where requirements can’t change, but most projects have changing requirements. For most projects readily accepting changes can actually cost less than ensuring requirements will never change.
We can produce working software starting with the first week of development so why not show it to the customer? We can learn so much more about the project requirements in the context of a working system. The changes we get this way are usually the most important to implement.
There are no best practices
Yes! It’s true. There are no best practices. There are only some good practices that you can adjust and tweak in your context, so that they can match your situation and serve you properly and effectively.
Agile People accelerate the worldwide agile transformation through spreading the values of customer collaboration, energized people, learning organization, inspiring leadership and rapid change to all areas of businesses and organizations.
If you have great people on your team, you are more likely to succeed, regardless of the tools. The reverse is also true: You may have the best process and most expensive tools, but without highly skilled and motivated individuals, success will be difficult.
By focusing on people and freeing your teams from a process and structure-led response to disruption, your organisation can develop a culture that thrives in complex, unpredictable and rapidly changing environments.
However, here are the two basic ideas that most people agree upon when it comes to Agile software development:
#1 The Agile Manifesto
Agile software development is based on the Agile Manifesto, or The Manifesto for Agile Software Development:
“We are 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
That is, while there is value in the items on the right, we value the items on the left more.”
#2 The 12 Principles of Agile Software Development
There are 12 principles of Agile software development, which you can read on the Manifesto for Agile Software Development website.
Bend those Rules, If Needed
“Being Agile” doesn’t mean throwing out all rules and processes following the way of the old Wild West. Being Agile does mean working in a lightweight, highly responsive way so that you deliver your product or services in the way the customer wants and at that time the customer needs them.
There are rules, albeit not many rigid rules. After all, we are talking about being Agile here.
The Agile Manifesto and the 12 principles of Agile development are quite lightweight and hardly restrictive. So, how you actually put the Manifesto and principles development into practice can be subject to some interpretation. Especially if you are applying Agile methods to something other than software development—like managing or creating training programs—you have to make adaptations.
But, following the Manifesto and 12 principles in the spirit in which they were intended, I would say, is “Being Agile”.
In a nutshell, Agile is all about the 4 values and 12 principles mentioned in the Agile Manifesto.
