Review of Adrenaline Junkies and Template Zombies

I reviewed the book Adrenaline Junkies and Template Zombies, by the Atlantic Systems Guild consultants on StickyMinds.com. Like many of the other books by this group, it's an inspiring read. For more see the review.

3 Books every engineer should read

There are many excellent books to read if you write software (Software Configuration Management Patterns: Effective Teamwork, Practical Integration) among them :) ). Given that each of us have limited time, its difficult to read everything one might want to, so we tend to focus on reading material that addresses our immediate problems. Having said that, there are 3 books by Jerry Weinberg that have incredibly valuable advice that I use frequently, and I'd like to recommend them to anyone who's serious about software engineering work:

• Are Your Lights On?: How to Figure Out What the Problem Really Is
• Becoming a Technical Leader: An Organic Problem-Solving Approach
• Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

These books are more about working effectively with people to solve technical problems than actual technology problems. This is an area many people neglect; tools and technologies come and go, and you need to maintain your skill level, but knowing how to look at problem solving is a timeless skill. The

I first heard about Are Your Lights On? from Linda Rising who recommended it on the patterns-discussion list. This is an easy to read, entertaining book that illustrates quite clearly what some people never really learn: you need to know what the problem is before looking for a solution. Sounds obvious, but if you've ever spent a lot of time implementing a complicated solution to what turned out to be a non-problem, the techniques in this books will be useful.

Becoming a Technical Leader: An Organic Problem-Solving Approach has lots of good information for technical people at all levels. This book also has some good work-style and problem solving ideas for non-technical people. If you have a role with the word "lead" in your title, the value of this book seems obvious. What's surprising is how the book explains how to be a better technical contributor on a team, regardless of your title. It has many problem solving techniques and guidelines expressed in a clear style. I've read this book a few times and found new insights each time.

If you are in a role where you need to give or receive advice Secrets of Consulting: A Guide to Giving and Getting Advice Successfully has a number of excellent, easy to remember, "rules" to keep in mind. Regardless of whether you are a full time employee, contract employee, or someone who is considering consulting, the techniques in this book are valuable and timeless.

It's rare that a week goes by when I'm not in situations where I apply the advice in one or more of these books. There are other, more recent books that cover similar ground, in particular a few by Johanna Rothman, Esther Derby (among others). Jerry Weinberg is one of the masters of combining the technical and human side of software development, and it's worth your while to read what he's written.

Feeback, Writers Workshop Style

I was fortunate enough to participate in the first few Pattern Languages of Programs conferences, where I learned quite a bit about technology, writing, problem solving, and giving and receiving feedback. What made the biggest impression on me was the process the patterns workshops used.

Before I started to write patterns, I was used to getting feedback in a way that focused on what was wrong or missing in my presentation. The patterns community approach is to evaluate papers through a shepherding process that ends in a writers workshop.

A patterns writers workshop has the following parts:

• The author of a paper reads a selection. This gives the other participants a chance to understand something about how what the author thinks is most important about the paper. After this reading the author becomes a passive participant in the session, only speaking if someone makes comment that isn't clear. The author does not defend his writing.
• Someone in the workshop summarizes the paper. This allows the author to understand if the main points of the paper made it through.
• The group discusses what they liked about the paper.
  
• The group discusses things that could improve about the paper. Notice that this phase is not "things that are wrong about the paper," as the goal is to help the author.
  
• Finally, the author can speak again, asking clarifying questions.

The important things about this process are that the feedback starts with positives, and focuses on improvement. Reinforcement of what's working helps the author be more receptive to suggestions for improvement later on and provides guidance for what not to change. Since the "negatives" are cast in terms of actionable items, the author has direction.

I've found the following approach, which is a variant of the workshop format, useful in other circumstances outside of reviewing writing:

• Starting with things what went well
• Discuss things to improve, not simply things that are broken.

These guidelines are part of retrospective formats and this is a component of some management techniques. Sad to say, many day-to-day many seem to focus on negatives, because the argument goes, there isn't a need to discuss what you're doing well. This isn't a great argument. Without feedback on the good things, someone won't have the confidence to make improvements or guidance on what strengths to leverage as they make changes to their work.

Sure, the first tendency is to focus on what's broken, since it probably has your attention, and thinking of things to do to improve takes more work than simply registering observations, but if you are being trusted to provide feedback, shouldn't you put in the effort?

Next time someone asks you to give feeback on a work item:

• Start off by finding at least one thing you liked, and mention it.
• When you discuss things that need fixing, try to use a sentence that has the form: "this would be better if ..."
  

See if this approach helps your feedback be more well received and more effective.

For more on the writers workshop process and applying it in technical contexts, have a look at the book Writers' Workshops & the Work of Making Things: Patterns, Poetry.... To learn more about patterns visit the Hillside Group. Esther Derby wrote a great article to guide managers in giving and receiving feedback.

