A while ago I attended to an Agile conference here in Cluj. Among many interesting topics, presentations and discussions, I took part in a debate where the main idea was centered on the question "Is Velocity a metric or not". There were a lot of ideas thrown around and the final conclusions were pretty good.
At one point during that discussion I said that velocity is too contextual to be a metric. One of my colleagues asked if that was a good or a bad thing. Since I was not sure of an answer I picked the most neutral one and said that is neither good nor bad and it's just a fact (actually a very important fact). I continued to think about that even after the debate ended and I started to add pros and cons in my mind to see if something contextual can be good or bad. I reached the conclusion that "contextual" used in the right way might be very good if we want to obtain the maximum efficiency from a situation. Even more I tried to see what is the opposite of contextual and thinking about general solutions for large number of situations and somehow rules and best practices started to get into this picture. And finally I tried to picture where the Agile mindset comes in and how it encourages and facilitates the transition from these general solutions to contextual ones in order to maximize efficiency. And I was so thrilled about this argument that I felt the urge to put it down on the paper to see if I got it all right.
Rules. Some people love them, some people hate them, but in the end the rules are everywhere. If we take a moment and do a little reflection over our life we will see that almost everything that we learn starts with some rules. Some of them are more strict than the others but almost anytime we start something new we start with the rules and than we adapt to how it fits us the best. Remember the first time we played tennis or the first time we played basketball. Coaches are always starting with: let me tell you the basic rules of the game. All started with the rules and then was customized. From my point of view the rules power is the fact that they are aiming to get the best average of efficiency through a ton of similar situations. This might be a little too vague right now so let me try to get into some more specific details.
Having a lot of similar contexts, if we play by the rules we will obtain the best Performance / Waste average through all the situations. I'm calling waste the edge cases which are not generally solved by the rules.
The advantages of playing by the rules are multiple:
We have at least the impression that the control of the working environment is at a high level.
Predictability of the end result takes less effort (historical data has an important role in making predictions more easier - which doesn't necessarily mean more accurate)
Drawbacks:
Creativity and innovation is without a doubt limited by the rules.
Case study step 1: A new team is in place. They are ready to attack a project and they need to work by the Scrum rules. They have a Product Owner from the client assigned who knows the process and who is able to provide the priorities in time. They are putting in place iterations. They manage to have all the required ceremonies: planning, daily stand ups, sprint reviews and sprint retrospectives. I know what everybody's thinking right now: this is the ideal situation and usually this doesn't happen by the book in reality. Which is totally fine. The team is able to use all the Scrum rules because the stars are aligned in the right way for them.
Best practices. What would be the next logical step in order to increase performance in these edge situations? To have the possibility to bypass the rules where we are convinced that results will be better. And that's how best practices come into the picture. At their origin stands the same concept as in rules situations: through a lot of similar cases somebody very smart (and I know for sure those persons are smart because otherwise the word "best" wouldn't fit into the picture) has found a good solution, has found a pattern to solve all of them that fits in the same category. This solution or pattern is what "best practice" represents. The difference between a best practice and a rule is the fact that the best practice concept gives us the possibility not to use it when we feel we have something better for a certain situation. It gives us a strong starting point and it gives us a fast strong solution for our specific case but doesn't force us to use it literally. Even more the best practices allows us to juggle a little with them. They are not as strict and intangible as the rules are. Once we gain experience we will identify easier when a best practice needs to be applied, customize or bypassed.
Case study step 2: We have the setup in place and the team is following all Scrum rules. As a best practice they are doing estimations in story points and after some iterations they are able to have a stable velocity and do better and better predictions. And then something changes in client organizations e.g. the Product Owner is replaced and the new Product Owner doesn't want to hear anything about story points, doesn't understand them and he is pushing for time estimates because his level of comfort is much higher this way. The team will need to drop the best practice, adapt to client needs and provide work estimations in units of time.
Context. A contextual solution will take into account all the edge cases and all the factors that are affecting our case. The contextual solution will take in consideration also the edge cases which are not solved by the rules or best practices and which form the waste. Therefore a contextual adaptation should maximize efficiency by solving also the situations which are not touched by the power of rules or best practices. Based on each of our capabilities and experience we can find these solutions slower or faster and we can find the right solution or customization or not. But no matter how capable or experienced we are we will not be able to obtain maximum performance if we are not ready to adapt.
Case study step 3: There are an unlimited situations and factors which can influence the good processes which our team are trying to follow. In step 2 we already faced a client which doesn't like story points. What if we are facing one which doesn't want to have sprint reviews? We try to find alternative solutions on delivering the work and getting his acceptance. The rule might say that we need to have the review for a clean process but is not applicable here. If we run until now ten retrospectives and they were totally useless and we were not able to find a way to make them count should we invest more time in this just for the love of the rules or should we spend that time more wisely?
Adopting an Agile mindset will allow us to understand the rules and their power but to be smart enough to not be tied to them. Will allow us to understand the power of a best practice but in the same time will give us the power to choose if we will use it or not. The Agile mindset teaches us to adapt to different contexts and to get the most out of them. It is in our nature and is polished by experience. The simplest sample would be on how we gain our driving skills. First we learn the rules and in the beginning we follow them strictly. Than we are visiting England and we drop the rule which we knew our entire life which says to drive on the right side and adapt to a new rule and drive on the left side. And we drop also the best practice about changing gears with the right hand and we start changing gears with the left hand. And with experience it all comes very naturally, we don't think at the rules and best practices anymore and how are they applied in each traffic situation but we are doing it on the spot. So an Agile Mindset is there by nature. If we really want to make the best out of each situation we should not be afraid to use it.
by Ovidiu Mățan
by Ștefan Bălan
by Ioana Varga , Ioana Costea
by Oana Călugar
