Apr 30

With law our land shall rise, but it will perish with lawlessness

VikingsThe Agile Manifesto was written in February of 2001 by seventeen independent-minded software practitioners . While the participants didn’t agree about much, they found consensus around four main values. For those of you who are not aware they are as follows.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I think everyone working with Scrum or any other agile framework should be aware of the manifesto (if you’re not, shame on you).

But the Agile manifesto is nothing new. Working together and do something that is worth something for someone is a good idea. Knowing that a plan does not always work and things might change is good to know and react upon. For a while now the manifesto is used. As agile coaches we say that is good to be agile and not do agile and that is fine, but it is still a concept that for most newbees is hard to grasp. We work together and deliver software or something else but still clinch to old habits and ways of thinking. It is not easy to become agile and change your mindset overnight. And how can you become something if there is not a real example. Or if you like, there is not a real role-model. I like the way the first agile thinkers came up with this but I wouldn’t wanna be them. I’m not a Sutherland, Swabber or any other agile founding father (that sounded really scary). So how can you become something else without something to inspire you. It’s fine that you can work in a team and deliver high quality products to a happy and engaged customer, but that does not turn you in a agile minded person. So where can we find inspiration?

As I said, the manifesto is not something new. There is something that is much older and it originated somewhere in 10th century. Yes, more than a thousand years ago somewhere in the north of europe. Somewhere in the Norse world the first of these laws originated amongst the vikings. They were not made up with Agile in mind but with something else as a goal. They were written to conquer and rule. The vikings came up with the “Viking laws” and over the years they changed a bit. The Norse also were very straightforward incoming up with all kinds of laws and agreements on how to behave or life together. The very word LAW in English is a Viking word. After the vikings stopped their reign of terror and christianity spread, the laws changed and became less aggressive. But the first four basic laws are still very powerful. So what are they, and keep in mind that the sub-laws derived from the original four laws.

First law: Be brave and aggressive

Now this one strikes me as a good first rule when you are a warrior, but it can also be used in business. It is also very well usable in producing something. So what does it mean, Be brave and aggressive?

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

Second law: Be prepared

Need I say more. It’s all about team and team dynamics. And to be prepared means you can do the following.

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


Third law: Be a good merchant

This one could apply to product owners, salespeople and even managers. I think it should be an sales oath.

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


Fourth law: Keep the camp in order

Workplace, work environment and working together. And it is not just keeping you sprintboard up to date.

  • 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


If you read these laws with a working environment in mind it makes sense for your team and even your company. These simple laws worked for the vikings and admittedly they are written so they are a bit more acceptable for our thinking.  The vikings didn’t have a workplace or went out to find what the marked needed. And also being on the other side of the viking blade was not a really good place to be as they used these laws to plunder, pillage and rape. But for the vikings it worked.
From now on I don’t print the Agile manifesto to be posted on the wall, I provide a cool poster with these viking laws. I think they are much better to understand and relate to. Because let’s be honest. I much more like to be associated with a tough viking then with one of the seventeen software practitioners who gathered in Utah to come up with the Agile manifesto. I’d rather be a Agile Viking then a Agile Coach. I think I will put that on my next business card.

Many thanks to Rolf Dräther from Happycentric.de for introducing me to the Viking laws.

Permanent link to this article: http://agilethings.nl/with-law-our-land-shall-rise-but-it-will-perish-with-lawlessness/

Jan 22

The Curriculum Vitae is history

Erwin VerweijLet’s face it. The Curriculum Vitae (CV) does not work. Curriculum vitae is a Latin expression which can be loosely translated as [the] course of [my] life according to Wikipedia and is used by many of as to show to potential employers what we have done with our professional lives. It is a sum of all the thing that are in the past, our former jobs, education and so on. I’m sure that you as a reader have your own version. Needly designed with the right typeface, layout and information, ready to provide at the first opportunity. Or better, ready to provide at the first demand. So why does it not work?

The truth is not in there
At first, let look at the name, Curriculum vitae, course of life. It is a document that looks backwards in time. It tells what you have done. This seems something of importance but we all know that in our CV we only tell the things that we are proud of. We tell of our achievements and the victories, it doesn’t say anything about the lessons learned. The struggle, the pitfalls or the failures. Why, because we are not keen to share this and potential employers would skip your CV if you would mention them. This is strange as it is in these lessons that makes us unique and also very interesting. So we keep those difficult questions for the job interview where we have to share a little of our bad experiences but not to much as that would also jeopardize the interview and the change of being hired. So when you come to think of it we lie on our CV and try to camouflage the truth as much as we can. So first of all, what is the point in writing down the past when it is only half the real thing. And sharing a reference, same thing. You would not share the name of the manager of the job that you screwed up, or the one that screwed you up.

