Highlights Of Agile 2010 From Tom And Dave

 

Dave: Tom Grant and I spent the past week in Orlando at Agile 2010 and thought it would be good to share our observations of a fantastic event. This conference has been running for 9 years and during those years has always tried to both balance content and scale with focus and intimacy. This year I think they got it just right.

Tom: Among many virtues of the yearly Agile conference is its ability to be simultaneously high concept and eminently practical. You find yourself in a conversation that’s down in the weeds of build and test methodologies but then veers into a philosophical discussion of what the term “value stream” really means. You can see how, by entering the mainstream, Agile forces a fresh look at everything from SOPs to values.

Dave: This year’s event featured the now-familiar smorgasbord of sessions, from Agile for beginners to advanced topics like scaling and technology support. In addition to the physical sessions, a lot of discussions moved in and out of “open space” where participants could build their own content and sessions. Aside from increasing the number of interactions around an event, open space generates additional energy within the event. Many times, I tried to walk from point A to point B, only to stop and listen to a heated discussion on a particular topic.

Tom: Unfortunately, after the event, some of this energy dissipates. The Agile community really needs a community hub, a site that serves the needs of beginners and veterans across a wide range of topics. 

Dave: Because of the sheer scope of the conference, there was no one theme, but if I were to pick three, they would be (1) UX design and Agile, (2) development operations (dev ops) and continuous delivery, and (3) technical debt.

Tom: I’m going to expand Dave’s list a little to include one more hot topic worth considering in this post: serious gaming. I was very pleasantly surprised by how often it appeared throughout the forum. In a few paragraphs, I’ll tell you why it was a ubiquitous feature of the conference.

UX Design And Agile

Dave: Perhaps because of the importance of new media and their role in the development process, or the applicability of Agile to new media development, we heard many interesting discussions on how to make user experience (UX) design and Agile work well together. The sessions on this topic concentrated on solving one thorny problem: cadence. Traditional designers push for a complete picture; Agile teams want to build a more incremental understanding. Participants made the following recommendations for making the UX and Agile gears mesh successfully:

  • Integrate the designer into the team. Embedding the designer in the team helps resolve the disputes between the need for a holistic view and incremental discovery. In addition, as part of the development process, the designer can tap new sources of inspiration and insight.
  • Don’t start until you are ready. Agile methods encourage some thought prior to building software. In Scrum, this is called “Sprint 0,” which focuses on defining the initial backlog, team, and plans. Designers need to add their own milestones, such as indentifying personas, understanding context, and determining UX goals.
  • Make usability testing part of the normal test process. As unfamiliar as it might be to some teams, incorporating usability testing into normal testing provides immediate feedback loops for both development and design.

Tom: My only addition to Dave’s observations is the following slogan I may put on a bumper sticker: The importance of UX increases every day. UX played a conspicuous part at Agile 2010 because, among other reasons, people are putting a higher premium on the UX component of their applications. That’s a whole other blog post, or several blog posts, to explain why.

Dev Ops/Continuous Delivery

Dave: Agile 2010 could be described as the breakthrough event for dev ops professionals responsible for delivering what Agile teams produce. Emblematic of this trend is ThoughtWorks’ timely announcement of a new continuous delivery product called Go. Too many Agile teams complain that they can only be as flexible as their release organization. Addressed through a tool like Go, process changes, or both, integrating development with operations and release is crucial for long-term business agility. (Phil Murphy from the Application Development & Delivery team has written a very interesting blog on the topic, in which he describes the conflict and asks the Forrester App Dev community for their comments.) At Agile 2010 the discussion about dev ops focused on:

  • Shared goals. Developers (and Agile developers in particular) want frequent delivery; the system admins want infrequent delivery. People who are trying to square this circle are introducing incentives for the two groups to partner more effectively.
  • One life cycle, one process. ITIL, CMMI, and to some extent Agile methods have reinforced the separation between development and operations. ITIL 3.0 may be the basis for an integrated view of the end-to-end process as applications move from development to deployment.
  • Tooling that integrates. Currently, ALM tools support the SDLC, and IT service management tools support the operations groups. Organizations need tools that span these processes and teams. The scions of the Agile movement may have distrusted tools, but it’s hard to imagine solving the dev ops dilemma without them.

