You do something valuable if your clients perceive following:
- A problem of theirs is solved or minimized
- An opportunity they desire is seized, maximized or enabled
- That they are happy
What (if any) is missing in such description? POD_framework_0.3 updated.
I want to share my view on what problems are created by functional departments and hierarchical structure. Only organizing your company around value can solve these problems. But for that you need to have a bit different view on things and another level of transparency. Every team must know how they “earn money” (in quotes because it might mean different things in different companies). Don’t you think that we use Scrum to solve exactly the same problems?
There are couple problem areas around this topic
- Developers is responsible for non-functional requirements: response, multi-language, hardware
- Product people are responsible for business only decisions
- But real business decision consists of both things and you can find right balance without having information from both worlds. The only answer to this is cross-functional teams with different expertise. Like startups!
Functional departments make it difficult to focus on value creation for clients
- For example IT team. They understand that there are 40 servers, but it’s not always to map this to value creation and prioritize this properly. Especially when you have lots of teams. Basically it is not obvious that there might be serious impact for business if hardware purchase is late for couple of days. KPIs are often introduced to control the process, which leads to other problems like gaming metrics and etc.
- Similar problems occur with billing departments who monitors e.g. travel costs between offices. If to analyze single expenses number it might look high, but you must understand there is a business decision behind each travel.
- Functional departments with unique knowledge must change their thinking from control to self-service and information sharing. To challenge that even more, same services could be bought outside the company if they are of better quality.
- It’s very easy to end up in a situation that you are doing something because someone told you. Team does things not because the boss comes and tells what to do, but because you know the market and want to achieve something interesting
- When you know what value is created by your team and you know how you “earn money”/”create value” this question doesn’t occur at all. You just do what is necessary and when it’s necessary. You know that you won’t be able to survive if not doing valuable things
It seems that organization that is built around value fosters
- Right behavior
- Desire to achieve results faster
- Increase of transparency and information sharing: e.g. I try to share as much info as I understand my self – cost index, expenses and etc.
- Understanding that you know and want to bring value, but not just do some stuff
- Destruction of comfort zone. I had a post about comfort zone here.
Will be giving speech about this topic during Agile Day Riga
Continue sharing notes from Agile Estonia event – http://agile.ee/ Previous post about Staff Liquidity
- Lagging metrics – the ones you can’t affect [e.g. weight]
- Leading metrics – the ones you can affect [e.g. what food you take]
- The best way to influence the team is to visualize the data
- Avoid vanity metrics. Use AARRR metrics: Acquisition of customer; Activation – are the active? Retention; Reference; Revenue
- Don’t use metrics as target
- Make sure everybody understands what is behind this data and how it’s gathered
- Use balanced set of metrics, e.g. Revenue, Ability to do more work, Happiness of employees, Happy customers
- Keep in mind the cost of metrics gathering. Will you be able to make decisions based on that?
- Metrics expire!
Last part is going to be about improving the whole value chain. It was very interesting keynote by Mattias Skarin.
When someone tries to start using Scrum inevitably there are a lot of discussions about definition of done. You will hear a lot of things starting from design documents and ending with unit tests. But it becomes very obvious what must be included into definition of done when you imagine something not related with software.
Imagine a situation that you decided to paint you room with a new color. Since you are not able to do this by yourself (it might not be a case in your situationJ) you are going to hire external specialists. So, these specialists return to you in two weeks with following output:
- Elegant design of the room
- Report how they planned to paint the room
- Analysis of different colors
- Half painted room with low quality
- Tools scattered around
Are you going to be happy as a customer? Is this what you want? So, when you are going to have a discussion about definition of done, please take real value into account first and don’t forget the quality.
p.s. despite the common sense discussions about definition of done are always quite difficult and it is not so easy to come to a common agreement.