the agile engineer

One Kid, Two Kid, Red Kid, Where did my time go?

Tue, 18 Oct 2011 09:49:54 -0400

When you have your second child, along with all the joy comes the stark realization that what little remaining free time that you had after number one now completely disappears. Bam. Gone. And that free time you had before kids - you can't remember that far back. What was life like back then?
This is a leading contributor to my lack of blog posts for six months. Quite frankly, life has been a whirlwind recently. Between the arrival of our new baby girl Luna Marin (born July 18th), her growing big brother Indie (2 1/2), multiple client engagements and organizing Innovate Virginia, life has been a sprint since early April.
With the arrival of Fall I'm trying to find a better work-life balance with the little free time I have. But before I look forward, I thought I'd reflect a bit on life recently, starting with Innovate Virginia.
I helped organize the inaugural Innovate Virginia here in Richmond, VA focused on innovation in software delivery. It was a long time in the making - since last November - and represented a large part of my time over the past few months. One of the most challenging and rewarding aspects was creating the program and finding the speakers.

Before the Backlog

Mon, 21 Mar 2011 08:00:05 -0400

Some of the more interesting techniques I’ve been using recently are about what comes before you start the Scrum or Kanban processes. How do you know your next release is building the right features for the right people?

Most software delivery methods are silent about how you go about building the right backlog. It’s a problem that we deal with continually so we’re motivated to continually improve our methods in search of effective and practical techniques we can use with our clients. Recently I’ve been working with two colleagues, one from customer marketing and the other from user experience, incorporating these more progressive techniques into our engagements. Later this week we’ll be demonstrating these in a session at our local agile user group. The session is titled:

Before the Backlog: Interactive Techniques for tying Stories to Stakeholders (download)

The primary agenda is to help Agile Richmond’s board identify web site improvements based on input from attendees. The board (of which I’m a member) have stated we’d like to improve our web site this year but we’re unsure what our members (and non-members) want. So we’re going to ask them in the course of an interactive session.

The secondary agenda is to teach some of the techniques we’re using including:

★ Stick Personas - Lightweight representations of real users including a catchy name (thus “sticky”), a brief bio, adjectives, likes / dislikes and goals (which can be measured). I learned this technique from a session with David Hussman and Jeff Patton at last year’s Agile 2010 conference and have been using it since.

★ Story Mapping - A visual map of the major activities and tasks to complete a process. In eCommerce, this could be registration or purchasing a product. I learned this technique from Gabrielle Benefield in the Certified Scrum Product Owner class I took last year and also saw it done quite well at Hussman and Patton’s session last year.

★ Visual Release Planning - Overlaying the story map with the planned scope for the upcoming release, based on prioritized tasks within each activity.

We’re finding these techniques are not only more effective for getting the right information, they also take less time (less cost!) and are more fun than writing requirements documents and scheduling document review meetings (so boring!).

I’ll plan to upload our presentation after the meeting, but in the mean time here’s two recent snapshots, the first of a sticky persona and the second after a story mapping session for an eCommerce project we’re doing:

In this photo, the product owner at the right is reviewing the activities (yellow stickies) and supporting tasks (pink stickies) for the shopping and checkout processes for Rebecca the Registered User. The agile coach and dev team look on inquiring about the details of each task. Once the tasks are prioritized under each activity, the agile coach will draw a line from left to right showing the planned cut-off for the next release (whiteboard painted walls makes this easier - you can faintly see the line in this photo). Afterwards the agile coach will turn ~90% of these tasks into user stories for the release backlog and prioritize for implementation.

After a few pilots we’re seeing some positive results of these one-day, full-immersion workshops:

★ Our clients like these techniques because in one day we can collectively sketch out the entire context and scope for a project. At the end of the day, everyone has a good understanding of who we’re focused on (personas), what’s desired (activities and tasks), what’s most important to the product owner and what areas are the riskiest and need to be further researched.

