Project Manager, Iteration Manager: Who's who?

Does your team have a project manager? Probably. An iteration manager? Maybe. More likely not. Do you need one? What's the difference?

Google for "project manager vs. iteration manager" or similar phrases and you will get lots of job search links and about half a dozen fairly good articles and posts that attempt to answer these questions. (A selected few are at the end of this post.)

Probably the one that does it best is the original description from 2000 by Cara Taber and Martin Fowler: Planning and Running an XP Iteration ( http://bit.ly/YnnASZ )

In the section on team structure, they give a real-world example that makes the inward-facing, outward-facing nature of the two roles pretty clear. Their description shows that making these roles effective for the team is not so much about how you characterize tasks but how you enagage personalities for situations. That has certainly been my experience. Across all my projects, going back to the 1990s, projects with teams larger than five ran best when two or more people split up the PM and IM roles.

The PM role primarily looks outward and deals with leadership from participating teams and the overall parent company organization. The IM role looks inward and tracks the pulse of the team, resolving small issues and escalating big ones, and keeping the metrics clean.

You can compare it to film-making. The PM is the Producer and the IM is the Director. Sometimes a Producer can direct their own film or a director will self-produce their work but the results are generally better with a team.

The Producer is responsible for backing and selling the project vision, plus all of the arranging of people, places, supplies, contracts, etc. necessary to bring cast, crew, and location(s) together. The Director is responsible for conveying the creative vision to the cast and crew and enabling them to perform the actions that become the film. (You can make the same type of analogy with sport team owners and coaches, or the difference between conducting an orchestra vs. the executive duties of a music director.)

The Software Project Manager, like the Producer, is the big-picture, big-structure, studio-boss facing, investor-facing money person.

The Iteration Manager, like the Director, is the on-scene, every day, fine-tuning, people-relating, situation-improvising person.

If the software project is large or complex enough, the IM role can be full-time. More likely it is not. Sometimes the PM and IM role is combined in one person but more often the IM role is played by a BA, QA or Dev Lead, or a combination of people in those roles.

The reason why that happens, it seems to me, comes down to personality type – there are Manager types and Maker types ( http://bit.ly/WZOYHc ). Project Managers obviously tend toward the Manager type. BAs, QAs and Dev Leads tend toward the Maker type. For whatever reason, IMs (at least all the ones I’ve met) also tend toward the Maker type.

Perhaps there is a flow-state awareness that happens to Maker-types that makes them better attuned to the day-to-day rhythm of the team. Whatever it is, it seems different from what drives Manager types and all teams need some of each.

A few more links

Venkatesh Krishnamurthy, The Differences between a Project Manager and a ScrumMaster. http://bit.ly/14NuFAe

Darian Rashid, Transforming a Traditional Manager into an Agile Manager. http://bit.ly/Y5H7Z7

Rene Maslen, What is an Iteration Manager and why do we need one? http://bit.ly/WZu634

Petra Skapa, Iteration Management: Unclogging your development process. http://bit.ly/YdmWe1

A Checklist for Effective User Stories

Even though the classic Agile position is that a story is just an starting point for a conversation and thus should only be a sentence or sketch, this only works well for certain kinds of teams and projects - within big corporations, you usually need to do more to document the story for stakeholder review and to retain knowledge within the team. But you don't need to do too much more.

Having a good story pattern or checklist makes it much easier to get the essentials captured without going overboard on documentation. Here are the eight checkpoints I run through when I prepare a story:

1.	The story.	As a (role), I want (to do or have something ) so that (I get this benefit). In addition to this statement, you can add one or two short paragraphs giving any necessary background explanation of the problem and goal.
2.	What is in scope.	A list or statement of what everyone agrees will exist when this one story is done. Note, this is a list of what to do, not how to do it.
3.	What is out-of-scope.	Give a general statement or list of specific of exclusions. These are the things everyone agrees go beyond the current goal.  E.g., this story will not calculate depreciation using LIFO method; ability to add comments will be handled in a separate story, etc.
4.	Assumptions.	List any assumptions made about existing functionality or data access.
5.	Open questions and issues.	List any questions still to be resolved and update them as the answers become available.
6.	Design artifacts.	Don't go overboard but do include at least one relevant sketch, screenshot, flowchart, design diagram, mapping table, etc.
7.	Dependencies and related stories.	What else should developers, testers and reviewers know to put this new story in context? What others stories must be complete before this one can go forward?
8.	Acceptance tests.	Given (the system's starting state), When (this action occurs), Then (the system delivers this result). Acceptance tests are the BA/product owner's contract with the developer how they the product owner/BA will test the story. A BA/product owner cannot fairly reject a story if their test was not included in the acceptance criteria.

1, 2, and 8 are necessary. You can't have a story without them. 7 is also almost always necessary if you're doing anything that has a strong UI component, but sometimes it's OK to add or update this after development starts or after the story is completed. In this way the illustration acts as a guide for tech writers and the support team.

The other checklist items are optional but it's a good idea that any record of the story indicate when an item is not applicable, e.g., No open questions, no dependencies.

Remember to keep it short. If you are telling the background story, that can be one or two short paragraphs but no more than three or four sentences each. If you are listing out points, (e.g., a list of assumptions) no item in the list should run more than one or two sentences (think one-liners).

If you are writing more than that, you may have bitten off a story that is too big or you don’t know enough about the situation to isolate the central objectives. Stop what you are doing, check in with your teammates and SMEs and try again when you have a better handle on the situation.

PS: Later Developments - This is a discussion on LinkedIn about how to write user stories in which I take a troublemaker role: How to Write Good Stories.

Thoughts on Moving Beyond Scrum

Moving Beyond Scrum, a posting by Todd Charron on Infoq.com has been making the rounds of our team lead discussion groups. Here's my take on what the writer says and the comments he received:

I’m with the voices that say that Agile is a philosophy and set of principals; not a practice. When we live those principals, we choose and adapt practices to best fit the current situation. Thus, each project team may do things a little differently from the others and one project team may change what it does over the life of its project.

The key drivers of being Agile are focus on business value, delivering working code as frequently as possible while maintaining a sustainable pace, and constant improvement in process and outputs by regularly iterating (review/change) over the results.

Practices that facilitate being Agile are close communication among business representatives and the development team (where UX is part of the development team and not handled as an over-the-wall service); pairing – programming, designing, user researching, testing; test driven development and continuous integration; user research; rigorous ETA projecting and prioritizing based on business value and team velocity.

Attitudes that facilitate being Agile are tolerance for ambiguity and unknowns; flexibility to compromise; interest in hearing and trying new ideas; satisfaction in teamwork (getting things done) over heroics (getting credit for being right).

Shu – Ha – Ri describes three stages of learning -- beginning to learn fixed patterns, experimenting with changes to the patterns, intuitive actions transcending patterns.  This is what much of the article’s discussion was about and describes why the article and its commenters feel there is a problem. There are too many people and organizations who are only in the Shu phase (I read about Agile, I got a Scrum certificate, we always do it like this) and not so many people and organizations at the Ri stage.

SCRUM, whatever its original intention, has become a defined set of practices. Ri people that I know have always referred to Scrum as a project management method and not about how software development happens. Scrum in itself is not magically agile.  Ditto Lean and Kanban.

Entropy, gravity, and human nature combine to emphasize or depend on predictable patterns and relationships. Difficult things fall apart faster, bodies at rest tend to stay at rest, following directions is easier than making a trail or reading a map. Agile works when you bring together a collection of people who prefer to go against these patterns. Therefore, the first challenge is to collect the right people.

Collecting the right people becomes difficult in large, established organizations unless the organization’s culture already rewards innovators and explorers.

Starting small with selective teams and projects is generally the best way to introduce change but such change is never sustained if it depends on outside coaches and consultants or if the higher leadership in the organization does not support and exemplify the change through its own behavior. In other words, long-lasting change needs to start simultaneously at both ends and work its way into the middle.

Things that can be done to foster a JIT delivery culture:

·         Evangelizing – reading & discussion group(s); brown bag sessions (internal & external presenters); publicizing internal examples; agile game sessions.

·         Hiring

·         Project staffing – all intentionally “agile” projects should have sufficient staffing at the Ha level and a Ri member or coach.

·         Co-location – UX, QA, Dev, Business sit together and have mixed meetings beyond IPMs  to discover and negotiate project requirements and design (google "Divergent and Convergent thinking" to learn more).

·         Shadowing

·         Regular process and structure to identify negative patterns, think of solutions, and conduct real-world tests (retrospectives make this happen at the project team level, what’s the equivalent at levels above that? Are the right people participating? Is the right information surfacing? )

·         Demonstrative leadership – actions and words are aligned.

How big is a 1?

Nothing sinks a project faster than a poor estimate, or rather, an estimate that sets the wrong expectation. Part of the problem with setting expectations is finding the right words to paint an idea of the development  effort.

It usually starts to go wrong when somebody tells a prospective client that the team estimates work in story points and 1 point “is about a day”. Wrong!  And too late.

 

The client will never lose the impression that a point is really just another word for “a developer day” and they will always be suspicious why it’s taking weeks to do what apparently was rated as a few days work.

A point is not always a day. I’m on teams right now that are only getting 1 or 2 points done per week. I was on a project where it took 3 weeks to complete a one point story.  I’ve also been on a project where the stories were so small, we stopped using points completely and did 3 – 5 stories a day.

So how big is a 1 or rather, what should a 1 represent?

All we want is some way to express time and effort relative to everything else that’s on the table.  

A 1 seems like an easy way to say that of all the things there are to do, each story in this pile will likely take about the same effort and time to do and they are all smaller than any other story on the table (or in the list).  From there, 2, 3, and 5 are useful to express increasingly larger scales of work, with anything above 5 or 8 signaling something big enough to require decomposition. 

But although it is convenient to use numbers to express relative positions on a sizing scale; using numbers tempts people to apply the same numbers without adjustment to generally quite unrelated timing scales.

Eliminating the numbers and using other mental images may be better for illuminating story sizing and starting a discussion around the development effort that might be involved. Let’s try some different scales:

     Cherry, apple, cantaloupe, watermelon, holiday fruit basket.

     Skateboard, bicycle, Vespa scooter, Ford Escort, 18-wheeler moving van.

     Pebble, rock, boulder, Corinthian column, Stonehenge.

     Stick horse, pony, racehorse, the Budweiser wagon, a circus carousel.

The next time you are sizing stories (and yes, call it sizing not estimating), it could be interesting to forget about numbers and try using some flashcards with pictures of objects instead. Your team might end up saying, “This week we finished three little ponies." Or, "The last time we did a beer wagon, it took a week and a half."  

Lifecycle of a project: What's wrong with this picture?

This weekend, I attended a Design Hack session for CivicLab, a new effort in Chicago inspired by Milwaukee's Bucketworks.org; an institution that fosters member-driven civic and creative projects and activities.

There were several discussion groups taking up various themes. Since it seemed well correlated to what I do at work, I joined one about the lifecycle of activist projects and campaigns. Quite a few other software geeks took part, too.

The facilitator kicked things off by putting the following illustration on the board. Take a look, do you see anything wrong with this picture?

I quickly killed my good will with the facilitator by pointing out that Inception was a noun and Execute a verb. You don't execute at the end of a process, you execute all the way through a process. Someone else jumped in and observed that a lot of preparation has to happen before you can do an Inception. Another person wondered where Feasibility studies fit. And so on.

In the end it was a good discussion, enough for two or more blog posts but what I've been pondering all day is what kind of diagram would have said it better?  This is what I came up with:

Execution happens throughout a process. Throughout a process, research and investigation are happening to detect problems and opportunities. At any time, ideas may pop up, or you may set aside specific brainstorming sessions. Ideas, and problems and opportunities have to be prioritized. Problems and solutions have to be validated and evaluated - are they real problems? Will the solutions work? Will people adopt the solution as designed? Is it cost effective? Prototypes at varying levels of fidelity are in order throughout the process.

Feeding into all of this is an understanding of the context; the bigger environment of the problem and the people you want to assist: politics, money, geography, values, culture, etc.  Understanding the context and where you are in the process determines what tools will be useful in the execution of any phase.  

We Don't Estimate Hours!

Now that I'm at Pathfinder, many new clients are coming in through the UX door and they are not familiar with Agile. I often have to explain how estimating and story points work.

If you search the Internet, there are tons of links about Agile estimating and story points so it seems redundant to add another but I really wanted to blog about this, if only to organize my favorite references.

So here are four links that cover just about everything on the subject (plus they'll send you to other places anyway). And if you don't have the patience to comb through these references, I've added my basic explanation to customers at the end.

1.I know Anand Vishwanath from a long time ago.  I value his overview for the thorough job it does of covering all the angles: http://bit.ly/MdH1tS

2. I love Dan North's post because it correctly, and effectively, shoots down that compulsive estimation marathon most companies want to indulge in: http://bit.ly/J9DvxF

3. Jay Fields is another former Thoughtworker who sums up the how-tos concisely: http://bit.ly/LbKy9Q

4. Mike Cohn is the ultimate writer in this area and this link leads to a chapter from his book on Agile estimation and planning, "Chapter 6: Techniques for Estimating": http://bit.ly/K6pvqQ

What I tell customers: We estimate expected effort, not hours. My teams count effort in points -- one is small, two is something more than small, three is something more than a one and a two, five is a large effort and going above five indicates the story is stated too broadly or contains enough unknowns to be manageable within an iteration.

Effort is either a measure of complexity (figuring out the unknown) or time spent on something that is naturally slow and tedious or a combination. Effort doesn't translate directly into hours but a team can use effort to figure out approximately how much can get done per iteration. It takes a team several iterations (2-5) to get a handle on their velocity (stories points completed per iteration) but you can use yesterday's weather to get a starting range for estimating a project.

Yesterday's weather comes from looking at what a similar team (size, experience) accomplished in a similar situation (familiarity with technology and domain). You only need one previous project to get this information. Use the averages - mean, mode, median - to figure out a likely range of outcomes and prioritize stories accordingly. Add 1-4 iterations for ramp-up (because both sides have to get up to speed) and 2-4 weeks for wrap-up (bugs, testing, and the unforeseen). Review and adjust the plan as you complete each iteration.

Tips for improving Your Iteration Planning Meeting

Our iteration planning meeting (IPM), like many, is not really a planning session but a status report and demo for managers and SMEs who are generally mostly disconnected from day-to-day development and support. Team leads provide information and our PM assembles the slide deck and gives the presentation.

In a recent retrospective we talked about how for two weeks in a row, the only questions attending stakeholders had were about about release dates and release contents. We agreed to add a slide to highlight this information. I think that will help but it's not enough. Following are some observations I shared with our PM and GM.

As I see it, our biggest problem, and it may be true for you too, is confusing the recitation of lists of things with telling a story that the stakeholders can connect to.

1) Our deck includes one slide that shows how the business handled by our application is growing (or not). It is the most interesting thing in the presentation but the rest of the material doesn't connect to it. When I see this slide I have two questions, "Are these numbers in line with our expectations?" "And what are we doing to keep things moving along as-is or fix what is deficient?" In short, I am looking for the slide to be followed by a statement of strategy.

2) Assuming that the deck gave a clear picture of strategy, then, as a stakeholder, I'd like to see how the stories just worked and being planned match up to that strategy; and I'd like to know how the current priorities fit the strategy too.

3) Listing issues that came up in the past iteration is not useful if we don't also show how these issues affect the strategy and talk about their solutions and status.

4) A long list of priorities is not effective without relating them to the business strategy and giving projected timelines and dependencies.

