Nov 16

Impact mapping and continuous validation

There is always a reason for making software. Let’s rephrase that: there should always be a reason, at least from a business perspective. How else could our products have any impact?

Whether we want to make an app that that seamlessly connects riders to drivers or build a community where you can hire and rent apartments while earning tons of money: it is basically all about adding value and solving problems from a software point of view.

Impact Mapping

Impact mapping is a technique that can be helpful in defining the impact you want your product to have with all that follows. Why are we doing this? You first define the desired impact with some criteria that you consider necessary to make this impact. These criteria stand for the how and the what.

The example below from by illustrates how impact mapping works:


  • We want to reach 1 million players on our platform.
  • We think that there are three personas that can help us with that: players, internal employees and advertisers.
  • We think we know how they can help us with that.
  • We think we know what will facilitate them on our platform.

The impact map cheat sheet made by Craig Smith can be a helpful aid to keep everybody focused while doing the impact mapping:



With impact mapping we make a lot of assumptions. In the example below we assume that the actor called Player can help us in making the desired impact (1 million users). We also assume that Player will do this by inviting friends, and we make the assumption that semi-automatic invites will help.


Following up on your stories

The thing I don’t see happening often is following up on the impact of a piece of functionality. We have a review or demo and sometimes we get feedback from users. Yet apart from some performance monitoring we do not really know a lot about the impact we are making. Did we make valid assumptions?

Continuous validation

With continuous validation we also make many assumptions. In contrast to automatic unit tests we want to keep validating the same assumptions in production as long as the functionality is alive, and not run it only once. It is very common that the impact of one feature is diminished by a newer one. To create great projects this is something you really want to know and should act on.

We introduce validation as an extra dimension to a user story. We call this an experiment. These experiments will run scheduled in production as long as the functionality is there. The experiment for the example above could be:

Experiment: By giving players the option to invite friends semi-automatically the number of players will increase.
Baseline: Get the current number of players.

Assume: There will be a 10% increase in new players.

Time: 1 month.

Success: Send cake to the whole team with congratulations.

Failure: Push message to Product Owner.

Other things I would like to know and want to create experiments for is how much the invite option is being used, who uses it, and what the assumed effect is after 6 months?

Impact mapping and continuous validation

In a sense continuous validation is the automation of impact mapping. Where impact mapping is a great way to define products, continuous validation makes sure your assumptions are being validated. Not once, but as long as the functionality is alive.

Creating great products is not only about adding new cool features. It is also about removing or changing existing features whose goals aren’t met. We know which impact we want to have. Are we in any way achieving this goal? Are our assumptions right? Is there functionality that is not contributing to our goal?

Manual monitoring of all the assumptions that were made is undoable most of the times. Working software must be delivered at an ever faster pace. That’s why after continuous integration there is continuous validation.

