the agile engineer

Product Qualities Approach, Agile Style

Fri, 5 Feb 2010 19:30:11 -0500

My latest article came out this week on gantthead.com. The topic is Product Qualities, a concept from Evo that can apply to any product development teams. Here’s the intro...

In many agile organizations, the product owner is responsible for setting the team’s priorities through the product backlog. Whether they want enhancements to in-house systems or shrink-wrapped products, product owners get input from customers and stakeholders to create product backlogs of prioritized features (or user stories). These backlogs contain functionality that can be estimated by developers and planned for releases.

While there’s nothing wrong with this approach of functions-first planning, I have come to believe it’s short-sighted in that it doesn’t place product qualities on equal pairing with functions. Currently in the agile community, there’s a tendency to focus too quickly on user-centric functionality instead of product qualities that can deliver real stakeholder value, often very quickly. Product owners who understand and leverage product qualities cannot only delight customers, but also help them achieve their organization’s business objectives.

This article provides a how-to for progressive change agents interested in delivering products that generate measurable business value for their customers and stakeholders. You’ll learn how product qualities differ from functions, how to identify the right ones, measure them and use improvements to drive business results. Along the way, I’ll demonstrate how to integrate an agile development processes such as Scrum.

If this sounds interesting, continue reading...

In other news, in December I received three certifications in the mail from Kai along with a listing in the Certifications section of their web site. I am now certified in Value Requirements, Value Decisions and Value Delivery. I’ll post a bit more about the certifications in the future, but in the meantime thanks Kai and Tom for the recognition!

Defining Success for Agile Transformations

Fri, 15 Jan 2010 22:58:26 -0500

Over a year ago I started having some informal conversations with a local IT leader who was interested in learning more about Lean and Agile. We met once at a neighborhood pub and another time over lunch as I learned more about his organization and some of their challenges with software delivery.

We lost touch for the past six months but then I got a call from him right before the holidays asking if I would come in and talk with he and a few agile leaders in their organization. I learned that for their latest release they had implement some agile practices within their traditional “waterfall” process and found they really helped the team deliver on time. Now there was an interest in helping the teams more formally adopt Lean and Agile principles and practices as the preferred method for delivery - not the exception to the rule.

I met today with he and his core team and for two hours and our conversations spanned a range of agile topics including how the current teams are adopting agile practices to where there is resistance to agile methods (and why). As we talked, I was reminded just how many stakeholders are involved in a typical software product company. A quick list includes:

Executive Sponsorship
Release Planning
Requirements
Design
Development
Testing
Release Management
Operations
Support
Training
Sales

At first its tempting to think adopting Lean and Agile is just changing the way your developers work. Quite the contrary, its about changing how your organization works including all the people, processes and technology it takes to create and release a product. All of these stakeholders would be impacted by a transition to Agile ways of working, not just the developers, and so we’d have to develop a plan that addressed each stakeholder in order to ensure the transformation is a success. As we could collectively see, this was going to be quite a tall order.

Towards the end of our conversation we came to their key question:

“How do we get all the stakeholders on board with adopting Lean and Agile principles and where do we start?”

I replied, “What are you really trying to do?”

The room was silent as they thought for a bit.

I continued, “Lean and Agile are a means to some ends. They don’t tell you where you need to go, they work to help you get there. It’s up to you to figure out what’s really important for you personally and your organization including what results you want to show from this initiative. From there, we can layout a plan to introduce the specific Lean and Agile principles and practices in the right order that delivers value early and shows progress on your initiative objectives. But without a clear understanding of your objectives, it’ll be impossible to ensure your plan will help deliver the results you want.”

And this is my main point of this post, a bit of advice for would-be Lean and Agile adopters: Don’t adopt Agile or Lean or ITIL or any other “methods” without first understanding your goals and what you really want to accomplish. These should be goals that directly translate to business value - not goals related to how many methods are adopted within a time period.

If you can’t figure our your top objectives, you’re about to waste time and money on an effort that may or may not deliver the results you want. You may get lucky, but why chance it? Agile and Lean are tools in your toolbox, means to some ends, not the ends themselves. They are excellent tools and I practice and recommend them, but they should be used in the context of improving specific aspects of your organization and the product you create or service you deliver to your customers.

