Category Archives: Socio-Technical Systems

Agile Should Not Make You Feel Bad

Agility can be great (even though for many neurodivergent people, it’s the opposite of great). But when teams go through the motions to be “Agile” they often end up overcomplicating the work, adding stress to interactions, and achieving less agility.

If your agile processes are “working”, then over the next iteration (typically 1-4 weeks):

⬜ You have a clear understanding, as a team, of the value you’re working to demonstrate. (Note that this is not a promise or a commitment, but a shared purpose, direction and intention.)

⬜ You have a clear understanding, as individuals, of the actions that will generate that value. You know what to work on (and think about) when you’re not in meetings or with clients.

⬜ You don’t feel alone – you have teammates to communicate with and collaborate with, and resources you can use, as you move forward to advance project objectives.

⬜ You are working at a comfortable, sustainable pace.

⬜ Your team is improving every week – you continually do things a little differently to help improve quality, productivity, collaboration, or other outcomes.

None of these things require meetings (or “ceremonies”) – just communication and inclusion. We should always be asking ourselves and our team members: what’s the easiest, smoothest, least intrusive way of building this shared understanding and maintaining it every day?

When teams work with agility:

⬜ Everyone understands the overall goal and the next increment of value to demonstrate.

⬜ Everyone has clear things to do to contribute to that value.

⬜ Each person (and the team as a whole) works at a sustainable pace.

⬜ Nobody feels alone. There’s a group of collaborators to share the work with.

⬜ The client or project champion has visibility into the work and is happy with progress.

⬜ There’s an opportunity to rest, reflect, and adjust every week or two.

It’s not ridiculously hard to adjust to changes in scope, tools, or personnel. 

But I regularly see “agile” teams flailing… unhappy… in constant panic mode, with stress that just won’t end. They are very busy and always seem to be scrambling to show their client or project champion some kind of value… with the feeling that they have to defend their existence. They have a nagging sense of confusion and impostor syndrome may be creeping in. They can tell you exactly what tasks are on their JIRA boards, but they can’t tell you why those tickets exist or how their task is contributing to overall project value. They have lost sight of the forest (value) because they have planted so many trees (tickets).

For these teams, the Scrum process and Agile ceremonies may be adding layers of stress and bureaucracy rather than helping the team work sustainably to consistently drive value. They are “doing Agile ” but have actually made themselves less agile… less able to flow and adapt and respond to changes in scope, tools, or participants.

Agile methods first emerged in response to the slow, painful, unsatisfying, unhappy practice of software development. It was really depressing to spend months building software, only to have customers and users complain how bad it was when they got it (especially when you developed exactly what they specified). It felt isolating to have to figure out how to deliver a piece of the software without any input from other engineers, and it was distressing when others were blocking your work and you had to convince them to listen to you. The whole endeavor was inefficient, and people were often tense and stressed. 

The realizations in red (in the 90s) led to the Agile Manifesto items (2001) in blue

We’re applying processes and tools without really examining why we need them

So let’s prioritize…

Individuals and interactions over processes and tools

  • Why this is part of the Agile Manifesto: Since the beginning of time, development teams tend to get hung up on the details of using tools (e.g. MS Project, JIRA, kanban boards) rather than why the tools are there in the first place: to make sure people are getting the information and context they need – on a regular, routine basis – to make continuous progress on the team’s overall deliverables.
  • What we should do in 2022: Focus on information sharing, context building, and working arrangements that help people get work done. This applies to interactions within the team as well as interactions with the client.

We’re doing a lot of work that doesn’t actually contribute to our goal

So let’s prioritize…

Working software [ie. tangible stuff that’s valuable] over comprehensive documentation

  • Why this is part of the Agile Manifesto: Software development in the 1990s was documentation-heavy. I even remember, in 2018, throwing away a few hundred pounds of paper (in about 20 4” binders) containing requirements and design documents for a really big software project that we did between 2002 and 2004. Often, development teams wouldn’t even produce software that matched the documentation because we’d learn about what was feasible and what was not as we were doing it. Everyone tended to deliver software that the business needed a year or two ago. We didn’t learn together and co-create the software. 
  • What we should do in 2022: We provide value in the form of information, shared understanding, and working software (which may be in the form of quality controls) – that’s it. Anything we produce that doesn’t directly contribute to making these things happen shouldn’t be done. 