Hylke staperma @hylke1982 and myself are currently working on a continuous validation framework called Gareth ( It is an open source project and we would really like to hear from you if you are interested in contributing, trying Gareth out or just discuss it. Fork us on

Impact mapping:

Continuous validation:

Permanent link to this article:

Sep 16

Meet Gareth. He is seriously unpleasant.

Hello world, please meet Gareth. He can be seriously unpleasant. Trust me, we know. But he is becoming more and more indispensable.

He will tell you clearly, without emotions, when your ideas are rubbish. He will certainly not hold back and he will give you the facts when your assumptions don’t hold up. He will keep validating that your business goals are reached. If not, he’ll let you know.


What Gareth does

Gareth validates the Why, the reason certain functionality was built in the first place. He makes sure that the (business) goals are reached and keeps validating these goals. We all know that implementing one feature can affect another. This also has impact on the success of the related goals.

Gareth loves business goals. He doesn’t want to talk about functionality. He wants clear assumptions like: the performance of feature x will be 25% better after implementing this change; feature y will decrease the usage of functionality z by at least 50% over the next 3 months, and so on.

Why we really need Gareth

There is a lot of focus on software craftsmanship and automation. We can build and deploy software very quickly with current technologies. However, it’s the post-deployment stage that worries us. How can we be sure that this new functionality has the impact the business needs?

We believe user stories and backlogs are too detailed and complex as an aid to communicating with stakeholders. We think it would be better to talk with them about goals and assumptions. What are the goals and how do we want to validate them?

We know the world changes, and so must our software. That’s another reason we need Gareth. It’s vital to know that your goals are still reached after changing parts of the software. Sometimes one feature makes another unneeded. If so, Gareth will let you know.

Gareth Logo incl Name

How Gareth works

We introduce validation as an extra dimension to an user story. We call it an experiment and it consists of:

Experiment: Name of the experiment
Baseline: What is the initial state.
Assume: Which impact do we hope/wish the software is going to have?
Time: What is the interval and period of the experiment?
Action: Which action does Gareth have to take when an experiment fails/succeeds?

Let’s describe an example:

The story:
As the owner of the hotel booking site,
I want the users to see the rooms with discount first,
So that they will be booked first.

The experiment could be:
Experiment: I want to validate that by showing the discounted rooms first, there will be an increase in booked rooms.

Baseline: Get the current number of discounted rooms booked per week.
Assume: There will be an increase in bookings for discounted rooms of 25 per week in the first month.
Time: 1 month.
Success: Send email to the whole team with congratulations.
Failure: Send an email to the Product Owner.

Baseline: Get the number of discounted rooms booked in the last 6 months.
Assume: After 6 months, bookings of discounted rooms have increased by 80%.
Time: 6 months.
Success: Send reminder to buy cake for the developers.
Action: Create an investigative story on the backlog.

Gareth will run these validations as often as described in the assumptions and take the appropriate action. It is a great way for a product owner to be sure the right things are being built and kept that way. This is what we want to communicate to our stakeholders.

It is also great for teams to see that not only code, but also business goals are validated continuously.

Gareth Schema Business

Get Gareth

Are you interested? Please be our guest and try Gareth. Gareth is open source (GNU General Public License v2.0) so that we all can benefit. Do you want to contribute in any way? Please let us know! We are really looking forward hearing from you.

Get Gareth:

Permanent link to this article:

Aug 24

After continuous integration there is continuous validation

It’s a funny thing to say that delivering business value is the most important thing when developing software. It doesn’t matter that a framework like Scrum is far from efficient, because we focus on value. We deliver business value. Working software. Every sprint. Period.

But in the end we often just don’t know the impact of the things we make. What do we really know about the business value we supposedly created? Is it a one-time validation? Is it a one-way validation?

We keep adding stuff to our products because that is what we are expected to do. We always need more features. But do we know the difference these features make, except that there are more features now? More stuff. What if one feature undoes the effect of another? Wouldn’t that be valuable to know? Wouldn’t it be nice to remove it?

Software development has everything to do with validations. There are at least three rounds of validation from ideas to maintaining the software in a production environment.

Validate your ideas and business goals

Cycle 1

The first round of validation is about vision, business goals and problems to solve. Is the vision of the product (still) right? Are the right personas defined? Is the desired impact of the software defined? Are the right activities defined? Are the goals clear? What is the desired ROI?

Continuous Integration

Cycle 2

The second round of validation is about technical and behavioural validation. Features are being designed, built, tested, accepted and deployed.

Live validation

Cycle 3

Hooray! Your software is live! Well, let’s NOT sit back and relax. This is usually the moment where we tend to run back to the product backlog and get started on new features. Burn down those points! Move post-its around like there is no tomorrow! Like dropping your children off at school without ever speaking to the teachers.

Let’s make sure that this is what the world really needs. Let’s also make sure we keep it that way.

Proactive monitoring

Monitoring is often limited to raising the alarms when something is seriously wrong. With continuous validation you are monitoring something else entirely: you want to know the effects new features or changes have on the system and be able to act on them. Use the feedback you get from your users, that is, from the behaviour of your users. For instance:

  • What is the performance of the most important business transactions? Do the new features affect these? If so, how do they over a period of time?
  • What do heatmaps say about the assumptions you made earlier? Or the usage data? Do the users really use the new feature more than the older one? And what about over a period of time?
  • What do the statistics say about the increase or decrease of a certain feature? Was that the intention?

Validate goals

You make your software with a purpose, right? You want to reach business goals or you want to solve problems. But to make sure your software achieves what you intended it to do and keeps doing you need to validate this continuously. If your goal was to sell more items and you implemented functionality to reach this goal, you’ll need to validate its effectiveness. And then you need to keep validating it because software is no concrete structure and will change.


I cannot emphasise this enough: remove functionality that doesn’t meet the criteria anymore. The world is full of bloated expanding products which become even bigger and unusable. Like the gate in the picture. I’m sure there was a good reason to make it and it worked very well when there was a fence. For now it only costs us because it needs maintenance.

Does your product have gates without fences? Are you aware? Not all as visible as the one in the picture I’m sure, but they’ll cost you money just the same.

Permanent link to this article:

Aug 24

More with LeSS

MatroesjkaFor a while now I’m coaching and training Scrum. And for a while I had the feeling that, even though Scrum works, it is very hard to get it to work in a larger environment. so I needed something extra. So I read books about scaling Scrum and I read blogs and talked to other coaches. But somehow I felt that I missed something. I know that in order to get Scrum to work it is important that the entire company is willing to change. But that is easier said then done. I provided training and talked with management. I also provided workshops and sessions. And everything was great and fun but still something was missing so I started focussing on the Scaling models. SAFe (Scaled Agile Framework) was the first one, and even though it seems to work as a larger framework, it didn’t feel right to me. I’m not saying that SAFe is wrong but it just was not my thing. So I looked further. LeSS (Large Scale Scrum) was the next option. I read about it and I liked it. So I went on a course. Four days buffering over powerpoint slides. Games, debates and theory. It was inspiring and fun. The fun thing was that LeSS is just Scrum, only bigger. And that is what I liked about it. The Scrum part was very familiar, but the strategy to get a company to change was something I loved. Not just a big bang and go on with it. The “Here is your training and now you can do it” mindset. The approach with LeSS has much more to do with slowly preparing the entire company for the change. And only doing that change when everyone and everything is ready.

One thing you have to be prepared for is that the change towards a larger Scrum environment takes time. I often have talks with managers who want Scrum in their company and want to hire me as a coach. When I predict the future and tell them that it will take two to three years before everyone knows a little how to work with Scrum, they turn pale. One or two months is what they hoped for and two to three years is not what they anticipated. But when you come to think of it, it makes sense. Most companies have taken years to get to where they are. Through growth and using various models they are what they have become. And all of a sudden they want to change because the market demands it. You can’t just divert overnight. It takes time. And you will have to take small steps. I know now that LeSS provides in those steps and it can help make the transition transparent for everyone.

LeSS is not easy and I don’t think that every company can just adopt it. Same goes for SAFe or any other scaling model or even Scrum for that matter. Change is difficult and for some people nearly impossible. And in order to do so you have to prepare everyone for the change. Make everybody a part of the the new way of working before you start working like that. LeSS provides in this. It provides a gentle slope of change. But once you have started to climb that hill together, the higher you get, the easier it gets but turning back becomes harder. I know, this sounds fluffy but take it from me, don’t just read a book about scaling but follow a good training. Also hire a coach to help you with the change. Sorry, i’m advertising myself and maybe other coaches. But if you want Scrum to work on a larger scale, you need every help you can get. It is no longer a development team with a scrumboard and a daily standup. We are talking about organizational change, and this is something not to be taking lightly. So, more with LeSS, I’m sure it will but you have to invest for the long run.

Permanent link to this article:

Aug 03

Don’t hire a ScrumMaster

smroleThe ScrumMaster is a role and not a job title, so companies posting a vacancy for ScrumMaster are on the wrong track. Earlier we talked about the idea to first answer the “why” question and then start by looking for the right people to help you with the Agile transformation. Lately we see that roles are becoming much more important. Companies need to change to keep up with the dynamically evolving market. But also need to change to adapt to the way people work together. For long we are saying the specialisme is no longer needed. People need to work more together and divide the various roles amongst each other in order to get the work done. Holacracy is more and more the new way of thinking within the business.

So why not hire a ScrumMaster? As the ScrumMaster is a role within the team, the parts of this role can be divided amongst the various team members of a Scrum team. Keep in mind that one of the goals within Scrum is to evolve a team towards self management. So in other words, the ScrumMaster becomes obsolete when a Team is evolving. In some situations the Scrum master role can grow. So someone filling the role might start helping more than one team and slowly evolve towards a team coach and eventually a company coach. When this happens, you know that the agility growth within the company is happening. The Agile maturity is a different matter and we’ll talk about this some other time.

Also when looking at a ScrumMaster vacancy in most cases the role and responsibilities within the role are poorly described. When you analyse that there are more coaching aspects described, the company does not understand what a ScrumMaster should do. A ScrumMaster role is completely different from an Agile Coach role. An Agile Coach is someone who will advise the teams and organization in how to become more Agile. He or she will be advising them how to play the game. An Agile coach also has the goal to go as wide as possible through the company. He or she is asked to help changing. From teams to management and not so much just doing Scrum but also help with the change to become more Agile across the entire business spectrum. An Agile coach is more a change manager and in large companies this is also a fulltime job. A ScrumMaster facilitates Scrum teams to become more efficient in playing the game. A real facilitator.

When there is a poor description of roles in a vacancy, you are probably dealing with a Non Agile organized company. In most cases those companies ask for a ScrumMaster but actually there is need for an Agile Coach implementing Agile or transform a company to become more Agile. When contacting those companies, in most cases, if you’re lucky they have read some books about Agile Scrum. Majority in Agile is low.

When dealing with brokers in between or recruiters, in most cases they do not ask questions to the companies who have published the vacancy. When asking questions about the role in most cases you get no answer either.

So for you companies who feel they need to hire a Scrum master, first look at the real question. Is Agile Scrum sufficiently incorporated into my company. Do I need more knowledge? And if so. Wouldn’t it be better to hire an expert to get things going. To train the Scrum master role with the people already working. Keep in mind that hiring someone from the outside to fulfill the role of a ScrumMaster might also have a negative effect on the people already working in starting Scrum teams. “Am I not good enough?” or “Why do we need someone from the outside when we are supposed to overcome difficulties within the team?”.

For Agile coaches it is one of the first important signals that there is need for more than just a simple filling in the vacancy. It is a clear signal that they are probably dealing with a company who needs help. For the human resource department it is a first signal that others are struggling to work towards change. Help is needed. For teams and management a clear signal that knowledge and support is needed, but not so much by just hiring a Scrum master. And well for you brokers and recruiters, start by doing your homework.

Co:writer Erwin Verweij

Permanent link to this article:

Jul 14

How assumptions are not the mother of all f-ups

The thing about trends is that they will come and they will go. So after the agile trend continuous delivery and devops are in line. I think in a way it is very nice to see that development craftsmanship practices are becoming more and more accepted. We can all benefit from this. Software is eating the world so let’s be damn sure that the software is good. But is it?

Be honest. After the development of the first couple of versions. After adding new features for a while. What is the state of the product? Are the same assumptions holding up? Are your goals still the same? Did the world change? Or is the fact that you can deliver your software in a matter of seconds enough?

Often we think we are building software like this:
What we think we make

But we are doing this:
What we really make

Let’s say we are still building the same crap but at least now we can deliver it faster and with fancier new tools.

Agile, continuous delivery and devops can make our processes and delivery easier. And we can do that in the cloud, with big data and microservices written in Elixir. But that is still only a part of creating software products. We have to look at software development as a whole again. Because that’s the only thing that really counts: making good products. And that does not only mean bug free or easy to deliver.

Why continuous delivery isn’t finished

The prerequisites didn’t change at all. With bad input and lack of validation the results are mediocre at best. It made my colleague Hylke Stapersma (@hylke1982) and me think about why continuous delivery isn’t finished and what we are missing. So we started experimenting with this. In the following blogs we will describe more of the technical journey. for now it’s about the concept.

Step 1: Stories that don’t suck:

Good story describes the goal a certain user wants to achieve with a piece of functionality (the why). It should be pretty functional. It works very well to add acceptance criteria (BDD/ATDD scenarios) in an early stage to fine tune and make sure a functional validation is in place. Let’s say that’s all in order.

We now want to introduce another dimension to make sure we achieve our goals. We add something we called an experiment, which includes some assumptions, to an user story. These assumptions can be measured and will automatically be validated.

**And for me it is not about being SMART all the time. I’m definitely more of a DUMB guy. It is more about validating assumptions than the measurement in this case anyway.

Here is an example of a story we are using in our demo setup which contains both the BDD feature and an experiment:

CD is the start1

Step 2 – 8: Do the magic: build and deliver the best software ever seen.

CD is the start

For a more indepth explanation of this model please check this blog.

Step 9: monitor assumptions.

If the results of the validation are under expectation, these result should have impact on the backlog. In theory the result of the validation is more valuable than any new feature you were dying for to implement. To be honest, the story in which the assumption was made was highly prioritized.

So one of the first thing we saw is that in contrast to unit or acceptance tests we now have the time dimension. Our behaviour tests run a couple of time in the continuous delivery pipeline but never when the software is in production. There’s no need either because there are no changes there. In the case of the experiment we have a starting point, our baseline, and from there we will schedule a periodic validation of the assumptions we made. We can validate as often as we want. Why ever turn them off?

Removing features is not a bad thing people.
If you find out that something is rarely used please do not be afraid to remove it. That will make your product leaner and your codebase cleaner (there is a song in there). Also here the validation of assumptions can be very handy. Because we can measure over periods of time we just set a limit and everything below that we have to evaluate. If something isn’t as valuable as expected then I would like to know that. Often by adding a new feature an older one becomes unnecessary. No problem. Just remove it and try again.

Impact mapping.
If you take a look at impact mapping you see that assumptions are a big part of it. Those are the things we often can make measurable. In our case add them to an experiment and validate. Impact mapping is a great way for us to gain insight in the many assumptions we make. If you don’t know impact mapping I can recommend the book by Gojko Adzic.

Non functional stories.
A story has to describe something that has value. But sometimes that value is easier to define than the functionality or the user. And what to do with some non-functional stories? I think we all have had experience with user stories that feel artificial. Like we can’t even describe a proper user for it. We just want to decrease the costs of operations with a piece of functionality for instance. Should we describe “ the members of the board” as users? It just feels artificial sometimes. I think in those cases an experiment/assumption could replace the story.

In the future we want to be able to also use information of tools like AppDynamics or Google Analytics. Those have so much information that will help the business in making good products. Performance and usage are definitely things that are key in that process.

So, in conclusion, in contrary of an earlier blogpost of mine, in this case assumptions are not the mother of all f-ups. Assumptions are a step in completing the whole flow of software development.

We are currently implementing this idea and will share our findings and solutions in one or more following up blogs. Stay tuned!

Permanent link to this article:

Jul 04

Don’t start with the vacancy, start with the question

Scaling at the beach

“Hi we want to hire a Agile coach with LeSS or SAFe Certification. He or she will provide our teams with some training.” Well I hate to bring this to you, but this does not work. The first big question you have to ask yourself as a company is “why”. Why do you want to scale. Is it so that work will go faster and teams will work better or the competition is also doing it. Then don’t do it. Is it that you want your time to market to go up and actually start to deliver valued work more easily with everyone involved, than it might be a good idea. But even then don’t focus on the framework but start with the question. The first thing that companies should do is ask a good Agile coach who does understand large scale agile and ask to help with the big question. Sit down with management and identify the challenges, current affairs and mindset. Visualize the challenges and pressure points. Where are possible areas that could benefit from change. And then focus on what would work best. Only then you can start thinking about SAFe or LeSS or any other model.

I wrote an article before about scaling where I said that I’m not a huge fan of scaling scrum models. Not so much that it is not a good idea to scale. I think it is great when a large company want’s to change and involve everyone and everything in the change. But lately I see a lot of Scrum vacancies for Scrum Master or Agile coach who also has to have SAFe (Scaled Agile Framework) or LeSS (Large Scale Scrum) certification. I’m not a big fan of SAFe, I think it is too complex and way less Agile than LeSS. But I do believe that at some level it might work if you do it right. I recently became a Certified LeSS practitioner so I know a little bit more now about scaling. And yes, also LeSS only works if you do it right. The reason I don’t like scaling models is that companies who don’t understand anything about it and want to implement some sort of large Agile framework, think and even believe that by just hiring people to train people within the company, the question is answered.

So again, start with the Why and then the What and How. The Why is the reason you want to change, the What is, well what needs to change and the How is they way you probably could do it. I say Probably because there are no certainties. A certified coach is not a guarantee that it will work. A coach is just someone who can ask the right question and trigger response. The change will have to come from every layer within the companie. And it starts at the top. It starts at the top with change and If you don’t want to go all the way then don’t. Stop hiring SAFe, LeSS and Spotify experts and keep doing what you’re doing because when it does not start from within at high level, and you don’t know why you want it. It is not going to happen. Ever.



More about LeSS (Large Scale Scrum)*
More about SAFe (Scaled Agile Framework)*

 * the “e” is just added for the fun of it

Permanent link to this article:

Feb 05

Scaling Agile, steep mountains have slippery slopes

7699228408_e7805285c5_kA lot of IT companies are trying to work with Agile. And most of them are having some sort of success. But the bigger the company the more difficult it gets. Getting Scrum to work with development teams works in most cases but surrounding management and connecting departments have a hard time to adapt.

To accommodate this we see a new trend. Scaling. Scaling Agile to help larger companies to make the change and gain the benefits of agile frameworks like Scrum or Kanban. But this comes with a price and to my believe might in most cases not even work. When a company starts to work with Agile, often Scrum, a change is set in motion. Communication and interaction start to work differently and the focus moves from budget driven to value driven. As I said, most often the development teams can work with Scrum but the interaction between these teams and the rest of the company becomes blurry. So systems like SAFe, LeSS, Scaling Agile, Blowing up Scrum or whatever the name, are brought in. Sometime because someone read an article or a coach is challenged to come up with something that fills in the blanks. I have heard from companies who start directly with these larger systems without even trying to get the basics like Scrum to work.

Why doesn’t it work? Keep in mind that the idea of scaling comes from the fact that there is a feeling that Scrum does not accommodate the larger picture.  Scrum doesn’t say anything about architecture or design. It doesn’t say anything about DevOps. So smart people start to invent large scale scrum solution that accommodate the bigger picture, but in doing so they forget two very important things. The first one is that the Agile mindset is about people and bringing value. Frameworks like Scrum are designed to help people to communicate and work on value. And they are horizontally throughout the company. They feed on what customers want. Traditional process management on the other hand is budget driven and feeds management and sometimes shareholders. You can read about this in an article from Forbes. Large scale Agile systems are to keep this vertical system in place and in most cases go against everything that Agile stands for. The idea of using Scrum is so everything becomes visible. The good things but also the bad and painful stuff. Agile as an mindset can then help to make the change.

The second thing is that often examples from other companies are used for these Scale Scrum Systems. Spotify is a good example. At Spotify they started small and with Scrum. When they became larger, they adapted Scrum so it worked in their larger system. They started to use Tribes and Chapters. And it is very cool, but keep in mind that this is something that Spotify worked out by themselves. They knew the potential of Agile and got it to work and designed their own Spotify system. This does not guarantee that this will work for other companies. What is good for one might hurt another. So when a company works with Scrum and finds that is does not completely work throughout the entire system. A click and play scaling Scrum system will not work. Each company will have to start working on their own Scaling. Every company has it’s own unique DNA and even though they all might develop software, the people doing this have a unique mind. You cannot upload a system into that mind and hope everything will scale. You have to build it from the inside out and using the companies own building blocks.

We often say that frameworks like Scrum are easy to understand but are very hard to get to work. There is no plug and play solution. We often try to adapt systems or frameworks to the needs of the company. Most companies have grown so large that it is nearly impossible to control. So we try to fit something over the mountain. But when are companies going to learn that maybe they have grown too big and made thing to complex. Maybe it is not about Scaling up. Maybe it is better to start sizing down. To go back to the basics and look at what is really needed and what will bring value.  I know of companies who work with around 250 developers and 5000 surrounding managers and supporting functions. What went wrong there? Together they try to control a large software landscape where most of the functionality isn’t even used anymore. But nobody dares to touch it, change it or throw it away.

So the question is not if you need to scale? The question is if you can reduce. And if this is somehow not an option, don’t just pick a ready to install Agile Scaling system, because they don’t work like that, but start to change from within the DNA of the company. Use Scrum as the tool to make the path visible and apply Agile as you navigation. That’s the way to scale the mountain. And I can provide a lot of metaphors hear about slippery and danger. But I think you can figure it out by yourself. So don’t just use an “instant” scaling system but device your own.

Permanent link to this article:

Jan 12

Bring home the bacon not the receipt

BaconWhen did we start to lose track of what we really needed and began focussing on how much something costs? As a Scrum Coach I see it more than often that customers ask how much time something takes. How much effort and money is needed. The planning of a project is build upon the time people are consumed by it and decisions are taken on these plannings. Often I hear that developers need to do something within a certain time. It no longer is important what they do but it seems it is more important on how long it takes.

Somehow it seems that businesses have lost track of what it is all about, namely the delivery of something that is needed. Something of value. A product or service that can help the customer to do business with. The fact that at the end of the year in almost every company, people start to worry about the budget. Either they have to spend the last dimes in order to preserve the same budget for next year. Or there is not enough and more is needed. It is never about what is really needed. I have always disliked the thinking in budgets and end of year nonsense. Somehow customers and companies have lost track of what they are doing. Al the energie seems to go in the effort and not in the result.

In the time before software it seems it was all a bit easier. You needed something. You got it. And you paid for it. You left the store with something that brought you value or satisfaction. Over time products have become more complex and we no longer know what it is that we need. Sofware is no longer something that you can save on a disc, it is intricate and has connection with other networks and services. The scope is lost and the only thing that people seem to hold on to is how much lose is made on something. It seems easier to control how much is spent than how much is gained. This is strange. When you walk into a store, you will look at what you want to have and you make sure that you take it home. I never walk into a store to get something but the only thing I take from the store is the receipt. What I got is not important. Can you imagine going to the grocery and buy stuff you need. But when you get home you tell everybody how much you spend and that you stayed within budget. The groceries you left at the store, but hey you stayed within budget. Seems strange but we do it all the time.

Big companies only seem to focus on controlling budgets and not on what is gained in value. They have lost track of what it is all about and forgot the groceries. No wonder that employees of large companies have no idea what everybody is doing. As long a they work hard, show some results and don’t take to long in doing so. So think of this. What is more important to you as a customer. Getting something of value, something you really want. Or spent money and stay within budget. Do you want the groceries or the receipt? If you want the groceries start by focussing on the value output and not on the cost. Stop wondering how much time something will cost, but focus on what is delivered and why. The why is important, because if you get something that you don’t know why you want it, then why spend money on it.

In order to move towards a more logical delivery of goods, companies need to change their way of thinking. Stop looking at the cost and start looking at the value. Stop thinking in budgets and start with value streams. And most important, start with looking at you groceries and bring home the bacon.

Permanent link to this article:

Dec 08

Make sacrifices if you want to change

zurbaran-agnus-dei-lamb-of-god-madrid-1339x800“We only do scrum where and when there are problems within the company” the guy said on the other end of the table.”Otherwise we just keep doing what we are doing”. I almost dragged his ass across the table. I often hear this. People think that Scrum is something you only do when you want to solve a problem, as if it is a short term fix. The silver bullit you can fire and then all is solved. Well I hate to bring this to you but it is not. Scrum has to do with organizational change. Once you start to implement, the effect will be noticeable throughout the business. I agree that Scrum is not something you do just for the fun of it. You have to realize why you need it and what you hope to achieve by implementing it. But once it is running it is very difficult to go back.

I also agree that Scrum is not something you do when things are going great. It is something you do when things are not going great. When revenues from developed work are not up to the standard or could be better. It is not so a team can perform better and management can lean back in comfort. And when suddenly things change and work is not delivered as planned by sales, you stop Scrum and go back to the old way of working with micro management. I also see this a lot. “We really have to deliver on that deadline so we quit Scrum until things are smooth again”.

The biggest challenge is to get a business to see that when you want more revenues, better quality work and delivery of work that really has value, you can work with Scrum but you need to go all the way. It is organizational change. Everything needs to change. People have to start working differently. The old ways will have to go, and if that means that people have to change or even have to go, then so be it. I’m a big fan of Ricardo Semler and he said, more or less in these words, that a company is not a family. People come to work, provide a service and get paid for that. The company needs to grow and make profit. And when it doesn’t, you need to change and improve where you can. The company is not for providing jobs, it is to make money. If your company is doing the right thing then people delivering the right thing together can be happy in doing so.

So if you embrace Scrum you need to be willing to change everything. To radically reorganize everything. People who are willing to see this and want to move with this change, keep them and help them where you can. But as soon as you stumble upon conformism, act with your goals in mind. You want to make money and be a successful business. You want people to work together on things that matter so they can produce a good quality product so you can satisfy customers. You do this with people who are willing to do so. You don’t want to do this with people who are out there to save their own ass and their own job.

It may sound a bit harsh but keep in mind why you want change. Why you want departments and people to start working differently. What is the goal of what you do. Is it keeping people within your company happy by solving problems when they occur or is it to be successful and change so problems won’t occur? It’s not why you want to do Scrum. It is why you want to change. The you can look at what you want to change and the how can be with Scrum (thanks Simon). You need to see this first and make sure the people who are at the helm see and understand this and know that you need to change and make sacrifices in order to excel.

Permanent link to this article:

Older posts «