Change the unchangeable

In an environment where so many people avoid decisions, shy away from responsibility and avoid asking hard questions, the people who do this well stand out.

Shake a few trees. Take a risk and raise a tough issue. What’s really stopping you? What are you afraid of?

Politics? Don’t want to make an enemy? The times in which trolls and power seekers can gain influence without creating and delivering are slowly but surely coming to an end. The Internet has relativised the playing field, and our creations and art speak for themselves.

Afraid that you’ll look silly or uninformed? If you raise your hand you will almost certainly be wrong from time to time. Maybe even often. But recovering from being wrong with grace and dignity and learning from your failures is far more valuable to you and those around you than sitting silently.

Do you believe it’s unchangeable? That the status quo is unquestionable and immutable? It’s not.

True, you want to pick the battles you can win. But pick one. Try it. Look around you, and pick one thing that has been bugging you but you have always considered unchangeable – then change it.

What’s getting in your way?

The daily scrum standup is about answering three very simple questions:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. Do you have any blockers?

All three questions are important, but you know what… this is another great case where the whole is greater than the sum of its parts. It’s the combination of all three that make the standup as effective as it can be. 

I often see the third question get dropped from standups. I think developers naturally want to downplay impediments… I think they want to feel that they can solve them, no big deal. But the thing about forcing developers to articulate the things that might get in their way is not only so the Scrum Master or Product Owner has the opportunity to comment or act on them… the act of talking about your blockers forces you to think about it actively, and quite often things will come up that the developers themselves weren’t really aware of. 

On top of that, undiscussed impediments are like little icebergs floating around in your sprint… icebergs with which you will most certainly collide on the afternoon before the sprint demo, when you have no time to respond in order to save the sprint. Keeping an up-to-date impediments log is the best way to avoid nasty surprises on sprint demo day.

What gets in your way?

Scrum is not a solution to your problems

Scrum won’t solve all your development problems. Even if you implement 100% of the Scrum textbook (and most companies don’t), it won’t fix a broken development environment overnight.

Scrum process just helps to bring your problems to the surface so you can see them and deal with them. It’s all about exposing problems and issues, so you can identify them and do something about them. Scrum process aims to ensure that problems can’t fester unnoticed – but are brought to the attention of the whole team very quickly.

  • Scrum roles force defined and logical team roles and work division. You know exactly what you expect from a Product Owner, and he knows what is expected of him. If someone on the team is not fulfilling their role, it’s easy to spot, allowing you to do something about it.
  • Scrum meetings ensure that the team meets and discusses the appropriate things at the appropriate time. If the specifications are incomplete, if the stories are unclear, if the product vision is not defined – you will know it in the Sprint Planning meeting when the team can’t accept any stories. 
  • Continuous integration ensure that your development environment runs smoothly and minimises downtime or team-blocking integration issues. If there are intrinsic problems in the architecture, if the code is too brittle or if there are skill deficiencies in the team, you will see it in the CI environment.
  • Sprint demos give the team a target for a sprint and an opportunity to regularly celebrate what has been achieved as a team. But… if there are problems in the development team, if there are skill deficiencies or if the team is being blocked or interrupted, you will see it quickly at the sprint demo with the amount and quality of the stories that were completed.
  • Regular releases allow you to respond to your customers and stakeholders faster, and fix bugs or problems quickly… but if the team is not quality-conscious from end-to-end, you will see it in the quality of the code that is released at the end of the sprint.
  • Sprint retrospectives give everyone a chance to look back and think about what went well and what can be done better. Issues and team blockers will be raised by the team, and problems that don’t get fixed will get special attention…

It’s all about making the problems visible. Scrum won’t solve the problems that you have – that’s your job. 

Why the Product Owner is not the Scrum Master

Despite what is often the case in software organisations, a Product Owner is not a Scrum Master. To me, the two roles are both absolutely critical to the success of a scrum team, but they are not only very different, but quite often contradictory.

The Scrum Master protects the team from interruptions and blockers and facilitates their working together both within the team and with other teams. The Product Owner sets the direction of the team and the vision of the product and defines and prioritises the backlog based on product needs and input from stakeholders. 

Mike Cohn describes it by drawing a comparison to a pirate ship: if you consider the ‘management’ tasks that need to be taken care of on board Blackbeard’s Queen Anne’s Revenge, there were two main types: Star tasks (risk-taking, planning and strategic), and Guardian tasks (protective, ‘crew’ support tasks). 

The team should see and know the difference…

You can read the full article here.

Shooting the messenger

Sometimes you have to choose between two or more bad options. Often the perfect choice is a luxury that you can’t afford.

The question is how you respond to this choice, and how you communicate it to your team. I believe you have two options:

  • You can act purely as a messenger, or
  • You can take responsibility and ownership of the decision, and explain to your team enough of the background to the decision that they understand and accept it.

It’s easy to go with option 1 – to throw up your hands and say “well it wasn’t my decision” – it’s always easier to be a victim – but option 1 is poisonous because it builds in your team an inherent distrust of management and a dissolves belief in your product strategy. And in the long run, if you always play ‘the messenger’, your team won’t only lose faith in your company, they’ll lose faith in you.

Option 2 is hard… but get it right, and it’s art. And sooner or later the messenger gets shot anyway.

Bienvenue!

Welcome to my blog. 

My name is Will. I grew up on the east coast of Australia, studied and started my career in Sydney, and 2 years ago I followed my girl and my heart to Berlin, Germany. I now work for Nokia. I am the Product Owner of Nokia’s web social location platform, maps.ovi.com

I thought the best way to start out would be to come up with something of a mission statement for this blog. Basically, I’d like to share:

  • my thoughts and experiences in the world of agile software and product development
  • my observations and thoughts on the web world in general
  • my thoughts on creating change and building products and systems of value

I must admit; my motives are selfish… I want to force myself to consolidate my thoughts. I want to give myself a deadline of one blog post per week (to start with) to make sure I take the time every week to reflect and to learn. 

Despite my selfish motives, I hope you find something valuable for you here, and I hope you find something to take away. 

Thanks for dropping by.

Cheers,
Will.

1 14 15 16