Why should you have an agile coach?

Why on earth should you spend money on a coach, especially an agile coach? We need developers who can write could not some coaches running around and doing strange exercises and prevent the teams from doing their job. That is one answer. I think many people really wonder what an agile coach is and what value they can bring so my intention is to trying to give an overview of that in this post and also try to explain what value they can bring.

What is an agile coach?
An agile coach is a person who have a great knowledge about agile & lean and know how it can be used to help organizations being more agile in order to achieve their goals and be more successful. This might sound strange but I think that the agile coaching competency framework can give you a better overview of what and agile coach is.

Agile Coaching Competency Framework

Agile and Lean Practitioner
Agile and lean are the foundation for every agile coach. They live by the agile manifesto and it’s values are reflected in every action and decision. The coach is a role model of an agile person. By observing the coach you can learn what being agile means.

Coaching
Professional coaching is about helping people to move from A to B. An agile coach team up with people and help them helping them selves to solve their own problems and moving towards being agile.

Mentoring
Mentoring is about sharing experiences and knowledge to help people grow and solve their problems. A bit like coaching but more focus on knowledge sharing instead of letting the person figure out their own solutions.

Teaching
Teaching is a bout teaching people about agile and lean methodologies and practices such as SCRUM, Kanban, TDD, Pair programming and much more.

Facilitation
Facilitation is about helping groups creating an environment and process in which groups can collaborate to solve problems. This means designing and running workshops and meetings where the coach guides the team to a desired result.

Mastery
Mastery is about where to coach have his/her special in-depth knowledge. The technical mastery is about being good in the craftmanship of building software. The business master is about being good at building products with high business value . The transformation mastery is about being good at helping organizations to transform and change to become agile.

 

I hoped that gave you the big picture of what an agile coach can do and help with. If we try to look and what value this brings, what is it really the coach does? The coach help the organization to change it self in a direction to be more agile. The coach work from individuals to teams to the whole organization to achieve this. It’s all about support. Much like a coach for a sports team who help their team to always perform better and be at their best. But why should we be agile, whats the value in that? With an agile organization you can deliver the right business value to your customers fast and  your are  fast in adopting change so that the organization can adapt to an environment that constantly changes. What’s best today my be out dated tomorrow and then you need to able to adapt and find your place in the new world as fast as possible. You can see it like evolution. An agile coach help the organization being able to have a fast evolution so that they can mutate in order to survive even when the environment changes dramatically.

Why should you invest in an agile coach instead of a new member to the team?

It all sounds good with a coach but in the end of the day it’s all about the software your company produce. That’s true and we shall never forget about that. But if you don’t have an agile coach today you might consider to get one. A new team member sure helps you produce more stuff but a coach can help your organisation to improve, including all people inside it so that they can produce more great software? Maybe that’s a reason to invest in a coach instead? Sure it’s hard to measure and find out if the coaches actions really bring a higher productivity, all the fancy things with post-its and talking to people can it really bring that much of a value? Can’t we just have the coach for sometime and then do it ourselves? Of course but having someone who focus on keeping you at high-performing mode might be needed for many of us, including myself. I personally belive that investing in a coach really pays off and definitely is worth the money in the long run. Because if you have an organisation that can’t adapt to a changing world it doesn’t matter how many lines of code you can write, your company will die and a new and better suited will take your place and thrive in the new world.

 

What’s your choice, hire a developer today and cash in for a short period of time, or hire a coach and cash in and make a difference for a long time ahead?

Read More

Mob programming – One way to create real teams

 

Mob

I love working in a team and they days I work together with other people are the best days. This is the exception of how it works. Usually we sit alone at our desks and work on our part of the user story.  Maybe we talk about a problems sometimes but most of the time is spent alone at our computers. Oh and we meet at the daily standup at least. We also meet at backlog grooming and retrospectives but is this really team work? Are we a team that collaborate or a bunch of people who happens to work on the same thing and sitting in the same room? I think we are the later. Does that mean that we don’t collaborate? Of course not. We do some collaboration but I think it can be much better but the question is how? Maybe we should all work on the same thing all the time standing around one computer? Sounds crazy and ineffective at first but maybe it is not such a bad idea.

