And just like that, we’re done with Day 3 of Agile 2018! I’m hoping that by now any readers are aware of the previous two posts about days 1 and 2, but if not...here they are:
The focus of the post today is going to be about how we interpret and use data. Don’t worry, this won’t involve any complex analytical theories or jargon (I have a degree in History after all) but will focus on what I have learnt today that can hopefully help you as much as I hope it will help me.
For those of you who have worked with me you probably know that I like to get my hands on whatever data I can. Having led two published research projects at AXELOS, I enjoy being able to find new insights from information available, building theories and conclusions off the back of that information.
My final point, as with yesterday, will diverge from the main topic. So, here are today’s ruminations:
- “Data is a people problem” - Keynote speaker Troy Magennis gave a great talk which challenged a number of preconceptions that exist in many organizations today. One of the main points he made was that data is a people problem. It might sound simple that how people interpret and use data has a huge impact on how that information is viewed. Take the example of a status report that is all green but in reality, the project or delivery team has huge concerns about progress. Is it the data’s fault, or actually how it has been portrayed? Data is incredibly valuable, but it must always be used in context and with conversation to understand what it is actually telling us. This links well to the point earlier in the week about Outputs vs. Outcomes. Data can show the team is doing a lot work or look busy, but what impact and benefit is that work driving? Data is important, but data combined with context is critical.
- Do we need bigger teams? - Troy also put forward a controversial argument in agile spaces, that he believes we need bigger teams. Something I have heard a number of times this week is for an organization to move towards a holistic agile approach they must remove dependencies between teams where possible. This has been supported by Troy’s work that has found every dependency between two teams doubles the chance that the work will be delayed. So why not combine the work of two teams who have a lot of dependencies between them? Even if this goes beyond our team size sweet spot (detailed in the Scrum guide as between 3 and 9), could this not actually make the work more efficient overall? And, more likely to achieve the right outcomes instead of simply the output of a single team?
- Who is your customer? - Strictly speaking this wasn’t from a session but instead from an interesting conversation. Without naming names it was put to me today that agile has it wrong when it comes to the customer. Ultimately the customer must be external to your organization, the ultimate entity who is paying for your product or service which generates revenue for the business. Otherwise focusing on the customer and their feedback in any other context fails, as you are not strictly serving the right customer. Put another way, if you are torn between pleasing your boss or the end customer, who would you pick? Who should you pick? I’m not looking to solve this in one short paragraph, but it is worth considering. I’ll finish on an example as food for thought. The history of Amazon’s coveted internal “Just Do It” award (I recommend Googling it if you haven’t heard of it) has it’s very roots in people who chose the latter option in the question a posed above.
Tomorrow will be my last day here in San Diego and I’ll endeavour to bring both my top thoughts from the sessions as well a quick overview of my top thoughts from the week. Until then!
Read other posts in this series
Agile Alliance - Day 1 recap
Agile Alliance - Day 2 recap
The last hurrah - final thoughts from Agile 2018