DEV Community: Steve Hallman

What difference could it possibly make?

Steve Hallman — Wed, 23 Feb 2022 04:36:11 +0000

15 Reasons to Change Sprints Mid-Week (and hold the Scrum Events as intended).

The ironic thing about assumptions is we’re generally unaware of them. Like fish saying, “What’s water?”, we are surrounded by things we assume must be true. Which means we’ve never even considered doing them any other way. Weeks start on Monday, months start on the 1st, the batter starts on home plate. These feel so natural.

Do Sprints have to start on Monday and end on Friday? The answer is not only “No”, there are significant advantages to changing Sprints mid-week. (It is also worth contemplating the Sprint length, and other factors, but we shall discuss that another day)

I argue that mid-week Sprint change is a technique of hyper-performant teams– just as important as holding every event, performing each event as intended, with the right participants present, at the right time. Here are 15 advantages of the mid-week Sprint change, and the Scrum Events held unapologetically. Can you think of others?

Sprint Planning should be the first event of a Sprint. Time spent on anything else (other than the preceding Sprint) introduces a Cost of Delay to your efforts. You need adequate time to plan. This means a working meeting free from “meeting guilt”. We’re not ashamed, we have no imposter syndrome, we know we are solving novel problems, and this takes time for the customers and Scrum Team to plan. That means avoiding the worst day of the week for meetings.
Start with the maximum Event length your Scrum Master or Agile Coach is ever going to ask for. The proportional Sprint Planning length is 8 hours for one month, 4 hours for two weeks, and so on. It’s very easy to take less time if you find you have completed the outcomes expected of Sprint Planning. Meeting guilt is always going to pressure people from increasing the time. When you’re 6 days into the Sprint and realize you don’t know the details of the feature you’re supposed to build, you will think back to Sprint Planning, when some folks felt pressed for time, and DOR was skipped because “everyone knows what the green button is for”. Skipping the three sections of Sprint Planning (you know all three, right?) will inevitably introduce COD in the system.
This ratio has been validated for more than 30 years. A lot of teams have done a lot of Scrum, and not all of it good. The Sprints that went well are planned well, and follow Sprints that were closed well. If hyper-performant teams use 8 hours to plan a month long Sprint, and it boggles the mind, it’s worth asking, “What are they doing that we’re not doing?”

Given that two weeks is most common, 4 hours can be done. There are ways to resolve all the most common rebuttals and complaints. Take breaks, set time blocks for different groups of customers, adapt!

Adequate time for a full Review. Sprint Review is the second most important Event in a Sprint. It does for the work, what the Retrospective does for individuals and interactions. Review ≠ Demo. Review may include a demo of features, but the purpose is to produce specific outcomes (a new Product Backlog) and discuss factors that affected the work itself. If you’re breezing through a 30 minute demo, I challenge whether you are doing “Transparency, Inspection, and Adaptation”.
Adequate time for a full Retrospective. The single most important part of Scrum. Raise you’re hand if you’ve been on a team that had a “Review & Retro” single event on the calendar. These are distinct, and each has it’s own outcomes and timebox. If the Retrospective is sharpening the saw after every day of cutting lumber, what are we doing if we pencil-whip a few “pat-on-the-back” cards in our Retro plug-in and call it an early Friday? Sharp tools are safer, they cut better, they require less compensation with technique (or personal strain). I will guarantee you a Scrum Team that breezes through Retrospective is relying on heroics, and heroics are not Sustainable Pace.

Advantages of Mid-Week Sprint Change

Given the importance of the Events outlined above, we want to take advantage of any hack that allows us to squeeze the maximum value from them. The mid-week Sprint change is that hack.

