Tag Archives: Quality

“Documentation” is a Dirty Word

I just skimmed through another 20 page planning document, written in old-school “requirements specification”-ese with a hefty dose of ambiguity. You know, things like “the Project Manager shall…” and “the technical team will respond to bugs.”

There’s a lot of good content in there. It’s not easy to get at, though… for each page I want to understand, I can expect to spend between ten minutes and an hour deciphering what’s going on. (That’s half a week of work, and I have a lot of other work to do this week. Is it even worth it?)

Also, this document is boring… and there’s a lot of filler (like “package X is useful, flexible, and open source” – OK, that’s great, and factually correct, but not very informative).

The whole document could have been condensed into 4 or 5 slides of diagrams plus annotations. If that had happened, I’d be looking at a 10 to 30 minute commitment overall to get my brain into this particular company’s context… and then I’d be able to make some useful contributions. (As it stands, I’m weighing whether it’s worth my time to go spelunking in that 20-pager at all. Probably not.)

Unfortunately:

  • The bulk of technical documentation that I read is unintelligible or lacks sufficient meaning. I have three decades of exposure to this stuff, so if I can’t understand it, I feel super sorry for the early career people (who might think they can’t understand it because they don’t know enough).
  • Nearly all of the technical documents I see are uninteresting. And tech is interesting.

99 times out of 100, technical documentation is dull and dysfunctional. While it’s supposed to help people and teams establish a shared understanding of a system or a process or a concept, it just ends up looking really impressive and convincing you that the authors know a lot more about this than you do. It doesn’t help you much, if at all.

And as a CTO, CIO, or VP of Engineering, I don’t want to pay for crappy documentation. This particular document probably cost me between $32K-50K, and that’s just the tip of the iceberg… because it doesn’t account for the incremental costs of the people who will attempt to decipher it – which could be 10-100x more over the lifetime of that document. Although the person or team that wrote the 20-pager probably knows what’s going on (at least a little bit), the artifact itself is going to cost other people time and take them away from more value-adding tasks.

The sheer volume of information we’re required to wade through to gain understanding – without the assurance that it will lead us in the right direction, or even in any direction at all – is probably what’s led to the disease of devaluing documentation

A lot of managers think documentation isn’t value-adding, and shouldn’t be done, because… in most cases, people do it so badly that it wasn’t worth the investment in the first place.

Dear tech workers: can we fix this, please? I know it will take a whole generation to effect meaningful change, but… I’m ready to roll up my sleeves.

Scrum and the Illusion of Progress

Agile is everywhere. Sprints are everywhere. Freshly trained Scrum practitioners and established devotees in the guise of Scrum Masters beat the drum of backlog grooming sessions and planning poker and demos and retros. 

They are very busy, and provide the blissful illusion of progress.

(Full disclosure: I am a Sprint Grinch, and my heart will not grow three sizes, or even one… on any day.)

Despite the mirage of progress, the people on the front lines doing the engineering work feel little relief from the ill logic and misplaced pressure of the pointy haired bosses. The managers aren’t getting the deliverables faster (like they convinced themselves they would). There are tons of charts and graphs that tell us how we’re doing (like burndowns) but now the CFO is using them to whip our horses just a little bit harder, trying to get them to go faster. They’re not going fast enough. (Spoiler: They will never go fast enough.)

And isn’t that what Agile is supposed to do… speed things up? NO!

Once upon a time, we used to build software like we built skyscrapers: plan every single task, put in on a Gantt chart, and make sure there are approval gates between every phase of work: elicit requirements, design the systems, write code, test it, deploy it, maintain it.

But a couple of big, bad things tended to happen over and over: 

  • By the time we got to “test and deploy” we’d discover that the thing we built was not what the users and stakeholders actually needed. (“But it’s exactly what you asked for in the requirements,” we’d say, “and you approved it at multiple decision points.” “Sure,” they would say, “but we learned a lot in the meantime, and things are different now. You just built us what we thought we needed six months ago.”)
  • The software developers would build something that the operations team, responsible for standing it up and maintaining it, wouldn’t be able to support at the intended service levels. (“You can’t expect us to maintain this,” they’d say. “It’s fragile.”)

