Another year of great learnings has passed. I am thankful for having the opportunity to gain lots of new insights and experiences. Most of the year was spent on designing and supporting an IT transformation focusing to deliver at speed with quality. This initiative allowed me to be exposed to a lot of different challenges and meet wonderful people.
Stepping into 2020 I thought of writing top 3 learnings which I want to take into the next year and work more on.
Everyone has the same amount of time in a day, then how some people / teams accomplish much more than others? There has been considerable research on the subject, I feel the common theme in most results is successful people / teams don’t waste effort.
From reading and working in scrum teams, a very core focus in agile ways of working is to focus only on ‘what’s important’. Further to decide what’s important, ask the customer who’s paying for the effort. This singular focus on what’s important, what’s needed to meet the objective is a key factor in success.
Over the holidays some family time was spent talking about achieving goals. I shared an observation that every person has the same 24 hours in a day. Also, every person while they are awake are doing something, working on something, watching something, talking or whatever, just doing ‘something’. To achieve your goals, don’t do ‘something’, do ‘THE thing’ instead of low priority items.
I often give the example of a magnet. All solids have atoms exerting force in some direction, but the net result of all force is neutral. In magnets, like other solids atoms are exerting force too, only difference is they align in one direction. Collective focus in a singular direction makes the difference.
The problem with people / teams, we don’t always have a prioritized list of activities to do to reach our objective. Without this ‘prioritized backlog’, we react instead of being proactive and end up working on what’s not important and waste time for which the users / business is not ready to pay for.
For additional reading on alignment of purpose, especially for scum teams, I’d recommend “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland.
Leadership is being Selfless
My philosophy for leadership has always been ‘leading by example’. In my quest to learn more about transformation, leadership kept coming up. Therefore, I turned to my favorite speaker on the subject: Simon Sinek.
From primitive times, leaders of the tribe were always given first choice of food and preferential treatment, and members of the tribe didn’t have a problem with that. That’s because they were getting something in return, the leader giving sacrifices which others were not ready to do. To protect from any external dangers and look after the tribe members.
The same unwritten rules still govern the modern world, but when leaders don’t give any protection in return, or don’t look after our interests, this unwritten contract is breached, that’s we have a problem. Leadership, by definition, is an act of being selfless and keeping the interests of the tribe / community / team ahead of your own personal interests.
In the capitalist world we live in, with extreme deprivation of moral code and ethics, it’s challenging to be truly selfless in a corporate environment. I feel we should at least try to be closest to this golden standard. One cannot be a true leader unless they have interests of others ahead of their own.
Additional reading: Leaders eat last by Simon Sinek.
DevOps – A mindset & a TON of enablers
I’ve always said the Agile manifesto had the core of DevOps in there, in theory DevOps does not suggest a new paradigm shift, it provides pointers around technology and tools to really become agile. Therefore, a big part of DevOps is the cultural mindset change.
A big part of that mindset change for me were the two points mentioned earlier, eliminate waste and leadership. To produce quickly, the whole team has to be single mindedly focused on one objective only and not waste time second or third priority items. Only then we can quickly move things from ‘work in progress’ to ‘done’.
Part of waste is teams waiting around for someone to take a decision and tell them what to do. Teams need to feel empowered, so they think for themselves, take decisions and make things happen. As they progress, they’ll learn and improve as they move along. This is where leadership comes in, if leaders selflessly try to make things easier for team members to do their job, they feel more empowered and motivated to go ahead.
With DevOps, things don’t just end with transformational talk, a lot of enablers need to be put in place to achieve this. Therefore,
DevOps is sexy – but not a piece of cake
Bare minimum to do it well, you need CI pipeline(s) with all hooks in place, code repos with proper branching / merging, spinning up of on-demand environments which are fit for purpose, a TON of automation running at different stages across the pipeline, mocks / stubs, test data creation / deletion, connectivity with other products where needed. So you see, doing all this is not sexy at all.
Oh, and lastly, if you expect DevOps is going to reduce your cost, in the long run it should yes, but for a year or two you’ll be spending 2X or 3X the amount to get all these enablers in place. It reduces cost by eliminating waste, reducing manual churn, people not working on low priority items (back to cultural change)
To sum this up, I wrote a short Poem a few weeks back:
Software over the wall ; results in a great fall.
Testers, developers and all ; will then not like management’s call.
Ship in collaboration, be quick and release small ; that’s a lesson for us all.
There were a lot of other things I experienced, these were the top 3. Looking forward to continue working on these in 2020 as well.
What was your top learning from 2019?
Yes, I am in line with what you said. But also DevOps proposes a Development Life Cycle that include an interest for software metrics. The only hic-up in this metrics is that the Agile derived metrics is a metrics of the Process. I would prefer it to be a metrics of the ‘value’ provided.
I trust that any Quality interested person would be happy to seek a resulting output be conform to the expectation.
Best regards, Bernard
Thank you for adding Bernard. Finding the right software metrics to measure is something I’ve been trying to research for years. The problem is as you said, most ones are based on ‘how closely are you following the process’, instead of telling ‘what value have you delivered’.
So far the only two I’ve got are 1. measure speed of delivery – how quickly you release 2. Number of bugs coming from the field. Both are easier said than done, but are the only two which can truly measure success