Agile Adoption: Necessary Adaptations & Pitfalls to Circumvent
As a longtime agile practitioner, I was pleased to have been quoted by InformationWeek in an article published June 20, 2017 alongside five others including two CTOs on “how DevOps techniques such as continuous improvement and Agile can be embraced by departments beyond IT.” What I shared with the publication is below in full.
InformationWeek: What sort of adaptions might be necessary?
Gfesser: The foremost adaption that is necessary is for all stakeholders and participants to stop using detailed plans. The second necessary adaption is to accept the premise that change is good. Not change for the sake of changing, but change that is needed to help enable success in light of new information. The third necessary adaption then must be a free flow of information between all stakeholders and participants to help enable the visibility on which everything else is dependent.
Adaptations needed for departments to embrace agility:
- Stop using detailed plans
- Accept the premise that change is good
- Enable the free flow of information
Working in an agile manner helps enable the ability to steer in a different direction than was otherwise planned. While it is important to understand that planning is important, focus directed toward creating detailed plans that are likely to change tends to lead the creators of these plans to think about the sunk costs involved in this type of activity, potentially increasing the likelihood of change resistance.
It is important for all stakeholders and participants to accept the inevitability of change. In my view, one of the main reasons why agile processes have been adopted by so many technology teams is because they have frequently needed to adopt to stakeholders during the construction of tangible products which are testable. As has often been said, many stakeholders do not know what they want until they see it. Iteratively reacting to feedback from stakeholders simply helps enable the construction of products that are actually used.
While change might be uncomfortable or an aspect that individuals might wish to avoid, not recognizing the reality of change will result in opportunity costs. At the same time, the decision making process around change needs to be visible by everyone involved. One of the primary reasons, for example, that open source software has been so widely adopted is because of the visibility that open source software provides with regard to code and product roadmaps, as well as the participation that it welcomes from the community in terms of general feedback, bug reporting, and the ability to submit changes.
InformationWeek: How can skeptical managers be persuaded that DevOps is worth pursuing?
Gfesser: The best way to show value is likely to demonstrate agile processes through a timeboxed experiment. As I reminded a colleague recently, everything is theory until execution takes place, and execution is the hardest part. Skeptical managers can be exposed to successful execution in other firms, but since people are such an integral part of business processes, the people involved will result in variance even if everything else stays constant. In order to show value, the experiment needs to define success. The definition of success can often be described by referencing current processes which are viewed as failures. Ideally, metrics will be involved, because as has been said by others in the past, measuring improvement needs to be based on something. Many previously skeptical managers will champion agile processes once they see success, but as is often the case, the champions at the forefront need to take one step at a time.
Timeboxed experiments are the key to success, as execution is always the hardest part. Just remember that “success” needs to be defined, attempts to take on too much at once will put the likelihood of success in jeopardy, and some experiments are bound to end in failure – use these failures as opportunities to learn.
InformationWeek: Are there any pitfalls to look out for?
Gfesser: One pitfall is what I refer to as “uneducated change,” and this pitfall is associated with product priorities. One responsibility of the product owner in the Scrum process framework, for example, is the prioritization of product change often related to product functionality. The Product Owner needs to understand current and potential users (i.e. the marketplace and where things are going) in order to know how to prioritize the changes that result in work for the development team. If the product owner is not educated, the product will likely not evolve in the needed direction.
While this first pitfall is a likely risk of the well-intentioned, the second pitfall is when one or more individuals either deliberately obstruct agile processes, or simply do not care. The reason I have repeatedly mentioned both stakeholders and participants is because this work is really a team effort. Scrum provides retrospectives at the end of each Sprint lasting one month or less so that teams can continue to assess and improve over time. Communication should be open so that both benefits and drawbacks of team processes can be discussed without fear, but baseless disagreements should be handled appropriately.
Pitfalls to be avoided during the agile adoption process:
- Uneducated change
- Deliberately constructed obstructions
- Attempts at monetizing everything
- Not defining the agile processes
Another pitfall is to relate everything to monetary cost. The agile community often seems to argue about whether the benefits of agile processes really just boil down to reducing monetary costs. While it might be the case that this is true, stakeholders and participants need to realize that costs come in different forms. One type of costs that I mentioned earlier are opportunity costs. But another big cost is building a product that is not used. The feedback loops that agile processes provide are intended to help ensure success so that the risk of this taking place is minimized.
In my view, a fourth pitfall is not defining the agile processes being used by teams. As I have mentioned to a number of colleagues in the past, every team uses a process regardless of whether it is actually documented. Stakeholders and participants should agree on key tenants of the processes that they adopt, which should ideally not use borrowed language from others when the concepts used are different, so as to help prevent confusion. For example, the InformationWeek query here uses the term “Agile” with a capital “A.” What does this mean? Does it mean anything differently than “agile” with a lowercase “a”? For some, “Agile” refers to the Agile Manifesto, but for some it does not.
