|
Scott W. Ambler
Senior Consultant |
Scott W. Ambler is a Senior Consultant with Cutter Consortium's Enterprise Architecture and Agile Software Development & Project Management Practices and a contributor to these Advisory Services. He is the thought leader behind Agile Model Driven Development (AMDD), the Agile Data (AD) method, and the Enterprise Unified Process (EUP).
Mr. Ambler is coauthor of several software-development books, including Agile Modeling, The Elements of UML 2.0 Style, Agile Database Techniques, and The Enterprise Unified Process. He is also a contributing editor with Software Development magazine and author of their monthly Agile Edge column. Mr. Ambler has spoken at a wide variety of international conferences including XP200n, Software Development, UML World, Object Expo, Java Expo, and Application Development, and he works with clients around the world to improve the way they develop software. He can be reached at consulting@cutter.com.
For more by Scott Ambler, visit the Cutter Consortium Bookstore:
The Current and Future States of Agile Processes
An interview with Scott W. Ambler, Senior Consultant, Cutter Consortium
We recently spoke with Scott W. Ambler, Senior Consultant with Cutter Consortium's Enterprise Architecture and Agile Project Management Practices. In this Executive Update, Scott addresses the current state of agile development processes and touches on a couple of points from his recent Agile Project Management Executive Report " Evolutionary Database Development: Skills for Agile DBAs" (Vol. 4, No. 9).
Q: How do you view the current state of agile processes in corporate IT?
SA: From what I can tell, most organizations are at least thinking about agile techniques, if not trying them. Many organizations are finding that agile works very well in practice. Apparently, the proof is in the pudding.
One problem that I do see is that people aren't as fully up to speed on agile processes as they should be and, as a result, may address only development issues when they really need to consider more. I think that many organizations are still looking for a single "one-stop shop" solution. What they are better advised to do is to blend several methods together to meet their own unique needs. For example, many people are adopting Extreme Programming [XP] for their development process. They're then enhancing XP's project management aspects with Scrum. Some of the smarter ones extend development methods such as XP or Feature-Driven Development [FDD] with agile modeling [AM] to address effective modeling and documentation practices; they also may use agile database techniques to address how data professionals can be effective on agile projects.
Q: When the economic rebound comes, will agile become increasingly important? Why or why not?
SA: Agile is important now and will become more so. As the economy rebounds, organizations will begin doing the IT projects they've been putting off. The smart ones will try agile approaches, the not-so-smart ones will continue on as before. My prediction is that [in North America] we'll see the non-agile shops get picked off by the offshore outsourcers over the next decade or so as [the non-agile shops] will be the "low-hanging fruit."
Q: What kind of corporate cultures can most easily adapt to agile processes?
SA: Those in which the people respect each other, are willing to learn, and work well together. If you have a rigid command-and-control structure, then you're probably going to have problems adopting agile approaches.
Q: In your recent Executive Report "Evolutionary Database Development: Skills for Agile DBAs," you addressed the issue of data professionals being part of the agile movement? Why is that important?
SA: Data is clearly an important aspect of any business application, although it is only one of many important aspects. Data professionals have significant value to add to an IT project, but only if they can work with that team effectively. Because agile developers work in an evolutionary manner, data professionals also need to work that way, otherwise it simply isn't going to work. As the report shows, techniques exist to do exactly this, but the data community needs to choose to adopt them.
Q: How do data professionals, in general, operate today?
SA: There's a wide range of approaches. Many data professionals choose to work in a collaborative manner with developers; these are the type of people that will do well with agile techniques. At the other end of the spectrum, there are many data professionals who want to work in a command-and-control environment, who want to work in a serial manner, who want to review everything the developers do. These people are going to have a really tough time in the future and likely are having a hard time right now working effectively with developers.
A clear sign that your data group is in trouble is when it insists either on reviewing data models before development starts or on developing the data models themselves in isolation from the developers. This clearly isn't agile because the data group is not working closely with the development team. When you work closely with each other, you're more effective, you do a better job, and you do it faster. You also learn valuable skills from one another. Handoffs between groups are often an indication of dysfunctional politics within your organization, not of effectiveness.
Another symptom is when development teams choose to go around the data group. If the data group feels something along the lines of, "If only everyone would do what we tell them, things would be okay," then you know this group is not working well with others. If the development teams are going around the data groups, then either the developers don't understand the value that the data folks can add or the data folks aren't able to respond quickly to the needs of developers. I've been in several organizations where the data group complains about development teams that go rogue, only to find out that the data group takes weeks or months to get even the simplest of things done. So naturally the developers go around them. It doesn't have to be this way; you can choose to work together effectively.
Q: In the report, you seem to give a slap to the Rational Unified Process [RUP], implying that it doesn't work in collaborative environments. But can RUP thrive in certain places? And if so, where?
SA: What I was trying to say was that RUP is often adopted by people who want to take a command-and-control approach. It doesn't have to be this way; RUP can be implemented in a reasonably agile fashion if you choose to, but it doesn't happen as often as it should. Like it or not, RUP speaks to the managers and the bureaucrats, whereas agile techniques such as XP and agile database techniques speak to developers. At the agile modeling Web site [www.agilemodeling.com], I've written a fair bit about how to streamline modeling and documentation efforts in RUP. Similarly, at www.agiledata.org, I've written about how to streamline your data efforts following RUP. You can be quite effective with RUP if you choose to be; unfortunately many organizations seem to choose otherwise.
Q: What are the biggest impediments to effective execution of agile development techniques and strategies?
SA: People outside of the agile team who are unwilling to change. A development team can't be agile if it's hobbled by a data group that insists on getting the data models done up front or that is unwilling to supply an agile DBA [database administrator] to the team. Similarly, the project managers in your organization must be willing to work in an agile manner. You should be taking a serious look at Scrum right now and move away from things such as the Project Management Institute [PMI] certification efforts.
In the end, you need to choose to succeed. You need to choose to focus on developing software, and you need to focus on doing so in an effective manner. Many organizations simply aren't set up to work this way, and it's going to take a long time to change things.
-- Cutter Consortium
Scott W. Ambler