★ Did I mention everyone? Yes. In addition to those responsible for planning such as the product owner and agile coach, we engage the entire delivery team in the day’s session including developers, testers, analysts, user interface designers - anyone who’ll be working on the project. Doing so ensures they hear directly from the customer what’s most important and what’s not. At the session above one of our developers told me, “I’ve never come up to speed on a project this fast - I feel like I really get what the customer wants”.

★ In one day’s session, we can sketch out 2-3 releases’ worth of stories and have a good plan for our next release agreed upon by the product owner by the end of the day. After this day’s session, our user interface team can start working on wireframes, our agile coach can flush out the stories and layout the delivery plan and our development team can do research on some of the risks identified.

We do this workshop within the initial two-week inception phase before delivery begins, but doing it in this manner allows the team to get engaged and started quickly with everyone on the same page after the initial one-day session.

This particular team is using a mix of Scrum (roles, artifacts) and Kanban (WIP limits, pull, weekly cadence) - sometimes referred to as Scrumban. Although this project is still in flight, so far the results are encouraging for rolling these techniques out to all our engagements.

I’m looking for some feedback from readers on these ideas. Are you also using interactive techniques like these to elicit requirements? What’s been your experience? Any other ideas we should be trying?

Looking Back on the Gantthead Years

Mon, 24 Jan 2011 20:44:48 -0500

If you’re like me, the beginning of the year brings a time of reflection on what you’re doing and where you’re going. For me this means thinking about priorities and where I need to spend more time and (consequently) where I need to spend less. As a result of wanting to spend more time focused on my value work, I’ve decided to cut back in other areas - one of which is as a regular contributor to gantthead.com’s agile department. After two years, eight articles and a webinar I’ve decided to hang it up.

During my time with gantthead I worked with editor Doug DeCarlo. Doug was a great sounding board who helped me shape ideas into articles - always with enthusiasm. He’d let me know when something was good and when it wasn’t. Based on reader’s feedback the process worked - so thanks Doug for the opportunity and help along the way!

Without further ado, here’s all my gantthead articles in reader-preferred order (on scale of 1 - 7). Click on the title to view the PDF version.

Product Qualities Approach, Agile Style - 6.8
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.

Seven Strategies for Technical Debt - 6.7
This article introduces you to technical debt, including common symptoms of organizations suffering under technical debt. You'll learn the basic steps to set up a repayment plan, the common causes of technical debt and effective strategies for paying it down.

Hyper-Productive Agile - 6.5
This article introduces you to the key practices used by Scrum teams around the world to achieve hyper-productive results (4x - 8x) including the practices your team can apply right now to get started.

Agile Engineering: An Introduction for Managers - 6.3
This article introduces the Agile Engineering principles and practices enabling some teams and their respective organizations build very high quality software, very quickly that pleases customers. Organizations embracing Agile Engineering practices, when used in conjunction with Agile and Lean management practices, can gain delivery advantages on their competitors while managing lower maintenance and support costs in the long term.

Bolstering the Backlog - 6.1
This article introduces the concept of a Results Backlog for maintaining the prioritized business objectives and product qualities. It encourages quantification of these and regular review of the progress towards goals during planning.

Value Thinking in Lean Times: Put the Hatchet Away - 6.1
This article, written during the midst of the economic downturn, encourages IT leaders to resist the urge for across-the-board cuts and instead focus their teams on delivering value to their stakeholders through the use of prioritized, measurable business objectives.

Four Techniques for Delighting your Customer - 5.8
This article introduces techniques for better defining your customers and their desires to help ensure teams know who their customers and users are, who they are not and how to create winning solutions for delivering value.

The Art of Finding the Real Release - 5.5
This article introduces the basic practices of finding the real objectives of your next release, using a case study as an example.

Tools for the Agile Engineer

Tue, 23 Nov 2010 14:21:01 -0500

I’m working on my final article for gantthead.com and I’ve decided to write an introduction to agile engineering - the catch-all terms that refers to the principles, practices and tools associated with building quality products using progressive methods.

