Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Opinion: Do Agile Development Practices Always Help?
Posted by Amr Elssamadisy on Sep 10, 2007
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?
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Improving Software Delivery Cycles: Pre-requisites and Inhibitors
How ALM Supports Business Processes
Using ALM to Drive Business/IT Alignment
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Subordinating to the bottleneck
by
Amr Elssamadisy
Posted
Re: Subordinating to the bottleneck
by
Bruce Rennie
Posted
of course they help
by
Remember Objective
Posted
They don't hurt
by
David Chia
Posted
Re: They don't hurt
by
Amr Elssamadisy
Posted
Re: They don't hurt
by
David Chia
Posted
Re: They don't hurt
by
Deborah Hartmann
Posted
Re: They don't hurt
by
David Chia
Posted
Re: They don't hurt
by
Amr Elssamadisy
Posted
Re: They don't hurt
by
David Chia
Posted
Re: They don't hurt
by
Bruce Rennie
Posted
Re: They don't hurt
by
Brandon Carlson
Posted
Re: They don't hurt
by
Amr Elssamadisy
Posted
Re: They don't hurt
by
Remember Objective
Posted
Re: They don't hurt
by
Amr Elssamadisy
Posted
faster is helpful either way...
by
Kevin E. Schlabach
Posted
Re: faster is helpful either way...
by
Bruce Rennie
Posted
Exposing problems (loudly)
by
Brian Adams
Posted
Not all software development is equal
by
Justin Corry
Posted
-
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. -
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.
-R -
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. -
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). -
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. -
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.
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. -
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. -
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. -
> 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 :-) -
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. -
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?
-R -
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? -
You lost me - can you please restate?
-
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. -
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. -
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 -
blog.systima.ie/2007/07/solve-real-problem.html -
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?
-
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? -
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.
19 comments
Watch Thread Reply