I wrote yesterday about the problem we crashed into this sprint when we discovered that designs for one major feature we were building had failed to consider two important user personas, had worked off of an inadequately articulated user story, and had been conceptualized by one team while being built by a slightly different one.  Agile is great at helping us pivot when we need to mid-sprint; the methodology also provides helpful guidelines on how to avoid the very problems we tripped over.  As I mentioned at the end of yesterday’s post, there is an important way in which our Agile process went ‘right’ instead of ‘wrong’ because it allowed us to catch and focus on this issue before it got out for our clients to find.  So what are we doing now to address this problem?

One thing we aren’t doing is continuing to build this feature along the path the team already started down.  Maybe that sounds obvious, but too often in waterfall software approaches, the development team simply builds what the business requirements document tells them to build (at least according to their own understanding of the requirements) even if they think that plan is flawed.  ‘I just built what you told me to build’ is a common response at the end of a traditional software project when the business user complains that the software feature isn’t ‘what I wanted.’  Fortunately that is not what we do with an Agile approach.  If we realize that something isn’t heading down the right path then we shift direction.

Instead of developing toward what we now realize was a flawed product conception, we are doing three things:

1. We’ve pulled together the key stakeholders so that we can revisit our user personas and user stories around this feature.  I spent several hours over the past few days talking with subject matter experts, product owners from adjacent products, software architects, and our lead coder for this feature so that we can wrap our minds around the right approach to this more complex problem.  Together we’ve gone back to the key user personas that we missed last time to get more clarity around what they will need.  And I’ve talked to the product manager about the roadblock we’ve run into so that he can adjust the expectations of the sales and marketing team and the ultimate client users of this feature around both when it will be available and how this will impact timing on the next feature set we develop.
2. We’ve focused on both the desired user experience and the underlying technical realities for this feature.  Developing something that works across all three key user personas will present more complexity than we originally anticipated, and we need to figure out how to accomplish our goals (both functionality and user experience) within the constraints of our technical resources.  This is easier to do when we follow the Agile principle that, “Business people and developers must work together daily throughout the project.”  Making sure all perspectives are considered is much more feasible when we are already in the Agile habit of working closely together throughout our sprints.
3. We’ve tasked the team to work on other things from our prioritized backlog while we sort this out.  While several key folks on our team have been heavily focused for the past few days on reworking our proposed solution for this feature, we have been able to task other members of the team with working on some prioritized issues already on our sprint backlog.  Encountering an issue in one of our ‘swim lanes’ didn’t mean that all development ground to a halt; our team knows what the next set of important things is to work on and so development of identified high priority features can continue even while we work on clarifying how to approach the feature set that tripped us up.

This has all disrupted part of our sprint, but it also gives us the chance to improve the way we work together.  Using the same Agile principles that helped us catch this issue in mid-development, we have worked both to refine our conceptualization of this problem and to fix other important items that we planned to get to soon.  Even when things go wrong in Agile the methodology helps steer things in the right direction.  It has been a crazy couple of days working through this, but for me it helps confirm why we use an Agile approach in our software development.  And I think the feature we are building will be more effective than the one we first started on.  Of course, in truth it’s not that simple.