Over the years I have seen many teams and organizations who start on their journey towards Agile product delivery make the mistake of thinking that Agile is easy, promotes freely changing direction and worse will fix all of your issues and make everything better quickly and easily. The truth couldn't be further from the reality. There is no such thing as a perfect software development delivery process. Unlike production lines for things such as automobiles where you have the same pieces going to together each and every time and each piece has a specific functionality, tolerance and timing, software development is the exact opposite.
Software development is about meeting changing needs across the dynamic nature of business For example - You wouldn't see an automobile company add anew feature to a car on their assembly line over a 2-4 week time period. They need time to design the entire process and ensure that the production line is capable of accepting the new change.
Traditional software development tends to align a bit more to the automobile example and in fact there are times where this type of rigid, pragmatic approach to product delivery is actually the correct process (Agile isn't for everyone nor for every situation).
However for those that are going to move to Agile you need understand that the type of discipline that you might use in the automobile example actually needs to exist in your Agile processes, seriously you ask? Yes - You need to be able to deliver high quality, well-tested and fully functional pieces of software every two weeks. Now are you seeing how difficult Agile can be?
If you think Agile is easy, then you are already on the path to failure and unmet expectations.
It is very common for teams who are moving to Agile to take their interpretation of the Agile Manifesto to the unhealthy extremes, for example:
- Working Software Over Comprehensive Documentation
Many teams I've worked with take this to mean NO documentation and that couldn't be further from the truth. We value working software over the need for documentation but I've never believed that you can have long-term success with your product without delivering some levels of documentation. Without documentation your software knowledge becomes tribal and when your tribe leaves the team or your organization, well so does their knowledge.
There are way for teams to build documentation as part of their daily Sprint development work. Using the combination of user stories and Behavior Driven Development (BDD) acceptance criteria as the foundational elements of your work you are creating your documentation as part of the work needed to deliver quickly. The great value in BDD is that the acceptance criteria is written in English syntax and then translated into test automation.
This process of writing stories with BDD is supported by Gojko Adzics book, Specification by Example and allows us to deliver light weight documentation during our sprints. I often see teams adding a story to a future sprint to handle their 'documentation' requirements of their previous work but I haven't seen this work long-term. Functional development, dealing with bugs, etc... will ultimately push these stories down into the backlog, never to be seen again.
The process described above is not easy, but it can be done and the teams that can get to this level of capability will succeed in driving value to your organization every two weeks.
One of the things that I consistently tell organizations moving to Agile is that it will highlight every current weakness of your product/software delivery methods. Agile is a game changer, it requires a mind shift in how you look at your product, the work that supports it and how you see the visualize the value your product delivers. If you are a leader who is going to be uncomfortable finding out truths about your organizations inefficient manner of product delivery then you need to think twice about moving to Agile.
Do you have TITL (To Important to Lose) people in your organization? If you do, then you need to really look at how they influence any changes in your organization. Do you need to get their approval, gain their support, etc....? If so you will find more often than not that Agile will scare the hell out of them. Successful Agile teams/organizations understand that self organizing teams take away the need for many of the day-to-day management decisions our middle management layer makes. Agile speed comes when you remove the friction of management layers and provide teams with a clear vision of what you want them to deliver.
You must be prepared for the resistance that you will face from your product delivery teams, not everyone wants to go to Agile We become comfortable with what we know and do in our daily work life and in that comfort comes stasis. If you are not prepared to lose people, especially your TITL people, then you need to question if Agile is really for you.
I know it sounds heartless, but I've been working for over 30 years and one of the first things I learned right out of college was that technology was disruptive and if you weren't on board with how it changes how you work you would be left behind. At one company I worked for many years ago, I saw Regional sales managers who had been with the company for over 30 years and when we rolled out a sales force tracking/marketing tool (which I led) there were several who refused to even turn on the computer, they were all let go within months. As employees we have the obligation to continue to grow and learn and continue to make ourselves valuable to our organization and if we don't, then you as a leader have an obligation to make tough decisions that ensure that the organization is continuing to grow and not stagnate with old processes. It's not personal it's business.
As you move to Agile you also need to understand the investment that needs to be made in your technology stack. Many organizations have decades old technology stacks which have been shoe horned into the future and though you get by you won't be able to become Agile until you have a strong Continuous Integration framework, high levels of Unit, Integration and Functional test automation. Getting to this will take time (and using the stories and BDD disciplines mentioned above will help you get there). You simply can't go fast if you don't have the technology backbone that supports it.
Agile isn't easy by any stretch of the imagination, it requires thoughtful introspection, focus on continuous improvement, disciplined delivery and a tenacity for value and quality that is never satisfied.