By Simon Stewart 

I bought a book several years ago called It’s Your Ship by D. Michael Abrashoff (https://www.amazon.com/Its-Your-Ship-Management-Anniversary/dp/145552302X). It is a useful book on teams and collaboration, but what struck a chord with me was the pencilled inscription on the inside cover. It read: 

“Alan, I found this very interesting. If we ran our operations on these principals we would not have so many unhappy people. Stuart”.  

Operational problems within companies and the continual search for solutions is as common today as they have always been.

Trying to bring some agility into a corporate environment that has a decade or more of momentum in the opposite direction can be like trying to turn the Titanic around in the Vaal. The direction that many corporates go is to send several people on Scrum, SAFe or Agile training of some sort and use that to kick start their journey into agility and radical transformation – along with the help of an army of consultants. I’ve yet to see this result in anything more than a veneer of “agile-ness” and a return to the status quo within six to 12 months. This obviously doesn’t help anyone, nor does it solve the original problems. It just results in some combination of further reduced staff morale and an organisation pushing back against anymore “radical transformations” towards agility until a renewed cycle kicks in.  

So, what exactly is “Agile” and why are so many corporates and teams striving for it as a panacea to all their problems?

First off, here is a roundup of some of the general problems that teams face: 

·       Ability to adapt quickly to business pressures and changes

·       Consistent and predictable delivery

·       Good quality baked in from the start

·       Unified teams with the autonomy to get things done. 

The list goes on and while “Agile” typically means the ability to keep up with changes in the business, it tends to encompass a solution to a multitude of problems that have grown alongside many modern industries; software development being one them. Many of the more common definitions of what it means to be agile are linked to popular certification programmes, which limits the scope too much and overly simplifies the problem.

I feel that one of the reasons behind this is a lack of understanding of the fundamental tenants behind what agility actually means. The subtlety here is a distinct difference between “being agile” versus “doing Agile”. The analogy I've heard illustrate this further is the difference between “being fit” versus “doing fitness”. You become fit as a product of your actions. You can't “do it” explicitly. It takes continuous action. 

While there are as many definitions of “Agile” as there are consultants in this space, my suggestion is to go back to the work of W. Edwards Deming (1900 – 1993). He was one of the Americans involved in helping turn Japan around post World War II. Imagine turning around an entire country...

Many years after his work in Japan, when American companies desperately needed help from someone with his skills (ironically to compete with Japanese companies), he was still an unknown force within the United States even though he lived not far from the White House. After a documentary aired in 1980 highlighting his work in Japan (https://www.youtube.com/watch?v=vcG_Pmt_Ny4), he was acknowledged in his home country and began working with companies such as Ford Motor Company and others. This is a pattern I see play out in corporate environments too: How often has the solution been sitting quietly in a cubicle all that time, but never used? 

Back to Deming. Let’s summarise just a handful of what he popularised and see how this relates to the more recent wave of Agile-related practices:

1. Shewhart Cycle (Plan-Do-Study-Act) also known as the Deming Wheel (https://en.wikipedia.org/wiki/PDCA) 

Looks just like a Scrum iteration, doesn’t it? This is one of the most important aspects of trying to seek out and execute improvements, and ties in well with the Japanese concept of Kaizen or “change for the better”, also popularised as “continuous improvement”. Do a bit; check how the performance has been; adjust accordingly; repeat.

With P-D-S-A and Kaizen, the common mistake is seeking “constant change”. The intention should rather be to constantly find areas for improvement. The difference is subtle but it’s important because change for the sake of change doesn't lead anywhere.

2. Drive out fear

This is one of Deming’s 14 Points for Total Quality Management, and probably the most important and difficult one to achieve. Fear could be a fear of asking a simple question or fear of asking for help; or fear of being “caught” learning something during office hours. I’ve often seen all of these examples play out during consulting and they all point to a deep cultural issue within companies. A team operating without fear is often a high performing team.

3. Break down barriers between staff areas

We speak about removing silos during the same time that we encourage “squad” formation and micro-teams. This is a very difficult issue to solve until there is an understanding of the problem.

An autonomous team (which is typically made of developers, testers and business analysts) are almost always formed without involvement from the end customer. This is a fatal mistake as continuously delivering something that no one wants is the same as not delivering at all.

4. Institute a vigorous programme of education and retraining

I see this as being quite distinct from indoctrinating an acceptance of an "Agile roll out" programme with a company. Rather, it's ongoing micro-training initiatives to keep everyone up to speed and shifting the skills and team forward.

5. Eliminate numerical quotas

The “numerical quotas” problem plays out in many areas. One of which is in the well-known Scrum sprints where points are assigned to tasks. Typically, a team is judged on whether they achieved their target points or not, often without regard for what was actually achieved or whether the team's knowledge grew during the sprint.

While I understand the need for numbers, ill-conceived quotas are common. Here are some more examples:

• Number of tasks completed
• Number of bugs reported
• Number of lines of code written
• Who completed the most "story points" within the sprint?

These examples are very easy to measure and simple to track, but are generally useless in determining actual progress within a team and are too easy to game. When lines of code are tracked, it encourages verbose code patterns that bloat the work without adding real value.

When the number of bugs are tracked, it encourages arguments about whether something should be logged as a bug or not and who is singled out as the responsible party. When the number of unit tests are tracked, it encourages a multitude of low-value tests of simple functions.

6. Building quality in from the start

In the software development field, we're often guilty of adding tests last or thinking of security just before a large rollout. The ideal approach is to ensure quality is baked into whatever you do from day one. This could include involving testers early on in the process; getting input from security teams during the design phase and performance testing as part of the development cycle.

The pursuit of "being Agile" is not an easy one, but needs to start with a fundamental understanding of what this movement is all about. The answer does not lie in the certifications. The answers all sit in books and articles that pre-date these wall decorations. 

Here is a short list to get you started:

The article was the basis for the Scrum movement:

http://hbr.org/1986/01/the-new-new-product-development-game/

Robert Townsend's book Up The Organisation, written in 1980 and is as relevant today as it was 40 years ago.

The Deming Management Method, by Mary Walton

I'll end off with a quote from Yvon Chouinard, founder of the Patagonia company and author of the fantastic book Let My People Go Surfing:

“Maintaining a sense of urgency throughout a company is one of the most difficult challenges in business.”

Simon Stewart has been fortunate enough to spend the last 20+ years working in various technical roles in businesses ranging from two-person start-ups, to large multinationals in industries such as financial services, mining, healthcare and travel. Having spent many years working remotely, Simon believes that problems appearing within a project are more likely a people or process issue, and not a technology one.

In 2011, Simon started the JavaScript in South Africa Conference which allowed him to give back to the technology community by providing a platform for new speakers and companies to gain recognition.   

Simon has several industry certifications and is a self-taught polyglot programmer.