Important but Rarely Considered.

FBI SWAT teams are one of the most highly trained infiltration / exfiltration units in the world. Highly skilled, highly trained. Practice frequently. They are armed with the best gear in the world, bristling with guns, ammo, handcuffs, flash-bang grenades. In their center pocket, easiest and fastest to reach, is their most important tool.

A rubber doorstop. It’s worth thinking about.

“Feature” is Ambiguous.

Great joke of course.

We’ve used the word feature to the point that it’s lost specific meaning. A feature could mean, “this field will retain your data for the next time you log in”. A feature could also mean “big green button”.  A feature could also be almost any object or landmark. That big rock that looks like a bird’s head is a feature on the way to the world’s largest ball of twine.

I realized this as I was writing about an accidental behavior, that some might claim helps a customer. “Well, it wasn’t planned, but you could consider that a benefit if…”

This is the reasoning behind the joke, “It’s not a bug, it’s a feature”.

My question was, “Was this designed as a feature?”

I realized someone could answer, “Yes, that field is a feature”. Or be confused, thinking “The Product Owner created that object as a feature (story), and we made it. Of course it’s a feature”.

I don’t mean “was this object as part of the GUI, designed?”

What I really should be asking is, “Did someone argue that this would intentionally create a benefit for the customer?”

“Does this add value?”, is something we should be asking more often.

How Not to Get Lost

My friend and UX designer (and legendary keyboard warrior) Evan Travers writes about orienteering, something you may have done as a scout. Abstractly, two techniques to navigate in the territory of the modern software domain – Moderate Complexity and Moderate Uncertainty. While finding an exact destination requires many steps and many skills, here are two skills to avoid getting lost on the way there.

The Mechanics of Flow: You don’t have to be the fastest to beat the fastest.

In the past year I watched the Amazon series Patriot. From a plot perspective, the show is about an American agent who takes on a “non-official cover” with a pipe company to prevent a nuclear threat. At a deeper level, the show is about the complications of flow, mentioned several times as the simplicity of “getting something from Point A to Point B”. The company he works for is a global supplier of pipe and fluid delivery systems; think oilfields, Schlumberger or Halliburton. There are some truly stunning monologues of made-up technical jargon. Kurtwood Smith (That 70’s Show, RoboCop) delivers some incredible line readings showing his level of passion for his profession in dialog that borders on a psychedelic-tinged Star Trek techno-babble as written by Aaron Sorkin.

The fictional book pivotal to the show. Integral Principles of the Structural Dynamics of Flow, by character Leslie Claret.

As it turns out, Smith’s character Leslie Claret literally “wrote the book” on flow. I cackled when the book came up, as I’m actually reading the real book The Principles of Product Development Flow.

As the story in Patriot unfolds, the small and large scale patterns that affect flow come into play — complexities, coincidences, similarities, parallels, counter agendas, competition, enemy action, accidents, misunderstandings, miscommunications, poor timing, distrust, misaligned incentives and more. From an Operations Management and Scrum Agile perspective, these are a part of the normal understanding of optimizing systems.

The simplistic view of scientific management that is still a pervasive leftover from Taylorism is a simple input / output model. Speed is good. More work hours are better than less. Working harder is good. These implicit premises are rarely stated out loud with a full explanation of the assumptions and expectations. The general assumption is that increasing some input (hours worked, workers, speed) the system will increase a desired output (tires, iPhones, lines of code).

The modern history of scientific management from WWII till today has taught us that speed itself is not guaranteed to be correlated with good outcomes. In fact, speed itself can actually reduce outputs. What the sophisticated OM or Agile view has taught us is that overall flow of the system is the primary concern. When the smaller conditions are aligned in order to maximize total flow, it may actually turn out that one or more small inputs are actually under-utilized, or performing below their maximum output. The revolution from Project to Product view tells us that Value is the goal, not maximizing inputs that the customer has no interest in paying for.

With this view as background, I found the following article fascinating.

Japan's Olympic Relay Team Wins Silver Medal Without Having the Fastest Runners
Japan’s Olympic Relay Team Wins Silver Medal Without Having the Fastest Runners

The World’s Best Exchange Rate: Japan’s Secret to Relay Success

