Business and Technology Consulting
Ryan Shriver is a Managing Consultant with Dominion Digital, a Virginia-based Business & Technology Consulting firm where he's a leader in their Agile practice (dominiondigital.com/agile). He helps organizations and teams transition to Agile ways of thinking about solving problems, ranging from new product lines to operational performance improvements. Ryan's solutions typically use some combination of people, process and technology to deliver measurable results.With a deep background in software architecture and enterprise Java, Ryan understands the challenges and issues facing development teams to deliver predictable results. His approach to getting senior leaders to define measurable objectives and priorities for their organizations, projects and development teams helps bring focus to the highest priority initiatives. Using agile methods like Scrum, Ryan helps teams iteratively deliver value quickly to the business...often in a matter of weeks.
Ryan's experiences with diverse companies and teams are the basis for his presentations on Agile subjects.
Presentations by Ryan Shriver
Smart Decisions
Aligning organizations, projects and agile teams with measurable business objectives. The attendee will learn how to align their work in agile teams with higher-level business objectives and see a case study of this in practice. This talk is designed for people yearning to get "more out of agile" and should help them learn techniques that can be applied in their world.the agile engineer
Thursday, August 7, 2008
I had about 20 people attend my Measuring Business Value with Agile talk yesterday. This was the second time I’ve given this talk and in some respects it was harder the second time. I added some material the night before and likely tried to pack a bit too much into the talk.I had a handful of people come up afterwards to tell me talk was exactly what they were looking for, so that made me feel good. During the talk I discovered the first part (defining business value) was a bit boring and I know I lost some people. The second part (exercise) was more engaging and when we got to the Impact Estimation part I think people really got was I was trying to convey. So that went better and it ended on a good note.
Afterwards Robin Diamond gave me some really good feedback on the style and approach, so I’m going to revamp this talk before the ICSPI talk in October. Among the changes:
Create a Hook - I really need to get a hook at the beginning, in the first 5 minutes, so I can capture people’s attention. Robyn suggested pulling the exercise forward and using it as the hook and I think I’m going to do that.
Dropping Content - I’m going to drop my background and how I got to where I am, most people don’t really care about this.
More Pictures / Less Words - Some of my slides are too busy with words and I need to get more pictures and less words on each one.
More Entertaining - Robyn reminded me we’re partially in the entertainment business and presentations need to be more engaging, this is certainly something I can work on in my presentations instead of presenting lots of information.
More Details for Exercise - Some folks were a bit confused on the exercise because a lack of background information. This is what happens when you’re so close to the content, you forget that everyone else is new and assumptions you have they don’t hold. I got some complaints about this and I can see why. Also, I don’t need to present all the info at once, I can spread it out and introduce just-in-time.
So overall pretty good, but could be better. I’m motivated to make improvements now for ICSPI in October.
After sitting in on three talks about Business Value, I know I’ve got some original (to the community) ideas, I just need to work on my presentation style, format and materials. I think this will help convey the concepts better.
Thursday, August 7, 2008
I’m sitting in the Toronto airport on the way home, wrapping up the week at Agile 2008. I’m leaving a day early so I won’t see Thursday afternoon or Friday morning sessions, but I did see enough to form some opinions on the state of Agile:Is Bigger Better? - I heard there were 1,525 people registered for the conference and it sure seemed like it. What a big conference. The agile community continues to grow and become more mainstream, but I’m not so sure this is a good thing. I think things are getting watered-down for appeal to the lowest common denominator.
Tool Guys - The two title sponsors were tool vendors and I’d bet half the other sponsors were selling tools as well. I guess this is inevitable but it’s a bit sad. Lots of people looking for shiny new things that I’m not convinced really help that much.
Too Many Sessions - There were 12 session slots over 4 days, so an average of 3 session slots per day. Most session slots had 44 tracks which was way too many. Some sessions had 1 or 2 people. I’m not sure Agile 2008 turned away anyone who proposed a session. I wish next year they’d cut the number of sessions way back, maybe in half, and keep the better sessions so each one had better attendance.
Overexposed Rock Stars - The Agile celebrities continue to dominate. I was told that there was a limit to 4 sessions per speaker and some of the brand names took full advantage of this. Maybe it’s a bit of sour grapes on my part, but it seems the folks who have books and seemingly present at conferences for a living should maybe be limited to 2 or 3 sessions and let others get a bit more exposure. But I’m sure the leadership in the agile industry have little incentive to change things, seeing as how selling books and classes is how they earn a living.
Lack of Engineering - There’s still a real lack of engineering focus at this conference. Too much code-level, not enough systems engineering level talks. There must have been two dozen TDD talks and lots of code-level stuff, but I’d bet there’s less than a handful of talks about engineering systems using agile. Scott Ambler had a good talk about getting started on Kicking Off Agile Projects and Mary Poppendieck and Michael Nygard had a good talk on Complex Systems. These were refreshing yet sadly too few and far between. This gives me hope that my Agile Engineering talks will present some fresh ideas for the community, but talking about engineering robust systems is definitely not mainstream.
Overall Agile 2008 for me was good in some respects (meeting people, hearing some interesting sessions), but on the whole I can’t say I was blown away. Maybe that’s just me being a bit cynical, but I think there’s something lost with something gained.
Friday, August 1, 2008
After a busy July with new project work, I’m getting ready for next week’s Agile 2008 conference in Toronto. I’ll be speaking on Wed, Aug 6 at 2pm in Civic North #2 on “Measurable Business Value with Agile”. The presentation will be on the synthesis of ideas from Evo and Scrum and how they can put together in practice. If your going to Agile 2008, please attend and say hi afterwards or even shoot me an email in advance. I’m up for discussing the finer points of agile engineering or measurable business value in the bar over drinks!I’ll also be giving this talk at the International Conference on Software Process Improvement in Washington, DC on Oct 21 - 22. I’m not sure my time slot yet, but if you plan to attend this conference, please consider attending my session.
Finally, I’ll be giving my “Agile Engineering for Architects” talk at the Agile Developer Practices conference in Orlando on Nov 10-14. I’ll be speaking on Thu, Nov 13th at 2:45pm. I’m getting excited for this conference and plan to update my presentation in advance based on feedback from the Agile ITX conference. If you’re planning to be there, please get in touch in advance or at the conference, I’d love to meet up.
Thursday, July 10, 2008
I just finished three days of sales training using Miller Heiman’s Strategic Selling and Conceptual Selling training classes. My company brought them in and the entire leadership team went through the courses. I learned many new things about complex sales processes and how to best position yourself to achieve a Single Sales Objective for each opportunity.One of the more interesting concepts I learned was that of the Buyer Influences that are involved in all complex purchasing decisions. Buyer Influences are roles that are always present on every complex purchasing decision (such as when a consultant sells services to organizations). Your job, as someone selling into an organization, is to figure out who is playing each role and to ensure you’re paying attention to all of them.
But the roles aren’t equal. The User Buyer Influence includes the hands-on users of the new system and their bosses. The Technical Buyer Influence includes IT, systems, architecture, security, etc. Each of these has a certain degree of influence and can screen out or derail your sale...essentially they can all say no and stop you from closing the deal.
But they can’t say yes! Only the Economic Buyer can do this. Economic Buyer’s have the approval to release funds and sign the contract. The lesson to the class was that during the sales process pay attention to everyone who can say no, but above all else, pay special attention to what the Economic Buyer considers important, because only they can say yes.
So let’s recap here. One of the most widely used sales training programs for the last 30 years says you should always pay the most attention to the needs of the Economic Buyer, because they control the funds. Common sense, right?
By now you’re probably asking yourself what this has to do with Evo? I’d say everything.
Here’s the connection:
In every deal, the Economic Buyer Influence is looking for improved results in some fashion after the promised solution is implemented. That’s what they pay money for (in part...as I learned...personal reasons are also part of the decision). These business results are usually expressed as impacts to the bottom line and should always be quantifiable (according to both Miller Heiman and Evo).
Since the Economic Buyer is the #1 person with respect to selling the deal, their objectives should be the implementation team’s #1 focus when delivering a solution. I mean, they put up the money for the project, right? Seems kinda fair that the most important person gets attention for their requirements.
But in practice this rarely happens (our trainer corroborated my experiences)! As soon as the deal is closed, the User and Technical Buyer Influences take over the project. Sales tosses it to Delivery. And the race is on. The swarming begins (picture ants). Write User stories, create project plans, set up development environments, draw up architectures and all sorts of things. Busy, busy, busy, busy.
Yet sadly, the Economic Buyer’s measurable results that were promised in the sale, are somehow either lost in the shuffle, never specified clearly by management or taken seriously by the team.
How can this be?
This is where Evo can help. Evo’s concept of the Top 10 Business Objectives aligns with the Economic Buyer’s Requirements. They’re the same thing. When written in Planguage, a planning language, the Economic Buyer’s Requirements can be specified succinctly with precision.
So how would this work in practice? Let’s imagine an Economic Buyer who is looking to increase revenue for a product line. He’s determined that improving current customer satisfaction is part of his strategy for increasing revenues (too many customers are not renewing due to poor issue resolution). One of the biggest historical customer complaints has been the time it takes to submit an issue and get a resolution implemented. For critical issues, while the system is down, customers lose tens or hundreds of thousands of dollars. They tend to get pissed off when things like this happen and don’t want to sign new license agreements. Thus lower revenues.
So our Economic Buyer is looking for a solution to help fix this and some other issues. Using Planguage, we could express this one Economic Buyer requirement as:
Name: Improve Issue Resolution Time
Scale: Elapsed time in hours from when [Defined Issue] is detected by customer until tested fix is applied in the production environment.
Meter: Issue Tracking System monthly report of all reported issues
Benchmark [Current Release; 186 customers; Issue = Critical; 90th]: 32 hours <-- May 2008 report
Target [Next Release; 90th; Issue = Critical]: < 8 hours <-- Top 3 Customers are asking for this level
Failure [Next Release; 90th; Issue = Critical]: > 24 hours <--Tightest current customer SLA
The syntax is a bit odd, but hopefully you can see how clearly we created a name and scale of measure for the requirement that was simple and makes sense. We also parameterized our scale and specified precisely how we’re going to measure progress (a monthly report). Finally, the current Benchmark was provided, followed by Failure and Target levels of performance for the next release and the sources where the numbers originated.
With these 6 lines we can express over a 15 pieces of important information about this one requirement alone. For an Executive Buyer’s “Top 10 Objectives”, that would be 150 pieces of critical information on one page. How’s that for Agile AND Rigorous?
With each of the top objectives specified at this level and then prioritized for implementation, we could use Evo or Scrum to deliver results iteratively. By leveraging Planguage, we’re now able to actively measure our progress towards objectives in terms the Economic Buyer specified when they released funds for the project! And they can even...gasp...“re-focus their funds” on new opportunities if the project isn’t delivering the promised results.
What a novel concept!
So next time you see the sales consultant in the hallway, walk up to them and ask, “Have you figured out who’s the Economic Buyer?” If they don’t think you’re nuts and actually say “yes”, then ask them to share their Win-Results for the Economic Buyer Influence and make sure you focus on their needs first. They’ll know what you mean :-)
Thursday, July 3, 2008
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.
