Category: Agile

Published on SogetiLabs, date: June 9th, 2016: http://labs.sogeti.com/unorganize-and-win/

Last night I was at our annual VINT symposium in Bussum in the Netherlands. The topic was “unorganized” and a good number of speakers told us about the developments in IT and how unorganization is a part of that.

Thinking how to apply this, I got inspired from the speakers and my colleagues Menno and Sander.

Many of the things I saw last night, are topics I have used to explain to people why Agile is such an important development in the ways we look at problems. It is not new that technology and market developments have sped up in the past decades; and we must change our way of thinking and innovation to keep up.

Wait…ways of innovation? Is there another way of innovating? Maybe not innovation itself needs to change, and you cannot speed up the way people innovate, can you?

Well, we can increase the environment we are in to be inspirational. We can help people to think “out-of-the-box” to be able to come up with solutions to problems we may have been unaware of before. etc. Step out of organized Research and Development and into consumer world to experience the developments and needs of our users.

Another aspect that was mentioned was Fail-fast. This is something the Agile world has been using as focus for a long time. Agile methodologies and frameworks help organizations to fail fast. And the emphasis needs to be on Fast, not on Fail. We do not help them to fail, we help them to fail Fast so they learn quicker.

One of the most inspirational speakers was Erben Wennemars, an ice-skater who has won numerous world championships and took us along in a story about his journey in ice-skating. His story I found very fitting with the topic of the symposium, even though he claimed to not know much about our work.

He has dealt with many things during his career as ice skater. One of the most important things he mentioned was that top-class athletes need goals and passion. They need to translate those into a vision for themselves and they need to work hard to achieve those goals. They need to go to the brink and beyond to be the best and to win.

This helped me realize that unorganization is part of a learning curve. We need to fall, or at least need to experience unorganization to be able to deal with it in the future. The way a seasoned traveller knows how to deal with missing a connection without panicking. The way veteran fighters are more effective in a war after having seen more than just one battle. The way Wolff’s law (bones heal up stronger) is applied in breaking – a martial arts skill where hard materials are broken with bare fists, elbows, etc.

Many experienced entrepreneurs can be found among those who have failed businesses in their past. For example, using numbers mentioned yesterday, 80% of startups fail. Does failing make YOU a failure? Or does it make you stronger?

I believe that we can use unorganization to help our company get stronger. This does not mean we need to fail; this means we need to learn from failure or potential failure. We can use unorganization to help our professionals learn and get stronger. The way in “The Phoenix Project” John the security officer used “Evil Chaos Monkey” to help the company to overcome the problems that could occur if external agencies (hackers, criminals) exploit the holes and cracks in your system.

As I referred to Cynefin in my previous blog, the Chaos domain is to be avoided. We do not want to find ourselves in a situation where we need to apply novel practices to survive. But those who did survive have learned valuable lessons to get out of this domain. I believe by skirting the edge of Chaos we can become better. We can bring organization to unorganization and WIN.

Posted on SogetiLabs, date: May 26th, 2016: http://labs.sogeti.com/agile-is-not-the-answer-to-everything/

A tool is a tool, it fits within a certain domain. I do not use a ladle to get my nails into wood and I do not stir my soup with a hammer (both might work to a certain degree, but are not specifically fit for it).

During the trainings I provide for colleagues and clients I often get the question “Where does Agile not work”. Funnily enough the question always focusses on the negative, as if the person who asks wants to disqualify Agile. I would love to one day be asked the opposite, but many people still struggle to get into the Agile mindset and might be looking for things to justify not getting there.

As I said, Agile is seen as a mindset, a way of working. It is not so much a tool, as it is an approach to solving things. So where does Agile work and what is not its domain?

 

If I need to answer this question I look for examples, situations, I look into my past experiences to see if I can make someone understand.

Until Cynefin..

Cynefin is a framework that Dave Snowden uses to explain the types of systems he identifies. It is also called the sense making model and it has helped me to explain to people where Agile fits.

