Human OS, Stupid and Lazy, Leadership, Story Scope

Upgrade to the Human Operating System – BusinessWeek

I read this article, and it seemed to me to say for organizations in general, what Agile has done for software development teams.  Moving from a command and control – process/factory model, to a model that allows/incents/expects humans to invent, analyze, innovate, figure out.  Is it possible that we are finally ready to tranform organization structure from its industrial age roots into an information age – service orientation.  How many organizations say “our people are our most valuable resource” – but act like they have FTE’s – (HR/Manager speak for “universal man widgets”). 

Seth’s Blog: Stupid and lazy

I highly recommend that you evaluate every difficult thing that is on your plate, and decide whether it is lack of talent/skill/knowledge or simply lack of motivation that is getting in your way.  I hate this evaluation, because it always comes out the same.  Arrgh! 

Seth’s Blog: The difference between management and leadership

This short post was a huge shot in the arm for me this week.  Management is about constraints, leadership is about movement.  Movement and constraint are opposing forces.  Dang!  Now that I am not in a staff management role (first time since ’04) this is much easier to see.

Stories, Epics and Themes | Mike Cohn’s Blog – Succeeding With Agile®

Mike Cohn is pretty much “the man” on user stories.  I have had conversations with lots of agilists about stories epics and themes (story scope).  What nobody (including Mike) really wants to get into is whether stories are about business capabilities or software capability.  IMHO – when it comes to “requirements” for software – everything (not just agile) craps out on this divide.  And it is a critical division because all the value is on one side, and all the work is on the other.  Hmm.  Never the less – I thought this was one of the best posts on story scope I have read in a long time.

Local Optimization

I am clearly aggravated. I have been for a while, and I finally understand why.

In the world of systems thinking, it is called Local Optimization. That is where, in a multivariable system I optimise for one variable at the expense of other variables, and subsequently reduce the overall output of the system.

In more understandable business terms, I am optimizing one or more of the means, without regard to the “ends”. As my seventeen year old son put it I am maximizing one benefit without regard for the overall goal.

In organizational management, in a business with multiple business entities or sub-units – we are trying to maximise the profit of each entity, rather that maximising the profit of the whole. In process optimization, we talk about optimising throughput of one subprocess, without regard for the throughput of the whole.

Here are some examples that should resonate with everyone:

1) I spend so much time working to earn money, that I don’t have time to enjoy my wealth.
2) I build an educational system optimized for a specific metric (standardized tests) but have not taught my students how to learn independently.
3) I construct a business enterprise optimized to grow the stock price quarter by quarter, but do not produce anything of value.Continue Reading

Planning Bug Fixes

Jason Yip posted recently about scheduling bug fixes. I liked what he had to say. He is a very thoughtful person. I wanted to extend his thoughts with my own…

1) Fixing bugs is unpredictable – you never know how many you will have or how long they will take to fix.

Defects in delivered code fall in to categories:


  • non-working new capabilities
  • usability issues
  • collateral damage to surrounding code

If your goal is to have a quality product, there is no way to prioritize these apart. They all need to be addressed. So this taxonomy or similar taxonomies usually do not give you reasonable leverage for prioritizing defects.

2) Usability issues can be prioritized based on time, risk and frequency

usability issues may be deferred:

  • if the usability issue does not add unacceptable business risk.
  • if the usability issue does not add an unreasonable amount of user time to a business process.
  • if the usability issue does not affect a frequently used feature or path that would generate an unacceptable support call volume.

3) Defects can be caused by poor code design, or less thoughtful implementation

Sometimes, the problem is that the new capability is not adequately supported by the current design. The developer ended up playing whack-a-mole with the issues because he couldn’t quite wrap enough duct tape or baling wire around it to get it to stay working. Sometimes the prior releases duct tape needed to be re-wrapped.

Other times, the problem is that the developer simply didn’t think through the implications of his design pattern or understand the usage scenarios deeply enough so his design was simply inadequate.

Still other times, the implementation was just plain sloppy, so it passes the happy path scenario, but fails most alternates or edge cases.