Monday and Friday are the most frequent national holidays.
Monday and Friday are the most frequent company holidays.
Monday and Friday are the most frequent employee vacation days.
Monday is the most frequent sick day.
Monday and Friday are usually the “busiest” or most hectic days. Monday is the day everyone “puts their work brain back on” and tries to remember what they were doing last Friday. The weekend is a break in momentum. Picking up on Monday is usually hectic (see more below) and you’re entering that chaos without the memory of what you were excited about on Friday.
Monday and Friday are the most common days scheduled for reporting, starting, and ending of other projects. This frequently causes meeting conflicts. Since everyone else is hosting kick-off meetings that you’ll get roped into, avoid holding your most important events on the same day. Unless you’re the bride, don’t wear white to a wedding. Having your key events mid-week helps you to Be Fully Present for other stakeholder’s events. They’ll thank you for it.
Review and Retrospective should be the last thing that happens in a Sprint. These are the two most important Events in Scrum. It’s no secret that people tend to “zone out” on Friday afternoon, or they are impatient to start the weekend. Possibly leave work early, get a jump on that traffic on the way to the lake. If you hold Review and Retro early, you have cut your time to produce value before these. The last possible moment would be the end of the day, on the last day of the Sprint. If you make that a Friday, good luck getting anyone to think about “inspect and adapt” with enthusiasm while they are groaning and watching the parking lot empty.
Releases to PROD often happen coincident with Sprint closing. This leads to bugs that show up on Friday and cause a panic fixing them last minute. Or having to troubleshoot on the weekend. Or, people miss Review or Retro because they are troubleshooting just-released code. While there are plenty of technical tactics to avoid this, we’ll leave that for another time. One thing you can do to prevent this is mid-week Sprint change. If you push everything to PROD with a prayer and voodoo dance around the server, you’ve got 2-3 regular work days to catch something, and you’ll be in a better mind to deal with it than sweating while your wife is waiting in the parking lot with the beach trip luggage and kids slathered in sunscreen.
A mid-week change gives a full, uninterrupted week during the Production Episode to focus. Your whole team does understand the Production Episode pattern, right? With mid-week Sprint change, the entire (assuming a two week Sprint) cycle takes place over three calendar weeks. You start on a Wednesday or Thursday, have one full, uninterrupted week in the middle, then half a week till wrapping on Tuesday or Wednesday.

If one of your team’s goals is to reduce meeting fatigue, find enough time to focus on work with some momentum, and hide from customers and the Product Owner (I kid, I kid), you’ve never known peace like a Production Episode with a whole blissfully uninterrupted week in the middle of it. Also, remember that stuff at the top about actually having a FOUR HOUR SPRINT PLANNING!? Guess what, holding all the Events for their recommended duration goes a long way to put out the little “meeting fires” that pop up when the team discovers unanswered questions during the middle of the Sprint. You have time in the Retrospective to ask questions like, “Why do we keep having ad hoc meetings? Why can’t I concentrate on something for more than 30 minutes between meetings? I want to mob with Judy and Tom, why can’t we find even an hour that overlaps!?”

The 2-3 days at closing, and 2-3 days after planning feel like “mini-sprints” and help focus on the most important things that need to happen “right now”. Let’s use the example of closing Sprint 1 on Tuesday and starting Sprint 2 on Wednesday. Wed, Thurs, Fri feel like a little 3 day Sprint. You’re invigorated from Sprint Planning, and you’re full of fresh ideas for some new experiments. If this was Monday, there is a psychological temptation to think, “I’ve got all week”. And by the end of a typical Monday, everyone else’s chaos has ground the oomph out of you.

Similarly, returning from a weekend with 2-3 days remaining till Sprint close, you have a little pretend pressure and a smaller timebox to think, “OK, what do we need to wrap everything up and land the remaining planes in the air?”

A bonus! While everyone else has the mid-week doldrums, you will come out of Sprint Review and Sprint Planning invigorated right in the middle. I’ve seen downstream internal customers that were ecstatic coming out of Sprint Review. They were positively giddy and looked forward to opening their Christmas presents in the middle of the week. It lightened their mood and gave them a few following business days to think of new ideas, changes, or additional details based on what they had just seen. This captures psychological momentum. Hold Review on a Friday afternoon and you’re likely a customer overlooks a bug or style problem while they’re watching the traffic back-up, and then any chance of continuing their product thought excitement is flushed down the drain once Friday is officially in the books.

What did I leave out? Can you think of other reasons to emphasize the importance of Event scheduling, timeboxing, and mid-week Sprint change?