Before you begin an Agile transformation (or any other organizational transformation) figure out what you are specifically trying to do, whether it be reducing time-to-market, improving team collaboration, reducing defects or any other improvement on some business objective. Many things matter, but not everything can be a top priority now. Define the objectives using the succinct format I describe in my articles and presentations, based on Planguage. A simple example could be:

Reduce Release Defects
Scale: Number of defects in Defined Release reported within agreed acceptance period
Method: Current Release Defect Report based on data in defect tracking system
Target [v2.0]: 46 defects <-- 20% improvement by adding unit testing and TDD
Constraint [v2.0]: 58 defects <-- no worse than last time
Benchmark [v1.0]: 58 defects (12 high / 28 medium / 18 low). Slight improvement over 64 defects in v0.9 release.

Using this format you can quantify up to 10 objectives on a single piece of paper, so there’s no excuse for not quantifying at least your top few. If you’re looking for specifics steps on how to get started with developing these, see my article here. If you want help doing this on your next project, contact me, I’m happy to support you!

Of course defining your objectives is just step one, this needs to be followed by execution and inspecting and adapting towards continuous improvement. Lean and Agile principles and practices are only as good as they are taught, rolled out and practiced - but an important first step is defining success. Spend a little time doing this before you begin your transformation and don’t chance the results - the stakes are too big.

Coming up for air

Tue, 13 Oct 2009 18:13:26 -0400

Like many consultants, with the melting of the economy last fall I spent the latter part of 2008 and the first half of 2009 underutilized. So naturally, as the the number of new engagements increases recently (yes!), so does the amount of billable work (also yes!), but unfortunately time spent reading, writing, creating and just thinking tails off (no!).

Thus explains the absence in blog posts here - I’m running three engagements now and finding the time to do the fun stuff is difficult. But in the trenches of daily project delivery, there’s a few highlights that I think are worth sharing:

Performance Testing in the Cloud
The new class of SaaS performance test tools arriving are very interesting, in terms of both capabilities and costs. I found Mike Kavitz’s blog post on this subject interesting and through a mutual friend got in touch with him. During our call he told me about the performance testing for the system he was architecting. The volume was astounding - proving out the architecture with one million concurrent transactions! With the solution under test hosted in the cloud, and the testing tool also hosted in the cloud, they could do extremely large scale testing for a fraction of what it would have costs 3 years ago. The setup he used would have cost tens of millions of dollars (or more) a few years ago, now his bill is in the thousands because of the cloud. Simply amazing.

I’m using a much more modest tool for my project, Load Impact, an affordable in-the-cloud performance testing tool. I did some analysis on test tools before I started, but wound up selecting Load Impact for their price/performance. I recently used it for load testing a client’s web site and it worked out quite well. I had my first load test up and running in literally 5 minutes. There’s definitely a ramp-up curve for recording, editing and creating test scripts - and learning what all the different parameters mean - but nothing too complex. In less than 4 days working very much part-time, I was able to do 10 runs of increasing complexity against our client’s web site and ascertain what level of load it could handle before response times started to deteriorate. This was valuable information used to set expectations for rollout.

Pivotal Tracker
I’ve become a big fan of this tool. When I teach teams agile, I always start with index cards on walls to introduce the basic agile practices. But my teams these days are virtual and I find Pivotal Tracker (PT for short) the simplest mechanism to manage stories so we all have the same view. I can give my client a CSV dump of our stories at milestones and also provide read-only access to the schedule that updates dynamically (this is handy on conference calls when we prioritize the stories). Overall a great tool that I’m enjoying and the price is right!

Unfuddle
I’ve used Unfuddle for over a year and continue to enjoy their hosting services. I can browse the source repository (Subversion or Git) and see color-coded diffs of each commit. When branching it makes it easy for me to verify exactly what will be delivered to the client through visual confirmation. I’ve found the notebooks, a collection of Wiki-pages, useful for documenting release processes and audit logs. And like PT, I can provide our client read-only access to the repository so they can fetch weekly code drops from the branches.

