A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?’”

“It will take one year,’” said the master promptly.

“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”

The master programmer frowned. “In that case, it will take two years.”

“And what if I assign a hundred programmers to it?”

The master programmer shrugged. “Then the design will never be completed,” he said.

So true.

Stay small.

Over the past couple of days, I’ve been pulling together a simple Information Radiator for CruiseControl.net. The idea behind the project is to use the power of visualizations to provide simple, visible, and informative displays that expose the current-state of your automated continuous integration builds.

I threw this app together very quickly a week or so ago and I’ve been amazed at how addictive it’s become. In our team room, we have a dedicated monitor that is always running the application. The result is that you know exactly where the builds stand as soon as you enter the room.

I initially wanted to put this together as a temporary solution to picking out what items we will use to show our build status. We always bounce back and forth about Nabaztag, orbs, lava lamps, and other physical things to show our build status. It’s usually easier to find an extra monitor than it is to get a purchase request approved for a wireless-enabled rabbit. Big Visible Cruise is the same idea, it’s just a visualization instead of a physical device. Judging by how much we all enjoy seeing it, it will probably stick around in addition to any physical device we pick up.

You can find out more about the project at http://code.google.com/p/bigvisiblecruise/. After the holiday I’ll post some pictures and explain how we are utilizing the big display in our team room.

In the meantime, you can likely get an idea from looking at the display while it’s monitoring three different projects in the following screen shot…

This shows that I have three projects (Foo, Bar, and Some Project) being run on my CCNet server. In this example Foo and Bar are successful and Some Project is broken.

The other state that isn’t represented in the pic above is the “building” state. When a project is building, the row representing the project will turn yellow.

By default, BVC will poll every 15 seconds. I recommend using BVC with CCTray so that you have a big visual display along with auditory clues about your build process.

Big Visible Cruise is being released under the MIT license.

If you’re interested in WPF and/or information visualization, I’d love any contributions

I plan on providing some interesting visualizations over the next couple of months. Let me know what you’d like to see on the RoadMap page.

Today I re-installed Business Edition. Maybe now I can get a little work done.

The tools that I use on a daily basis include Microsoft SharedView for screen sharing and Skype for voice and video. The combination of these two tools seems to work very well (even over wireless).

SharedView is still in beta, but it is a very nice, minimal, and responsive tool. With the exception of the ads (integrated into the tool), I’m impressed. I’ve used many other tools in the past but this one just seems to fit the way I work better. The features like the ability to see other mouse pointers, clicking, and highlighting is a very nice feature.

Right now, the only thing that consistently bugs me is the quality of my headset (junk). I’m hoping to pick up a new one in the next couple of days.

“In Jeet Kune Do, one does not accumulate but eliminate. It is not daily increase but daily decrease. The height of cultivation always runs to simplicity.”

-Bruce Lee

Could your software use a litte Jeet Kune Do?

Think backwards, throw out your preconceived notions, forget about dependencies, and ignore your constraints.

If you search long enough, you just might find the right problem to fix. When you focus on the right problem, you might actually surprise yourself with what you can come up with.

Q-Drum solved the right problem.

The real problem…

A novel solution…

One day, I realized that I spend a whole lot of time taking notes and very little time reviewing or referencing them. Based on this realization, I decided to experiment with not taking notes at all. This worked out much better than I ever thought it would. No paper, no laptop, no distractions. So far, it’s been a great experience.
I’ve realized that there are some situations where writing things down or drawing visuals helps me digest things easier. In these cases, I’ve narrowed everything down two different techniques that I use consistently. Here’s what I’ve come up with…

Hipster Note Taking

This is my favorite technique. I usually take out a couple of 3×5 index cards and use one for drawing a mini-mindmap and keep the other one handy for any action items that I take out of the meeting. There are many times that my cards stay blank. When I leave a meeting with mini-mindmap, I take the card and spend some time thinking back through the concepts. After I mentally review the concepts, I tear up the card.

MindManager Note Taking

This is my electronic version of the technique above. I use MindManager to collect my notes. After the meeting, I review the mindmap, reorganize it, think about the concepts, and delete the entire mindmap.

As I’m processing the information from the above techniques, I drop the relevant information into one “master mindmap” that I use to collect the things that I know that I’ll need to remember. After about six months, I only have a handful of things on my “master mindmap.”
So far, this is working well. I feel like I can devote more time focusing in the meetings and thinking about the topics. It feels good to be note-free.

