Tag Archives: Agile

A Book List About Lean-Style Methodologies

Recently, my job has changed a bit. I’ll probably write about that in a post coming up, but for now it suffices to say that I’m definitely spending more time than usual thinking about entire projects and all aspects of the project. Naturally that has me thinking about process more. I have always tended to prefer Agile methodologies, and the Lean flavors in particular.

However, I didn’t feel that I really had a solid background in the lean parts. While I’ve understood the processes and motions and studied Lean manufacturing in college, some of the motivations and subtleties are tied to a deeper understanding. I feel like I needed to spend some time reading the best works on the subject. Practical experience on lean teams is great, but I wanted more.

With that in mind, I reached out to Rick Simmons (@simmons3k). I used to intern for Rick way back in my college days and we keep up and discuss software, Agile from time to time. Rick is an Agile Coach for Rally, and at one time helped implement and improve Agile processes at Constant Contact. Needless to say, he’s an expert in the area. Rick was kind of enough to give me a list of Lean books that he recommended, and I got the idea to publish the list as a post with his permission.

I’ve linked to each book directly, but if you prefer I have a public Amazon list for the books as well available here.

As I read some of these, I intend to follow up with more posts about what specific lessons I took away from each one. Feel free to follow up with your thoughts in the comments below.

Find The Agile Signers On The Web

If you’re interested in seeing what the signers of the agile manifesto are up to these days, I’ve compiled a list with twitter and blog links below. If you use twitter lists, I’ve created on here.

If you have any corrections, please post in the comments below.

signer twitter blog github
Kent Beck @kentbeck blog kentbeck@github
Mike Beedle @mikebeedle blog  
Arie van Bennekum @arievanbennekum blog  
Alistair Cockburn @totheralistair blog  
Ward Cunningham @wardcunningham blog wardcunningham@github
Martin Fowler @martinfowler blog martinfowler@github
James Grenning @jwgrenning blog jamesgrenning@github
Jim Highsmith @jimhighsmith blog  
Andrew Hunt @pragmaticandy blog  
Ron Jeffries @ronjeffries blog  
Jon Kern @muddyallen blog jonkernpa@github
Brian Marick @marick blog marick@github
Robert C. Martin @unclebobmartin blog unblebob@github
Steve Mellor      
Ken Schwaber @kschwaber blog  
Jeff Sutherland @jeffsutherland blog drpentode@github
Dave Thomas @pragdave blog  

A Comforting Warning About Agile

“Beware of becoming an Agile zealout, because this can backfire and put people off. Don’t treat people who are not applying Agile as fools who just need to see the light! This is disrespectful, and people simply won’t listen to your rants.” -Rachel Davies in Agile Coaching1.

Why is this comforting? Good communities self-monitor. Many of today’s communities with momentum have some ego issues. Communities like Agile, Ruby and Mac folks. All three of those communities are great and everyone should be learning more about them, so this isn’t meant to start a flamewar. But what comes off as passion in an upstart community can be obnoxious in an established community. And it certainly doesn’t fly well with the 2nd and 3rd tier adopters that are often the target of such zealotry.

This isn’t an excuse for half-assed Agile. Go for “full-assed” commitment to whatever system a team uses, and in more cases than not, they should be doing a flavor of Agile (usually lean) throughout the software lifecycle.

But blind assertions and a condescending tone won’t win anyone over. No matter what is being sold. This can be a particularly hard trap to avoid when a person or their business are sold as Agile experts. Or… “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” –Maslow

When leaders and authors in the community stand up for moderation, it is a sign of maturity.

  1. Note that Agile Coaching is written by Rachel Davies and Liz Sedley, but Rachel Davies only is cited above as the quote is in a “Rachel says” section.

On a Feeling of Ownership, and How it Changes With Size

Through the years, a fair amount of my projects have been with small companies and startups. One thing I notice almost universally, is that members of smaller teams tend to have hunger for success, and a real feeling of ownership over their product. They take personal pride and consider themselves invested in the project.

That tends to change as the team size grows, for better and worse. On one hand, relying on “heroes” can be a dangerous thing, and people need to learn to pace themselves out. So a maturing and growing team can be a step in the right direction. On the other hand, it’s hard to see that desire for success and personal sense of pride in a product die off.