Although Unfuddle has a superb issue tracking system, on my current project I’m not using it because I prefer to keep bugs tracked alongside stories in PT - having everything in one place makes it easier for our entire team to review during stand-ups and me to keep track of what issues have been resolved.

OK, so I promise not to let this much time elapse again without a post. I’ve got an article coming out soon on gantthead.com and a book review of a new book on Business Value of Agile, so there should be plenty to write about in the weeks ahead.

Bolstering the Backlog

Tue, 4 Aug 2009 08:28:39 -0400

My latest article Bolstering the Backlog was published last week on gantthead.com. In this article I explore how Agile teams can measure business value using a “Results Backlog” in conjunction with the Product Backlog. While not completely spoiling this finely written piece of literary excellence :-), here’s a summary of the main ideas:

There is a distinction between Ends and Means. Ends are where you want to go. Means are actions for how you’ll get there.
Scrum’s Product Backlog is typically (in my experience) used for storing and managing the “means”, such as features, user stories, use cases, etc. There is no artifact in Scrum for storing and managing the “ends”, it is assumed this is done elsewhere, outside Scrum. Again (in my experience), I rarely see “ends” actively managed on a project, a problem I think needs addressing.
While “means” provides a good level of direction for people that have to implement the feature, they don’t provide quite as good information to people making decisions about budget and value for their investment.
I propose using a Results Backlog to manage the “ends” (measurable business objectives) in conjunction with the Product Backlog for managing the “means” (features, user stories). Each has a distinct purpose.

The concepts behind a Results Backlog aren’t new, rather they are time tested and a central part of the Evo method. I’ve been combining Evo and Scrum for a while now. What is new:

Simple Integration with Scrum - The goal was to introduce something new (measurable objectives) with something already familiar (a Backlog) and use it during an existing Scrum process (Release Planning). Minimize the change for existing Scrum teams.
New Artifact - The use of a new term Results Backlog to describe a new artifact that’s one level higher than the Product Backlog. By adding Backlog as suffix, its implied the desired business results should be prioritized. I’m hoping this new concept is easy to understand for someone already familiar with Scrum.
New Responsibility - Assigning the Product Owner as the person responsible for creating and managing the Results Backlog (and accountable for the results). They must work with the Key Stakeholders to prioritize and quantify the business objectives and ensure the team is focused on meeting these objectives during the Release.
Updated Release Planning Process - Before Release Planning, the Product Owner ensures the following activities are completed. I’ve found a combination of 1-on-1 stakeholder interviews plus a 1/2 day work session to get consensus works well to prepare in advance. One or two weeks (duration, not effort) is generally sufficient to get this done on a medium-sized project (it largely depends on stakeholder availability or interviews). For a small project, this can be done in one or two days if everyone is present and focused:
Define and Prioritize Stakeholders - Determine who you are serving and what’s most important to them. Value is not absolute, it is relative to the stakeholder, so ensure you have a clear sense of who you’re serving first.
Identify and Quantify Desired Results - While words like “improve”, “increase” and “reduce” are nice sounding, but they are vague and open to many interpretations. We should be more precise. Quantifying them with numbers allows you to set expectations around the levels of improvement desired (and what’s possible within budget). See my article for a how-to on this topic.
Prioritize Desired Results - Facilitate stakeholders in selecting the few results to focus on initially (top 3 or less). Have key implementation team members present and have them estimate whether the desired target levels are achievable within the proposed resource budget (time and money). If not, negotiate lower target levels with stakeholders, add more resources or re-prioritize objectives. Get consensus on the estimated level of improvement to be achieved in the upcoming release.
Identify Winning Strategies - Challenge the implementation team to identify strategies that deliver results quickly. These strategies could be projects, epic stories or even process improvements - something at a macro level. Use Value Decision Tables to help estimate the potential value delivered and compare alternate strategies and designs (again, using numbers). The strategies with the best performance-to-cost ratio should be pursued first.
Turn Strategies into Requirements - For the chosen strategies in an upcoming release, break down into user stories and prioritize in the Product Backlog for implementation.