Obviously, no one ever works a dozen priorities at once. There is usually some short list of 1 - 5 things that are getting immediate attention. That makes one slide. Then there is an equally short list of things expected to come to into play within the next 1-2 months and some work (research, design) may be starting or going on already.

Finally, there is a third short list of things brewing on the horizon that have the potential to become very important any time between now and the next 4 or 6 months. These are under watch but no one is acting on them yet. Three slides, three short lists with discussion about how each one fits into the business plan.

5) Just giving a count of open and fixed bugs is not informative either. People want to know what the trendline looks like. Are things getting worse, better or holding steady?

Put the numbers in the deck but focus the talk on the trend -- the direction and its implications. Also take time to touch on the top issues that were faced in the past week(s) -- usually just two or three, never more than five.

6) Give a summary. And be sure it packages the message you want everyone to hear.

It's a cliche but every journalist knows you have to tell your audience what you're going to tell them (agenda, introductions), then tell them the story (the deck), then tell them what you've told them (the summary). Here's an example of a summary that takes care of the message:

"So in conclusion, many new accounts have come online but they are not necessarily using the application regularly. We are targeting improvements in reporting, and implementing analytics to better monitor usage and identify pain points. We are making enhancements to the admin functionality to make it easier to support accounts and fine-tune pricing.