The article details how the Japanese team was constrained by the top speeds of it’s individual runners. So they focused on everything else. As the covert agent in Patriot learns, there are many complications in a process. Speed is only one element of a complex race like the relay. Please read the articles for the fascinating details.

When I shared this article with some online communities, my friend David Lormor (CTO, Wyndy. Find, book, and pay local college student sitters) shared this anecdote:

“I had a similar experience in high school. I was the fifth-fastest kid on my track team, but got promoted to the relay when our fastest runner got suspended due to grade requirements. We practiced our butts off — focusing on many of the same non-speed related “fundamentals” listed in that article. As a result, we took 1st place in all the races we competed in (I believe there were six).

The day before district finals, our “top runner” (who was probably a half-second faster than me in the 100 meter) came off of academic suspension and replaced me on the team. He didn’t have time to hone those same fundamentals with the team beforehand, and we ended up coming in 3rd in that race despite having faster individuals on the team. While we’ll never know how we’d have fared if I had stayed in the team for that race, the team all agreed that the last minute change was a contributing factor to losing that race.”

I love stories like these. Many people believe Scrum is just a way to schedule meetings, or that it means demanding work be done in two weeks. Using it from that limited perspective, it’s only as innovative as a grocery list. Maximizing speed, or “full utilization” are just inputs. These are local optima.

Scrum is more like learning chemistry so you know how to cook.

Putting the fastest runner in is exactly like the Taylorism obsessions of “working faster”, “skip the testing”, or my favorite “everyone staying busy”.

Understanding the difference in the paradigms of Local Optima versus Global Optimum is a fundamental step to maximizing the total flow of Value.

The iceberg in the glass: Two views of Agile, and what they say about your team.

The first generation of developers to experience Scrum Agile has moved on. The crop of developers encountering Agile for the first time are either in lagging companies with outdated SDLC methods, or are brand new coders who have only worked on personal projects, and had no need for a planning mechanism.

Is your glass half full or half empty? Is there an iceberg hiding underneath the waterline?

When Scrum was introduced, and the Agile Manifesto soon after, distribution and deployment of software provided a toleration of long development cycles. The Gantt chart, cutting edge in 1915, and the PERT planning of 1950’s still worked. As agility adoption proved the efficacy of Operations Management science in world of uncertainty and complexity, with refactorable work product, developers were delighted because they had something to compare it to.

Those development teams that are still not Agile are often called “waterfall”, simple because we’ve differentiated the pre-Agile and Agile eras by the old Gantt chart versus diagrams with looping arrows. But we have to be careful to recognize that a team is not necessarily Waterfall just because they are not Agile.

If you inspect many of the non-Agile teams now, you’re not likely to find Business Analysts with thoroughly documented requirements, Microsoft Project plans filled with fully detailed Gantt charts, and PMP certified Project Managers busily finding ways to crash the critical path with available resources from a slack branch. What you’re more likely to find is no methodology at all. The wild, wild west. Cowboy coders doing things their own way with, at best, some cultural norms.

This brings us to two different views that are common when Scrum Agile is introduced to existing teams. The “Relief” and the “Daunting”. For teams that are truly practicing a well defined SDLC methodology, they will see Agile as a relief. A reduction in documentation, contract negotiation, long range estimates pulled from thing air. For those cowboy coders who have evolved in their wide open prairie of no rules, Agile feels restrictive and constricting.

“So many meetings!”
“I’m spending all my time updating Jira instead of writing code”
“Why do I have to answer so many questions about this feature request?”
“I can’t pay two people to write the same piece of software!”
“I can’t spare my people for constantly testing your software every day!”

Herein lies the warning sign. If a team reacts to Agile with relief, you can predict they are likely to translate that halo effect into an appreciation of the framework itself. This positive feedback loop means they’re more likely to willingly learn and understand the concepts that make Scrum work. The more they “buy in”, the more success they will have applying the additional Scrum patterns.

If a team’s initial response to Scrum is that it’s restrictive, prescriptive, and high-overhead, consider this the tip of the iceberg floating above the water.