From here, Scrum’s Release Planning process takes over for prioritizing stories within the release. At the end of the release, the one additional step is to measure the ‘progress towards the desired results’ - this represents the ‘business value’ of the release as measured in terms the stakeholders have defined. While the number of features delivered can be calculated easily with the Product Backlog, the Results Backlog will maintain the overall progress towards goals.

Since the article was written, I’m starting to use the Results Backlog on projects and will report back on how it goes. If you’d like to try it out, please contact me with your feedback and any issues uncovered putting it into practice. I’m genuinely interested if you find the concept useful enough to put into practice.

The Bunny Chronicles: Part 1 - Is This Thing On?

Sat, 18 Jul 2009 22:12:44 -0400

This summer my company is participating in a local internship program whereby we get a high school student to come work for us two days a week for 10 weeks. I’m the person responsible for this year’s intern, Steven, and what he’s working on this summer. Its a bunny.

This post is the first in a series of my adventures with Babic, our Nabaztag rabbit bunny and the resulting summer internship. For some reason The Promise Ring song “Is This Thing On” felt like an appropriate title for the first post.

Is This Thing On?

We decided that for Steven’s internship there were two projects both interesting and with direct connections to improving our development teams’ performance. First, get Babic hooked up to our build process (currently in Hudson). Second, explore frameworks like Hackystat or Sonr and see how they can help teams deliver higher quality software.

And plug them up to Babic.

Because, naturally, when you have an electronic bunny in the office, why not hook everything up to it?

If you are wondering, “What are you doing with this bunny?”, you are not alone. Many of my work colleagues have been asking the same question. The office joke is “it must be nice to play with bunnies!”. And I have to admit, it is a bit odd, but really fun. This lump of plastic with ears makes for an interesting project.

Believe it or not, there is a valid ‘work purpose’ for the bunny (or so I try to explain to others). Babic is a Nabaztag rabbit, a wifi-connected device that does interesting things (like move his ears, light up and speak). He’s designed to tell everyone, in fun and interesting ways, the status of most anything. He can report the weather, read news announce new emails or blog posts. He can even read children’s stories. In up to 6 languages!

In our case, I’m interested in having Babic tell the team in real-time the quality of the software their developing with motion, lights and sounds. Convey important information in fun and interesting ways.

Old School

Babic is an evolution of the build lamp concept that was made famous in Mike Clark’s book. Back in 2005 on an XP project I was leading, we were having a conversation one day about how cool it would be to not just hook up the lava lamp. I had read about this in Mike’s book and was anxious to try it out. The only issue I had with the lava lamp was that it was slow to show results and not in-your-face enough for me. But better than nothing.

So we’re talking about how to do this one afternoon and Guy, the project manager, overhears our conversation. He asked a few questions about what we were doing. The next Monday comes and Guy walks in with a custom-built build lamp! (we later found out Guy, in addition to being great at Resource Plans and Gantt Charts, majored in Electrical Engineering and could build anything with a circuit).

Guy’s new version was a big improvement over the lava lamp. It was and outdoor floodlight mounted on a wooden box with the two spotlights pointed upward. The wooden box was about 8” x 8”, sat on a desk, and had two huge spotlights: one green, one red. It was hooked up to our CruiseControl instance using X11 and we configured CruiseControl to tell the lava lamp the status of the build (If you’re interested, here’s the instructions setting this up).

When things were well, the green spotlight was on. It was pretty mellow. Things are OK. But that wasn’t the case when the build broke. The entire room lit up in red floodlight. It was Bright. Blinding. Annoying.

It worked perfectly.

But our floodlight had some issues too. For one, it was on all day and night (unless we remembered to unplug it daily) and it got hot to the touch. Leaning up against the build lamp might send you to the hospital. Plus, our lamp only show one of two states: green and red. We wanted more!

Guy took this as a challenge and created the next version: an integrated LED light into a small wall lamp that he found in the clearance bin at Lowes. He mounted it on a wooden base and next thing you know we have 256 colors available and the light could move between colors easily. Sweet. We could also show a build in progress in addition to pass / fail, so blue was chosen as the color for a build-in-progress. We even managed to save electricity with the LED light and it wasn’t going to burn anyone. We loss the big bright light, but overall it addressed many of the issues for the floodlight.

