Sunday, April 22, 2018

Most Common Mistakes During the Transition to Agile (Part 1) | Supreme Agile

תוצאת תמונה עבור ‪agile transformation‬‏
When examining the last few years, we can see the extended amount of organizations that use Agile frameworks (Especially Scrum) as the preferred software development methodology. Some organizations had a massive success implementing and adopting Agile. While other organizations achieved partial success due to well-known problems that I will cover in this article.

Well, how can it be that organizations fail to adopt Agile? This is despite the fact that it is well known, there are many implementers, coaches and endless knowledge on the internet that is available for everyone. 

Well, the answer is not surprising and relatively simple. Agile is a document with a set of principles and values that are interpreted differently by different people. The direct result of this interpretation is the creation of too many ways to implement the method and the abandon of the real spirit of what this document really represents. 

This article will present some of the most common pitfalls made in organizations while implementing Agile. My recommendation for you is to pay attention to each one of the items described below and to ensure that you avoid them to achieve a successful transition process. 

Mistake #1 – Retrospectives without continues improvement

The main goal of the retrospective meeting is to allow the team to raise all issues that affect their progress and to suggest new ways to improve the process and their day-to-day work. Therefore, all action items must be prioritized and resolved quickly. If they are not, team members will have no respect for it and will not contribute to future meetings.

Keep in mind, that retrospectives are critical meetings during and after an Agile transition. Great trainers will use these meetings to show the team that they respect their problems and will do the necessary work to resolve them. This is one of the most important ways to start building the respect and trust between the team and the process. 

Mistake #2 – Agile as a Religion

This is one of the classic mistakes made by new Agile facilitators is using Agile as a religion. Therefore, they implement it without understanding the real needs of the customer. As a result, they fail to adjust his/her needs to resolve the true challenges raised by the customer.


Mistake #3 – Ignoring the Ceremonies

There is a reason to why we use ceremonies as part of the transition to Agile. These meetings allow both the organization and its teams to inspect and adapt the implementation. At a team level, ceremonies help the team to increase the collaboration, visibility, and efficiency from sprint to sprint. Below are some meeting types:
  • Daily meetings - Enables the team to synchronize and remain focused on the iteration goal.
  • Review meetings - enables the team to share their work.
  • Retrospectives - enables the team to grow using continues improvement.
  • Planning meetings – enables the team to understand the work prior to committing to it.

Mistake #4 – Poor Team Structure

When building Agile teams we should do our best to create teams that have all of the relevant skills to act as a truly cross-functional team. The main reason is to allow the team to make commitments at the start of the iteration (A.K.A: User Stories) and perform the necessary activities (Design, Coding Testing Etc.) to their completion.

Agile teams that do not have the correct mix of skills to act in this manner, will not be able to see the big picture of what it takes to complete a user story, or at worst deliver a poor quality implementation.

In addition to above, cross-functional teams have the ability to estimate the scope of work required to complete a story. However, should the team not have the relevant resources; they will most likely fail to make the correct estimations. This will result in resolve delays, increased pressure through the iteration and higher % completion failures. 

Mistake #5 – Not Enough Training

Once I was invited as a consultant to an organization that was in the middle of transitioning to Agile. The reason that they invited me was to analyze the current failures they had in the process that leads to increased frustration among their teams. The investigation results lead to a basic, but a crucial factor, there was a lack of training that was not part of the overall implementation strategy.

Making an Agile transition without providing the relevant training is like letting a person drive a car without experience. As part of an Agile transition, one must ensure that the implementation strategy includes providing relevant training to build the necessary foundations that will be used throughout the entire process. 

Mistake #6 – Automated Test Coverage  

The basic concept of Agile suggests a team should deliver an incremental release of the product at the end of each iteration. Well, automated testing is a critical factor in achieving this and can be the difference between a successful team and an unsuccessful one.

So why it is such a crucial factor?
  • Without automated testing, the team will create technical debt that will affect their progress in future iterations.
  • Automated testing helpד to increase the resilience of the code (Unit, Component and integration tests) and will help increase the quality of each delivery.
  • Automated testing will reduce the waste of time-related to regression testing. 