When Leveraging Skills Increases Team Fragility.

Steve Hallman — Fri, 11 Feb 2022 18:05:01 +0000

Understanding the Team Skills Profile, and

why “un-teaming” kills delivery of value.

Every team has a Skills Profile, like the unique fingerprint of technical and business abilities of the group as a whole. My friend Tim Ottinger (who you should follow) often uses the term “ Un-teaming “. He is primarily referring to the “scatter / gather” anti-pattern, where teams still don’t fully grasp the power of moving one single item (the most valuable) forward as a group. In Tim’s “un-teaming”, each person grabs a piece of work and scatters to the winds. This anti-pattern is often a defense mechanism for Imposter Syndrome. If Dave the developer is working alone in his home office, on a separate piece of work, no one hears him say “I don’t know how I’m going to do this”, or look up answer on Stack Overflow, or YouTube videos.

There’s another way in which teams can be worse off, by following a heuristic that seems intuitively beneficial. It’s a special case of “un-teaming”. First we need to understand two specific benefits of a high-performing team: Robustness and Anti-Fragility.

Robustness is the ability to do work, a lot of work, heavy work, different types of work. Robustness is a resistance to fragility inducing stresses. Robustness is like being a strong, flexible cross-training athlete. A healthy all-around athlete can lift heavy things and can do more than one specialized exercise. One stressor will not defeat a Robust system.

Anti-Fragility is the ability to recover from fragility testing conditions stronger than before. When an athlete lifts weights, the muscle tissues suffer micro-tears, and the body rebuilds the muscle stronger than before. Broken bones heal to be stronger at the break. Poke an anti-fragile system, and it bounces back beyond the original peak.

Un-teaming by leveraging a team’s individual skill advantages is a common, intuitive tactic that leads to an unintended outcome. In practice, this means Dawn is the team’s brilliant DBA and data science expert. The team, or someone who dictates parsing out the work, decides having Dawn work on a new data warehouse feature is helping the team by taking advantage of her expertise. It will be done well, and quickly.

The Team Skills Profile

Every team has a unique combination of knowledge, skills, and experience of each individual member. It’s like an imaginary fingerprint that I call the Team Skills Profile. This could be multi-dimensional, including factors of time, multiple experience contexts, general expertise, academic knowledge and many more factors. For our purposes, we’ve collapsed this into two dimensions. The example below shows a team’s self-rated skills level (Y-axis) across their range of technical and process skills (X-axis).

Any individual line (like Frederick in green) shows that person’s skills profile. In Frederick’s case, he has just joined the team as an intern. He has only been developing for about a year. Learning Python at home, he became incredibly proficient at it. He’s a deep dive kind of guy, but he’s been in his own fishbowl. Frederick hopes to get hired on as a junior developer, and he’s eager to augment his deep Python knowledge in a broader context of version control, interfacing with other technologies, testing, awareness of customer needs, and how to plan and track his work.

The beauty of the Team Skills Profile is seeing the maximum capability the entire team is capable of delivering. As an individual increases a specific skill, the top-line profile only moves up. It will decrease in variance from the bottom up. Theoretically, the top line never comes down. (The exception would be the loss of one member, but following the principles from understanding the power of Robustness and Anti-Fragility, the effects of sucj a loss should be minimized).

It doesn’t matter if one or more developers have a lower skill than others. No one can bring the top-line down— it’s not an average. The top-line profile also shows the team’s peak skill and the team’s weakest skill, making it easy to identify areas for rockstars to share knowledge (Anti-Fragility). Frederick could get a big ego boost and gain some appreciation from his new team by hosting a lunch-and-learn on Python. It’s visibly clear which topics could increase team-wide weak skills (Robustness). Ashlyn, Kevin, and Felipe could research some advanced CRUD techniques and host a team session.

Does it matter if one developer is the weakest across all skills? Argee’s line isn’t even visible because he’s rated himself a “0” on everything. Should he be nervous? No! Because the team is responsible for delivering the work. This understanding should increase Psychological Safety for all team members and helps create a safe space for new team members, or junior developers. The top-line Team Skills Profile is a “defense shield” protecting learners and noobs.