Adopting Babic

Fast forward to this Spring. I was working on setting up a build lamp for one of the teams I’m leading. I recall Guy’s work, but also start poking around online a bit for what’s been developed in the last few years. Right around this time I see Eric Pugh at beCamp and mentions the HackyStat project. I check it out and stumble upon the integration with build lamps and someone had integrated HackyStat with this bunny...a Nabaztag rabbit.

“Wow, cool” I thought. This was just like Guy’s build lamp but better (no offense Guy!). I clicked on the hyperlink to explore further this bunny with the funny name I couldn’t remember or spell.  
N-A-B-A-Z-T-A-G

.com. Twenty minutes later I had purchased adopted a new Nabaztag bunny. For $108.95 including shipping. My new adopted bunny arrived a week later in the mail. I opened the package and started getting it connected to the Internet. It was like Christmas morning.

My wife thought I had lost my marbles.

After some configuring, Babic was connected to the internet. I created a new Violet.net account so I could configure him and shortly thereafter Babic was doing Tai-Chi and reciting the weather in French every morning at 8am. The air quality report came at 8:02 from an English guy. My wife speaks a little French but suffice to say, I didn’t understand the weather. But I didn’t care. It was weird and quircky yet someone my wife and I really liked having Babic around.

He quickly became a member of our family.

Putting Babic to Work

But I didn’t buy Babic for sitting around at home all day. There was work to do. It started last week when Steven started his internship. On day 1 he was already starting to setup Babic based on the configuration instructions. But he hit a snag pretty quickly - what had worked OK for me at home on my secure WEP wireless network, didn’t work on the WPA network at work. Babic would light up telling us he’s connected to the network OK, but he couldn’t resolve the violet.net servers. When I arrived, we double and triple-checked our settings to no avail. We could ping the servers violet.net servers OK, so they were alive, but Babic wasn’t resolving the name correctly.

I Googled for about 20 minutes and stumbled upon a forum post for this issue. Their solution was to put the IP address in the p server configuration (instead of DNS name). We tried this and it worked, so after a side-track Babic was connected to the Internet.

Once online, we tried to get it connected to a Hudson instance. It turns out the recent version of Hudson ships with a Nabaztag plugin, so it was just a matter of enabling it in Hudson’s configuration and telling the build job to invoke the Nabaztag plugin with the results of the build (SUCCESS or FAIL). It only takes two pieces of information to get connected: Serial number and Token number (both available from the Settings page in your violet.net account).

Once supplied, we forced a build and Eureka! It worked! Now every time a build was done, Babic’s ears spun around and he displayed green or red blinking lights, depending on whether the build succeeded or failed. Babic also said, “The build for project Test has Passed”, in one of his configurable voices.

By shortly after lunch on Day 1, Steven, with a little help from Chris and myself, got Babic and Hudson working together. But there were two things that I thought would be nice that the plugin doesn’t support (that I can tell):

The ability for green and red lights to stay lit for longer than a few seconds after the build is complete. I’d like for Babic to be lit up in green all the time when things are ok, and flashing red when not. Similar to how the weather is broadcast now using the Light Language.
The ability for Babic to signal when a build is ‘in progress”. Right now only after the build is complete are messages sent to the bunny.

Chris and I conferred and we decided that learning how to write a Hudson plugin would be a good programming project for Steven. So that’s what he’s going to start, a plugin to implement these features.

So far so good on the summer internship. In Part 2 we’ll see how things progress with our plugin.

Tom Gilb's Conference on Culture Change

Fri, 26 Jun 2009 07:40:20 -0400

I’m on the way home from London - flying high over the Atlantic in the relaxing confines of BA’s Club World section. I’m not sure how I got upgraded to business class, but after a long week I certainly can’t complain about a seat that lays down, red wine, some classic live Dead on iTunes and a gourmet meal on the way.

This year’s conference was on “Culture Change”. It was my third trip to London to visit Tom and the merry cast of thinkers who have somehow crossed paths with him along the way. I’m always amazed and impressed by the caliber of folks who attend Tom’s conference - an intersection of technologists from around the world who have some connection with the principles and practices of Evo and measurable value.