Within Cynefin Mr. Snowden described four types of systems.

• Obvious
• Complicated
• Complex
• Chaotic

In Obvious systems there is a clear relationship between cause and effect. These things are normal to us. They are obvious and after childhood these things stop to amaze us.

To achieve things within obvious systems we can suffice with a checklist for the actions we take to achieve an obvious goal. Often a checklist is not even necessary as we know what will happen.

Complicated systems usually mean we cannot immediately see the effect of our actions. We need to do some analysis to determine what will happen. it could also mean we need to have acquired some form of expertise to know what will occur and we will therefore need to involve other people.

For these systems we can find Project Management to be necessary. We can set up projects with a clear end and afterwards we will have achieved a goal that we have set in the beginning. Waterfall fits well here.

Complex systems describe the environment where we do not really know the effect until we have experienced a bit of the solution. We need to allow knowledge to emerge while we work on finding out what will work best. Waterfall does not support these systems. We cannot predict what the precise result will be. (I am not referring to Dr. Winston W. Royce’s white paper when I mention Waterfall. It’s the single direction method that emerged later that does not support Complex systems).

Agile frameworks and methodologies require emergent requirements to get the best results. As the Agile principles describe: “Agile processes harness change for the customer’s competitive advantage.”

Chaotic systems have no correlation between cause and effect whatsoever. You need to figure our then and there what the best thing is that you can do, yet there is no guarantee that it is the right thing to do. There are no clear ways to deal with these systems so it is good to monitor the situation continuously and to find novel ways in dealing with what happens.

Now, to answer the question I asked before I started telling you about Cynefin. Where does Agile work? The domain is clear. Agile fits best in the Complex system domain.

Can we use Agile in the complicated systems domain? (Can we use a hammer to stir soup?). Sure we can, Agile will work. It even works in the Obvious systems domain. The question is if it is necessary.

A checklist won’t work in a Complex system, so the ways to deal with the systems will work in the previous systems but not the other way around (as shown in the picture it works clockwise, not counterclockwise).

When I get to a new situation I often look at what kind of system I can determine I am in.

Does Agile work everywhere?

No, and specifically not within Chaotic systems. It works better there than waterfall though.

Within a chaotic system we need to have practices what we can to make it possible to understand the situation we are in. The more muscle memory we have the better we will survive.

I hope Cynefin will make sense to you. It helps me a lot!

find out more on Dave Snowden and Cynefin on: http://cognitive-edge.com/

Posted on SogetiLabs, date May 24th, 2016: http://labs.sogeti.com/are-you-a-viking/

During my travels I am always looking for links with the Agile world. There are many examples where a more iterative and value driven mindset is used to achieve certain goals and I use these examples in my work and teachings.

Other Agile experts also have this professional deformation and we meet up on Agile Coach Camps and other Agile events. One of those Agile friends is Rolf Dräther (Happycentric) whom I met on our Agile Coach Camp NL (ACCNL16) this year. Rolf had taken a trip to Norway and was intrigued by a postcard he found there. The postcard showed him the Viking Laws and he was astonished how well they can be mapped onto Agile culture.

The text on the postcard was this:

VIKING LAWS

1) Be brave and aggressive

Be direct
Grab all opportunities
Use varying methods of attack
Be versatile and agile
Attack one target at a time
Don’t plan everything in detail
Use top quality weapons

2) Be prepared

Keep weapons in good condition
Keep in shape
Find good battle comrades
Agree on important points
Choose one Chief

3) Be a good merchant

Find out what the market needs
Don’t promise what you can’t keep
Don’t demand overpayment
Arrange things so that you can return

4) Keep the camp in order

Keep things tidy and organized
Arrange enjoyable activities which strengthen the group
Make sure everybody does useful work
Consult all members of the group for advice

Looking at these laws I’m struck by how well they fit on Agile cultures. The first set shows the way Agile teams approach the work they have, to not have a Big Design Up Front, to be open and direct, to use Swarming (get one item done at a time – to limit work in progress), and the approach towards tooling.

