The Agile approach to managing software projects has been getting a lot of play recently. Why are people talking about it so much? Is this just the latest "new thing"? Or is there some real value to it?
"Agile," as a set of software development methods, was defined seven years ago, so the "flash in the pan" would have burned itself out long ago. The fact is that more and more organizations (from small shops to large corporations) are finding real value in Agility.
After defining what Agility is and is not, we will look at the value it can bring.
What is Agility?
The Agile approach has a number or key attributes that can be referred to as the "Essence of Agility." They are:
- Learning and adaptation - Traditional approaches expect that we can foresee how the project will unfold with reasonable precision. The Agile approach accepts that there are many things we cannot anticipate, so it is structured to allow us to first learn about those unknowns and then adapt to what we learn.
- Collaboration - The Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customers.
- Customer focus - The customer is the central focus of an Agile project and is actively involved throughout.
- Small self-directed teams - Agility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.
- Lean principles - The principles that have been proven by Lean Manufacturing are embodied in Agility, especially concepts like "Just Enough" and "Just in Time."
- Progressive requirements elaboration - We expect to learn about the system requirements as the project progresses, so trying to nail them down in a full-blown specification at the beginning of the project doesn't make sense. Agile projects establish a roadmap and elaborate the details as they are needed.
- Incremental delivery - The best way to ensure we are building the right system is to regularly get feedback from our customer. Agility always includes incremental delivery of the product to the customer - at least for acceptance testing.
- Iterative planning and adaptation - Agile projects place a high value on planning. They engage in planning at various levels of detail and engage in it regularly. Again, this is driven by the fact that we cannot foresee everything that is important, so we must adapt our plans as we learn.
What is Agility Not?
Many people have abused the term "Agility" by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:
- No documentation - The documentation that an Agile project produces is significantly different from what traditional projects produce, and an Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.
- No planning - Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day's work.
- No requirements - The Agile team's Product Owner (customer) defines a Product Vision, and they work together to document the product's high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.
- No schedule or budget control - Agile projects always operate within a "Time-Box." That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people's time is the largest part of a software project's budget, the time-box limits the project budget as well. The Agile mantra is, "We will deliver the greatest possible customer value within the project constraints!"
- Programmers doing whatever they like - The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team's only role is to estimate what can be done in limited timeframes. The team's customer determines how that effort will be directed.
The Value of Agility
There are many reasons why companies find the Agile approach (when it is implemented as intended) to provide value. The value that is cited usually includes:
- The right product - The customer is continuously involved in the project, ensuring that valuable software is being built and prioritizing the work. In addition, the customer accepts or provides critical feedback on each increment of the product that is produced. With this level of involvement by the customer, there is no way that the wrong product can be built.
- Quality - Agility always includes a strong focus on the quality of what is built. This includes not only the customer's acceptance testing, but also many technical quality practices. Properly functioning Agile teams produce high-quality software.
- Schedule and budget - Time-boxing of an Agile project means that its schedule and budget are rarely "over-run" If things don't work out as planned, the low-priority features can be skipped or cut short. If an Agile project does need to extend its time-box it would be with their customer's and management's full concurrence.
- Early warning - Because an Agile project is essentially a series of short mini-projects, problems become apparent very early, when they can be corrected.
- Adapting to change - Change is a fact of business. An Agile project can adapt to changes in the business environment, within the organization, or with the customer much more effectively than a traditional project.
Every business values agility (lower-case "a"). What many are finding is that Agility (upper-case "A") provides what it promises.
Copyright ©2009 Global Knowledge Training LLC All rights reserved.
Alan Koch, PMP, is president of Ask Process. Inc., (http://www.askprocess.com/) and an instructor with Global Knowledge Training LLC. A longtime member of the business analysis community, Mr. Koch has 28 years experience in software development. He can be reached at http://ca.mc883.mail.yahoo.com/mc/compose?to=alan.s.koch@askprocess.com.
Comments (19)
Subscribe to this comment's feed
written by Brian Chugg, February 03, 2009
To play devils advocate for a momment it seems to me that Agile will only work if you have the following:
1. A Customer and an IT PM who are prepared to accept that requirements will NOT all be identified up front, ie scope creep is acceptable?
2. Programmers and Customers collobaration (ie. are on the same page. Can they even be on the same Planet?)
3. "Self directed teams" dont get distracted by the technology.
4. How can a project be time-boxed and budget limited from the beginning if we dont know what is required. Will we produce an incomplete product. Is this a risk the customer is prepared to accept.
Just some things to consider. Is agile applicable to all projects or do we need the right conditions to really make it work?
Brian.
1. A Customer and an IT PM who are prepared to accept that requirements will NOT all be identified up front, ie scope creep is acceptable?
2. Programmers and Customers collobaration (ie. are on the same page. Can they even be on the same Planet?)
3. "Self directed teams" dont get distracted by the technology.
4. How can a project be time-boxed and budget limited from the beginning if we dont know what is required. Will we produce an incomplete product. Is this a risk the customer is prepared to accept.
Just some things to consider. Is agile applicable to all projects or do we need the right conditions to really make it work?
Brian.
-
- +3
-
-
written by Pushpa Murthy, February 03, 2009
Excellent article. I am right now in an Agile methodology project and can feel every word of your article.
Thanks much.
Pushpa.
Business Architect.
Thanks much.
Pushpa.
Business Architect.
-
- +0
-
-
written by JP, February 04, 2009
Brian, I agree with everything you said. Can someone give us more concrete details on how Agile should work. That's the reason why people are so afraid of trying it. They don't really know how to manage it and deal with scope changes.
-
- +1
-
-
written by John Snuggs, February 04, 2009
Concise and thorough summary -- WELL DONE!
When applying agile methods (we use scrum almost exclusively), I like to include a focus on improved engineering practices. Things like test automation and top notch configuration management practices. If you can code a little then test a little, your design / develop / demonstrate cycle can be incredibly fast ... and your customer can participate more. It's a virtuous circle that begins with tools that enable continuous integration.
When applying agile methods (we use scrum almost exclusively), I like to include a focus on improved engineering practices. Things like test automation and top notch configuration management practices. If you can code a little then test a little, your design / develop / demonstrate cycle can be incredibly fast ... and your customer can participate more. It's a virtuous circle that begins with tools that enable continuous integration.
-
- +0
-
-
written by Shounak Dasgupta, February 04, 2009
Very effective and pin pointed article.
I am a Business Analyst, and we are trying out an experimental and iterative model, where we are following lots of things from an Agile methodology. Hence, I can appreciate each & every word of this article.
I would sure like to learn more about Agility, and looking forward to a full Agile model implementation (atleast for my work - requirement documentation). I have started documenting requirements in terms of user stories and acceptance test cases, and using ScrumWorks to manage the backlogs.
Regards,
Shounak Dasgupta
Business Analyst
I am a Business Analyst, and we are trying out an experimental and iterative model, where we are following lots of things from an Agile methodology. Hence, I can appreciate each & every word of this article.
I would sure like to learn more about Agility, and looking forward to a full Agile model implementation (atleast for my work - requirement documentation). I have started documenting requirements in terms of user stories and acceptance test cases, and using ScrumWorks to manage the backlogs.
Regards,
Shounak Dasgupta
Business Analyst
-
- +0
-
-
written by Charles Agu, February 04, 2009
Brian I agree with you. the problem am having here is not knowing what the scope is upfront, it means the project can last till eternity because customers will at every stage think up some very funny things they need/want to add to the project, that also have implication on cost and time.
BR
Charles Agu
Business Analyst
BR
Charles Agu
Business Analyst
-
- +1
-
-
written by Mick Wren, February 04, 2009
Good overview. Thanks.
Just a quick observation: Agility suffers from the same inherent issue as other systems development approaches / languages such as as UML, namely it has built into its core the presumption that the answer lies in a systems solution. As a business analyst this is something that must always be questioned.
Give the same problem to a Six Sigma specilaist and you'd get a very different solution. Business analysts need to straddle all of these disciplines if they are to truly determine the optimum solution.
Regards,
Mick Wren
www.businesschange.com
Just a quick observation: Agility suffers from the same inherent issue as other systems development approaches / languages such as as UML, namely it has built into its core the presumption that the answer lies in a systems solution. As a business analyst this is something that must always be questioned.
Give the same problem to a Six Sigma specilaist and you'd get a very different solution. Business analysts need to straddle all of these disciplines if they are to truly determine the optimum solution.
Regards,
Mick Wren
www.businesschange.com
-
- +3
-
-
written by Timothy Fetzko, February 04, 2009
Very good article. I work in a highly structured, corporate environment and we have trouble adapting to non-traditional software development projects.
Case in point - we recently deployed an Enterprise solution using a vendor product. The product was a framework - a blank slate. We tried to put traditional requirements development techniques on top of the project and it was like fitting a square peg in a round hole. It took longer to document the requirements than it did to develop the solution.
We are searching for a more flexible approach that involves the customer more directly. This might be it.
Regards,
-Tim Fetzko
Business Analyst
Case in point - we recently deployed an Enterprise solution using a vendor product. The product was a framework - a blank slate. We tried to put traditional requirements development techniques on top of the project and it was like fitting a square peg in a round hole. It took longer to document the requirements than it did to develop the solution.
We are searching for a more flexible approach that involves the customer more directly. This might be it.
Regards,
-Tim Fetzko
Business Analyst
-
- +0
-
-
written by Claudio Brancher Kerber, February 04, 2009
Brian, I agree with you too. That´s why I´m "selling" agile only for the projects where the approach seems effective.
In our case, we are are about to develop a new product and our BAs have already designed the main concept (2 Km per 2 Cm view) but it involves so many variables that we can´t predict that I prefer applying Agile and release functionality fast in order to get the current prospects (and future costumers) involved, so we can learn and adapt fast.
Of course it´s an especial kind of project and now it seems obvious, but years ago I would try to guess everything, make a big design up front, and of course, get myself into trouble.
Talking about Agile and BAs, when you look at SCRUM it´s hard not to think as yourself as a Product Owner. There are some controversies about this adaptation, but to make your own decision I recommend a small PDF book called "Confessions of a Serial Product Owner" by Anna Forss. You can easy Google and download it.
cheers,
Kerber
In our case, we are are about to develop a new product and our BAs have already designed the main concept (2 Km per 2 Cm view) but it involves so many variables that we can´t predict that I prefer applying Agile and release functionality fast in order to get the current prospects (and future costumers) involved, so we can learn and adapt fast.
Of course it´s an especial kind of project and now it seems obvious, but years ago I would try to guess everything, make a big design up front, and of course, get myself into trouble.
Talking about Agile and BAs, when you look at SCRUM it´s hard not to think as yourself as a Product Owner. There are some controversies about this adaptation, but to make your own decision I recommend a small PDF book called "Confessions of a Serial Product Owner" by Anna Forss. You can easy Google and download it.
cheers,
Kerber
-
- +0
-
-
written by Zander Nieuwenhuys, February 04, 2009
We are in a full on agile environment, and the one benefit that is not mentioned, especially when comparing it with more traditional approaches is the adrenalin and pace.
Many of the analysts, who left our organisation (full agile environment)have returned citing that they are not able to function in the slow moving environment in other consulting firms.
Dare i say: "once you go agile...."
Many of the analysts, who left our organisation (full agile environment)have returned citing that they are not able to function in the slow moving environment in other consulting firms.
Dare i say: "once you go agile...."
-
- +1
-
-
written by ryan forsberg, February 05, 2009
I have been hearing about the wonders of agile for years now. It seems everyone has their own vision of what it is. It is a buzz word around the cooler in our shop.
I am obviously skeptical about the so called benefits of the Agile approach. There are parts that are very logical ie: the Lean principals and client focus. But can these ideas not be applied to all development approaches?
I have serious doubts about certain aspect of Agile.
Most importantly, I have my doubts about the efficiency of such an approach where system architects are expected to periodically adapt their data and application models to accommodate newly discovered requirements. The fact is that Agile requires a significant amount of time spent remodeling and refactoring to maintain any kind of 'Quality' of product. These skill sets do not come cheap. I would argue that the agile approach nearly doubles the developers workload. This may suggest that that the developers can only produce half the software deliverable compared to a more traditional project approach. To clarify, I would argue that our developers are spending half their time remodelling and redeveloping the applications to maintain quality. What's worse is that maybe they are not refactoring and quality is flying out the window!
I would love to hear from other developers on this. Maybe I am totally out to lunch - It wouldn't be the first time.
I am obviously skeptical about the so called benefits of the Agile approach. There are parts that are very logical ie: the Lean principals and client focus. But can these ideas not be applied to all development approaches?
I have serious doubts about certain aspect of Agile.
Most importantly, I have my doubts about the efficiency of such an approach where system architects are expected to periodically adapt their data and application models to accommodate newly discovered requirements. The fact is that Agile requires a significant amount of time spent remodeling and refactoring to maintain any kind of 'Quality' of product. These skill sets do not come cheap. I would argue that the agile approach nearly doubles the developers workload. This may suggest that that the developers can only produce half the software deliverable compared to a more traditional project approach. To clarify, I would argue that our developers are spending half their time remodelling and redeveloping the applications to maintain quality. What's worse is that maybe they are not refactoring and quality is flying out the window!
I would love to hear from other developers on this. Maybe I am totally out to lunch - It wouldn't be the first time.
-
- +3
-
-
written by Wayne Lingard, February 11, 2009
Interesting article and some interesting comments and observations, as a six sigma / lean practitioner who is now trying to work with developers who think they are Agile and are just not interested in any documentation as it benefits them to keep it in there head and not the organization i agree with the sentiments expressed. Agile is ok but if you are constantly having to rework structures and code in your programming then you are wasting time and money constantly. Agile may be good for smaller more improvement type projects but for large projects it may cost twice as much and take twice as long? Has anyone actually done any rigorous data collection to actually prove that Agile is more cost effective??? I would love to see it.
-
- +1
-
-
written by P Dawson, February 11, 2009
I have been part of a development team on a few Agile projects. One thing I would like to add to the "What Agile is Not" list is the misconception that BA's are no longer needed because now the client talks directly to the developer and BA's just get in the way. Anyone else experiencing that?
-
- +0
-
-
written by David Wright, February 18, 2009
Hmmmm...
1) 'Agile' has been around for a while now. If you are looking for loads of content on how to make Agile work, try Scott Ambler's websites.
2) "agile" just sounds good; who wants to be slow and clumsy?
3) I know no one will agree or even believe me, but it is possible to define Requirements up-front. I am not making a sales pitch here, but I will discuss this further if contacted
4) all the focus on Agile development misses one point; it is still the same old software being delivered, that needs maintenance and needs IT people to change it when the business changes. What we need is Business Agility, the ability for organizations to change how they do business without always needing IT involvement. Check out James Taylor's Enterprise Decision Management to see how...
1) 'Agile' has been around for a while now. If you are looking for loads of content on how to make Agile work, try Scott Ambler's websites.
2) "agile" just sounds good; who wants to be slow and clumsy?
3) I know no one will agree or even believe me, but it is possible to define Requirements up-front. I am not making a sales pitch here, but I will discuss this further if contacted
4) all the focus on Agile development misses one point; it is still the same old software being delivered, that needs maintenance and needs IT people to change it when the business changes. What we need is Business Agility, the ability for organizations to change how they do business without always needing IT involvement. Check out James Taylor's Enterprise Decision Management to see how...
-
- +0
-
-
written by Miroslav Divis, February 18, 2009
Part1. I would like to express additional doubts about Agile approach to the ones written in this discussion.
1.Before the first “releaseâ€/cycle may start, we have to decide a lot (logical and physical architecture, data structures, choice of tools, appropriately skilled people…). These decisions will be determining for next work (determining means hard to change, because to much expensive to change). Is this “before†part of Agile conducted project?
2.Code writing is part of development, which has the best automation tools support; code is able to undertake quick changes. Because it is the simplest part of development! There are other parties of development and externalities, which are far more conservative then coding and they do not undertake repeated changes in month time scale:
a.Nobody is going to change hardware and network every month
b.The same conclusion holds for data structures realized by RDBMS
c.Organizational structure of company, role description, whole company policy and realization of these by people – it is very rigid. How often do you want to retrain users, how quickly will be training documents developed?
d.People are able to evolve, of course, but not every month. And I talk about employees, which are little bit “under control†– try this approach to customers of you precipitately evolving Internet banking application.
3.The core problem of project management generally is stakeholders – their identification, getting information from them, balancing of their very different interest, their availability. The number of stakeholders may easily exceed the number of Agile team members and stakeholders cannot be subordinated to every day scrum meetings. It seems to me this big problem was conceal out of Agile approach.
1.Before the first “releaseâ€/cycle may start, we have to decide a lot (logical and physical architecture, data structures, choice of tools, appropriately skilled people…). These decisions will be determining for next work (determining means hard to change, because to much expensive to change). Is this “before†part of Agile conducted project?
2.Code writing is part of development, which has the best automation tools support; code is able to undertake quick changes. Because it is the simplest part of development! There are other parties of development and externalities, which are far more conservative then coding and they do not undertake repeated changes in month time scale:
a.Nobody is going to change hardware and network every month
b.The same conclusion holds for data structures realized by RDBMS
c.Organizational structure of company, role description, whole company policy and realization of these by people – it is very rigid. How often do you want to retrain users, how quickly will be training documents developed?
d.People are able to evolve, of course, but not every month. And I talk about employees, which are little bit “under control†– try this approach to customers of you precipitately evolving Internet banking application.
3.The core problem of project management generally is stakeholders – their identification, getting information from them, balancing of their very different interest, their availability. The number of stakeholders may easily exceed the number of Agile team members and stakeholders cannot be subordinated to every day scrum meetings. It seems to me this big problem was conceal out of Agile approach.
-
- +0
-
-
written by Miroslav Divis, February 18, 2009
Part 2.
4. Team memory. If the memory of running project is mostly not in documentation, but in heads of developers, how effective is project staff change, what is caused when the project is temporary suspended and team members spread into other teams? How is the final release documentation prepared and how is to the most expensive part of development – the maintenance – handed over?
5.How are different projects coordinated, especially when they develop important parts for each other - e.g. interfaces?
6.Learning. During development I am getting experience – about development only of course. For life experience – I have to live (some experience is collected in tests). But I have no time to live – I have to work on next month release. Or one month of development will be alternated by on month of using? In any case, one month is too short time interval – all is new, nothing is settled down, and more – what about the effect of season, of tidiness…
7.By the way – what is the small change? How is the size of change measured? The complexity of different development parties: analysis, coding and testing is absolutely different and knowing complexity of one part I am not able to say anything about the complexity of another part. Small team with fixed staff (roles) compared to very different needs in each release – what about this?
My conclusion: Agile approach is as good and bad as other methodologies and is very code centrist.
4. Team memory. If the memory of running project is mostly not in documentation, but in heads of developers, how effective is project staff change, what is caused when the project is temporary suspended and team members spread into other teams? How is the final release documentation prepared and how is to the most expensive part of development – the maintenance – handed over?
5.How are different projects coordinated, especially when they develop important parts for each other - e.g. interfaces?
6.Learning. During development I am getting experience – about development only of course. For life experience – I have to live (some experience is collected in tests). But I have no time to live – I have to work on next month release. Or one month of development will be alternated by on month of using? In any case, one month is too short time interval – all is new, nothing is settled down, and more – what about the effect of season, of tidiness…
7.By the way – what is the small change? How is the size of change measured? The complexity of different development parties: analysis, coding and testing is absolutely different and knowing complexity of one part I am not able to say anything about the complexity of another part. Small team with fixed staff (roles) compared to very different needs in each release – what about this?
My conclusion: Agile approach is as good and bad as other methodologies and is very code centrist.
-
- +0
-
-
written by Brian Chugg, March 31, 2009
There appears to be a mis-conception that Agile means no documentation. This is probably where most agile projects are likely to fail and probably scare people as well. Certainly from the comments here this seems to be what people think. Both Mike Cohen and Scott Ambler profess that documentation is still required in an agile environment. The key is the level of detail throughout the various cycles and the acceptance of that level of detail by the stakeholders. Its all in the timing, this "Just in Time" concept. Identify the high level requirements early and as the cycles progress build on them with more detail. This is why in a scrum model there needs to be time for analysis as well as development within a sprint. Alan mentions this in the article, its this part of the process that people think they can avoid by going agile, but they cant, if the want it to work.
Having said that I'm still not convinced about Agile, if you dont have the right sort of people and the right sort of work environment (highly communicative) it simply wont work. People need to be on the same page.
Having said that I'm still not convinced about Agile, if you dont have the right sort of people and the right sort of work environment (highly communicative) it simply wont work. People need to be on the same page.
-
- +0
-
-
written by Robert Cunha, April 03, 2009
Another consideration is that a project can include both traditional and agile principles. If a concern is having "light" requirements, then perhaps be more traditional on the requirements phase (more detailed requirements) but apply agile principles on the development end -- iterative development, product backlog, time-box, etc. We did this for a project I worked on and it was very successful. The iterations allowed the users to provide feedback on the product, changes were made to the product back-log and decisions were made to determine what would be included in the next iteration. The time-box approach really forces the business people to make decisions on what features are important. The end result is that all the important fuinctionality was included (and some that was not that imprtant), and anything left out was considered no longer needed or insignificant.
-
- +0
-
-
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
Click Here to login or create a free account.
Click Here to login or create a free account.
I´m a business analyst and together with the development team am trying to convince the PMO to give agile a chance.
thanks,
Kerber (Brazil)