The only numbers that I had seen at this point were the numbers cited in Agile and Iterative Development: A Manager’s Guide by Craig Larman. To say the least, the numbers were very impressive: Of those polled, 93% saw increases in productivity, 88% increases in quality, 83% improved stakeholder satisfaction, 49% reduced costs, and so on. I dropped these numbers in the collateral and I made every one of the sales members happy.

A few months later I was looking for some deeper numbers and I started to dig deeper for more quantitative data. The first place that I went to look for numbers was the study used that came up with the above numbers (by Shine Technologies in 2003).

When I started digging deeper, I realized that this survey has huge room for error. I’m not an expert on surveys or quantitative methods, but what I read didn’t leave me feeling convinced that it was worth publishing and standing behind the results.

After digging a little deeper, I noticed that these numbers (that I had been advocating) were based on a web-based survey that had only been taken by 131 people. Yes, 131 people and web-based. Ouch.

You can find the survey here.

Now, I don’t want to completely discount the survey and/or the results. This is important information; but I’m just not comfortable presenting these findings as “evidence” that agile works. I’m just not comfortable putting them up on my company website and I’m not comfortable putting them in my presentations. I believe in agile methods, I just don’t believe that this study “proves” that they are a valid alternative.

An interesting thing that I have noticed is that many individuals and many companies have used this survey as justification for agile initiatives. Last week (at Agile 2007) I saw these numbers presented multiple times in slide decks and I’ve seen them on plenty of web sites of vendors that are offering agile services.

Anyway, I just thought that this was an interesting bit to share about how you should always know more about the survey results and numbers that you use to backup any claims. Make sure you can stand behind your numbers and that you find out the information behind the numbers.

My favorite sessions included:

(Follow the links for the abstracts, presentations, and handouts)

1. Agile Enterprise Rollout–The Greening of the Software Industry (Jean Tabaka, Ryan Martens)
2. The Role of Leadership in Software Development (Mary Poppendieck)
3. Learning Kaizen from Toyota [with MindMaps] (Mary Poppendieck, Kenji Hiranabe)
4. I Don’t Like Mondays – Improving Agile Team Collaboration Events (Jean Tabaka)
5. Reaching New Heights: Learning to Adapt is Essential (Susan Ershler)
6. Agile adoption at Google: Potential and challenges of a true bottom-up organization (Mark Striebeck)
7. The Agile Enterprise: Real World Experience in Creating Agile Companies (Jeff Sutherland)

Some of the big-picture realizations that I came to:

• Mary Poppendieck has turned into the Tom Peters of the software industry (well-deserved).
• Lean thinking has started to move to the center of the agile universe (finally).
• Executable specification / story-driven development is moving to the mainstream (finally).
• Everyone wants to scale agile.
• Everyone wants to distribute agile.

A few things that I’m concerned about:

• Lean has moved to buzzword status. A lot of people are talking about Lean but I don’t think the majority understand the essence behind it. I think this will get better.
• Everyone wants to make “Enterprisey” software with agile teams.
• There are a lot of “agile” consulting firms that are full of shit.

And some other random thoughts…

I think the fact that everyone is focused on “scaling” agility to large teams and distributed projects and that there will be a lot of agile disasters over the next couple of years. Now that the bigger software companies are moving to agile, the teams are getting too big and they are adopting agile in scary ways (too big, too fast). I think that you need to evolve to big teams, not start out there. I would also (passionately) argue that you should focus on how to have smaller software instead of how to scale agile teams to accommodate large software. I seem to be in the minority.

Lastly, I really think that the organizers of the conference need to step it up. The programs sucked (hard to read, hard to navigate, mis-prints, missing pages, etc.), the event was really hard to follow (talk duration, locations, topics), the location of the conference sucked (tight hallways, hard-to-find rooms, etc.), and the beverages and food was awful (a big thank you goes to Rally for providing everyone with bottled water).

I certainly appreciate that everyone worked hard to put this together, but I expect the basics to be nailed for a major conference.

I’m going to be at Agile 2007 this week.

The sessions look great this year

If anyone is hanging out and interested in meeting up, shoot me an email (b e n c a r e y @ g m a i l . c o m).

The ultimate value of the presentation is much more than the deck that is being presented, but I have noticed that the interestingness of the presentation and the simplicity/story/thought that goes into the deck usually seem to be in alignment. If I walk into a presentation and I see the standard corporate title slide, I almost immediately know that I’m getting ready to plunge into a an hour or so of straight bullets. The standard title slide isn’t 100% as a leading indicator, but it’s pretty high.

