Thursday, August 27, 2015

Singh's Inevitable Avoidance Principle

Asshok Singh, in a post on Linked In, spoke deep wisdom in these words

...when people are not able to solve organizational problems, they come down to tweaking the framework to accommodate the dysfunctions. 

I dub it Singh's Inevitable Avoidance Principle. Let it be noted.

A Little Context

The forum question where Assok Singh uttered the IAP was answering the question "Why do we have sprints instead of just working one story to completion at a time?"

A great question. Why, indeed?

Working on one item at a time requires teamwork, as indeed all Agile methods are intended to do.

But working on groups of features is more palatable because people can divide up the work individually and defer learning how to deliver as a team. Giving up the "solo ninja programmer" is hard for some people, as frankly most of us are introverts and a few are genuinely anti-social.

If your team is full of people who hate working together, they'll want at least one task available per person at all times. Singh's Inevitable Avoidance suggests that we can avoid solving this problem with a tweak -- so load up the sprint with a lot of stories, maybe a few per team member.

It's even more palatable to managers because with many tasks in flight, they can have different tasks assigned or self-assigned to different people and hold them individually accountable. That kind of thing is hard for managers to let go of. Sinhh's Inevitable Avoidance again comes to the fore, and we allow that within Scrum sprints.

Of course, avoiding or preventing teamwork is entirely anti-agile, but this is what Singh's Inevitable Avoidance warns us about.

One Story Makes Sense

Working on one story to completion at a time is a much better idea, provided you do the most valuable part of the story first and work as a team, and let the PO choose when you have 'enough for now.' That's the point behind story mapping and thin slicing.

Even within a time box it makes sense to work one story to completion at a time, most-important first, so that if any work is left over at the end, it's the least important thing.

Mob programming is the other technique entirely compatible/orthogonal with Scrum or Kanban or XP, by which teams work an entire story to completion. It's pretty amazing stuff.

Pairing, Mobbing, 3 Amigos, story mapping, story splitting, ... there are many features available in modern agile methods that make Continuous Delivery possible and improve team focus. Of course, people inevitably will avoid them.

Take Back Agile

I've been conversing with others who have the same sense of Take Back Agile and a few whose sense of departure from non-agile "agile methods" are a bit more pointed.  I think that recognition of Singh's Inevitable Avoidance may become the centerpiece of the movement.

Maybe. We'll See.

Tuesday, August 25, 2015

An End To Dueling Strawmen?

I'm not the first to ask this, but here is a suggestion:

Let's end the nonsense of straw man arguments in agile discussions.

I heard it again today:

"I don't see Agile as a silver bullet for all software development problems in the world." 
Of course you don't. Nor do the people you're arguing with/against. Nobody believes that switching to XP or Scrum will make everything trivially easy and prevent every kind of design issue or organizational dynamic or schedule interruption possible.

I think we can drop that rhetorical device now.

Next steps when most people use that device tend to be:
* reject the insufficient miracle ("if it doesn't do everything, we shouldn't use it")
* take a piecemeal view ("if it is not everything, then integrity of the parts is unimportant")
* use it to declare their superiority ("I am not the fool that you are")

Let's not understate the depth and integrity and value of a thing just because it's not perfect.

But let's not stop there. Let's hit up the agilists for a favor too...

Not using & supporting agile doesn't mean that your opponent supports the worst dehumanizing death marches that waterfall has to offer.  Offering "well, it's better than waterfall" is an equal and opposite straw man argument. Nobody desires a bad waterfall implementation with brutal management and enslaved developers. That was never a goal, even though (in agile and waterfall implementations) it sometimes has happened.

I think both of those mechanisms are tired and trite and unconvincing. Most of us in the business have been through the argument dozens of times.

The world is much bigger than a simple process dichotomy.

Can we put the straw men down, walk away from arguing, and get back to trying to understand and help each other now? 

Monday, August 24, 2015

Product Owners Maximizing Value

The Product Owner is responsible for maximizing the value of the work done. Check out this list of responsibilities from the Scrum Guide (2013):
  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what
    the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level
Optimizing value is a funny thing to think about when does "value" even mean?  

To an industrial-age mindset, "Value" correlates to "Output."  If I make seventeen yachts, I have more to sell, and then potentially make more money than if I have three. 

