How We Finally Made Agile Development Work

October 14, 2012 Editor 0

Many software products benefit from a continuous improvement model, and for the teams working on them, increased agility is inevitable. Yet, despite dozens of books on the subject, thousands of eager coaches, and a multitude of software vendors hawking products to make agile development “easier”, many companies struggle to get to a point of true agility (i.e., being agile instead of “doing agile”).

There are many causes for failed adoption of agile development, but the one that seems to be least often addressed is how people who are comfortable in a waterfall world adapt to this new way of working. For those in some roles — software engineers, for example — the core activity doesn’t change: they continue to write the code. For others, the path is not so clear.

In my last post, the comment thread was filled with project managers and systems and business analysts challenging the validity of increased team agility. What became clear from those conversations is that people in those roles tend to struggle to find comfortable footing in an agile environment. This resistance, born of hesitation towards the unknown and a heightened concern for job security, often creates team dynamics that inhibit true cross-functional agility.

This trepidation also holds true for software designers. As a designer who has not only gone through agile transitions as an individual contributor but also led teams through them, I’d like to share how the design field has adapted to agile, in the process proving our original concerns to be false and creating a new approach to doing our jobs.

The waterfall process provided designers with an insulated period of time to do our work. The “design phase” — regardless of how long or short it was — gave us the opportunity to generate ideas, tear them down, and then build up new ones until we came up with what we felt was the best design for the product or feature being developed.

Non-designers didn’t participate in the process, and that was fine with us. How would they contribute anyway? We were the “designers.” The agile process forced us out of the safety of the design phase and into a furiously fast new reality in which product managers, software engineers, and QA specialists were far more involved in the work we created. The demands of two-week sprints forced us to cut up our “big ideas” into lots of little pieces that could be fed to the “dev machine” to ensure that, God forbid, no developers sat idle.

We panicked. “This is not design!” we cried. Our best work wasn’t being developed and because of that, we felt significantly less valuable to the business. Every design that actually got implemented felt like bronze medal work. There was no place for “good” design in an agile environment, we concluded.

But then a light went off.

Instead of adapting our process to fit in this new reality, we had tried to cram our old processes into these new constraints. They didn’t fit. And that was the root cause of our problem. We had to rethink the way we did software design. Our expertise, talent, techniques, and tools were still very much necessary, but how they were executed, who was involved with them, and their timing all required change.

The value designers brought to the creation process was now distributed to other roles on the team. This was a tough pill to swallow initially. As our teams matured we realized that software design was evolving beyond simply laying out the pixels. Design facilitation was now a much bigger part of our process, as was a broader understanding of all the other elements — performance, pricing strategies, content, etc. — that encompassed user experience.

If you’re struggling to figure out where you fit in an agile world, I urge to take a look at your current process and see how you can reconfigure the value you bring to meet the demands of nimble teams. In addition, look beyond your role and into your competencies. What else can you bring to your team beyond what your job title dictates? The attributes you find in doing these exercises will ease your transition and help you find your new, more agile footing.

Go to Source

Categories: HBR, Insights, Technology

Tags: agile, designer, team