My goal is to create an article with the principles, practices and tools in use on real projects in common platforms such as Java, Ruby and .NET. In doing so, I need your help to ensure I capture the most popular tools commonly used in practice. See my current list below and give me some feedback on additions or subtractions based on what you’re using (and endorse). You can either add a comment below or send me an email to get me your feedback. I’ll post the full article here once published in December.

Note: I’ve organized these primarily by development platform, but many of these tools (such as source control and continuous integration) work on multiple development platforms. I’ve also tried to capture the more popular tools and not an exhaustive list of ever tool made....

Java
• Integrated Development Environment (IDE)
✓ Eclipse, NetBeans, IntelliJ IDEA, JDeveloper
• Source Control
✓ Subversion, Git, CVS, Perforce
• Continuous Integration
✓ Hudson, CruiseControl, Continuum, AnthillPro, Team City, Bamboo
• Build & Deploy Automation
✓ Ant, Maven, AnthillPro
• Unit Test Automation
✓ JUnit, JMock
• Acceptance Test Automation
✓ FitNesse, Selenium
• Code Quality & Reporting
✓ PMD, Sonar, Emma, FindBugs, CPD, Clover, Cobertura, JaCoCo, Simian, jcoverage

Ruby
• Integrated Development Environment (IDE)
✓ TextMate, NetBeans, Emacs
• Source Control
✓ Git, Subversion, Perforce
• Continuous Integration
✓ Hudson, CruiseControl.rb
• Build & Deploy Automation
✓ Rake, Capistrano, Passenger
• Unit Test Automation
✓ Test::Unit, RSpec, Mocha
• Acceptance Test Automation
✓ FitNesse, Cucumber, Selenium, Watir, Shoulda
• Code Quality & Reporting
✓ Metric-fu, Reek, Roodi, rcov, RailsBestPractices, Saikuro, Flog, Flay, Heckle, Churn

.NET
• Integrated Development Environment (IDE)
✓ Visual Studio, MonoDevelop
• Source Control
✓ Team Foundation Server (TFS), Subversion, Mercurial, Git, Perforce
• Continuous Integration
✓ CruiseControl.NET, TFS, AnthillPro, Team City
• Build & Deploy Automation
✓ NAnt, MSBuild
• Unit Test Automation
✓ NUnit, MbUnit, xUnit
• Acceptance Test Automation
✓ FitSharp, Selenium
• Code Quality & Reporting
✓ Sonar, NDepend, NCover, dotCover, Visual Studio, Simian, Resharper

Reflections on Lean Kanban 2010: Stop Starting. Start Finishing.

Sat, 2 Oct 2010 07:16:57 -0400

It’s been a little over a week since I boarded the plane home from the Lean Kanban 2010 conference in Antwerp. I’ve been meaning to take some time to write up my thoughts and a recent post got me thinking I need to do this before too much time passes and my memory fades.

So here goes.

To set some context, my agile journey started with XP ten years ago and gradually migrated to Scrum about four years ago with some Evo ideas tossed in for good measure. The past few years I’ve watched the Lean community grow, taken Mary and Tom’s course and read their books. In all this I’ve largely stayed on the sidelines as the new Kanban community grows.

Frankly, I was skeptical on Kanban. I thought it was a way for a handful of agile talking heads to say “Agile has become soooo mainstream (i.e. boring), we’re onto something cool and new”. This happens all the time in the technology community and I sensed a similar pattern. I’m naturally suspect of “new cool things” and although I sat in a few sessions at Agile2010 about Kanban, I still came away thinking “neat ideas...but doesn’t really change my mind”.

It took a trip to Antwerp for me to get it.

The “aha” moments happened less in the formal presentations (which were good), but in the conversations with fellow speakers and participants over breaks, dinner and wonderful Belgium beers in the evening. These discussions helped me make the connection with what Kanban really is and how I, my company and my clients could benefit from introducing it into our lives.

