Archive

Standard work

What is Rigour?

February 7, 2024
Actionable Insights, Article, Capability development, Caring, Culture change, Engineering, Fellowship, Organisational effectiveness, Product development, Quintessence, Rightshifting, Self-organisation, Software development, Standard work, Teambuilding
Leave a comment

What is Rigour?

Rigour refers to the strict precision and accuracy with which work is executed in fields like software engineering and collaborative knowledge work (CKW). It entails adherence to standards and best practices for needed outcomes.

The Importance of Getting it Right

Attentive rigour matters because carelessness breeds mistakes. Flaws in logic or bugs in code stem from a lack of rigour. This introduces unwanted surprises, and failures down the line. Rigour is an attitude of mind that zeroes in on getting things right the first time Cf. Crosby, ZeeDee.

The Perils of Getting it Wrong

However, the quest for rigour can go awry when imposed hastily or mindlessly. Establishing rigorous frameworks like requirements analysis, peer review etc. does carry overhead. Teams can get so bogged down chasing perfection that creativity, productivity and morale suffer. Or so much time is spent eliminating small defects that bigger picture progress slows. Like most things, balance is warranted.

The Laissez-Faire Extreme

At the other end of the spectrum from rigour lies the laissez-faire attitude. This French phrase meaning “let it be” encapsulates a laid-back approach where participants have broad freedom to work in whatever manner they choose.

In software and knowledge work contexts, laissez-faire environments feature very few enforced policies, protocols, or mechanisms for ensuring quality. Creativity and unhindered workflow takes priority over rigour. Peer reviews, quality assurance, and documentation are optional. Teams self-organise organically without work standards.

This spontaneity can spark innovation but has pitfalls. Lack of rigour tacitly permits cut corners, gaps in logic, unfinished ideas and sloppy execution. With an easy-going approach, easily preventable flaws accumulate and undermine end results.

In applied contexts like commercial software development, laissez-faire practices practically guarantee shoddy work products riddled with defects. User needs demand rigour not as an obstacle, but as an enabler of excellence. Finding the right balance is key.

The absence of rigour embodied in laissez-faire philosophies may promote freedom. But the ensuing chaos leaves the fruits of hard work easily compromised. Some structure and rigour ultimately serves applied collaborative knowledge work better in the long run.

While cutting corners is not an option, forced rigour without context can mean marginal gains at disproportionate cost. Rigour must enable, not encumber, the pursuit of excellence. Teams that foster a culture where rigour flows from all participants, intrinsically and voluntarily, tend to find the sweet spot. Getting there requires clarity of purpose, patience, and care. Do that and rigour lifts the quality of collaborative knowledge work substantially over time.

What does rigour mean to you and your team?

The Secret Sauce Behind Exceptional Development Teams

March 17, 2023
Antimatter principle, Article, Software development, Standard work, Teambuilding
Leave a comment

The Secret Sauce Behind Exceptional Development Teams

💡Unleash your teams’ true potential by discovering the untapped secret to a thriving software and product development environment – it’s not about the tools or methodologies, but the way work works! Get ready to revolutionise your SOPs (standard operating procedures) and create extraordinary results.

➡Hey there! I wanted to have a little chat about a thought that’s been on my mind recently. You see, in the world of software and product development, we often find ourselves in a never-ending quest to improve our practices, methodologies, and technologies. While it’s important to strive for continuous improvement, I’ve come to realise that we might be missing the bigger picture. Here’s what I’m thinking: it’s pointless trying to improve software and product development practices before improving the way the work works more generally. Let me explain.

To put it simply, we can have the most cutting-edge technologies and methodologies, but if the overall work environment and culture aren’t conducive to innovation and growth, we’ll still face challenges and inefficiencies. Think about it: a healthy work culture that encourages collaboration, open communication, and mutual respect can create an environment where people feel empowered to share ideas and contribute to the development process.

