Also while in Las Vegas for the ADP/West Conference, Bob Payne and I sat in the Agile Philanthropy booth and recorded a podcast on Acceptance Test Driven Development and the 3 Amigos. This is the latest in a series of Tips and Advice podcasts that Bob and I have done.
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
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
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.
Jason Gorman has just written a piece in defense of Software Craftsmanship that highlights how very dependent our world has become on software. He offers Gorman’s Law Of Software-Dependent Business Evolution:
Software-dependent businesses can only evolve as fast as their ability to write and evolve their software allows them to.
I think this is not only true, but an incredible opportunity for businesses that understand that. Let’s face it: most businesses spend an awful lot of time for a very meager increase in systems capability. Companies that do better than average can shoot to the top. Look at the spectacular successes of some of the relatively young internet companies, for examples. Read More
Dan North says that programming is a trade, and not a craft. I agree with him that it’s a trade, like plumbing and wiring. I’ve already disagreed with his definition of craft. I’d say that programming is a craft only when it’s done well. I’d also say that plumbing and wiring are crafts when done well. Rather than a definition, how about a couple examples to illustrate the point? Read More
Dan North has created a bit of a stir with his declaration that programming is not a craft. Liz Keogh has agreed with him. The funny thing is that most of what they have to say is not about programming, but about the Manifesto for Software Craftsmanship. Well, writing is a craft, also, and I’ll agree with Dan that this manifesto is not “a call-to-arms, feisty, opinionated, brash and everything that a good manifesto should be.” It never grabbed me the way the Agile Manifesto did. Dave Hoover has taken this challenge as a call to improve the software craftsmanship manifesto.
I didn’t “sign” the Manifesto for Software Craftsmanship because I thought it was particularly well written, though. I signed it because I support the intent (as I perceive it, and which Ade Oshineye defends) behind that manifesto. Writing software is a craft, and there are far too many people who don’t treat it that way. Read More
In the late 1970s, in the Co-Evolution Quarterly, the magazine successor to The Whole Earth Catalog, Peter Warshall stated that geodesic dome houses always leak. This was a bold and surprising statement at the time, coming from a man who was considered one of the finest builders of dome houses–ones that didn’t leak.
Why did he make this statement? Read More
Jim Shore has posted a response to the reactions about his previous post on Acceptance Testing in which he defends the way he and the teams he coaches are working. About the same time, Lisa Crispin posted her thoughts on the topic.
As Lisa says,
I can’t tell you the one right way to test and develop software”¦. The one right way for your team to code and test will continually evolve over the years. In fact, I’m sorry to tell you that you’ll never find the one right way; it’s a moving target, but you’ll get closer and closer to it.
This is an incredibly important point! There may be many “wrong” ways—wrong in that they fail to achieve your objectives—but there is no “right way.” So I’m happy that Jim and his teams are able to achieve the results they want. I’m not saying they’re doing it wrong. Read More
Recently, Jim Shore wrote about The Problems With Acceptance Testing. I like Jim, and respect him a lot. Because of my respect for his opinions, I found it quite discouraging that he said, “I no longer use [automated acceptance testing] or recommend it.” Gojko Adzic has posted his response to Jim. This is mine.
Certainly when something’s not giving you the results you want, it’s time to make a change. That change can be to drop the practice that’s not working for you. It can also be changing the way you go about the practice, or changing what you want to accomplish. Or, instead of changing, maybe the word “refining” is a better fit. Read More
Maybe you’re starting your first Agile project. You’ve read books and blogs. You’ve had training. You think you’re ready, but it’s still a daunting prospect. There’s just so much to remember—so many details.
Here’s a little cheat sheet. Forget all the details and the various ways you can implement Agile for the moment. Let’s simplify the picture. There are just three essential legs that your Agile project needs to stand. Get those in place, and you’ll do OK. Keep improving all three, and you’ll do fantastically! Read More