For a first article it seems fitting to discuss Agility and what I believe it means to “be agile”. Everyone has a different path. But no matter which road you take, there will always be questions about what it means to be truly agile. To many, it may seem like punching through the sound barrier. Once you burst through, you’ve finally made it. Many other people just consider it a process that just needs to have enough boxes checked. To me, agile is more a perspective and approach. The agile mind understands that there are always possibilities and improvements to be made. Agilists embrace a world that is changing and adapting to these changes requires both ability and mindfulness.
“Agility (noun) – the power of moving quickly and easily”
This is the definition from the dictionary. But, with software development, agility means even more. It’s often a balance of the power to absorb change and the need to maintain quality and drive innovation. You have to do more than just be able to pivot freely in order to be agile. You need to be smart, nimble, and creative. Luckily the 12 principles of the Agile Manifesto give us a great blueprint for discovering agility in our software development processes:
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is the root principle behind any agile processes. Teams striving for agility must be focused on delivering value for customers. This is a great principle to discuss in a lot of detail and I’ll be coming back to it again and again in future posts.
Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The feedback between your customers and team is a critical link to being an efficient agile team. Agile teams should be building in these feedback loops into their processes such that they are constantly in tune with what the customer needs and wants are. Implementing the wrong requirements is waste. The best way to eliminate it is to be as close as you can to your customer.
Principle 3: Deliver working software frequently, from couple of weeks to a couple of months, with a preference to the shorter timescale.
This is the principle that drove processes like Scrum to be invented. Why is shorter better? It’s only better if you have feedback loops established with your customer. If you do, these short cycles of deliver will be followed by valuable customer feedback and allow the team to pivot early in the process. In order to be agile you should only deliver the software required to ensure that the customer receives the intended value. Any more is just waste.
Principle 4: Business people and developers must work together daily throughout the project.
It is often hard for business people to understand why this is so valuable. Developers need to make dozens of small decisions every day. Working closely with business people ensures that everyone is aligned around the customer and what delivering value means to them. Without close relationships, both sides will be working based on their own assumptions. Teams that work based on assumptions are wrong a LOT more than they are right. This creates a lot of waste and is also the breeding ground for bad politics. (us vs them)
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Sounds great. Who in their right mind wouldn’t agree with this principle? In reality, it’s a lot harder than most companies realize to actually build self-managed teams. For years, companies have worked in top down hierarchies that can create a stifling environment for agile teams. They don’t just disappear after a few training courses!
Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Another great principle that is a lot harder than it seems to implement in reality. Today teams are often not collocated. Many times they aren’t even in the same time zone. The offshore development model has teams spread across continents. We’ve come a long way with technical solutions that bring teams together. But, none of them help much when it is 3am in your teammate’s time zone and you really need some input from him. I definitely plan on a few future posts to delve deep into this problem.
Principle 7: Working software is the primary measure of progress.
I, personally would have pushed back harder on this principle. I would prefer to say that “Delivering value is the primary measure of progress”. I have seen plenty of working software that does nothing valuable for the customer. Regardless, this is still a good principle to talk with your teams on. Done should mean it is ready to deliver value to the customer. Too often in the past, software was considered “done” and then it still took many months before a user could get his hands in it. Focusing on delivering working software pushes the team to truly finish it before declaring it “done”.
Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Work/life balance is incredibly important for long term sustainability of teams. Unfortunately, corporate culture today is centered more around driving productivity by pushing people harder and harder. This may work for short term goals but not in the long haul. Agile teams need to have chemistry in order to function. Throwing a bunch of stress onto them 24/7 will cause them to break down. The highest performing teams I have seen are also the ones that like being around each other. Creating the right environment to make teams flourish should be a top priority for companies aspiring to be agile.
Principle 9: Continuous attention to technical excellence and good design enhances agility.
Obviously!! But, how to get there from where you are today? Dealing with a bunch of legacy code? Don’t have enough test automation to deliver in a short enough cadence? Have too many dependencies to be able to move quickly? Don’t feel bad we all have these problems. The best way to solve them is to start today! I’ll have plenty of posts with my ideas about this in the future.
Principle 10: Simplicity–the art of maximizing the amount of work not done–is essential.
Applying this principle from inception to delivery will help to build out the LEAN processes you need to become agile. Agile teams need to have the autonomy and confidence to trim waste from their projects. The power to move quickly and nimble demands a simple approach. Often it is hard for companies to trim things down to the minimum necessary to deliver value. This is why the next principle is so critical
Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
Committees are almost useless for making nuanced decisions. Especially ones that require simplicity to deliver. Companies love to call meetings to make decisions. In my experiences these are mostly a wasted effort. Agile teams that are self-organized and work on a daily basis with their business counterparts are able to make the best decisions. Waiting on some management hierarchy or committee to drive things is just another bottleneck to getting things done. But, empowering agile teams is not something that is easily accomplished in every case. They need the autonomy, tools, knowledge, and experience to drive their work independently. If you don’t have these types of teams today. Start building them!
Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
High performing agile teams understand the principles we’ve discussed above and are in a mode of constantly improving to try and meet them. High performing teams take retrospection very seriously. They always find some area of improvement they can work on. They review their work and tune their behavior at a regular cadence. Teams that don’t feel this is necessary may not be as engaged as they need to be.
For companies that are attempting an agile transformation, these principles, on the surface, seem to be fairly simple. But there can be much inertia within a company that can be in direct conflict against these principles. There are impediments of all sorts that will try and derail it. There is culture, organizations, geography, infrastructure, architecture, process, and politics that can easily sink any agile process. Plenty of companies undertake this journey and few actually realize the value of a truly agile process. Underestimating the resistance to change inside any organization is a sure-fired way to end up with a failed process. Transition is something that has to be managed over a long time period. Be humble and realize that it won’t happen overnight. As I continue to contribute to this blog, I would like to dig in depth into a lot of these issues and hopefully sharing my experiences will also be valuable for you. Let me know what you want to hear about.
— John