The second applies to how Agile teams are set up with a focus on technical excellence and to have just one person responsible for the product so the team does not have more than one person setting the vision.

When I look at the third one I see the way Agile teams deal with the outside world. To look at what is important now in the current marketplace and go for what brings the most value. Measuring what can be done in one iteration and only picking up (and promising) what they can deliver. To not work overtime, and be clear in expectations so people want to keep coming.

The last set for me represents how teams do their work. They use the boy-scout rule, leaving the code they work on better than they found it. They keep the work they do fun for all. They don’t do the work alone, everyone has a say in the product development and are all there during refinement sessions.

I am going to use this in my trainings and while coaching my teams. They can apply these rules, and/or add to them.
Maybe you can ask yourself these questions:

Am I a Viking?

Can I live up to these Viking Laws?

What are my laws?

Published on SogetiLabs, date April 28th, 2016: http://labs.sogeti.com/how-to-measure-value-part-4/

Relative weighting

In Part 1, Part 2 and Part 3,  I explained Theme Screening and Theme Scoring. In Theme Screening we added a weight and made the scoring more relative.

Relative weighting takes the weight factor of Theme Screening to another level and adds the teams estimate to the equation to make a new ranking within the Product Backlog.

Consider the Backlog we have been working with so far:

1	Cinnamon Apple Cupcake
2	Liquorice Mint Cupcake
3	Green Tea, Honey Cupcake
4	Pecan Salty Caramel Cupcake
5	Lemon White Chocolate Cupcake

In Relative Weighting we look at the following per theme:

• What is the impact of implementing this theme scored from 1 to 9.
• What is the impact of not implementing this theme scored from 1 to 9

We add these two values together per theme and this is the “Value” of the theme.

Then we determine the relative estimation per theme. This is the “cost” of the theme.

Both these need to be normalised to make it usable in the future. After all, a backlog is not a fixed list. We can do this by making the “Value” and “Cost” variables into percentages. Add up all the values and all the costs and determine per value-variable and cost-variable what this represents as a percentage of the whole.

Then we divide the Value percentage by the Cost percentage. This represents a very pure ROI number of the theme. This ROI number we can use to rank the Theme in the full list.

What I like about this way of determining value is that it actually relates it with the costs as well. Mind you, this does mean that you have to have sessions with your development team to discuss the Theme before you can rank it in your list. To be honest, I expect the Product Owner to involve the team anyway in the Backlog Refinement sessions every week.

Let’s look at the Matrix again:

Cupcake => Theme V	Benefit	Penalty	Value (benefit + penalty)	Value %	Estimation (totals of PBI’s)	Estimation %	ROI (Value% /Est.%)
Liquorice Mint	3	2	5	8.33	54	27.69	0.30
Green Tea, Honey	8	4	12	20.00	43	22.05	0.91
Cinnamon Apple	9	8	17	28.33	35	17.94	1.58
Pecan Salty Caramel	8	8	16	26.67	25	12.82	2.08
Lemon White Chocolate	5	5	10	16.67	38	19.48	0.86
Totals			60	100	195	100

Considering the highest ROI gives the following ranking:

Rank	Theme	Relative Weight
1	Pecan Salty Caramel Cupcake	2.08
2	Cinnamon Apple Cupcake	1.58
3	Green Tea, Honey Cupcake	0.91
4	Lemon White Chocolate Cupcake	0.86
5	Liquorice Mint Cupcake	0.30

Looking back at the different methods to calculate value I have a slight preference for Relative Weighting when I consider the full ROI focus I expect a Product Owner to have. It is still a tool and Agile considers tools to be important only if they support interaction.

What tool you choose is up to you as “value optimizer”. Make sure that it matches your environment and product.

You could also use more than one tool. I can imagine that the first setup of a Product Backlog when you have not selected a development team yet is best helped by Theme Screening or Scoring. Without the estimations of the team the ROI calculated in Relative Weighting is too unsure. At least determine with your stakeholders what is important to get ready for the new team first. But involve existing or new to form development teams in your determination of Product Backlog items.