The converse is also true. When “un-teaming”, we’re decreasing robustness and increasing fragility, because we can only utilize the Skills Profile of one person, or even a pair, which mathematically will always be below the top-line profile. If we imagine calculating the delta space between an individual, pair, or mob Skills Profile to the Team Profile, that is the value we are throwing away whenever we un-team.

A common pattern seen comparing “intuitive” tactics to empirical systems like Lean, Theory of Constraints, Scrum, or XP— “intuitive” ways of dealing with apparent obstacles often accomm _ odate _ a problem rather than _ solve _ the problem at the root. And this brings us to the problem of un-teaming. Every individual has high and low areas of skill. The black top line is the Team’s skills profile. No individual can have a skills profile as robust as the whole-team skills profile. It’s very common for a team, dev lead, manager, or even Dawn herself to decide she should take the new data warehouse feature.

To optimize the company’s Goal, our team’s Goal, and individual developers’ Goals, we need to consider the second-order effects of this decision. What will happen when Dawn continues to take the data work, Kevin continues to take the API work, and so on? The Team Skills Profile increases in contrast. Dawn’s skills in other tech will get dusty, and she will increase her expertise in data. In fact, because she’s already highly adept, she will notice lessons during the data problem solving that Marvin (who is moderately skilled with data) may not notice. High expertise combined with more practice compounds. The more Dawn’s peak data skills outstrip the rest of the team, the more likely she will be assigned all data work in the future. This is a negative feedback loop. It seems temptingly positive at creating a better data wizard and getting work to Done quickly (both are Local Optima). But it lowers Robustness and decreases Anti-Fragility. The long-term effects include “black swan” events, like Dawn going on vacation, or leaving the company because she feels burned out and plateaued on data expertise.

When a Team works as a Team, even if Dawn is leading a session to solve a data problem, every member on the team gains a little skill.

Scrum is named after the rugby formation where all players of all skill positions link arms and push in the same direction at the same time to move one ball forward. In custom software development, there are techniques that leverage major advantages of the nature of software itself, and the complexity and uncertainty of product requirements. Operations Management experts in physical manufacturing would be insanely jealous of these. These advantages are what allows Scrum teams to see increases in Flow of Value in the 200%, 400% range (or more). It’s nearly impossible to do that on a Toyota truck assembly line.

A customer software development team that does not use the techniques leveraging unique advantages of software cannot see performance gains greater than a team that does not have these advantages.

Un-teaming is a major loss. And using a Team Skills Profile with self-assessment and period team discussion is a great way to increase the Robustness and Anti-Fragility of your team. You competition might be doing it right now.

The Value of Failure

Steve Hallman — Wed, 09 Feb 2022 17:24:19 +0000

Success and Failure work together. I always remember Adam Savage on MythBusters saying “Failure is always an option!”

Everything in custom software development is an experiment. The actual code is an experiment. The feature has an unknown value to the end users. The product is a hypothesis about business value. The processes we use to produce working software is composed of many experiments.

What we want isn’t “success”, because that’s not a thing you can directly acquire. Otherwise we would walk into the Success store and just say “Give me $200 worth of success please”.

We have to attempt success. Which means failure and success are possible outcomes of each tiny experiment. High performing people, teams, organizations are those that experiment often, earlier, and in smaller increments.

Failure isn’t an end state. It’s not comprehensive, unless you allow it. Failures are way-points along a continual journey. If you can fail as early as possible, with a tiny loss, many times, you gain information on how to pursue your path forward. We’re a bit like submarines, pinging a blind landscape to move forward. Success and failures help us see the terrain and navigate the path toward success.

Failures are exactly as valuable as successes.

Turning User Stories Into Enabling Specifications

Steve Hallman — Fri, 28 May 2021 16:17:13 +0000

I’ve had a contractor re-building my back deck, and adding a screened porch area. I had a little side-project I wanted done in the garage, so we walked in there so I could describe it.

I told my contractor a story , showing him where my car fits in the garage, where the “extra fridge” sits, how much room there is to walk between my side view mirror and the fridge door handle. How my wife has to walk around my side of the garage to get in the house, and when she’s carrying two arms full of grocery bags, it’s hard to get through.

