All About Agile
Kelly Waters has just informed me that All About Agile will be aggregating from a number of blogs, thereby better living up to its title. It’s one more way we can share ideas and help each other.
When something persists, some reward exists
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
It is possible to fail in many ways
On Twitter, Alfonso Guerra (@Huperniketes) asked me, “Okay, tell me how [software] quality will improve by prog[rammer]s taking more resp[onsibility] for quality?” My response is longer than 140 characters, so I’m replying here.
For background, my involvement in the conversation started when he caught my eye with
The problem with the Software Craftsmanship movement is its attempt to create a race of superprogrammers who can save [software] from bad [project management].
Well, I don’t know anyone promoting Software Craftsmanship who thinks that. Read More
Trades, Crafts, and Certification
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
Software Craftsmanship
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
Project advice from a solo circumnavigator
Tonight, we attended a lecture by Rich Wilson about the 2008-2009 Vendee Globe, a race around the globe by solo sailors in 60 foot overgrown sailing dinghies. While many sailboat racing talks get rather monotonous, this one was fascinating. Instead of talking just about boats and gear, Rich spoke mostly of the experience and the people involved.
He offered some advice that I think fits well with software projects:
In a race of four months, going 22 knots for a day doesn’t mean much. It’s just an opportunity to break things. It’s more important to raise the average speed from 10 knots to 11 knots.
This says something about sustainable pace, but it also says something about our tendency to measure ourselves by our peak performance according to some measure. Let’s face it–we’re only at those peaks for brief moments.
In the normal world of human endeavors, rather than artificial contests, the measure of “best” is never a measure of a single attribute. I would say that the measurement scales for our performance are so numerous and varied that we are never “best” by all of them at once. Perhaps we are not at our peak even for brief moments.
Yet we can always strive. And even when we don’t achieve that which we desire, or that which we think we’re capable of achieving, we may still be doing our “best” under the circumstances. In fact, how could we not?
Accounting for Spikes
The term Spike Solution is associated in my mind with the early days of Extreme Programming. I’m sure that it is built from prior ideas, as everything seems to be. If the term and the concept it describes predates the Chrysler C3 project (Ron Jeffries mentions using it there), I’ve not yet uncovered it. Ron credits Ward Cunningham for the term. I’m sure there are predecessors, even if not expressed as distinctly.
The goal of a spike solution is to answer a question. For example, a spike may be used to test the feasibility of an algorithm or 3rd party library. It may be used to explore design alternatives for solving a sticky problem. It’s called a spike because it drives all the way through the problem, but as narrowly focused as possible. It’s not a complete implementation. Associated complexity that is secondary to the question is likely stubbed out to reduce the clutter and increase the focus. Read More
If Scrum certification is the answer, what might be the problem?
Ron Jeffries has written a nice article on some of the effects, both positive and negative, of the Certified Scrum Master (CSM) program. On the positive side, he notes that it does interest people in training. I’m less optimistic that the training they receive will result in many improved projects. The CSM training teaches people how to follow the Scrum process, and tries to give them a little boost in courage for dealing with the inevitable impediments. Is that the difference between a troubled project and an improved one? Read More
So you want to make your organization Agile
When I first discovered Extreme Programming a decade ago, I was a software developer wanting to produce the best, and best fitting, software that I could. In those days, it seems that most Agile adoptions were from the bottom up.
Now I find a lot of Agile adoptions are from the top (or, at least, middle) down. Managers have heard about the improved results that companies are achieving using Agile development, and they want some of that for their organizations. That’s not surprising, and it should result in both better results for the organization and better work life for the employees.
Unfortunately, it doesn’t always work out that way. What is it that goes wrong with these top-down Agile transitions? More importantly, how can a well-meaning manager conduct a successful Agile transition? Read More
It’s a mystery; I just know.
The first words I learned to read were “off” and “on.” I noticed them on the light switch. By the sounds of the names of the letters, and the effects of moving the switch up and down, I made the connection to the words.
After that start, I was on my way to becoming an avid reader. It’s not that I read great literature or learned essays. I read pretty much anything that was in front of me. Read More