Rusty Divine

Live, Love, Learn, Teach

Some times we’ve failed with Agile

Tomorrow there’s a lunch gathering for our local Agile community and the topic is failure led by Keil Wilson, an agile project manager who works with me at NDOR.

At this Luncheon, we'll focus on the value of failing fast and forward.  Bring a simple--or the most heinous--failure you've encountered in your Agile Transformation.  We'll then focus on how it was discovered and the good that came out of it.  We'll also rely on the collective wisdom of our Community to offer other suggestions.

We often talk about failure being an option on our software development team. For example, we did not burn down last iteration when two of our user stories didn’t get completed in time. At our retrospective we brought this up to talk about it. One of our customers was there and she didn’t care that we didn’t burn down, in fact, just the opposite – she thought we were too focused on it when it wasn’t a problem. We talked about value and commitment but in the end agreed that if we fail to burn down occasionally it is actually a sign that we are pushing ourselves appropriately. If we always burned down it would seem a little suspicious that maybe we were slacking off some, and if we never burned down it would be a loss-of-trust issue where the expectation would begin to be set that the burn down is irrelevant. In our case, we burn down 80% of the time or more I’d estimate, and our team is comfortable with that amount of failure.

For the luncheon tomorrow though I’ve thought of a few examples of when I’ve been part of  projects and teams that have failed with Agile in the past:

  1. One customer brought us a requirements document they had created and put out to bid. We won that project and actually did a great job delivering on the project using Agile to guide us. The failures we had were poor definitions of conditions of acceptance from that document they wrote, missing assumptions and constraints, and a fixed budget that didn’t allow room for pivoting when they needed to left the customer with a solution they weren’t satisfied with in the end. Later, they paid another company to rewrite it, and that company is still working on it today, but at least they are charging time & materials.
  2. Another customer was a startup and we pre-billed them each month with a definition of what we were going to complete that month – we worried their funds might dry up. We were able to get done what they needed, but in the later stages of the project their project sponsor (the money-person) realized how much the project had cost, and their product owner (his brother) got convenient amnesia and pushed the blame on us. Our failure there was not making sure the product sponsor was involved more in the project as it was being completed and it ruined a relationship with that customer that could have been prevented with better project management.
  3. Some of my early experiences with Scrum and Agile took a light-approach. I now realize we could have done much better by occasionally reflecting on how we could be doing better instead of making the same mistakes over and over.
  4. On the project I currently work we still have some things we could be doing better. For instance, our customer does not get very involved with prioritizing the backlog, and when they do it seems like they aren’t thinking as strategically as would be good for the project in the long run. The result is we end up focusing on enhancements to existing features – moving fields around, swapping columns, changing shading, etc. – instead of taking on the new initiatives that need to be completed during this phase of the project. The silver lining is that our project manager specifically set a budget in this phase’s project charter for enhancements, and as of this iteration they only have a few points left to spend before they need to make an official request for more. Even though we put this safeguard in place, it didn’t prevent them from spending their entire enhancement budget first, including reversing some of the work they asked for, before working on anything new.

I’m looking forward to tomorrow’s meeting to see what the rest of the group has to say about their experiences. One things for sure, the restaurant we are meeting at has never failed to sever up some great burgers!

We Scrubbed our QA/Prod Move

It was quarter-after eleven Friday morning and I noticed my teammate’s brow was furrowed. It was her turn this iteration to coordinate the move to QA and Production, which involved enough steps that we have created several process documents and an iteration calendar to help keep the move on track.

The seven of us were in the basement for our weekly team technical training meeting – two hours set aside to explore new technologies and discuss how to improve our code base. It’s a time we look forward to each week as a fun way to start a Friday and a time to talk openly about our ideas and interests.

Two of the team were discussing or debating something while the rest of us worked through a tutorial on SignalR on our Azure VMs.

I asked the developer in charge of the QA move how it was going and she told me there was a problem.

“Could you open the QA website and check the obligation transaction page? We are getting a work phase not found error,” she said.

I checked and found the same error. It was strange and took a minute to process what could be going on to cause this error message. Neither our developers nor our very thorough QA tester had encountered this in our development branch during the iteration.

After a few minutes of conferencing about it, we realized one of the stories we sent to QA was failing because the table it was expecting to update did not have any data loaded yet, and would not until we turned on this multiple-iteration release in production, converted the data, and took over the functionality we were replacing in the main frame system.

Our application is complicated by having some parts that are used in production, and some parts that are technically in production but are turned off and hidden until we can complete the entire set of features and turn them off in the current main frame system. This particular feature bridged both worlds, which is why it caused a problem when we got to QA – in demo, we have data loaded from production, but QA matches production exactly and does not have that data loaded.

What to do. We could scrub moving to QA and Prod this iteration, roll back the problem feature, and do a normal QA/Prod move next iteration. We could populate the empty tables with production data so that our cross-over feature would work, but the data would become stale as soon as someone used the main frame system, so that was out. We decided our best option was to scrub the move because there was only one minor feature that would have been visible in production.

The QA mover and I went upstairs to talk to the product owner. We explained the situation and she agreed, the minor feature wasn’t important enough to do an emergency fix for and we should just scrub the move.

To me, this issue and how our process handled it so smoothly was awesome. Sometimes its easy to overlook something like this that appears trivial – it was no more than 20 minutes between the time we realized the issue to when we decided to scrub the move. We didn’t need to debate or discuss, it was clear from our process what we should do – and that included both developers and the product owner.

Days like this make me so happy to be working with an agile team!