September 2011 – In Search Of

Inaugural Curation Post…

Posted on September 30, 2011Leave a comment

This week I am making good on my intent to post some of what I’ve been reading and found valuable.

agile42 | Feature Injection Applied to Service Delivery

I spent a bit of time reading about Feature Injection as a different way (than other agile processes) at dealing with requirements. I really am intrigued, and will try to adjust my requirements practice to include these concepts.

Do You Suffer From Decision Fatigue?

This also was interesting – as it clearly reflects what we all experience – decisions take mental energy, and making decisions when mentally tired is sub-optimal. One could infer from this how to re-arrange one’s schedule to make better decisions, or to be less mentally tired when decisions are needful.

Time to ditch “The Backlog” « The IT Risk Manager

This also was provocative – not because having a backlog is a bad thing, but because how we name things allows others to infer things from the connotative meaning in that naming.

Calamity howlers & positively selecting with surprise « Freckle Time Tracking

A “calamity howler” (CH) is a persistently negative individual who predicts rack & ruin, frequently and at the top of his voice. It’s a great term that was especially popular in political writings back in the mid-to-late 1800′s but has since fell out of disuse. — who is the CH on your current project or in your current team.

Emergent Vs. Inverted Thinking

Posted on September 27, 2011Leave a comment

In agile communities developers, project managers, testers, there is a phobia or paranoia about big ANYTHING up front – that is we should not spend more energy up front than is absolutely needed to get the committed stories/features done in the next iteration.

The concept that we use is emergent thinking. Requirements emerge as we bootstrap our thinking by delivering early features. Design emerges, as we build features that have similar needs, and we refactor towards opportunities for generalization or re-use. Plans emerge as we estimate and sequence the stories in the backlog.

So what happens when the requirements don’t emerge. When the design doesn’t emerge. When it feels like we are just skating on the surface, because there is too much fear of bigger change, or spending energy building anything now because it will all change in 3 weeks. When the product owner is unable to sequence the backlog because there are unmade business strategy decisions that are inhibiting the emergence of plans, requirements, and designs.

I use inverted thinking. It is the opposite of big anything up front- I envision a result (it doesn’t have to be the right result) and I build a plan to acheive that result. I work backwards from a conclusion, as if my decisions were made. I propose a design (as thin as possible) that I think will support the envisioned result. I build a plan (as thin as possible) and propose needed skills and resources.

I pretend I know everything, and when I need an answer, I make one up. But every answer I make up, I list as a decision – because that is the schedule I want. What decisions need answers in what sequence, by what date, and what deliverables are dependent.

Then I dare every stakeholder to tell me why my proposal (that I just completely fabricated out of BS) is wrong. If you can’t give me a good reason not to do this, we are going to move forward in this direction.

When the fear of making a wrong decision is inhibiting the emergence of requirements, plans and designs – Invert the thinking from “What should we do?” to “Why shouldn’t we do this?”…

…and watch decisions emerge.

What is up with This (Blog)?

Posted on September 22, 20112 Comments

So I want to talk a bit about this blog and how I have been doing it and something that has changed the way I will blog in the future…

**Personal Stuff**
Most of the posts on this blog have been born out of my own experience – both good and bad.

This blog is not widely read. I probably get a couple dozen page views on each post. I don’t actively promote it. I have tried to post at a consistent, sustainable pace. I try to write and refine about 4 weeks in advance, so that I don’t feel pressure to get stuff out. Most of my posts are written as I ride the train to and from work. I spend about 35 minutes each way, and try to write about 3 posts per week.

I struggled to get out a post or two per week, because things at work were not producing the kind of frustration that induced learning or analysis. I have been reading the same techie and management blogs for the past few years (Fowler, Foster, Alleman, Rothmann and a few more… ) Occasionally I would post a riff or a reaction to something these guys said especially Alleman, but… Sometime around the end of July this year, I re-engaged on twitter. Still not sure why, or what actually prompted me to go there, but I did. Wow – I found that there was a whole bunch of people who write the same kinds of things that I write (and much better). It is always amazing when I find others that think like me.

