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.

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.