Retrospective: The End

People leave. Occasionally, this will be the SM. This retro is dealing with the handover to the next SM and acting as a exit interview for the SM.

The goal behind this is to give the new SM insight into how the team regard their process, what they need help with and most importantly what they want to keep. This was to give my new SM a good idea of what the teams buttons where so he would get off to a flying start with the team.

It also helped me see some improvements that I could carry with me to my next team. Some I knew about some I needed to acknowledge. SM's, like teams aim to continuously improve.

The icebreaker I used was a simple game where I wrote up some numbers and asked the team what they thought they correlated to. I went back to when this team formed and found totals for: Number of Sprints, Total number of stories, Total number of points, Longest Lead time and average velocity.

Then we did a happiness radar to give the overview of what the team think about 3 areas:

• People - the people they work with both in and out of the team
• Technology - the kit they work with on their local, development and integration environments
• Process - the way they work

I gave my team 2 votes each and they created this:

Thinking like my new SM, I would be thinking "Hmm, I wonder what's up with the technology?" and maybe "So, observe for a while since these guys think everything is working just fine".

The last section was just a post it session around some key questions:

• What should the SM leave alone?
• Is there something the new SM should look into straight away?
• What are our strengths?
• What does Richard do that our new SM should do too?

As usual, it's the little things that made me chuckle - biscuits, always a favorite:

When the SM arrived I went through what the team had said and gave them a rough history of the team so he had some context. Not only did I find this process quite therapeutic, I think it helped the team know that the next SM would help them continue on their chosen path rather than make them take a different route.

So, who is the customer exactly?

The term customer is often used in agile teams to represent who we are delivering value to.

The problem is that the larger the organisation, the more difficult it is to separate value in terms of things software teams can deliver and financial value placed on those things by the institution buying them.

In a previous role, my company sold software to the NHS. Part of my challenge was to connect developers with the value they were delivering. The challenge with this was the sheer number of people that were involved with the software, each of whom derived a different value from what we sold.

The NHS is split up into trusts, which are spread throughout the country. You don't sell to the NHS, you sell to a trust and each one is independent even though they all contribute to the same national charter for healthcare.

The trust itself could consist of multiple sites which offer services, each of which might have different requirements depending on the services they deliver. Each trust has it's own IT departments and generally a project team for a large deployment. The project team will be looking after how the solution is implemented. They will also have accountants looking after the financial aspects of the project.

The project team work across the different departments that will be impacted. During a tender they will consult with the heads of department and consultants that work in those departments. There are also doctors, nurses and other support staff who may be consulted.

As you can see there is a bit of chain forming and each level of this chain is looking for a different aspect of value from the delivered solution.

At the top you could say this is predominantly financial - how much the thing costs to implement, support and run. The project team are interested in the financials, but more so about what the solution does and how it fits in with their existing infrastructure. At the bottom you have the people who use it, who's concerns are solely with the software itself. They have no interest in how much it costs, just what it does.

For me, this does not still describe the true value of the systems the NHS use since the customer is actually the patient. They do not use the software but without them there is no point to the rest of it. Continuing one level further down the chain reveals a better way of understanding the value we deliver. In this example, everything should positively impact the care of the patient.

Indirectly, this could be reducing costs for the trust. Lower costs mean more funds for the care of patients, however the trust chooses to deliver it. Directly, it could be managing the information gathered by the hospital to provide the best care for the patient by the doctors, nurses and specialists who use the software.

In every system, there are multiple customers and the value they want from the system will vary. In each case, there is at least one core person or group who benefits - removing them, removes all value from the chain. Finding that person is key to understanding the true value of what is being delivered.