And so where before, I did not have a source for inspiration (except my experience and the scripture) I now read a couple posts every day from folks that I follow on twitter. So I decided that I will publish links and commentary on the stuff that I read and like on this blog. These posts will likely be much shorter than my “regular” posts, just a link to the other post, and a few thoughts.

You can follow me on twitter if you like, I am @regenerateweb.

**Technical Stuff**
I use posterous.com as a blog host. I like it for several reasons:

1) it has an e-mail interface – so I can send an e-mail from anywhere to post – this became a requirement because I wanted to be able to post from my blackberry which does e-mail really well.
2) it automatically connects with my social networks (facebook, twitter) and lets me autopost to them.
3) it lets me schedule posts in advance so that I can get ahead.
4) it supports some custom theming – which I might do when I get 20 free hours. but has enough basic themes so I can pick one that is not too obnoxious.

I use a note taking tool called ZIM Desktop Wiki. It is extremely simple, but lets me maintain hyperlinked notes – so that I can make a “page” related to a topic, and make links to those pages there, so I can organize my posts. Also, using the wiki metaphor, to make a new page, I just create a link and click it and a new page is created.

Competency Vs. Excellence

Posted on September 20, 2011Leave a comment

We can train people to be competent, but excellence is a result of an individual being given the freedom to make mistakes, to learn, and truly incented to grow without fear of retribution – not without accountability but without loss of reputation. Excellence develops when an individual recognizes his own adequacies and inadequacies, and is willing to grow by following, learning, and failing.

If “Failure is not an option!” – then the best you will get is competence.
If you must “prevent them from making mistakes” – then the best you will get is competence.
If the following the process is more important than developing the people – then the best you will get is competence.

Product Owner Excellence

Posted on September 17, 2011Leave a comment

What makes a product owner excellent? Is it subject matter or domain knowledge? Is it discipline around following the rules of the delivery management practice? Is it ability to elicit value propositions from or to sell value propositions to stakeholders?

In my last post ProductOwnerTraining – I listed out a set of core activities that product managers do. I think being able to perform these activities makes a product owner competent. I think that for someone to excel, it is not necessarily expressed in what they can do, but how they do it, or even in how they think about doing it.

I think for a product owner to excel, she must have the ability to produce a long term vision for the product, aligned with organizational vision and strategy. She must also be able to abstract meta-value propositions, like the ability to extend the product along certain axes (new client types, new reports, new process variants) without drama, or even without development effort. She must be able to see not only the visible skin of the product, but aspects of the framework around which it is built, so that she can speak, not only to what product capabilities are valuable, but what framework capabilities are valuable as well.

Product Owner Training

Posted on September 10, 2011Leave a comment

How do you develop the mindset and skills needed to be a successful software product owner?

In a technology organization, (software vendor, tech startup) product owners tend to come out of a technology background. They are ex-developers, ex-architects and sometimes ex-sales engineers.

In a non-technology enterprise (a normal company) the product owner is more likely to come out of a business background. In client facing software products, that background is likely to be marketing or business product management. For internal facing software products that background is likely to be that of a business practitioner, or a business analyst.

Regardless of background, product owners need to be able to do the following activities:

organize stakeholders into specific communities based on desire for specific value delivery.
sell the existing value propositions of the product into the stakeholder communities.
elicit new value propositions for the product from the stakeholder communities.
distill problem statements / value deficiencies from specific feedback from stakeholders.
maintain a prioritized/sequenced backlog of deliverables, contemplating the sponsoring stakeholder community, value proposition and business strategy.
sell/explain business value propositions to technical team.
evaluate whether proposed technology solutions add the value expected by stakeholders.
develop high level test cases for acceptance for each deliverable.

Maybe there are some additional things, but this is the core list. You can see that depending on background, some might gravitate to activities from this list that are more comfortable. Training product owners is about helping them grow abilities to perform outside their comfort zone.

A Definition of Done

Posted on September 7, 2011Leave a comment

In his Herding Cats blog, Glen Alleman, asks a very pertinent question. What is the definition of done? Well?

Done (Enterprise software delivery project) – when software capabilities have been delivered that support the business value proposition per the customer’s business capability requirements.

