the agile engineer

Agile 2010 Presentation: Non Functional Requirements (Qualities), Agile Style

Thu, 12 Aug 2010 14:13:09 -0400

You can download the presentation and the Impact Estimation spreadsheet as well. I’m happy with how this turned out and would like to thank Dean Leffingwell for working with me on this presentation.

Agile 2010 Presentation: Value over Velocity

Thu, 12 Aug 2010 11:12:15 -0400

You can download my Value over Velocity presentation from this morning’s session.

I had a good turnout, the room was full and it seemed most people got the basic concepts I was teaching. I got some feedback after the session for how to improve it, including more examples for stakeholders, values and objectives and covering impact estimation to show how means impacts ends. I originally had the impact estimation in the talk but pulled it out after some feedback and due to time constraints.

Still one more talk to go later today with Dean Leffingwell on Non Functional Requirements, Agile Style.

Endless Summer

Sat, 24 Jul 2010 20:23:25 -0400

As the heat bears down on us here in Richmond and I contemplate another 100+ degree day, it feels like summer has been here for months. The heat advisory days weeks are starting to become a drag and It’s not even August.

When it really gets hot.

All this time indoors away from the heat should afford me time to write more posts, but I see I’ve been negligent since May 22. Its for a good reason though - I’ve been busy with my family, travel, work and lots of cool projects.

So this is a catch-up post full of things I’ve found interesting along the way:

The big trip was to London for Tom Gilb’s seminar in late June, this time with my colleague Jimmy. The topic was Value Delivery and every attendee had a different interpretations on the topic. My presentation Value Delivery in Practice was about putting Evo and Scrum together on different types of engagements I’m working on. Sort of an experience report from the practitioner’s perspective.

One of the surprises of the conference was Will Hopper’s two-part presentation on his recent book The Puritan Gift. Jimmy and I agreed this was probably our highlight of the week, just listening to Will tell stories and recount history. It was especially nice having the opportunity to get to know Will over lunches and dinners during the week, he’s a very kind and sincere person.

It was also great to see the group of friends I look forward to catching up with every year. This year’s group included (left to right) in front row: Niels, Lorne, Susan, Benjamin, Renze, Grant, Vlatka, Elayne and back row: Alan, David, myself, Bruce, Eilif, Rolf, Jimmy, Tom, Lars, Hubert, Jeff, Gabrielle, Clifford and Lech. There were a few more including Kai, Marilyn and Gerrit that didn’t make the official photo.

Hyper Productive Agile Webinar

Sat, 22 May 2010 08:44:18 -0400

Wow, my first webinar went live two days ago and attracted 1,750 attendees! I still can’t wrap my mind around that. My presentation on Hyper Productive Agile was part of gantthead’s annual PMXPO Virtual Conference.

- If you want to watch it, you can sign-up for a free account here and then login. Once inside, go to Conference Hall and select the presentation. Running time is 33 minutes.
- You can download the slides here (8Mb PDF) and here (1.4 Mb PPTX)
- You can download a companion article here (PDF) with most all of my talking points

As background for those interested, Doug DeCarlo my editor at gantthead, was kind enough to ask me to do it back in March. I had just returned from the Scrum Gathering where I saw Jeff Sutherland’s talk on CMMI + Agile. I was intrigued with his use of the term Hyper Productive to describe teams that were 2x, 4x and 8x more productive than their peers.

Based on my experiences, I knew it was a topic I wanted to explore further and this webinar provided the right opportunity. I tried to keep it short and simple to emphasize a few points:

1. With a solid base of research, agile is more productive than waterfall
2. A minority of agile teams are hyper-productive, meaning 2x - 8x more productive.
3. Wow, that’s interesting, what are they doing differently?
4. Certain practices they use can help explain their extraordinary results
5. Your team can use these practices to improve their performances too

I’ve received great feedback from attendees, thanks to everyone who joined and thanks to gantthead for a great PMPXO conference.

Related to Hyper Productivity, after I had recorded the webinar I had the pleasure to hear Dan Mezick speak at Agile Richmond about the concept of team intimacy and its influence on hyper productivity. Dan goes into depth on the topics of creating emotionally safe environments to facilitate team learning. Teams that work in these environments, and feel personally safe and safe as a team, achieve higher levels of productivity and happiness.

It not only makes sense but Dan provides research showing this phenomena is not just specific to Scrum teams, but all teams including sports teams, military units, etc. Had I seen Dan’s presentation before I recorded the webinar, I would have included some material from it within the the presentation. Next time...

Seeking Feedback on Agile 2010 Submissions

