Tag Archives: Sprint

Our History of Agile Adoption

Posted on by

Birth of an Unusual Planetary System Courtesy NASA/JPL-Caltech.My development team began adopting Extreme Programming (XP) in January 2004.

Before this, we were hit and miss. Success relied on individuals. We had few shared practices. Our goal in going “Agile” was to consistently perform across projects.

“Agile” declares a set of common values and supportive practices. It fosters collaboration with customers and shared ownership within project teams.

In time, the team became proficient in core XP practices:

Planning

  • User stories
  • Iterative development
  • Tracked velocity
  • Daily stand-up meetings
  • Regular retrospectives with continuous improvement

Designing

  • Simple system metaphor
  • Use of development spikes
  • Refactoring

Coding

  • Onsite customer
  • Pair programming with switching
  • Test driven development (TDD)
  • Continuous integration
  • Collective ownership
  • Sustainable pace

Testing

  • Extensive unit test coverage
  • Bugs are resolved within the iteration
  • Acceptance testing by the on-site customer

The team Ript page by kjudy

Within a year the team’s performance was more consistent and visible. We were measuring our velocity and predictably delivering on our 30 day iteration goals.

We discovered our project management practices had become a bottleneck. We were clearly hitting idle periods within and around projects because of a failure to efficiently describe and prioritize work.

We introduced Scrum as a management framework on top of XP. It provided practices for organizing and prioritizing work. It helped us define roles and responsibilities.

We clarified our expectations of internal clients and achieved more efficient interactions overall. We created mechanism for reporting progress and costs to senior management.

In Q1 06, the team’s practices were evaluated by an Agile Coach, Jason Lewis. Among his findings:

Oxygen Media’s Agile software development process overall rates above average and is better then the benchmark team. The benchmark did have considerably more Agile experience, but less time together as a team.

In the evaluation of practices, the team was overall: 1) well above average to outstanding in the adaptive learning practices, 2) Above average in Sprint practices and 3) Average in planning practices. High points for the team’s individual practices were the retrospective and use of the wall for iteration tracking. The one low point was the maturity of acceptance testing.

When comparing roles to the benchmark team, the benchmark team had a much better customer role but the team was stronger in the developer and facilitator roles. When comparing the team’s adoption of the practice’s versus the benchmark the team was generally more effective. Iteration tracking was one key area the benchmark team was better, however, the team was much stronger in the all the adaptive learning practices.

Scrum Release Burndown by kjudyAfter the audit, we pre-staged our iteration planning, reduced our iterations to 2 weeks and formally planned releases.

We added discipline to our acceptance testing. We described acceptance tests in a narrative script authored by and exercised by our product owner (proxies).

We never automated acceptance tests for rich windows applications or systems tied to large, volatile back end data stores. But by Q3 2007, the team was using automated acceptance tests on it’s web applications.

The most drastic improvement however was in the customer role. Scrum defines the responsibilities of the product owner. In our case, that role was divided into two individuals.

The product owner, is an empowered single authority for prioritizing business value at the feature level. They are usually are executive level and work in the business unit “funding” the work. They also have working knowledge of the system to be built. Product owners participate in planning and review, and are available for ad hoc questions within iterations.

The product owner proxy is a member of the development staff who acts as onsite proxy for the product owner. This person assists in authoring user stories and maintaining a product backlog, meets regularly with the product owner, and acts in their place to broker decisions within the development team during iterations.

By Q2 2007, the team had product owner proxies for both our IT and our consumer facing work. Product owners included the VP of Broadcast Operations, VP of Ad Sales Traffic, our CTO, and our CEO.

Sprint Burndown by kjudyThroughout 2006-2007 our team performed exceptionally well, balancing two simultaneous lines of work and maintenance in both .NET and Ruby on Rails with four to six developers. Our projects delivered on client satisfaction, originality and early monetary goals.

Team members raised their skills and began contributing to our field. They were writing, presenting and speaking at conferences on topics of scrum, XP and platform as well as contributing to open source projects and developer knowledge bases. We were drawing positive attention from our peer community and within our company.

Our consumer product, Ript™, was recognized for its elegance in design and implementation by members of Microsoft’s platform and developer evangelist team as well as by members of the WPF team. It also achieved high ratings in usability testing with end users (avg rating 8 of 10) and showed potential to deliver on its revenue targets.

Video thumbnail. Click to play.
Ript Promo – Click to play.

At the end of 2007 our company was acquired by a much larger television company. Software we wrote for internal use is considered valuable enough by the acquirer that they are hoping to transition into their much larger operations.

More Remoting At Oxygen

Posted on by

Remoting At Oxygen made with Ript

These are candid shots from this week’s Sprint review (full size image).

One of our team, Wendy, often works from home. We use webcams, skype, community document formats and remote access. She even has her own build bunny.