These defects all mean that the fix may take as long as the original implementation of the capability to correct. They can result in a story getting backed out of a sprint if they are found late.

4) sometimes the source of the defect report is an important determinant of priority.

Defect reports from key users or evangelists tend to get prioritized above those of testers or non-savvy users. Sometimes also defects reported by users who are know to have the ear of management also get prioritized, as a noise limiting mechanism.

5) Assuming all bugs reported represent defects. Sometimes testers and users report how they “thought” things would work or should work.

Many times a validation is necessary to ensure that all reported bugs are really defects. Sometimes reports are simply enhancement requests masquerading as defects. Other times the tester simply mistook a working feature for a defect because of how they had envisioned it working, or because they assumed (untrue) things about the solution. Often these types of defect reports are an indication of counter-intuitive design, other times they are just wishful thinking. We need to be very careful about working on these defects as they can add uncommitted scope to a sprint, and can add risk to the committed scope via collateral damage.

6) When you have enough time and resources, prioritization is not necessary.

The closer to the completion of a feature the testing (and bug reporting) is executed, the less prioritization is necessary. When testing is done the “day after” the feature is complete, we often have the luxury of working on defects in sequential order. When testing is done days or weeks after the feature is complete, we can end up with more defects than we can fix and a larger completed codebase to re-engineer if the defect is related to a design issue. The opportunities for thoughtful re-design are often long past, and we end up wrapping duct tape and baling wire around the feature to fix the defect. This is one way we accrue technical debt. Perhaps the sequence of our testing and user feedback activities relative to our development activities is as or more important to manage than the sequence of our defect remediation.

