Opinion: Do Agile Development Practices Always Help?

| by Amr Elssamadisy Follow 0 Followers on Sep 10, 2007. Estimated reading time: 2 minutes |
Are our efforts in Agile development really helping the organizations we work for?  What does it mean to ‘help’ our organization anyway?  That depends on our organization's goals – if what we are doing moves our organization towards its goals, then the answer is “yes”, otherwise the answer is “absolutely not”, we may even be inadvertently hurting the organization.

To be concrete, let’s consider a publicly traded company whose ultimate goal is to make money for its shareholders.  Anything that helps the organization makes more money helps the organization meet its goal.  Now, back to Agile development and organizational goals:  given that our organization’s ultimate goal is to make money – does Agile development help make more money?  My observation has been varied – sometimes it does, and sometimes it doesn’t.

Goldratt, the originator of Theory of Constraints, tells us if we are not working on the bottleneck then we are wasting our time – the bottleneck limits the throughput of the entire organization.  In fact, if we work on something that is not the bottleneck and is upstream of the bottleneck, then we are probably making things worse by increasing inventory which, in turn, increases operating expense and lead-time.  

Is software development our organization’s bottleneck?  Is improving software development actually translating into more money or are we simply building inventory that increases the operating expenses and lead-time?  Unfortunately, most of us don’t know.  If we are part of the software development group, then we naturally think it is our job to always produce more or be able to respond more quickly – to be agile.  The painful truth is that if we are at an organization where software is not the bottleneck, we may be wasting our efforts by adopting Agile practices to make things better.

Many of us will shrug and say "that's not my problem, I'm a developer (or tester, or project manager, or ...)".  Is it really only the concern of executives?  Or should we all know about our context to be able to more effectively do our jobs?  Don’t we owe it to ourselves and our organizations to know what the bottleneck is?  If software development doesn’t happen to be our bottleneck, then why are we spending time and effort trying to make it better – it will not help the organization’s goals.  Please share your individual experiences here, do you know your organization’s bottleneck?  If so, how did you find it?  Is it software development?    What is your role in your organization and do you think it should be your business to know the goal and bottleneck?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Subordinating to the bottleneck by Amr Elssamadisy

In Theory of Constraints (TOC), all steps in the process are supposed to be subordinated to the constraint; that is you slow them down if they are moving faster than the bottleneck, and make sure they always support the continuous utilization of the bottleneck.

By far, most of the organizations I’ve worked for have employees who have no idea what their bottleneck is – everyone, everywhere, is sprinting to go faster. Piles of inventory are building up everywhere. All departments are locally optimizing. I have rarely seen a development team ‘slow down’ to keep inventory levels down.

of course they help by Remember Objective

if you have the true agile mindset, you end up deleting inventory...

As an Agile Janitor, you end up asking things like "why 8638 LOCs in 41 files for an application of three (3) pages"???

This excess inventory then gets translated to 3 PHP pages (well, including a reasonable open source framework)...inventory is shrunken dramatically by leveraging outside frameworks and using a dynamic language.

but maybe I give "agile" too much credit...try being a Code Janitor for a while.


Re: Subordinating to the bottleneck by Bruce Rennie

I agree that awareness of ToC should probably be something that's taught in more organizations.

I've had a recent experience that has shown me that it's difficult to just teach practices such as unit testing, TDD, etc. In some ways, it's better to start simply with "You want to go faster but you can't. Why? What could we do to remove that bottleneck?" and allow the organization/team to decide for themselves what they need. When/if they come to automated testing as an answer, then they understand the reasoning behind it and why they need to do it.

They don't hurt by David Chia

Nowhere does Goldratt say "ok, make anything not your bottleneck more inefficient."

Sure, you're adding WIP (work in progress), but at the same time you'd be helping to expose the bottleneck. If you can identify where the work is building up, you can identify the bottleneck. Once the bottleneck has been identified, the organization can act on it.

