Don’t You Have to LOGIN first?

In my previous post, Avoiding Iteration Zero, I suggested starting with “the one obvious thing that needs to be done? (Hint: it’s not ‘login.’)” As Jon Kern has recently mentioned, this same topic has come up elsewhere. I was also in that list discussion.

Jon is, of course, right in a narrow sense. You can start with login, if you want. You can also start with an Iteration Zero. (Or, an Iteration Minus One, as I’ve seen one organization do when their list of pre-planning outgrew one iteration.) I’ve observed that you can generally get better software, faster if you start somewhere else.

There are some very good reasons for this. Read More

4 Comments

Categories: Tools and Techniques

Tags: , , ,

Avoiding Iteration Zero

Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with

  • A list of features to be built
  • A release plan or timeline for those features
  • Setting up development infrastructure such as version control or continuous integration servers
  • Studying or practicing skills in new technologies they expect to use
  • … and other management, infrastructure, and technical endeavors.

They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.

The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.

And we’ll have burned an iteration without producing any working software that tests our decisions.

My advice is to borrow an idea from Lean and look at the situation from the output point of view.  Ask yourself, “what would it take to start delivering?” Read More

23 Comments

Categories: Tools and Techniques Working Software

Tags: , , , ,

On Models

Brian Marick has written a tantilizing post The Stance of Reaction. In it he says

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.

I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).

So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me. Read More

2 Comments

Categories: Individuals and Interactions Tools and Techniques

Tags:

The Carrying Cost of Code

Michael Feathers has just written a post on The Carrying-Cost of Code: Taking Lean Seriously.  He says,

No, to me, code is inventory.  It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.

I’m not sure I can see the analogy of code that’s in production to inventory.  Code that hasn’t shipped, yes.

But all code is a liability, I think.  When code is in production, then it’s offset by the asset that is the functionality.  Whether or not the net is positive is another question.

There’s no doubt to me that code, whether in production or not, has carrying costs that are larger than generally realized.  Perhaps it’s a depreciating capital expense?

Carrying costs are larger than we think. There’s competitive advantage for companies that recognize this.

It’s something that takes up space.  It takes maintenance.  It takes attention.  It does have a substantial cost of ownership–larger than we think.

The analogies may be failing me, but I think Michael’s sentiment is correct.

2 Comments

Categories: Working Software

Tags:

Simplicity and Perspective

Everything should be made as simple as possible, but no simpler. — Albert Einstein

Dave Rooney recently bemoaned on Twitter about how complicated people make things, pointing in particular to a thread on the scrumdevelopment yahoogroup.  It’s a thread that started with a question about a team wanting to adjust the Sprint Backlog in-sprint when something changed about their capacity to complete the work.  From there it spawned a long discussion about various ways to estimate the work and commit to it.

To me, most of these approaches to estimation are more complicated than is necessary.  Some go into detailed calculations that are far more complicated than what most teams do.  I could tell you a really simple technique, but I suspect most teams aren’t ready for extreme simplicity, yet. Read More

No Comments

Categories: Individuals and Interactions Tools and Techniques

Tags: , ,

Joyful Change

Brian Marick challenged me for an expression of joyful change, especially related to software development, based on the teachings of Virginia Satir. As discussed in my previous post, he’s come to associate the combination of “Virginia Satir” and “change” with pain and the following:

…blaming… …placating… …anger… …guilt… …stress… …resistance… …denying… …avoiding… …blocking… …deny… …avoid… …anxiousness… …vulnerability… …fear…

This post is, in part, to demonstrate to him that the work of Virginia Satir is not focused on the negative. Mostly it’s to share, and rejoice in, the freedom we have to reach our goals. Read More

2 Comments

Categories: Responding to Change

Tags: ,

It’s Only A Model

We use models to help us simplify the situations we’re viewing, so we can reason about them more easily. I’ve often found this to be enormously helpful. It’s important, though, to remember that this is only a model. We can use a model for understanding, and even for making predictions.

We cannot substitute the model for the thing that it is modeling, though. The map is not the territory. When we use a model in contexts where it doesn’t apply, it’s likely to lead us astray. Similarly, when we mistake an illustration of the model for the model itself, we may make inferences that the model doesn’t support.

For example, a couple of my friends have recently tweeted complaints about the Satir Change Model in response to such misuses. I find the Virginia Satir’s model extremely useful, and would like to disassociate it from these misuses. Read More

3 Comments

Categories: Tools and Techniques

Tags: ,

Agile In 6 Months

How long does it take to take a team from where they are to becoming an Agile team?  Of course, that depends on many things, including where they are and how badly they want to succeed at Agile.  It’s reasonable to think they can make a transition in six short months.

If you’d like your team to become Agile, give me a call to find out how I can coach the team to do that for about the same cost as contracting a senior developer.  If your team has already made a transition, but you find that you’re not as effective with Agile as you’d like to be, I can coach using the same framework to help you reach that effectiveness.

1 Comment

Categories: Individuals and Interactions

Tags: , ,

Iteration, Increments, and Timeboxes

Like many words, we often use “iterative” and “incremental” quite loosely. I’m OK with that, until that lack of precision causes misunderstandings, disagreements, or misdirection of effort.

It’s quite common for Agile teams to speak of an iteration as a synonym for the Scrum term sprint. Both of these usages really mean timebox. Read More

9 Comments

Categories: Tools and Techniques

Tags: ,