In our agility, we recognize that requirements are clarified by “emerging information”. That doesn’t mean that they “change”. When a requirement “changes”, it is effectively a new requirement. We often experience a case where the business value proposition is inadequately defined at the outset of the project. In this case, it is necessary for this requirement to be clarified by emerging information.

We also recognize that there may be different paths to deliver different software capabilities that support a particular business value proposition. Chosing a different path or delivering different software capabilities that support the same value proposition does not mean the requirements have changed, more likely that we are responding to emerging information.

I like to break requirements into business capability requirements and software capability requirements. Regardless of your project methodology you must contend with these facts:

Fact: Enterprise software projects are created to deliver some business value. The requirements should define both the value (business capabilities) and a path to deliver it (software capabilities). Requirements form the basis of the definition of done.

Assertion: If the business value does not change, there is not a new requirement.
Assertion: If during the delivery of the business value, we learn things about the domain, the technology, or the world external to the domain that alter the path to deliver the value – there is not a new requirement – but emergent information.
Assertion: How we manage the (the documentation of our understanding of) requirements is a method.

Fact: Some software projects are required to change course mid-stream. Sometimes the business value we initially intended to deliver is overturned by market pressure, financial impact, or a change in management or strategy.

Assertion: When the business value for a project changes, there is a new requirement.
Assertion: When the work done toward that value is abandoned, there is a loss.
Assertion: How we manage the (documentation and accounting for) change to requirements is a method.

—
Recognizing that there is a difference between allowing emerging information to clarify, influence, or stabilize the delivery of value and accounting for changes in the definition of the value stream for a project is key to understanding agile and how agile methods manage both cases.
—

In either case, the definition of done is when we have delivered working software capabilities that support the business value proposition(s) that have been “commissioned” by the customer.

Enough (as a damping mechanism)

Posted on September 7, 2011Leave a comment

In a recent post, Esther Derby describes a tendency of organizations towards oscillating between centralized or decentralized controls – I thought it was a brilliant insight in that she exposed that at the extreme reaches of the pendulum in either direction, there are evidence of lower performance, but for different causes. I have experienced this myself, but really never thought up the food chain to where these decisions get made, only about the local effect, and my own efforts to locally mitigate said effects.

In the article, it is suggested that centralizing controls tends to squelch innovation and creativity, slowing down decision making and reducing ability to maximize opportunistic growth, while decentralizing controls can allow decreased visibility, subunit goals to trump larger organizational goals and decisions that do not align with the mission of the organization. Both of these extremes tend to lead to lower performance, and so in reation to the downside of one extreme, we tend to lurch towards the other extreme.

Esther went on toward the need for feedback loops which would allow managers/management to detect and react to the pendulum and adjust to reduce the periods of lower performance induced by the swing.

What Esther is describing is a damping mechanism, like a shock absorber in your car. The damping factor is based on a target range of motion, and the further out of range the motion, the greater the damping force. As I thought about this, what is needed is a conversation about enough (a definition of sufficiency will be required) centralization or decentralization, and perhaps some discipline on sticking close to the definition of enough. Enough is the target range of motion we want to contain any oscillation between enough decentralization to prevent the loss of performance from those causes, and enough centralization to prevent loss of performance on the other extreme.

So the questions that management must be required to ask is:

1) How much decentralization of control is sufficient to prevent the loss of innovation and creativity in our workflorce?

2) How much centralization of control is sufficient to prevent the abandoning of corporate strategic vision for more localized goals?

I also think that this is a matter of establishing policies, aligned with rational management incentives backed by meaningful measures. This is where management usually falls down from my experience. Here are some management anti-patterns that tend to interfere with this process:

1) No measurement process is established, therefore the policy must be written in absolutes.
2) Policy is written and implemented in a “one size fits all” paradigm, which fails to contemplate how the policy might be implemented differently in different contexts to achieve a similar net effect.
3) Incentives do not go far enough down or up the management hierarchy, so the desired behavioral changes are not properly incented at the point where they are necessary.
4) Incentives do not align with the policy, creating a paper tiger – a policy that has no teeth – one that is paid lip service, but limited effort is applied because there is no perceived benefit to behaving differently. Draw a correlation between policy and compensation and you will see behavioral change.

