I just remembered, over this past weekend, that a long time ago I had submitted an article for the ThoughtWorks Anthology. I had actually gotten accepted for the book - with a sort of caveat. Martin Fowler told me that I’d have to improve the essay - to make it actually helpful to people reading it. Great advice, of course!

Except that I’m way too lazy and couldn’t be bothered.

So here it is, in it’s original unedited glory. Against All Oddities by Amit Rathore. I’m also too lazy to convert it into HTML, let Google do that, I say!

I just re-read Maverick by Ricardo Semler, and having just read The Cluetrain Manifesto this past month, I feel like there could be some very serious synergy between the two.

First off, Maverick. If you recall, Semler talks of some fundamental truths about companies, markets, about being effective, agility, and about employees. The most basic of these forms the foundational element of Lean Product Development Systems as well - the fact that ordinary employees can generate extraordinary results if they truly engage in the company’s business. It is the management’s responsibility to make it possible for them to do so with the least amount of organizational friction. The important thing is simply to remember that most people want to do the best they possibly can!

Semler, of course, also talks about a whole bunch of other things they did at SemCo, and a lot of them are worth reading the book for - for instance, employees setting their own salaries, and a transparent compensation structure. Trust me, get the book.

I already talked about the Cluetrain Manifesto. I’m excited by the possibilities of marrying the two (they’re not conflicting at all) philosophies. I wonder about the power of an organization that does what Semler advocates, and that also extends the organization to truly include customers the way the Cluetrain Manifesto describes.

What would this imply, and what would such a company look like? I can’t really say, but I know I’d like to experience one. Maybe someday, yewoh might be such a place?

I just finished reading this book called The Cluetrain Manifesto. I read about it on someone’s blog a long time ago, and had it on my reading list for a while. Then recently, my close friend Kiran recommended it to me again, and so I picked it up.

I liked it! Sure, it is a little repetitive at times - the book is kind of a collection of essays by a group of four authors - and they cover overlapping grounds. However, for most people the book will be one of two things - a) a whack on the side of the head, or b) a reinforcement of what they might have been thinking.

The basic premise is simple - the Internet has changed the way markets behave, and companies need to respond and engage the new markets in this new way as well. Nothing new, huh? Still, how many companies are truly doing it?

In fact, from the above, it might even seem a rather dated book. After all, it was written in 1999, when it was a fact that the Internet was new, and not well understood, and companies were jumping onto the bandwagon. The authors explain that the Internet is not just some new medium to advertise on, or set up websites that dispense corporate-speak. It is a place where people (existing and potential customers) can talk, have a conversation. And these people talk about companies, and share experiences about them. They swap reviews - both good and bad, they analyze companies’ strategies, they come up with ideas for improvement, so on and so forth. It is up to the companies to participate in these conversations and gather what they should from them.

Smaller companies are sometimes good at doing this. They actually know many of their regular customers by name, and gather plenty of feedback and ideas on what they could do more or better. However, there are plenty of companies out there, that even today, do not respect truly their customers, or think they can get away with being a corporation that doesn’t need to truly engage with their customers in a human-like manner. If you’ve ever been treated badly by a large company, say an airline company or a rental car company, then you know what I mean. Most people are pretty clear about the difference in service they should expect when they’re dealing with typical large corporations versus small, mom-and-pop outfits.

And that’s the point. Companies need to get off their high-horse of being a business, and become more like the normal people that work in them. After all, they’re customers too, from someone else’s perspective. Companies sometimes do this during the startup phases. And as they expand (when the distance between the producers and the consumers grows beyond a certain point), they lose this human-ness, and become a faceless corporation that is impersonal and forbidding. If the founders can truly inculcate this and the rest of the principles outlined in The Cluetrain Manifesto, they will find that it becomes another secret-weapon that can be wielded against their more traditional, large corporation-type competitors.

A decent read, I’m sure at least a couple of ideas will stick.

I was just thinking of something, and thought I’d ask people in general.

If process-improvement is supposed to optimize the methodology for better/more output, then why is the default thinking around it ‘additive’? As in, when organizations think of process-improvement, they generally think of things to add to the process - be it documentation, an extra step/approval/review of something, some kind of audit, quality assurance, and so on.

Shouldn’t the default be - what can we remove from this process, and still produce better quality stuff, and more of it?

I don’t quite know what it is, but some project managers really like to measure ‘actuals’. They say it helps them plan better, and that it helps them predict the end-date better. Again, thanks to my love of the dramatic, the title of this article is a tad more severe than what I really mean. In this post, I only make the point that many project managers measure unnecessary things, and often the wrong things - and understanding the what, the how, and most importantly the why, of metrics can make a world of difference to the overall success of a project.