Agile practices emerged more than two decades ago when engineers said… hold it, there’s got to be a better way. If we work collaboratively with our users and stakeholders, learning together, figuring out how to realize value together… then we’ll produce something that real people are able to get value from much faster. We need control over our process, and we need you to be actively engaged, business people. We can eliminate all these handoffs, and replace them with shared accountability.

The two solutions were: 

  • Agile: We said “let’s take a more collaborative approach to development, and get the users and stakeholders together with the engineers, so they can all learn and co-create together until they’ve produced the next nugget of value.” 
  • DevOps: Instead of two groups siloed from each other, let’s automate the handoff and make it seamless, and give the developers tools that will alert them when they’ve got to fix more stuff. If tests automatically run before the code is merged into production, we’ll always know that we’re deploying stuff that runs. (I’m pretty sure everyone agreed this was a good idea.)

Agile is a great aspiration. But how often have you ever seen the users and stakeholders sharing space, sharing accountability, sharing the process of creating value? Not often. They still coordinate through user stories, and tickets, and handoffs, and PRs. 

Agile speeds up value delivery, but not necessarily software delivery. Having daily stand-ups and burndown charts and JIRA tickets won’t make people code faster. But it will make managers think they should be coding faster, and that’s where the poison will settle in and grow.

Bottom line, my position statement is:

  1. Any (minimalist) process is better than no process.
  2. Agility is an essential goal, but Scrum and certified Agile practitioners are less likely to get you there.
  3. Go back to first principles: plan an iteration, co-create value, see where it got you and reassess your ability to reach your goal, then adjust. Keep experimenting.

Would I ever use Scrum? Sure, under specific conditions:

  • There’s something we have to build, and we’ve never built it before.
  • The road ahead is unknown.
  • We have access to collaborators who can help us see what’s needed.
  • We agree to intentional checkpoints where we can see how far we got, and whether we can still get to the place we’d originally intended.
  • We iterate, and iterate, until we agree we’ve incrementally added enough total value nuggets to move to the next project.
  • There are no well-meaning-but-not-helpful engineering managers or business managers hovering over the development team with bated breath, waiting to beat us with burndowns. The dev team can manage itself.

Agility is a laudable – and essential – goal. But only in rare cases do I believe Agile and Scrum will get you there.

Why Software Estimation is (Often) Useless

For 12 years, I blogged and wrote a whole bunch. For the past year and a half, I’ve let myself be pulled away from so many of the things that make me me… including writing. Today I heard one of the best anecdotes ever, and it’s the spark that will be pulling me back in. (Thanks, John.)

So here it is! It has to do with software estimation. Not only is it difficult to accurately estimate how long it’s going to take someone to do a programming (or similarly technical) task, the act of estimating often does not add any value at all. Estimation is a bad thing, especially if you’re trying to be Agile.

(And if you’re in a client/contractor relationship, you’ll have discovered that estimates are the lifeblood of the relationship, even as they drain all the life and all the blood out of the relationship, slowly and deliberately.)

Sometimes I get caught asking engineers for estimates even when the task we’re embarking on is new, unknown, uncertain, and requiring lots of learning and exploration and discovery. I should know better. But I cave, because the concept of the software estimate is so enticing: with a good estimate, I’ll know exactly how much time someone will need to spend working on a task that’s still kind of nebulous and mostly unknown. (That was a joke.)

My friend John shared the best anecdote ever today about why software estimation is so frustrating (liberally embellished):

Imagine that you’re standing on a hill looking down at a labyrinth, or a corn maze. It’s reasonably small… you can see that the corn maze is definitely doable, you can see a couple paths in and out, and the entire maze is a similar size to other mazes you’ve successfully found your way out of. So you’re pretty sure once you get to the entrance, you’ll find your way out.

But there’s no way you can say exactly how long it will take you to escape. Maybe you’ll run right through from start to finish, and it will be smooth. Maybe you’ll get stuck in the beginning, and spend a long time before winding your way out. Maybe you’ll run right close to the end, but have no idea you’re a few feet away from the exit, and you’ll get stuck there for a while.

And maybe you’ll make it halfway through, get lost, go in circles, and eventually just die in the maze.