There are so many better ways to present and to use a slide deck to help with messaging. If you’re interested or intrigued by giving great presentation and being a better communicator – I highly recommend Presentation Zen. This is the best site out there for tips on communicating, presenting, and giving effective presentations. If you are new to presenting or if you just want to spare your co-workers or audience of sitting through another mediocre presentation, check out the site. The book recommendations are always top-notch as well.

I’ve recently started instantly deleting any emails that are over a page to read. This is mostly because I don’t care to put the effort into reading emails from individuals that can’t (or won’t) take the effort to boil the email down to core essence of what they want to communicate. It’s working pretty well so far.

The 5 Sentences idea sounds like it can help out as well.

I have to get one or two of these things for our current project

I’ve always viewed teams as teams and recognized good teams by “that feeling” that you get when you participate in one or see one in action. Beyond “that feeling”, I really hadn’t thought about the categorization of teams beyond a “good” and “not-so-good” level. This book has been very interesting because of the research and observations that they have done in grouping the different categories as well as comparing and contrasting the different types.

Throughout my time in the IT industry I’ve seen all these categories of teams and participated in each respective type. One very relevant point from the book is the discussion about the differences between working groups and teams. This really hit home with me because of the methodology changes that I’ve been involved with as both a consultant and an FTE.

The image below shows the different categories discussed in the book and the evolution of performance when moving along the curve.

One thing that I’ve noticed from starting up various initiatives to move towards agile methodologies over the past couple of years is the thrashing that occurs when you move from a command-and-control structure (usually accompanying traditional methodologies) to a self-organizing structure (more prevalent with agile methodologies).

It’s rare that a new agile team hits the ground and starts performing as a “high-performing” team in the first couple of months. I’ve never seen it happen when the team members are coming from traditional methodology backgrounds. I really think this can be expected because there is so much happening so quickly. This scenario is usually very disruptive and usually overwhelming from the standpoint of the individuals on a new team.

While the leap from “working group” to “potential team” can be a rough experience for many individuals, the progression from “working group” to “real team” (and possibly to “high-performing team”) is a pleasure to watch and a pleasure to be involved with.

So, what is the difference between a “working group” and a “team?” The book recognizes the basic distinction as performance.

“A working group relies primarily on the individual contributions of its members for performance, whereas a team strives for a magnified impact that is incremental to what its members could achieve in their individual roles.”

I think that the giant leap in forming a team for most individuals from a command-and-control structure is the blurring of roles and shared accountability that occurs on a team. Most individuals in command-and-control organizations or models think from the standpoint of individual contributions while a true team focuses on mutual accountability and the contributions of the team. This is a hard leap to make, but the benefits (both organizationally and personally) are usually tremendous.

Why Penguins Have No Commanding Officer [InsideKnowledge]

I spent this past Thursday and Friday in Boulder going through a Certified ScrumMaster course at Rally. I’ve been working in agile environments for quite a while now and I’ve used XP and Scrum on quite a few projects over the past years. I wasn’t really sure what to expect from the course, but I can now say that it was definently worth it. The class was really good and well worth the time to attend. I learned quite a few collaboration techniques and enjoyed listening to the experiences of the instructors and participants.

I would highly recommend the course even if you have a lot of experience with Scrum. I can also highly recommend Hubert and Tamara.

The last time I checked, my job was to solve business problems or create business opportunities for my customers. If this is the case, then why should I care if scope changes? Shouldn’t changing scope be a good thing? If the scope is changing then it likely means that the business has found a new opportunity or that we have received feedback on something that could add significant value to the market or to our customers. If my heart is in the right place and I really care about delivering value then change can be a good thing.

The problem with “scope creep” is not changing scope; the problem is really a process or mindset that doesn’t allow for change. Pouring concrete on your requirements might help with predictability, but it sure doesn’t help you build great software.

It’s strange to me that most consulting firms completely gloss over the idea of building internal networks to expand knowledge and improve collaboration for the consultants that work there. This is a huge benefit for the consultants, the consulting firm, and the customers that use their services.

Now that I’m on the other side of the fence and I’m looking at a variety of different vendors, this has turned into a key criteria during the vendor selection process.

If your company is having trouble attracting fabulous people, it is because your company sucks.

- Tom Peters

I don’t think it can be said much better than that.