(more…)

Read More

Happy Change become Your Change

As you may have noticed the blog have changed name to Your Change instead of Happy Change. The reason for this is mainly that I decided to start a private firm that will mainly focus on coaching for both individuals and companies. As a result of that I filled the papers and suggested Happy Change as the name. unfortunately this name was not allowed. My girlfriend came up with the name Your Change. At first I thought it was not as good as Happy Change but after a few weeks with the name I like it more and more and think it’s really great.

 

I still have some things to sort out before everything is done but I hope to have everything in place and be up and running in September. I will continue to write this blog and do it in English even if the company is targeted and Swedish customers. I have some blog posts in progress so stay tuned ;-)

Read More

What if real software projects were like our hobby projects?

Have you ever wished that your current project was more like your hobby project? I have done that for a few months now and would like to share my reflections about my latest hobby project. I think a brief introduction of the project is a god place to start.

The project

It’s a web application to help the rabbit jumpers in Sweden to manage their rabbits and competitions that is called Skuttli.  There are about  18 local clubs within a National Association for rabbit jumping, they are the target users. The reason I build this is that I love to solve problems and had previously built some small applications to solve a few problems for my girlfriend but I felt that a more general solution for all clubs was the next step. I started with a vision that Skuttli could be the Nation Associations preferred system to mange rabbits and competitions. With me as developer and product owner, my girlfriend and some other key users we started to build Skuttli and so far 6 clubs use it and  more are about to start the coming weeks. I think we already can say it’s a success based on the users feedback and hopefully it will be the preferred system in 2015.

Passion, purpose and the users

Everyone involved in the project are passionate about what they do. They do all work because they love it and not because they get money for it. This is really great and have resulted in a lot of feedback which have been invaluable to me. I know what they like and don’t like, what problems they have and how Skuttli is used in the field. I guess I have a strong connection to the users and really care a bout their problems and every support case is about helping them with a real problem and making Skuttli even better. The fun think working this close to the users with the fixes delivered directly to production is the fast feedback and verification that I mad a difference that very soon have my users value.
Another thing that have made me build a better understand of the users and deepening my connection to them have been to do what they do. You could call it a mini internship and it have been really great to learn and see what works and doesn’t work. This have given me some nice ides and deepened my understanding of the domain.

Planning
(more…)

Read More

How to handle the never ending buglist

Angry cat

We have all heard about it, we have all contributed to it and most of us have worked with it, but have anyone really seen it? With seeing it I mean without a filter? I mean physically on paper or maybe a big screen, if there are so big screens? The bug list is usually endless and contains hundreds, thousands or even millions of issues.  Wouldn’t it be nice to get rid of it? No it’s impossible you say, how shall we have time to fix all those bugs? Well there might be a way to handle this, without fixing all bugs. All you have to do is to follow three simple steps.

1. Be honest

The first thing we need to do is to be honest to ourselves.  I know it’s hard but it’s the first step. We must admit to ourselves that we will never have time and/or money enough to fix all bugs in our software. I know it can be really hard to accept, it was a bit shocking for me when I realized this but I have come to like it somehow.

2. Inform your customers and users

Second step is to talk to our users and customers about the truth revealed in step 1. We need to tell them the truth even if it’s really hard and most likely will cause conflict. Maybe they will be angry and tell you about their agreements that say x and y about how long it shall take to correct bugs and that they want all bugs fixed. But lets pause here. Here are some questions to think about:

Do your customers really want you to fix all bugs?
Do they want this even if it means that you will add less value by adding new features?
Is a bug more important than a new feature?
Can fixing one bug give more value than fixing 20 other bugs?

What is the value to store all these bugs that will never be fixed(or some time in a distant future)? Is it that we shall have something to talk about and blame on each other about when we talk and get disappointed at? Of course not. We need a could relation with our customers and in order to have that we need to be transparent and honest. Transparency and honesty can’t be built on false promises and hopes. We need to take the conflict and find a way to communicate this. It will be hard at first but when things have settled it will start your journey to a better world.

 