Problem is, I can tell you how long it’s taken me to get across comparable mazes, but I have no way of knowing how long it will take me to escape from this maze, and just having another engineer in the maze to pair with me and see things I’m maybe not seeing is no guarantee at all that either of us will get us. Statistically, we’ll probably make it out, but the estimate I give you is just a guess.

Unfortunately, it’s a guess that’s going to make a lot of people unhappy, no matter what. Because even if I make it out of the maze fast this time, then they’ll expect that I’ll zoom through the next maze.

– John

The Endowment Effect: The Ultimate Organizational Rose-Colored (Risk-Enhancing) Glasses

Fifteen or so years ago, I was a member of a review team that assessed a major, multi-million dollar software project. We were asked to perform the review because the project had some issues — it cost nearly $2M a year, was not yet delivering value to users, and had been running for 17 years.

Were I the ultimate decision-maker, my plan of action would have been simple: shut down the project, reconstitute a team with some representation from the old team, and use the lessons learned to rearchitect a newer, more robust solution. It would have customer involvement from the start to ensure a short time-to-value (and continuous flow of value). But there was one complication: the subject matter for this software package was highly specialized and required active involvement from people who had deep knowledge of the problem domain… and the team already had about 60% of the world’s experts on it.

Still, I was focused on the sunk costs. I felt that the organization should not choose to keep the project going just because over $20M had been poured into it… the sunk costs should not factor into the decision.

But then something very curious happened two years later, as the project was still hemorrhaging money… I was put in charge of it. So what did I do? Launched a two-month due diligence to reassess the situation, of course.

I was not on the review team this time, but their assessment was not a surprise — can the project, reconstitute the team, use the lessons learned to plan a new approach to delivering value quickly.

So that’s what I did… right? NOOOOO!!! I decided to try a little harder… because of course we could get the current software project to be stable and valuable, if we just gave it a little more time.

Even I was shocked by my transformation. Why was I feeling like this? Why was I ignoring the facts? Why was I, all of a sudden, powerless to make the appropriate and most logical choice?

Turns out, I was just demonstrating human nature via the Endowment Effect — which says, simplistically, that once you own something you value it more than before you own it. This is not just a curiosity though… because it can get in the way of effective decision-making.

Think about it:

  • Before you buy a house, you psychologically devalue it because you want to get a better deal. But once you move in, your psyche inflates the value because you stand to win as the value increases.
  • Why is it that leaders often value the opinions of consultants more than the opinions of full-time staff? Because consultants are more expensive, and once their reports have been submitted, you now own the intellectual property… and value it more.
  • The same effect occurs if you buy a company. You may be sensitive to issues and opportunities for improvement prior to the sale, but once your signature is on the dotted line… the endowment effect kicks in, and the rose-colored glasses magically appear.

This has a huge implication for quality and process improvement. Once you own something, you are less able to see the problems that need to be solved. This is why we use external auditors for our ISO 9001 programs, or review panels for our government projects, or a quality award assessment process for evaluating how well we are translating strategy to action.

Other people can see areas for improvement that you can’t, if you’re an owner of the process that has problems. The lesson? Get external eyes on your internal issues, and pay attention to their insights.

Shifting the Mindset: Walter White on Quality

(special shout-out to those of you who saw the typo the 30 sec it existed!)

In college, to meet my phys ed requirement, I chose a class where I wouldn’t have to exert much physical energy: golf. Almost three decades later, I still can’t play golf, but I did learn one thing in that class that has helped me through life.

When you’re trying to reach a goal, figure out a process to help you reach that goal, then focus on the process instead of the goal. I used this approach to improve my putting. Here’s how it worked: to get the ball in the hole, don’t aim for the hole… aim for a point along the line that goes to the hole, which should be easier to hit. If your ball hits that midpoint, it’s more likely that your putt will go in.

For example, if you’re at the white dot, aim for the Red X, not the hole:

This approach centers you on the process of making the putt. Getting your mind off the pressure of the goal results in the freedom to focus on what’s most important: developing the discipline and habit that will lead to success.

Bryan Cranston, the actor who played Walter White in Breaking Bad, had a similar experience until he was in his mid-40s. Although he had landed many roles in films and television series, none were the kind of long-lived and memorable performance Cranston was aiming for. So he made a conscious effort to shift his perspective.

Author Scott Mautz, citing Cranston’s 2016 memoir, describes the process:

Early in Cranston’s career he was an auditioning machine for commercials or guest-starring roles, a bevy of high-pressure stabs that might serve as at least a step up to the big time. But he was walking into a slew of rooms where he felt he had no power. All that changed when a mentor suggested a new outlook, and it led to an honest-to-goodness six-word secret to his success.

Focus on process rather than outcome.

Suddenly, Cranston felt free. He approached each audition as not going to get something, but to give something–a performance. And giving a great performance requires staying obsessively focused on the process of preparing to be able to give a great performance. He learned that if he overly focused on the outcome (will he get that part?) it set him up for disappointment and left him yearning for validation. Focusing solely on the outcome had also kept him from taking risks as he didn’t want to give a potential gig away with a mis-step.

But this mindset shift, of falling in love with and staying laser-focused on the process, changed everything for him. Soon after he adopted it, he got the role in Malcolm in the Middle, and then the career-changing Breaking Bad starring role.

From Mautz (2019): https://www.inc.com/scott-mautz/breaking-bads-bryan-cranston-finally-achieved-success-when-he-adopted-this-powerful-6-word-mindset.html?cid=sf01001

When you have a challenging or aspirational goal in your sights, like when your organization is starting a lean transformation or digital transformation, it can seem overwhelming. The heavy feeling can actually prevent you from getting where you want to go.

The solution is to identify your intermediary goals — the ones you can achieve by developing and tuning an operational process. Let go of the aspirations, and focus on the daily work, creating the habits that will make you and your organization successful.

Agile vs. Lean: Explained by Cats

Over the past few years, Agile has gained popularity. This methodology emerged as a solution to manage projects with a number of unknown elements and to counter the typical waterfall method. Quality practitioners have observed the numerous similarities between this new framework and Lean. Some have speculated that Agile is simply the next generation’s version of Lean. These observations have posed the question: Is Agile the new Lean?  

ASQ Influential Voices Roundtable for December 2019

The short answer to this question is: NO.

The longer answer is one I’m going to have to hold back some emotions to answer. Why? I have two reasons.

Reason #1: There is No Magic Bullet

First, many managers are on a quest for the silver bullet — a methodology or a tool that they can implement on Monday, and reap benefits no later than Friday. Neither lean nor agile can make this happen. But it’s not uncommon to see organizations try this approach. A workgroup will set up a Kanban board or start doing daily stand-up meetings, and then talk about how they’re “doing agile.” Now that agile is in place, these teams have no reason to go any further.

Reason #2: There is Nothing New Under the Sun

Neither approach is “new” and neither is going away. Lean principles have been around since Toyota pioneered its production system in the 1960s and 1970s. The methods prioritized value and flow, with attention to reducing all types of waste everywhere in the organization. Agile emerged in the 1990s for software development, as a response to waterfall methods that couldn’t respond effectively to changes in customer requirements.

Agile modeling uses some lean principles: for example, why spend hours documenting flow charts in Visio, when you can just write one on a whiteboard, take a photo, and paste it into your documentation? Agile doesn’t have to be perfectly lean, though. It’s acceptable to introduce elements that might seem like waste into processes, as long as you maintain your ability to quickly respond to new information and changes required by customers. (For example, maybe you need to touch base with your customers several times a week. This extra time and effort is OK in agile if it helps you achieve your customer-facing goals.)

Both lean and agile are practices. They require discipline, time, and monitoring. Teams must continually hone their practice, and learn about each other as they learn together. There are no magic bullets.

Information plays a key role. Effective flow of information from strategy to action is important for lean because confusion (or incomplete communication) are forms of waste. Agile also emphasizes high-value information flows, but for slightly different purposes — that include promoting:

  • Rapid understanding
  • Rapid response
  • Rapid, targeted, and effective action

The difference is easier to understand if you watch a couple cat videos.

This Cat is A G I L E

From Parkour Cats: https://www.youtube.com/watch?v=iCEL-DmxaAQ

This cat is continuously scanning for information about its environment. It’s young and in shape, and it navigates its environment like a pro, whizzing from floor to ceiling. If it’s about to fall off something? No problem! This cat is A G I L E and can quickly adjust. It can easily achieve its goal of scaling any of the cat towers in this video. Agile is also about trying new things to quickly assess whether they will work. You’ll see this cat attempt to climb the wall with an open mind, and upon learning the ineffectiveness of the approach, abandoning that experiment.

