I just finished reading Agile Estimation and Planning by Mike Cohn today and thought I’d write up some of my immediate thoughts.

This book is absolutely jam-packed with exceedingly practical tools and techniques. It’s also very well sectioned and organized, so it will definitely make for a good reference and guide in the trenches.

The main thing that sets this book apart from the rest, is that it shows you how to deal with things. Having participated in agile development on several small and large projects, I feel like this book really captures a lot of the real-world challenges you are likely to encounter and shows you how to deal with them.

Each chapter walks you through one fairly isolated subject; theory and examples. The last chapter takes you through a case study, where a lot of the tools and techniques presented throughout the previous chapters are applied.

Here are some of my key take-aways from this book:

• Insight from an experienced agile practitioner on what does and does not work
• Being more conscious about factors to consider when prioritizing features
• Understanding the differences between date-driven and feature-driven projects
• Advice on when and how to forecast a team’s velocity
• Very useful techniques on how to split, merge and taskify user stories
• Exciting tools for financial prioritization of features (very unique for its genre!)
• Two interesting tools for obtaining a feature’s desirability
• Knowing when and why to estimates in different units and ranges
• Understanding when and how to use “feature buffers” and “schedule buffers”
• How to use release and iteration burn-down charts more effectively
• A useful template for writing “iteration reports” if need be
• Some new techniques for interteam dependencies on multi-team projects
• Answered a lot of small, pointed questions that have been lingering for a while

I would recommend this book to:

• Product Managers/Owners, marketing people and C-levels
• Any *manager who need practical advice on agile software development
• Developers who are above average interested in project planning and execution
• Anyone who wants to introduce (or improve) agile practices in their organization

This book might answer a lot of your questions. It answered a lot of mine.

Despite an overwhelming amount of really good books on the subject, there still seems to be a surprisingly high demand for information and insight from real-word experiences on what it means to be Agile. Stories from the trenches, so to speak.

This series of (upcoming) blog posts will be my humble attempt to share some of my candid thoughts and experiences. Perhaps someone else out there could make use of it for the greater good or, if nothing else, at least I will have lightened my head a little bit.

Oh, and if you have any questions or feel like you have some related story or trick that you would like to share with the world, then I would be thrilled to have you as a guest blogger in this series. Please drop me a line via my contact form if you’re interested.

Stay tuned for the first post in the series! Subscribe here (RSS).

That was a bug. In fact, it was the first computer bug.

Word quickly spread that they had “debugged” a computer over at Harvard, giving birth to the term we developers love to throw around so casually in our offices.

I have seen thousands of colorful “bugs” throughout my years in the software business, but I have yet discover a bug while looking for the source of the problem. In the end, most of them were caused by people, and a few by compilers or faulty hardware.

If they aren’t really bugs, then what are they?

Since they are primarily caused by people in one way or another, my best guess would be to call them mistakes. Honest mistakes of course, since most of us wouldn’t make mistakes on purpose (except for the sake of experimentation or for comical effect).

It’s okay to make mistakes, as long as nobody gets hurt and we learn from them.

I can’t help but to feel like we are, at least subconsciously, denying and hiding our mistakes when we dub them “bugs.” As if they just “crawled into our code” when we weren’t looking. Unless you can fix it with a can of Raid, it probably isn’t a bug.

Maybe if we called them out for what they really are–mistakes–then we would develop a heightened sense of responsibility and in turn make less of them? Just a thought.

My code is full of mistakes, but they can’t fly. How about yours?

It is so ubiquitous today that we take it for granted. Most of the time we don’t even think twice about it its existence. I’m loving it, but I must admit that I am a wee bit concerned about how it has become such an important part of my daily life.

Thinking back, I vaguely remember the days when I used to get on my bike and go to the local grocery store, where I would read gaming magazines off the shelf and take notes as quickly as possible, before I got shown out of the store for loitering.

At school, the geekier kids would huddle up to share new information; copying notes by writing them down by hand on sheets of paper; memorizing walkthroughs, cheat codes and trading save-games on cassettes and floppy disks.

There used to be a time when I was ecstatic about going to the library to borrow books for self-study. As a kid, when I was playing the piano, borrowing or buying books was pretty much the only way I could get my hands on new sheet music and lyrics, aside from what I got from friends and my piano teacher.

Speaking of music, let’s not forget about borrowing audio cassettes and VHS movies from friends and family, trying to copy them with the aid of a second cassette player, only to get the tape all tangled up and then carefully trying to straighten it out and rewinding the tape manually with a pencil.

In a weird way, I kind of miss those “analog problems.”

I especially miss the feeling of satisfaction after having solved a problem on my own, without having the possibility to find the solution online. Obtaining and retaining knowledge in my head has become less of a priority today, now that I can look up anything online within a couple of minutes. Is this a good thing? I’m still undecided.

I guess what I’m trying to say is that, I really do enjoy the Internet, but there are many things that I miss from the time when it was still just a dream.

What do you miss from the days before you got all tangled up in this web?

As soon as we walked through the door (fashionably late), we were greeted by friendly like-minded people, a truckload of pizza and an introductory slide reading: “Automate All The Things.” With that, we all knew that this was going to be good meetup.

Roy walked us through a series of tools and methods used for automating the build process; meaning, everything from the point where you commit your code, up until when it has been tested (automatically, of course) and deployed. We also got a good introduction to concepts of Continuous Integration with FinalBuilder and TeamCity, as well as some “colorful” discussions related to Team Foundation Server.

Then we got to see some of the build-patterns that Roy is working on for his upcoming book, Beautiful Builds. It was interesting to see how one of these patterns (“Build Script Injection”), resembled a familiar home-made build system I used to work with. Aside from patterns, Roy also wants to establish a common language amongst developers, for discussing build-related subjects.

