When things can get slow?

Posted on Leave a commentPosted in quick thoughts

When all decision making goes only via “Path I” _green_ people  a) become a bottleneck b) don’t know details, so either have to trust or c) start asking questions to understand by delaying things even more.

Is it possible to leverage the power of “Path II” and make things faster? Set expectations, provide success criteria, boundaries (time, $, KPIs), principles, identify potential lack of knowledge and start delegating. More control is needed at the start and less when you see that things are working out well.

Screenshot 2015-12-13 22.48.42

Organizational design – problems

Posted on Leave a commentPosted in management

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

Separated thinking

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

Decision making

  • 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

Agile Saturday X – Metrics

Posted on Leave a commentPosted in management

Continue sharing notes from Agile Estonia event – http://agile.ee/ Previous post about Staff Liquidity

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

Part 2: When and Why to Fire a Scrum Master? – Decision Making

Posted on Leave a commentPosted in management

As I mentioned in previous post main question is changing a bit – “What and Why to Fire a Football Coach?”

Would you fire a Football coach when he makes all the decisions for the team on the field? Why? The answer seems very obvious. If this happens – team loses opportunity to get better as they don’t learn by making own failures. All decisions are made by players during the game: tackle, shot on goal and etc… Of course principles and tactics are agreed before the game, but when the game starts a lot of things can change and a lot of things depend on players. What coach can do is to assist the team and make maximum 3 substitutions if things get out of control.

130525160147-champions-league-final-14-horizontal-gallerycoach

Main reason why it happens this way in football is the “system” itself. Rules don’t allow coach to run on the field and instruct everybody how things should be done. Unfortunately nothing prevents us from doing that in our daily routine. That’s why it’s so easy for “new” scrum master to fall into micro-management and “break” the sprint. And if such behaviour continues, probably even the team spirit can suffer in the long run.

What could be alternative of such “system”  in software development that prevents micro-management? I have such thoughts:

  • focus on providing as much information as possible, so team could make proper decisions
  • walk away 🙂

Could you help to come up with more ideas?

Next post on this topic: Part 3: When and Why to Fire a Scrum Master? – Planning and Analysis

p.s. presentation is available here. I will go through it in further posts.