This is the sixth and final post in a series about building great software using agile techniques. The series began here.
Many people, managers and developers alike, view agile development approaches like Scrum and Kanban as just another way to write software. Once they decide to try an agile approach, they quickly realize how wrong they are. Agile development isn’t about writing software. We assume you already know how to do that. Agile development is about delivering software.
I’d like to expand upon and summarize my original premises as follows:
- Enterprise software development is complex and requires many skills. [Note: This series is not about small utilities or mobile apps. It’s about software systems built and used by large groups.]
- The agile manifesto is the definitive list of guiding principles and beliefs for agile development. [As such, it is a starting point, not an end game. We need more ideas.]
- Agile development encompasses several approaches including Scrum, Kanban, Lean, XP, DSDM, FDD, BDD and others. [All are valid and applicable in appropriate situations.]
- Applying agile development principles on an enterprise scale is much tougher than it looks. [Note: The Scrum of Scrums idea is merely a bandage.]
- The hallmarks of truly agile teams are simple — they are adaptive and resilient.
What does it mean to be adaptive and resilient?
One of the key differentiators for agile developers is change. I’m not referring to accommodating user requests for changes to the software. That’s easy. I’m referring to changing the way the developers work. Changing the development process. Changing the very rules followed by the team.
Such changes need to be discussed, arbitrated and applied frequently — such as at the end of every sprint or cycle. If you’re looking for the ultimate, tried-and-true way to build software, look somewhere else. Agile development is about adapting to the current business situation.
If you develop software in a business that is changing rapidly or in an industry that is highly competitive, change will come at you fast. Your team must be able to learn and adapt continually. “Evolve or perish” is a good motto to adopt.
If your team is adaptive, there’s a good chance you can also be resilient. The terms are related though resiliency goes deeper. Resilient teams bounce back. They recover from adversity and find a way to succeed.
If you’ve worked on enterprise-scale software systems, you know that things will go wrong along the way — some things will go very wrong and cause near panic on the team. Resilient teams will swarm. They’ll apply their collective skills. They’ll change the rules. They’ll find a way to move forward.
The Attributes
To become adaptive and resilient, several attributes are essential:
- The team must be highly cohesive, loosely coupled and decentralized. [See this post.]
- They must implement constant feedback cycles and continuous improvement. [See this post.]
- They must exhibit rapid responsiveness and swarming behavior. [See this post.]
- They must have diverse skill sets and share a common vision. [See this post.]
Does your software development team have these attributes?
Would you describe your team as adaptive and resilient?
If not, what’s missing and what are you going to do about it?
I hope you found this series of posts interesting and thought-provoking. Whether you agree or not, I encourage you to leave a comment and expand the conversation.