Dennis Stevens - Theory of Constraints and Big Agile

Here's a great article I found on CCPM and Agile. Its a bit short.... and I still have read The Goal...but I think there's alot of synergy between agile and CCPM.
--


Dennis Stevens -  Theory of Constraints and Big Agile

Theory of Constraints and Big Agile

By Dennis Stevens

In 1984, Eli Goldratt first published The Goal: A process of ongoing improvement. The book describes the Theory of Constraints, a method for managing systems. It is based on the concept that at any time in a system there is one (of very few) bottleneck(s) slowing down the performance of the system. Performance is measured based on three variables. Throughput measures the units delivered to the consumer of the system. Operating expense is investment into the system to ensure its operation on an ongoing basis. Inventory is investment into the system to produce.
The Goal is to make more money now and in the future in order to meet the expectation of stakeholders and ensure the business continues to operate. You increase profit by combinations of increasing throughput while decreasing the ratios of operating expense and inventory against throughput. A key first step to accomplish this is to reduce inventory – or work in process. This will improve cash flow of the organization. Reducing WIP has the added benefit of exposing the bottlenecks in the system. Exposing these bottlenecks is the key to implementing POOGI (Process Of OnGoing Improvement). Goldratt provides five focusing steps to follow to help achieve the goal.
Five Focusing Steps
Identify the limited number of current constraints: At any point, there is a single point in the system that is the current bottleneck. For example in Agile development teams, it may developer productivity or a testing person. The way that you will identify the constraint is that it is the person where work is piling up in front of them and where downstream resources are starved for work. In the figure below the constraint is B. Work can only get through B at 3 units per unit of time. Since A is more productive work will pile up in front of B and C will be starved for work.

Two important concepts need to be presented here. The first is that the team of ABC can’t produce work any faster than the bottleneck, B. So the consumer is only receiving 3 per unit of time. The second really important concept is that A, B, and C don’t have to be different people, they can be state transitions of a piece of work. In an Agile team, A might be understanding the requirements, B might be develop and unit test the code, and C might be integrate and acceptance test. On an Agile team, everyone is involved in all the states, it is the work that is moving through various states.
Make sure output from the constraint is not compromised. The second step in the five focusing steps is to recognize that the work done at the bottleneck is precious and must be exploited. So focus on making sure that none of B’s work is wasted. In our Agile example that means improving the quality of how work is communicated in the transition from A to B. It also means focusing on quality at B so that C is able to use everything produced by B. Doing this step will result in improved performance of the system.
Subordinate the system to the bottleneck. This means slow down the work at A. While this might seem counter-intuitive B can’t work any faster than it can work. Often, manager’s focus on improving utilization rather than throughput and this focus actually exacerbates the problems. Producing more and more inputs to B creates stress on the people in the system, makes the system more difficult to manage, and increases the likelihood of waste at B. In our Agile example, A can spend more time clearly communicating what needs to be built and less time producing more detailed stories. A may consist of meetings where stories are communicated, estimated, and prioritized. On our Agile team, it is consuming time from the team that could be spent at A. So do less detailed estimating and prioritizing in each cycle. The effort is better spent at B.
Elevate the constraint. In many organizations, when the effort is to elevate performance of a system (or team) investment is made to elevate the entire team. In our example above, that may mean adding more subject matter expert resources as well as more testing resources. But the only benefit to improving throughput of the team in our example is to increase at B. Elevating the constraint can happen through improving the capabilities at B or shifting more manpower to B. In our Agile example above, it may be better to shift one of the testing people to focus on development. Even if they are initially not as productive as the top developers, they will contribute to elevating the constraint without damaging the throughput of the team.
After the system has stabilized go back to the beginning and identify the constraint. The final step is really to not let inertia become the constraint. Remember, this is POOGI – a Process Of OnGoing Improvement. You don’t go through the process once – you go through it continually.
Theory of Constraints and Big Agile
This model is very interesting because if provides a thinking process for focusing efforts on the next most important problem. If our Agile team example above, if this model is not kept in mind by the team, they may spend time putting in a cool new CI environment – but unless that environment raises the constraint at B it will not result in an improvement. So it isn’t the next best place to focus. The other interesting thing about this model is that it scales up through the organization through the orders of scaling. If you haven’t read The Goal and Goldratt’s other writings you need to get this model into your thinking toolkit.

Dennis Stevens � Blog Archive � Theory of Constraints and Big Agile

Here's a great article I found on CCPM and Agile. Its a bit short.... and I still have read The Goal...but I think there's alot of synergy between agile and CCPM.
--


Dennis Stevens � Blog Archive � Theory of Constraints and Big Agile

Theory of Constraints and Big Agile

By Dennis Stevens

