Best Agile Tools - By Blog Favorite - Woody Zuill

Here we go again. I asked Woody what his favorite agile tools/blogs are. This was his very well thought out answer (the bolding is my own):

"I don't pay much attention to the Agile blogs - there is a LOT OF NOISE out there with people giving advice about stuff they have insufficient (or no) experience to give advice about, and probably very few people available for taking that advice anyway. Many of the "blogs" are merely lame marketing efforts. The most solid of the bloggers are worth reading - but I don't typically follow them, but I'm more likely to click a link to an article if it is from a blogger who is someone I respect.

Tools for managing an Agile effort are another matter.

My one general rule about Agile Tools is DON'T (if the tool is in the form of a computer application). There are better alternatives. (I am not talking about refactoring tools, testing tools, etc. here - but the management tools, the communication tools, things like that).

Agile is best done manually, and the computerized management tools will in most cases be counter-productive IMHO. (Or IMNSHO - which is In My Not So Humble Opinion).

In a nutshell: You learn Agile by study and practice and doing and talking about the doing and so on. Tools often block learning by forcing you to follow what someone else decided is useful. Tools needlessly complicate the simplicity of Agile. Simplify, simplify.

Like the Agile Manifesto says: We value Individuals and Interactions over Processes and Tools.

I take that to at least partly mean that we get a lot more value out of focusing on empowering Individuals and improving our ability to interact well as individuals than on following some Process or using some Tool.

I have only one rock solid, immutable rule, however (that I reserve the right to change anytime): Continuously Inspect and Adapt - continuous improvement of our thinking, our understanding, how we learn, how we get along, our principles, our practices, our processes, our tools, etc.

So, if I found a tool that looks like it would bring me value, I would certainly investigate it, try it, and use it if it proves to be userful. And I would continually evaluate its usefulness. But typically - I follow the rule of DON'T when it comes to computerized Agile management tools.

Right now, my favorite tools continue to be physical ones - white boards and erasable markers, sticky notes (small) and sticky notes (huge), 3 x 5 index cards and Sharpies, face-to-face interactions and information radiators, blank flip charts and a digital camera, eye of newt and toe of frog (to paraphrase Shakespeare)."

Best Books on TDD, Agile, and SCRUM by Woody Zuill

My friend, Woody Zuill, is a developer and manager that I respect an awful lot. Recently he was asked to recommend great books on agile software development. Since Woody is always reading, he seemed like a great guy to ask. His response was thoughtful and interesting, so I thought I'd post it below:

"The books I've found useful all have holes in them. You have to get a fair amount of bad to get a small amount of good.

- For me, the Lean books by the Poppendiecks were probably the most good with the least bad.

- Kent Beck's XP book - both editions. I think you need both to get it all. These books have been very useful to me. A lot more real stuff and real thinking than most of the "How To Agile" books.

- Kent Beck's TDD book

- The second edition of Alistair Cockburn's book - Agile Software Development: The Cooperative Game. I think the first edition missed the boat in a lot of things. I think he must have learned a lot by the time the second edition came out. I don't know how experienced he actually is, but I like the nature of his book. Note: His book on How to Survive an OOP project was one of the worst books I have seen.

- Of course, Michael Feather's Legacy Code book is great. I recommend that for all developers.

- And Bob Martin's Clean Code and Agile Software Development books are must reads. The Bob Martin Agile book is overall probably the most useful book I've read (on software development) - but it is a hard read in some ways, and very difficult to sort through.

- I found Diana Larsen and Esther Derby's Agile Retrospectives book very useful to adjust my thinking about making teams work well.

I used to like Mike Cohn's books on estimating and so on - but only barely. Not so much anymore. Same with Ken Schwaber's Scrum books, in some ways I wish they were never written.

I'ver read about 20 or 30 books on the topic, and flipped through a lot of others. Most are misleading at best. Knowing what I know about things in general, I suspect a lot of this garbage is written by people who don't really know what they are talking about and aren't able to admit it to themselves. I want to believe that - otherwise the authors are being purposely misleading or deceptive and I am not ready to accept that.