For this technique there is also a tool on Mike Cohn’s site

In the past 4 blogs I have given you some tools. I would like to remind you of the first value of Agile:

We value: Individuals and interactions over processes and tools
agilemanifesto.org

The use of tools should not interfere with your work as Product Owner with your team(s).

You as Product Owner are accountable for Return of Investment, most of the time with the research that you do and the stakeholders you work with you get a feeling of what is value for you and your product. With the tools I have given you it is easier to quantify this feeling. Don’t ignore your feelings though. The best result from Agile product development comes from focussing on the outcome as opposed to the output. Outcome is usually user satisfaction not short term profit.

This was published on SogetiLabs, date April 27th, 2016: http://labs.sogeti.com/how-to-measure-value-part-3/

In Part 1 and Part 2 I have given you two techniques that you can use as Product Owner to determine the highest value in your Product Backlog together with your stakeholders. For this blog I would like to tell you about:  Theme Screening

The last time I told you about Theme Scoring; this is fine for doing a single backlog ranking. To use it, pick a base theme every time you start scoring the list of themes you have.

Theme Screening is similar to Theme Scoring.

You have a list of Criteria:

Profit in the next half year

Important for current customers

Base material cost

Recipe complexity

And you have a list of themes:

1	Cinnamon Apple Cupcake
2	Liquorice Mint Cupcake
3	Green Tea, Honey Cupcake
4	Pecan Salty Caramel Cupcake
5	Lemon White Chocolate Cupcake

Yet in Theme Screening you do not pick a base theme. This time you pick a theme where you think the Criteria is best/easiest to determine. For instance, you pick Cinnamon Apple for the Criterium “Important for current customers” because in your survey under the current clientele you have found a demand for Cinnamon Apple Cupcakes.

You pick Pecan Salty Caramel Cupcake as base theme for the “Profit in the next half year” because this flavour combination has turned out to be very popular with the younger upcoming generation based on your market research and tests you have performed on large cupcake conferences.

Base material costs are good with Cinnamon apple and Recipe Complexity is easily determined with the Lemon White Chocolate Cupcake.

Instead of Scoring the themes Better, Equal and Worse you add an extra level. You score the Criteria using the following table:

1	Much worse than the reference
2	Worse than the reference
3	Equal
4	Better than the reference
5	Much better than the reference

For every theme you determine the score it gets compared to the reference.

Next to the Scoring complexity theme screening also normalises the results by adding a weight to thecriterium. This allows you to fit your ordering in with company strategy. For instance, the CEO has consulted all Product Owners and has decided that the Base Material Costs need to be reduced. This criterium will be considered more important than the other criteria. Profit is still important, so it will also weigh more and Recipe Complexity is least important as a criterium.
The total of weight is never more than 100%

The matrix looks a bit different:

Cupcake Theme > Criteria  v	Criterium Weight	Liquorice Mint		Green Tea Honey		Cinnamon Apple		Pecan Salty Caramel		Lemon White Chocolate
Profit in the next half year	30%	1	0.30	3	0.90	2	0.60	3	0.90	2	0.60
Important for current customers	20%	1	0.20	3	0.60	3	0.60	2	0.40	3	0.60
Base material cost	40%	3	1.20	4	1.60	3	1.20	2	0.80	2	0.80
Recipe complexity	10%	4	0.40	1	0.10	2	0.20	2	0.20	3	0.30
Result:		2.10		3.20		2.60		2.30		2.30

The ranking can now be done. And as you see, the Green Tea Honey ranks number one this time. The weight of the base materials cost criterium has pushed this theme up. Still you can get dilemmas as you can see with the Pecan Salty Caramel and Lemon White Chocolate cupcakes. They have the same ranking in Base Material cost, yet the Pecan Salty Caramel could reap better profit. The choice to make is up to you as Product Owner. You might want to wait till the team that has to build this theme has estimated the relative size. If one of them is less complex or less effort you could choose to rank that one higher.