Mistake #7 –Product Owner is a JOB and not a Habit

The Product Owner is a critical role in the process and must be treated with the appropriate respect. It is easy to see why the Product Owner is a Key stakeholder in any Agile transition that uses Scrum as the chosen framework. From my years of experience, I have seen many teams that fail to perform their job due to chosen Product Owners (PO) for the role. A product owner without any knowledge, Experience, and skills cannot perform this function.

The product owner should be a person that understands the business and has the characteristics, time and expertise in the specific area. This is the only way to guarantee that the team will be able to prioritize the backlog, write good stories. These will ultimately increase the ROI of the team.

Mistake #8 – Start with a Management Tool

Another simple but costly mistake is an organization that starts with selecting the management tool prior to starting the Agile adoption. Sometimes it is justified to do it (Especially if the organization understands the needs that arise in a new Agile transition) but in many cases not. This is because the organization does not have the experience and therefore will try different tools that do not provide the necessary answers to manage an Agile transition process.

When starting a new transition, the organization must first gain a deeper understanding of the Agile Framework and the different concepts that come along with it.

Mistake #9 – Certification is not a guarantee of success  

I am not a great believer in certifications that you can get without real hands-on experience. In Agile there are many certifications such as CST, CSM, and CSPO that you can pass without any relation to the real practical world.

Because of the above, I have a major problem with organizations that start the process with Scrum Masters that do not have any experience or certified trainers who do not have a clue what it takes to transition the company to the new Framework

Trainers can assist, but one always needs to ask the right questions and not follow them blindly. Remember the trainer may not have any experience in your domain, organization culture, and the root problems that keep you from succeeding.

The exact same thing is relevant to the Product Owner and Scrum masters that are certified and no one trusts them to perform their job at the highest level. This can never happen without real experience (Simulating 1 or 2 situations during the course is just not good enough).


Mistake #10 – Ignore the Quality factor

Agile allows us to release an incremental release of the product and doing it fast. Many organization loves this approach due to many obvious reasons that we all familiar with. So what can go wrong here? Well, the answer related to a state of mind that delivering the product earlier and faster is enough to succeed, but it is not! Agile is not about delivering releases faster; it is about delivering quality releases in a way that will increase the trust between the customer and the team.

Using Agile is not a free license to provide fast releases of the software with poor quality that will affect the relationship with the customer. The team may release less functionality in a sprint, but once they do, the customer will know that it meets the quality standards he expects to see.

Mistake #11 – Customer as the Key Stakeholder

The Agile manifesto contains 4 values and 12 principles that state that the customer is the most important stakeholder and should be the center of any Agile project. Many Agile projects that fail related directly to this. The customer is left behind at critical junctions that have a major effect on the entire project. One must avoid this pitfall by ensuring the customer is involved throughout the sprints and his feedback is considered. This is the only way to ensure the team meets the customer vision and technical expectations. 


Mistake #12 – There is no Executives Support

Any transition should start with the support of the organization executives who will take a decisive role in the success of the implementation. Without their support, the new Scrum team will have more difficulties to adjust the new Agile approach. A

1 comment:

  1. Great post David, you get so much right here.

    You nailed it to the point, you cannot adopt a manifesto.
    And then you go and spoil it all for yourself.
    Why to continue to mix Agile and Scrum together like this (except maybe for marketing purposes).
    Yes, Scrum has many trappings we associate with Agile but Scrum comes from a Lean legacy.

    There are no 'retrospectives', 'daily meetings', or even 'sprints', or god forbid 'planning meetings' in agile (Agile is primary about doing not thinking).
    These are all organisational patterns that are part of the Scrum pattern language (https://sites.google.com/a/scrumplop.org/published-patterns/).
    What's interesting is that many of them, Backlog , Product Owner, Sprint - are not even Scrum.
    These are prerequisites for Scrum.

    “Scrum came from TPS, xP from Scrum (“except they got it all wrong”), Agile is the cream skimmed on top”
    - James Coplien






    ReplyDelete

My Presentations