A world where we talk about the value/outcome that each correct bug will produce instead of talking about how many bugs we have fixed. The conversations have shifted from agreement discussions to value and outcome discussions from both your perspective and your customers perspectives.

3. Limit the list

A good place to start is to a limit the size on the bug list. Sounds crazy but this is the only way to take control of this bug list and minimize its damages like:

* Wasted time on administration
* Dishonesty between you and your customers
* Focus and energy wasted on the wrong things

But a bug is a bug? No a bug is not a bug. As with features there are always some bugs that are more important than the others. If they are equally important just pick one. But what do we do with the bugs that don’t fit the list? Well we just throw them away. Yes it sounds crazy but if we do not do it we will start to create the endless list again and be lying and we agreed in no more lying in step 1, right? If a bug is important enough it will be reported again and added to the list when there is room. I promise this is true even though it sounds strange.

Reality check

This sounds easy enough when you have one customer, but what to do when you have more than one, maybe 10 or 50 or 1000? This is when it becomes a challenge to be honest. We have more bugs from more customers that we can handle and we have a limit on the bug list? Should we just say sorry you can’t add any bugs because the bug list is full? Yes if that is our opinion after a quick look at the bug that it’s not  more important than the other one then we throw it away(or we could save it in the system as a first step as deferred).

This is pretty radical and might be hard to start with even though I think it’s the best solution. Another approach would be to limit the number of prioritized bugs per customer. Different customers can have different limits depending on their support agreement. When we do this with the customers we must be honest and tell them that all the other bugs will not be corrected until we have room on their priority list. This way we are honest and let the customer prioritize their own bugs and as a result we know that we fix the most important bugs for our customers and they know which bugs we will correct.

Summary

So what do we need to do?

1. Be honest that we can’t correct all bugs.

2. Have a discussion with your customers and focus on value/outcome instead of number of corrected bugs

3. Limit the bug list

4. Follow step 1-3 and learn from it and adapt. Just remember to be true to step 1-3 when making adjustments. It’s not easy to change things but it will be a start to a better life for us and our customers. Maybe not a life without lists entirely but at least a life without endless list with realistic expectations :)

 

So what do you think? Is this possible? Will you try this or do you have any other ideas on how to do this?

 

photo credit: Nebojsa Mladjenovic via photopin cc

Read More

How we buy software

When people shall buy software they compare it with how they buy other things like milk or cars. You have a limited number of options and go to the shelf and buy what you like. The milk and the car are complete products that have been developed for years and are considered done and the buyer can’t make many adjustments. He know what it will cost and exactly what he gets. This is standard and from the customer’s perspective, why should software be any different?

The customer tells us what he wants and we tell him what it costs and then we build it. How hard can it be? It sounds simple but we know that customers change their minds and realize that they need something different from what they said from the beginning. Because software is easy to change we can tailor it along they way to fit the customers needs and business  so it’s not like moving a highway or a floor in a house. We can easily change to the customers advantage but this is not for free unfortunately.

When you buy a car you can’t change so much because you don’t start from scratch, you don’t develop a car specific for one customer. Instead you build a few different cars that will fit as many users as possible and when you have found out how they shall be built after a long development you decide price and sell them to customers. This applies for most of the things we buy, we don’t see all this development, we just see the result of the development and know exactly what we get to a fixed price. Imagine that you could set a price for your software AFTER it was built, or even estimate it, what awesome it would be :)

For standard software like Windows, Office, Photoshop, Gmail, Spotify or any other product it’s easier to set a price because then you as a customer accept the solution and do not need any changes. Well you maybe need changes but you can’t pay the companies for them. When a customer need changes to a standard product or an entire new product for their specific needs we need to build a tailored solution specific for that customer. Because of that it’s specific for the customer it’s something that we have never built before and we know that the customer does not fully know what he wants . Before we have built the product the customer want’s to know exactly what it costs, when it will be done and exactly what features it includes. Quite a challenge we have here, right? So how do we usually solve this? Well the customer make a guess and try to write down everything he think that he might need and we make more or less bad guesses on how much time it will take and cost. And how does this usually ends? Well the maturity of all software projects fails so I guess we need to come up with something better.