People who advocate ‘measuring actuals’ often mandate their developers report how much actual time they spend working on a user story. So, let’s say that a particular card was estimated at 100 points of work. If the developer pair spends 2 hours working on unexpected build-failures, 1 hour on a staff-meeting and another couple of hours fixing bugs on a story from the previous iteration, then they must report a total of 5 hours less than the total time they might otherwise claim for the card. They must also, of course, report the 5 hours separately.

Often, developers are required to update these numbers on a daily basis. Sometimes even on a per-task basis. (Ouch).

These PMs then subtract the total amount of actual time the team worked from the total available time (capacity) to determine what is sometimes called ‘drag’. The ratio of drag to capacity is their ‘drag factor’, and they then use it to plan the remaining work and predict the end date. I believe this practice is less than optimal for several reasons.

The first reason is that it is painful to report time like this. Ask any developer. It distracts from writing code and breaks flow. And if part of the process doesn’t directly add value to the software being built, it should be a candidate for streamlining. It also sends a signal to the team that tracking/accounting/number-crunching is apparently more important (or at least as important) to the management as the value of the software being built. A related reason is that PMs and HR in certain organizations use these numbers during performance reviews. This, of course, makes the measurement completely useless (because using the numbers in this manner alters behavior too much for the measurement to be accurate anymore).

Another reason I don’t like calculating ‘drag’ and using it to plan future work (and predicting the end-date) is that it simply gives an incorrect answer. This is because a truly agile team that is doing the right things will always see an increase in velocity, iteration after iteration. And so, using drag to project plans becomes less than accurate. That leaves even lesser value in measuring and calculating it.

Now, assuming that the end goal is better estimation of the end-date and a better idea of current rate of development, measuring actuals in this manner is not the best way to achieve it. That’s simply because there is a much easier and more efficient method - it’s called velocity.

It’s called velocity for a reason - it helps answer the question ‘are we there yet?’ Take the analogy of driving a car from city A to city B. Since the drive is long (Google Maps estimate it will be about 12 hours of continuous driving), you make several stops along the way. Making the stops is natural, so when asked how long you might take to get to city B, your answer will usually include those unproductive stops; so you might say - about 15 hours. You don’t say - well, if I stick to the speed limit then I’ll be driving for 12 hours, and I’ll also take a one-and-a-half-hour break for lunch and to recoup a little, and two or three other half-hour breaks. It only matters how much total time you might take to get to city B.

Software development also has a convenient metric like this - and as mentioned above, it’s also called velocity. It is the total amount of work that gets done per unit of time (usually an iteration). This already includes things like meetings, lunches, bathroom-breaks, training, filling out review forms and so on. The total time spent, of course, is a matter of counting the number of developer bodies that were in the team-room for that duration, and multiplying by the number of days in question. Done.

Now - a confession. I do care about ‘drag’. I care about it because by reducing it, the project can move faster. This, however, is what the PM or Scrum-Master should be watching out for during the day, every day. If developers (or BAs or QAs) are being pulled out of the team room into meetings that do not add value directly to the project, then the PM should work the system to get these meeting cancelled or, at least, get the concerned folks out of them. If builds are constantly failing, the PM should sell to management all the benefits that the team will get from an improved build-system. Letting the team refactor ugly parts of the code follows the same reasoning - and sometimes, these refactorings might become rewritings parts of the system. It is the PM’s job to do the cost-benefit analysis with the help of the technical folks, and get permission from management to do the right thing. These things ought to be the goal, not telling management that the team only got 1200 points done because of a 30% drag.

So - the takeaway? Don’t measure actuals the way some people do. Use a ‘drag’ of 0 percent for your iteration planning. Use historical team velocity to estimate team capacity. Be vigilant about the time your team spends on non-project-related things, and fight for them to reduce that time. Enable them to optimize themselves (refactoring, investment in fixing annoyances, better software tools, outings), and watch their velocity increase along with quality. Your job becomes easier, too!

For those who’ve been following along, I recently started a new project team that’s working on pretty much a green-field type of a project. I’ve been using mind-maps to kick things off, in various areas of the teams’ initial effort, and have now extended it as a way to build the functional backlogs that the teams will work on.

Essentially, what that means is this - imagine that we, along with an analyst (or a team of analysts) sit down to brainstorm an area of the application. We always start with the high-level ‘project’, lets call it Todos2Go. Just to retain context, lets also go ahead and list out the high-level functional areas of the application. These include modules we already discussed and elaborated, they certainly include new modules we want to include in our system. So in our example, Todos2Go would start with the basic todo-list creation module. It might also have a collaboration module, a search module with advanced search options, a calendar integration piece, an RSS generation module, an email interface module, a tagging and tag-browsing piece, and others. The analyst team doesn’t worry about trying to capture everything at any given point of time, knowing that they will be revisiting these requirements (the mind map) whenever they need to. So at this point, here’s what we have -