My talk was on Changing Organizational Culture in software development teams and included a mix of proven techniques (those I’ve used effectively) and emerging techniques (those I’m exploring now). The reception was good but I worked and refined it up until the last moment - something I’d like not to repeat next year. I received a good response - from a crowd that can be testy at times - but I wasn’t completely happy with the way I delivered the information. Definitely need to finish earlier and have more prep time next year.

In addition to getting to spend time with Tom and Kai Gilb, I also got to have some in-depth conversations with Rolf Goetz, Allan Kelly, Giovanni Asproni, Niels Malotaux, Clifford Shelley, Lorne Mitchell, Gio Wiederold, Marilyn Bush, David Stoughton and Yazdi Bankwala amongst others.

It was a special treat to meet Jeff Sutherland, who was in town teaching a Scrum class. I was able to join him, Tom and Solveig (Tom’s wife) for dinner on Sunday evening at a Thai restaurant in Tom’s neighborhood.

I think next year’s talk is on Value Delivery, this time I’ll try and prepare earlier!

Reflections on being World Class

Thu, 28 May 2009 21:55:16 -0400

For the last few months I haven’t been working hands-on on software development projects. Its been a nice break that has forced me to get outside my comfort zone in some respects, but at the same time I do miss working with software teams. Everything changed three weeks ago when I started two new projects in the same week. This is why my blog posts have fallen off as well as my reading!

In the first project I’m an engagement manager for a .NET development of a SaaS for a non-profit client. I’m taking over for someone who recently left our company and in doing so have inherited a system and development team. I’m coming up to speed on the application and working to secure some work building new features the client has requested. This project is a bit of a departure for me in that I’m purposely not hands-on with the code.

[Aside: After eight years of Java and the last few dabbling with Ruby, I made a personal decision two years ago to not learn .NET. Although much of the software my company develops for clients is .NET, and I think that .NET is a decent-enough technology, for me I saw little value in ramping up in a new language and platform that was, IMO, nothing really new or interesting. I know plenty of smart people inside and outside my company who are passionate about .NET, but it’s just not for me. I think this stems in part from the early years of the Internet when I saw Microsoft eschew standards, open-source and take an our-way-or-the-highway approach to working with others.]

The second project is far different - I’m leading a small team developing a high-level plan and business case for a client who wants to make enhancements to their real-time marketing platform (ironically, also developed with .NET). I’ve been involved with this company for over two years, on and off, and they’ve been extremely successful. I think I’m most proud of the fact that we introduced Scrum to them when they were a small start-up and now after two years of growth they’re still succeeding with Scrum. They still use cards on the wall, daily stand-ups, burndown charts and the works. Even their marketing and analytics teams use Scrum.

After initial success with their platform they want to grow revenues by $150M by 2015 and are looking for new capabilities that will enable them to do this (along with go-to-market costs). Our charter, from the CEO, is to “get from 30,000 feet down to 10,000 feet” in 4 weeks. Our team consists of myself, who knows the domain and can assess the technical impacts, and two colleagues who have expertise in finance and operational processes.

After our last interview today we headed out to grab a few beers and my friend Jimmy asked Ryan and myself, “What do you think you could be world class at?” It’s an interesting question that I must admit I’ve thought about before, but never discussed with others. My answer was that I thought I could be world class with solving complex problems, especially those involving teams designing and building software systems. Jimmy followed up and said, “So what are you doing now to be world class with this?” I didn’t have a good answer.

On the drive home and later this evening I find myself coming back to this question again and again. I’m not sure if my answer is right, but I am sure that I don’t ask myself this question enough nor do I share my thoughts with others about it.

While most of my blog posts are informative on some topic, this one is more of a reminder for you to spend some time reflecting on what could you be world class at and what are you doing now to make this happen? Give it some thought and if you’re not on the right path, figure out what it’ll take to get there.

The Agile PMO: Prioritizing by Business Value

Wed, 13 May 2009 06:21:19 -0400

One of the consistent themes in my work is this notion of making sure you’re doing the right thing before doing the thing right. While the word juxtaposition is slight, their implications are anything but.