Before we even consider adopting new tools and practices, we should focus on understanding and improving the foundation upon which our projects are built. This might involve examining our team dynamics, communication channels, decision-making processes, shared assumptions and beliefs, and the overall alignment of our teams with the organisation’s goals and values.

One way to start making improvements in the way work works is by fostering an atmosphere of trust, transparency, and attention to folks’ needs. This can create an environment where people feel comfortable sharing their opinions, admitting mistakes, and asking for help when needed. This, in turn, can lead to more effective problem-solving, innovation, and ultimately, better products.

Another aspect to consider is the work-life balance of team members. Ensuring that employees have enough time to recharge and avoid burnout is crucial for maintaining high levels of creativity, productivity, and engagement. By addressing issues like excessive workload, unrealistic deadlines, or lack of support, we can create a more balanced and healthier work environment.

So, let’s not get too caught up in the pursuit of the latest software and product development practices without first taking a step back and evaluating the broader context in which we operate. By focusing on improving the way work works more generally, we can lay the groundwork for lasting, meaningful improvements that will ultimately benefit not only our products but also the people who create them.

Software Development at Scale

June 13, 2021
Agile, Culture change, Flow, Innovation, Management, Organisational effectiveness, Product development, Software development, Standard work
Leave a comment

Software Development at Scale

Scaled Agile – or agility at scale – seems like a hot potato at the moment. Here’s a few
thoughts:

Scaled Agile? Don’t. Just don’t. For GOD’S sake don’t.

Agile even at a small scale doesn’t work and scaling something that doesn’t work just leads to an even bigger mess that doesn’t work. Take a look at SAFe if you don’t believe it. Or just listen to Ackoff:

“The righter we do the wrong thing, the wronger we become. When we make a mistake doing the wrong thing and correct it, we become wronger. When we make a mistake doing the right thing and correct it, we become righter. Therefore, it is better to do the right thing wrong than the wrong thing right.”

Mindset (Obvs.)

Mindset (a.k.a. culture, memeplex) over methods, tools, etc.. What an organisation, collectively, believes and assumes has far more impact on e.g. productivity, quality, etc. than any methods or tools. See: Organisational Psychotherapy, the Marshall Model, and my new book, “Memeology“.

The only thing of real importance that leaders do is to create and manage culture. 

~ Edgar Schein

The thing I have learned at IBM is that culture is everything. It took me to age fifty-five to figure that out.

~ Lou Gerstner, CEO, IBM

If you get the culture right, most of the other stuff will just take care of itself.

~Tony Hsieh, CEO, Zappos.com

And Schein also provides us with a definition for “the culture of an organisation”:

Culture is the deeper level of basic assumptions and beliefs that are shared by members of an organisation, that operate unconsciously and define in a basic ‘taken for granted’ fashion an organisation’s view of its self and its environment…

It’s a pattern of shared basic assumptions invented, discovered, or developed by a given group.

~ Edgar Schein

Flow Efficiency

Goldratt wrote the book on Flow Efficiency (see “The Goal”, in case you’re interested).

Flow efficiency is miles better than resource efficiency (a.k.a. utilisation). What is flow efficiency? I’m sure you can look it up. But for the lazy: Flow efficiency suggest a focus on keeping work moving through its various value-adding steps, with minimal or zero queues and wait times, thereby attending to folks’ needs (value to the Folks That Matter) – and prompting feedback – as quickly as possible.

Formalise Innovation

Formalise innovation, evolve into continuous organisational transformation.

What do I mean by “innovation”?
In the context of organisations, here are a few possible definitions of “innovation”:

  •  A process by which a method, a product, or a service is renewed and refreshed by applying new ideas or introducing new techniques to create new value.
  • Turning an idea into a solution that adds value from the perspective of the folks that matter
  • A new strategy (means) for attending to the needs of the folks that matter.
  • The application of ideas that are novel and useful.
  • Staying relevant – keeping pace with changes to the (business) environment.
  • The implementation of something new – until it’s implemented it’s just an idea.
  • Stop talking about innovation. Focus on organisational transformation.

Here’s my preferred definition:

Innovation: Delivering against an idea which meets a specific set of needs, for all the Folks That Matter.

And “formalise”? What the hell does that mean, exactly? In effect, institute trainings, standard work, measures, etc., around the whole innovation (and, a.s.a.p., organisational transformation) piece.

I’ve been brief here to avoid a rant. Do get in touch if you’d like me to elaborate on some of these themes.

– Bob

Standard Work and Collaboration

February 27, 2019
Engineering, Product development, Software development, Standard work
1 Comment

Standard Work and Collaboration

[Tl;Dr: Ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.]

Standard Work

Standard work (also known as Standardized Work) is an operational definition of how the work works today. Best written and maintained (studied, updated) by the folks actually doing the work. Toyota defines Standard Work as ”the steps one needs to walk in order to complete a process”. Mike Rother defines Standard Work as the “Target Condition” in the Improvement Kata. This seems to me to make some sense.

“There is something called standard work, but standards should be changed constantly.”

~ Taiichi Ohno, Workplace Management

5W+1H

In slightly more detail: “Standardized work answers the 5W+1H of a process – the who, what, when, where, why, and how. Who operates the process, and how many people does it take? What does the final product look like, what are the quality check points, what are the tools required to complete the job? When is a part completed and ready for the next step (how long should the cycle time and takt time be)? Where is this process completed and what does this location look like (standardized work cell, point of use storage of tools, etc)? Why is this step necessary or value-adding, or why is this a quality check point?”

“When there is no standard [work], there is no Kaizen (continual improvement).”

~ Taiichi Ohno

In other words, when a process is performed unsystematically in different ways, then:

  1. There can be no basis for comparison (before/after)
  2. One cannot objectively tell if there was a difference or change
  3. No improvement is possible in regards to Time, Quality, Quantity, Cost, etc.

Collaboration is Waste

So, where does collaboration come into the picture? If the standard work specifies “collaborate here” (with 5W+1H or an operation definition for the collaboration) for a particular step, then all is fine and dandy.

But often, in software development particularly, there is no standard work, or the standard work lacks the detail which might suggest the 5W+1H of the collaboration. Exceptions which come to mind are: the daily standup (Scrum), sprint planning (Scrum) and sprint retrospectives (Scrum) (i.e. the various Scrum ceremonies – for which teams rapidly find their own work standards or de facto operational definitions).

Consequently, collaboration in software development is most often ad-hoc. Someone might run into a problem or challenge, and ask a colleague e.g. “Hey, can you help me with this?” or “Can we pair on this for half an hour?” or “Let’s get together and figure out what to do here”.

If we had clearly defined standard work, the specifics of what to do and who to call on when a problem arises would already be defined. Without such standard work, the coordination (set-up, figuring-out) of the necessary collaboration is waste, and interrupts the flow (both of value, and in the Mihaly Csikszentmihalyi sense of the word).

Do I hear you rail against this idea? Do you believe it’s impossible to foresee where and when collaboration might be necessary? Do you enjoy collaborating so much that you’re prepared to dismiss its negatives? May I put it to you that in such circumstances, you don’t actually know what y’all are doing? That you have little or no clear idea how to get from the start of sprint (or longer term) to the end, to the delivery of value? That you’re making much of it (“the way the work works”) up as y’all go along?

“…this model of ‘standards’ as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what ‘continuous improvement’ really means.”

~ Mark Rosenthal

The Bottom Line

This may all seem rather esoteric. How much can it matter whether collaboration costs us a few dollars or hours? For me, ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.

Does it matter? I leave that to y’all to decide.

– Bob

Further Reading

What Is Standardized Work (And What Is It Not)? ~ LeanBlitz article
Mike Rother: Time to Retire the Wedge ~ Mark Rosenthal