[Curation #3] Competency, Principles, Hiring, PM101

Want to be strategic? Be competent first | Adventures in IT – InfoWorld

Provocative post about walking before you run.  If you can’t execute, your strategy will not help.

Agile Complexification Inverter: What are the Principles?

I like this way of thinking – principles first, because it helps us stay out of “methodology” land.  Too often, we are looking for a “prescription”, rather than ways of thinking that help us solve problems that are impeding our progress. 

How to Change the World: What I Learned From Steve Jobs

Best bit: A players hire A+ players….  – Avoid the bozo explosion.

Herding Cats: Are We There Yet?

Project management 101 from Glen Alleman. 


Culture of Duz

A while back, Ester Derby posted in reaction to an email advert for a leadership workshop – about how to counter the “culture of entitlement”.

She reacted somewhat violently to “leaders are constantly frustrated” by this. She implied or stated that the leaders who are frustrated are somehow responsible for the culture.

So I have two reactions to her post – the first a “have you considered” that the leaders referred to may be many pay grades below the senior management level that value having the corporate logo on the “best places to work” list, HR policy makers that require months of high intensity documentation before they will consider a termination, and an IT staffing policy that has changed dramatically as work has moved offshore, and back onshore, and capital and expense budgets and policies have adjusted to regulatory and market changes.

As a non-manager leader, I have often been frustrated by the availability of willing and able resources on initiatives that I am driving, getting a “do the best you can with what we have available” from the staff manager.

As a manager of small teams, I have often been frustrated by a small percentage of staff members who accomplish just enough to avoid the bottom of the list, but are generally the most difficult to work with, and aggravate the remainder of the staff, while they are working the system for special accomodations. It is worse when there is a good ol’ boy network to which the individual is juiced into, being patronized by some mucky muck executive, 5 levels up and 3 organizations removed horizontally…

Ester, you say that all of this can be resolved by simple conversation and I agree, it is simply much harder than you may want to believe to determine who needs to participate in the conversation, let alone to get them to the table.

My second reaction is that each leader whether via influence from within a team, or from a position of authority contributes to the culture of the organization, and is in some way responsible for that culture. So as a leader, one must reasonably assess the capacity of people and what they might need to work up to their capacity or how they could expand their capacity. Having done this, we may be positionally able to direct them toward these goals, or work toward the same effect by earning their trust and using that as a lever of influence convince them to adopt these goals for their own benefit.

Curation Collection #2

“Q: What change models work? Q: How ot be agents of change? (as coaches)” This was an insightful list of questions related to enterprise agile adoption.  I like questions because they are less likely than answers to lead to one-size-fits-all-suits-none solutions.

I like the cult of done.  I like the manifesto – I posted the poster included several places in my workplace.  Good reminder of why done is important.  “Done is the engine of MORE!”

An interesting look at the way that the “power culture” of an organization interacts with agile adoption strategy.  When your organizational culture has a high power index in the large, then every reorg or management change presents a challenge to agile adoption.  “When I see organizations with a high power differential, they keep falling back to command-and-control approaches, because the power differential is so ingrained in their culture.”

Interesting look at product from a VC perspective.  Caused me to ask how people see me as a product.  I work inside “the enterprise” I am not marketing product to VC, but I constantly market myself to others.  “CHICKEN LIVE IN CAGE. NO CAN HAVE PERSONALITY INSIDE CAGE.”  — smash cage, light barn on fire do that you win…

 – @paul_boos @bre @johannarothman #grimlockquotes

Ancient Business Books that I have learned from

OK – so everyone should know that I am “the old one”.   I have a couple recommendations for books now out of print that were business oriented, but that I frequently hear blog advice that reminds me of things that I learned 20+ years ago in these books.

Today Seth Goding posted Expanding the Circle of Missed which reminded me of a sales oriented book that has basic work wisdom going way beyond the domain of sales called “Winning Through Intimidation” by Robert J Ringer.

WTI is a book about making yourself appear essential to whatever business endeavor the people who pay you are conducting, thereby securing yourself a paycheck, pay raise, promotion, or closing. 

The other ancient text is called “How to Work for a Jerk” by Robert Hockheiser – which is a great text on management antipatterns, and how individuals can work successfully in light of office politics and poor management.

Both of these books were written before the current political correctness fetish – when things and business culture were much different.  However human nature has not changed much in 4000 years, and so while we all wear the mask of sensitivity and diversity, the thought processes going on behind the masks are little different than they were 20 years ago. 

Both are now out of print, but can be found in libraries and used bookstores and are worth the read.  Both are written in a humorous, tounge-in-cheek style using lots of stories and allegories that make them easy to assimilate.



Pragmatically Agile

In a conversation recently, I was reminded how being agile is awfully like being pragmatic.

We were talking about topics of interest to project managers like estimation and forecasting and measurement.

One of the topics discussed was about grooming the backlog, and backlog sequencing strategies: Walking Skeleton vs. feature by feature? Do you build just bones, and then add the skin? or do you build one complete body part at a time.

Another topic was about “sprints as phases”: requirements works a sprint ahead of development, testing works a sprint behind – this strategy might work for a longer duration effort (many sprints), but not as well for a shorter duration (4 or less) – it might drive you to more shorter sprints than fewer longer ones.

Yet another topics was about planning margins or slack. Budget or Schedule margins are not on the surface agile concepts, but when they are valuable or necessary risk management tools, they must be implemented in ways that do not interfere with measurement. A budget margin implementation means that I have the ability to spend more but stay on schedule. Pragmatic strategy for that is to overstaff at the beginning, and reduce staff as velocity stabilizes as sufficient, and risk is retired. Adding staff in the middle of a project decreases the stability and predictability of the team.

Our last conversation was about choosing a sprint length. Sprint lengths should be consistent – so that the measurement (velocity) is useful for projection. Sprints should be immutable – once a sprint is started, it cannot be shortened or lengthened. If there is a need to have “variable” length sprints then a shorter consistent measurement period should be adopted (weekly) so that the feedback loop doesn’t elongate. Last, the shorter the overall project, the shorter the sprint size – again, so that the feedback loop is timely enough to make adjustments.

There is no one right way – just ways that make more sense and ways that make less sense. We all learn more from failure that we do from success – but using a framework that fosters timely feedback and rapid adjustment provides ability to see failure coming and get better faster.