Month: October 2010

A half product is better than a half-arsed product

Posted on by will

Most software projects have a deadline of some kind, and only the very lucky few don’t have a budget. In this landscape that leaves two things you can compromise on: features, or quality.

The temptation is always there to try for as many features as you can. Rush to cram them in. Squeeze, push. Race to the finish line, push it out. 

The problem is that when you’re rushing, when you’re cramming, other things tend to get dropped. Unit tests don’t get included. The testing team get new features to test on the last day before release, and can’t really test it completely before it’s released. Defects that would normally be fixed are deprioritised due to time. 

Sound familiar? It does to me – I see it every day.

Why do we always let ourselves try to do everything?  Instead, why don’t we try thinking about our feature set? Chances are we can survive with a smaller feature set. 

Design what can be realistically achieved to the best level of quality in the time you have available. It’s better to launch a half-product, than a half-arsed product. 

The danger of cc and reply-all

Posted on by will

I got an email the other day, adressed to me with a mailing list of all the other Product Managers from our site in cc, that started with the words: “Actually, that’s completely wrong.” It was referring to my previous mail to a small group where I had made a comment about the readiness of a particular component to be integrated. It wasn’t just the arrogant, schadenfroh tone that irked me, but the sudden inclusion of the complete mailing list in cc. “Hey look, everyone, he was wrong!”

When you put people in cc on an email, you are making a statement. Always. The cc list can completely change the meaning and intent of an email… Who you include is often almost as important as what you say. So please be careful…

If you write to a colleague to give not-so positive or negative feedback, and you put their manager in cc, it is an escalation. If you don’t put their manager in cc, it is colleague-to-colleague feedback which has a much lower chance of provoking a defensive reaction.

If you write to a colleague to give positive feedback and you put their manager in cc, it can often increase the weight or worth of the feedback significantly.

When you answer an email with a reply all, especialy when you want to critisise or disagree with a point of view, etc, including everyone is a a statement that you want everyone to know that you disagree. This can sometimes be constructive, but if you intend to attack an idea or point out how someone was wrong, it can quickly look immature and cheap. 

Replying all to point out someone’s failure or weakness is like when you used to run to mum and dad as a child to tell on your sister whe she did something she wasn’t supposed to. It might feel satisfying for a minute, but at the end of the day you will end up looking like a child.

Recurring impediments

Posted on by will

Last week I wrote about impediments, and making sure you go through them every day at the daily scrum standup. As I was discussing blockers with my team over the past week I noticed (again) that most of these impediments are recurring… they seem to crop up nearly every sprint.

Scrum teaches us about the impediments log, which you keep during a sprint to track the burndown of impediments. Even more interesting, I think, is to track a history of your impediments over time. Which ones turn up often? Which ones seem to cause the most interruption/downtime? What common themes are there?

This information becomes perfect input for retrospectives or general continuous improvement, and you can easily see the issues that are the most problematic or recurrent, and tackle them first.

Change the unchangeable

Posted on by will

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?

Posted on by will

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

Posted on by will

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

Posted on by will

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

Posted on by will

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!

Posted on by will

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.