Why asking “why” is as important as being “agile”.
When I was young my next door neighbour used to have to put up with me constantly asking “why” he was doing stuff:
“Why are you doing that Jim?” - I’d enquire, as he mowed his lawn.
“Otherwise my garden will look untidy” – he’d reply.
“But why?” – would come my reply, to his frustration and amusement.
And the pattern continued. Too young to have heard of the five whys, I wasn’t performing any root cause analysis. This inquisitive behaviour was just my way of trying to make sense of the world.
So, when I first started getting paid to build software, I was working with some friends in the middle of the Dot Com boom, my innate behaviour led me to follow the same pattern. We were regularly asked to go and attend meetings to pitch for business, for people or organisations who “needed a website”. The meetings were with a range of potential clients, from individuals with a little money to international corporations. We were in the fortunate situation that meant we could ask “why?” and if we weren’t sattisfied with the response based on what we knew about our business, we would gracefully turn down the opportunity of work, much to the surprise of the potential client.
Asking “why” is healthy, it helps us to understand our environment and get the answers key to improvement and survival.
These days I work mostly with large organisations usually as part of an “agile transformation” or “digital transformation” where they’re employing coaches, trying to implement processes, patterns and practices to solve their respective problems and sending people on all manor of training to try to and improve software delivery, but in most cases they don’t connect the “doers” to the “why”!
In my experience, this habit is the one that hinders software delivery over and above everything else I’ve witnessed in the last eight years. What I do see often are companies paying lip service by appointing a “product owner” who checks stuff or companies creating mountains of Jira tickets, both in an attempt to be “agile” as if that’s a silver bullet to their software delivery problems.
There are plenty of articles across the web backing or damning “Agile” and frankly. I believe that the detail of isn’t too important and a process that supports the teams, and their individuals, in delivery will probably work - as long as you can count on good experience within a team, empowerment, autonomy and proving quality.
Empowerment, autonomy and proving quality
To truly connect the “why” to the doers, the doers need to be able to understand the problem space fully, question it and shape it. They need to be empowered, they need to be autonomous in the delivery so that they can act on the answers they find when they ask “why”. This doesn’t (often) mean teaching a team of developers about a fine grained problem and leaving them to it, it means putting the team in charge of the solution by making sure that everyone needed to deliver a successful solution is available, present and interested during delivery – technology and business people, whoever is needed to answer “why” – every day. Largely, the business of a lot of companies these days is technology, whatever their output or service offering – trying to keep this separate is almost futile. This is why the programmers, engineers and developers who are slowly transforming into poly-skilled individuals who understand their business domain are highly sought after.
Ultimately the answer to “why” can and should be used to judge success and to prove quality.
Without a healthy level of questioning “why” I think delivery teams struggle to prove quality to any significant degree, no level of CI, CD, or Devops practice is going to help if you don’t fully understand the real value of what we’re delivering and can steer it appropriately.
The Milgram experiment proved that instinctively humans are not pre-disposed to questioning authority and it’s this “blindly following instructions” that leads to the death marches we see a lot of. Organisations that require and promote layers of hierarchy with a top down prescribed model are actively discouraging curiosity, inquisitive behaviour and innovative behaviour.
Often some of the best innovation comes by accident, encouraging inquisitive behaviour and getting individuals to ask “why” should help breed innovation.
In my experience, putting team members in a flat structure, across the tech, business and operations efforts encourages the “team mentality” and the curiosity and innovation that’s needed to deliver quality based on business value. Furthermore creating feedback loops that are available to the team through empirical evidence, will give any delivery team the ability to answer the “why” accurately and in turn empower them.
So before you set off and “do Scrum” or setup a Kanban board or create your first Jira ticket, make sure your teams are enabled, empowered, autonomous and have a good amount of questions at the ready!