I believe that Agile practices make things more efficient. Or put another way, I wouldn't want to develop in an non-agile way. Would you? If the software development is the bottleneck, then agile can only help. If it's not the bottleneck, it'll help you find it. There's no reason software development should be penalized for an organizational ineffiency.

Another question is what do you feed your bottleneck? Odds are that you work at a place with multiple projects, but only have capacity to really feed a handful of them at any given time. How do you figure out which projects gets top priority? Ideally, the ones with the most ROI.

Of course, this assumes that the higher-ups are actually using analytical methods to choose projects (as opposed to good ol' social engineering).

faster is helpful either way... by Kevin E. Schlabach

To provoke some thought... if you produce faster to the point of creating "too much inventory"... then management can reduce the overhead (lay off a few people or assign them elsewhere in the organization)... thus saving money. Saving money is almost the same as making money.

Don't be threatened by this concept, sometimes the cost of success is moving on to the next challenge sooner and trying to replicate that success.

Re: faster is helpful either way... by Bruce Rennie

Wait a second here. Too much inventory is considered a BAD thing in most industries and it should probably be viewed that way in software as well.


If we define inventory in software as untested, unreleased requirements, then this is work for which we have paid but cannot received revenue. In fact, there may be even more investment required to test the product in order for it to be released.

The view that software inventory is not a bad thing is based on the idea that requirements will not change. How likely is that? The worst possible situation is where we have invested time and money on requirements, do not release them because we do not have the resources to test effectively, and then have the requirements change on us.

So, yes, it could easily be very dangerous to a company to build up too much software inventory.

Re: They don't hurt by Amr Elssamadisy

Nowhere does Goldratt say "ok, make anything not your bottleneck more inefficient."

Actually he does, but not in those words. If non-bottleneck processes are running too fast, and they are upstream of the bottleneck, they will continue to grow a queue before the bottleneck. In the story, Alex and his group control the raw materials being released, effectively running machines below 100% capacity which reduced inventory and lead time.

Now, back to software development, if software development is not your bottleneck and, for instance, sales becomes your bottleneck, then spending time building software that is not sold is detrimental to the business by increasing operating cost, increasing inventory (unsold software), and increasing lead-time.

Re: They don't hurt by David Chia

He didn't say dumb down the rest of the operation. He just said slow them down.

I'm saying there's a difference between throttling throughput and making something inefficient.

Let's say I want to slow down the amount of items my delivery people deliver to a destination. I can either weight their trucks with 1000 cows, thus slowing them down. Or, I can just send less trucks. One is making something inefficient, the other is just throttling output.

Re: They don't hurt by Deborah Hartmann

> Or, I can just send less trucks... just throttling output.

It's not JUST throttling output. It's reducing inventory. Assuming you don't buy the cows that you don't send because you've reduced the number of trucks. So this plan give you more liquid cash that's not tied up in cows (if I understood the metaphor correctly :-)

Re: They don't hurt by David Chia

I guess I'm not being clear. I thought reducing inventory was implicit in my point. Yes, we definitely want to reduce inventory. If I gave the impression that I was willing to let inventory build up, then I'd like to clear that up. No, I'm not suggesting that. Besides, where are you going to find 1000 cows for every truck? :)

Amr was asking if agile practices always help. In the case of software development not being the bottleneck, it's not helping. But, someone might come to the conclusion of "We don't have to practice agile if we're not the bottleneck." I don't like the implication that any part of the chain that isn't the bottleneck can or should use inferior methods. You should always use the best tool available.

Bottlenecks are fluid. If all of a sudden the bottleneck shifts to software development, then you'll want to have the best tool available. I think agile has been proven to be very helpful.

Re: They don't hurt by Remember Objective

Analytical methods would be helpful, unfortunately it's less than half the story with Agile, due to the innovation dimension, which goes in the opposite direction of analysis/problem-solving. In fact the innovation encompasses the problem-solving.

So worst-case higher-ups are actually two-steps removed from effective prioritization :-) ...

