The Idea Backlog

While talking to some co-workers about Scrum, we discussed the initial part of the process: Preparation. This part of the process is one of the less detailed overall, most likely because of the various ways companies have to initiate and validate a project. Most of us had come from more structured development shops where the project initiation process was fairly laborious and usually did not include anyone outside of management until the project was already a go and timelines/details basically written in stone. So the question was how could some of the Scrum/Agile philosophies be implemented to make this a "better" process (Better is always a relative term).

Thinking about it later, I thought of how people have kept up what they call an "Idea Backlog" of things they think up but cannot immediately put the time into them to see them to fruition. I thought using TFS, Sharepoint, or some similar technology so that a company could create an Idea Backlog much like a Product Backlog to facilitate the submission, discussion, and initiation of project ideas.

My thought was that ANYONE would be able to post an item to this Idea Backlog from the highest member of management to the most junior developer. These backlog items would have a little bit of structure to make sure initial submissions were at least minimally fleshed out, but then people would post comments in response to the submitted idea.

So Employee A submits an idea that equipping the engineers that regularly inspect Company XYZ's Widgets in the field with a Tablet PC application would increase data accuracy and decrease time spent per inspection. Other employees would post comments, questions, etc. to help flesh out the idea such as: "What about a Tablet PC application would provide better accuracy and less entry time than a laptop or handheld?", "Does anyone know a formula for calculating the average cost per minute for an inspection currently and the average inspection time?"

Now the discussion is open and available to everyone instead of siloed to management. Input from any source could provide great value and address areas of the idea that may have not been covered if it had been decided by only a few select people.

Most companies want a bit more structured analysis when deciding to move forward with a project and they usually have some basic criteria and metrics they apply to a business case to judge how valuable it would be to an organization. For instance, the pencil pushers usually want to know what the Return On Investment (ROI) or Total Cost of Ownership (TCO) would be. On previous projects I have seen companies spend a good bit of time trying to calculate this up front and just like trying to capture all the requirements up front and predict strict timelines: it is rarely very accurate. But it is something to be addressed, so each Idea Backlog item can have an ROI (or TCO, etc.) metric applied to it by any employee. It could be as simple as a 1 to 5 rating: 1 being little ROI and 5 being substantial. Risks Analysis is another big thing I have seen companies dedicating effort to and this could be yet another metric to apply to an item in the Idea Backlog. There could be many more metrics, both standard ones for all ideas and then custom ones that are more specific to a particular idea.

These metrics would follow a convention of the lowest rating being the least valuable and the highest rating being the most valuable to the company. A report could easily show what the employees of the company think about the value of the items in the backlog. Items could then be sorted by the metrics and you start to get a prioritized list of ideas much like a Product Backlog. A go decision for a project is still most likely going to be up to a select few, but now the evaluation of the idea is much more open and collaborative. When the go decision is made, postings and comments to the Idea Backlog item would also most likely give birth to Product Backlog items to get the project started in its first Sprint.

I'd be interested to hear comments on this idea as I myself start to think more about it. As a big proponent of Team Foundation Server, I am going to try and implement something like what I have described above as a collection of custom work items and links. I will post more as I start to work on this.

Thanks Memphis!

Yesterday I drove the long 3+ hour drive to my old haunt Memphis, TN to give my "Implementing Scrum with Team Foundation Server" presentation to the Memphis .NET User Group. We had a decent crowd who were equally interested in both Scrum and TFS. I went long (Again!), but was able to get the bulk of the meat done and then rounded out the rest afterwards with a few of the members who stayed afterwards. Thanks to Colin and Adam for having me! The venue at the University of Memphis was great.

Thanks again guys!

Management buy in is one of the keys to adopting Scrum

All last year I worked at a shop where we struggled to adopt the Scrum process. It was haphazardly implemented and most of management never really had any training or direction and did not buy into the process. They remained very entrenched in their old ways. This resulted in some major frustration and poor results which just made matters worse since everyone thought this was due to the process being flawed.

While I am not an agile purist by any means, I do find value in Scrum in certain situations. It is hard to say if my last shop was ready for it.

This year I am on a project with a new client who has also adopted Scrum. At first I was worried because they were almost polar opposite in that they had development iterations (Sprints), but did not do much else as prescribed by the Scrum process. Since they were basically outsourcing the development to my team of all contractors, I asked to implement a bit more structure to ensure that the client's expectations were met.

We created our initial Product Backlog, started our Sprints with our Sprint Backlog and moved forward. By the second Sprint Planning Session the Product Backlog had been fairly refactored and with the current velocity it did not seem that all the backlog items they wished to have done by the 3rd Sprint were going to happen. I met with the CTO to talk about options and if capacity could be increased somehow. After all our options were discussed he was very understanding and did not press to throw bodies at the problem or modify the process to get more backlog items done.

And during a meeting where we reviewed the Sprint Backlog items, someone observed that the total of the Sprint Backlog Items for the current Sprint did not add up to our theoretical capacity based on the Scrum Team. Before I could open my mouth, the CTO was explaining how the Sprint Backlog was constantly changing during the Sprint and that we gauged ourselves by the weight (story points) of Product Backlog items. I have to say I was floored. Here was a shop where the management truly got the ideals of the Scrum process and was totally on board.

The experience has been very positive so far and I have been able to try more of the Scrum process nuances that we could never get off the ground at my previous company. It has given me some more insight into the potential qualities in a company that may (or may not) make it more conducive to adopting an Agile methodology like Scrum.

Upcoming Gigs

Here are some upcoming presenting gigs I have scheduled. This is my new "Implementing Scrum and Team Foudnation Server: A Semi-Practical Guide" presentation which has been going very well.

• February 19th at the Memphis .NET User Group
• March 27th at the Little Rock Tech Expo 2008
• April 29th at the East Tennessee .NET User Group

If you have a group in within driving distance of Nashville, I'd love the opportunity to present for you. Post back to this blog entry if you are interested.

Death by bullet points!

At a recent Microsoft get together, our local DE Josh Holmes gave us a book on creating better presentations (Beyond Bullet Points). After reading it I tried to adopt some its basic ideas around trying to tell a story and not using the standard bullet list approach to my presentations. I have to say I found it very hard to succinctly convey my ideas in a technical presentation without using bullet points at all. I found that my scripts became more essential, which was not bad necessarily, but it made the presentation as a stand along meaningless. So if I posted the presentation online without the notes, it provided little value.

I started looking at presentations from other speakers I had enjoyed in the past to get some ideas. I found this presentation by David Laribee which had no bullet points at all and was very stylized. While aesthetically pleasing, the presentation by itself held little value when you did not have David talking over it. I also found plenty of rote presentations with tons of bullet points with a few standard architecture diagrams sprinkled in for good measure. While those did have plenty of information contained in the actual presentation, I can see where sitting through them might have been pretty boring.

I came away thinking there is a good middle ground where you can effectively display your information (and yes use bullet points) while not resorting to just reading from your slides and not actually presenting the material. I am currently revamping my Scrum and TFS presentation in this manner and trying it out at several user groups in the Tennessee area over the next few months.

If you have links to good presentations done in this style, I would love for you to post them for me to take a look at.