I told him I don’t know enough about housing construction to know if those 2×6’s were structural supports, whether they could be cut and engineered with a header over the top, and if that would provide enough support for the two stories above. I pointed out where the electrical plug is, and I believe the fridge can plug into the same place, without needing to cut the stud that the plug is on.

When he showed the project to his lead builder he just said “There’s pipes and several walls meet here (points up). Prop this with a jack stand. Cut these two studs (pointing), move them out, supporting the next two, and cut 2×6’s to create a header spanning them.”

All of these parts needed to happen. Sometimes the customer needs to tell their story. This activity alone is useful. I’ve seen customers talk to a Product Owner and the outcome was that no work proceeded; the person realized their need was outdated, or they had a solution to the problem already. Helping the customer say “No” is just as valuable as taking an order. Remember the Agile Principle #10, “the art of maximizing the amount of work not done”.

A Product Owner’s job is to understand the customer’s needs in both the language of the customer, and the language of the developer. Although we often use the terms “Story” or “User Story” as interchangeable with “card”, “PBI” (Product Backlog Item), “Feature”, or “Enhancement”… a true User Story is really just one method of telling the user’s journey from his current need to his successful resolution.

The role of the Product Owner is to translate that into “Enabling Specifications”, a list of discrete work items that the Development Team can immediately understand and begin work on.

Note: “Begin” work. If the Development Team has to ask questions before they can start, the written PBI does not yet allow them to “begin”. This is what’s meant by “Enabling”.

_ The PBI is the gunshot that sets the runner at the block free to race forward. _

The Real Costs of Sub-Optimal Product Backlog Ordering

Steve Hallman — Thu, 27 May 2021 22:44:59 +0000

A quick post while I’m thinking about real costs (see the previous post, real costs of context-switching). The role of the Product Owner is to “maximize the value of the team”. Paradoxically, she does not do that by altering the team itself. The flip side of the coin is that the team of creators do not control their own fate when it comes to maximizing their own value. They can deliver high quality software soon and often, and still be a very low-value team, because they do not control what they work on.

The synergy of the Product Owner and Development Team (or creators) is a major component of what makes Scrum work — and by “work” I mean deliver 400% more value than non-Scrum teams, or the same team’s pre-Scrum days. The Product Owner owns the Product Backlog , which can be considered the “on ramp” of the production highway. While the creators are focusing on “this mile of traffic” the PO is queueing up the next batch of work to merge onto the highway once the lane is clear. This both protects the team from distracting work (and distracting people) and preserves their time during the Production Episode so that they can Focus.

The Product Owner herself is also in a bind. She does not control the work she’s given to do! There are caveats to this. A great Product Owner is much more than an order taker. The most valuable thing a Product Owner can say is “No”. But I will touch on this another time. For our limited scope, we will treat the Product Owner as simply an order taker. Since the PO has no control over the work requested, and the creators have no control over the work the PO serves up, how can the Value possible be optimized or sub-optimized?

One good question to ask yourself when wondering if something can be improved is, “Could I take what is given and make it worse?”

The answer is often “Yes”, because a given system or collection of goods is most likely to be in a random order. If your PO simply orders the stories in the Product Backlog by their arrival time, or the importance of the customer, or the height of the customer, or any other arbitrary criteria, we have no reason to assume there is a relationship between the Ordering of stories in the PBL and their Valuation. If we could intentionally rearrange that order to make things worse, then we could intentionally rearrange it for the better.

If the PBL is ordered by anything other than Valuation, the most likely outcome of long-run production is the average value of all stories selected randomly.

In other words, not properly ordering the PBL is a guarantee the value of the Development Team will be average.

Hard to imagine? Picture a black back with a collection of ping-pong balls. On each ball is a $ value. If you randomly reach into the bag, over time, the value you pluck out will approach the average value in the bag. You might get lucky and pull out $1000 first, but you might be unlucky and pull out $1. What kind of bag would you like to use? (What’s the 1st pillar of Empiricism?) A Transparent bag. So what would a transparent bag mean, it means picking the Story order by looking at what’s relevant.