How do we explain agile contracts?

So how can we build this in a better way? One way is for the customer to say how much money they can spend or define if they need something for a specific date. Exact features are left for later because we know that we along the way, most likely, will change our mind about what we need and we start with the most important things first. Regularly we deliver what we have built and get feedback from the customer to decide what to build next until either the customer is satisfied, the date comes or we’re out of money. With this model we know that we have built the most important things first and have after a short time delivered value to an acceptable price.

This sounds really nice to me but some people thinks this sounds strange. So you mean we shall give you a lot of money but we don’t know what we get? It’s like buying a car a we might end up with only four wheels and GPS. I totally understand their concerns and that this sounds a bit crazy and I still struggle to find a good way to explain this to the customers so that they can understand what this is and see the advantages. I have been thinking about a good metaphor for this and I think that I have come up with one the might work.

The metaphor

Let’s say you have decided that you home needs a make over. You’re tired of the old design and need it to be more modern a cozy. You start to dream about how the entire house shall look and start to select materials and interiors for all rooms. You go to a company and tell them a bit about your plans. They say that your plans sounds expansive and asks for your budget. If you’re like most people you have not unlimited funds so you decide on a budget and tell the company. They recommend you to start with one room at a time. They will get you a complete usable room every week and show you the progress at the end of every day so that you can come with feedback so they can change if necessary.  With this model you pay weekly and can end the project at any time. You could also decide all materials and design upfront but from their experience it’s not a good choice. You decide to take one room at a time and start with the kitchen. The company now asks you what you want to change first in the kitchen and you say the ceiling. You pick a dark ceiling and also want’s a dark floor but they recommend you to first pick ceiling so you trust in them. They install the ceiling on Monday and you find it to be really nice at the daily inspection and that the floor is not that bad and should definitely not be dark. Your next choice is the fix the walls in the kitchen so they get some new color. You pick blue and they paint it blue on Tuesday. At inspection you find out that it’s not good at all and ask if they can change it and they do and on Wednesday they paint it green which you like much better. You like the result and think now that 15% of the budget is spent you want some progress in the other rooms before you do anything more in the kitchen. Like this it continues until that you are satisfied. When you are satisfied and all rooms have a new look you see that there are some money left for fixing the kitchen cabinets but you think it already looks so good, even better than you first imagined, so you decide to end the project with a different and better result than you first imagined to a lower cost then first calculated.

 

What do you think, is this a good metaphor or how do you sell in agile contracts to your customers?

 

 

 

 

Read More

#NoLists – What would we do without our product backlog and other lists?

I have been reading about #NoEstimates for a while and I think it has a lot of interesting ideas. Inspired by that and observing my environment I see that people seems to love lists. I do not mean lists like arrays or linked lists in programming, I mean lists like product backlogs and other to do lists.

Everywhere I hear people talk about in what list they shall put that work and what tool is best suited or how it shall be configured to be able to keep track of all the lists. Of course it’s great to keep track of your work but I have seen some problems with lists, especially product backlogs.

Communication is lost

When we write something down we get a relation to it and we all know, it’s hard to kill your darlings. It’s easier to read than talking to people so it’s a risk that people skip having a conversation as soon as there is a list instead of letting it be a conversation starter and/or summary. This is true for all documentation of course and in general lists are light weight so the risk is less but it exists. You can also have a list and attach documents to its item like requirement documents and well what else is the list then that a waterfallic(is that a word) requirement document?

An item on a list becomes a promise

When you add a user story or bug to a list most people take that as a promise but we all know that isn’t true. For how many times haven’t we reported a bug that still is not fixed but on a list somewhere?

The list become the goal

The biggest risk I see with lists is that they become the new goal. It’s so easy to measure if the list is empty or not and in the hunt for easy metrics we use the list as a measure of our success. When the list is empty we are done and the project is over. But wait, what happen when the customer add new stuffs to the backlog? Well we don’t get done and people get a little sad the project is going to take longer. This does not sound very agile to me. If we do this how can we embrace responding to change over following a plan when we are measured and rewarded on how well we follow the plan? The list have become the goal instead of the real goal that is lost somewhere. It’s the good old requirements document in a new outfit that is stopping us from create real value for our users which was the real goal. We must get rid of this requirements document once and for all but how shall we do that?

 

