Recently a young engineer stopped me after a class I shared at a national conference and was asking questions. The context in this case was this:

• We were talking about the importance of having “dynamic” Sprint Reviews that engaged the organizations stakeholders and customers. How showing “working code” was important for the team to show progress towards their Sprint Goals and commitments.

• In this particular case, the client organization was delivering more API level software to their internal customers. They were being asked for system-level functionality in some communications equipment and would implement low-level code to meet the requests. They would expose the User Stories functionality via API calls.

• Their Scrum teams were struggling with the demo. Their customers were not that interested in attending each demo and it wasn’t that compelling to “show” an API without the code to leverage it. In fact, the customers were responsible for exercising the API deliverables, but this often happened weeks to even months after the API was delivered.

• So clearly the teams were struggling to connect-the-dots in their reviews to:
  • Their Definition of Done
  • Getting User Story sign-off with their (customer) users
  • Getting feedback on API solution viability
  • Gaining quality feedback
  • Gaining a sense of accomplishment or even momentum

My Response

If I say so myself my response (or the conversation that ensued) was novel for me. I’m not quite sure if it actually helped this young man, but let me share it with you:

I asked him to pretend that he didn’t get paid (receive a paycheck for the API work; all financial transactions were deferred) until:

1. The API was demonstrated and exercised by the customer/user
2. They were happy with the implementation – they verified that it met their needs by integrating and trying it out
3. The quality proposition (robustness) of the solution was confirmed
4. The customer actually “signed off” on the work (API delivery) and said the team was “Done”
5. After sign-off, with an appropriate waiting period ;-), then the team would be paid…

I asked him that if this were literally the case that they didn’t get PAID until sign-off, how would they change their practices, tactics, and behaviors within the team? Regardless of what agile methodology they were using—what would he and their teams change in their approach?

• Would they change their Definition of Done?
• Would they engage their clients differently?
• Would they change the Sprint Demo?
• Would they change the workflow?

I was purely wondering.

It was a thought experiment of sorts, where the pressure would be on the team (and their clients) to figure out creative ways to deliver and confirm value in their work. That instead of asking me if deferring sign-off was ok or pushing back on the difficulties associated with doing a demo, the organization would figure out a way to get paid.

I hoped the thought experiment would inspire him to be creative and try different approaches to gain feedback and acceptance.

Wrapping Up

Believe it or not, I hear this sort of thing all the time in my travels. Teams often struggle with getting their deliverables in a state where they can be effectively demonstrated and accepted. When it gets challenging, they always seem to be looking for permission to skip this step and I nearly always pushback on them.

However, this was the first time I used money or compensation as the driver. I like the model because it challenges our thinking of how long we’ll queue things up before presenting it to our clients? Clearly if we have a mortgage to pay we won’t wait months.

So how long will you wait? And how would you approach getting paid sooner?

Stay agile my friends,

Bob.