Baby Steps

“But we don’t put a dollar denominated Valuation on our Product Backlog Items”, the patient says.

That’s OK. Can your customers or stakeholders give your PO an estimate, even a very rough estimate of dollar value? Can they even give you an estimated order of value, absent any realistic dollar value?

“But what’s the point of making up numbers? Didn’t you just say we want to avoid getting random value out of the team? All of the stakeholders are just going to put a large number on everything!”

That’s OK. These are baby steps. Imagine customer Carl can tell our PO, “Well, I’ve given you three portfolios of work, and they’re worth about $1M, $2M, and $3M respectively”. This is a great first step. Now our PO can work with Carl to decompose the individual stories within each of the three portfolios and ask, “Now within Portfolio A, can we order these by value? Then let’s put some pretend value numbers next to each one in descending order”. Do that three times and you have three portfolios broken down into individual PBIs, each of which has a (made-up) number representing a value relative to the other stories within that portfolio; but also against all other stories in all three of the portfolios.

If our intrepid PO serves four customers, and does this with each, we now have 12 individual portfolios, with all of the decomposed stories represented by a relative value. We’re making huge strides in improving the long-run value of our Development Team. Now, it’s true that those individual customers may have exaggerated their base numbers. They could be gaming the system against the other managers! But we can work on improving this system later. This is enough to get us started.

So What?

How much difference can the order of the items in the PBL matter? (By the way, this also applies to the Sprint Backlog, but we’ll tackle DOWP later). The short answer is “a lot”. If you’re incredibly lucky, you might pick the most valuable PBI from the top of the PBL and the SBL. If so, you immediately win! Because the next best possible move would be selecting the second most valuable PBI instead. The value of your win is the difference in value between the two. But the most likely outcome is picking a random, average-value story first, and a random, average-value story second.

Here is a sample Product Backlog:

That’s some expensive fruit.

You’ll notice these are mostly thrown in order of the total portfolio’s value. There’s one monkey in the wrench, where our Blue and Orange portfolios snuck up to the top, maybe Ms. Blue is a Very Important Manager, or Mr. Orange brought our PO her favorite coffee. We can also see where the organization decided on an arbitrary cut-off of “Phase I” and what will be part of “Phase II” and “Phase III”. It seems reasonable that someone would think of working each project in this order, because each portfolio is (mostly) more valuable than the one below it, and if you compare the individual stories, they are also more valuable on a one-to-one basis (I used starting values of 1, 2, 3 etc. to make the case clear).

If we calculate the value of working the PBL in this order, how does it compare to ordering by individual story value? And how do both compare to throwing the PBL into a random order?

The graph is pretty. The results are not.

The graph tells the story. Blue, Green and Yellow show the comparison between Portfolio order, individual PBI order, and Random order for good measure (there are many variations of the random order. This particular case was by RNG). The Story order (green) versus Portfolio order (blue) is the first thing to note. Both start out the same, because we’re tackling our $600M story first either way. But then we immediately see the cost of taking the second most valuable story in the pink portfolio instead of the second most valuable story overall. Yellow is our random order, which start out close to zero (a $60K story was in first place), jumps a decent amount by the time the fourth story is a $150M payoff. As we go further in time, the average value delivered converges.

Loss

Right out of the gate, within 1-3 items we have an enormous difference in value delivered between the three ways of ordering the PBL. The dark red line shows the value sub-optimized ($178M is a substantial difference) between the Story-ranked PBL and the Portfolio-ranked PBL. The difference in Story-ranked and Random (thin red line) is even worse, essentially foregoing close to $600M right out of the gate, and not catching up until well into Phase II, or by the time we complete PBI 33.

Questions:

What should our next baby steps be?
This is just a snapshot in time with 6 portfolios or epics. What happens over time as more epics are submitted to our Product Owner?
What other benefits would come from ordering by valuation of individual stories, aside from maximizing the dollar denominated production value of the team?
We would have reached “Phase II” at item #25, and “Phase III” at item #32. What observations can we make while thinking about this? What about the time before it; the time after it?
Why is the timeline important when considering the comparative value lost?
What happens if you miss nearly $600M in value within the first 4-5 items delivered? Could this make or break a project in a way that isn’t fundamentally related to it’s intrinsic value?
How much value did your Development Team deliver last year? Does anyone know?