You are in for a rough ride. If a team is not relieved by the reduction in documentation and overheard, but sees Scrum as an increase in non-value added work, you can bet they haven’t been doing any of these non-functional practices. Technical Debt will be buried below the waterline. Documentation will be non-existent. Pairing was likely never practiced, and as a consequence, the skills profile of team members will vary wildly. You’ll find “experts” in different areas, with a great amount of pride about their fiefdom. Expertly controlled fiefdoms mean integration problems lurk underneath. Do you expect anyone has been writing automated unit tests? Not likely. Therefore the team assumes every feature is a monolithic algorithm that takes a month to produce (while they hide in a cave, the code hidden under a bushel).

In a case like this, the best approach is to put all the political capital on the line immediately, and find out if people have the willpower and the desire to practice Agile principles, and a Scrum framework.

“But we’re so far behind, we can’t take the time to do training now!”

Without a thorough understanding of what Scrum Agile is, what makes it work, a hearty desire for the outcomes promised, and an amount of faith to try it, the incremental “learn as we go” approach with an iceberg team is doomed to failure. There’s a specific certification exam questions about adapting the Scrum terminology to make the organization comfortable… and the inevitable trade-off is that the clean-break from past practices won’t be obvious and memorable. The weight of inertia and “how we’ve always done it” will grind the change to a halt.

Heed the warning signs if a team shows alarm at the “increase” in administration from an introduction to Scrum. Take the opportunity to have a meaningful gut-check about what the organization truly wants, and make sure you have buy in, and commitment to get past short term pains. Without the buy-in, every little pain will lead the team to wish for a return to the past. When the massive iceberg of Technical Debt begins to break into chunks and float into view, Scrum will be blamed as the cause (not the tool that made it visible).

Scrum is radical. It delivers radical results. A team deserves to know what they are in for, and a voice to commit or bow out.

Counter-pitching freelance gigs as Agile engagements

A recent discussion in one of my tech forums turned to a question of how to price yourself when you’ve been approached about freelance development gigs. Much good information was shared on topics including new developers getting their first paying gig, race and minority status in the job market, the temptations that lead to undervaluing your work, and how to research the going market rate of development time.

I wanted to add some perspective from the Scrum Agile world. I believe working in an Agile framework has a lot of advantages even for a single developer working at home on freelance gigs. Thinking like an Agilist can change the way you respond to requests for work, or bids.

Most discussions are going to start with one of the parties focused on “How long with it take to do X? What do you charge per hour Y? I can therefore expect it to be complete by date Z”

Consider pitching them an alternative business model. If someone is in the sandwich business, there’s no reason to assume they’ve ever heard of Agile. One of the beautiful things about the Scrum framework is setting development as an assumed continual cost (until the product is retired), and holding cost as a constant. The shift has been from “project focus”, where we assume something will be “complete”, to a Product focus, where we assume a new technology will have a continuous life cycle as long as it serves a purpose for the customer. One of the great benefits of broad Agile adoption is that almost anyone you talk to about a gig will be familiar with the “early and continuous delivery of value” model. They have all loaded a minimalist app on their iPhone, and they are used to receiving app updates every couple of weeks. Pitching them a business model like this may help them feel that you’re a more sophisticated professional.

Instead of saying “It will take X hours to complete this whole list, and I will charge Y per hour”, I would ask them a few questions:

A. “How will you maintain this product once the initial coding is finished?”
B. “How long do you see this (application) being useful to your mission?”
C. “Do you see it increasing in value if you add more features in the future? Do you expect your users will have ideas and requests for more features?”
D. “When do you plan to retire it?”
E. “Do you have a technical support and operations IT team on staff that I can hand-off my documentation and source to?”
F. “What will you do when you’re ready to add more features to this product?”

It’s likely a prospect for freelance work hasn’t thought that far ahead. One of the ways you may impress them is by consulting them on these aspects of modern development that other bidders are not likely to bring up. After asking those questions, I would pitch something like this: (an imaginary dialog)

“I find your project really interesting, and I look forward to helping you achieve your goals of XYZ. I think that will be exciting to see come to life. Let me tell you a little about modern trends in software development. Most companies have now shifted from a “Project” mode to a “Product” mindset.”

