Opinion: Do Agile Development Practices Always Help?
- Share
-
- |
Read later
My Reading List
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?
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Subordinating to the bottleneck
by
Amr Elssamadisy
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
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.
-R
Re: Subordinating to the bottleneck
by
Bruce Rennie
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
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
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
Why?
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
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
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
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
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?
-R
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
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
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
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 -
blog.systima.ie/2007/07/solve-real-problem.html
Re: They don't hurt
by
Bruce Rennie
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.
Educational Content
.jpg)
Building Hypermedia APIs with HTML
Jon Moore Jun 19, 2013
Deleting Code at Nokia
Tom Coupland Jun 19, 2013
Intro to CLP with core.logic
Ryan Senior Jun 18, 2013
Spock: A Highly Logical Way To Test
Howard Lewis Ship Jun 18, 2013
Hello stranger!
You need to Register an InfoQ account 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