Optimize the Whole

I know we talk about self-organized and empowered teams being at the heart of agile practices.  But sometime I see that focus from individuals and teams going a little too far.  Sometimes people forget about the big picture.  I believe everything we do needs to map back to organizational visions and goals.  If you can't do that, what you are doing is wasteful.  For some organizations, everything needs to map back to increasing profits or lowering costs.  But we have to be careful not to fall into the "local optimum" trap.

A local optimum of a combinatorial optimization problem is a solution that is optimal (either maximal or minimal) within a neighboring set of solutions. This is in contrast to a global optimum, which is the optimal solution among all possible solutions. (Thank you Wikipedia)

You can read more about local optimums in the late Eli Goldratt's book, The Goal.  To the layman, you should consider activities and efforts that will benefit the organization or process flow as a whole, not necessarily what is best for you or your team.  I know it sounds counter-intuitive but hear me out.

You've probably seen this local optimum in action in one way or the other.  If you have a process flow, it's happened.  With a traditional waterfall application development flow, have you ever had a development team deliver features without any concern of the impact to their QA counterparts or others downstream in the process?  The release is dependent on the other teams but what do they care?  They were very efficient at getting their work done.

Have you ever had that boss who was utterly obsessed with keeping everyone "100%" busy rather then being focused on ensuring the greatest amount of value flowed through the system in the shortest possible time?  Both instances are bringing attention to practices that happen and we just accept them.  One example is focusing too much on the localized efficiency. The other focuses too much on utilization.

My Freeway Analogy

When I get on the freeway, I don't care that I can go the speed limit for 5 miles out of my 50 mile commute (localized efficiency).  I really don't care how many cars the freeway can hold (utilization).  What I care about is that I can go as fast as I can for my overall commute.  That should be the goal.

I'll close with one of my favorite quotes by Eli Goldratt

A system of local optimums is not an optimum system at all

I'm curious if others out there can give me some more examples of local optimums and how they addressed them.  How did you optimize the whole?

Image Source: Awesome DC

Organizing Around Teams

Several years ago, I was working with a client who was obsessed with keeping resources (in this case, people) 100 percent utilized. The client boasted that he had a strong matrixed organizational structure and everyone was a member of multiple teams working on multiple projects. When I came on board, I noticed that people were spread extremely thin between the projects. There was a lot of work being performed but very little was getting done. How can you make real progress if you have multiple managers asking you to deliver that high priority something for them? How can you make real progress if you have to constantly shift gears and go in different directions? In theory, having a matrixed organization sounds really great. Resources can potentially be utilized up to 100 percent. In reality, the goal is not utilization of a resource. The goal is throughput and delivering something of value. In the end, having a matrixed organization made people busy but it did not make them more productive. Perhaps managers felt more productive because they essentially had more people to manage. But again let me stress, the goal is not to manage people. The goal is to deliver something of value. When I did my original assessment, there were two common complaints. First, team members didn't know who to take direction from. Two, team members never seemed to have time to just focus on one thing and get it completely done.

Status quo organizes teams around projects

• Projects are initiated
• We beg, borrow and steal, looking for the right people to work the project
• We pull a few hours from here and a few hours from there
• Everyone is "fully utilized" by working on several projects at the same time
• When the project is completed, we release some portion of each person’s hours back into the pool and start again
• Endless resource-management frustration

Bring the right projects to the right teams

• Teams focus on one or two projects at a time and get them done quickly
• Management prioritizes projects and queues them up for the appropriate teams
• May need to move a few people around but hopefully not many and not constantly
• Much of the resource management problem goes away
• We also get fewer simultaneous projects, more focus, and more speed of delivery

Once we got people grouped into several (cross-functional) teams and then collocated in team areas, we actually started making deliveries on projects. The PMI would define this reorganization as being projectized. But, let us not forget that this is about the teams and creating an environment in which they can deliver value.

Organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.

Socratic Questioning

After reading the book The Goal: A Process of Ongoing Improvement by Eliyahu Goldratt, I found myself wanting to learn more about two things.  One, something known as the theory of constraints (TOC).  Two, the Socratic method or using Socratic questioning.  I'll leave TOC for another post.  This time around, I'll focus on Socratic questioning.  I started asking my client's vendor a series of Socratic questions, with some surprising results.   But first, what is Socratic Questioning?  From our old friend Wikipedia:

Socratic questioning is disciplined questioning that can be used to pursue thought in many directions and for many purposes, including: to explore complex ideas, to get to the truth of things, to open up issues and problems, to uncover assumptions, to analyze concepts, to distinguish what we know from what we don't know, and to follow out logical implications of thought.

The key to distinguishing Socratic questioning from questioning per se is that Socratic questioning is systematic, disciplined, and deep, and usually focuses on foundational concepts, principles, theories, issues, or problems.

Using my client's vendor as a guinea pig, I decided to give this a go.  Rather than just accepting what appeared to be a half-baked answers, I started to ask more of the same questions.

I asked questions like

• What do you mean by that?
• Could you help me understand this a little more?
• Is this always the case?
• Why do you think that this assumption is true in this case?
• Why do you say that?
• What is there reason to doubt the supporting data?
• What is the counter argument for this?
• What is another way of looking at this?
• But if that happened, what else would happen?
• How does this affect that?

Though I've always asked a lot of questions, I've never tried to be so systematic or disciplined in the process.  I'm frustrating the hell out of the vendor with all of the open ended questions.  But I think the client is getting better answers.  I hate to see someone ask a complicated question, only to get a yes or no answer.  I want to understand why someone is doing what they are doing.  Hopefully, by asking these types questions, the vendor will start to wonder why as well.

Have you used Socratic questioning before?  What was your outcome?

Book link to Amazon is an affiliate link. Original Drawing by Pictofigo