We’re unable to deliver something we don’t know how to define or describe yet

So let’s prioritize…

Customer collaboration over contract negotiation

  • Why this is part of the Agile Manifesto: Because deciding what you’re on the hook to deliver at the beginning of a project – and exactly what the deliverables are going to look like – is dangerous. You and the customer rarely have enough understanding of the problem (or of each other) to get it right. 
  • What we should do in 2022: Establish shared accountability. (Note: this is rare. How many times has a customer been on your team and just as accountable to the project champion for the end result as you are?) A workaround is to set expectations with the client that we are discovering the shared understanding together, and we will get as close to the desired deliverables as we can, given the fact that we are embarking on a process of learning together.

We’re unable to commit to a plan when we might learn that our plan isn’t feasible

So let’s prioritize…

Responding to change over following a plan

  • Why this is part of the Agile Manifesto: As you learn about what’s possible, what’s not possible, and what the client actually values… plans will change. Instead of establishing a timeline that won’t end up working out (and that will cause you a lot of stress when you start deviating from), just start with the understanding that your Gantt Chart and your intermediary milestones will probably not be achieved when you think they will – or maybe even at all.
  • What we should do in 2022: Always keep the final goal in mind, but revisit and adjust the plan as you learn more every week. Iterate! 

The Discovery Channel Test

Presentations can be boring. Talking about your work can be boring (to other people). When you’re sitting in a talk or a session that you find boring (and you can’t figure out WIIFM – what’s in it for me)… you learn less.

Although we shouldn’t have to use clickbait techniques to satisfy societally decreasing attention spans, it is easier to learn and retain information when it’s interesting. So I encourage all of you to apply the “Discovery Channel Test” to every presentation, talk, or session you contribute to or lead.

The reason I call it the “Discovery Channel Test” is that there used to be a program called City Confidential that was on all the time. Even though City Confidential was a show about murder mysteries, the first half of the one-hour show was about the city or region where the crime occurred. They talked about when the town was first settled, and key families who made the town what it is today. You heard about stories of intrigue, and challenges the town was facing today. They made the story about the town itself so captivating that EVERY SINGLE TIME I was caught off guard when they ended the first half-hour segment with “You’d never believe a murder could happen here.” Through the hundreds of times I watched this show, I was always shocked when this point came. “Oh, yeah… this is where that murder mystery happened, and we’re about to find out about it.”

Any production crew that can spend a half hour off-topic, keep me interested, and give me a dopamine burst right before the main point of the show… has achieved something great. And you, too, can achieve this same greatness when you’re talking about your tech stack or a new architectural initiative or that project you did last year that improved customer sat. Make it interesting by applying….

The Discovery Channel Test (* = could also be called The Good Podcast Test)

Rule 1: Use an emotional hook up front. Why should any of the people in your audience not leave after the first five minutes? Don’t make them guess! Tell them specifically why this topic might be interesting, or surprise them with an initial feeling of novelty or unexpectedness. Jonathan Lipnicki’s character in Jerry Maguire (1996) was great at this, with his “did you know?” questions. The dopamine surge you create with an emotional hook will keep them engaged for long enough to get hooked on your story.

Rule 2: Find the wow nugget(s). This is one of the things the Discovery Channel has always been really good at: getting me interested in things that I didn’t think were interesting to me. Remember that your projects and initiatives, no matter how cool they are to you, will be boring to other people unless you TRY to make them interesting. I try to tell my high schooler that even in the most boring classes you should be able to find some nugget, some angle, some insight that helps you see the subject matter in a way that grabs you. Find that angle for your audience, and then spoon feed it to them.

Rule 3: Use examples, screen shots, visuals, diagrams. If your presentations are full of slides with words, people will start yawning immediately and may or may not actually hear those words. You can also reduce ambiguity with examples and screen shots. For example, saying “we used Python for this project” is far less compelling than showing the tree structure of the code (or a simplified diagram) and annotating it with what each piece did to get the overall job done. Saying “we used Confluence” is less compelling than saying “we set up a confluence site at [this location] and agreed to put [this kind of information in there]” because if someone has a need for [that information] – at least they know a first place they can look for it.

