The Goal

[Brandon Carlson]

For the uninitiated, "The Goal" is set in a manufacturing setting and is focused on optimizing the operations of a plat that produces physical goods and it's one of the most eye-opening books I read when starting down my Agile journey.

With that being said, there are places where the lessons in the book are directly applicable to product development and there are places where it is not. For those who have read the book, where have you seen the ideas presented within the book succeed? Break down?

I have my thoughts but I'll hold off on them for now. :-)

Brandon

---------- Forwarded message ----------
From: Moreland, Bridgett <BMor...@fhlbdm.com>
Date: Fri, Apr 20, 2012 at 8:45 AM
Subject: RE: [agileiowa:127] April Meeting Tomorrow!
To: "agil...@googlegroups.com" <agil...@googlegroups.com>

I second a reading of ‘The Goal’. It was a required reading for a MBA class I took a while back and it is one of THE singular turning points to get me energized and on track to understand and effect change. Many “A-Ha!” moments and it is so engrossing you don’t want to put it down until you’re finished.

 

From: agil...@googlegroups.com [mailto:agil...@googlegroups.com] On Behalf Of Tom Henricksen
Sent: Friday, April 20, 2012 8:39 AM
To: agil...@googlegroups.com
Subject: Re: [agileiowa:126] April Meeting Tomorrow!

 

I asked Brandon the same question awhile back,  here is his response:

 

As far as my Agile reading list goes, I would say the following books are pretty useful:

 

The Goal -- Eli Goldrat (http://tinyurl.com/82xdjbt), not about software but the parallels are kinda scary

Agile Management For Software Engineering -- David Anderson (http://tinyurl.com/7sp8vwf) 

Kanban, Successful Evolutionary Change for your Technology Business -- David Anderson  (http://tinyurl.com/7ht2b3d)

Implementing Lean Software Development, Concept to Cash -- Mary Poppendeick (http://tinyurl.com/74q8enw)

The Lean Startup -- Eric Ries (http://tinyurl.com/83mvq9f)

 

That should get you started anyway. ;-)

 

On Fri, Apr 20, 2012 at 8:09 AM, Richard Hermann <richardher...@gmail.com> wrote:

Brandon,

 

Hey I wanted to tell you how much fun I had last night. I've been kind of out of the loop on current software activities the last couple of years since moving back to DM and have really missed it. The place I'm working is small and I don't have any like minded people to interact with. I did join the IADNUG about a year ago and attended several meetings but nothing was as fun as what we did last night. Does calling that "fun" make me a geek ? Ha ha, guess so. 

 

I do have a question though. As you may have surmised I don't have a lot of experience in Agile and would like to know what you would consider good reading/background material. A book recommendation or reference to an online tutorial would be best. 

 

Thanks and take care,

Rick Hermann

 

On Wed, Apr 18, 2012 at 9:19 PM, Brandon Carlson <bca...@gmail.com> wrote:

Date/Time: Thursday, April 19th from 6:00-8:00 PM

Location: Okoboji Grill in Johnston (large meeting room)

Speaker: You

Topic: Open Jam

For the April 19th meeting we will be collecting topics from attendees and discussing them in breakout sessions during the meeting. Bring your questions, from novice to advanced and get the answers you need.

 

--
Richard Hermann

 

This message and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed.  If you have received this email in error, please delete the email and any files transmitted with it entirely from your computer.

[Mike Prior]

Like Bridgett, there were many "a-ha" moments for me in The Goal.  The beauty of this book is that one of the main characters uses Socratic questioning to challenge the other character into solving his own problems, which in turn causes you to start thinking critically about cause and potential outcomes before you see how the main character does it.  Sneaky.

Perhaps the biggest concept is the idea of identifying your bottleneck and understanding the role that plays in continuous flow.  Finding out that you are only as fast as your bottleneck, the idea is to identify that bottleneck and make sure that that resource is only working on tasks that the bottleneck can do.  Additionally, it makes sense to find out how to optimize the work flow so that the bottleneck resource only touches the product once.

I was first able to apply concepts in The Goal when I worked on a team that was tasked with fixing defects reported by customers.  We were falling behind with more defects arriving that we could kill.  The first thing we did to fix this was alter the mechanism feeding our development group these defects.  We created a first-in-first-out queue in which we picked up and fixed defects in the order they came in.  Secondly, we measured.  Now that we had a more stable inflow mechanism, we could then begin to establish some level of predictability of when a defect would be fixed.  This armed support with critical information when talking with customers.  Or better yet, support could reach out to the customer and let them know.

Knowing that we wanted bottleneck resources to ONLY work on bottleneck work, we also tried to find ways to reduce the amount of defects into our bottleneck (development team).  We did things like weekly defect backlog grooming with support and the business and asked the data team to work data specific defects allowing the development team to focus on code related defects.  Ultimately we were albe to get the defect fixes out the door quicker AND gain back some trust with our support team and our customers.

There are little nuggets everywhere in the book that make you ask "how would this affect what I am working on?".

I would also second the reading of David J. Anderson's book, "Kanban, Successful Evolutionary Change for your Technology Business".

Mike Prior

[Brandon Carlson]

Nice! 

I agree with your thoughts on this. I'd like to ask another question to the group. The manufacturing setting that the book takes place in is linear and deterministic. In software development, however, work is much more variable. How did you identify the bottleneck in such non-linear processes. For example, a defect could bounce between the customer and IT 15 times before it's finally determined that it should be fixed. Any guidance here?

Thanks!

Brandon

[Mike Prior]

Sorry, just getting back to this…

I think the key is to try and reduce as much variability as possible because the more variability you have the less predictability you gain.  One way to reduce variability is to reduce or standardize wait time.

But finding a bottleneck in a non-linear process…  Hmmm.  I think maybe one thing to identify is the incoming vs. outgoing items in each cycle of the system.  Are more things coming into IT than are going out and do we have a build up of items waiting for IT to work?  Or are we finding that we have a build up of questions that need answered by the customer team before we can call the development work done?  

Of course you can guess about those things but you really need to measure incoming vs. outgoing as you may find that where you thought the bottleneck exists is actually somewhere else in the system.

Any other ideas?

[Nick Parker]

It seems like a way to bring production leveling to software is to target deliveries in vertical slices, minimizing extraneous amounts of time spent focused too heavily in one particular area of a codebase.

This approach would allow teams to make adjustments yet minimizing overheard.

--
Nick Parker

[Tim Andersen]

I recently saw an announcement on the XP mailing list about a new eBook that intends to be like "The Goal", but set in software development. I haven't read it yet, but here is the link:

http://www.rollingrocksdownhill.com

[Moreland, Bridgett]

Know it’s been a while on this. Just wanted to update on the Rolling Rocks Downhill read. (Thanks, Tim, for the link.)The author has it as a free download now through amazon. Despite the ‘Beta’ version with the misspellings and plot deficiencies, it’s not a bad read.

 

http://www.amazon.com/Rolling-Rocks-Downhill-BETA-ebook/dp/B007QRUQU4/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1340734485&sr=1-1&keywords=rolling+rocks+downhill

[Marianne Tromp]

I have not read "The Goal." However I enjoyed reading Goldratt's "The Critical Chain" which focuses on Project Management. That was my introduction to the Theory of Constraints. I plan to re-read that book after I unpack from my move. I enjoyed the context of using a novel to teach the theory of constraints principles.

Marianne Tromp