Once we have overcome the management anti-patterns, then and only then do the feedback loops become important – because the necessary constraints and enticements are in place to ensure appropriate action when the feedback is delivered.

Esther promised a future post about feedback loops, and I am keen to read it, because she is typically very insightful.

Agile Estimation Sanity

Posted on September 2, 2011Leave a comment

Some of the things I read about estimation in the agile community appear to me to be insane. Story points and the reasons that they are the preferable unit of estimate is one of those things. Before you call me a heretic, and burn me at the stake for my blasphemy, and my castigating your dogma – hear me out. I simply don’t find any value in the practice of estimation using story points.

I want to start by stating some facts about software development and estimation.

1) There are no measureable units of output for software development. We have tried source lines of code, and function points, but they really are not a measureable unit of output, they are simply facts about the underlying software product. This is like saying that the number of nails I used (source lines of code) or the number of rooms (function points) is the measurable unit of output for building a house. Both are too variable (rooms vary in size and nails vary by job and practitioner).

2) We estimate using only Units of Input (the denominator) (Since we have no measurable units of ouput), so are estimates are neither repeatable nor generalizable. The input of software practitioners is time. We can choose to represent that time in any way we want, but it is still time.

3) We measure productivity in estimated units of input per actual unit of duration. Since we do not have measurable units of output, we can only measure against estimates.

4) Actual units of input may vary from estimated units of input, but since we have no measurable unit of output, actual units of input are irrelevant to a productivity measure.

5) Cost and duration are forecast based on assumptions around productivity metrics. There are some number W of estimated units of input, and our team’s productivity metric is some number V of estimated units of work(input) per unit of duration, and our bill rate for the team is some number B per unit of duration, so Duration = W/V and Cost = Duration * B – it is really that simple. The magic is in assumptions around V and B and getting the team estimate W so that our assumptions around V become true over time.

Given these truths, it doesn’t much matter what you name your units of input and units of duration, as long as you estimate W in terms of units of input and V in terms of units of input and units of duration.

So from all of you advocates of story points (which appear to vary in size from team to team and from person to person, and from project to project because they are uncorrelated with the actual unit of input (which is time):

How do you project an initial value of V from which to baseline your plan and make your commitment for the initial time box?

Here is my supposition about Story Points:

Story points propose to be an intentionally imprecise metric of software effort. They are uncorrelated to actual units of input. Actual units of input are time. But it doesn’t matter, because we don’t project or predict or forecast or commit based on actuals, we use estimated units of input divided by actual units of duration to do this.

From all the conversations that I have had, the primary purpose of this uncorrelated unit is to prevent or limit the weaponization of metrics. What I mean by this, is the use of metrics in a punitive or manipulative way leading to unsustainable practices: overtime, unexposed technical debt, whip-cycle management, etc. Once metrics are weaponized, they can be used by either the customer, or management but when the weapons are used, there will be destruction.

What else is there?

The alternative to using uncorrelated units of input (story points) is to expose the assumptions behind your projections, predictions, and commitments. Walk your management through how you build your forecast, your schedule, your resource calendar, etc. Explain to your customer what they need to know to make decisions.

While it sounds stupid to tell your customer that your developers only deliver 3-3.5 days of effort per week, it is all that most developers everywhere deliver. There are very sound reasons why it is true. They are the cost of doing business. Collaboration, administration, personal management and learning, team leadership and process improvement all take time away from delivery work, yet all are necessary for a healthy team. Your management knows this and so does your customer, they simply aren’t used to seeing it as an assumption underlying a software delivery projection.

Treat management and customers like “grown-ups” and the trust you earn will be empowering. Don’t give them projections and forecasts without exposing or explaining underlying assumptions, and simply proclaim “You can’t handle the truth” when they ask questions, or misinterpret your intentions.

The value you get out of using correlated units of input is simple. You get the ability to compare productivity across teams using units that have the same underlying basis. You get the ability to compare actual units of input to estimated units of input, understand what the estimate missed, and continuously improve estimating practices. You get a greater level of transparency to management and customer.

Articles from September 2011