New Product Backlog:

Rank	Theme	Relative Estimate
1	Green Tea, Honey Cupcake	5
2	Cinnamon Apple Cupcake	3
3	Pecan Salty Caramel Cupcake	5
3	Lemon White Chocolate Cupcake	8
4	Liquorice Mint Cupcake	5

Based on the result we can decide if we are going to drop the theme for the next release or even the whole product.

Compared to Theme Scoring this technique is a bit more complicated. However, you can keep these matrixes around longer since there is no single Base theme and the criterium score can be more relative to the whole list of themes making this technique more holistic than Theme Scoring.

Another advantage to this technique is the weight. If you make this a matrix in which you can manipulate the weight, for instance using Excel or Numbers, you can decide on strategy based on market research, company strategy and stakeholder management.

For this technique there is another tool on Mike Cohn’s site:https://www.mountaingoatsoftware.com/tools/theme-screening#

Posted on SogetiLabs on: April 26th, 2016: http://labs.sogeti.com/how-to-measure-value-part-2/

In my last blogpost I mentioned that I would like to give Product Owners a tool to help them determine value with their stakeholders. One technique I referred to last time, Business Value Poker. In this post I would like to tell you about another technique: Theme Scoring

This is one of the easiest techniques to use as it gives you a firm reference with which to work.

Mind you, you still have to determine the themes for your product yourself. But that is no different from other product management work.

Say you are the Product Owner of a Cupcake factory. You have the hearty cupcake product line as your responsibility. What is the next product in your Cupcake suite of pleasure?

You determine that next to the product “Cinnamon Apple Cupcake” you want to bring out the “Liquorice Mint Cupcake” and the “Green Tea, Honey Cupcake”. One of your stakeholders has told you that there is a fandom for the “Pecan Salty Caramel Cupcake” and the “Lemon White Chocolate Cupcake”.

So you put the different Cupcake themes in a list:

Backlog
1	Cinnamon Apple Cupcake
2	Liquorice Mint Cupcake
3	Green Tea, Honey Cupcake
4	Pecan Salty Caramel Cupcake
5	Lemon White Chocolate Cupcake

Mind you, this order is fine. YOU are the Product Owner and as Product Owner the order on a Backlog is yours to determine. You can listen to your stakeholders, and act on market signals, but in the end the Product Backlog is your responsibility. You are the one that determines what’s good for RoI.

The company wants more profit in the next half year though and you want to give them that. There’s also the current customers you want to please. You want new customers but to alienate the current customer base is bad for business. It is also necessary to save on base materials; you need to be able to make profit. Last but not least is the complexity of the recipe. If it cannot be baked easily you end up bogging down the production process.

You put those aspects in a list as well:

Profit in the next half year

Important for current customers

Base material cost

Recipe complexity

These two lists have to be combined to figure out which of the themes make a chance to be worked on first by the conceptual bakery team.

So we put them in a matrix:

Cupcake Theme => Criteria V		Liquorice Mint		Green Tea, Honey		Cinnamon Apple		Pecan Salty Caramel		Lemon White Chocolate
Profit in the next half year						0
Important for current customers						0
Base material cost						0
Recipe complexity						0
Result:

We know that the Cinnamon Apple is important for the product line so we will use this as a baseline. The Cinnamon Apple column will contain the score 0 for all the criteria. We score all the other Themes based on this Base Theme.

With our stakeholders we now start scoring the other themes on these criteria and compare them with the base theme. The scoring is done using three possible outcomes. The theme is either better or worse than the base theme OR it scores the same.

The result is added from the column. We add all the plusses and subtract the minuses. This leaves us with a positive or negative score per theme that we can use to rank the themes and order the backlog again.

Example:

Cupcake Theme => Criteria V		Liquorice Mint		Green Tea, Honey		Cinnamon Apple		Pecan Salty Caramel		Lemon White Chocolate
Profit in the next half year		–		0		0		+		–
Important for current customers		–		+		0		+		0
Base material cost		+		+		0		+		–
Recipe complexity		–		–		0		–		+
Result:		-2		1		0		2		-1

We find out that Cinnamon Apple is no longer the theme that delivers the most value. We place everything in the order we find them to be in after scoring:

Backlog
1	Pecan Salty Caramel Cupcake
2	Green Tea, Honey Cupcake
3	Cinnamon Apple Cupcake
4	Lemon White Chocolate Cupcake
5	Liquorice Mint Cupcake

You will have to tell the concept bakery team that you and your stakeholders have a new order for the themes in your backlog during the Product Backlog Refinement session. You and your taste experts will work together on finding the best recipe to make the Pecan Salty Caramel Cupcake as good as possible and in the next sprint(s) your team will be working on this cupcake.

Mike Cohn provides a wonderful tool that you can use to help you visualise Theme Scoring. A link to this tool can be found here:

I’d like to thank Mike Cohn, Arne Åhlander and Jim Coplien for much insight into this hands-on tool.

Published by SogetiLabs for me on April 25th, 2016: http://labs.sogeti.com/how-to-measure-value-part-1/

When I wrote the blog ‘Measuring performance is an act of sabotage’,  I did realise I should also give people a means to measure value. Even though I expect a Product Owner to know his or her business and Scrum does not give an answer on how to measure value because this is different for every business. In this series of blogs I will give you a few hands-on ways to measure value.

Value is not something that is singular. In fact, for everyone value can be something else. Quality time spent with your significant other can be way more valuable than spending more time at work to earn more money. For every company value is different as well.

Non-profit companies will not care about

profit (duh). For profit companies may, but sometimes they see more value in a growing market share. I should emphasise that offering customer satisfaction may go a long way in achieving long term success for a for-profit and service company.

I’ve worked in many different companies, some were government companies, railroad and airline companies, energy companies, non-profit and profit. All see value differently, yet many choose to work Agile to achieve goals they would not be able to achieve in the current ever changing market.

There are several ways you can measure value. The simplest one to understand is getting the product out there and seeing if it sells. This works well for small product that get an immediate return on investment metric. In todays world you see this simple scheme often in the app market.

You think of a concept that might help smartphone users. Something you think they will pay for. You invest time in writing an app for one or more types of phone and you publish the app on the phone providers’ app-shop or store.

If the app is useful people will buy it. If they like it they may even write an evaluation (if the store supports it). They may grade the app and that might push your rating up and generate more visibility for other users.

For small businesses and one man companies this may work fine. For larger companies this may work if they offer the app as a service or as a side product. When I speak to Product Owners they usually want more though. Their job is to do market research, to figure out what brings most value.

Agile and Scrum don’t tell you how to do your business. They do however strive to support your quest for making the most business you can. The Agile Manifesto even has a principle that explains that: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

In my next blog posts I will explain several ways to measure value. I hope this will help you get your own competitive edge.

One suggestion I would like to make now is to look into Business Value poker.

Look here for one version of it: http://www.agile42.com/en/agile-coaching-company/agile-scrum-tools/business-value-game/

Published by SogetiLabs for me on February 12, 2016: http://labs.sogeti.com/force-of-habit-is-a-good-habit-for-agile/

It’s what I heard in the New York subway. “Oh I do that out of a force of habit.”

Habitual things can be bad things, especially when they turn out to be addictions. But besides that, they are usually neither bad nor good. They are what make you “you”. They are what make you good at your job, or more efficient in what you do for yourself.

You lock your bicycle when you arrive at the public library, you put your reading glasses in your left jacket pocket. You do things because they make sense and stick to it.

When it comes to Agile we want to break through the tradition. But only when this tradition is holding you back from improving. In fact we want people to create new habits. To become more efficient.