If I have twenty features or stories or jobs done, then theoretically I make more money, and thereby have maximized value. 

This is doubly-strongly reinforced when you are hiring staff augmentation to create a pre-planned feature set which was determined (complete with end date) before the contract took effect. It seems clearly that "reaching the milestones" and "getting the most for our contracting dollar" are maximizing value. 

The role of the Product Owner must be, therefore, to wring the maximum output from the developers on the teams assigned to his/her product. 

Except that it doesn't work that way in software, and that wasn't what was intended. 

Given a development team with its current skills, headcount, tools, and process, you will get a more or less the same amount of output per any given period. The only way that you can change that number is to change the factors that go into it. New, useful skills will allow more to be done. New, useful tools will allow more work. Useful knowledge will increase speed sometimes. Reducing the causes of friction, wait states, and other wastes can speed the process. 

However, all of these are things a PO is not allowed to do in scrum. Remember:
  • "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality" -- The Scrum Guide 2103
It sounds to me like the team can't be driven into practices or demanded to violate sustainable pace or any such thing by the PO.
The PO has no mechanism to maximize output. 
So how is the PO to "optimize value?" 

It seems that the trick is to divorce "value" from "output." It's not HOW MUCH, because that's governed separately, but HOW MUCH DIFFERENCE IT MAKES to the users.  In other words, it is by considering outcomes instead of outputs.

If we only have 13 idea days or 13 story points or 13 gummy bears to work from this sprint, then what is the best 13 we can work on? What will teach us the most? What do we need feedback about soonest? What will 
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what
    the Scrum Team will work on next;
From here, we can look at thin slicing, story mapping, and options .. but I leave that as an exercise for the graduate student.

But the take-away here is that the PO isn't to drive the team to maximum output (he's not the Development Team Owner), and lacking that ability the PO instead steers the product to the best outcome possible given that the outputs are going to be roughly the same.

A secondary take-away to consider, though: shouldn't the PO leave enough capacity unclaimed to allow the development team to improve their tools, knowledge, skills, and process so that perhaps more output might become possible in the near future? 

Thursday, August 13, 2015

(Revisionist) History of QA Departments

The things that pre-agile managers know about managing software mostly comes from contractors and consultants.

In the old days, military/government contractors were the gods of management.  They had huge development staffs, rigorous procedures, colossal budgets. Those where the people to watch. Everyone wanted those staffs, those projects, those budgets.

QA and Development were split. Development was owned by the contractor, and QA by the customer.

Sometimes the contractor had their own QA people to help assure that their product would pass the customer QA process.

The customer's QA was focused on proving that the contractor had not finished the project, and so they don't need to be paid yet.

The goal was to PREVENT COMPLETION of the contract and delivery of the code.

The contractor's developers and testers argued that they did indeed fulfill the terms of the contract and should be paid post-haste.

Of course it was important that the contractor/developers did not know what tests were going to be performed, else they would write code to pass those tests and get paid for doing the minimum.

The threat of not being paid for on-time completion was supposed to scare the contractor into making EVERY ASPECT of the code as perfect as possible, and supposed to make them sweat every small detail that might end up in a client-side test plan.

The next step is typical of cargo-cult behaviors in our industry; if we copy easily observable behaviors of successful people , we will be successful too!

In due course, adversarial QA was considered good management and seldom questioned by professionals. It had crossed the line from "common practice" to "moral imperative.

I think the "separate, independent QA" practice has outgrown its useful context by several decades.  Nowadays we want organizations to enable completion and delivery, not prevent it. We're not building software on contract for people who want to avoid paying us, we're partnering.

The new model breaks a lot of old, broken traditions. Good.

Wednesday, August 12, 2015

The BS Line

Consider that everyone has in their mind a fuzzy line:

On the left side of the line is what we like to call "the real work" (abbreviation: RW). It's what we get paid to do. It's the value we provide to the world. It is usually about 30-40% of the work we do, which pays homage to Gall's observation about the inefficiency of human systems.

The stuff to the right of the line is what we call "bureaucratic silliness" (abbreviation: BS).  It is the stuff we have to do in order to satisfy the internal "process police."

There is always some hoop-jumping and nonsense that we have to deal with because that's the price of being a developer.

The Difference

