decisions – In Search Of

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.

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.

Posts Tagged with decisions

Inaugural Curation Post…

agile42 | Feature Injection Applied to Service Delivery

Do You Suffer From Decision Fatigue?

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

Calamity howlers & positively selecting with surprise « Freckle Time Tracking

Emergent Vs. Inverted Thinking