Analysis...problem-solvers would seem to have the edge, but thinking about root causes of an albeit well-defined problem, they are missing the overall...

The overall is basically mischief-making, synthesis. What would be the effect of this? Think of the possibilities. It's divergent, it's the opposite direction. (I'm not talking the Randian hair-splitting here with the term "synthetic").

If Agile includes Innovation process, and I think it does, it supports it really well, then you have much more than problem-solving process. Then who knows how to measure that? Not too many yet. Is there a Learning Tree course for that? Metrics for Enterprise Innovation Processes?


Re: They don't hurt by Amr Elssamadisy

I can either weight their trucks with 1000 cows, thus slowing them down. Or, I can just send less trucks.

ROFL - excellent metaphor David.

You are absolutely correct - we should throttle the process (software development), and release the resources to help with the bottleneck.

This is if you are already doing Agile. But - what if your team is not using Agile practices, and is not the bottleneck?

Rather than spend the time getting the team into shape and speeding up SD, shouldn't you focus on the bottleneck instead?

Re: They don't hurt by Amr Elssamadisy

You lost me - can you please restate?

Re: They don't hurt by David Chia

This is if you are already doing Agile. But - what if your team is not using Agile practices, and is not the bottleneck?

Rather than spend the time getting the team into shape and speeding up SD, shouldn't you focus on the bottleneck instead?

This depends on who you're asking.

If you're the head of the organization (CEO/COO/etc...), obviously you work on the bottleneck.

If you're the person in charge of SD and don't have real obligations to the bottleneck, you work on getting best practices into your process. I mentioned this in an earlier post, bottlenecks are fluid. You never know when SD will become the bottleneck. If I'm in charge of SD, I'd want to make sure we were prepared to be the bottleneck.

Exposing problems (loudly) by Brian Adams

In many organizations, software development is the most visible process in the organization (often due to resource costs). So, even when the software process is not the bottleneck, it is an opportunity for transparency in downstream processes. If you are fortunate enough to be in an organization that allows you to think outside your local software development group, the transparency that agile methods encourage will help you uncover and fix bottlenecks downstream.

Once the 'true' bottleneck is uncovered, agile teaches project teams often find a way to get 'done'. This can mean that the project team redesigns downstream processes, or raises the information upstairs.

Often having a very visible (and somewhat noisy) department focus attention on a downstream process is enough to clear whatever constraint is slowing down the whole.

Not all software development is equal by Justin Corry

The arguments made above can equally apply to questions of which software development activities should be the first to go Agile.

My experience of enterprises is that Agile is applied to new projects with modern technologies first where as the contraint to new initiatives is often changeing the legacy application. It is often better to streamline the legacy enhancement processes first.

I have developed this thought further here -

Re: They don't hurt by Bruce Rennie

Yes, but you're kind of short circuiting the entire ToC 5 point process for addressing bottlenecks. In essence, you're locally optimizing, aren't you? And while you're locally optimizing, aren't you potentially building up inventory?

Re: They don't hurt by Brandon Carlson

Rather than spend the time getting the team into shape and speeding up SD, shouldn't you focus on the bottleneck instead?

I'd say it's much like your initial comment. I don't think that most organizations have any idea where their bottleneck is. My experience is that even the C-level folks in many organizations don't even know.

I struggle with how to locate the bottlenecks across the organization. What are the appropriate measurements?

Re: They don't hurt by Amr Elssamadisy

I struggle with how to locate the bottlenecks across the organization. What are the appropriate measurements?

One of the best simple tools to identify a bottleneck is to search for a large stack of inventory. For software companies that are usually project base, we can substitute the word 'inventory' for 'lead-time'. The path that has the largest lead-time is the equivalent of the biggest stack of inventory.

Therefore, with organizations that are project-based (i.e. not manufacturing), the bottleneck is the critical path. Generally a PERT chart (ala Microsoft Project, for example) shows the critical path clearly.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

19 Discuss