Remember, we’re only capturing functionality from a business requirements perspective right now. Things like config-management, architecture, etc. are somewhat orthogonal areas. They’re captured in a different mind map. Also, we’re not concerned with scheduling right now - as in, when a particular piece might get built. Those decisions will be made based on business priorities, technical dependencies, and developer estimates. So, onward! Lets continue following the analyst team as they keep using the mind map to go further and further into details.

The analyst team picks one module that they’re going to focus on for the moment. They decide that since they’re just starting the project, they might as well pick the one they know best (from previous versions of the software, or from market research) - a basic task-management feature - the Todolists module. So they start to discuss the things the user might want to do, and/or how they would like to break the functionality down for development. Here’s something they might come up with -

The idea is simple. Keep breaking things down as you go down a path of functionality. In other words, go ahead and do plain ol’ functional decomposition. Again, remember to view things from a business requirements perspective. This means that ‘design database schema’ is probably not something that ought to appear on this mind map. The numbers next to the items are simply ID numbers, for tracking purposes, and will be of use later on. This view is what I’ve started to call Story Trees, thanks to a colleague - Roger Marlow.

Also, since most people use Excel to track projects (so do I, and I will continue to do so until Mingle launches), here’s how I capture this meeting artifact (it’s usually a whiteboard thing) in a spreadsheet -

The Parent ID column is simple. It is just the ID of the bubble in the mind map that is a ‘parent’ of a given bubble. This way, a simple script can be written to reconstruct the mind map if needed. The reconstructed version of the mind map can sport color-coding based on status, priority, or whatever else one might consider useful. More on this script (or my version of it) in another blog post.

So, I do hope this was useful. This is a simple meeting technique for project managers to use to facilitate requirement gathering workshops or business analysis sessions. Again, as I mentioned in one of my earlier posts, I do not use software/laptop/projector in my meetings because it is just not a good, interactive way to run a meeting. I use a whiteboard, flip-charts, and Post-Its. Later, I use software to capture it.

Coming soon - more benefits of Story Trees.

P.S. - Please pardon and ignore the horrid use of the generic term ‘user’ in my story list. We typically use personas, the focus of this post however is the story trees.

As you might have read earlier, I recently started a new team that has been chartered with building a suite of new products from scratch. The business folks have been working in the domain for a long time and have built similar products before. Despite that, requirements for the new products have not all been nailed down yet, making this project somewhat of an ideal situation to start a new team. We’re using Agile (Scrum with XP practices) methods, and I’m infusing several ideas from Lean Software Development into the mix.

I used a new tool to kick-ff the high-level planning sessions this time. I’ve been using mind maps (FreeMind, Mindjet Manager, and NovaMind) for a while now: for various things - keeping track of to-dos, planning my personal projects, thinking about high-level goals, brainstorming and brain-dumping, and so on and so forth. I’ve always felt that such an intuitive tool might make for a great way to facilitate work sessions, especially when the work at hand is fairly high-level. An example might be - early stages of planning.

In my opinion, using the tool turned out to be quite a good idea. The first meeting lasted three hours (including coffee and a 10 minute break), and had about 12 participants with me facilitating using a whiteboard and sticky flip-charts. I ended up with several mind-maps including one for the overall project layout, one for training requirements, and another that detailed a particular module. The whole team was able to participate in building it as it was merely a form of a brainstorming exercise, with some extra structure.

Here’s a mock-up of one of these mind maps that got produced at this session -

One possible next step is to pick up the area which needs to be worked on first (actually this will probably be more than one - for example, the architecture-spike and config-management piece will need to be done in the beginning regardless of what else gets picked up) and continue to drill-down into its details. When sufficient granularity has been achieved, the leaf nodes of the mind map can be translated into backlog items (or phrase-level user-stories). Of course, this will mean that the brainstorming will need to be done with an eye towards this end goal - and all the guidelines around writing good user-story phrases will need to be kept in mind.

Overall, it was a good exercise - it was interactive and fun. More importantly, it was a visual way of representing the project and its potential scope - and was a great start at arriving at a shared mental-model of the system. Having all members of the team present (developers, QA, BA, and sponsors) helped a lot as well.

Note: I didn’t use the actual software in the meeting, instead, I chose to draw on the whiteboard and one of the participants (the sponsor!) volunteered to scribe. This let the session be more about the content than about formating and word-smithing. I later converted the notes to soft-copies using FreeMind.