"We are getting ready to add new business lines. The team velocity continues to trend up and we are getting three time as much work completed now per iteration than at the start of the quarter. Our next release will deploy on Thursday and it will contain the things listed on the next slide. (show next slide and tell people they will get a copy of it, but don't read it aloud. Ask for questions or comments instead.)"

Is there room for UCD in Agile? part 3

So now we are at Question 3:

Do the UI stories count as "done", even when no software has been written?


"Count" is the operative word here. Do we mean "count" as in "keep track" or "tick off on a list" or do we mean "count" as in adding up some numbers and coming to a conclusion about actuals vs. estimates?

The purpose of saying a story is Done, is to have a means of measuring the team's velocity -- how much working software gets built on average per iteration/ sprint. Thus, in theory, you only really care about Done if the story is a coding story.

But you still need some way of determining if the flow of stories out of the backlog will impede the team's velocity. Now we're talking lean. Are stories getting delivered into the "ready-to-build" backlog fast enough so that the development team can always pull something off the backlog given their average velocity? Or are the developers going to sit around with nothing to do because stories won't be ready? Or better yet, can we move on to the next phase early because we're going to blow through / complete all the stories originally planned for this sprint/phase?

It is important to see the status of those higher-level analysis and UI research tasks that precede the coding stories. If UI work was substantial enough to make it visible as a "story" then you have to be able to say if it is not started, in-progress, or done, and have target expected completion dates so the team can get some kind of assurance about how and when the backlog may grow or shrink.

