William Gill

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. 

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.

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.

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.