Rule 4: Spoon feed the closing thoughts. At the very end, remind people what you want them to remember when they leave. Remind people why that’s interesting, and how it might benefit them in the future. Make it concrete and tangible. For example, can you give them reference material, or an infographic, or a checklist that they can use in the future? Don’t assume that people will get something out of your presentation just by attending… spoon feed what you WANT them to get out of it.

“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.

Burnout at Work? It’s Not Your Fault

Over the past week, I’ve noticed lots of people on social media talking about burnout — loss of energy, loss of enthusiasm, and loss of self-confidence at work. The holidays have ended, and it seems many are not getting back into the swing like they hoped they might.

Are you burned out? If so, you’ve probably taken steps already to fix it. Most people have a natural desire to do well at work, and to make valuable contributions… and besides, burnout doesn’t feel good day to day. Maybe you spent lots of time away from your email or phone, and with family or friends. Maybe you focused on “self-care” — those activities that are supposed to pull you back to center, to restore your depleted energy.

And if the concerted steps you’ve taken don’t seem to be working, you’re probably even more stressed out (and more burned out) than you were weeks or months ago.

What’s the solution?

The good news is, the burnout won’t last forever. There’s a natural endpoint for burnout, and that’s when you completely reach your limit and don’t even have the energy to remember why you cared in the first place. Most of us would rather not get to this point. So what’s the alternative?

You have two choices, both of which can have huge impacts on your life:

  • Stay, and work on improving the situation, or
  • Leave, recognizing that you’re not able to contribute to a solution.

But how do you know which path to take? First and foremost, it’s important to understand where burnout comes from. In December 2019, Harvard Business Review published a great article that makes it clear:

  1. Unfair treatment at work. If you’ve been treated unfairly, or if you see coworkers being treated in ways that you feel is unfair, your trust in the organization is going to falter. It takes a long time to build trust, but only one or two incidents to break it.
  2. Unmanageable workload. If you’re given too much to do, or if you work on tasks that (for some reason or another) tend to get changed, shifted, or cancelled in-progress, you’ll have a hard time seeing your efforts pan out. Everyone needs a chance to see their work come to fruition.
  3. Lack of role clarity. If you don’t know (or are not told) what to focus on, OR if you’re told to focus on one area and then later discover someone else actually owns it, conflicts are bound to emerge.
  4. Lack of communication and/or support from your manager. This doesn’t mean you don’t talk to each other, or that your manager doesn’t philosophically support your work — it means that they aren’t doing enough to make sure that #1, 2, 3 and 5 aren’t happening.
  5. Unreasonable time pressure. Being expected to pull off heroics can lead to burnout, especially when it’s the status quo. The people who do the work should always be asked to provide effort estimates, particularly when the work is engineering or software development. Failure to develop and implement systematic, repeatable processes for effort estimation can lead to mass burnout later.

But here’s the part of that HBR article that really resonated with me…

The list above clearly demonstrates that the root causes of burnout do not really lie with the individual and that they can be averted — if only leadership started their prevention strategies much further upstream.

In our interview, Maslach asked me to picture a canary in a coal mine. They are healthy birds, singing away as they make their way into the cave. But, when they come out full of soot and disease, no longer singing, can you imagine us asking why the canaries made themselves sick? No, because the answer would be obvious: the coal mine is making the birds sick.

Jennifer Moss, in Burnout Is About Your Workplace, Not Your People

The lesson here is: If you’re burned out, it’s not a personal failure.

Burnout is a symptom of structural or process issues… that senior leaders are responsible for repairing.

The “Should I stay or should I go?” question, then, boils down to this:

  • Stay if you can help the organization treat people more fairly, establish manageable workloads, define more clear roles, improve communication with managers, and/or alleviate time pressure.
  • Leave if you can’t.

Granted, the decision process for you individually is probably more complex than this… but perhaps, by realizing that burnout is a characteristic of your environment and not a referendum on your personal resilience, you’ll be able to figure out your own path more easily. Good luck!

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.

« Older Entries