Interview with Rebecca Wirfs-Brock

Rebecca Wirfs-Brock and the Agile Journey

From her home looking out over the lush Oregon landscape, Rebecca Wirfs-Brock spoke with Francesco about her work. Author, lecturer and consultant, Wirfs-Brock is a well-known and respected object practitioner. She is president of Wirfs-Brock Associates and IEEE Software’s Design Columnist.

FRANCESCO: What is one of the most important things you’ve learned in your career?

REBECCA: I would say the importance of team-work. When I was a young engineer I would put all my enthusiasm into one project after another and only later came to understand how much extra energy, creativity and productivity comes from having a special team relationship, that team synergy. It took me maybe ten years to figure that out! But then I made a conscious choice to do things with that, and started working in the small-tech world and with trusted associates.

FRANCESCO: How do you recognise an Agile Team?

REBECCA: A team that takes responsibility for the way they do work rather than place blame on someone else; a team that recognises that their professional productivity together is what’s really important.

FRANCESCO: Can any team become Agile?

REBECCA: I teach design courses, and you know when you form a small group whether they’ll become a team or whether they’ll be argumentative personalities that are clashing. There can be people who are bright, who have good design ideas and want to share them, but don’t know how to do it in a way that’s not confrontational. There are lot of intangible qualities to agile teams too.

It’s an attitude…there’s this aspect of having an open mind, of trying to learn something whatever you do. But probably what it comes down to is that agile work means collective ownership.

FRANCESCO: What advice would you give to teams who want to become Agile?

REBECCA: I don’t recommend jumping in with both feet first: it depends on the kind of team and at what point they are along their journey. If it’s a small team, they need to understand something about the practices that allow them to iteratively develop and make sure they know how to do those things as a team, as a group.

For a large organisation, start with one thing the team wants to try and understand, rather than doing it all at once. I know a company that was involved in developing software in a large, complex environment, and the team understood they couldn’t just stop everything they were doing to become agile. They were able to pick a practice that would have the most leveraged impact.

FRANCESCO: Is there any particular order that teams should follow in adopting agile practices?

REBECCA: Getting your build environment in place is probably a fundamental aspect. But I’ve been reviewing experience reports for the agile conference for the past five or six years and I’ve seen a lot of ways that people get to agile. Many feel guilty because they don’t adopt agile principles in their entirety but that isn’t what is really important. If a team doesn’t take the twelve practices of XP all at once, that’s OK, because they are working differently than they were a year ago or two years ago.

It’s not always the same path. It’s a journey, not just an end point. A journey of improvement, self-reflection and meeting your goals and not being satisfied with the easy way out.

FRANCESCO: What positive things do you see in the future for Agile?

REBECCA: I have an optimistic outlook about a second generation pushing the boundaries of what can be done in an agile development environment. It’s gone from easier applications in small teams to figuring out innovative ways to get scale and agility in multi-disciplinary teams, distributed teams, with massive amounts of software.

Other positive aspects of future developments are understanding the different rhythms of work and lean processes: I think in the future there’s going to become some sort of pattern of practice to apply, given the kind of work that you have.

What I also see is that people who have been in user experience have gotten involved in the agile movement. User experience design is something I’m very keen on, and they’re introducing those kinds of practices in the agile way. That means not having to do usability research before feeding it into a product, but doing in a way that’s more agile and incremental, from low-fidelity to wizard in the machine. Some of these techniques should be part of the skill set that developers should have, too. The result would be more usable software.

FRANCESCO: What negative aspects or risks do you see for the future?

REBECCA: One possible negative is that agile has become such a smorgasbord, so diluted that it becomes difficult to define. People pick and choose the practices to adopt and then abandon agile when they don’t get the results that were promised and move on to the next silver bullet.

But I don’t think it’s necessarily a good idea to try to define the fuzziness of agile through testing and certification. I’m skeptical that anything that is not experience based, such as testing for a certified agile person – has very little meaning. Eventually it might lead some people to pay money to get certified, but down the line, it has no effect. Another danger I see is trying to bring Agile to contexts where it won’t work, a set up for failure. This drags everything else down. Some people say that agile can be done everywhere. But I’ve seen places where the way that you develop software and the things that you have to do and steps that you have to go through are pretty tightly established already. Maybe some things can be done in a more agile way in order to fit within those processes, but it’s going to be a lot of work mesh. Change across companies and clients and suppliers can be very difficult.

And different cultures, whether it’s the company culture or the national culture, have to be taken into consideration. When I was in Japan, the people who invited me told me how difficult it was for them to adopt agile practices that engaged the client in an incremental way – companies didn’t want to hear about problems, they wanted you to manage them on your own and deliver software when it’s done!

FRANCESCO: Do you have a worst-case scenario?

REBECCA: The worst thing that could happen is that the agile community doesn’t embrace new practices, or new needs, or new software, or ways of doing software. A lot of the attention or the intellectual marketplace for Agile has been on team practices, management of incremental scrum practices. It’s all too easy to forget that it’s not just a set of development practices, or programming skills, or technical build things, it’s a bunch of ways about figuring things out. If a good team is unable to design good complex software it’s a failure, and the team may say “agile didn’t help me here.”

Some companies have told me: “I created code, I developed it, I have mountains of tests. I have so many mountains of tests that I cannot change the way that my code is factored”. Software needs to be, as Richard Gabriel has called it, “habitable”. But it isn’t just the code that’s habitable, it’s the tests and code together, you need to manage those as an asset that helps you make the code able to be living and growing. If tests are preventing you from growing the code base, there’s something seriously wrong with what you’re doing. It’s alarming, because one of the things that’s been really good about agile practices is how much it has raised awareness of the value of having test-driven code. But if it becomes a use that strangles the ability of the software to grow, that is a problem. Tests need to be designed too. A kind of “rigid agile tested legacy code” becomes the greatest risk.

FRANCESCO: How can these negative scenarios be turned around? What is the next step?

REBECCA: We need to recognise what our values are, underlying our practices. To focus on the ability for software to grow and adapt in a constant stream, with an intelligent planning of that stream so I don’t just expect anything to just turn out in the same way.

We have to acknowledge that there are different rhythms, the goal isn’t always the 2-week increment, it’s more nuanced. Sometimes you have to take things off a track to figure it out. I think that the next generation of agile won’t be all masters… you can be a practitioner along your journey. We don’t have patterns for Agile yet. The next step is to figure out these patterns.