Mike Blechar
While I am not a guru on Agile development methodologies (I defer to my colleague David Norton on these matters), nonetheless it is a topic of discussion on almost every call I do with clients interested in improving their speed of delivery of applications or wanting to improve their understanding of user requirements to deliver the right solution. Agile methods and approaches like Lean, Scrum and eXtreme Programming (XP) are valuable when used selectively based on project needs and objectives.
Agile methods are not a panacea
Whenever I hear managers talking about Agile methods I am reminded of a Dilbert cartoon where Dilbert asks his manager for 3 more developers due to the expanding workload. And the manager suggests, instead, that Dilbert use Agile programming methods to improve productivity. When Dilbert responds that agile programming doesn’t mean doing more work with fewer people, the manager effectively replies “Then find me something which does!”. So, the decision to go to Agile methods generally has more to do with how it changes the business outcome versus Agile methods being “better” than traditional development ones.
So what are Agile development methods?
Agile development methodology is a highly accelerated, iterative development process with monthly, weekly and even daily deliverables of priority requirements as captured in user stories, often documented in test cases prior to coding. The principles of collaboration, refactoring and promoting ownership are key differentiators. Agile methods prefer to define themselves in terms of "values, principles and best practices," rather than as "processes and procedures." Agile methods attempt to establish a high level of collaboration among developers and business users. They also attempt to "flatten" the project and organizational structure, often through self-organizing teams. They embrace the notion that requirements change, unexpected requirements appear, priorities shift and development practices must enable quick, accurate adaptation to these changes.
What impact is Agile having on organizations?
In some Type A (aggressive technology adopter) development organizations, agile approaches on certain projects already are providing the benefits of fast, accurate delivery of priority application requirements. Although agility is rarely the dominant approach, even the lessons that Type A organizations have learned from agile development have a positive impact on other methodological approaches in the development organization. Tight business collaboration (on-site customers) is a key success factor with agility, but it’s also the most broken principle ("You can have my domain expert for three weeks, but no more"). The successful adoption of agility requires more business involvement in the development process than most organizations have committed or experienced with older methods.
Net: Every organization should find that at least a subset of their applications are good candidates on which to use Agile methods to improve time-to-market, cost, functionality and agility– and arguably should be the dominant method of choice for most new service-oriented applications development (SODA) projects. Gartner clients will find the following research of value in understanding Agile development methods and when to use them.
“The Current State of Agile Method Adoption*”, “Don’t Let Short-Term Agile Create Long-Term Pain*”, “Agile Estimation and Planning Is Moving From a Dictatorship to a Democracy*”, “Making the Most of ‘Agile’ in a Distributed Development Environment*” and “Case Study: Inovis Uses Agile Methods to Accelerate Product Development*”
*Available to Gartner clients or for a fee
Category: Uncategorized Tags:
7 responses so far ↓
1 Vinit Kumar Mathur June 27, 2009 at 10:38 am
Hi Michael,
This is a very pertnent subject and is bothering me also. I have been wonedring how to develop IT Systems that “change at the speed of business”. This is more relevant in the current economic downturn scenario wherein the demand for IT has not really slowed down and business users are asking more and more changes to adapt to new situations.
There are two aspects – How to
1. Develop new IT systems using Agile Methods
2. Change existing IT Systems very fast
The former requires adoption of new methodologies that focus on only few critical aspects of development and leave the overheads to be completed at the end.
The latter requires a solid architecture that is flexible to change, For example – a Master data management foundation which allows building of flexible IT systems
2 Michael Blechar June 27, 2009 at 6:24 pm
Yes, you are correct that Agile Methods are not a panacea. We address this in the note “Don’t Let Short-Term Agile Create Long-Term Pain”. Simply stated, Agile methodologies can “get you there faster but constrict you later” by creating more costly overheads. And therefore they should not be used on all projects.
And I encourage proactive things which can expedite solutions as described in my post on “Master Data Management Enables BPM and SOA” as well as implementing the role of the Application/Solution Architect to create reusable software and data services, patterns and templates across application solutions to improve quality, productivity and consistency.
But I’d also like to address two positive things about Agile methods:
1)Agile methods are iterative and intended to build more agile solutions – so overheads ought to be more easily addressed in later iterations and
2)The business can derive value from the delivery of early iterations.
So, while the total cost of development and maintenance of a set of solutions and iterations built using Agile methods might be high, this can be offset by producing greater financial and competitive advantages to the business sooner.
Also, I would like to point out there are advantages to using Agile methods for doing business process improvement – beyond those benefits which IT may see using Agile methods for developers.
But to substantiate your point, organizations need to look at each application or service solution and determine if Agile methods are appropriate or not based on sound business principles.
3 Agile Methods Can Add Value – But Is not a Panacea! « Create IT Value. Now! June 27, 2009 at 9:26 pm
[...] http://blogs.gartner.com/michael_blechar/2009/06/26/reflecting-on-agile-methods-for-applications-dev... [...]
4 Vinit Kumar Mathur June 28, 2009 at 2:36 am
Hi Michael,
I agree with your comments
The main issue that you’ve stated is that the cost of development using Agile means is offset by the early financial benefits that business would derive.
One question I have is whether adopting an iterative approach will be feasible in large implementations involving multiple business units having multi site operations. While everyone would like to have early benefits, is the approach risky for the organisation. For example, in a Steel Industry environment that I work in, I could start with a Supply Chain Project in one of the busines units (say Flat Products) and then later on iterate the same design for Long Products. However, in this approach I may be taking the risk of developing a design that is not suitable for the second business unit
On the contrary, an integrated approach would be less riskier, albeit more time consuming and costly.
We need to make Agile methods the norm as no one can afford large implementation time frames. Proper standards and well proven methodologies are the need of the hour
5 Michael Blechar June 28, 2009 at 1:12 pm
Yes – Herein lies the selective nature of applying the right project approach to the problem at hand – and why in our research we provide a decision framework for choosing the right method.
First, it should be noted that Agile methods need not be applied to a solution being built for only one business unit. Ideally, within the iterative timebox you can involve as many of the pertinent business analysts from ohter business units as possible in order to design the solution with some degree of intelligence in a way which is likely to meet the needs of more than just the primary/first user.
Second, iin an ideal world you have a business process center of excellence where the business analysts have been collaborating on the potential reuse of processes, steps, tasks and data on an ongoing basis as part of the Future Solution Architecture (FSA). Even if the IT project is of limited time and scope for implementing a given process, you should have with the FSA some reasonable vision of what reuse needs to be designed into the solution for future processes or iterations (and whcih business analysts ought to be consulted on the project beyond the primary business unit).
Again, the methodological approach to a project needs to factor in a lot of things – and there are times when Agile will be appropriate and other times when a more formal approach makes sense. This requires both IT and the business to make good choices based on the short-term business opportunity and ROI, but also other factors including quality, maintainability/agility, compliancy, security, consistency and total cost of ownership.
And, now, I will be heading out for a week of vacation. So, I urge you and others to please be patient while I take some time off.
6 Vinit Kumar Mathur June 30, 2009 at 6:34 am
I am interested in learning more about the decision frameworks that you have talked about. Is it something that can be shared ?
7 Michael Blechar July 6, 2009 at 10:24 am
I’m back from a nice week of vacation – hope everyone is doing well!
I obviously cannot share details here in this blog format regarding things like the decision frameworks. Gartner clients who are interested in this topic should arrange to talk to my colleague David Norton and read his research on this topic. Others are advised to work with internal or external consultants and gurus with regards to formulating policies and guidelines on picking the right methods and approaches for individual projects and initiatives.
Leave a Comment