“The best advice that I can give to organizations is to get help from a company with enterprise-class experience...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
with Agile delivery and to be prepared to make a long-term investment transitioning to Agile and Lean strategies,” says Agile expert Scott Ambler. In this second part of a two-part interview, Ambler talks about team sizes, organizational models and the transition to large-scale Agile. Ambler will be presenting, The Agile Scaling Model (ASM): Be as Agile as You Need to Be” at the upcoming Agile 2011 conference. Find out more about ASM and the eight scaling factors in part one.
SSQ: Do you feel that for each of the factors you’ll be talking about that there is an “ideal” for success? For example, I’ve heard things like “Team size is ideally seven to nine people, and if you have more than nine people, you should split into multiple teams.” What are your thoughts on this?
Ambler: Keeping the situation as simple as possible is the ideal. Each of the scaling factors is described in a similar manner, presented as a range with the simple/ideal situation on the left hand side (i.e. small teams, co-located, no regulatory compliance, and so on) and the harder situation on the right hand side (i.e. hundreds of people on the team, globally distributed, life-critical regulatory compliance, …). I’ve run surveys over the years which show that Agile teams not only find themselves in all of these situations but are also succeeding in them (and yes, failing in them, too). So, it’s good that many people talk about focusing on ideal situations, that clearly increases your chance of success, but realistically we should be talking about the actual ranges that teams find themselves in and provide tailoring advice to address those situations.
SSQ: Speaking of ideals, what are your thoughts on the ideal organizational model? Do developers and testers belong in the same organization?
Ambler: I’ve written extensively about this issue. I’m a firm believer in project teams being “whole” and having sufficient skills to get the job done within the team. A whole team would include people with testing skills, analysis skills, architecture skills, programming skills, and so on. However, at scale there is often very good reason to have an independent testing effort supporting the whole team. For example, regulatory compliance may dictate that. Technical complexity of your environment may require sophisticated, pre-production integration testing which is only economical when done by an independent test team.
SSQ: For large organizations that are transitioning from a traditional to Agile approach, what are your recommendations about where to begin?
Ambler: It really does depend. We promote a strategy called Measured Capability Improvement (MCI) where an initial assessment by a qualified person(s) occurs, a prioritized plan which reflects the unique situation is developed, then improvements are made accordingly. This should be supported by qualified mentors and coaches and a light-weight measurement program. The best advice that I can give to organizations is to get help from a company with enterprise-class experience with Agile delivery and to be prepared to make a long-term investment transitioning to Agile and Lean strategies.
SSQ: Do you think large legacy applications that are in maintenance mode would benefit from a switch from traditional to Agile? If so, would you recommend only using Agile techniques such as TDD on new code, or would you suggest adding TDD test cases for code that is already written?
Ambler: Once again it depends on the situation. Issues that I would look for are generally people oriented. Does the maintenance team prefer to work collaboratively? Are they quality focused? Are they willing to improve their toolset (I can’t tell you how many times I’ve run into maintenance developers still using development tools from the 1980s)? Are they willing to learn new skills such as TDD, Continuous Integration (CI), and others?
As far as developing a regression test suite for legacy code, I generally suggest developing it over time as you touch existing code or add new code. This requires discipline, skill, and a long-term focus. Also, there’s more to enterprise modernization than fixing the code (frankly, that’s usually the easier stuff to do). What about fixing your existing legacy data sources? A few years back I wrote Refactoring Databases with Pramod Sadalage which showed how to fix both development and production relational databases. Lately, I’ve worked on applying those techniques to hierarchical datastores such as IMS. Also, what about consolidating your portfolio of systems? This requires both an enterprise view and a long-term view. Retiring existing systems in favor of a shared solution can offer significant benefit to your organization.
SSQ: If you only could give one piece of advice to an enterprise team that is making the switch to Agile, what would it be?
Ambler: My one piece of advice is to talk to disciplined Agile practitioners who have experience in applying Agile techniques at scale throughout the entire lifecycle. You can leverage their experiences and they are a great starting point when making the switch to Agile. However, you want to be careful of whom you speak to since there are various certification schemes and "quick fix" coaching promises out there. When you’re ready to make that switch, understand that you'll need to make changes to your practices, tooling, and organizational culture. These changes do take time, but is a worthwhile effort.
The ASM is described in greater detail in the IBM whitepaper here.
The Disciplined Agile Delivery (DAD) process framework is described in greater detail in the IBM whitepaper here.
Click here to read the IBM whitepaper Lean Development Governance written by Per Kroll and myself for some interesting insights.
You can read more about MCI here.