OutSystems BlogDev Zone

Agile = speed over quality?

Don’t think about it – what’s the one word that springs to mind when you think of “Agile” in terms of application development? Write it down somewhere.

The above video is from this year’s OutSystems NextStep users conference where we asked Agile Platform users from around the world for the one word that they felt summed up Agile. Some of the responses: Change – Flexibility – Success – Efficiency – Time-to-market – Quick – Mandatory – Build-to-change – Web 2.0 – Faster – Quick – Success…Most are about speed and flexibility – but interestingly “Fit for purpose” and quality of application (measured for example, in terms of how well it delivers what the business needs) are not mentioned.

Why not?    Is it just this set of people who responded this way?   Does the Agile community at large think speed over quality?

I can’t speak for the rest of the Agile community but in terms of the OutSystems community, I suspect a number of things:

1)    Waterfall has led to an expectation of extremely slow delivery…and so the excitement over rapid iterations and speed of delivery.

2)    Having the business guys on the team throughout the process, coupled with rapid iterations means by default the results are high quality … and so quality is being taken for granted. Their main concern now is how to increase the number of projects that use the Agile approach without slowing things down.

3)    They’re all using the Agile Platform (sorry, shameless plug) that enables rapid delivery of large-scale apps using Agile and SCRUM methodology and are very happy with the speed.

I’d love to hear what other practitioners in the Agile community think is their “one word” – but either way, I think one of the most important issues here is that we, as practitioners and people who are teaching newcomers about the benefits of Agile, remember that it’s not about quality OR speed – Agile is all about quality AND speed.
You should follow us on Twitter here.

 

About the author

Mike Jones

Mike is a professed 'hater' of complexity. He has been in the IT industry since the mid 80's where he learned his technical skills at EDS and Texas Instruments. He believes there is a simpler way for IT professionals to deliver business value that requires a pragmatic mix of agile methods and application development tools.

Comments

It’s two words, but my response might be “appropriate outcome”.
By appropriate, I include this scenario in my thoughts: http://agile-commentary.blogspot.com/2009/07/early-kills-are-improvement.html

Quality, speed, flexibility, etc all come from one source, the ADAPTIVE (rather than prescriptive) nature of agile development.
Adaptive is therefore my one word. Do and test seem to come pretty east to most teams transitioning to agile but to complete the circle they need to learn from the test and ADAPT, otherwise there’s little point.

Michel Ozzello

Speed is commonly referred as one of the main outcomes of adopting agile.
I think that has to do with the fact that with Waterfall, people were used to see a first (crappy) version of the application only after 18 months… with agile they get to see a working version after a couple of weeks, and then see it evolving every week during the sprint demos. That gives people the notion of speed – things happen fast and they get to see the application evolving every week.

Chuck van der Linden

You are either jumping to an unwarrented conclusion, or purposely choosing a title and position (a ‘straw man’ of sorts) that is of the ‘modest proposal’ type designed to cause a reaction and drive traffic to your blog.
Fact: speed was not the most common answer, “change” was
Fact: nobody in the video gave an answer that indicated a LACK of quality. nobody said ‘shoddy’ ‘slapdash’ ‘buggy’ or any other one word answer that indicated quality was lacking or being sacrificed.
So everything on the right hand side of the = in your title is bogus.. ‘Change’ would be more accurate than ‘speed’ when it comes to the most common theme in the answers. and there’s no basis to add ‘over quality’ to that, because there is nothing in the answers given that provides a basis to onclude that the respondants thinking was anywhere along those lines.
So what are we left with?? ‘Agile = Change’.. but of course that’s old news and doesn’t make for a good blog title to slather all over linked-in and anywere else you cna find to promote you blog.

as said by chuck nobody said lack of quality.
Actually in my experience (and I guess everyone on the agile projects I know) would say agile is speeding thing up because of quality.
there are other parts why agile is speedy, but quality is a necessary part of it.

If I was going to pick one word (and fully recognising that picking one word is a pretty silly thing to do 🙂 I’d pick “joy”.
The joy the customer gets when they actually get a product that they want.
The joy the team gets in actually building stuff that works that people actually want.
Yeah – I dig all the quantitative improvements…. but gosh darn it doesn’t it just _feel_ better?

Maysoon

I just posted this to a linkedin group in response to a question and thought I’d put it here too. In the video people were answering the “one word about agile” question and the crowd was a mix of folks experienced in Agile and some who were just starting, during an OutSystems Agile users conference. I think that the original blog post was intended to drive a conversation about the benefits of agile – but the title of the post, as a few have noted, did not communicate this well. The video was just used as a trigger for new ideas and answers, and was not directly related to the title (which should have been clearer – apologies for any confusion).
There have been some great responses both with “one word” question and the speed-quality discussion, plus lots of valuable lessons learned about blogging!

I would say ‘Better’. I wouldn’t sell Agile on being quicker, although we might get down to actually making something a bit quicker than with waterfall, the final finished product could take as long, surely? We just spend more time making the thing work well. At least that’s my limited understanding of it all.

Kevin

Agile is about early return on investment and reduced risk (value) a side effect is that it delivers faster..quality is not usually a variable as this would simply slow things down and reduce the ability to deliver value in subsequent iterations. Yes the concept of velocity is used in Scrum and this does imply speed but the fundamental aim of agile is to be couragous and to be truthful…unlike traditional approaches which try and hide behind a plan which does not reflect the reality which is software development is empirical and cannot be planned in detail upfront.

Not by a Long Shot!

Agile is (all) about Value to the Customer, and Quality built into the process and into the product.
Agile means frequent customer validations of product quality, of product adherence to requirements. It does not mean fast and sloppy
delivery of some product features.
Kind regards, Gastón

Even if speed is the first and most important attribute of an agile method, it is a mistake to think that speed comes at the expense of quality: in fact, increased speed should drive improved quality. Why? Because poor quality no longer has any place to hide. In a long waterfall delivery cycle, poor quality can creep in anywhere, and inspection (a very ineffective technique) is really the only way to find it. Typically, poor quality only comes to light at the end of the project, when you are already behind schedule, and so quality is compromised in order to avoid the schedule getting even worse.
On the other hand, if you are operating with a long series of very short delivery cycles, then you can no longer afford to inject poor quality into the product, because the impacts to everyone and every aspect of the project are almost immediately apparent.
Think of it like a runner’s gait: if you’re running slowly, you can use almost any gait you like, and get away with it; as you speed up, though, the problems with a poor gait become more apparent and less sustainable.
The other analogy, from lean manufacturing, is inventory reduction. As you reduce inventories (analogous to reducing your inventory of partially developed software) you are forced to fix quality problems in order to maintain delivery schedules.

Leave Your Comment