I left Antwerp with lots of new information, but a few things really stick out in my mind. In addition to the simplicity of “Stop Starting. Start Finishing”, they include:

1. Kanban is the simplest way to teach Agile transitions

As someone who helps teams and organizations transition to agile, even though I tend to thing teaching someone the Scrum process is pretty easy, it still contains lots of new things from their perspectives. New roles. New artifacts. New processes. New collaboration. For relatively immature teams this can still seem like a lot of change to absorb at once. Especially one that comes from an outside consultant.

I’m struck that Kanban’s first two steps of “visualize current work” and “limit work in process” are much simpler to absorb for a few reasons. First, it works on a team’s existing processes today and doesn’t require immediate changes to the way they work - at least to start. Second, its less threatening to teams because we’re just visualizing their current process where they are still the expert. Third, by setting limits on work in process, teams can start to figure out for themselves more quickly how to resolve issues. The team is more engaged in owning the process than when a new Scrum process is introduced by an agile consultant like myself and the coach is suppose to have all the answers.

While there’s much more to “becoming agile” (whatever that means) than setting up a Kanban board, I think it’s the easiest place to start a team heading down the agile path and can be an entree to adoption of agile and lean techniques.

1. Kanban can greatly improve delivery within a Sprint

I’ve always focused my Scrum teams to use pair programming and focus on the highest priority stories before working on lower priority stories. Inevitably with many teams I have to continually remind them of this and even then it doesn’t always stick. With Kanban’s explicit limits on work-in-process being transparent, it helps the team see they can’t pick up new work before completing existing work. They also must collaboratively figure out how to get stories passed and work through their constraints. Even if using time-boxed iterations for delivery, I think there’s value in using a Kanban board to visualize work within a Sprint is invaluable. Basically, a Kanban board is an improved story tracking board.

1. Kanban can be used with Agile - it doesn’t have to be Us vs. Them

Although one of the tenants of Kanban is the idea of continuous flow without a need for time-boxed iterations, it’s not mandatory to toss the iterations...at least at first. Perhaps over time with enough metrics on lead time the iterations can be removed, but for teams looking to get more out of their current iterations, Kanban can be an effective tool as a replacement for your story board. Blend the best of both to start instead of throwing out Scrum for Kanban.

As I’m learning, the folks in the Scrum-ban community have already figured this out and provide a nice transition plan.

Since returning I’ve lined up some opportunities to try out Kanban within our company and for some clients new to agile. I’m currently reading David Anderson’s book and hope to learn some new ideas for putting Kanban in practice. We’ll see how it goes and I’ll try to blog about successes (or failures) I experience.

Lastly, I’d be remiss if I didn’t say thanks to Maarten Volders for organizing such a great conference. I had a blast. I’d also like to thank those speakers who helped me learn some very practical techniques including Claudio, Joakim and John. And finally thanks to all the folks I got to hang out with including Robin, Kurt, Christopher, Kitty, Serge, Lillian, Mathieu, Antony, Andy, Marco, Gus, Simon and of course the ever-present Olav. Hope to see you all again.

Lean Kanban 2010: Value over Velocity

Thu, 23 Sep 2010 07:21:14 -0400

You can download my Value over Velocity presentation from today’s session. It is an updated version of the talk I gave at Agile 2010 and I feel an improvement based on the feedback from that session.

In particular I added:

1. Visualization of steps in Value Delivery process
2. Integration with Scrum and Kanban
3. Example of Value Decision table (aka Impact Estimation)
4. Techniques for identifying Customer and Business goals

In order to reduce the presentation from 90 to 60 minutes I had to cut some things too:

1. Exercises to identify and quantify objectives
2. Real examples of poor objectives
3. How my organization is using objectives in our strategic planning processes

Overall I’m happy with the continual evolution of this topic and am interested in integrating these concepts with Kanban as I learn more about it.

