Tag Archives: backlogs

Publishing Your Ebook For Nerds – Lessons Learned

Working on wrapping up my third e-book. It’s a book on how to make and manage effective backlogs, or the lists of things both teams and developers do. The first two were kind of a lark — although I was trying as hard as I could, I realized that this was something that was going to take a while to learn.

This time around my e-book is much larger, and I’m hoping to hit the mainstream, both in terms of content and quality. Most all organizations have the job of coordinating their work both globally and locally, and I’ve made the book as a lesson wrapped in a story. I figure either you’ll like the lesson or the story, maybe both.

After spending several days fighting tools, I thought it’d be good to capture what I’ve learned. If you’re a tech person who wants to write an e-book, this’ll help you get from words to e-book format.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Making Of Agile Program Management In 15 Minutes

Yesterday I finally got around to doing something useful with one of my Christmas presents, a Wacom Intuos5 digitizer tablet. For a sample project, I created a 15-minute video about #agile program management — “Agile Program Management in 15 minutes

I bought the tablet because I found myself doing a lot of training using the whiteboard, and I’d like to re-use some of that training instead of having to sketch things out over and over again. (Videos and pictures of whiteboards work, but they’re far from optimal)

So this video came straight from a talk I gave to some Agile program managers (RTCs) a few weeks ago — all the material was on photos on my cell phone. I re-sketched the diagrams using Photoshop and the digitizer — while recording with Camtasia Studio

Later, using CS, I sped up the drawing (you don’t want to watch me draw) and added the narration. Of course, there’s a lot more I could do once I get this format down — callouts, hotspots, loops, user input, adding web cams, etc. But for now this was just a proof-of-concept.

The original diagramming took about two hours. Doing it all for the first time like this took about 8 hours, with another 2 or so spent in video editing mode. Fair warning: video editing uses a freaking lot of HD space and memory. I think for the 15 minutes of video I produced (around 15MB) the raw footage was over 70GB.

Fun stuff, though! Can’t wait to do the next one.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Why your programming skills suck at project management

I was working with an Agile program doing planning last week, and we were all busy creating our release plans and beginning to scope out our product backlog. Every team was using big visible indicators of work, usually post-it notes and blotter paper.

Except one. As we started socializing our work, talking about dependencies and identifying opportunities to refactor, one team came up and presented their backlog on the projector using a spreadsheet. Everybody stopped while one person went down each line, item-by-item, for 100 items.

This kind of meeting, where somebody grabs a projector and folks stare at a wall for hours, is one of my pet peeves. But these guys were new and I saw it as an opportunity to coach them later on. I timeboxed their presentation to limit the damage, then we all managed to complete.

At the end of the day, when we were getting feedback, I got quite a surprise! The group who didn’t physically work with their backlog thought that all this post-it and physical stuff was so much rework. Why not everybody just complete their work ahead of time and we could all show it on a projector? Ten teams, all with hundreds of items on spreadsheets to go down line by line, all day long.


They also thought the 3 hours we spent doing the same work took too long! Go figure.

I had to come up with a respectful way to tell them that this is a bad idea.

“You know, the way you think about backlogs, a big hunk of data to be created and managed, is not actually the way they work. The wonderful skills you have as a programmer or analyst are actually not applicable here. The goal here is not to work with the data, it’s to work with what is between your ears. Your brain. We are optimizing the transfer of information using humans, not computers. That means that there’s a whole new set of rules to deal with.”

I don’t think they got it, but most of the other teams knew what was going on and had my back. So it worked out.

But there is a teachable moment here. As technologists we are used to moving data around on machines. This is a completely different universe from optimizing the behavior of people to understand and attack a problem. People are not computers.

There are a lot of little consequences from this. For instance, people can only compare so many items at a time, so we usually limit comparisons to 2 or 3 items. People can only remember so many items in a meeting, so we limit our lists to 20 or 30 items. People read more by body language than by words, so we put them physically together while planning. People are more likely to make good tough decisions early in the day, before they reach “decision fatigue”, so we front-load the work. And so on.

Some of this stuff, of course, is unproven pscyho-babble. Some is not. What the Agile community has been doing is empirically testing these various theories to see which ones work well and which ones do not. As practitioners we have a big list of “games” and principles the games are built on. We add some in, see how the team reacts, then adapt. That’s why Agile is different from other methodologies. Agile is a marketing term around best practices for iterative and incremental development. That vagueness is its strength, but it can also drive newbies nuts. It is entirely different from the kind of yes-no, off-on boolean logic most of us deal with in our jobs everyday.

Or to paraphrase a famous presidential campaign, it’s the people, stupid.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Backlogs Redux

Spent some time today gathering together the many ways Agile Backlogs are wrong.

It was a painful journey — very sad to remember the different, many ways we screw up doing backlogs. But it was for a worthy cause: I have a new microsite positioned around Agile. Part of the site is a bunch of landing pages, part is a blog.

I’ve never blogged tightly around one subject before — quite frankly, the concept drives me nuts. But I’m wiling to give it a go. I have a lot of experience with Agile teams. Perhaps I can take some of my SEO/Microsite experience, some of my Agile experience, some of my e-book experience, and make something useful out of it. Who knows? Never know unless you try.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.