There is one book that I really loved, and felt the guy was actually right on - but I searched all over the Internet tonight looking for it and couldn't find it. When I get home I'll look around and see if I can find it. [ I found it: "Sustainable Software Development: An Agile Perspective" by Kevin Tate. I must have "loaned" it to someone because I couldn't find it anywhere at home. I remember it as being very good and humble - but I read it about 5 years ago and haven't seen it since so a re-read is in order, and I reserve the right to change my mind about its usefulness. ]

Well... there have been a lot of good in a lot of those (and other) books. And for me, the main use was to help me think through things. There is a lot of garbage to sift through, though."

Great stuff, huh? Below are links to all the books he references in the email:

Kent Beck's Books

Agile Software Development: The Cooperative Game

Working Effectively with Legacy Code

Bob Martin's Books

Clean Code

Esther Derby's Agile Retrospectives

Mike Cohn's Books

And the gem:

Sustainable Software Development

Mind Map Software - Free Mind

A friend of mine, Chris York, turned me on to mind mapping as a way to flush out projects and requirements. I love it.

Mind mapping is a way to document and diagram meeting notes, while the meeting is taking place. It allows the meeting to be a freeform expression of thoughts, while maintaining the general topic.

During meetings, conversations tend to move from one topic to another, seemingly directionless. This is an excellent place to capture salient points about a software or technology project, without overcontrolling the meeting. It can also help to avoid repetition, because you can go to a branch on the map and add or remove detail as needed.

You can also use mindmapping outside meetings to organize your own thoughts and projects. It will help you take a general idea and create concrete action items and ToDos.

Here's some info on mindmapping:

Mind Map Wikipedia Entry

Here's FreeMind, an open source, java software package that will help you implement it:

FreeMind

Agile Development - Not A License to Skip Steps

We've all been part of software development projects that didn't have a very good project plan. I believe that it is still possible for a project to be successful without a project plan, but it introduces unnecessary risk. A properly agreed upon project plan will not eliminate that risk, but it will greatly reduce it. Proejects without planning documents are about 50% successful. When they have a plan, they are about 90% successful. That is independent of developer talent.

Often as agile developers, we skip some of the SDLC steps. Agile does not mean that SDLC steps are skipped. It just means that they are compressed into shorter, more frequent release cycles.

Here are the SDLC steps that are mandatory:

Planning/Design
Development
Review
Testing
Rollout
Support Plan

The two steps that are most frequently skipped or inappropriately shortened are arguably the most important: planning and testing. This is just a friendly reminder to review how those steps are implemented and delivered.

The Ideal Customer: One Person Who Calls The Shots

Further reading from Mr. Parmenter’s “Key Performance Indicators”, unveiled this nugget; “Any layer between the CEO and the [KPI] team indicates that Step 1 has not been successfully achieved. This point is so important that the project should not proceed if the CEO does wish to be involved in this way.”

Mr. Parmenter’s point is that the KPI project team should report directly to the CEO and no one else.

I was just talking to my oft-quotable, former business partner, Roy Allen. He said, “I only want to work with customers who have a single person who is responsible for the entire organization, and that person mandates what the other employees of that organization do.”

In other words, Roy likes decision makers who actually make decisions and he wants to report directly to that decision maker. He feels like that’s the only way to ensure success of his projects at that organization.

I don’t know about Roy’s projects, but Business Intelligence projects need a top-down mandate in order to succeed. I don’t always get to report to the CEO, but I love it when I do.

I'm Not Pete Rose

I went to Lake Havasu with my old business partner, Roy Allen, this weekend.
While we were out boating with our families, hanging out in the nice cool lake, avoiding the 120 degree heat, he said something pretty interesting.
He said, "You know your problem, Ike? You suffer what most of us suffer from. You are a terrible player-manager."

After I got over my shock, I asked him what he meant by that. He explained that there hasn't been a really good player-manager in baseball since Pete Rose, and even he wasn't all that great. He said that in a services firm, there are players (billers) and there are managers, and you can't be really good at both. You can stink at both, or stink at one, but being good at both is not an option. He explained that someone has to play the game and someone has to watch the players objectively, because only the manager will have good insight on how the game is progressing.

After some thought, I totally agree. And since I find consulting, teaching, and creating solutions so much fun, it looks like I'm going to need a full-time manager for the rest of the staff.