One of the core principles of Agile is this: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”  The ability to respond nimbly to new information is a hallmark of Agile (in my opinion) and part of what makes it such a good approach to use when developing complex products like financial software.  Working in short sprints the way we do, meeting daily to discuss progress and roadblocks, and carving out time in the current sprint to talk about known and emerging issues to tackle n future sprints all contribute to making our team ready to face changes when we encounter them.  Responsiveness to change in the middle of a development cycle is a big part of what distinguishes Agile from more traditional waterfall approaches to software development.

At least in theory that all sounds good.  But when you crash into a need to change direction the way we did this week things are no longer as simple as they sounded in principle.  I mentioned this issue in yesterday’s post and want to write about it both for today and tomorrow.  Today let me focus on the problem.

As we are building out features for part of our risk management software, we have tried to break these feature sets into smaller chunks and prioritize which parts to work on when as we roll out new pieces of working software to our clients on a regular basis.  One key feature set is being developed by a sub-group of our larger scrum team and they have been involved in various stages of this development for months.  They started with some user personas and user stories – who will use this feature and what problem will that person be trying to solve – gathered from interactions with people who will actually use this once it is available; they involved our designer in creating wireframes that match the workflow; they broke the larger project into smaller tasks that could each be completed in a single sprint; and they have been making good progress on the actual coding and testing.

Until recently, when this part of the team hit a major roadblock.  Their entire approach to solving the problem had a fundamental flaw.  And that sub-team and I are now asking, what went wrong?  As we’ve talked this through, it seems at least three things tripped us up:

1. We missed two key user personas that will need this feature.  The approach we took in our development would work great for one of the central personas who want this feature, but we failed to take into account the overlapping and divergent needs of two other types of people who will interact with this part of our software.  And it turns out that what works for one group causes some major headaches for these two other groups.  As we started the actual development of this feature we realized that some important users would lose key functionality that they need.
2. We did not articulate the user story as well as we thought we did.  Even for the one user persona whose needs directed our approach to this feature, it became clear that our user story did not grasp some key nuances of what this type of user will need to do.  Of course we knew we had not articulated every permutation of what a user would do with this feature; in an Agile approach (as I understand it anyway) we never expect to document solutions to all possible problems before beginning the development work.  But as the team worked on building out aspects of this feature they continued to encounter development decisions where they lacked clearly articulated direction.  This uncertainty is a big part of what unearthed the larger problem for us this week as we faced it head on.
3. The team that did the conceptual planning for this feature was not the same as the team actually building it.  The design team and the development team certainly overlapped, but there was enough disconnect between those of us on the sprint team who mapped the feature conceptually and those who would be actually building it that words and ideas were interpreted differently by each group.  Was our plan to merge two existing features into a new and more intuitive approach as some of us thought or were we eliminating one feature and planning to find a way to make the other feature do double duty as the coders thought?  We work closely enough together that we were able to identify the disconnect this week and start focusing on the solution; but the fact that there was less overlap among the different parts of our team contributed to the problem we crashed into this week.

None of this is rocket surgery (or is that brain science), but still we got tripped up by it.  We are definitely still learning how to apply the Agile principles as we work together.  It’s great to have the tools to respond to this discovery of a problem in the middle of our development cycle (more on our attempts at a solution tomorrow).  You could even argue that this is an example of how Agile helped things go right instead of wrong, since we found the problem before this feature got released for clients to use and we are now making the necessary changes to address the issue.  Sure the ability to change is a welcome part of Agile, but in truth it’s not that simple.