Implementation & Change management
Everyone knows that “it takes time and effort to make an organizational change”. Unfortunately not everyone knows exactly what it means. You have to ask yourself some key questions before introducing any change of process (“how we work”). Otherwise you will be sooner or later (rather sooner) faced with exactly the same questions directly from people who are affected by those changes. There is no escape from it as if your goal is to successfully change processes you have to know how to successfully engage people about why they have to change “how we work”.
In my opinion 3 crucial questions to ask yourself would be:
- Do I know how people react to changes ?
- What are the real costs vs potential benefits of that change ?
- How much time would it take to see results after implementation of a change ?
.png)
Ad. A) how people react to changes?
This straightforward graph from Ray Immelman’s “Great Boss Dead Boss”. It’s rather self explanatory. Show it to everybody involved in any process change. People are changing attitudes in time and there is nothing wrong with it. We have to just accept it and keep everyone on the same page with the current state of “where we are”. What we should focus on is identification of impediments, gathering clear feedback from and clearly stating the reason for change to everyone who is affected
Ad. B) What are the real costs vs potential benefits of planned change?
This is really the true tradeoff that has to be made. Changing processes is taxing both time, resources and will power of people involved in change. If you will radically underestimate how big that tax is, you will be exposing yourself to huge risks. Lowering temporary quantity & quality of delivered end product is one of those risks but even more dangerous one is “squeezing” people’s psyche. The more sophisticated your end product is (software is rather sophisticated) the bigger burnout of your team you will observe from forcing process changes that are not properly managed. Ask yourself if the risk of losing crucial team members is something that You can accept.
Potential benefits of change are most of the time way more exposed and shiny then real costs. We have to always properly assess if that “beautiful future” is really that bright and worth the sum of effort.
Overall there is a risk in both making too frequent changes and not making any changes at all. There is no clear definition of where is an optimal balance between those two but for sure there is a value in figuring out that balance.
Ad. C) How much time would it take to see results after implementation of a change?
Nobody wants to engage in a change of process that will not bring any result. Even if that result is clearly negative there is some value in testing a hypothesis. We should accept that if a change will not bring results we are always able to make a step back. What we should avoid is to stall in situations where no results of change are observed (either good or bad) and no clear timeframe/plan for reaction is set.
What to avoid during implementation of Agile frameworks/tools?
Implementation of the Agile framework it’s a really hard and complex task but you can make it a bit easier by focusing on things that are really important at any given point of time.(read Theory of Constraints - link in bottom of that article ).
During first steps try to focus on
a) choosing a framework/tool that will suit most to your product development process (but don’t be upset when 1 st choice will eventually not last, just try different one if there is enough potential value in it)
It’s crucial to balance time spent on figuring out which framework to choose vs time spent on actual implementation. It’s no sense to waste time on forcing some solution where it’s clear that it’s not bringing enough value. It’s better to be open to change of direction. On the other hand if you will never make a decision you will never test any solution.b) teaching about foundations & important elements of certain agile frameworks / tools.
b) teaching about foundations & important elements of certain agile frameworks / tools.
It is absolutely necessary for everyone working in a certain framework/tool to understand why and how they are going to use it. The more widely acknowledged and accepted is that reason the smoother and less stressful this process of transformation will be. .
c) not becoming an Agile policeman who is expressing need for every small change separately (without context) by only reading loud short fragments of Scrum Guide (or a KanBan manual).
Always express why there is a value in a certain approach/method/rule/artifact/event and what we may miss if we would not change “how we work”. That will create a mutual understanding and will spread responsibility across the whole group affected by agile framework introduction.
d) not pushing detailed and overspecified solutions to every problem that occurs during adaptation.
Your role is to install certain mindset, boundaries and responsibilities but not to actually execute changes in behaviour by micromanagement. Certain team members/stakeholders will need your help to better understand reasoning but ultimately it’s their job to grow into new responsibility. Your job is also to constantly (at least every retrospective) induce clarification and open a discussion to find what was the root cause of the emerging problem so the people involved can react and find a solution by themself.
Which project to choose for Agile framework implementation?
There is no clear answer to that question but for sure this scheme/graph is going to help you to choose a certain class of projects/products.
Your best shot will be a project/product that is at the same time:
- critical to the point that whole organization will even care about it’s progression or regression ;
- having a “future” in term of time and potential team grow to give you possibility to observe if transformation brought expected value;
- supported by a client/sponsor that is “stable” in terms of both finance and quality of cooperation. It will be necessary for all stakeholders to understand what will a planned transformation mean to them. (change of value delivery, value quantity & quality etc. )
For now this is end of "How To Agile?" script but look out for more!