Technical Debt: Crossing the Chasm

Mon, 13 Sep 2010 06:09:27 -0400

I’ve been thinking a lot about technical debt recently, it seems to be popping up everywhere for me. This is in part due to upcoming article I just sent to my editor to be published later this month on gantthead.com.

Updated: here it is published on gantthead.com or you can download a PDF
 The article looks at the topic from a number of angles:

1. What is Technical Debt
2. Common Symptoms of Technical Debt
3. Creating a Repayment Plan
4. Strategies for Paying Down Technical Debt

It was a fun piece to write, in fact one of the most enjoyable ones I’ve written this year. I was inspired to write the article through a combination of Jim Highsmith’s talk at Agile 2010 and my current consulting engagements. I think Jim (along with Israel Gat) are doing great work to bring this concept, known for years in the technical community, to the attention of management.

Jim and Israel recognize that addressing technical debt requires buy-in from management who are responsible for budgets, priorities and resources. Without them on board in understanding what technical debt is and how it affects their organizations and the bottom line, addressing technical debt in a proactive manner is nearly impossible.

One of the most interesting things I’ve seen in recent years is how technical debt is crossing the chasm from the technology to leadership communities. While we’ve know for years for that ignoring technical debt results on the need for code refactoring and the creation of ‘technical stories’, what’s now being emphasized is how ignoring technical debt results in extremely costly, risky system rewrites that impact organization competitiveness and the bottom line: topics that get the attention of management.

This shift in focus is helping me better articulate the business impacts of technical debt to my current client’s leadership. In particular, proactively managing technical debt for their products should be a part of their strategy for reducing costs and risks while improving velocity (and even morale).

The topic of technical debt is relevant in two of my current engagements:

In the first, at our sprint retrospective, the team discussed factors limiting velocity and technical debt was identified as a culprit. In particular, lack of automated regression testing is resulting in the team spending more time fixing defects created as new stories are implemented each Sprint. Finding and fixing the defects typically takes more senior members of the team to diagnose, reducing the time they can focus on story development and delivering points.

As we start to plan our next release, having the product owner hear from the team is helping me make the case that a proactive investment in fixing technical debt (meaning prioritizing technical stories over user stories) will eventually lead to the delivery of more features within each release as velocity improves. As velocity improves, the cost per feature will decrease by reducing the cost per story point. Aside from the bottom line impact, the team is currently frustrated it takes so long to deliver each story, which affects morale.

In the second, I presented the results of a recent methodology audit to my client’s senior leadership including the CEO. One of our findings was that technical debt is one of the leading contributor to their product’s and team’s poor performance. As they sign up new customers (multi-million dollar contracts), scalability is affecting their ability to meet customer demand which is translating to a huge risk to their organization. It’s also contributing to the team spending nearly 50% of their time on re-work and fixing defects which is crippling their ability to respond to customers.

In communicating this to the CEO, I borrowed Jim Highsmith’s idea that they have three basic strategies for dealing with their technical debt:

- Do Nothing and it’ll continually get worse over time
- Do Nothing and face a big, expensive, risky system rewrite in a few years
- Commit to Invest in incremental refactoring and proactively managing their debt

Time will tell whether this message resonated enough to warrant action by them, but at least I felt I had communicated the concept as succinctly as possible to the group of stakeholders who have the authority to make do something about it.

For further reading on the topic, here are some of the resources I found useful in researching this topic, maybe you will too.

Helpful Technical Debt Resources

✓ Brad Appleton’s post on Technical Debt Definitions and Resources
✓ Martin Fowler’s post on Technical Debt and the Technical Debt Quadrant
✓ Ward Cunningham’s video explaining Technical Debt
✓ Jim Highsmith’s slide on Technical Debt
✓ Israel Gat’s post on Technical Debt on your Balance Sheet
✓ Tom Brazier’s article on Managing Technical Debt
✓ Sonar’s Technical Debt plugin to help measure technical debt in code

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.