In 1984, Eli Goldratt first published The Goal: A process of ongoing improvement. The book describes the Theory of Constraints, a method for managing systems. It is based on the concept that at any time in a system there is one (of very few) bottleneck(s) slowing down the performance of the system. Performance is measured based on three variables. Throughput measures the units delivered to the consumer of the system. Operating expense is investment into the system to ensure its operation on an ongoing basis. Inventory is investment into the system to produce.

The Goal is to make more money now and in the future in order to meet the expectation of stakeholders and ensure the business continues to operate. You increase profit by combinations of increasing throughput while decreasing the ratios of operating expense and inventory against throughput. A key first step to accomplish this is to reduce inventory – or work in process. This will improve cash flow of the organization. Reducing WIP has the added benefit of exposing the bottlenecks in the system. Exposing these bottlenecks is the key to implementing POOGI (Process Of OnGoing Improvement). Goldratt provides five focusing steps to follow to help achieve the goal.

Five Focusing Steps

Identify the limited number of current constraints: At any point, there is a single point in the system that is the current bottleneck. For example in Agile development teams, it may developer productivity or a testing person. The way that you will identify the constraint is that it is the person where work is piling up in front of them and where downstream resources are starved for work. In the figure below the constraint is B. Work can only get through B at 3 units per unit of time. Since A is more productive work will pile up in front of B and C will be starved for work.

Two important concepts need to be presented here. The first is that the team of ABC can’t produce work any faster than the bottleneck, B. So the consumer is only receiving 3 per unit of time. The second really important concept is that A, B, and C don’t have to be different people, they can be state transitions of a piece of work. In an Agile team, A might be understanding the requirements, B might be develop and unit test the code, and C might be integrate and acceptance test. On an Agile team, everyone is involved in all the states, it is the work that is moving through various states.

Make sure output from the constraint is not compromised. The second step in the five focusing steps is to recognize that the work done at the bottleneck is precious and must be exploited. So focus on making sure that none of B’s work is wasted. In our Agile example that means improving the quality of how work is communicated in the transition from A to B. It also means focusing on quality at B so that C is able to use everything produced by B. Doing this step will result in improved performance of the system.

Subordinate the system to the bottleneck. This means slow down the work at A. While this might seem counter-intuitive B can’t work any faster than it can work. Often, manager’s focus on improving utilization rather than throughput and this focus actually exacerbates the problems. Producing more and more inputs to B creates stress on the people in the system, makes the system more difficult to manage, and increases the likelihood of waste at B. In our Agile example, A can spend more time clearly communicating what needs to be built and less time producing more detailed stories. A may consist of meetings where stories are communicated, estimated, and prioritized. On our Agile team, it is consuming time from the team that could be spent at A. So do less detailed estimating and prioritizing in each cycle. The effort is better spent at B.

Elevate the constraint. In many organizations, when the effort is to elevate performance of a system (or team) investment is made to elevate the entire team. In our example above, that may mean adding more subject matter expert resources as well as more testing resources. But the only benefit to improving throughput of the team in our example is to increase at B. Elevating the constraint can happen through improving the capabilities at B or shifting more manpower to B. In our Agile example above, it may be better to shift one of the testing people to focus on development. Even if they are initially not as productive as the top developers, they will contribute to elevating the constraint without damaging the throughput of the team.

After the system has stabilized go back to the beginning and identify the constraint. The final step is really to not let inertia become the constraint. Remember, this is POOGI – a Process Of OnGoing Improvement. You don’t go through the process once – you go through it continually.

Theory of Constraints and Big Agile

This model is very interesting because if provides a thinking process for focusing efforts on the next most important problem. If our Agile team example above, if this model is not kept in mind by the team, they may spend time putting in a cool new CI environment – but unless that environment raises the constraint at B it will not result in an improvement. So it isn’t the next best place to focus. The other interesting thing about this model is that it scales up through the organization through the orders of scaling. If you haven’t read The Goal and Goldratt’s other writings you need to get this model into your thinking toolkit.

Making Your Culture Work with Agile, Kanban & Software Craftsmanship

Making Your Culture Work with Agile, Kanban & Software Craftsmanship

An extraordinary article on culture and agile. I'm not sure I totally align with his analysis - I always saw kanban as a hippie version (or libertarian, whichever is less offensive) of agile. "hey dude...limit wip, pull stuff where done with it and we're cool...'? Groovy...."

But I need to do more thinking about it. To me it all boils down to commitment and renewal - how do you generate commitment where this really matters to people, and two, how can you keep renewing those folks so they *continue* to care?

Later duuuuudes.

- joe

Intrinsic Commitment vs. Extrinsic

