Image for post
Image for post

Ever tell a kid to do or not do something?

The chances are they replied with: Why?

It is a very potent question and the ramifications of “because I said so”, every adult understands.

We could exercise authority and make them do what we want them to. However, making clear the “why” paves the way for ownership and responsibility of the chores over time.

Not here to talk about parenting (Universe knows I could do with some help).

I have worked with teams at myriad levels of maturity on the process spectrum — ranging from everyone in the team understands the value add of following a process to everyone doing their own thing their own way.

The realization of potential in a process mature team is significant and my experience across the spectrum has only solidified the belief that these teams deliver faster, safer and together.

Let’s explore the below scenario:

You are embarking on a project with a new team and building out a Scrum process. Most of your team are not well versed with scrum.

Scenario 1:

You set up your project in JIRA, chalk out your epic and story templates, send meeting invites for all the scrum ceremonies and let the team know this is what we are going to do, and this is how we are going to execute it.

It is a team working for an organization, they will do what needs to be done.

The catch:

Stand ups will be confusing and long — you will need to interject every time.

JIRA stories will merely be place holders — The value of a JIRA story will be lost

The burndown chart will look like this — will not highlight if we are doing less or more — in fact it will be a useless chart

You will need to follow up mercilessly to get the right information in there. The stories will not depict the right features being delivered. The velocity will be indeterminable. Even if you do manage to nag the hell out of your team, they will begrudge you.

I have faced this first hand and I have learnt from my mistakes.

Scenario 2:

Once the team is set, you not only explain what Scrum is and how to do it. But you articulate the value proposition, why this process will enable the team to deliver. You take feedback. You incorporate the feedback.

The benefit:

Team will be on board. They will feel like a part of delivering and not just part of a feature being delivered.

The team will engage in the story creation.

The team will cheer their own velocity.

The team will find ways to automate and deliver faster and safer.

The team will eventually find the rhythm.

The team will build their own culture which will be sustainable.

The why will lay the foundation on which the process can be built and improvised to fit the needs of the team. Will you still have to follow up? Definitely. Will you face resistance? Absolutely.

But the team eventually gets there.

This applies to any process or change you bring to the table. Articulate the “Why” and you will have more people willing to give it a try.

There is a brilliant book by Simon Sinek “Start with Why” where he talks about the Golden circle, which can be applied in a team, in your home, anywhere for that matter.

No matter what you are trying to implement: moving to a DevOps model, incorporating Scrum or Lean or Kanban, or for that matter delivering a project — answering the “why” drives you and the team. It drives people.

I could digress into a philosophical tangent. Instead I will stop here.

Explain the Why!

Written by

Technology enthusiast | Book Lover | Curious

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store