Is Agile Really Worth the Trouble?
If development methodologies were a religion – and depending on who you’re talking to, they are – we here at the uTest blog would be agnostic. That is to say we believe no methodology is inherently better than another. As we’ve learned from our customers, almost any approach can work given the right personnel.
That said, there seems to be a strong preference among the industry’s movers and shakers for the Agile methodology. Seen as a more flexible and efficient approach, Agile is now entrenched in dev and testing shops all over the world for a number of reasons – too many to list here. But what if all those reasons are wrong? What if Agile isn’t really more efficient? What if Agile is actually – gasp! – a hindrance to dev and test teams?
That’s the case being made by analyst firm Voke, who just published a report on the hidden (and not-so-hidden) costs of the Agile methodology. In “Market Snap: Agile Realities” they summarized the experiences of over 200 companies who had recently transitioned to Agile. Here are a few clips of what they found, courtesy of TechWeekEurope:
Out of over 200 participants, 64 percent said that switching to Agile Development was harder than it initially seemed. Forty percent of respondents did not identify an obvious benefit to the practice. Out of those who did, 14 percent thought it resulted in faster releases, and 13 percent – that it created more feedback. Seven percent of participants noted that Agile developers were happier due to reduced future planning and documentation.
According to Voke, since the global financial crisis of 2008, the average cost of software projects has seen a sharp rise, even though developer teams have become smaller and the deadlines tighter. Meanwhile, the risk of software failures associated with Agile Development has remained high.
“While many people assume that Agile is faster, better, and cheaper, actual results vary greatly. Many organizations are diving into the Agile movement without a clear understanding of what it is, and what the consequences of adoption may be. They may not realize that today’s solutions are tomorrow’s problems,” said Theresa Lanowitz, lead analyst at Voke.
Is this a problem with Agile or with implementation of Agile? In other words, are they doing it wrong? I’ll leave that for you to decide. In the meantime, here’s Elisabeth Henderickson with her explanation of ”fake agile” from a past Testing the Limits interview:
When I meet victims of fake agile, my first advice is to stop accepting the role of victim. No matter what our role in an organization, we have the power of influence. We can educate our colleagues and managers about the difference between fake and real agile. And we can help the key business decision makers understand that if they want the potential benefits of agile — capabilities delivered sooner at higher quality — they have to support the practices that provide those results and not just support “compress the schedule” and “change everything up to the last minute”.
To close, I’d like to focus on one Agile problem area – the transition – and propose a solution. It’s clear from the report (and countless other sources) that transitioning to to Agile may be the most difficult aspect of the methodology. This makes sense, especially for teams that had become stuck in their ways. So, to help make that process a little smoother, I’d like to revisit a solution from eBay’s Jon Bach called Agile-Fall.
“Agile-fall” refers to having the principles associated with Agile (daily stand-ups, sprints, burndown charts, etc.), done in a waterfall-y series of development steps. Example: Sprint 1: Gather requirements, Sprint 2: Design your tests, Sprint 3, Run those tests, Sprint 4, Fix bugs, Sprint 5 regress those bugs. There’s no shame in that if that’s what works, and when you’re going through a transition from Waterfall to Agile, that may be the best thing as opposed to a sudden lever-pull one day where you show up and your desk is next to someone else with no walls and there’s a stack of sticky notes and markers on your chair with an email to report to your first standup in 30-minutes.
What do you think? Is Agile worth the costs? Let us know in the comments section.
[Image credit: accurev.com]
Where is the proof that Agile is better? There is none. Don’t give me your anecdotal nonsense about some tiny web-based Ruby On Rails project you and a buddy conceived over a weekend.
For all you scrum masters who have gone through the requisite 2 day baptism by other consulting Agilistas, you do a good job of blaming everybody else for the problems of so-called Agile.
Management adopts these things because they’re lazy and they want to buy silver bullets. TQM, anybody? CMM?
That is not to say that some tenets of Agile aren’t worthy, but the Amway-like creepiness of Agilistas and the religious fervor they espouse (along with the usual “you’re not doing it right!” excuse), leaves me unimpressed and forever skeptical.
Where I work, there are a lot of things that the move to Agile have improved.
Empowerment of the team members is way better than it ever was before.
Collaboration amongst developers, testers, and systems engineers is better.
There are things that haven’t really improved and perhaps even gotten worse. But, over all, I would much rather keep what we have today than go back to the water fall based system we had prior.
I think the report mis-represents Agile. Many (although I agree not all) organisations take a disciplined approach including continuous integration and testing, business value assessment and governance. Many organisations are getting significant benefits from Agile (http://blog.standishgroup.com/pmresearch). See also http://www.indigoblue.co.uk/blog/alternative-realities.
wrt your comment on companies finding it harder than expected to be Agile – I would agree with this. For Agile to succeed, it needs to be taken beyond daily standups.
I am going on an interview this Friday and the Company requires Agile with Scrum. Now I’m reading this information and find the statistics very low as far as improved response time.
I was taking classes at Villanova University studying Lean Six Sigma and Reading Lean Six Sigma. This is what my gut was telling me that this methodology had higher accuracy and streamlines and optimizes processes. It’s no longer used for manufacturing it’s been adopted by any organization.
I’d like to understand and receive comments on challenging the Six Sigma Methods and tools compared to Agile.
I have reaped benefits from Agile even though I work in an organization where there’s little or no support to Agile. Agile does work when done correctly.
Agile means top down visibility. If the business can’t be bothered to stay in the loop, Agile won’t work for you and that’s the least of your problems! Think about contracting out to that company because they’re about to waste a LOT of your time with indecision and last minute changes.
The thing everyone is missing is this line:
“the average cost of software projects has seen a sharp rise, even though developer teams have become smaller and the deadlines tighter.”
You can’t bleed a stone. Engineers can only work so much. Knowledge work is not predictable and it is one of the rare fields where the top 10% is an oder of magnitude (or more) better than the rest. Where do those 10% want to work? Where they can get stuff done.
We’ve outperformed teams 10x as big with our small team. We’ve limited them to 40 hour work weeks so there can be no working extra to try to keep up. Yes we use Agile but I realize its not for everyone. I just want to work on something for a few weeks as a team and have something to show at the end. No games… no politics
People try to escape from planning due to impatience. Shorter cycles help those. But so far, none of the agile teams have honestly done unit test automation etc that are core principles in agile. They just have another name for adhoc dev work – i.e. agile. People need new names to cover up their non-compliance to fundamental processes.
The waterfall method has not worked where I work for years. We’ve had projects in development, back to development, back to more development forever and ever. Agile saved time and money and helped us release more products in a shorter time frame than our archaic waterfall methodology. If Agile is done right bringing in experience guru who can quickly teach the organization about Agile it will work and can be applied effectively and efficiently. We were able to get teams assembled and collaborate and communicate and focused on delivering a product that met the expectations of the product owners. Agile does work.
DBD: It depends on the environment. I too have taken Six Sigma classes, but have yet to see Six Sigma applied to software.
My company adopted Scrum about 2 years ago, right before I joined the team. I have never worked (10 years software experience) in a place where development and testing were as tightly coupled and synergistic as they are here. But, it was an uphill battle of almost a year (this is a well-established, stable group on a long-term, large project) to get us past the initial churn.
Fake agile is laziness, I agree. I’ve worked in those environments. Adopting real agile is hard, but can result in an empowered team that starts to take a real interest in finding ways to create higher quality products.
I agree 100% with Pat Larson. I have seen Agile used as an excuse to not document and have seen it used as an excuse to cover up issues that you could have solved without a switch to Agile. I like Agile tenets. I disagree though that you can’t have those if you are not “agile”. You can have daily meetings, good communication, collaboration, empowerment, etc. without Agile. In one specific instance, we had more properties of an Agile group before we switched to Agile…the ignoramus leading it used it as a buzz word and what ended up was we were more waterfall than ever.
Bottom line, you don’t NEED Agile to solve problems in your process. And your quality is directly related to the documentation used to verify your code, design, etc. especially on long-term, maintained and complex products. To me, Agile has incorrectly given a lot of project groups the justification to document less and in some cases not even track necessary progress. I love Agile tenets but those should apply to any project.
Agile has greatly improved our efficiency and our ability to build faster, and with higher quality. We keep things more simple. We work on solving problems, not building something we think the market will use if we can sell it. Agile is working in every aspect of our company.
Agile development has allowed us to become focused, creative, and innovative. We are definitely not doing “fake” Agile. The world is changing rapidly. Agile helps your company change rapidly along with it. We have developed many more products in a shorter time frame with Agile. The products were built in response to needs of our clients.
I really recommend going Agile if you do it right. If everyone embraces it, the growth can be greater than you ever imagined.
Some of what people are calling not enough is a dream to others. I work for a company that does stand-ups weekly, but where it’s actually just a company status report and has zero focus on the active project. The managers band the word agile around to excuse a lack of time to plan and as an excuse to alter requirements a day before release. Sprints are 200 man days with developers checking in sprint 2 code as soon their own sprint 1 work is finished, so with no delineation in builds delivered to test. The user stories are often upwards of 300 words. Fake agile? I’d say more like “fragile”. Empowerment exists to make changes to the process, and as a QA team, we’re more diligent and proactive than the rest at trying to get this done. The recommendations are accepted by the senior management and are approved for implementation as soon as this really tough project we’re doing right now is out of the way and we’ve got more time.
The lessons? Agile isn’t just about getting your peers collaborating, but about getting wholesale buy-in for the transition from management. Without it, you’re doomed to failure.
Pat you seem quite bitter about agile. Don’t dismiss it because you don’t agree or think the people who practise it are evangelists.
It works for some, and works well. Just as waterfall does.
And with both, if you do it in name only it won’t work. Agile doesn’t work if it is not run correctly, just as waterfall doesn’t work if it is not run correctly.
The best thing I have seen in agile is the dev team working more with others, more collaboration and creativity because there is more talk less writing.
For those who say agile is an excuse not to document I ask you what is most important – the product or the documentation of the product?
There is a lot of badly practiced Agile. There are a lot of people selling Agile snake oil. Yes, it’s too easy to get a CSM. Replace “Agile” and “CSM” with any number of other things and it will read much the same. Neither Agile nor those other things are bad when practiced intelligently.
Pat, there are lots of reputable studies showing benefits of Agile. Do a few searches.
If the lead-in is accurate, this study is flawed from the start. The real benefits of Agile methods are long-term, not short-term. There is no way “over 200 companies who had recently transitioned to Agile” could have realized more than a fraction of the benefits.
Even getting through the learning process takes months, just like any other skill. Just because you know how to program doesn’t mean it’s trivial to become a skilled Agile developer. And yes, Agile is a disciplined process that takes practice and hard work to realize. Anyone who tells you otherwise is selling the above-mentioned snake oil.
Everyone comparing agile with stone age old waterfall model JUST to exaggerate agile principles.. Why don’t anyone talking about iteration development model where you have short iteration cycles yet highly productive? I worked in several product dev companies and yet very successful with iterative dev model.
agile is creating business for thoughtworks and new entrepreneurs who has to preach something new. But not adding much for enterprises.
developer frustrations are increasing due to agile methodologies. For example, Add/modify a single line of code require tons of testcases.
developers are turning into testers, who are focusing more on testcases rather than thinking of the effective solution. Design/code is not being cleaner.
my team facing hard time adopting agile, eating more resources than saving..
trust me, whenever new stories are to be assigned, test maintenance is the big part we are discussing rather than business problem that has to be solved for customers. Who is getting benefited with this model? Neither customers, nor us.
what’s your experience folks? Pease talk your experience only.. beware of agile evangelists.
jellybean, how do you sell the product to customers? Are you going to ask your developer(s) to be on sales call?
does your tests are your apis?
documentation of the product is equally important as the product..
newhires find it incrementally easy to read and understand docs rather than tests. Coz tests are developer oriented and not every dev creates tests in same manner.
Agileee.. The new methodology. From my prespective it works very well in product based companies but not for service based in most cases.
Although Agile gives the flexibilty to make changes till end but in practical situation we do not really do it, as the project is coming to end I think each project looses a focus on which methodology they are using.
More over, I have seen many projects do follow Agile but they do lack in documentation part which would be the most critical one when the project is running as well as when it is delivered.
We just need to think where the projects not delivered with quality before Agile coming in picture, I agree that due to new technology or software’s today’s quality is much better however, do we ever or have think when working with Agile of more better solutions for e.g some complex functionality in some cases we might have but in major of cases it fails due to scrum deadline and invariably it ends up in some short term fix.
Over all if we need to use Agile I think we cannot run from Waterfall rather in Agile we need to apply Waterfall
in each sprint planned in Agile Project. This would help in maintain the documentation, the quality, less working hrs (currently on an avg. each resource works almost more than 40hrs even if he works 5 day a week)……
Agile is not a silver bullet lets be very clear on this.
It does work wonders if
There is 100% commitment from the management to support this.
100% commitment from product managers to be involved with teams.
100% trust of the management on the team.
Teams are allowed to independently take decisions on their own.
True Agile is a powerful methodology and has many benefits over waterfall – but only for the right project, client and desired outcome. Agile requires more control over the testing activities compared to Waterfall and arguably better and more rigorous test management, configuration management, and planning.
However ‘Agile’ is frequently used as a badge to infer speeding up, reducing costs and adopting less rigour as companies look to improve speed to market and gain market advantage.
This results (in some cases at least) in running a Waterfall-type methodology but cutting corners at each step in the life-cycle, introducing more (but unquantified/unmitigated) risk to the product delivery.
There’s an ingenious Dilbert cartoon (by Scott Adams) in which Dilbert goes to his pointy-hair boss and says: “We need three more programmers.” His boss says: “Use Agile programming methods.” and Dilbert responds with: “Agile programming doesn’t just mean doing more work with fewer people.”
To this, the boss says: “Find me some words that *do* mean that and ask again.”
JellyBean has an interesting statement:
“For those who say agile is an excuse not to document I ask you what is most important – the product or the documentation of the product?”
Aren’t they equally? Who tests your apps? What do they use to verify against? Their own interpretations? What documentation do you provide customers? Are your developers handling support and sales? What do you do for maintenance and subsequent projects/releases, either testing or code? Isn’t it easier, especially for something complex, if you have valid documentation to refer to? What if someone leaves with their domain knowledge or changes positions and didn’t document their designs or you don’t have requirements to fall back on? For something in the design that was done 5-10 years ago, reasoning behind design and decisions, implementation ideas, explanation of functionality, etc. how do you know what it is or was supposed to do? Do you read through every line of code?
THAT is why I say they use it as an excuse not to document. It’s a typical response from someone who wants to wash their hands of it as soon as they’re done or is involved in a once-and-done project. But, from experience, I can tell you for any long and/or complex and/or maintained product, you need that documentation. You are only as good as your documentation. Unless you and only you will be involved in the product for the next 20 years and then it dies. I’m not disputing you can get a release out quicker. I’m saying you are in trouble after that and I can see it in our own product as well as hearing it from software developers, business analysts, and testers around the country.
So I’ve experienced alot of ‘evangelizing’ of Agile, particularly over ‘waterfall’ in the past decade.
Whats interesting to me is that at its core, Agile just states that we value working software first and foremost. This seems good.
Yet alot of the advocates seem to think there’s some kind of process war between ‘Agile’ and ‘Waterfall’.
In implementation, it seems that most shops claiming ‘Agile’ implement a short ‘sprint’ system with the logic that daily meetings and less documentation and less detailed planning = faster results than those ‘waterfall’ shops that have slower schedules and perhaps perform more analysis.
In reality, I think every individual team’s needs are different and we might benefit from throwing away some preconceived idea of two methodologies at war.
In my personal experience, support shops with narrow changes tend to benefit well from faster iterations as the scope tends to be smaller and code more stabilized. There is also usually adequate time to document small changes.
Large, new development projects need to be careful and need the extra planning up front. They are building foundations for future development efforts.
And I’ve seen both sides of the documentation coin. I’ve seen shops virtually paralyzed by over documentation simply for the sake of compliance.
Likewise there are alot of teams claiming ‘Agile’ who can’t tell you how they got where they are, couldn’t give you a build manifest or prove up anything to show what it was they’ve been doing or how much it cost. Worse even, unable to rollback code once a major issue is introduced into production.
In general, be wary of anyone telling you they know what process you need if they have never set foot in your work environment.
I do believe well implemented agile works, on my experience I have had more of agile-ish implementations and a lot of hybrid. The key for me is as someone already said, the kiddo business and the level of commitment you get from the business users and management. It no a excuse but if you don’t do any methodology all the way they result won’t be a satisfying. Agile is very often misread and misinterpreted as just short development cycle and no documentation. But that misses the reasons why you are able to move without a formal document and work the short cycle, how you document your requirements in the form of test cases, unitest, etc. You need to learn to read/listen to your code.
Five years ago, we made the transition to agile from a very traditional waterfall-style approach. I’ve been in software development for over 20 years now, and can say unequivocally that this is the most productive software development organization that I’ve been involved with. Here are 3 key factors that have made it successful for us (and this is far from a comprehensive list):
Accountability: The simple fact that we all have to stand up together and talk about what we did yesterday and what we plan to do today brings accountability and urgency to our work. It’s hard for people to sit at their desks and waste time when they need to get up the next day and talk about what they did. The fact that we do company-wide demos at the end of each sprint also adds to that sense of urgency in our work.
Communication: Between the daily stand-ups where we talk about our impediments, and the co-located arrangement of our development teams, we have very few instances where people spin their wheels on issues that can easily be solved by a 5-minute conversation, or by bringing up impediments during stand-up. Our regular sprint kickoffs also go a long way to make sure everyone is on the same page regarding our current sprint objectives.
Estimation: We are much better able to accurately estimate and complete our work in 3-week chunks rather than 3-, 6- or 9-month segments. We still do long range release planning, but by completing deliverable code every sprint, we remain “agile” with respect to the scope of what gets delivered when we hit hard release dates. The key to making this work is having full buy-in by our product managers, who are active members of our scrum teams.
We did have some quality issues early on as we learned how to do testing in an agile environment. Some of the keys to making that work for us were establishing key checkpoints for testing – QA previews for new functionality before it is delivered to QA, and test debriefs after our first-pass testing on new functionality, to help evaluate coverage and clarify requirements after we’ve had our first pass. The other big challenge for us was determining what “barely sufficient documentation” means in the context of test documentation.
I have a website dedicated to agile dreams versus realities..
Click on my name (postagilist) above to go there
Jordan
A lot of it comes down to the complexity and risk. You really can’t roll out a whole new version of software using agile and the larger the org, the harder it gets. That said, lots of large development or ongoing development can ‘drip’ out very nicely to users using an Agile methodology.
Having worked using both waterfall and agile methodologies the benefits of agile clearly outweigh the benefits of waterfall. Big specs and resistance to the dreaded “Change to requirements” are a huge overhead in waterfall projects due to the fact the dev is completed by the time you get true customer feedback.
At the end of the day you want to be delivering what the client wants and by drawing in earlier customer feedback loops i.e. whilst the development is still in progress it’s easier to adapt your product to your client’s needs, this is where you can really reap the rewards of agile.
In a large scale waterfall project you can spend weeks reviewing tech specs and writing tests scripts only for it all to change by the time it hits QA. This is a huge burden to deal with and compromises key deadlines being hit, not to mention all of the re-work which in turn builds resentment towards your client who is simply requesting what they want.
Whilst i agree there is a lot of “fake agile” being used when implemented properly you can customise it to work the way you want. You are not prescribed a rule set to follow you are given guidelines to use to mould to suit your team.
For example we currently impose kanban style boards and have imposed work in progress limits so we only work on a maximum of 3 stories at any one time. If the work is not accepted by the client by the time all 3 lanes of work are blocked then we don’t continue further until the client accepts, which reduces risk to the business as they can invoice accepted work rather than running the risk of spending months on a huge amount of work only for the client not to accept the invoice until you spend another month reworking your solution.
Work smarter not harder!
Somehow the USP of agile lies in its being anti-waterfall. The premise is that agile corrects all that is apparently wrong with Agile. The answer to the question “Is Agile Really Better than Waterfall?” should be a no since no method or model can claim to be perfect in all situations.
Somehow the USP of agile lies in its being anti-waterfall. The premise is that agile corrects all that is apparently wrong with waterfall. The answer to the question “Is Agile Really Better than Waterfall?” should be a no since no method or model can claim to be perfect in all situations.
I have been woring for a Networking company (which actually falls under embedded domain) and I have not seen any Testing Methodlogy that really could be applied here. But recently we are planning to Move a Mix of Agile, XP and with our own testing process as well. I think this is exactly called “Agile-Fall”.
Thanks for letting US know about this. Now I know what the test methodlogy we need to follow.
To avoid developers getting sucked into testing in Agile methodology , planning of testing resource in terms number & skill is necessary.
Agile strength comes handy to handle frequent chage requests from customers and meet aggressive time lines without compromise on quality .
In the times where project managers were people who worked their way up from programmer, lead programmer, perhaps architect, business analyst, and then project managers, there was no need to stick to a methodology. The project manager knew what he wanted and how.
Now a days, anybody with no programming experience (and even no computer’s background) can be a project manager. How do you cover that knowledge gap? Just sticking to a recipe, an off-the-shelve formula that will tell you how to do your work. And Agile is nothing but that, a formula for non-experienced managers.