Scott W. Ambler is the Practice Leader, Agile Development at IBM Corporation. Scott works in the IBM Methods group developing process materials and travels the world helping clients understand and adopt the software processes which are right for them. Scott is an award-winning author of several books, including books focused on the Unified Process, agile software development, the Unified Modeling language, and CMM-based development. Scott is a regular speaker at international IT conferences and is a contributing editor with Dr. Dobb’s Journal. Prior to working for IBM, Scott led the development of several software processes, including Agile Modeling (AM), Agile Data (AD), Enterprise Unified Process (EUP), and Agile Unified Process (AUP) methodologies. Scott holds a BSC in Computer Science and a Master of Information Science from the University of Toronto.

In this interview, Scott answers questions about Enterprise Unified Process, Technical Issues in Agile projects and also advises on linkages between “people management” and “technical excellence”.

agilecollab : How did your interest in research into Modeling and interest in Agile/ Lean/ Lightweight methods converge?

Scott : It was my experiences in software development. I saw that the heavier approaches to modeling really weren’t doing much other than employing modelers, yet I still believed in modeling. So I started observing what was working well and what wasn’t, and started writing about it. One thing led to another and the Agile Modeling methodology, www.agilemodeling.com, emerged. It’s important to point out that I’m only the method leader, and that several hundred other people also actively participated in its creation.

agilecollab : Do you think “modeling” and “analysis” disciplines are under threat or reinvention from Agile [or even “a”gile] movement? What are going to be some of the important differences in the way we architect scalable and usable applications?

Scott : It depends on your point of view. The hard-core, traditional modelers definitely seem to be threatened, likely because the approach is so different than what they’ve been taught to do. The traditional approach is to create comprehensive models and documentation, the assumptions being that you need to think everything through first and that the development team will actually follow the detailed strategy. Sounds great in theory but in practice this proves to be very risky. See http://www.agilemodeling.com/essays/proof.htm for some thoughts and more importantly links to supporting research. The agile approach is to focus on collaboration, to model and document just enough as the situation warrants, and to be prepared to change when your stakeholders change their minds (and they always do). This is much more realistic but requires greater skill and discipline on the part of the IT professionals. You should still do some initial requirements and architecture envisioning, see http://www.agilemodeling.com/essays/initialRequirementsModeling.htm and http://www.agilemodeling.com/essays/initialArchitectureModeling.htm respectively, particularly at scale. Celso Gonzales and I wrote an article about Agile Model Driven Development (AMDD) for the June 2008 issue of Better Software magazine, the article should be online in early May, and showed how to use software-based modeling tools such as Rational Software Architect (RSA) to scale agile approaches.

agilecollab : UML was considered the bible for all architects and designers. However, of late the interest in UML has slowed down. Is there a future for UML after the onset of multiple light weight techniques?

Scott : UML is still a critical skill to have, and as you can see at http://www.agilemodeling.com/essays/umlDiagrams.htm the Agile Modeling community takes the UML seriously. Agile developers are still modeling, but they’re doing so far more effectively than their traditional counterparts, so the UML is still important. I suspect that interest has slowed down because UML has truly become a standard and is now part of the IT intellectual landscape.

agilecollab : This is a tough question. You have written many pioneering books as one can see at http://www.ambysoft.com/books/ - which of them you enjoyed the most?

Scott : Writing books is definitely hard work. I think that the one that I enjoyed the most was Agile Database Techniques, www.ambysoft.com/books/agileDatabaseTechniques.html, because it really opened up the world of database development to agile approaches. The data community has fallen behind the rest of IT when it comes to process, they struggle when it comes to quality and productivity, and in short they really need to improve the way that they work. This book clearly provides concrete, proven strategies for doing so.

agilecollab : Tell us about Enterprise Unified Process. The tagline of the book you wrote is “Extending Rational Unified Process”. What prompted the idea for the same?

Scott : The realization that there is far more to IT than just software development, something that is very easy to observe in virtually every IT organization, led me to work on what eventually became the EUP. Up until the EUP the focus of the Unified Process, including Rational Unified Process (RUP), was on software development. While software development is clearly important, it’s only part of the overall IT picture and the goal of the EUP is to address this greater scope. EUP extends RUP to include a Production phase where you operate and support your system and a Retirement phase where you remove the system from production at the very end of its lifecycle. The EUP also addresses cross-system issues such as strategic reuse, enterprise architecture, portfolio management, and others. Since I first started writing about the EUP in 1999 we’ve seen several plug-ins, extensions, to RUP created to address these sorts of issues. The EUP is described at http://www.enterpriseunifiedprocess.com/ and the plug-ins at http://www.ibm.com/developerworks/rational/downloads/07/rmc_v7.2/

agilecollab : How is this different from Agile Unified Process that you talk about?

Scott : The AUP, http://www.ambysoft.com/unifiedprocess/agileUP.html, focuses just on software development

agilecollab : In terms of developer or architect expertise, what are some hard and soft skills, they should acquire to be successful in any light weight method? Also, are the chances of success better with Enterprise Unified Process or XP?

