SOGETI UK BLOG

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.

Julya van Berkel AUTHOR:
Julya van Berkel is an Agile adept and coach and has been championing Agile and Scrum since 2007. In her role as Agile Coach Julya has helped numerous clients and colleagues in getting better at Agile and as teaches she has set up and taught hundreds of Agile and Scrum training and courses. For Sogeti in the Netherlands she helps set the direction in Agile and is involved in many groups within Sogeti and outside in the Agile community.

Posted in: Agile, Business Intelligence, Developers, Digital strategy, Environmental impact, Innovation, IT strategy, Quality Assurance, Requirements, Research, Security, Software Development, Technology Outlook, Test Driven Development, Testing and innovation, Transformation, Transitioning      
Comments: 0
Tags: , , , , , , ,

 

Cynefin

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 it’s 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/

Julya van Berkel AUTHOR:
Julya van Berkel is an Agile adept and coach and has been championing Agile and Scrum since 2007. In her role as Agile Coach Julya has helped numerous clients and colleagues in getting better at Agile and as teaches she has set up and taught hundreds of Agile and Scrum training and courses. For Sogeti in the Netherlands she helps set the direction in Agile and is involved in many groups within Sogeti and outside in the Agile community.

Posted in: Agile, Business Intelligence, communication, Digital strategy, Innovation, IT strategy, Quality Assurance, Research, Software Development, Software testing, Test Tools, Testing and innovation, Transformation      
Comments: 0
Tags: , , , , , , , ,

 

012 - Yola & Co And the Viking Laws-1

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?

Julya van Berkel AUTHOR:
Julya van Berkel is an Agile adept and coach and has been championing Agile and Scrum since 2007. In her role as Agile Coach Julya has helped numerous clients and colleagues in getting better at Agile and as teaches she has set up and taught hundreds of Agile and Scrum training and courses. For Sogeti in the Netherlands she helps set the direction in Agile and is involved in many groups within Sogeti and outside in the Agile community.

Posted in: Agile, communication, Innovation, IT strategy, Quality Assurance, Requirements, Research, Software Development, Test Tools, Testing and innovation      
Comments: 0
Tags: , , , , , ,

 

Picture of a row of cupcakes

Relative weighting

In Part 1Part 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 focusing on the outcome as opposed to the output. Outcome is usually user satisfaction not short term profit.

 

Julya van Berkel AUTHOR:
Julya van Berkel is an Agile adept and coach and has been championing Agile and Scrum since 2007. In her role as Agile Coach Julya has helped numerous clients and colleagues in getting better at Agile and as teaches she has set up and taught hundreds of Agile and Scrum training and courses. For Sogeti in the Netherlands she helps set the direction in Agile and is involved in many groups within Sogeti and outside in the Agile community.

Posted in: Innovation, IT strategy, Quality Assurance, Research, test framework, Test Tools, Testing and innovation, Transformation, User Experience      
Comments: 0
Tags: , , , , , , , , ,

 

Tools

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

Julya van Berkel AUTHOR:
Julya van Berkel is an Agile adept and coach and has been championing Agile and Scrum since 2007. In her role as Agile Coach Julya has helped numerous clients and colleagues in getting better at Agile and as teaches she has set up and taught hundreds of Agile and Scrum training and courses. For Sogeti in the Netherlands she helps set the direction in Agile and is involved in many groups within Sogeti and outside in the Agile community.

Posted in: Application Lifecycle Management, Digital strategy, Innovation, IT strategy, Marketing, Quality Assurance, Research, Test environment, Testing and innovation, Transformation, User Experience      
Comments: Comments Off on How to measure value? – Part 3
Tags: , , , , , , ,