The Scrum Process Should Drive Out Fear

I was interviewing a candidate recently and the question was asked "When you don't have clear requirements from project stakeholders, what do you do?". The candidate provided an excellent example of a project he had worked on, whereby he had simply provided the stakeholders with the requirements that he was going to implement, based on the vagueness that they hold told him, and then asked for comment. He then went about working with his team, delivering and demonstrating the requirements as they were built. His reasoning was that stakeholders were not providing clear requirements because they feared making mistakes and feared that what they were attempting to do would result in failure. His process of defining and demonstrating requirements, as they were built, drove out the fear and provided a platform for the successful delivery of a product. A great response to a difficult situation and a great interview answer. One well worth remembering ;-)

This is exactly what the Scrum delivery process does. With the product owner sitting in the scrum delivery team they are able to see early in the product delivery process the difficulty, or not as it may be, to deliver certain use cases. If the scrum team, prioritised by the product owner, attempt to deliver, and demonstrate complex use cases first, then it is possible to determine if certain use cases are possible.

Alternatively it is possible to see if product complexity will be detriment to the product as a whole, i.e. by concentrating on complexity first to guarantee it is delivered might not leave enough time towards the end of a product release schedule to complete the product as a whole.

By demonstrating sprint deliveries every 2 or 4 weeks the scrum team, at the behest of the product owner can self correct and re-prioritise functionality to ensure successful delivery. This might entail demonstrating the complexity of a certain use case, resulting in the product owner rethinking and reworking a set of use cases with stakeholders. The critical thing is that fear is driven out of a project as early as possible:

• The 'northbound' stakeholders (management) get a clear indication of progress at regular intervals. they don't wait until the end of a 3-4 month software delivery cycle to get an outcome they don't want. They can see at regular time intervals progress and if issues arise, expectations can be reset. There should be less fear from management as they have a clearer indication of what can be achieved. They get this vision at a very early stage in the delivery cycle.
• The product owner can also see progress immediately as they are sitting with the delivery team, working on the hardest use cases first. This gives the ability for the product owner to assess the over all project commitment and assess at a very early stage the chance of delivery success. The product owner then has the data they need to set expectations.
• The Scrum team can drive out fear as working closely with the product owner they can assess what can be delivered at a very early stage in the software delivery cycle. This gives the power for the team to self correct and concentrate on delivering the core value of any given product in a specified time frame.

This is one of the key benefits of the Scrum process. As the team are empowered, or should be, to deliver a product that they have ownership of, they have the power to set what is achievable within a given time frame. This means, as long as 'northbound' stakeholder expectations can be managed, that the delivery team can drive out fear as they can commit to what is possible, as opposed to worrying about what is not possible.

It is worth the 'northbound' stakeholders while to work in this fashion as if they drive a team to deliver, what cannot be delivered there are two possible outcomes:

• The delivery team will simply burn out trying to achieve the impossible. On the odd occasion they may well actually deliver the impossible, but it's no way to maintain the long term health and prosperity of a team. Undoubtedly there will be a lot of recruitment after each project as teams break up with individuals moving on elsewhere.
• The delivery team will simply become demoralised. This is as they will feel that their concerns are simply being ignored. Again expect to have to manage a lot of recruitment during and after the project.

the difficulty on the product owners part is:

• knowing what is hard and
• knowing what is impossible. 

If the product owner knows this, then hopefully prioritising what is hard, at the beginning of the project can drive out the fear. If they prioritise the impossible, then a load of time is going to be wasted not delivering anything. More on this later! ;-)

Cheers

m