We tend to take on Real Work happily and go right to it. It allows us to practice and pursue the skills that define who we are in the workplace. They further the goals of the company, the customer, and our career ambitions (if any). They are why we come to work.

The Real Work directly adds value to the products we make and to our colleagues with whom we make it.

The real work is what we "get to do."

The Bureaucratic Silliness is assigned to us, and we are obliged to comply. It does not further the useful skills we value, but may require us to build additional skills and habits in order to fulfill expectations. The BS is a set of formalities that do not provide value to us or to our teammates, though some of it is valued by the business.

The BS is what we "have to do"

How to Tell

Nobody loves filling out timesheets, but we're expected to account for the time, so we'll get around to it.  We tend to delay BS in hopes that we'll run out of time for it, which is fine since the Real Work is done.

So don't ask us what we value. We may give the "acceptable face" and say "yes, I know it's important, but I forgot" or "I ran out of time" or "I'll get to that right away." We will tell you how important the standup meeting or the documentation are.

Instead, look at what we dive into and what we avoid. We will order our lives and our days by the things that give us a sense of value and purpose. The things we put off are the things we don't really want to do; we put off the BS.

So What?

Which items are on the left (RW) and which on the right (BS)?

  • Testing 
  • Code reviews 
  • Collaboration
  • Integration 
  • Delivery/Deployment
  • Documentation
  • User Feedback
  • Bugs
  • Expense Reports
  • Time Reporting

You might be surprised to find out which items are on which side of your line, and what/who keeps them there.

If your people are racing through the code and then doing code reviews and testing after, then you know that coding is RW to them, and the rest is BS that they are willing to sacrifice.

You can try to convince them, or demand more obligatory compliance, but you'll always find that until something has alignment (provides value for everyone) it will be at best a nuisance to the people who are trying to do the Real Work.

Friday, August 7, 2015

Write Me An Online Agile Tool

I would rather work with physical tools than online, but frankly my own team is highly distributed and so we sometimes need to be able to visualize and communicate our work. Rather than complain about how awful all the online tools are (and how badly wrong default configurations are) let me describe what I really want:


Backlogs are about 80% nonsense. I don't plan all the work I'm going to do. We have found that we are better off if we just do the most important slice of a thing today and get it live, rather than plan how long "the whole thing" would take. We are frugal with our time and investment, and frankly our features need to be validated in production or we don't know that they are really good ideas at all.

Don't treat our backlogs as promises and commitments. They're just a waiting list of things that we might want to do sometime. It should be easy to add/remove.

By the way, you should probably warn us if we have a lot of things in our backlog. Maybe add a WIP limit and warnings to the product backlog. There are real issues and very few advantages to having several years' worth of stories entered into the "backlog black hole." 


The most important thing about a story is that it has a title people recognize, and there are a cast of characters who may be working on it.

The easiest things in the world should be to split, combine, and delete them. 

Deleting stories is especially important, because that's where most of our cost savings comes from. 

Splitting them is where value delivery comes from, so that that should be trivial and not a horrible series of clicks and context switches. Split one into two duplicates and let me change the text as I like. 

We don't need to have the explicit ability to enter estimates or actuals into stories. We might want to track lead time and/or cycle time, though. It might be nice to see how long things sit in a non-Done column before being completed but that's mostly for the team's retrospectives.

Finally, we should be allowed to add text and adornments as we choose. We shouldn't be locked into a specific pre-defined set of fields. Think more about "document" than "row in a table."  Each story may have unique information and unique marks on it, and the inability to scribble and add stickies and colored marker text/drawings is the primary drawback to using an electronic tool instead of a physical system. How flexible can you make the content and display? 


One person shouldn't assign another to anything, and we should never have names or faces attached to work we are not doing yet. Agile isn't about crushing "promise debt" and individual measurements. In fact, drop all of your individual contributor metrics. 

In particular, realize that we form, reform, un-form, and reconstitute people-per-job all the time. So, let us have images of our faces as tokens. Let us drag our faces from one card to another in the card wall. When a job is complete, return our faces to "available."

Never limit the number of people on a job.

Moving from job to job should be an absolutely trivial gesture instead of a tedious job of opening jobs and "assigning" and "un-assigning" ourselves. 

Terminologically, we don't "assign". We "join"

