In the Spotlight - Ryan Shriver

One of the things that helps reenforce new concepts, like the ones I���m teaching, are simple tools that guide you along the way. Like a carpenter���s square, hand plane or ruler, simple tools can be very effective in the hands of a trained engineer. To help further the agile engineering discipline, I���ve created a Tools section of the site and published the first one, an Impact Estimation table designed for Architects and Requirements Analysts.

Impact Estimation is a way to assess a design���s impact on a set of desirable qualities. This can be for one quality, such as Response Time or Transactions per Second, or for a collection of key qualities, such as System Performance.

As useful as Impact Estimation is, what is perhaps even more important is the exercise of filling it out. In order to do so, you basically have to do two things:

Quantify the key Qualities
Estimate a Design���s impact against these if implemented

First, to quantify the key qualities, for each one you capture:

- Name
- Unit of measurement (Scale)
- Method to measurement (Meter)
- Target level
- Fail level

WIth this information for key qualities such as Response Time, Transactions per Second, Scalability, Availability and others you can specify critical information very succinctly. This information is used by the architect and development team who must engineer the system to meet the target levels and avoid the failure levels.

So how does the architect know which design (aka strategy) to pursue that best balances performance and costs? Enter impact estimation. Once you enter the Name, Scale, Target and Fail levels for each quality, you estimate the impact of that design and enter it into the worksheet. This helps you answer questions such as:

If this design were implemented, how much closer to our target level would our system be? What % gain or reduction would we see?
How much do we think it will cost to implement the design? What���s the benefit-to-cost ratio (called performance-to-cost in impact estimation)?
How much certainty (or uncertainty) are we factoring into our estimates?
Do we have credible sources for all our input data or is it based on speculation? Have we done this before on this project or in this organization?
If we can���t reach our target level of performance with just one design, what are our next best options? How many different designs will it take to reach our target level of performance (and how much do they all cost)?
What order should we implement our designs that delivers value quickly and iteratively (in days and weeks)?
Are we factoring any risk into our designs? Are we designing just to spec or beyond spec?

These are some of the big decisions architects must face in systems engineering and represent to management with confidence. In situations with hundreds-of-thousands or millions of dollars on the line, wrong decisions can waste money and evaporate time to market. But if done right, organizations can gain quick competitive advantages by focusing their resources on designs that deliver value quickly and iteratively in an agile fashion.

Hopefully this is just the start of more handy tools to come. Let me know what you think and if you find them valuable.

These are the final ones used for my presentation, so if you want some of the newer slides, please download.

Measuring Business Value with Agile
Agile Engineering for Architects
Agile Engineering for Managers

I���ve uploaded 3 new presentations:

Measuring Business Value with Agile
Agile Engineering for Architects
Agile Engineering for Managers

I���ll be giving these at Agile ITX later this week, we���ll see how it goes!

A while back Clarke Ching contacted me, he runs the Agile Thinkers web site. He was researching people who have used Evo with Scrum. It took me a while but I finally got back to him. I just started writing and it flowed out into my eight-year agile story. If you���re interested in my agile path and thoughts on what agile doesn���t address (but Evo does), give it a read.

Yesterday I was working with an organization that was planning out the next six releases to take them from June through January. I���ve been working with this team for the past few months and it���s taken a lot of work to get to here. We were chartered with coming up with plans and options to present to the CEO the next day that ensured the new system got launched this year.

There are lots of features Marketing and product managers want, each benefiting their client base (the companies products and their product managers are aligned around the different types of clients that use their software. There���s not a single product manager). The product managers and team had identified most of the epics and stories for the rest of the year and yesterday was a full-day estimation and planning workshop. There were approximately 125+ epics and stories in the mix.

The team for the last two Sprints has provided steady velocity numbers so although we only have two data points, we feel like it���s enough to estimate what level the team could deliver at for the remaining releases, understanding that this would get more precise in time. There���s some danger here in extrapolating two data points, but it���s somewhere to start.

At the end of the exercise, with everything laid out, everything Marketing and the product managers wanted this year wouldn't be completed until next June of next year at the current pace with the current team. Features wanted in October wouldn���t be ready until January, thus missing an important seasonal window for their products (and revenue opportunities)!

The leaders were exploring options for what to do, including:

Hiring an outside firm to turn-key develop some of the features in parallel with their development team and integrate (potentially costly and with integration risks)
Exploring options to increase velocity through higher productivity on their team (worth consideration, but wouldn���t alone get the 50% productivity improvement needed to make the schedule realistic)
Bringing on staff-aug folks to bolster the development team to meet the aggressive schedule (costly, would take time to train and be a hit on velocity in the short term).

None of the options were ideal and each presented risks that even if mitigated produced little guarantees the new system would still get launched by October.

Towards the end of the meeting, the head of IT (John) was describing how he needed to present viable options. As currently laid out, unfortunately there are no easy ones that don���t involve pain, a good amount of money and risks that the new web site (the system under development) wouldn���t be launched this year. Also, without additional funding, there wasn���t a clear path to launching a new system by October to maximize the revenue opportunities.

The head of marketing (Karen) next spoke up and said, ���Ted, our CEO, has been telling the board of directors for the past two years that this new web site is our #1 priority. Because we���ve switched technology platforms and had stops and starts, he can���t go back to them again this year and say it���ll be 2009 before we���re live. That���s not a realistic option.���

I then said, ���If you understood what was most important to Ted, what would the plan look like that would allow him to stand up in front of the board and declare ���victory��� and everyone internally feel good about what got accomplished? Does it really involve all these features we���ve discussed or can we create a plan that meets the #1 stakeholder���s definition of success, which is declaring victory that the system was launched to the board?���

The leaders in the room nodded in agreement and Karen really seemed to get it. She said, ���Ted doesn���t care if we implement all these new advanced features, we just need to get a new working system launched with the same features as the current system with an updated look-and-feel. If we got a few of the new features great, but if not that���s ok too, it just needs to look new and improved! And actually, we could live with a re-skinned version of our current commerce system instead of replacing it with the new system and still launch the site.���

Then some of the others starting chiming in, ���It wouldn���t be ideal and we���d have some re-work to do, but we could re-skin the older registration system and link to it from the new site for this year, instead of building the new registration system this year.��� People naturally started thinking about ���What���s the minimum we could we live to launch the system and Ted be able to declare victory this year?���

Based on our estimates, re-skinning commerce and registration as opposed to re-building would potentially reduce 8-10 weeks off the best schedule estimates and bring us back to the October timeframe for launching a new system. The team understood there would be some throw away work to re-skin the current system, but it would also be less risky, because they knew the nuances of the current systems quite well. Although not ideal, it does look like a workable plan.

Time will tell if this works out, but it reminded me of the lesson I���ve learned from Gilb and applied during this session:

Always focus on the needs of the top stakeholder and what���s really important to them, everything else is secondary

In this case, the #1 stakeholder is the CEO, who has to answer to the board of directors for being able to deliver the new system this year. Understanding what���s most important to him (declaring ���victory��� in front of the board on the #1 initiative) can help bring great focus to the leaders and team surrounded with lots of features and options for implementing them.

On your project, are the real needs of the #1 stakeholder visible to all and a part of your planning process? Do you know what it takes to declare victory?