As I look at my family work board I  find myself wondering - why aren't things like,  "take child to basketball practice" on there?  Are the things that are on this board extrinsic or intrinsic? 

Lets look at this basketball thing.  At some time we in our past we committed to it. What does that mean?

• We committed funds
• We involved other people (the team) in the commitment
• We didn't set the times ( set for us) 
• but we know its good for our children, and we're committed deeply to their well being. 
• Its fun when kids play sports

I'm drawn to that last two.  We can do the first two, but at the end of the day its the heart that matters.  We really want  to do something. we probably don't even need a board for it.

So what's on this board, at least in part, are extraneous things, things that life could probably go on without.  We won't put dinner on there, because we're intrisically motivated to do that thing. The things on the board are elective time items then?  If so, does this make them less important? 

I think not.  I would position it to say that this board is the things we want to do but have force ourselves to set the time for. They make our commitment public, they make it clear.  It forms an information raditor.  And for me I play the game that I "cannot finish this week without clearing that item out."

One piece of leadership literature said, " eat  the big frogs first."  So the things you don't really want to do ," call the bank.."  that's the stuff that goes on there. But Bri already has some art things on there.  So she needs to be held to that commitment by someone else.  Its her own priority rather than one dictated to her by parents or curriculum.

Topgun hasn't gotten in there yet, nor has Julie.  I'll have to push it a bit.  :)

-Joe

The Family Kanban

It was a lovely vacation I just finished with, and while I want to type about that, for this journal I would focus on one big outcome. My family has agreed, amazingly, to be part of an experiment - a bold experiment of bringing agile into my family life with greater energy.

Understand – in our family my wife Julie generally runs things. She’s got the planner, she’s fabulously organized and networked, and does a great job of it. Interjecting myself into this working system is a bit scary for me, and a bit out of my “defined role”.
However, there are a few things that I think I can help with. Agile, and the many roots it has in OD and systemic thinking, finds its specialty in managing goals in environments rich with change, and as any family of almost any constitution can attest, there’s a bunch of change out there. I see the labors Julie has put into planning meals, planning trips, planning schooling, planning events – its staggering.

More than that, I feel that really we’re a team and as they get older (I’ve got one teenager, near to two) they need to take more ownership in the tasks and goals they want to accomplish in their young lives.
And then there’s me. I’m like an uninformed CEO of my family. Julie will run things past me. Usually I nod and agree, or try to say something intelligent about whatever event we’re talking about. We get by, but I do not feel that I’ve really added much value since I don’t have the big or little pictures in my mind. I generally don’t put things on the calendar (google’s calendar has helped), but I certainly have things, and on occasion that will be a source of friction.

For example:
“Hey, can you be home by 5:30? I’ve got book club.”
“Oh…well, I was going to meet Erik at Starbucks…”
Or another…
“Hey, what are we doing this weekend?” Julie asks.
“….” Joe has no response.

Then the space gets filled with other tasks. Eventually I realize I had other things, but I never mentioned them. So to make my role a more active role and to have the whole tribe here see what’s happening and get them to focus on things, I sold to them an experiment. I plan to use Agile and Lean software development techniques to help run the family’s goals and accomplishments.

Notice how I framed that – goals and accomplishments. I do not intend to take from Julie the daily efforts of planning every action in our lives any more than I think she wants to hear about every meeting I go to. One good change technique, perhaps the core change technique, is to simply show the tool, and this tool will be focused on those things above and beyond the daily grind. Or will it? I’m not sure.
Of course, as a good agilest, I have tried some of this already,. I was able to install Retrospectives into my family. We do them every 6 months, and I think they’re starting to enjoy them. It’s difficult work to look back, think about what we’ve done, and think about what we want to do. I sense that it doesn’t come easily to children.

I’ve also had a bunch of sticky notes by the fridge, but they’re wrinkled from age. They’re definitely the epics, and we didn’t manage on the list other than lament the fact that we haven’t done many of them for more than a year. So it lacked commitment.

My kids are cautiously agreeing to this.  When I told topgun, my 12 year old, the full plan (my hopes to make this into a book or at least a talk and a white paper), he got excited. This experiment, as you will see in future posts, has been launched around a whiteboard. Everyone got their own sticky note color, and the board is just two weeks, so really, this is more of a family kanban. Perhaps that’s what I’ll call it.

The journey has started. I intend on doing this for at least 6 months, and will be blogging about it often. I have no idea how to map all this. Is it Kanban, or Scrum? If the later, who is product owner? Are there user stories? Burndowns? Hours? I mean a lot of this won’t apply, right? I’m keenly aware of the differences between managing adult professionals in software and the dynamic of family.

In the end I hope, as I do at work, to add value by leveraging the perspectives of a change agent and in this context, a dad and husband.  :)