The Real Costs of Context-Switching

Steve Hallman — Tue, 25 May 2021 17:18:12 +0000

The Buggles: Video Killed the Radio Star (1981).

The first music video shown on MTV, 12:01 a.m., August 1, 1981.

This gif is my piece of ’80s humor for team members who appear on the kanban board as creating two items at the same time. I’ve never actually seen a developer who was simultaneously ambidextrous and therefore able to type on two different computers, producing two different items of valuable work. What the Transparency and visualization of work is actually telling us is that Jane is switching between two pieces of work.

This post was partly inspired by a recent Your Daily Scrum episode by Ryan Ripley and Todd Miller. (I highly recommend the show)

There is good research that shows multi-tasking actually lowers your IQ by 10 points or so. That’s cumulative. So if you’re working on three things, you’ve dropped your general IQ by more than one standard deviation. Probably not a recipe for quality work. Focus is one of the core Scrum values, and let’s always remember that the rugby term “Scrum” was intentionally chosen to invoke the image of a whole team, arms interlocked, moving one ball forward in the same direction at one time.

Gerald Weinberg’s data on context-switching gives us some estimates to do advanced napkin math. From his findings, individuals in software development teams, when assigned to two tasks, have about 40% productivity per task. Combine the two, and that person is working at 80% of their normal productivity. By assigning a person to 2 tasks instead of 1, we’re already losing 20% of our ability to context-switching.

By the time we’ve divided one person to 4 tasks (and they’ve dropped a few IQ points) we’re losing 60% of their productivity. What does that look like in terms of real dollars? Average developer wage in the US is $96K and change. If we wanted to get more specific, we’d take into account healthcare and other non-compensation benefit costs, plus the value-added percentage of development. Where I’ve plugged in $100K as developer cost, you could easily use $150K or $200K and still be realistic. With our over-burdened developer working on 4 tasks, we’re literally lighting $60,000.00 on fire.

“It’s not about the money. It’s about sending a message.”

(The message is “we’re causing our own problems”)

This cost is real. It’s concrete. And it’s multi-dimensional. The costs of context-switching show up in dollars, time, productivity, flow, clarity, focus, priority, visibility, transparency, simplicity, predictability, stability.

And human happiness. Both your team’s and your customer’s.

Edit: I just ran into a great example of the costs of context-switching, where the cost wasn’t even offset by valuable work. Just by having multiple projects live, I have to switch between them “to see what’s changed”. With lingering projects, often the answer is “nothing”. Which means probably an hour of my day is spent just bouncing between different project boards and looking for hints of change, so I don’t get caught flat-footed. This time is a dead-weight loss.

Quality Software Management: Systems Thinking: Gerald M. Weinberg: 9780932633729: Amazon.com: Books

Cost of Exit is a Cost of Entry.

Steve Hallman — Sun, 18 Apr 2021 18:25:06 +0000

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.

I heard this listening to Penn Jillette relate his experience talking to the leader of an FBI SWAT team. He asked why the rubber doorstop was so important that it deserved front and center pocket placement.

“We go into a lot of rooms with risk and uncertainty. We want to make sure we can get back out.”

Question : What are the implications of this principle in software development?

“Feature” is Ambiguous.

Steve Hallman — Mon, 08 Mar 2021 22:22:56 +0000

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

Steve Hallman — Tue, 19 Jan 2021 19:08:06 +0000

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.

A challenging statement. Kanban is failure.

Steve Hallman — Tue, 28 Jul 2020 16:27:54 +0000

Just heard this quote on a webinar today about Lean and Theory of Constraints. I found it fascinating and challenging. Tell me your thoughts in the comments:

“Kanban is an admission of failure to achieve one-piece flow”

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

Steve Hallman — Tue, 21 Jul 2020 17:24:41 +0000

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

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.

Steve Hallman — Fri, 10 Jul 2020 22:13:03 +0000

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.