Serious Gaming

Tom: Agile focuses attention on the quality of decisions that guide the development process. By shortening the iterations, teams have seized the opportunity to assess their past decisions then make mid-course corrections (and even early-course ones). However, there’s nothing inherent in Agile that tells you how to make a better decision or even spot the bad ones. The exception, perhaps, is planning poker, a conspicuously game-like activity that, for many teams, makes scoping more accurate. Now, teams are considering other games to help with other decisions, such as prioritization, process flow, and design.

Managing Technical Debt

Dave: The Agile community has faced a lot of hard questions about how a methodology that breaks development into short iterations can maintain a long-term view on issues like maintainability. Does Agile unintentionally increase the risk of technical debt? Israel Gat is leading some breakthrough thinking in the financial measures and ramifications of technical debt. This topic deserves the attention it’s beginning to receive, in part because of its ramifications for backlog management and architecture planning. Application development professionals should:

  • Start capturing debt. Even if it is just encouraging developers to note issues in the comments of code as they are writing it, or putting in place more-formal peer review processes where debt is captured, it is important to document debt as it accumulates.
  • Start measuring debt. Once captured, placing a value/cost on the debt created enables objective discussions. It also enables reporting to provide the organization with transparency of the growing debt. I believe that this approach would enable application and product end-of-life discussions to happen earlier and with more accuracy.
  • Adopt standard architectures and open source models. The more people who look at a piece of code, the more likely debt will be reduced. The simple truth of many people using the same software makes it simpler and less prone to debt.

Tom: Since the role I serve, the product manager in technology companies, sits on the fault line between business and technology, I’m really interested in where Israel Gat and others take this discussion. The era of piling up functionality in the hopes that customers will be impressed with the size of the pile is clearly ending. What will replace it is still undetermined.

Tom and Dave: It’s a great show that leads to discussions like these, and we’re both looking forward to the 2011 Agile conference in Salt Lake City, Utah. If you were at the show or have general observations about these topics, please contribute to our own open space here on the Forrester blogs.

Comments

Community Hub

I agree about missing the energy after the event. Folks are welcome to join our community group that meets monthly in virtual worlds: http://www.meetup.com/agile3d . For example, last month's meeting was an online immersive chat to reflect on highlights of the conference. September is a discussion of Kanban vs Scrum.

But thanks for the outstanding writeup / summary of the convention! AgileBill

To Tom's Good Question Where We Take Technical Debt

First and foremost, thanks for the report Dave & Tom!

To Tom's good question: click http://bit.ly/bzHRw2 for the first "installment" on the answer.

Best,

Israel

Unified Life Cycle

Great comments and insights on Dev Ops and managing the release cycle continuously and seamlessly. We have long held the view that ALM is really about not just development, but must bring continuity across the life cycle including the portion where most money is spent - maintenance.

It turns out that delivery is only one point of intersection between dev and ops (or ALM and ITSM) in a long list including change management, problem resolution, incident management, ITBM, etc. All of which are relevant in some way to Agile teams as well as traditional teams.

http://www.mks.com/solutions/process/itil

Managing Technical Debt

Excellent comment by all on managing technical debt. There are a couple of techniques that I wanted to point out.

1. Incorporating technical debt metrics within Defects - As Defects are found by Agile teams, the ones that cannot be fixed during an Iteration should be prioritized for the next one but it is important to capture metrics around a) how many days it has been outstanding b) which product/component it affects and c) If the defect was found related to a User Story which has a high-level Epic associated with it, this defect should be given a higher cost/value.

2. Formal review process for code - As developers check in source code, using a version control tool that allows a formal review process can reduce technical debt as more than one pair of eyes is looking at the code. This works great in pair programming and XP development shops.

One Could be the Manifestation of Another

I would like to add a "1d" to the first recommendation by Harsh: defects experienced in production are often (though not always) the manifestation of technical debt deficits. It is important to establish the relationship between the two and to manage them in tandem. For example, a system crash might be caused by a program passing a null pointer.

Israel