You don’t want to go back
Second, we send our CV to potential employers in the hope to move forward. To get that new job or assignment and to grow and learn more. Most of the time we do that because we have to. either the current job is ending or we are not happy at where we are. If you look back into your past all of us have jobs that we hated but also jobs that we really liked at that point in time. But there is a very small change that you would want to go back to that former job. Even if it was the greatest job in the universe, there was a reason that you moved on. Either you got bored and there weren’t enough challenges. Or the payment was bad. Maybe the company moved and you were not that dedicated to move with them, or they simply went bankrupt. Just to name a few. Either way those ships have sailed and you moved on. So why keep lingering in the past. As I mentioned before, we only tell the good things about our past experiences so again there is no point in doing this.

Surpassing the teacher
The third thing is what we have learned. We sum up all our training, certificates, diplomas and so on. Nothing wrong with that as it is something that you have achieved and worked hard to get. But how many of you remember their basic teachings. All that gained knowledge has grown over the years and we added a lot more from experience, reading and doing. When I look at my own learning past I even got diploma’s for welding, steel machinist and even electrician. Trust me, you don’t want me in your workshop or let me do your electrical wiring. I simply forgot and probably end up making a mess of it. But still people ask me for information about that part of my life. Who cares, I moved on way beyond that knowledge. Although I still have some affection to technique. So, when we are honest about what we know, most of it is from experience and learning on the job. Even from reading but I haven’t seen a single CV where there is a prefered booklist.

Look ahead
So three things that just look into our past and none of them makes any sense. So what should we do then. Well that is very simple. Talk about what you would like to do. Where do you want to go, what is it that you still want to learn or experience. Often we are asked to write a motivation alongside that CV. Why do we want to work somewhere? Well to be honest, I don’t want to work anywhere. I much more would like to sit in my garden drinking a cold beer and reading a good book. I would only trade that for a really nice challenge, something cool, where there are great people from whom I can learn and share my own experience with. I would love to leave my garden and cold beer if I can really make a change somewhere. And no, i don’t want to do what I did in the past. The same things over and over again, I want to grow, learn, teach and experience. When I’m asked why I want to work at a certain company I have no idea because I haven’t worked there yet. I do know they have a great product or service that I would like to get to know more of and maybe even leave my mark on it so maybe it can become even better.

Who do you want?
When you think of this as an employer, who would you rather have. Someone who has done the same thing over and over again at different companies. Or someone who is keen on doing new things, eager to grow and willing to make mistakes and learn from them. I agree that a CV provides a shallow look into someone’s past, but admit that someone’s future is much more interesting. A new thing, especially in europe is the Resumé. A short description that, when done right, tells what someone would like to do. What they want to learn and where they want to go. My CV, that I hate to use and send, is about 4 to 6 pages long. My Resumé is one page and let’s you know what I like. It has two or three lines in it about what I have done and learned. Until know I have had more success with it, than with my Curriculum Vitae. And I’m even replacing my Resumé with just a picture of myself with my passions displayed. 

The CV is looking backwards and somehow, the way they are written, not really reliable. You better spend time in looking what someone is willing to do and where they can take you. Don’t look for someone with ten years of experience. Look for someone who is willing to experience for the next ten years. You want energy not waste. And be honest, you want to read a small poem about someone’s dreams, not a six page history book. And if you want to know about someone’s past. Just ask them over for a nice cup of coffee, I’m sure you will switch very fast towards dreaming about the possible future instead of lingering in the past.

Permanent link to this article: http://agilethings.nl/the-curriculum-vitae-is-history/

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 impactmapping.com illustrates how impact mapping works:

foto: impactmapping.org

  • 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.

Foto: impactmapping.org

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 (getgareth.io) 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 https://github.com/craftsmenlabs

Impact mapping:

Continuous validation:

Permanent link to this article: http://agilethings.nl/impact-mapping-and-continuous-validation-2/

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: https://github.com/craftsmenlabs

Permanent link to this article: http://agilethings.nl/meet-gareth-he-is-seriously-unpleasant/

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: http://agilethings.nl/after-continuous-integration-there-is-continuous-validation/

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: http://agilethings.nl/more-with-less/

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: http://agilethings.nl/dont-hire-a-scrummaster/

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: http://agilethings.nl/how-assumptions-are-not-the-mother-of-all-f-ups/

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: http://agilethings.nl/dont-start-with-the-vacancy-start-with-the-question/

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: http://agilethings.nl/scaling-agile-steep-mountains-slippery-slopes/

Older posts «