You can even assign and track analysis estimates and velocity in the same way that you track development velocity. But don't mix the two things together; the velocities are measuring completely different things.

UI research and the subsequent problem definition and solution finding (design thinking) will either add new coding stories, provide details for existing stories, or remove stories. Where the research provides new details for existing stories, that information will increase or decrease the stories's complexity. Likewise, adding and removing stories changes the estimated amount of effort in the backlog.

Being able to see when UI findings are likely to conclude gives the team information about future events that could affect the backlog and helps everyone roadmap the project's progress.

The team needs to be able to see it like this: Our velocity is V. The total point value of our backlog is 4xV so the project should complete in 4 sprints BUT, we still have two UI research tasks to complete and our experience so far on this project indicates that those tasks could add as much as 1xV each in changes to the backlog. So we have a total potential story point increase of 2xV. Therefore, as of today, our best estimate of finishing is in 5 sprints but we may need as many as 6.

(If you are curious about assigning story points for tracking velocity, here's one nice way to do it.)

Is there room for UCD in Agile? part 2

In my last post, I started to cover some ground on how Agile and UCD can fit together. These postings come from a discussion on agile usability in which Robert Biddle of Carleton University, asked me three very good questions.

Q1: are the UI designers and programmers within the same team but do different kinds of tasks, or do they do both?

Q2: what are the UI stories (or backlog items) like, especially for user research?

Q3: do the UI stories count as "done", even when no software has been written?

My answer to Question 1 essentially elaborates on my previous post: UI designers and UI programmers are just another flavor of business analyst or programmer and they would collaborate with the other analysts and programmers on all the tasks that need to be done including user research and usability testing.

For example, a team could have a person who has skills in UI design and UI programming. That person could pair up with another analyst to do user research in one iteration, then pair up with a developer to code the UI part of a story(s) in another iteration. A team may also have a person who is a UI designer and experienced in user research but not experienced in UI programming. That type of person would stay completely in the analyst / customer proxy role doing things like user research, product design, acceptance testing, facilitating showcases with the stakeholders, and also any needed product documentation.

The other programmers on the team would also pair up with UCD analysts as needed to have conversations, investigate solutions to a problem interface, and conduct or witness research into the user experience.

Q2: what are the UI stories (or backlog items) like, especially for user research?

We have to be careful with the term "story". "Story" is a thing that developers implement. "Tasks" are things that have to be done to get stories through the pipeline. Tasks are activities people do to figure out what the story should be, realize the story in code, or verify the story is done. You have a UI story if you have something that can be stated like this:

As a mother, I want to be able to search for a doctor who can treat my child's condition and practices close to my home. Acceptance: The search functionality must be easy to find on the home page, you can search by all or part of a medical term (e.g., cancer, scoliosis, juvenile diabetes) and/or a location (city, state, zip), the search results will include the doctor's names, specialities, location(s) and photo.

You have a UI task if you have something that can be stated like this:

Interview/observe 6-10 mothers of children under the age of ten to understand how they would search for and find a doctor for their child on the internet.

Or this:

Interview/observe 6-10 mothers of children under the age of ten to gather information on their expectations for a children's hospital website.

Or this:
Analyze interview results and identify new candidate stories for inclusion in the current or future development phases.

You definitely make the coding stories visible in the master story list and track their progress, but you may not build a backlog of all of the tasks. High-level tasks might be treated "as if" they were stories so it is easy for the entire team to be aware of overall progress and activities for the iteration, but your tracking system would have some type of physical distinction between the analysis/UI tasks and the coding stories.

For example, your information radiator/story wall would likely use color or parallel tracks to distinguish coding stories from other activities. The development track might show stories 2, 3, and 4 in play while your analysis/UI track might show that story 1 is out for customer and UI acceptance testing, detailed requirements discovery is starting for story 5, and user research (UI task) relevant for proposed backlog stories 6, 8 and 9 is in-progress.

A lot of tasks are not made visible because it's just too much noise. But people still report status and blockages in daily stand-ups -- I'm going to be late finalizing the requirements for story 5 because I can't get a meeting with Mr. Y; we need to get the XML spec for the interface to system G before we can complete story 3; our user interviews are proceeding on schedule and we have no problems to report.

I'll cover question 3 in another post since that also has a long-ish answer.

Is there room for UCD in Agile?

I'm a member of an agile usability discussion group. There has been a lot of discussion lately about how and whether designers and UCD people can work within an Agile project. There is a lot of concern that methods and aproaches may not mesh -- that Agile starts developing and releasing stuff long before the designer can complete their diagnosis of the problem and create an effective solution.

for most of my time at ThoughtWorks, we did not have any UCD staff but that has changed over the last year or so. Still, every project is different and we shape it according to what works for the situation.


Sometimes, there is no UCD involvement and business analysts and developers just have to make things up based on what they see as making sense and where the client is coming from (often these are applications for the clients internal use ). Sometimes there are projects where the client hired a designer independently of bringing TW in for the implementation and their design is pretty much a static requirement in place at the start or delivered part way through (not very good). And then there are projects where we can have our own UCD person on-board or the outside design firm is committed to working as part of the team through the life of the project. That's when it gets good.

Ideally, there is one or more UCD-skilled person(s) involved on the team through the life of the project. When you have this, the UCD person is utilizing their skills as they play some combination of other roles: product owner/customer, business analyst/SME, developer. This is very much like the way a business analyst would also fit into team.


A business analyst has to be able to understand the business operationally, grasp the strategic objectives of the stakeholders; interview stakeholders and customers/users to discover and verify requirements; be an advocate on the team for the customer/stakeholders; be an advocate for the strategic objectives (sometimes even stakeholders lose track of the greater goals); know enough about technology to have an intelligent conversation with developers so they can advocate back to the stakeholders when choices get hard; and maybe even sometimes do something technical themselves, plus be able to specify and conduct effective acceptance tests so everyone can be assured the story is Done when it's done.

That is not so very different from what the UCD person wants to achieve. Given that, the UCD member of the team is just another flavor of analyst /developer on the team. They concentrate on their specialty but they also collaborate on other just-in-time project tasks as appropriate. For example, maybe doing javascript coding or conducting showcases with the stakeholders, or writing stories and acceptance tests. Programmers also pair up with the UCD analysts as needed to have conversations, investigate technical issues, or research the business problem.

In my next post(s), I'll discuss three very specific questions about how this can work.

Great Leaps Forward

Last month, the Financial Times ran an excellent editorial about government and business activities that exhibit the Great Leap Forward syndrome.

The author, economist John Kay, uses the example of Mao Tse-Tung's attempt to restructure China's economic base to illuminate why large-scale software projects also, often end in failure.

"Great Leap Forward syndrome begins with an aspiration to remedy serious past failure with unprecedented future success...." he writes. "...In a Great Leap Forward, the wish is father to the thought. There is no recognition that past failure means that future success will be hard to achieve."

It's a short column but one that, in the second to last paragraph, effectively makes the case for an agile approach.

My previous project

Here's a little self-promotion:

Martin Fowler had a very nice write-up about my last project, the one that's still going without me. He said, "It's a favorite of mine because it exhibits an important property of my preferred view of software development: a long term support of a business function enabled by a well-designed code-base. The fact that they are still adding useful business value after ten years is a big dollop of kudos."

He also referenced a podcast about our project, Keeping Grey Code Fit, in which I am one of the panelists.

I didn't have any thing to do with that well-designed code base. We had and still have, a great team of developers. But I will take some credit for ensuring that the stuff we added over the past few years still had business value.

For example, my friend and fellow TWer, Josh Evnin, and I worked with members of the client's staff to do two contextual inquiries with the end users. This research revealed a sizeable list of quick-payoff process and software improvements, and helped the client avoid some expensive decisions.

We gave a presentation about this work at Agile 2008. The experience report is available through IEEE for $19 but if you are a registered user, the .pdf handout of our presentation, Are You Sure, Really: A Contextual Approach to Agile User Research is on the Agile 2008 wiki. Or you can contact me for a copy.