It’s how we learn to do things. The first time we need assurance. We need to test the waters and we need to get more confidence doing what we do. This is how I learned to drive a car. And I was not very quick at that. It took me a while to feel comfortable driving because there is no real margin for error.

We want that force of habit.

Old habits die hard, so that’s why we need to find a way to break with them. As I mentioned in my previous blogs, one of the habits we have from old days is to estimate work in time. Another one is to take all the time you allotted for a ceremony or meeting. More efficient is to estimate relative to all the work that needs to be done so we can actually increase our work speed without the student syndromeslowing us.

Often I am brought into a situation because organisations fail to get their Agile implementation to work. Interestingly enough, this usually doesn’t work because items are missing or misunderstood. Because old habits or preconceptions prompt organisations to omit essential Agile ceremonies or change them into inefficiency.

In my trainings I often refer to the movie “Karate kid” where the protagonist wants to learn karate and is taught how to wax the car of his sensei. Most people remember when I mention “wax on, wax off”. The sensei, Mr. Miyagi, is teaching him not about the power of strikes or stance. First he is teaching the movement to make. I compare this with the training drilling platform personnel goes through before being allowed on the platform. In dangerous situations you just want people to do what gives them the best survival opportunities.

It’s building “muscle memory”, it’s learning people to become, as Maslow taught us, unconsciously skilled. To form habits. To leave the cognitive elements of your work unhindered by the everyday tasks.

How does that make an organisation do Agile better?

Many organisations strike standard elements from Agile frameworks. Unlike traditional methodologies, frameworks like Scrum don’t have a lot of redundant ceremonies or other elements. Not doing retrospectives or standups because “they don’t work in our organisation” is one of the biggest traps a transforming organisation can step into. Do them, keep doing them and in the meantime figure out why they work.

Learn to walk before you can run, learn to run before you start competing in a marathon. Build good habits. Agile coaches can help there. The force of habit will help you do Agile in the most efficient way.

Published for me by SogetiLabs on June 26th, 2015: http://labs.sogeti.com/trust-goes-all-the-way/

The effect of trust on Scrum teams

Trust is something that any work situation demands. However, it’s hard to find trust nowadays, as it has been replaced by ‘control’ in traditional work environments. Our business models, leadership principles and relationships at workplaces, usually, do not accommodate trust.

I’ll give you an example from my youth. As a young student, I got an evening job in a supermarket. I helped replenish the store’s in-shop inventory. One night, my supervisor accused me of stealing. He claimed to have seen me putting something into my pocket (later, it turned out to be my own watch that had slipped off my wrist while doing my job). This incident questioned my integrity in a big way. I felt scared of losing the job and my reputation; and my expectation of justice suffered a severe blow. Although, I was cleared by HQ later, the relationship with my supervisor was never the same. He never trusted me after that and I must admit, I could never trust his judgment either.

Now, when I train people on Scrum, I hear about different work situations where ‘the level of trust my supervisor showed in me’ is quite common. When I say that a team should be self organized, they (management) object that people will slack off. I have never seen a team slack off in a Scrum environment; in fact, they thrive, improve, and have more pride than a lot of other teams. Scrum teams put more effort to deliver quality work and demonstrate technical excellence, exhibiting great performance overall. Often, I’m asked to validate it by providing relevant statistics, metrics, etc.

But trust comes from within. If you don’t give trust, you will not get it. Once a team is controlled, they may/will start to meet the numbers by using various devious means. For instance, they can double the team velocity without doing anything more, they can lie about the time spent or they can increase estimations to build in risk; so, eventually, the team output will decrease. Even worse… team members would get demotivated, because humans like their freedom, and controlling them too much will make them look for other opportunities. It affects loyalty, happiness and work satisfaction.

Just because the job I had at the supermarket was a student job, I decided to stay on long enough to make sure my reputation was restored and that I could leave without suffering from the incident. It did not affect my image and a few years later, I got through an atomic clearance investigation for a military position without any trouble. However, I used to get insecure every time I met my supervisor, even as a customer of the supermarket!