Working agile means you need to be more disciplined, not less! Think it’s one of the main reasons why is it so difficult to implement Scrum in a team (not speaking about whole organization). Here are several aspects:
- Estimation and planning
- Iteration planning with clients
- Daily follow-up with a whole team
- Iterative reviews of results and further adjustments
- Team work
- Definition of Done: list of requirements that all team has to contribute to – qa and capacity testing, documentation, presentations, monitoring.
- Time boxes
- Team has to deliver best possible results in a limited time. Requires lot’s of focus and determination
- Team is seeking for improvements at the end of each iteration. Normally each two weeks!
- Results must be presented to clients or main stakeholders at the end of each iteration
p.s. Stumbled upon the same topic in InfoQ – The Importance of Discipline in Agile
Forget old company structure – it doesn’t support growth! By the way did you notice that clients, customers or users are never represented in organizational structure? It is like company exists for itself, but not for the clients…
Inspired by Niels Pflaeging ideas was writing some posts about what type of change we are introducing in my company. Any change is not an easy thing to do as different people need different arguments. Analogy with Scrum framework helps to explain these ideas to those practicing Scrum. I must say this comparison is so obvious that you get buy-in instantly.
But there are other people in the company. I found this article about product lines which basically is orientation towards value but has this smell of control and hierarchy. But even with control mindset and orientation towards value creation brings such benefits:
- Improved productivity by as much as 10x
- Increased quality by as much as 10x
- Decreased cost by as much as 60%
- Decreased labor needs by as much as 87%
- Decreased time to market (to field, to launch) by as much as 98%
- Ability to move into new markets in months, not years
Have no idea how precise are these numbers and how they were collected, but i think this can help to sell it to top management. What do you think?
p.s. posts that i mentioned above:
Was making presentation at http://agiledayriga.lv/ and after discussions with other speakers completely understood that we are on the right track. Here is my previous post that shares some problems from this theme. Brief description:
It’s very easy to become hierarchical and turn into a “bank” when software company is growing fast. Is there a way to avoid that? How to keep the focus on value creation? What about Value departments, not Functional departments?
Want to share ideas what we can learn from Scrum and apply in organisational design. Will share hypothesis how company could look like when everybody is focused on value creation.
- Frederick Taylor was right long time ago, but things changed…
- Things changed – stop using Scientific management
- Create Value departments, not functional departments
- Create Helping departments for unique expertise and knowledge which serve but not control
- Change overall mindset from Control to Serving
- Introduce more alternatives and competition
- Make it difficult to hire a manager
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
I was covering “Process and Responsibility” topics in my last post.
To finish my analogy with Football Coach i want to suggest three main aspects that will help you to distinguish great Scrum Master from mediocre one.
1. Process is more important than value
Process is only a tool that can help to achieve results. Great Scrum Master will experiment with various practices and approaches to find what fits best his team, which depends on team’s maturity, experience, mentality and etc. And what is more Great Scrum Master will always think about the value being created by the team.
2. Suggests decisions only, but provides no information
Great Scrum Master will work towards increasing the transparency and bring as much information as possible to the team, so they understand the problem and would be able to participate in the decision making. Great Scrum Master will make sure big picture is not lost and everybody knows what is important and why it’s important.
3. Maintains status quo
Great Scrum Master is always focused on improvements. Without challenging status quo nothing much can be achieved. You can’t win two tournaments in a row if you are not going to change tactics and strategy.
What is next?
Professional Football team has several coaches. This is another interesting discussion to have… But remember – Scrum Master is team member with different skills set. Good luck in finding a great Scrum Master and right balance between number of team members and number of “Scrum Masters”!
Presentation is available here