Decided to change a bit how i introduce myself to new employees. Going to share problems and challenges during first introduction days for #developers. Main question at the end: “Do you have ideas how to help me?” What do you think?
- Previous one was boring even for myself: history of the company, structure, process, bla bla…
- Want to share what we tried already recently and explain why certain things succeeded or failed
- Want to be on the same page
- Think that good people are inspired by problems and challenges
- Want to share my point of view
- Want to hear alternative solutions and ideas
- Don’t always have a chance to participate in an interview
Just started and instantly got a feedback. “Didn’t expect it’s going to be interesting…”. Hm.. so it should work…
Last post was covering Planning and Analysis. Before conclusion I want to cover two key areas from my point of view. It’s about process and level of responsibility.
In most definitions Scrum Master is the person who helps the team to achieve best results: this can involve removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint.
Unfortunately everybody focuses mainly on process and completely forgets about the real purpose of team – create value for the customer, build great product. The real value of Scrum Master is that he has other skills and knowledge that can help the team to do that.
Have you seen Football Coach that doesn’t care about the Trophy? It’s not even a discussion. It’s weird. Both the Coach and the Team have exactly the same target! Why do we have Scum Masters who only cares about the process than? Don’t forget – Scrum is only the tool. Are you the fool with the tool?
Team wins the game, but coach loses the game
What do you often see in organizations? It’s so easy to find whom we should blame, but not the Scrum Master: Developers, POs, Other teams, Culture, whole organization, stupid users…
p.s. full presentation is available here
I visited another great event organized by Estonian Agile community – http://agile.ee/. It was pretty much great event with interesting topics. Even though my notes are taken out from the context and include my thoughts also, I still think they might inspire you for new ideas and improvements in your company. I will continue with notes in further posts. Here we go with part 1:
- Options have value
- Options expire
- Never commit early unless you know Why! Commitment kills options
- Jumping from a cliff. At the very start it’s an option, afterwards it’s a commitment
- Booking.com monetize options. You get better price if you commit your arrival. If you want to have possibility to cancel the reservation – price is higher
- When you start doing something it’s a commitment
- Decision making: 1) everybody wants to be right 2) people are willing to be wrong rather be uncertain
- Total uncertainty can be “solved” by bounded uncertainty – e.g. let’s try something for one sprint, validate output and make decision afterwards
- What can we learn from lions? They sleep 20 hours a day and commit only to good options. They don’t rush and run around like insane. Why do we rush than?
- Decision making: hierarchy alienates people who make decisions from real action
- Staff liquidity: Give tasks to least able person (just above his possibilities). It will allow most skilled people to find time for teaching and solving critical situations! Counterintuitive, but it makes a lot of sense!
- Value stream mapping helps to eliminate waste. 2 biggest wastes in development: bugs and delays.
- Track queues that form in front of the constraint and gaps that form after the bottleneck
- Staff liquidity: self score the team to identify weak and strong spots of the team
- TOC: 1) specify the goal 2) find the constraint 3) prioritize “around” the constraint 4) move staff based on decisions above
- Specify the work and assign value to it. Manage work, not people
- Move people to work, not the work to the people
- Focus on flow of work, not people utilization
- If it’s a commitment – think how to make this an option
- Scrum is more about commitments, Kanban is more about options
If you find these ideas interesting i believe you can read more about it here – www.commitment-thebook.com
p.s. if you decide to share these notes, please use #agilesaturday hashtag as reference to this event