Back and More Agile Than Before
Saturday, March 13, 2010 6:04PM PST — Permalink
So I've been away for awhile, and haven't posted much, but it's not that I haven't wanted to. What's kept me away you ask? Well, I had the pleasure/pain of working with a development team at HP as they changed how they build software. This didn't mean that they changed their coding tools or compilers. Rather, they attempted to change the process by which they went from getting requirements from product management to building something they could ship out on a DVD. The old process we used is a very traditional one called Waterfall, because each step would flow from the previous until you got to the bottom or end of the cycle. The new process we adopted is called Agile, and it's... well... different than Waterfall.
So the first question I had to ask was what the benefit of this or any change would be to the team. The answers I received were the variety cure-alls that I expected (better software, faster software, world peace, etc.), but the most promising and achievable goal was that it would expose weaknesses in the scope and schedule at a much earlier stage than we'd had previously had, and at a point where we could still make changes to fix it. We'd had many releases where we'd found out 6-8 weeks prior to release that some things weren't going to 'make it', and that's definitely not a situation anyone enjoyed.
Now that I knew why we were changing, I set about finding out what we were changing to. Agile isn't anything especially new. It's main tenant is that you can't know the future, so rather than try to make long term plans, it's better to do more small iterations, where there's more opportunity to react to external changes. I'd worked with teams back at Sun on projects that used 'Extreme Programming', so this wasn't a radical thought, but Agile seems to have some much more formalized processes, including the creation of User Stories in a backlog, and addressing user stories fully within the bounds of a Sprint cycle. (4 weeks in our case)
In general, I'm a fan of any process that makes engineers think more about how a customer will use a product rather than the technology with which it's implemented. Where I didn't like Agile (or at least our implementation of Agile) is that it throws out years of study and best practices around good user interaction design, and it presupposes things that make a UI designers life very hard.
- All activity for a set of user stories are suppose to occur within the confines of a single sprint. This means sorting out what the requirements really mean, designing an implementation, enacting that implementation, and testing the implementation for quality. So even in our elongated 4 week sprints (some teams use 1 or 2 week sprints) we at most had 3-4 days to design all the features. That meant almost no time for research or any customer validation of early prototypes.
- Apart from the reduced time for design, the short sprint terms also created another issue. By artificially limiting development to such a short amount of time, engineers were almost given an incentive to hack things together quickly rather than spend time to do things right. If the right way to fix a problem was to spend 6 weeks re-writing a component of the system, it would never happen because that doesn't fit into a sprint.
- One of the other features of Agile is that each team is lead by a Functional Architect. This is the person that knows the customer, knows the product, and understands the market and how best to influence the product to meet market needs. This is also the person that creates the user stories and prioritizes them into a backlog. Sounds good on the surface, but the problem is that functional architects are almost always pulled from the engineering team since no one else can attest to knowing the product well enough. The result is that the items in the backlog tend be overly steeped in implementation details and more often than not prioritized based on functionality rather than usability. Have a feature that functions, but most people can't use it? Don't expect that item to come out of the backlog anytime soon.
There are other aspects that made Agile less-than-optimal for my design team, but these ones are the things that stood out most, and they're also all things that I think can be addressed to make Agile more UX-friendly. Here are my suggestions:
- The functional architect, the product manager, and the UI designer should always be working on the next sprint. This gives them all time to thoroughly work through the research and design phases of the development process, as well as time to do simple prototyping and validate the interactions with customers and other stakeholders.
- The second change is a mental one, which is that it needs to be acceptable to exit a sprint without completing a user story, if the time was spent laying ground-work and refactoring code in preparation for a bigger fix.
- The last suggestion is likely the most contentious, but in the end I think it has the most potential to make things better. Every scrum team should have two architects - a feature architect and a usability architect. Or another way to look at it is there's one architect looking toward the future and scalability while there's a second grounded in the present with sustainability in mind. It's each of their jobs to come to an agreement on the priority of backlog items to make the product better.
I think the concept and intentions of the Agile method are good, and it's likely that it becomes problematic for teams like mine only when it's taken as a set-in-stone process as opposed to a philosophy that can be applied, reviewed, and revised as necessary. Developing software should be just like making software. Don't be afraid to make changes, but only make them if you end up with something appreciably better. Change for the sake of change is only churn, and that's not good business... unless you make butter.
