Agile – In Search Of

Information Driven Projects

Posted on February 10, 20152 Comments

When you look at software development or corporate change projects, you often see some creative fiction. There is fiction in the plans, fiction in the designs and fiction in the requirements. This fiction is created by the notion that “Before we can start, we have to know everything required to get to done.”

Intuitively, we all know that this is not really true. We all know that information will “emerge” from our activities that will change how we get to done. We learn from our mistakes. We try things that don’t produce as good a result as we want. We clarify our understanding of the problem as we demonstrate portions of the solution.Continue Reading

The Perfect Product Road Map

Posted on April 22, 2014Leave a comment

At the core of every software product road map are two concepts. These are essential to all software product development. We may think of different things, and we may use different terms or even look at them from different angles but at the end, I am convinced that it boils down to only two things:

Capabilities and Adoption.

in my experience, every other thing we do when we build software is a component, or is connected to one of these concepts. I think often that what gets us screwed up, is that that we focus on the “every other thing” from some methodology, or some playbook, or some consultant, and lose the plot on the essentials.Continue Reading

Smaller Bets (Story Elaboration Pushback)

Posted on April 1, 2014Leave a comment

It is always better to spend the least amount of (time, effort, money) to get what you want, right? If I can get a tasty meal for $10 why

McD's Dollar Menu Combo - Buffalo Ranch McChicken + McDouble with Coke = $3.64 — McD’s Dollar Menu Combo – Buffalo Ranch McChicken + McDouble with Coke = $3.64

would I pay $30 or $200 – for the experience of eating – that isn’t about taste. That is a different thing, isn’t it. We have different priorities for eating – being full, healthy, tasty, being served, fast service, being able to relax, a pleasant experience, being able to brag about my meal/experience. Each of these is a different reason for selecting a dining experience. Each of them is valuable to some people some times, but not all people all the time. The way we choose to spend our money to eat is not that different than the way we choose to spend our money on software capabilities; there are different reasons why we prefer one capability or a means of delivering a capability over others.

These are the principles that I use to guide my story elaboration – and thus my ability to challenge those who would ask me to do more than the minimum…Continue Reading

Packing The Box

Posted on March 25, 2014Leave a comment

Do you remember the last time you moved? Do you remember packing some boxes so full, that they were too heavy to lift after you were done? It happens. Especially books and vinyl records. When you are packing “regularly shaped” high density items, the volume of the box may be too large to contain the weight of the items. Or it may be that the lifters (I mean you) may not have enough momentary work capacity (strength) to carry the box.Continue Reading

Team Behaviors

Posted on March 18, 2014Leave a comment

In my recent post on Optimum Iteration Length, I finished by saying that iteration size is not the cure for bad team behaviors, but shorter iteration size makes those behaviors more apparent.

This post is about how to counteract ineffective team behaviors, from my own experience:

There are three general diseases that have lots of different causes and lots of symptoms, but at the end of the day, they boil down to these three things:Continue Reading

Optimum Iteration Length

Posted on March 11, 20142 Comments

In recent months, I have had quite a few conversations with Agile teams, and one topic that comes up is how to decide on or why to adjust iteration length. When a team is adopting agile practices, they often ask “What is the best iteration length?”

Like everything else in software development, my answer is “That depends…” Depends on what? Depends on how your team “thinks”. Depends on how your team “plans”. Depends on how your team makes decisions. Depends on how your team writes or receives user stories.Continue Reading

Better User Stories

Posted on March 4, 2014Leave a comment

While I will not claim to be an expert at writing user stories, I am experienced. It is not always enough to simply follow the pattern. Like any analysis pattern, there are some things that one can do to improve their stories. Continue Reading

The Appeal of User Stories

Posted on February 25, 2014Leave a comment

I have been “doing” user stories for a while, years now. I have been doing them mechanically without thinking about what makes them “good”. Not that I haven’t been working to make them better with each release on every project. My user stories have consistently grown better following the INVEST pattern. What I haven’t been thinking about is “why” user stories and the process through which we create them is good.Continue Reading

Connecting the Boxes

Posted on January 7, 2014Leave a comment

2013 was the year that I finally decided to replace my ancient two channel sound system with a 5.1 channel home theater capable system. My old setup was very simple. A pair of ADS speakers that I had bought when I was in college (1981) and a Nakamichi receiver that I had bought shortly after I was married (1989 or so). I had other components, but most had been replaced with a cheap Blu-ray player that I “won” at a silent auction a few years back that played most of my CD’s. I still have a B&O turntable that is serviceable, but I rarely play my vinyl these days.Continue Reading

Product Centered Worldview

Posted on November 12, 2013Leave a comment

Agile thinkers focus on the product – and how we are intentionally adding value to a “software asset” and potentially how we manage our “portfolio” of software assets. Phase-Gated Delivery (some people call it waterfall) patterns allow us to “optimize” the work against the constraints – but do not allow us to optimize the value delivery in time. In fact, they push ALL the value delivery to the very end of the cycle. But in theory, because we can optimize the projects by minimizing the schedule and cost against a constant value output – the value can be had for less investment. Problems arise when – the actual value is realized over time (meaning the sooner the customer has access to a software capability, the sooner his actual costs go down or his profits go up).Continue Reading