This Cat is L E A N

From “How Lazy Cats Drink Water”: https://www.youtube.com/watch?v=FlVo3yUNI6E

This cat is using as LITTLE energy as possible to achieve its goal of hydration. Although this cat might be considered lazy, it is actually very intelligent, dynamically figuring out how to remove non-value-adding activity from its process at every moment. This cat is working smarter, not harder. This cat is L E A N.

Hope this has been helpful. Business posts definitely need more cat videos.

How to Become a Successful Change Leader

For this month’s Influential Voices Roundtable, the American Society for Quality (ASQ) asks: “In today’s current climate, transformation is a common term and transformative efforts are a regular occurrence. Although these efforts are common, according to Harvard Business Review two-thirds of large-scale transformation efforts fail. Research has proven that effective leadership is crucial for a change initiative to be successful.  How can an individual become a successful Change Leader?

Change is hard only because maintaining status quo is easy. Doing things even a little differently requires cognitive energy! Because most people are pretty busy, there has to be a clear payoff to invest that extra energy in changing, even if the change is simple.

Becoming a successful change leader means helping people find the reasons to invest that energy on their own. First, find the source of resistance (if there is one) and do what you can to remove it. Second, try co-creation instead of feedback to build solutions. Here’s what I mean.

Find Sources of Resistance

In 1983, information systems researcher M. Lynne Markus wanted to figure out why certain software implementations, “designed at great cost of time and money, are abandoned or excessively overhauled because they were unenthusiastically received by their intended users.” Nearly 40 years later, enterprises still occasionally run into the same issue, even though Software as a Service (SaaS) models can (to some extent) reduce this risk.

Before her research started, she found these themes associated with resistance (they will probably feel familiar to you even today):

By studying failed software implementations in finance, she uncovered three main sources for the resistance. So as a change leader, start out by figuring out if they resonate, and then apply one of the remedies on the right:

As you might imagine, this third category (the “political version of interaction theory”) is the most difficult to solve. If a new process or system threatens someone’s power or position, they are unlikely to admit it, it may be difficult to detect, and it will take some deep counseling to get to the root cause and solve it.

Co-Creation Over Feedback

Imagine this: a process in your organization is about to change, and someone comes to you with a step-by-step outline of the new proposed process. “I’d like to get your feedback on this,” he says.

That’s nice, right? Isn’t that exactly what’s needed to ensure smooth management of change? You’ll give your feedback, and then when it’s time to adopt the process, it will go great – right?

In short, NO.

For change to be smooth and effective, people have to feel like they’re part of the process of developing the solution. Although people might feel slightly more comfortable if they’re asked for their thoughts on a proposal, the resultant solution is not theirs — in fact, their feedback might not even be incorporated into it. There’s no “skin in the game.”

In contrast, think about a scenario where you get an email or an invitation to a meeting. “We need to create a new process to decide which of our leads we’ll follow up on, and evaluate whether we made the right decision. We’d like it to achieve [the following goals]. We have to deal with [X, Y and Z] boundary conditions, which we can’t change due to [some factors that are well articulated and understandable].”

You go to the meeting, and two hours later all the stakeholders in the room have co-created a solution. What’s going to happen when it’s time for that process to be implemented? That’s right — little or no resistance. Why would anyone resist a change that they thought up themselves?

Satisficing

Find the resistance, cast it out, and co-create solutions. But don’t forget the most important step: recognizing that perfection is not always perfect. (For quality professionals, this one can be kind of tough to accept at times.)

What this means is: in situations where change is needed, sometimes it’s better to adopt processes or practices that are easier or more accessible for the people who do them. Processes that are less efficient can sometimes be better than processes that are more efficient, if the difference has to do with ease of learning or ease of execution. Following these tips will help you help others take some of the pain out of change.


Markus, M. L. (1983). Power, politics, and MIS implementation.  Communications of the ACM, 26(6), 430-444. Available from http://130.18.86.27/faculty/warkentin/papers/Markus1983_CACM266_PowerPoliticsMIS.pdf
« Older Entries