What is Killing Agile Software Development
Agile software development principles are no longer a secret or new to any organization like it once was. Many years ago, it burst onto the software scene and disrupted antiquated project management processes.
The word around town was;
…organizations can now respond to change better, they don’t have to spend as much time on documentation, they can inspect and adapt as every new feature is added to a product. Everything was becoming right in the world.
What happened to those days?
Are they gone?
Did they ever even get here in the first place?
Agile Software Development Changed the Game, or Did it?
I mentioned Agile as a Disrupter…
Organizations that were using the old antiquated development model had entire teams of employees in place that all added value to the processes in their respective ways. Agile development provided a level of disruption that threatened good employees who had sustainable career paths within their organizations and their industries. PMPs, Business Analysts, Middle Management, Technical leads, Architects, Quality Assurance Engineers, and Change Control Boards were all looking for their places on these ‘self-organizing’ ‘cross-functional’ teams that were going to continuously release production ready code into the wild. Furthermore, these new professionals with certifications were emerging and calling themselves Scrum Masters and Product Owners that were key to ensuring this sexy new process would succeed.
Sure, there were many folks adapting, as their organizations adapted, and taking on a slightly different role in order to keep the machine rolling. But there were others that moved on to other organizations in order to continue performing their jobs the way they knew best. This created the ‘Agile vs Non-Agile’ culture, which is similar Ford vs Chevy, or Xbox vs PlayStation debates. People stood stubbornly on either side of the fence without so much as peeking over to see how the other side lived.
Why can’t both be good in their own way? Or both be bad in their own way? Both have proven success, so it is more about finding what works best for you or your organization.
Having worked and consulted with numerous organizations over my 10+ year career in software development, I have had my fair share of successes and failures. The times that I have failed as a Product Owner and Scrum Master have been the single most reason for my successes in the same role. I learn each and every day about some fine details of how to coach organizations to delivery software more efficiently with higher quality.
However, I have observed some overarching consistencies with what organizations are doing wrong when trying to change their processes.
Commit to Being Committed
Switching methods or processes is usually done in order to fix a particular problem; whether it is software development processes, or it’s your weekend to-do list around the house.
If you opt to make a change, you need to commit to it fully so that you know for a fact that the new process is either going to work or it not. Just saying you will try something different and then only doing it halfway is not a full commitment. You will always be left with the question of ‘do I actually know the new process succeeded or failed?’ if you never fully try it.
It will always be a blend of multiple methodologies, and anytime there is multiple methodologies the Agile vs Non-Agile mindset is resurrected, and fingers start getting pointed. In order to be certain, you need to make a commitment to yourself, or your organization, that you will fully commit to change. If something is broken, and my options to fix it are, to use super glue or duct tape; using both does not answer the question of “Which one will single-handedly fix this?” Some combination of both might be the answer; however, you learned nothing because you didn’t commit oneor the other and quite frankly paying for BOTH super glue and duct tape is more expensive than only paying for one.
Understand the Why?
Too often we are told to do something, so we do it. We are given requirements, so we follow them. We are told when meetings are, so we attend them. We fail to ask and understand why? We do not understand why something is done, or how the requirements will be used, or what the purpose or goal of meetings are.
Organizations that move to “better” software delivery process and do not understand, or do not properly teach their employees, why agile development is a solution. Team go through the motions of scrum ceremonies because they are told how they should be structured. Teams use the work agile in its literal meaning and use it as a crutch for failed planning; “hey we are agile right? So, let’s pivot to something else.”
Agile relies heavily on the ‘why.’ The most obvious is that user stories need the ‘why’ so that development teams can make sense of what they need to create for the end user. This allows teams to better ask questions provide suggestions about specific functionality. However, most organizations fail at understanding the ‘why’ of the various sprint ceremonies. Why are they in this format? Why are they needed? Why do we have retros? A by product of not understanding the ‘why’ and then delivering on it, is organizations createmore meetings on top of the ceremonies to get the same info the ceremonies should be providing. And we all know that everyone loves meetings, right?
As you read, you probably notice a lot of my real-life examples used in describing implementing change and agile software development. I truly do believe it’s a very success model for organization to improve. So much so, that I feel it can be incorporated in a lot of people’s everyday lives. However,it’s not the ONLY way, and it’s not for everyone. But you will never truly know, until you commit and understand why you are doing so. Otherwise, implementing change will fizzle out quicker than those New Year’s resolutions do by February 1.
1553 Platte Street, Suite 300
Denver, CO 80202
(720) 574 - 9900
1553 Platte Street, Suite 202
Denver, CO 80202