Sat, 13 Mar 2010 10:36:06 -0500

I’ve submitted two tutorials for inclusion in Agile 2010 and would kindly request some feedback from the community. If you have a few minutes to spare, please consider reviewing one (or both) of the proposals and leave a comments if you think they would be a topic worthy of the conference. Just click on the presentation name and add a comment:

1. Evo + Scrum = Value Delivery - based on my recent Scrum Gathering presentation, I’ve received good feedback and encouragement that these ideas should receive broader exposure. Hopefully Agile 2010 can be this opportunity. This is listed as a Talk, but in reality it’s closer to a Tutorial for Product Owners and Scrum Masters who want to learn how to maximize the measurable stakeholder value delivered each Release.

1. Non-Functional Requirements, Agile Style - a collaboration with Dean Leffingwell who is working on a book on Agile Requirements. I was reviewing his chapter on Non-Functional Requirements (NFR) and adding some content around specific practices to define and measure NFR’s. We thought this would be a good topic for Agile 2010 that would appeal to analysts, architects and testers who are responsible for defining, developing and validating the key system qualities.

Thanks in advance for those who can contribute!

Scrum Gathering Presentation

Tue, 9 Mar 2010 12:48:17 -0500

You can now download the presentation (PDF) I gave at the Scrum Gathering today. This is a presentation that has gone through multiple revisions but I’m very happy with how it turned out. I got really good feedback on the session as being extremely valuable to Product Owners to help them connect Product Backlogs with Business Goals.

I believe now, after refining the presentation and the core message (thanks in part to the From-To Think-Do concept), I have the wrong title for the presentation. The primary focus isn’t on Evo + Scrum. The primary focus is that of Value over Features and Ends over Means. Evo and Scrum are techniques, but in fact not the core message (this was validated by an attendee). I’ll see if I can find a better title before Agile 2010 where I’ve submitted this talk.

Many thanks to Tom and Kai for their feedback (and edits on their train ride to Orlando).

Working with the Gilbs in the US

Fri, 26 Feb 2010 20:50:12 -0500

Wow! It’s been a frantic last few weeks, but things are coming together nicely for Tom and Kai Gilb’s visit to the US and my hometown of Richmond, VA. Amongst other things, we’re doing a public course on Saturday March 6th titled “Delivering Real Value with Scrum”. Sign up now to join us for this special training opportunity!

It all started a few weeks back when Kai contacted me saying he and Tom were coming to New Jersey for some training and consulting. Last summer in London we had chatted about working together and now the opportunity had presented itself. They were already on the East Coast and a relatively short flight or drive away from Richmond.

Kai and I brainstormed some course ideas (using Google Wave...I was pretty impressed) and agreed upon a day long course on Delivering Real Value with Scrum. I recommended the course to our executive team and they agreed, choosing to roll it out to everyone in the company interested in attending. Now there’s a positive buzz around the office as folks are looking forward to the team training next week. We’ve even reserved some space at the Capital Alehouse across the street for a social hour afterwards!

While Kai trains our team on Friday, in the afternoon Tom and I are going over to a client of ours where Tom will give a talk on “Measuring Value in Project Delivery”. They are an organization that uses a mixture of waterfall and agile for project delivery. While their project teams can and do report “tasks completed” and “velocity”, there’s no clear way to translate that into value delivered to the business. I’m confident some of Evo’s concepts can give them ideas to try on their next project.

As I mentioned earlier, on Saturday we’ll give a public course sponsored by Agile Richmond on “Delivering Value with Scrum”. Sign up here. I’ll be giving a brief of my presentation Evo + Scrum = Value Delivery. I’m pretty excited for this course and hope we get a good turnout. At $99 for the all-day course (including lunch), this is a great deal.

It so happened that as Kai and I were working out the training details, I told him I was giving a talk (Evo + Scrum = Value Delivery) at the upcoming Scrum Gathering (March 8-10) and that he and Tom should attend. Next thing I know, Kai emails Jeff, who emails Tobias, who makes room for Tom and Kai to give a 5 hour tutorial on Monday. Quick work! Now they’re all heading to Orlando from Richmond on Sunday for the conference.

So now we’ve got two Evo sessions at the Scrum Gathering, Tom and Kai’s tutorial on Monday March 8th starting at 10:30am and my 60 minute presentation on Tuesday from 11am - 12pm. If you plan on attending, please stop by for one or both sessions and say hey.

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:

1. Executive Sponsorship
2. Release Planning
3. Requirements
4. Design
5. Development
6. Testing
7. Release Management
8. Operations
9. Support
10. Training
11. 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.