Everyone who has seen a big struggling project knows that feeling. “The wheels of bureaucracy are turning, and all I can do is what the product owner has asked of my piece. Suggesting improvements is just going to cause argument. And besides, why stick my neck out and risk being listed as one of the causes for project failure?” Also, there is a big difference between the amount of responsibility you feel when you are part of a successful team of 10, compared to a successful team of 100 or more. And projects of that size face unrealistic expectations and rarely feel successful.

How do you change this?

Maybe you don’t. I was once part of a startup, the 3rd man in. There was the founder (with a marketing background), a designer / developer, and I joined to help with the the rest of developing. The feeling of pressure and control that we all had on that project is something I’ve almost never felt on larger teams.

However, there’s no need to throw in the proverbial towel. There are techniques to strike a balance. Agile methodologies usually push for smaller teams and more distributed responsibility. And products can be broken into smaller pieces using a module or a SOA approach. (Yes, putting SOA into an agile approach is a challenge, and possibly a contradiction).

In the context of your business and its goals, you have to find the balance. All aspects of the business can be controlled and dictated from the top, but your subordinates aren’t going to innovate and grow organically, and they are only going to work extra hours if you force them. For a mature business with stable returns, that model probably fits. But in industries that face a lot of change and require innovation, you probably need to risk the destabilization of delegating out large amounts of responsibility to small teams. You will have less consistent results, but they will hit some homeruns.

I think Microsoft has seen this in recent years. It’s a common complaint that the teams don’t coordinate and share information there, but they have developed some interesting products. Their having been more surprises than there were under the old centralized management of the Gates’ days. Look at products like ASP.Net MVC, Win Phone 7, Windows 8, WebMatrix and Azure. Not the most integrated products, and some are not commercially successful yet (WP7), but they were more surprising and interesting than a lot of prior products.

The real outlier is Apple. Steve Jobs flew in the face of everything I just described. He notoriously kept the decision making power to himself, yet left Apple workers with a feeling of investment and devotion to the company. Even the customers feel invested. I can’t imagine a Windows sticker on the car of a person whose pay isn’t from or closely related to Microsoft, but I see a lot of cars with apple stickers in the back window.

So as a business grows, you can either try to keep the teams small and empower them to feel invested, or find the next Steve Jobs. Best of luck if you chose the former. Sometimes growth is the mistake. There are industries (like service / partner type models) where growth can risk lowering the profit share per owner / partner / investor. See Managing the Professional Service Firm for more on that risk.

What do you think? What has your experience been? Comment below.

Agile Muffins: A Simple Justification of Iterative Methodologies

I find myself more and more involved in the sales process with my company. And while our primary focus is on expertise around technology and information, the team I sell for most does work using Agile methodologies. It’s not the primary aspect of our sale though, as people want to hear about our proposed solution, our work history etc. Rarely do they want a long explanation of how we do our work. But we do briefly explain it. So what is my Agile elevator speech?

I stumbled into this explanation on a particular sales call. I wanted to explain / justify an iterative approach, as opposed to a phased (big design up front) approach to a firm that had a background in mechanical engineering. After all, big design up front comes out of the kinds of engineering found in manufacturing and construction.

When building a bridge, the bridge is the end product. It is tangible and defined. It’s state may change, and it requires maintenance and monitoring, but it is a big noun. Creating software is more like making a muffin recipe (say for a book or something). In other words, it’s verbs. The muffin isn’t the product, the recipe is. After all, software is instructions for a computer, like a recipe is instructions for a baker.

In either case, you want to invest your time and money in the product. So with a bridge, you want all the data and research you can get, in order to have it right before building anything that commits you to all or part of a design. The cost of change is high. And the process is just a necessary evil. There is no value in the process, the value is in the bridge. And before finishing, you will test and refine the bridge, not the construction process.

With a recipe, you are investing in the process. The cost of change (throwing out the muffins) is low. And you are testing the process, not the muffins. Yes, you test by eating the muffins, but they are a proxy for evaluating the process. After all, if the muffins are bad, you don’t try to fix that batch of muffins, you rework the process and make a new batch.

Your mileage may vary, but for me, this analogy helps me keep the core values of agile in mind. I think Sports Management is another good one. Imagine planning everything for a season before it starts, and then refusing to adapt during the season.