In This Issue
- Not Agile Yet? Exploring the Excuses
- Hot Links
Not Agile Yet? Exploring the Excuses
It's the time of year when people are starting to think about what their New Year resolution will be. My suggestion, at least for your professional resolution, is that you should strive to help your organization become more agile. The majority of organizations are already on this path, Dr. Dobb's July 2009 State of the IT Union Survey found that 76% of organizations had adopted agile techniques on one or more of their IT projects, but clearly there are still some hold outs. Recently, one of the issues which the Dr. Dobb's November 2009 State of the IT Union Survey explored is why some organizations hadn't yet adopted agile. In this article, I explore the reasons which people gave, and more importantly describes strategies for overcoming these perceived challenges based on my experiences over the years helping organizations to do exactly that.
The most common excuse, cited by 59% of respondents, was that their organization has a culture that isn't receptive to change. I run into this problem all the time, and my observation is that although cultural change can be difficult it is in fact achievable when you choose to do so. Common cultural challenges that I run into are caused by groups of specialists who have over-engineered the processes that they follow, either because they've accepted the Tayloristic organizational principles of traditional development or because the manager of the group is shoring up their political empire. Examples of this include:
- Business analysts who insist that only they have the requisite skills to interact with stakeholders and that "their work" is to write detailed requirements speculations (a far more accurate term than requirements specifications). They could instead choose to adopt agile analysis strategies based on evolutionary collaboration throughout the lifecycle.
- Data management groups which insist that "their work" on creating detailed logical and physical data models must occur before development begins. These people could choose to adopt agile data techniques such as agile data modeling, database testing, and database refactoring which would increase their productivity, the quality of your data sources, and their ability to interact effectively with the rest of IT.
- Architects who insist that it is "their job" to think through all the high-level technical decisions, or at least bless them from their exalted perches within their ivory towers. They could instead choose to work in a more collaborative and evolutionary manner with the rest of the development team, sharing their skills with the others while ensuring that the team works to, and leverages, an effective architecture.
- Project managers who insist that it is "their job" to create, and then maintain during the project, detailed schedules and estimates for the team. They could choose to instead focus on leadership and coaching activities, which is what teams really need of them, and let responsibility for the detailed planning efforts to be done by the people doing the actual work occur in a just-in-time (JIT) manner throughout the project.
- Testing groups which insist upon having a detailed requirements speculation provided to them before they can begin "their work", even though they could choose to adopt agile testing strategies where they work in an evolutionary manner as part of the whole team.
Nearly half (47%) of respondents indicated that they don't have the resources needed for proper training and mentoring, which given the current economic climate is an unfortunate reality that many of us face. Although it's often hard to do, you need to find a way to pry loose some funds from the tightly clenched claws of your organization's financial people and invest in your staff. Numerous surveys have found that agile teams are more productive than traditional teams, so the opportunity exists to get positive returns from your education investment.
One third, 33%, of respondents indicated that their senior IT management didn't want to take an agile approach. My experience is that these managers have become concerned with some of the marketing claims of the mainstream agile community, if the claim that someone can become a certified master after taking a two-day course that practically nobody seems to fail doesn't scare the bejeezus out of you then I don't know what will, and as a result haven't gone further to explore disciplined agile delivery strategies. I find that when I walk these people through the Agile Scaling Model (ASM) that their concerns soon start to disappear.
One in five respondents indicated that several organizations were involved in development, often they were outsourcing all or part of the development effort to an IT service provider, and therefore they couldn't be agile. Having consulted to organizations on both sides of the services fence, I am very frustrated by this misunderstanding. The customers will tell me that they would love to work in a more agile manner but that the service provider isn't able to work that way. Conversely the service providers tell me that they've been trying to work in an agile manner for years, and often do so as much as possible behind the scenes, but that their customers insist on a more rigid and documentation-heavy approach. The real problem is often a dysfunctional procurement process based on traditional strategies where the customer defines up front, in detail, what they want and insists on the service provider to commit to the cost and schedule. In theory this sounds like a good idea, but in practice this strategy proves to be very risky and wasteful and little more than a nave gamble in many cases. Customers are much better advised to sit down with the service provider and have a frank discussion as to how they could work closely together as true business partners, and then actually follow through and do so. This strategy is also advisable if the other organization(s) that they're working with aren't service providers but instead are similar organizations to their own, perhaps they're involved with a consortium working on a common industry platform or perhaps they're working with similar divisions within their own organization.
The other excuses for not adopting agile approaches, all of which can be overcome if you choose to do so, included:
- 19% of respondents indicated that they have regulatory compliance issues. Interestingly, 19% of respondents whose organizations had adopted agile reported that they'd been successful applying agile strategies in regulatory situations.
- 14% of respondents indicated that they must conform to frameworks such as CMMI or ISO 900x, whereas 25% of respondents working in organizations doing agile reported success at applying agile strategies in such situations.
- 14% of respondents indicated that they have very complex technical environments, yet of the agile respondents 62% reported doing integration with legacy systems, 42% reported working with legacy data, and 34% reported working with multiple technology platforms.
- 14% of respondents indicated that their business stakeholders don't want to take an agile approach. My experience is that some stakeholders no longer trust their IT departments to deliver on their promises and therefore want to have as little to do with IT as possible. This is challenging for agile teams because we want to work closely with our stakeholders throughout the project. Luckily it's very rare for all stakeholders within an organization to be wary of their IT department. So, at first I look for projects being sponsored by stakeholders who want to be closely involved, thereby increasing the chance of project success. After a few visible successes the other stakeholders will start to come around.
- 13% of respondents indicated that they have a very complex business environment, which is where agile approaches do very well in practice. Of the people doing agile, 35% reported that the most complicated business problem that they had succeeded at with agile strategies was of medium complexity, 22% reported success at complex projects, and 18% with very complex projects.
- 12% of respondents indicated that they outsource development to a third-party vendor, but as I discussed earlier this shouldn't be a problem if you're able to get your procurement people thinking outside the enterprise box.
- 10% of respondents indicated that they have very large teams, yet in the survey some people were indicating success at agile teams with hundreds of IT professionals involved. They might find Agile and Large Teams of interest.
- 7% of respondents indicated that they do mostly package/COTS implementations, yet as I showed in Agile Package Implementations that it is in fact possible, and arguably quite desirable, to apply agile strategies in this situation.
Although there are a lot of excuses given for not becoming agile, none of them seem to hold up with a bit of scrutiny. As an individual you can choose to become more agile, although perhaps not as much as you'd like. You can also choose to help other people in your organization better understand the implications of agile, and better understand that it is possible to overcome the perceived challenges with adopting agile strategies. My hope is that you choose to do so. Regardless, I hope that you have a great new year!
Agile and Large Teams overviews how to succeed at "large team agile."
Agile Package Implementations describes how to take an agile approach to commercial off the shelf (COTS) package implementation.
Generalizing Specialists: Improving Your IT Skills argues that part of becoming agile is to move away from being overly specialized to have both one or more specialties as well as a general knowledge of the software process.
Introduction to the Agile Scaling Model summarizes the ASM framework which provides advice for scaling agile strategies to meet the unique needs of your project.
The Agile Data site includes numerous articles for how data professionals can become more agile.
Agile Testing and Quality Strategies: Discipline Over Rhetoric summarizes a collection of agile strategies for testing and quality assurance.
Agile Architecture: Strategies for Scaling Agile Development summarizes techniques which enable architects to increase their agility.
The Danger of Detailed Speculations summarizes the evidence around how detailed specifications can increase, not decrease, the risk on your IT projects.
Rethinking the Role of Business Analysts: Towards Agile Business Analysts? presents a roadmap for how business analysts can become agile.
The Surveys Exploring the Current State of Information Technology Practices page links to the results of all the Dr. Dobb's surveys which I've run over the years.
My Agility@Scale blog discusses strategies for adopting and applying agile strategies in the complex environments.