As everyone knows, a key success factor of an agile process implementation, specifically Scrum, is establishing trust between the team delivering and those waiting on the delivery (basically between the product development team and the business). In order to establish trust, a development team should be meeting their commitments made during the planning meetings; thus, delivering what they said they would. Sounds like a pretty simple formula and for the most part — it is.
Never trust the teller. Trust the tale.
– DH Lawrence
Outside of simply delivering what you said you would in a sprint, here are five ideas to establish trust:
- Always act with integrity. It goes without saying, truth sets you free. But what is more than simply being honest while communicating with someone, but it is more important to perform your job duties with integrity. This means, no cutting corners, maintain the utmost quality, and always keeping the team informed when it comes to matters that may impact the core deliveries.
- Ask questions and share information. Make sure that if an idea is not understood, be sure to not be afraid to ask a question (sometimes, the first thing that comes out the mouth is “I don’t know”). Be sure not to assume you are all-knowing about an issue, so share what you know — this is an excellent way to facilitate conversation and potentially discover what you don’t know.
- Reasonably accurate expectations (estimates to complete). In the agile world, estimation can be challenging. This is primarily due to the lack of data present at the beginning of tasks. The easy way to overcome this and become more accurate with your estimation is to be sure to break down stories into common development tasks. This may include an analysis, design, build out, unit test, etc type task. I also like the proto-type, stub, or even the sub-functional task where a small piece of functionality is implemented. Estimates generally get better the smaller the task and they are of course better when more than one person sets the estimate (leveraging the experiences of others will help). Finally, always accurately update estimates to complete daily.
- Deliver within the boundries of the commitment. Simply stated, don’t always try to be a hero and deliver beyond the expectations of the original commitment. This can be viewed by management (be it product or development) as sand bagging estimates, or simply going rogue and “doing as you want to”. Not to say that finding a great way to do something that was much more productive is not a good thing or seeing that you can do a lot more within the context of the product functional area is not appreciated. But the right way to handle this is to disclose that you found a faster way to do something and your estimate-to-complete is much less than orginally anticipated, so you would like to work on another key capability that is similar to the functionality being implemented. Negotiating this within the context of the daily standup (and possibly within a follow up meeting) would be the correct course of action.
- Consistency is key. Having one good sprint is not enough, a team needs to establish a trend of delivering on sprint tasks on a consistent basis. This applies to the team as well as the individual. Once a team is able to demonstrate a consistent trend surrounding capacity, story points delivered, hours worked, etc — the product stakeholders can start to reasonably expect that what the team says they will finish will in fact be delivered.
Remember the idea of trust should also exist within the scrum team and between scrum teams where there is a need to share deliverables or even if you all work within the same development organization. The five ideas above should be applicable to ensuring that all scrum teams work well together and within the overall scope of an organization.
What techniques or ideas do you have about how to build trust with the product management or project stakeholders? What have you’ve done that works?