“What most development efforts do now is called ‘Agile’, and we assume the product will have long term maintenance, updates, and improvements; it will continue to become more valuable over time. You’ll want to have someone available to maintain and improve the product as long as it’s still creating value for you. The great thing about Agile is holding costs to a predictable, fixed budget. Let’s work out an amount that is within your monthly budget, and then we will work together to plan out the individual features that will make this product useful for you.”

“I will work on those in a priority order, and estimate how much I can complete within a fixed time every month. If you feel like the pace is too fast and cost to high, or the pace is too slow and you have room in your budget, we can adjust the amount of hours for a new fixed cost, and the pace of development. You’ll know exactly how much you’re going to spend every month”

“We’ll start by breaking the big idea into a ‘Minimum Viable Product’, the smallest feature that adds value to your users. I can have something simple for you to review sooner, instead of delivering one big thing at the end. Your users can start testing it out early, and we can make changes to the plan as we go. This prevents a big sunk cost down the wrong path. We’ll break down all the other feature ideas beyond the MVP, and we’ll estimate how long those take to develop, and see what the pace of releases looks like within your budget. By breaking things down to the smallest size possible and releasing and testing early and often, we’ll get you exactly what you need and no more, as early as possible. If you want to continue developing the product, we can, at a budget you feel comfortable with”.

“Once we’ve completed a few releases, I’ll be much more familiar with the codebase, and how to approach changes and improvements. I’ll be able to give increasingly better estimates on the pace and completion of items. The work should become easier, so you’re getting more value delivered for your fixed budget”.

I’d almost guarantee the client has likely not thought of this route, and if you’re bidding against 10 other people, it’s very unlikely any of them will suggest it. My suggestion is avoid over-promising and trying to minimize the “pain” of the price. Instead, set yourself up for a stream of income based on a set number of hours you can schedule in your calendar every week or month. And the benefits for them are (1) planned, consistent budgeting at whatever level they are comfortable with. (2) Seeing results early and often.

On Good Coworkers & Business Humility

“What makes a good coworker in tech?
What makes a bad one?”

I saw these two questions posted in a coding forum today as part of JC Smiley’s daily questions, which he then reposts with the answers to his LinkedIn feed. If you’re getting started in development, you should follow him.

“What traits or actions would make a horrible co-worker in tech?”

“What traits or actions would make a fantastic co-worker in tech”

