A great way to make quality important in your organization

There’s really only one key practice for quality:  continuous improvement, and its dual, continuous learning. For continuous learning, many practices that help; one of my personal favorites is ‘Lunch and Learn.’  It’s easy to get started, allows the team to ‘opt in’ to shared practices, and is an amazing opportunity for growth.

One example that quickly springs to mind is “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert Martin. This was one of the featured books in our lunch and learns at EVault. We’ve also done this at Pharmatrust, and I think we’re about at critical mass to do this at MedAvail.

On a side note: I consider myself fortunate to have had the opportunity to learn from the teams I have worked with over the years; it’s one of the greatest pleasures of my professional life.

Advertisements

Software architects and strategic decisions: Build, buy, open source, or partner?

I had a conversation today with a former colleague about implementing mission-critical software, and the cost assumptions of Agile methods. He cited “Balancing Agility and Discipline: A Guide for the Perplexed” as an analysis which says Agile assumes as an axiom that the cost of change is constant (in the front end engineering processes, not in remediation, fixes in the field, etc.) Frankly, I suspect that’s because Barry Boehm is a classic “programming in the large” guru, but I haven’t read the book yet. 

This is true (that Agile assumes constant cost of effort) in the sense that it’s held constant in the same sense of any other “assuming all other things are equal, we vary this.”  I see the point, but it seems to me that it’s not true in practice, in my experience, but then, I don’t think many people implement Real True Pure Scrum or Lean or XP or any other agile practices; they typically implement some kind of composite methodology, which merges specifications and design artifacts in the outer feedback loops of (for example) Scrum.

But he did have an excellent…nay, *superb* point: without explicit architecture work as an input to software development, development frequently gets caught in a cycle of relative local improvement, without being able to leap beyond the limitations of the existing or incrementally developed architecture, and sometimes that just won’t get you where you want to go.  I personally believe that these outer feedback cycles, including project kick-off, are the best integration points, and that most people practicing Scrum are working away with the “release and below” of the feedback loops, and neglecting release and multi-release planning entirely.

(I personally like the XP-style feedback loop diagrams on this page…to me, the architectural inputs belong in the outer feedback loop, with tweaking and involvement from the architecture team in the inner loops.)

To me, the point is that as software professionals, we have to be able to make decisions about what we’re going to build, buy, or integrate with, and this meta-decision can easily be a part of the Scrum, XP, or other Agile processes, and we don’t have to model the cost of the estimate purely by (for example) planning poker, especially when there are other costs involved. However, many organizations FAIL to make these decisions, instead always choosing to build, which leads to massive expense overruns, because they are trying to solve the wrong (software architecture) problem.

I’m looking forward to reading the book to see if it provides suitable guidance for practitioners in the field, both that I can use myself, and that I can reference to customers and employers. I generally find (both when working directly for an organization, or as a consultant) that some kind of ‘made to fit’ methodology is what’s really needed…and I haven’t seen that codified. Might have to do it myself, we’ll see.

Comments, insights, or experience are always welcome. More later after I read the book; I’ve always enjoyed Boehm’s work, so I’m looking forward to it.

Thanks,
Dak

Focus, focus, focus

For me, today is all about focus.

As David Allen reminds us (you have read David Allen’s Getting Things Done, right?), you can really only have one first priority at a time. You CAN multi-task, but it comes at a cost.

So how do you deal with this? Focus.

Pick one thing.
Do it until it is done.
Do the next thing.

And now, on to the next thing.

If you want to read a little more deeply on this topic, here’s a paper written by Francis Heylighen and Clément Vidal, entitled “Getting Things Done: The Science behind Stress-Free Productivity.” Grab a copy and read it when you have some downtime.

In the meantime, focus. Pick the next thing. Do it until it is done.

Best,
Dak

Dan Keldsen: Innovate or die

My brother, who is a Director with AIIM, presented this at the AIIM conference in Boston this week. I thought I’d share it here, as it directly relates to how costs inflect the innovation/return curve.Thanks,
Dak

Do Or Die Innovation By Process Based Information Management

From: dan.keldsen, 2 days ago

Another “hyper-keynote” – although about half the the slides I’ve been using lately. 75 slides in 50 minutes, when done live. If you’re at the AIIM Conference in Boston this week (March 3rd, 2008), I’m giving this presentation on Tuesday, March 4th, at 2:30pm. Hope to see you there – and if note, feel free to comment here.

SlideShare Link