Last week Sanjiv Augustine came to town to give a talk at Agile Richmond (photo above). In addition to being an author, entrepreneur and agile practitioner, he’s also a heck of a nice guy. We enjoyed chatting over dinner on a variety of topics and I came away thinking it was nice to connect with an agile thought leader who lives in the area. Sanjiv’s talk was on the The Agile PMO - From Process Police to Adaptive Governance.

The main takeaways for me were the concepts of optimizing your project portfolio for throughput not utilization and the governance models for supporting an Agile PMO. Sanjiv presented a very tangible way to make this happen, including ideas for how to prioritize all projects by business value and then to limit the number of active projects to the capacity of the delivery team. This typically means canceling lower-value projects and re-distributing those resources to higher-value projects so they can be completed quicker. The end goal is faster time to market for high-value projects - not optimization of resources across all projects.

One surprising point I learned was that, according to one study, 53% of project prioritization is driven by politics. In this climate, adapting more open and transparent project prioritization activities can be extremely difficult. There are powerful people who like the way things are and may have “pet projects” that are near and dear. But that doesn’t mean we shouldn’t try and prioritize by value - it just means bringing change may be harder than we think.

While Sanjiv’s points were all familiar to me, the way he presented the information was new. He helped me understand the concepts and how I can do them in practice. During his talk, I couldn’t help but think of a few Evo concepts that could be included in the adaption of his Lean-Agile PMO framework.

The next day over lunch my colleague Jimmy and I kicked these ideas around and agreed to try and put them into practice at our next opportunity. Since Jimmy leads up our Operations and Technology Strategy solution that helps clients manage their project portfolios, he’s in a good position to try them.

Specifically, we discussed two “plugins” that could be used with the Lean-Agile PMO based on Evo:

Quantify Business Objectives
Project Prioritization using Impact Estimation

Quantify Business Objectives
Sanjiv presented a simple framework for prioritizing projects based on weighted values for certain criteria. Projects get weighted scores of 10, 20, 30, etc. based on criteria and when added up, the project with the highest score is the most important - resources should be focused here. He said this is one example, and there are others, for how to prioritize projects in the Lean-Agile PMO. His explanation reminded me of the plugin architecture I’m familiar with in software - how different prioritization methods could be used to extend the Lean-Agile PMO approach.

With my Evo background I recognized there was, I’d argue, a more robust way to define business value that would allow a Lean-Agile PMO to prioritized by business value. This plugin would use Planguage to quantify the business objectives first and then prioritize the projects through the use of Impact Estimation. Doing so will show us how well we think the project will meet our business objectives, and at what cost.

I can use examples from my Value Delivery article to illustrate the concept. Let’s pretend we want to prioritize our portfolio of projects based on business value so that we can ensure our resources are focused on the highest priority initiatives.

Step 1 is defining business value - which means defining the business objectives (aka results) of the business unit our PMO is working with. Instead of putting weighted scores next to a business unit objectives such as Increase Market Share or Increase Monetary Donations, we’ll go a step further and define them using a scale (what to measure) and meter (method to measure):

Step 2, is to understand where we’re starting from (benchmark), what’s success (target) and what’s failure (constraint):

Charting the results helps us quickly grasp which objectives we are doing ok with and which ones need our attention now.

So why this approach over a weighted scoring system? Yes, it is more work, but I’d argue not that much more once you understand the concepts. So is it worth it? I’d argue that with project portfolios in excess of millions of dollars, the decisions around which projects to fund is a critically important one that has an enormous impacts. So in this case, a little more effort can be justified.

If you want some additional arguments, see “What is Wrong with the Weighting Process for Determining Priority” in this paper.

Project Prioritization using Impact Estimation
With our objectives defined, we can use Impact Estimation for evaluating how well our proposed projects will help us meet our objectives, and what resources are required to make this happen. Here’s an example that illustrates which of the three proposed projects (Recurring Payments, Facebook Integration, Image & Video Uploads) will deliver the greatest business value:

The important point is that projects aren’t evaluated on just the expected value (Total Objective Impact), but the ratio of value to resources (Benefit to Cost Ratio).