I read the replies so far, as I considered my answers. The answers were good examples of specific characteristics:

  • No respect for others
  • Pushes work onto others
  • Doing the minimal amount of work
  • Negativity
  • Know-it-alls
  • Doesn’t ask questions when they need help
  • Advance themselves at the expense of others
  • “Holds an entire team hostage for their personal predilections” (#suspiciouslyspecific)
  • Seeks all the glory for themselves
  • Makes every meeting longer than it needs to be
  • Doesn’t come through on their responsibilities

The respondents often mentioned specifically that their examples of what makes a great coworker were the exact opposite traits. Which is not surprising, although there’s no reason to assume they are diametrically opposed:

  • Willing to help and share knowledge
  • Leads by example
  • Willing to go above and beyond just because that’s what a good human being should do
  • Open to ideas
  • Open to discussion
  • Good personality
  • Asks questions when they need help and gets things done as a result
  • Enjoys learning and talking about new things
  • The person who makes others better
  • Exhibits servant leadership before they have the leadership title
  • Being a decent person and treating others like one

I always think about patterns and root causes, and I thought particularly about this as a business-context specific question. We’re not looking for what makes a good person, but a good coworker. Mr. Rogers was an amazing person, but would he make a great DevOps Engineer? I don’t know. The mention of good personality also made me wonder, does being a good coworker require someone to be a good person in general? Is it important to enjoy playing couch co-op Super Mario Party with a coworker? Is the person you’ve shared the most beer with going to make a great coworker?

I believe in philosophy as a core element of business, and one almost entirely overlooked on a daily routine at least. What I believe makes a person a good coworker is what makes a good business, a singular goal; capital T, capital G— The Goal, and alignment with that goal. We form businesses or other organizations as “machine made out of people” to accomplish some specific end. Whether The Goal is revenue, profit, literacy, health outcomes, or saturating North Korea with wifi access, a lack of transparency and alignment with The Goal is a detriment. The lack of a clearly expressed goal allows individuals within the company to implicitly, perhaps accidentally, pursue independent goals. Alignment with The Goal is a requirement for a coherent and cohesive organization. You may not personally value elbowing someone in the ribs, but if your context is the NBA, if you can’t be aligned with that goal, you don’t belong in that context. The Goal should be so clear that everyone can remember it and quote it easily. So transparent that anyone can point to it on the wall when any debate about decisions is being waged. The Goal should clarify, align, and take out the garbage.

I’m coining as “Business Humility” the specific context of subsuming personal characteristics, goals, and fears to an alignment with The Goal. I am not making a case for slavish devotion to a business, or allowing personal goals to be flattened by a corporate behemoth. I say alignment, which should suggest pursuit of The Goal also accomplishes personal goals along the same path. The coworker who is aligned with the company goal does not have room in his personal philosophy for a fear of being replaced if he shares his technical knowledge with others. He doesn’t need to hoard glory. When a front-end designer makes the decision to initiate a pair programming session, navigating while a junior developer drives from the keyboard, she is showing servant leadership, sharing, teaching, and alignment with the company goals by increasing the bandwidth of her skill set.

A bad coworker is someone is essentially saying through their actions “The company exists to provide for my personal goals.”

A good coworker recognizes that alignment with the company means both parties benefit from the trade. Aligning with a clear and transparent goal, and the business humility displayed is the foundation of being a good coworker.

A Root Cause Retrospective

My goal with this Retrospective is a format allowing teams to break down a few specific issues into constituent parts, look for themes in root cause analysis, and take actions to prevent the recurrence of those factors.

Some specific choices about the Retrospective, and why I made these choices:

A. This Retrospective serves as an introduction or a reminder of Psychological Safety, a space where it is safe for the team to contribute ideas and feedback free from retribution.

B. Team Ownership – Promoting the idea that all of the work belongs to the entire Scrum Team. Everyone has a role to play in success, and includes (but goes beyond) writing quality code. For instance how the Product Owner wrote a story, or how the Scrum Master facilitated events.

C. System analysis instead of individual responsibility and blame. Pointing out that “Bob” caused the problem distracts from finding the systemic cause that allowed the Team to reduce quality. Therefore we have no column for Name, or anything related to individual effort.

To promote these factors, the choices I made in designing this custom Retrospective format include:

D. Input is Anonymous. Although discussion may “give it away”, creating anonymity for submissions, comments, and reactions can provide a small encouragement to speak openly. 

E. Work on multiple issues. I pre-seeded the Retro with several recent incidents. Tackling one specific incident, even one at a time, could create defensiveness in the person closely related to that one (or first) incident. Use enough seed Incidents to promote focus on factors of causality, not sources.

F. Make it clear that we don’t actually care if the cards in columns 2-6 are tied directly to their incident, they don’t need to “line up”. It’s OK to note that information if the participants feel it’s important, but once we get to a certain stage, we “throw away” the Incident cards anyway. We’re looking for clusters of themes that could apply to any incident, rooted in Team dynamics.


1. Create a Retrospective format on a whiteboard or whatever tool you use. You will need 6 columns to start. You will later remove column 1, and add columns 7 and 8 later. Leave room for them. I created mine using a Custom retro format on and their process worked well. Research a starter list of recent incidents the team has encountered and write those in column 1.

2. Create the following topic columns. The image at the top shows my column names, colors, and icons. Incident, Discovery, Symptom, Immediate Cause, Root Cause, Correction. Remember to leave room for 2 more columns. Notice that there is no column for “Who”.

3. If you’re using a virtual tool with anonymous option, I recommend using it. To help preserve the anonymity, instruct people to write in full sentences, so that thoughts can be clear on their own, without clarification. What is obvious in one person’s head will not be clear to others, especially surrounded by other cards. Any member should be able to read a card and expound on it, without the originator having to reveal himself.

4. Set your timer (5-10 mins): Invite the team to add additional Incidents in the first column, but have several seeded when they first see the board.

5. Set your timer (5-10): Invite people to fill in any cards within the appropriate topic columns, with details they can remember about the given incidents. It is not important to line them up, or link them to the related Incident. The factors should help to break each incident into concrete, specific actions and findings. How was it discovered? What was the symptom, who did it affect, what was the effect? What was the obvious cause? What was eventually found to be the root cause of the problem? What was done to correct the issue? All factors might not apply to all incidents.

6. Set your timer (5-10): Delete or remove column 1 with the Incident cards. We don’t care about the specific incidents. Instruct the team to identify the most common clusters or themes of factors. Move cards around to group them. It is possible that the same theme may occur in different column, and you can move cards to group them.

7. Set your timer (5-10): Instruct the team to place votes according to which factors they want to focus on. For the number of votes, I would suggest (Number of cards / 4) + 1 for the number of votes per person. They can spread their votes out one per card, or place multiple votes on cards they consider more important. The Incidents should already be gone, so voting is only on the remaining cards.

8. Set your timer (5-10): Begin discussion by sorting the cards by vote totals. Choosing the top themes you want to discuss. Maybe pick the top N items, and timebox for 5 minutes. Adjust based on team enthusiasm and the amount of time you have. If you have a thorough discussion on the top N, you can always choose another and add time. Remind members that the purpose is to determine common causes of incidents, and to create actions or artifacts that will prevent recurrence in the future.

9. Set your timer (5-10): Add the columns for Preventing Recurrence and Artifacts/Actions. Discuss what would prevent recurrence of the most important clusters the team has identified. Write those preventative solutions in column 7.

10. Set your timer (5-10): Instruct participants to choose a small number (maybe 2-4) of the Prevention cards. Ask them how to convert these into specific Artifacts or Actions to take going forward. An artifact might be “an automated testing tool” or creating a specific checklist for a certain procedure (things to do when promoting code to PROD). An action might be creating a specific “role” for someone to do X during every Sprint Planning ceremony. Discuss assigning these Artifacts and Actions to someone specific so they have ownership. Ad a card for each to next Sprint Backlog so that the work is visible and will get done soon. Focus on artifacts and processes that will be more robust than just the “knowledge” of the root causes. People will forget this Retro, but the Artifacts and Actions should cement the lesson into the improved Scrum process.

Expressing Pain

One theme on my mind right now is the proper expression and treatment of “Pain” as a core part of Scrum Agile working as intended. Schwaber and Sutherland said they promise one thing only from Scrum, everything else is a nice side benefit. Scrum will show you all of your problems. In order for that to work, the processes, Roles, Artifacts, Ceremonies are the given “rules” for what specific things to hold constant. Then let the pain be expressed where it actually happens. Hold everything constant that you can. Automate, routinize, and forget about everything that can be standardized. Reduce your degrees of freedom as much as possible. This will leave 2 things:

(1) The pain will be expressed in the correct place. The leak will happen in the correct pipe. That’s what we want to happen. We don’t want to allow the leak to spring in the wrong place because we’re trying to prevent the pain from coming out. That will lead to making the wrong changes from learning the wrong lessons (or not learning lessons at all).

(2) You will find out all the places that can’t be routinized. Where you need human creativity, innovation, people skills. This is the “Individuals and Interactions”, the “satisfying customers early and often”, the “working together daily”.

What prompted this was a question from a Product Owner about a story that we know will not be completed due to an upstream input we can’t control. He asked if he should just drop it to the Product Backlog now and pick it up in the next Sprint, or should we keep it and discuss it in Review. Every item for Review is a chance to look at a pain, and look for a solution. If we just pull the story mid-sprint, then we won’t talk about it during Review. We’re avoiding expressing a pain. This specific story may not be the magic key that unlocks all the answers. But some story might be.

If we skip steps in Sprint Planning, Review, Retrospective, or Daily Scrum then we’re skipping a chance for the correct pipe to spring a leak.

It is incredibly tempting to practice management as foreseeing, avoiding, and preventing pains from being expressed. This will lead to crippling a structure bit by bit, from a series of wrong changes to all the wrong parts. In writing code the answers are buried in the problem itself and you discover those answers by expressing the pain.

The first thing the doctor asks you is “where does it hurt”?

This may be the most important concept in the procedural aspects of Scrum.

<span>%d</span> bloggers like this: