Do you understand WHY?
In a time of fast-changing technology and constantly changing ways of working, it often feels like we don’t take the time to stop and ask “why are we doing this?” A while ago I saw the TED talk from Simon Sinek about how great leaders inspire action. In the talk he introduces the golden circle, explaining the different perspectives WHY, WHAT, HOW – and how we should always communicate starting with WHY.
Getting introduced to his golden circle got me thinking; maybe some of the challenges we see in agile transformations could be prevented if we used that mindset?
We are so good at defining processes, describing swim lanes, creating templates, etc. We train people in the method – the mechanics, but very often I think we forget to explain why. Do you know why your company is in the middle of an agile transformation? Has anyone explained to you why that journey was started, what value it will bring? have you read, and do you understand the 12 principles behind the agile manifesto?
If we don’t understand the WHY, how can we then be good at the how and the what? A couple of examples;
I see companies that don’t prioritize the continuous or at least the early focus on quality within their projects – on building quality in. Why do I want them to focus more on that?
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is the first of the agile principles. How can you create early and continuous delivery of valuable software if you don’t have the focus on ensuring that you are building the right thing… and building it right? How can you have that focus if you don’t’ get your foundation right? The user stories and acceptance criteria? How can you have a continuous focus on this if testing is something you do as a “finishing touch” done by the business?
Or another aspect; how can you have focus on value if the product owners choose to define the user stories and acceptance criteria deciding the what and how, rather than explaining the value needed? The user story is a placeholder for a conversation – a conversation between PO and team, and the acceptance criteria is the input to the confirmation of whether we have created what the PO need. It is not a specification of what to create in detail, it is not the design.
Working software is the primary measure of progress.
Another of the agile principles. How do you know if your software is working? you do that by executing the software – by testing it – using it. Whether this is manual or automatic is another discussion, but you cannot say that your user story or feature is “done” if you haven’t tried using it, focusing on both whether it works or not and whether it fulfills the needs of the users. Unit test, system test, acceptance test is still relevant in agile, just not as a phase but as a continuous activity across the lifecycle.
And examples could be given for all 12 principles I’m afraid – but I hope you get the point from these two.
I wish we could start all transformation journeys with a discussion based on the golden circle, getting an understanding of:
- Why do we want to do this?
- Why have we chosen approach X?
- Why can this support our business?
- How does this support our vision and strategy for the organization?
- How do we communicate the answer to the WHYs to the organization?
- How do we ensure that our employees see the value and see their part in the transformation
Do you know why your company is in the middle of an agile transformation?
About Sogeti Labs
SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.
For somebody relatively new to agile methodology, and currently working on a transformation project, this was a very interesting article. Thank you.