For example, in Figure 5, the Facebook Integration project isn’t selected because it has the highest expected value. At 110%, it’s actually 3rd with respect to value delivered. But, it does this with 40% of the resources - compared with the other projects that use 70% and 100% of the resources to deliver value. Thus it represents the best “bang for the buck” and should be prioritized high in our portfolio.

Summary
For those in charge with prioritizing the projects in your portfolio, next time consider using a more robust method than simple weighting based upon arbitrary values. If you need help, email me and I’ll provide you guidance.

Remember: Don’t just sort your portfolio, engineer it to delivery business results!

Agile Engineering @ RJUG April meeting

Fri, 24 Apr 2009 20:24:32 -0400

Thanks to everyone who came out to the Richmond Java User Group meeting last night. I saw mostly new faces in the crowd but as always it was good to re-connect with old friends and colleagues.

I felt the dynamics were good and everyone was getting the main concepts. People seemed to enjoy the group exercises and I enjoyed walking around and talking with people (and snapping photos on my iPhone). I overheard lots of interesting discussions about different was to define response time, availability and throughput qualities.

I wish one of my points about Impact Estimation had worked out better with the examples. It’s the point that the design idea with the most performance isn’t necessarily the best one - it’s the ratio of performance-to-cost that matters most. Well, I picked 3 design ideas at random from what the group’s identified, but it turned out the design idea with the most performance was also the one with the best performance-to-cost ratio! Doh! Oh well, it just worked out this way.

I’ve uploaded the slides and Impact Estimation spreadsheet in case you want to download. As I mentioned in the meeting, contact me if you’d like support implementing these ideas on your project. I’m happy to help anyone trying them in practice and would enjoy the feedback based on your experience.

After the success of the talk last night I was thinking how bummed I was this talk got turned down for the Agile 2009 conference. I think the agile community could benefit from new approaches to defining and measuring system qualities, especially approaches that integrate with Scrum. But I guess not. I submitted it for the Developer Jam stage and the rejection email said they had 100 submissions for 26 spots. Tough odds I know, but still never good news to hear.

The Fed: Going Agile out of Necessity?

Wed, 15 Apr 2009 08:39:21 -0400

During some recent time off I was reading an interesting article in the Washington Post about “How Bernanke Staged a Revolution” at the Federal Reserve with his guidance during our shaky economic times. It turns out Ben Bernanke, the Federal Reserve Chairman, is a scholarly expert on the Great Depression. He contends the major lesson learned from the Great Depression was that during a financial crisis like the one we are facing now, the government has no choice but to act quickly. After all, it was only World War II that brought the US out of the Great Depression, 12 years after the stock market crash of 1929.

This time around, Ben’s not about to let that happen on his watch, thus the government intervention into AIG, FreddieMac, FannieMae, CitiGroup, General Motors and a list of others. The argument goes the price of action is expensive, but history tells us the price of inaction could be much, much more expensive.

So what does this have to do with agile? Here’s the quote from the article that caught my attention: 
“A decade ago, when the Fed wanted to know how it might deal with technical issues created by the government's need for fewer Treasury bonds, a study of the issue took 18 months and involved 73 economists across the Fed system. The result was a 165-page report.

This year, the Fed has made decisions of similar complexity and importance over a single weekend.

The pressure to act fast has, by all accounts, come from Bernanke himself. His relationships with staff members are warm, dating to his days as a Fed governor when he ran the equivalent of faculty seminars to help young economists develop their research. But sources who have been in contact with Fed staffers also say that he has prodded economists and lawyers to move faster and think more creatively to execute new programs being enacted.”

In reading this, I can’t help but think, “A decade ago, the Fed was waterfall. Now they’re Agile. Out of necessity.”

The article goes on to describe Bernanke’s leadership style and his emphasis on setting goals and challenging his teams to “Find a way to do this.” He breaks down hierarchical barriers and fosters open and honest debate from a diverse set of team members. He challenges his team to find creative solutions to problems quickly.

Reminds me of a well-run Agile project!

With the Fed making swift decisions in days and weeks, not months and years, I’m curious if their IT organization as adapting as well? If Federal Reserve IT projects are traditionally waterfall, perhaps the new economic realities are just the impetus for going Agile?