Solution

What is the right way, shall we forbid lists? Of course #NoLists. It’s an interesting thought. What if we had not invented lists, how would we do than other than plain text? Maybe images, examples, conversations or something else. I don’t have the answer but I am sure there are good alternatives to do this. But of course we have to live with lists since they are good but we maybe need to think a bit about when and how we use them. Below follow some guideline for how you can use your lists smarter.

Keep it short
If you have a list. Try keep it as short as possible to avoid the possible side effects about it. The development team need to limit their work in process but the backlog can be hundreds or thousands of items, is that really fair to the team or to the poor stakeholders who believe that some day it might be my turn or the PO who have to prioritize and administrate this big thing. This builds up trusts, enhance communication and make you open to new ideas and changes since you do now have to remove anything. It’s more fun to add things than remove them, right :)

What value will it bring?
What is the purpose of the list you are about to create? Is it a plan, a requirement documentation in disguise or something else to eliminate the need of interaction and conversation? Then you should probably not create the list. If it’s your personal list that only you need there is no danger, unless it prevents you from interaction with your colleagues and users. Will it make you less open to change and learn from the feedback during a project you should think twice before creating it and see if there is another way to do it.

Tell people what it mean that an item is on the list
Be clear to your stakeholders what it means putting an item to the list. Is i a promise of delivery or is it just you writing down a good idea for possible future use?

If it’s important you will remember it
I know it’s hard to accept but I have come to learn that if something is important it will be remembered. If we remove our backlogs I guarantee that a lot of stuffs will not be added again because that they we not important enough to be remembered and if they can’t remember it, will creating it really bring value?

 

Summary

I guess this is a summary of my lightning talk (“Curse of the lists“) that I held at the Swedish conference Agila Sverige 2014 and the following open x. Thanks everyone for your great ideas. I think there is much to explore in this area and like for the estimates. How can we get the value from the lists without using them or how do we avoid the downsides with them?

Read More

Hello world! It’s time for some Happy Change!

Since I am a developer I think that what better title for my first blogpost , than Hello world? Maybe not the best title but it was suggested by WordPress so since I am new to blogging I trust in them. Hello world is a little bit boring and since am also and agile coach I thing that I have to add something more to make it great.

Maybe you have some questions about why a developer have a pink blog with a name like happy change? It’s good that you ask. It’s pink because I like the color, even though I am a guy so it’s no more thought than that about it. The name has it origins from my training as a professional coach at CoachCompanion spring 2014. During the training people was talking about starting there own companies and I got inspired and started think about what I would call my company if I was about to start one of my own. The first suggestion was “It Depends”. I have come to both love and hate that statement but after a while I felt that no, this is not the right name and want something more inspiring, something that show my passion for change and having fun. After some time I came up with Happy Change. I want the name to represent my passion for changing things to the better and having fun and be happy in the meantime. I liked the name and bought the .se domain just in case since they very on sale and well you never, maybe I would start a small company some day to have along side with my current job. So now I just waited.

I attended to the agile conference Agila Sverige 2014 and meet a lot of interesting people and learned a lot. I even held a lightning talk and hosted an open x on day 2 which was really fun. The conference ended of course with and retrospective and we got the question what we should do different when we got back home. I thought for a while and decided to start this blog and use my domain for something. So on the train home I started looking for a good looking wordpress theme and mow, two days later I am writing this blog post. I don’t know where this will take my but I guess my English skills will improve at least. My goal is, by sharing my ideas and thoughts, helping people to live by the agile manifesto and changing their life to the better. The short version: helping people create Happy Change :) Another purpose of this blog is to create new connections with people so that me and them can learn and grow together.

Next blog post will be about my lightning speak and my thoughts on it and the following discussions. In the meantime you can watch my lightning talk here:

Agila Sverige 2014 – Listornas förbannelse

I love feedback so feel free to share it with me :)

Read More