Scott : The most important thing that architects can do is be prepared to be active members of a development team, including writing code. Architects who don’t write code won’t be respected by the development team, increasing the chance that their architectural strategies will be ignored and thus increasing the likelihood that they will fail. Having people skills and a good knowledge of the business is also critical for architects to be successful. In addition, EUP and XP are completely different things due to their scope. A better comparison would be AUP and XP.

agilecollab : Do you see some specific “technical” instances where the “Application Architecture” generally fails in Agile projects? If yes, what do you think are the 03 top such instances? Which of your books would address these reasons the best?

Scott : It isn’t technical issue that causes architecture to fail, it’s “people issues”. The top three issues would be:

• People being inflexible and insisting on creating a detailed, up-front architecture. The architecture should emerge over time on an agile project.
• People not realizing that you need to invest a bit of time up front to do architecture envisioning. You should try to get going in the right architectural direction so that you avoid major architectural refactorings later in the lifecycle. Get the benefit of modeling, which is to think things through, without the disadvantages of detailed documentation.
• People not understanding the need to prove the architecture early in the project with working code. Too many teams get into trouble because they focus on modeling, documenting, and reviewing the architecture – just because you’ve passed the architecture review it doesn’t mean that your architecture will actually work well in practice.
  • The Object Primer 3rd Edition: Agile Model Driven Development with UML 2, is likely the best bet.

agilecollab : Following on from above, what are your top 03 advices to top management when transitioning to Agile and yet want to have some level of surety of their application’s scalability and maintainability?

Scott : My advice would be as follows:

• Promote a working environment based on trust, collaboration, communication, and flexibility. People, and the way that they interact, are the most important factors in software development.
• Recognize the inherent risks of serial, documentation-heavy approaches and actively ensure that your staff understands them. Too many organizations, particularly those that are struggling to retain experienced staff, think that if they invest in significant documentation that they’ll mitigate the risks associated with high turnover. They’d be better advised to invest that money in developing high-quality code and in retaining their staff.
• Adopt a process which has risk-based milestones, such as Rational Unified Process (RUP). Risk-based milestones are a critical strategy for scaling agile software development, see http://www.ibm.com/developerworks/blogs/page/ambler?entry=agile_scaling_strategy_risk_based

agilecollab : Do you see any difference in how “agile modeling” techniques are applied for full languages like Java/ .Net and lighter languages like Ruby or PHP? Which would be the language of your choice?

Scott : Agile modeling is orthogonal to the programming languages that you choose. Of course, different languages will motivate you to choose different models, but Agile Modeling doesn’t specify which models to choose. My language of choice is Smalltalk.

agilecollab : Agile and Usability are generally thought of mutually exclusive. Do you subscribe to that view? If not, what are some convergence areas you see?

Scott : I have to completely disagree with that. About a year ago I wrote the Agile Usability chapter for the book “Maturing Usability”, http://www.ambysoft.com/books/maturingUsability.html. The material from this chapter is summarized at http://www.agilemodeling.com/essays/agileUsability.htm and I clearly show how the two work together.

agilecollab : What is your day like? What are you currently experimenting with at IBM?

Scott : My days are always incredibly busy. I’m helping customers, and IBM itself, adopt agile approaches for large-scale efforts. I’ve been blogging about strategies for scaling agile at http://www.ibm.com/developerworks/blogs/page/ambler. It’s amazing what some organizations are currently doing, and over the next few years we’re going to hear some very impressive agile case studies. I suspect that we’re about 5 years away from “discovering” that agile scales better than traditional approaches. I’ve also been providing ideas and discussing strategies with various product/tool teams, so that’s been very interesting for me.

agilecollab : Do you think Agile is a phase just like CMM and ISO were? Where do you think the movement would be 15 years from now?

Scott : Agile is here to stay, so it will definitely be here 15 years from now. CMM(I) is still quite strong and in fact many organizations are combining the two. I recently ran a survey which explored this very issue, you can download the details at http://www.ambysoft.com/surveys/processFramework2008.html

agilecollab : How are you able to maintain so many portals at the same time? Are there any time management lessons you could share?

Scott : It’s not easy. My wife helps me with some of it, so that’s part of the secret. I also use standard layouts, fonts, … and basically keep things simple as possible. In hindsight it would likely have been easier to only have one portal, but hindsight is always 20/20.

agilecollab : Finally, are there any plans to visit India [IBM or otherwise] as well as what are your plans for the future in general?

Scott : I hope to visit India in August 2008 for the IBM Rational Software Development Conference: India. My plans aren’t finalized yet but it’s looking good. If I do go I’ll also be visiting clients to discuss agile adoption with them. In addition, my IBM colleague, Grady Booch, recently spoke about the Promise, Limits and Beauty of Software with the Rational User Group community in India, so I would encourage your readers to check out the replay at http://www.rational-ug.org/webcast.php#35

agilecollab.com wishes Scott all the best in his future and current endeavors. If you are interested then, the full list of Scott’s books and articles is available at:

http://www.ambysoft.com/books/

http://www.ambysoft.com/onlineWritings.html

Popularity: 28%