Swim Lanes

Never make it easy for anyone to create per-person swim lanes. Those are a pure evil.

Per-story swim lanes are iffy. People do tasking in such a way that they could have 80% of a story done, but nothing to show for it. We prefer teaching/learning slicing (in CD sense) so that the code always runs and can always be deployed. Having per-story swim lanes is an iffy practice. 

Class-of-service swim lanes seem to me to be a good idea. At least I've not convinced myself that it is not. It might be useful to have "Expedite", "Normal", and "Simmer" swim lanes. Consider that.


I know that it sounds crazy, but how about less of these? I'm not a huge fan of burn-down and burn-up (because they assume that the plan is too important). I would love to see cumulative flow diagrams, and cycle time charts of some sort, and maybe some work on traceability between requirements and code.

No individual ranking reports of any kind, ever.  No "work by person." No "top contributor." This competition between developers on a team has to die. You only have a great team when all the threats are external. Defending against each other degrades team performance. Threat and assessment kills pairing, mobbing, swarming. Don't let the system become the threat that they defend against.

No team-comparison charts.


I would love to see this tool have good integration to my

  • source code control system  (git)
  • build system (jenkins) 
  • test frameworks 
  • code editors (vim, intellij, eclipse, vs, pycharm, etc)
  • messaging/chat system (slack, mostly)

In other words, I would like it to integrate into my life, instead of being "a web somewhere that I have to navigate to and do data entry".

Final Words

Would I use such a system? Probably so.
Would I prefer it to a physical card wall? Maybe.
Would I recommend it over the more comprehensive tools available today? You bet I would.

Thursday, July 23, 2015

The #NoEstimates Hashtag

I'm not writing about #NoEstimates today, so I recommend the writings of Vasco Duarte, Neil Killick, Woody Zuill, and various publicly-available videos for that.

I'm only writing about the arguments that we see around the #NoEstimates hashtag itself.

Why? Because I think that the hashtag has been a great promotional device, but with some drawbacks. Hopefully by discussing this now, I can be guided to make intelligent choices about any hashtags I decide to create in the future.

The success of the hashtag in drawing attention is great. Heck, a lot of people are already sick of it.

Having recently experienced some of the argument recently after appearing in a podcast (see "poo-shoe effect"), I have a few observations:

  1. Arguing the literal hashtag will get us nowhere.
    When you want to talk about a thing in an online community, you have to have a searchable name for it. For better or worse, #NoEstimates is the term. We can argue how apt or unfriendly it is, but that ship has sailed.  It is the name that you use in Google (or the like).
  2. It's not a debate.
    In a debate, there is a motion or proposition (rule #1), and the debaters begin by agreeing on the motion and the definition of terms. Then come pro- and con- arguments about the proposition.
    Most of the #NoEstimates arguments exist because every attempt to reach an agreement has broken down.
    Either the people or the topic are not ready for a debate.
    Rather than two sides of a single issue, we seem to have a variety of different people with different experiences and thought processes and intentions.
  3. The most hotly contended part? The first two letters of the hashtag.
    It says "No" and there is confusion over what that mean. blog's subtitle is "Settle down, it's just a hashtag" but apparently it seems to be much more than that.
    Is it a command? An observation? A preference? A hope? A moral imperative? A war cry?Just a hashtag?
    Does it mean "WE DO not use estimates" or  "YOU MUST not estimates?" 
  4. The other hotly contended part? The term 'estimates'.
    Does this mean that you never do any kind of sizing, estimating, or forecasting?
    When you decide "small enough to do today" isn't that estimating? What kind of estimating are we saying NO to/about? What kinds are we not doing?
    If we do any kind of forecasting, guessing, or sizing does that make the entire "movement" a lie? 
The above are pretty much the soul of controversy. There is always a swirling word-cloud of confusion about it, and I think we can't look to the hashtag to fix it. The hashtag is a term in a context and its meaning must be contextually decided. 

I propose that those who are working in "estimate-free" models are the only ones must provide a definition that will unify the ideas and build a proposition that can be debated.  

But until then, I suggest that we pick through the links to articles posted under the #NoEstimates banner (pro, con, or neutral) and look for the ideas behind the tag. Merely arguing one interpretation of the tag over another is getting us nowhere.