The Value of Agile Infrastructure

Engineering practices such as Continuous Integration, Refactoring, and Unit Testing are key to the success of agile projects, and you need to develop and maintain some infrastructure maintain these engineering practices. Some teams struggle with how to fit work that supports agile infrastructure into an agile planning process.

One approach is to create "infrastructure" or "technical" stories for tasks that are not directly tied to product features. In these stories the stakeholder may be a developer. For example, a user story for setting up a continuous integration server can go something like:

As a developer I can ensure that all the code integrates without errors so that I can make steady progress.

While there not all work on a project leads directly to a user-visible feature, thinking of infrastructure stories differently than other stories has a number of risks, and can compromise the relationship between the development team and other stakeholders. Agile methods are about delivering value as measured by the product owner (though the team has input in helping the owner make the right cost/benefit decisions). Thinking about tools and as having value that is dependent from end user value subjects you to the same risks that Big Design Up Front does: wasting effort and not delivering value.

I'm a fan of being able to track everything an agile team does to something that can create value for the product owner. This may be a bit idealistic, but having this ideal as a starting point can be useful; even if just try to focus on delivering value you will be more likely to make the right decisions for your team and your project.

One way to make the relationship between "infrastructure" work and product value is to recast infrastructure stories with a focus on value to the product owner. For example, consider the example above for setting up a CI system:

As a project manager, I want to identify when changes break the codeline so that mistakes can be fixed quickly, and the code stays healthy.

This may not be the perfect example, but when I think of infrastructure items this way I have a better understanding of why I'm considering a change, and it prepares me to advocate for the work in case there is push-back. You can apply this approach to other "technical" items such as:

• Investigating a new testing framework.
• Refactoring (in the context of implementing a story).
• Upgrading your SCM system.
• Setting up a wiki
• Adding reporting to your maven build.

The benefits of considering the value of technical tasks to all stakeholders, and not just developers, include:

• A better relationship between engineers and the other stakeholders on a project.
• A better allocation of resources: If you can't explain the value of something there may be a better solution, or at least a less costly one.
• A better understanding of how to use engineering techniques to deliver value.

I admit that his approach has some challenges. The value of technical tasks can be difficult to explain, and are often long term at the expense of short term costs. Even if your project dynamics require you to address infrastructure in some other, more indirect, way you can benefit by starting to think in terms of how what you want to do adds value. Software engineering is a means towards the end of solving business problems, and as engineers we should be able to explain what we're doing to any informed stakeholder.

Pitching Agile and the Elevator Test

Some time ago I read Crossing the Chasm by Geoffrey Moore, which is about marketing high tech products to mainstream customers. The part of the book that stuck with me, and the one that has the most pages marked in my copy was the section on positioning a product, in particular the section on the elevator test, which I've found to be a useful framework for understanding the value of many things, not just high tech products and companies.

A successful 2 sentence statement of the value of product should pass the elevator test . While the book is focused on making a claim for getting the interest of investors, being able to cast any idea you are trying to sell into this format is a great exercise, as it forces you to be focused and to really understand the value to your audience of the idea you are describing. Once you've got someone interested you can then go into the nuances.

In an elevator pitch you should be able to describe:

• Your target audience
• The market alternative
• The new category that your idea/product fills
• What problem solving capability this new thing provides
• An alternative that is in the target audiences mind, and
  
• The key product features

I have seen the benefits of agile software development, and I I really understand them. The problem is that my intuitive understanding often gets in the way of my explaining the issues that others are concerned with -- what's obvious to me isn't always obvious to others!). The really short tag lines ("Embrace Change" for example) sometimes lead people to think of agile as just rapid change. and don't get across the discipline that an successful agile project needs. And lots of people have been jaded, having experienced projects billed as "agile" which were more chaotic with a couple of agile technical practices thrown in. I wanted to try to imagine what a pitch for agile would be. (And I welcome feedback).

This is my attempt pitch for agile that can pass the elevator test:

For organizations who are dissatisfied with the overhead and lack of flexibility of conventional software development methods, Agile Software Development is a software development process. Unlike traditional chaotic or document-heavy approaches, Agile Software Development is a lightweight, yet highly disciplined approach that delivers end to end value in frequent iterations, where the stakeholders can re-evaluate priorities based on the state of the application and current market needs at the end of an iteration.

This seems close to what I was aiming for. What's missing, I think, is a good characterization of the alternative to agile. People who are investigating agile might be looking to change from anything from a traditional waterfall process, to (more typically) a chaotic approach. I'm not sure that I captured that entirely.

Even if this isn't the best pitch, thinking about how to express the value of agile clearly and quickly is a good exercise. Much like agile planning, where "The plan is nothing, planning is everything," the exercise of developing a pitch that can pass the elevator test is perhaps more important than the actual pitch.