5 Keys to Successfully Implementing Agile: Trying to get over a waterfall in an agile barrel
So you’re trying to get over a waterfall in an agile barrel
There are buzzwords that circle professional circles like buzzards around a corpse. These buzzwords started out as actual ideologies and methodologies. They were focuses that were important to achieve success. But little by little their original meanings and purposes became reconstructed into meaning little more than nothing.
Remember when synergies actually meant something…. Or was even commonly used?
Today many of us who manage products and projects find ourselves being circled by the buzzards. Words like waterfall are the enemy, and anything agile is the messiah. Have a problem releasing software on time? Go agile. Have a problem with feature creep? Go agile. Have a problem with building a consensus around what you are going to build? Go agile. Going agile is supposed to fix everything, just like in the early part of this century going to the cloud was supposed to fix everything. However just like going to the cloud didn’t fix all of an organization’s problems, simply going agile isn’t going to fix problems either.
The issue stems not because agile isn’t a better approach to building software than a
waterfall method, but rather because many people confuse going agile with not having timelines or defined features and business requirements. This lack of understanding is compounded by many organizations having their development teams go agile, but refusing to do the hard work to enforce agile principles within senior management teams. This breakdown between how a team works and how that work is reported inherently breaks down the agile process, because it forces the one managing the development or roadmap to force their agile process over a waterfall mindset, and like most things that go over waterfalls, the agile process crashes on the rocks.
However, the destruction of agile processes isn’t a case of predestination. There are things that a product or project manager can do to successfully replace the waterfall method with agile:
Work to change the culture and changing the processes will follow:
Understand that changing from waterfall to agile isn’t just a question of process, you are changing the culture of an organization. Some people have been working under the waterfall method for decades and even if they believe that they want to go agile, they are still going to want the comfort of the familiar.
Everyone needs to take an agile course:
Most organizations pay up for middle management to take agile and scrum courses and certifications, but do not pay for or force members of the development team and senior management to take agile and scrum courses. This leads to a lack of understanding of what agile and scrum is and causes dysfunction on the development team and also significant pain points between middle management and senior management.
Agile is not que sera sera:
Individuals who are used to Gantt charts and waterfall methods are used to having everything planned out to the nth degree. Agile does not work this way. While it is important to accomplish a roadmap’s goals and features within the timeline of the roadmap, worrying about a single sub-task slipping is at best a waste of time and at worst can unroll any agile processes that are in place.
Don’t work on tickets until you have defined Acceptance Requirements:
One of the key issues that can frustrate everyone within the scrum team is a lack of defined requirements. Defined requirements are essential for agile to work. This does not mean that you need the Business Requirement Documents of old, but you do need to know what the end state goal is. It’s easiest to think of these requirements as the Acceptance Requirements. IE what does the thing that is built need to do to be accepted as being done. This is often times referred to as the “definition of done”, but in agile since tasks are broken down to fit within a sprint, the definition of done is not always an apt description and can lead to confusion.
Repetition is the mother of learning, the father of action, which makes it the architect of accomplishment:
It’s easy to start something and it’s easy to finish something. However, repeating the scrum process is hard. Often times it can feel like a burden to people not used to working with a scrum team. It’s easy to get rid of a backlog grooming meeting or a stand-up meeting to free up time because people often forget the dysfunctions that were the catalysts to follow an agile and scrum methodology in the first place. That said, all meetings should have a point and religiously stick to it.
Changing development, product, and project cultures is hard. Work with a team that has successfully helped companies transform their cultures and adopt agile methodologies. Read our most recent case study here.