In-between slides, we had several group discussions on related topics. The ones that I enjoyed the most were the discussions around breaking the build and how to perform automatic deployment, in relation to database changes.

All in all, it was a very good meetup with many good discussions, and I’m looking forward to future meetups at Bouvet. I just love it when larger tech businesses share their knowledge and expertise with the broader software community. Thanks, guys!

Update 06.02:

As requested by @codingsanity, here are some details on our TFS discussion. It’s been a few days since the meetup now, so please excuse me if it’s a little off.

It was then pointed out that TFS was not mentioned in Roy’s slides, along with a heap of other build-related tools in the same genre. Roy then explained that, in the myriad of tools available, he had simply forgotten to mention TFS, and that it was not omitted intentionally. Again, emphasizing that it was a descent choice for source control.

I believe it was Roy who mentioned that TFS focuses on “doing everything okay, rather than doing one thing really well” (or something along those lines), and that he thought TFS worked well for source control, but, when it comes to build systems and continuous integration servers, he would likely look elsewhere.

Apparently, there were some people in the group, and one person in particular who had more experience with TFS, who argued that it was more an issue of understanding how to set it up and use it efficiently (if I recall correctly). This lead to some discussions amongst those who had negative experiences with TFS, and those who liked it.

I think that, in the end, most of us understand that these are just tools, and the discussions resembled “the religious wars of the text editors.” As Roy also pointed out; just because you have the best tools, doesn’t mean that you know how to use them.

Again, it’s been a while since the meetup, so I cannot say that this is 100% accurate, but that’s what I could recall at this time. Next time, I will try to be more attentive to these kind of discussions, to capture more of these things in the summaries.

Thanks for asking, Sean!

Mr. Weinberg is a thoughtful fellow with a lot of real-world experience. He is also an excellent writer, who makes good use of familiar comparisons and vivid short stories to illustrate his points and make them stick. I caught myself frowning, smiling, snickering and even laughing out loud on the train a couple of times while reading.

I also felt like this book was well grounded and offered a lot of hard-earned insight. It’s also packed with memorable and thought-provoking gold nuggets.

I made 139 highlights in this book; here are 5 of my favorites:

Once you eliminate your number one problem, number two gets a promotion.

The better adapted you are, the less adaptable you tend to be.

When you’re not terribly smart, it helps to be a good listener.

Your primary tool is merely being the person you are, so your most powerful method of helping other people is to help yourself.

A small system that tries to change a big system through long and continued contact is more likely to be changed itself.

This is definitely one of the best books I’ve read in 2012 and I heartily recommend it to everyone who is even remotely interested in the world of consulting. Even if you’re not interested in consulting, chances are you might still enjoy reading it.

Thank you, Gerald!

You probably also know how hard it is to get into this state of mind and, once you’re there, how easy it is to get yanked out of it. This phenomena is essential to creative “knowledge workers,” like professional programmers, who need to keep a lot if information in their head at the same time. You might spend 15-30 minutes on “getting into the zone,” and then you get pulled back out in a matter of minutes.

That’s why knowing how to manage interruptions is so incredibly important to software developers, in order to stay happy and productive. It’s also important as a team and as a company to understand that, when you’re working with other knowledge workers, not to interrupt your teammates while they’re in the zone.

As a company, you want to do your best to create a culture and an environment which allows people to be “in the zone” as much as possible, to maximize on your overall productivity. With this in mind, it’s interesting to see how many software companies today seem to favor vast open offices, and nurture a culture and communications model where disruptions are diverse and bountiful; downright encouraged.

Some of the most common “zone-disrupters” might include:

• Managers (like myself) and other non-programmers coming by your desk to ask random questions or just to check out what you’re working on
• Other programmers asking you trivial or non-important questions, which they could easily have looked up online or deferred to your lunch break
• Your desk is located in a “hotspot” where people constantly walk around your desk to get coffee, use the restrooms, talk to other people, etc.
• People around you having conversations, in person or via Skype, etc.
• Random noises, like squeaky chairs, people tapping their feet agains the floor, humming and whistling, loud music from your neighbors headset, firetrucks constantly roaring by outside, construction work outside the building, etc.
• Phone calls, intercom and announcement systems, email and meeting notifications and of course that mandatory IM system you’re using for internal office communication, where people who have been yanked out of the zone are chatting about random things like programming language X, cryptography, internet security and how awesome Google is for their giving their programmers “20 percent time”

The list goes on ad infinitum, but I think we can mainly group these things into two categories; those things we can control by ourselves, and the things we cannot. For example, it’s easy to close your email application or turn of the IM notifications, but it would be considerably harder to keep people from going to the restroom or helping your fellow developer shake the habit of drumming on his desk while he is in the zone.

Also, I’ve found that there are at least two different types of disruptions; those which prevent you from getting into the zone in the first place, and those which yank you out of the zone while you’re in it. Some things, like soft repetitive noises, could prevent you from getting into the zone, but it wouldn’t yank you out of it. Kind of like when you’re sleeping; once you’re in deep sleep, it takes more than a dripping faucet to wake you up. This is, of course, highly specific to each individual.

As developers, I think we need to get better at understanding what our coworkers need in order to stay productive. And a lot of companies, especially software companies, really need to put a lot more thought and effort into facilitating for their developers and coaching people on how to manage interruptions.

We all need to take responsibility for creating our optimal work environment and nurturing a healthy culture that allows people to focus. I have some ideas and techniques that I want to share with you, but I’ll save that for a future blog post.

What techniques do you use to get into the zone and manage interruptions?