When searching for the terms ‘trust in Agile SDLC environments’, I found lots of articles on how to create better teams and relationships within the team. I did not find much on how to make people outside of the team (I.e. the stakeholders) trust that the team are delivering.
External trust in your team matters. A team’s performance must be visible and acknowledged, not just effective.
One of the common complaints about Agile Project Management is that it is too woolly – there are no hard deadlines. To the uninitiated, this could be seen as allowing the team to take it easy and not deliver as fast as they would if they were working in more traditional project management environments (i.e., personal deadlines mapped out in Gantt Charts).
I think the opposite is true (and maybe in another blog post I’ll explain why), but, in this blog, I want to describe how you can create trust that the team is delivering as fast as they can but also that they are delivering the right things at the right time.
To create trust in Agile Planning you need to follow these eight steps:
- Make the team predictable
- Make a plan
- Don’t over commit & have difficult conversations early
- Get Management buy in
- Show progress
- Change the plan
- Deliver and celebrate!
- Review the impact
1. Make the team predictable
This is the hardest sell to the management team. If you have a new team or one that doesn’t know its capacity in a quantifiable way, you have to spend time getting the team to this position – there is no short cut.
This will take at least three iterations (e.g. six weeks for two-week iterations). But in my experience, it will take a new team at least five iterations (10 weeks). In order to make yourself plausible in future conversations and timelines, you have to tell the stakeholders that they have to wait up to 12 weeks before you can give them a plan. If you crumble now and start giving delivery dates without this information you are likely to be over optimistic and miss delivery dates. I’m sure I don’t need to tell you that if you do this, your credibility will be lost.
To get to the team capacity (or team velocity) you need to start estimating all the work that they do in Story Points. (Again, this deserves a whole blog post on the subject but here are a few links for more detail: Scrum Alliance, Mountain Goat)
2. Make a plan
Once you know the team’s capacity you can create a plan. I suggest quarterly planning as this is long enough to justify the effort but short enough to ensure minimal amendments to the plan.
To make the plan, ask the product team to create a list of features required in the next three months. These can be described in one sentence or a short paragraph. The development team can then estimate the size of these items in T-shirt size – where the team can complete one large, or two mediums, or four smalls in a sprint. You can also use XL (takes two iterations for the whole team) or XS (eight items can be completed in an iteration). They should ask questions to the product team, but you should not spend too much time on each item otherwise the whole planning exercise will take too long.
I suggest that this process should take no longer than two hours.
Once the product team have the estimates, they can decide on items to work on in the next quarter.
3. Don’t over commit
At this point you need to put contingency in the plan – leave capacity for at least one extra iteration in the plan to account for –
- under estimation of tasks
- additional requirements on the features included in the plan not currently known by the product team (emergent requirements)
- some space for additional features that appear during the quarter
& have difficult conversations early
You might have some push back at this point either from the product team or the management team over how much your plan shows will be done in the quarter especially if they are used to being over-promised to. It is important to stand firm on the team estimates and don’t over commit. You need to have the difficult conversations now over how much work can be done, rather than accept everything and then disappoint everyone at the end.
The Product team need to make hard decisions now on what should and should not be attempted in the quarter. They don’t get the opportunity to do this if you make them happy by over promising now.
4. Get Management buy in
Once the list of features has been agreed on by the Product, Dev team and Scrum Master the list should be presented to the Management team.
You should review the plan with the management team. Each item should be explained as to why we are working on it – include the ROI, success criteria, customer value and any metrics which will be tracked.
If the management team agree we can continue.
5. Show progress
Show progress as often as you can to as many people as you can.
Report at least at the end of each iteration. Project the current velocity against the remaining work to make sure you can still deliver everything in time. I use burn up charts to do this.
Show progress as visually as you can. If you are co-located use a wall to pin up diagrams to show the work left to do and, more importantly, what has already been done. If you are a remote team use a tool such as Miro to do this but keep advertising it to make sure everyone sees it.
6. Change the plan
This is Agile, which means that we can and should change the plan when necessary! If we are running late ask the team to see if there is anything they can do to deliver the same features but for less effort. If not, then ask the product team to decide what items won’t be done.
Communicate this change and the reason for the change to everyone.
If there is new work to be done, then ask the product team to remove a similar sized item from the to-do list.
I run a bi-weekly change board to review all the new requests and decide whether they should be added to the quarter. There needs to be a high bar for things to qualify but we should also allow things to be added.
7. Deliver and celebrate!
At the end of the quarter you should have an official end of quarter review. Assess what got delivered, what didn’t, what extra was delivered and you should celebrate as a team and a company.
With one team I worked with, I would buy doughnuts if we delivered on time. I wouldn’t just buy doughnuts for the team but for the whole company (it was a small company). This meant when people outside of the team asked, “Why do we have doughnuts?” someone would answer that the team have completed a major milestone successfully. Nothing like advertising your success!
8. Review the impact
It is really important at some point to review what was delivered and compare it to what was expected at the beginning of the process. Did you achieve the expect ROI? Did the metrics change in the direction expected? by the amount expected? Ask the customers for feedback.
Present this to the stakeholders even if you didn’t get the results you hoped for. What did we learn? What are we going to do next?
Summary
If you follow the key steps above by confirming the plan with stakeholders, keeping them updated, delivering on time (even with scope changes), review the impact, and report back you’ll build the trust needed for your team and company to succeed.
Pragmatic Agile 