As you can see, we’ve developed the habit of giving Wendy a view of the action however absurd or precarious it looks.

Remoting does limit beneficial cross-talk among the pairs (osmotic communication) but word within the team is that pairing goes well. After some practice, we’re also getting the hang of the structured group conversations such as standup, sprint review and planning.

We have a strong, established bond with Wendy and the team is really pulling to make it work. She also comes into the office at least once a week which keeps us close. All and all, it’s about the easiest remote worker scenario I can think of.

The biggest downside is simply that we miss her.

Retrospectives and the Hair Shirt

Posted on by

Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things that it makes transparent and adapting to optimize the results and the organization that produces the results. — Ken Schwaber Scrum and NonScrum

My team embraces retrospectives. Every two weeks we list what we’ve done well and what we didn’t. We choose one or two things to do differently in the next Sprint. We revisit those commitments over time to see what progress we’ve made.

My team exists in a larger company.

In Waltzing With Bears, the one irrefutable reason to not do risk management is when no one else is doing it. If you are the only one presenting costs and possible negative outcomes management will assume your projects are troubled and you are a negative thinker. They’ll fund proposals that by comparison look cheap, safe and promise outstanding success.

I don’t exist in that extreme situation. But my team’s willingness to acknowledge mistakes is sometimes taken for negativity. Our willingness to admit the possibility of failure sometimes provides support to skeptics. Our willingness to question assumptions is sometimes seen as stone throwing.

Leading Change

In order to build something new we straddle two realms. In one we cultivate our aspirations and in the other we struggle to attain them.

At times we need to set aside our skepticism to see the world as it should be and people as we hope they are. Other times, we need to see how far we are from where we aspire to be, dig our feet into the soft earth and push.

Jeff Sutherland has a simple exercise for spurring organizational change

  • Setting aside all the obstacles in your path, picture one thing you would like to change. Write down what it looks like.
  • Now, go back to where you are. Look at that outcome. List things you can do in the short term that get you closer to it.
  • Which of the items on that list are achievable and most effective. Put those at the top of the list.
  • Identify what you can do in the next week to to achieve the items at the top of the list.
  • Assign each of those items to someone in the room with you.

You’ve just planned a Scrum.

The Hair Shirt

There is a difference between justifying one’s mistakes and reflecting on past performance in order to improve. There is also a difference between acknowledging one’s fallibility and dwelling on it.

We developers are crafts people not monks. Our job is not righteous contemplation — it is thoughtful and rightful action.

So as reflective developers, we do not wear a hair shirt. Our goal is not to dwell on our own or other’s failings.

We are idealists.

We embrace grand visions, ambiguity, contradiction and change. We believe good people deliver the best results in environments of trust and honesty.

.. And we are pragmatists.

We believe believing doesn’t in itself make it so: success requires discipline, determination, and ingenious problem solving.

And as we embrace both the outcome to which we aspire and the given circumstances that surround us we will acknowledge mistakes. We will shine a bright light on obstacles in our path. With humility and tenacity we will challenge ourselves, our teams, and our companies to do better.

Product Owner Change – Stop the Line!

Posted on by

What do you do when the fundamental assumptions behind a software project change mid-stream?

My experience before adopting agile practices was people often plugged away at the original plan drifting farther and farther off course.

I’ve been on projects that failed simply because no one had an honest conversation about who had authority to drive changes. How many of us have built something only to have the launch postponed because a senior executive got their first look and over-ruled their under-powered product manager? How many of us have had a project declared failure as a result? How many have seen work shelved? Me. Me. Me.

I’ve found Scrum does a great job of surfacing these issues and forcing the team to deal with them. Product owner is being over-ruled? Sprint integrity not being honored because interruptions and changes? Believe me, a performing scrum team will raise the alarm as quickly as this occurs and force a conversation about who is the product owner and what are the criteria for success.

One possible result? “Stop the line” interrupting the current sprint. Meet with the relevant managers and make the person setting feature priorities accountable for the backlog and the business outcome of the project. Plan a new sprint and re-commence work. The cost of mid-sprint changes is made explicit and responsibility is aligned with authority.

This can benefit everyone. First, the hidden product owner now has the regular feedback and control that reduces the urge for mid-sprint intervention. Second, the team knows who to rally around and why. Third, difficult conversations about what is driving changes and what defines success for the project happen earlier rather than later.

I’m not saying that these changes ensure success. Honestly, a project with mushy business ownership and vision is troubled. What I am saying is that with frequent inspections and a culture of honesty these seeds of failure become very clear to everyone much earlier.

I’ve found that once a team becomes used to satisfying the customer with early and continuous delivery of valuable software. They fight like hell rather than get caught in a familiar pattern of failure.