Complicated vs Complex Problem Solving


Do you know the difference between Complicated and Complex problems?

Earlier this week I was revisiting one of my absolute favorite books: Team of Teams: New Rules of Engagement for a Complex World. Excellent book, I encourage you to consider giving it a look if you are interested in modern scaling teams theory and/or how organizations are changing to be effective in a complex and fast-moving world via expanding trust, transparency, agility, and resilience within the organization.

One of the key concepts of the book that resonates with me is the difference between Complicated and Complex problems. I know I have used those two words interchangeably many times, but there is a significant difference in how to attack each type of problem.  If you treat a complex problem like a complicated problem, you are setting up yourself and your company for failure.

Complicated problems

Difficult problems/situations that can be separated and dealt with in a systematic/logical way, relying on static rules or algorithms.  I think of the popular ‘Divide and Conquer’ approach in this space where you break a large system into its smaller subsystems and solve for the pieces to tackle the larger problem.  There is a sense of predictability that can be gained.  Once you figure out how to solve a specific complicated problem, that solution can be used at will for problems of the same type in the future.

Examples: Building rockets, coding a tax calculation engine, repairing a furnace, etc.

  • Difficult, but can be broken down into dependent steps/etc.

Complex problems

Difficult problems/situations that you can’t get a firm handle on the parts and there is a lack of rules/algorithms, predictability.  These are more challenging and different than the sum of its parts thinking, because its parts interact in unpredictable ways.  You might figure these out once, but whatever you did won’t likely generate the same result next time.  Think of the Butterfly effect here.

Examples: Forecasting the weather four weeks out, predicting new product segment success, etc.

  • Highly interdependent, exponential outcomes based situations.
  • According to this article in Inc, integrating two merging companies is included here.

Best Practices to Consider

The Inc article suggests the following considerations:

1) Understand and appreciate the differences between complexity thinking and complicated thinking

  • Both involve different mindsets, different expectations, different tolerances of ambiguity.  Both require dramatically different management techniques

2) Become comfortable with Complexity

  • Complexity thinking is intuitive, simple, and often requires an open mind plus basic common sense.
  • Ask yourself, is this problem complicated (can be broken down into subparts), or Complex (part interactions wildly affect results to where it’s difficult at best to predict)

3) Think “Manage not Solve” when confronted with Complex issues

  • Manage effort with a playbook of broad principles (Guidelines), rather than rule books
  • Use Inspect, Adapt problem solving efforts with tight feedback loops to allow for quick turns/modifications.


In short: In complex situations, embrace that change and uncertainty are inevitable, allow for team flexibility to adjust often via a default=trust culture, vs a default=control culture.

If you got to this point in the post, thanks for reading!

Agree/Disagree with the above thoughts?  I would love to hear your thoughts/experiences in this space.  Ping me and let’s talk!

Want to make a lasting impact? Focus on bringing people together


Just a little over a year ago, Aaron Orr (J. J. Keller Developer at the time) passed away suddenly.  As the anniversary of Aaron’s passing approached, I found myself thinking about Aaron and the times I and others shared with him.  Many smiles/laughs and even a few tears for me during this time.

One really cool thing that came out of this reminiscing was a realization that Aaron still inspires me, even today!   When I asked myself why (something I do often to find root causes of thoughts/etc) I noticed Aaron was a master at bringing groups of people together.  He loved getting small groups of people together for lunch, organizing a Tough Mudder team including weekly training runs, annual ski trips to Granite Peak, weekly Ultimate Frisbee games at the local park in the summer, even late evening Halo/DayZ/League video gaming sessions.  Certainly Aaron’s playful personality was at the center of many of these events but in hindsight, I believe he loved feeling part of a team… if it was our Dev team as a whole, the ski group within it, etc.

What to make a lasting impact? Organize a group outing/event!

Take the extra time to organize a group outing/event that you enjoy doing. Many people will attend these events, but only a select few will take the time to organize the event as well as do the simple (but effective) 1on1 influencing (arm twisting?) needed to ensure a good turnout.

The reward for your efforts: A memorable time with friends/coworkers.  Thanks from those that attended, for your organizational efforts.  The start/continuation of a culture of team/family.  A lasting impact on the group… with stories to tell from the event, jokes to share related to little mishaps/etc that happened during the event, etc.

Take the time to attend group events and engage

Want to get to know more people?  What to expand your circle of influence? Want to be part of something bigger than yourself?  Take the time to attend group events and when attending, fully engage with the group.   Lasting relationships happen when you engage, while attending is necessary to even have a chance to engage!

Bring people together

Whether you organize an event or attend events others organize, take the time to focus on bringing people together.  Even if it makes you a bit uncomfortable, you won’t regret it and I guarantee you will be making a lasting impact like Aaron did, reaching far beyond his physical presence.

Thank you Aaron for helping teach me such a valuable lesson.  If you were here today, I would ask you to stand up and take a bow!

Note: Main article picture is the group of J. J. Keller Developers that got together for lunch to celebrate Aaron’s impact on us all on the first anniversary of his passing.  Qdoba was Aaron’s favorite lunch get together place.  Thanks John and Cody for organizing the lunch event!

Risk, Information, Time and Money–Lean Startup Conn Notes

By far, the session I received the most value from during the Screenshot 2013-12-09 14.25.11morning talks of the Lean Startup conference day 1 agenda was Dan Milstein’s (from HUT 8 Labs) Risk, Information, Time and Money talk.

Dan started out by restating the definition of a startup per Eric Ries:  “a human institution designed to create a new  product or service under conditions of extreme uncertainty’”.  We are talking about established product lines well along the maturity scale.



Though I believe the walk down the logic tree Dan put together in his session is valuable… as I wrote it up it got fairly long.  The walk is outlined below, but here is the TL;DR version:

-) In the presence of extreme uncertainty, you make money by extracting information from reality.

-) The most valuable information is that which reduces uncertainty about the largest in a chain of risks.

-) To acquire information quickly, the whole team must constantly adjust its understanding of risks.

Opportunity Cost

You know… what money you are not making by working on certain things instead of alternatives.    He gave the following example:

Which would you chose (assume you have the skills to do each):

1) Build customer graphics at a rate of $200 p/h.  Assume only 4 hours a day of work for a week (5 days).

2) Build a customer website at a rate of $20 p/h.  Assume there is enough work to keep yourself busy 8 hours a day for a week.


When he spoke these, it looked to be a straight math problem to me.


Screenshot 2013-12-09 14.27.02


Screenshot 2013-12-09 14.27.16

So in this example… it certainly demonstrates that choice #2, though keeping you busy all day, is not the most profitable choice.  (Da… it gets better)  It actually costs you $640 p/day per person.

Sometimes people/companies get lucky… the ‘right’ work comes their way and the flip of the coin works out for them.  Even in those situations, what are we talking about, getting the choice right 50% of the time?  That is still, on average,  a cost of $320 p/day.


If working hard, and/or luck doesn’t determine success/failure, what does? Identifying when you are working on wrong things is key.  Make sure you are working on the most valuable thing!

The choice of what you work on is critical to success.  It’s not how hard (or busy) you work, or how lucky you are, but instead it’s ensuring you are working on the right (or conversely NOT the wrong) stuff.

Dan goes on to state the these kinds of bad choices (opportunity cost wise) are happening all the time.   He goes as far as to say: “if you aren’t sure you are working on the right thing, STOP working”  You should be terrified of working on the wrong thing.

Information and Money

At this point, Dan poses the question most (including me) have on their mind given the above example:   Well, what if the customer requesting work doesn’t provide (hides) the rate of pay for an activity?  How do you choose then?  Dan says in this situation, Spend a week investigating both opportunities.  That week of investigation makes us money!  It leads to making the decision with proper context.

Taking the time to gather the proper context information before making a choice on where you spend your time makes you money!  (Even though it feels like you are losing money because you are not ‘working’.)

Information = Money

Risk and Information

So..  if gathering information = money….  What about the relationship of Risk and Information?


Consider these possible startup choices:

1) Build a teleportation device

2) Build a CRUD app for an insurance company


To lower the risk of the startup, what should you do in the first month for each of the above?

1A)  Attempt to ‘pre-sell’ 20 teleportation devices.

1B)  Attempt to build a workable teleportation device.


How about the first month of scenario 2?

2A) Attempt to pre-sell 20 copies of the CRUD app to insurance companies

2B) Build the CRUD app


In first month, I think we all would agree to reduce risk, attempting to build a teleportation device is a better choice than preselling a teleportation device.  I also think we would agree attempting to pre-sell the CRUD app during the companies first month is more important than attempting to build it (a fairly straight forward task).

The question is why do we intuitively know the above?   Answer: Degree of Surprise

Degree of surprise is the measurement of surprise you get in what you find out from an experiment.  We only get information when we can be surprised (or when we don’t know the outcome already) Information = Surprise

A startup is an information gathering entity.  We only get information when there is uncertainty and risk.  Demonstrated via the Degree of Surprise factor. This needs to be thought about when choosing where to spend peoples time.


Information and Time

In a startup, the primary source of money is information.  You should be searching out information that demonstrates a Degree of surprise factor.  Ok.   What about Time… how does that play in the picture?


Examples of ways to measure things related to time:

-) For physically moving items: Velocity = distance/time

-) For business: Revenue = money/time

For a startup, Information = Money… therefore Revenue = Information/Time.  The more quickly you gather the best information… the greater the chance of increased Revenue.

Risk, Information and Time

Very often, you get the most/best information by going after your biggest risk items. (They would likely produce the most degree of surprise.)   Many times, the things you have to do to get the most information change over time.

Walking the logic tree outlined throughout this post…. If your biggest risks change over time, and risky items yield the most information, andScreenshot 2013-12-09 14.42.22 information = money, How fast people respond to changing risks is directly proportional to how well the company can make money.


Fear / Vision

For the leaders out there, Dan states that a startup is really a chain of risks that need to be managed.  Many leaders (he referred to them as CEO’s) actually call this their ‘vision’ as they don’t have a real tight grasp on them.    Many times these leaders don’t articulate their fears (the chain of risks that need to be managed) and the company will have problems as those risks are the exact ones it should be attempting to test and extract information from… in the end yielding the revenue the company needs to at minimum, sustain itself.


Managing a startup is really managing a chain of risks. Don’t keep those risks to yourself, but instead test them to yield the information your company needs to be successful.

2013 Lean Startup Conference Livestream

Though I had considered many times attending the Lean Startup Conference in San Francisco (12.9-11, 2013) over the past weeks, I was fortunate enough to find a Green Bay LiveStream host (thanks @rdkhatch for organizing) which allowed me to check out the conference virtually before spending a large amount of money on travel/hotel/etc. LeanStartupInRoomPic

I plan to share info I picked up from the screencast sessions over the next few posts. I am not going to spend a ton of time attempting to define Lean Startup terms/etc with these note posts. I do expect to come back and do a few introductory posts on Lean Startup methods in the near future where those totally new to the topic can get themselves up to speed.

Eric Ries, the author of The Lean Startup book and host of the conference kicked off the day.

Eric states the lean startup looks very strong vanity metrics wise. He says there are lots of people jumping on the bandwagon now. It’s been two years since his book was released and five years of practicing the principles for him.

The question is, how are we doing as a Lean Startup community? Are we sharing/talking about the right things?

Lean startup: are we creating a new general theory of management? (Joke here about why talking about management… that’s not cool stuff!)

Remember: a startup is a human institution under uncertainty. Traditional management practices of planning, forecasting, and tracking progress to plan just doesn’t work in times of increasing uncertainty.

There are lots of ‘bumper sticker’ motto’s coming out of Lean Startup talks/etc. ‘Get out of the building’, ‘market disruption’, etc. That’s not the focus of this conference.  It’s more than bumper stickers and buzzwords. It’s about the important stuff… the hard stuff…. Topics like:

  • If an single employee in the company has an idea regarding how to innovate, or possibly improve efficiency, how does that idea percolate? Get implemented? Maybe even tested to see how it does?
  • What is the process to get idea’s tested to see if they matter, make an impact?
  • How do we simplify… ensure we are not overdesigning a product. (Example here of a microwave with 27 special action buttons… how many do you really use? 3? 4? Those other 20+ buttons took valuable time to build, test, etc… What a waste!)
  • Who’s fault is it when we over engineer products? (like the microwave example above) It’s really nobody’s fault, the system failed and wasted peoples time and also potential.
  • Do we have a routine and regular process to test and discover the ‘honest to god’ truth of whether it’s really going to make a difference or not?


More notes to come…

Hello World 2.0

The new is now up and running.  After many failed attempts to transfer the content I blogged at via various WordPress tools, I finally broke down and manually copied each post.   Side effect of this manual transfer is a lack of comments posted to the original blog posts.  leanstartupBook


I am excited to start blogging again and plan to focus many of my posts on The Lean Startup book/movement.  I have read and reread the book multiple times over the past 18 months.  I get inspired each time I read it. I have also read a number of other Lean Startup series books, and experimented with many of the recommendations/techniques shared both in the books as well as via Lean Startup based blog posts.


Now it’s time to start sharing my thoughts related to The Lean Startup as well as other topics I am passionate about like Agile, Scrum, Mobile Development/etc.


Stay tuned…

Red Pill / Blue Pill Scrum

Recently, a colleague sent me a link to a Agile Finland Seminar; Jim Coplien: Ten things that Scrum teams almost always do wrong . The talk is about 2 hours long, stuffed with excellent information, even if Coplien’s presentation style is a bit more laid back than I prefer. In it, he references that he does ‘Red Pill Scrum’ as opposed to ‘Blue Pill Scrum’.

Being an avid Matrix movie fan, I couldn’t help but think of Morpheus’s epic speech to Neo regarding if he wanted to know the ‘true’ meaning of the Matrix or not. If you have seen the movie, you know what I am talking about. Neo chose the Red pill… and the reality it lead to was certainly a game changer!

Coplien states Blue Pill Scrum is defined as simply passing the Nokia test (team focus). For many Scrum teams, ‘simply’ passing this test is difficult enough. (By the way, like the article states, many don’t even pass the Iterative Development part of the test!)

Red pill Scrum also integrates management and enterprise usage of Scrum from top to bottom.

Coplien states blue pill will give you 10% – 20% improvement. Red pill yields one to two orders of magnitude performance improvement.

I personally feel that organizations that are just starting to adopt Agile/Scrum need to experience team success to gain momentum and ‘social proof’ for other teams to see. Once that has been successfully done, moving to enterprise Scrum usage makes sense and the cross department synergy that will result will certainly yield crazy good organizational performance improvement.

I highly recommend giving the video seminar a view. Jim Coplien is one of the founders and proponents of Agile software development. He works closely with Ken Schwaber, Jeff Sutherland, David Starr and others to facilitate Scrum’s evolution as formalized in the Scrum Guide.

Agile Planning: Planning Session Timing

Once your team has decided to go forward with Group planning and estimating (and may have even decided to try Planning Poker as a estimation technique), often the next question is: “How much time should I expect a planning session to take?”


Best Practice: Time box 1-2 hours of planning per week in Sprint

tbA common rule of thumb quoted all over the internet is to time box sprint planning to 1-2 hours per week in the sprint.  So expect 2-4 hours for a two week sprint, 4-8 hours for a four week sprint.  In my experience, I have found that this amount of time is more than enough as long as your team has some experience with group planning.  If your team is new to group planning (or a majority of your team is new to it), expect to add an additional hour or two just to allow for learning discussions to take their course.  Expect 3-5 sprints to allow new team members to really get the hang of sprinting and the planning process that goes with it.

To some, 2-4 hours of planning time, an additional hour for a Retrospective, and also an hour for Review/Demo, seems like a lot to allocate for each team member every two weeks (assuming two weeks sprints).  In essence, you have a full day of ‘Meetings’ for the team.  My experience has been that the team can feel that this is a lot, but it really does pay off over the two week sprint, by ensuring all team members have a good understanding of all tasks and has participated in ensuring any unique knowledge a specific team member has about a task is shared and included in the estimation process.  This also allows for the knowledge sharing necessary to allow team members to pick their tasks off the task board as the sprint progresses, allowing for a team ‘to do’ task board instead of a number of personal ‘to do’ queues.


Best Practice: Start your Sprints on Tuesday, Wednesday, or Thursday

CalOne other important thing to consider: Attempt to start your sprint, and therefore your planning sessions, on a day other than the start or end of the week (Mon/Fri).  There is a natural build up to the end of a sprint, and it’s just not fun to end a sprint on a Friday or Monday given the weekend in between.  This also takes into account that often team members will extend their weekend by taking a vacation day on these edge days and might miss a planning meeting more often.  Teams I participate on have started sprints on Tuesday, Wednesday, or Thursday and have found those days have worked well.

Next in this series: Bugs/Defects: How they fit into the process.

Agile Planning: Micro-manage… Yourself!

MicroMIn my last post, I talked about the importance of tracking Remaining Work Hours instead of Completed Hours and some of the reasons why this can work for your team.  Because of the relatively short nature of a Sprint (usually 2-4 weeks), one might think it’s not important to update the Remaining Work hours on their individual tasks, but instead just set the task to ‘in progress’ when work starts on them, and when completed, remove the Remaining Work hours and set to done.  Truth be told, many times this would be just fine.  It might make the Sprint burn down chart a bit more ‘up and down’, but the work would get done just fine.

I strongly encourage teams I work with to update the Remaining Work hours at least once a day on any active tasks.  Some have accused me of attempting to ‘Micro-Manage’ the team by this request.  I simply say to them now: “You can micro-manage yourself if you want, this request is for the benefit of the team, not me.”  By updating the Remaining work hours daily, the whole team has a better picture of how all tasks are progressing, and it allows the team as a whole to quickly identify possible time line issues and adjust to the ebbs and flows of all development work.

The one big caveat that goes with asking the team to update their Remaining work hours daily, is the time entry mechanism has to be simple, fast, and readily available. If it takes more than 30 seconds to update this metric, it simply will not get done consistently.

Though I understand why Remaining work hour entry time (tool wise) can be a barrier to getting it entered, I believe the majority of the time Remaining Work hours don’t get updated daily has to do more with the thinking necessary to attempt to truthfully estimate what is left at the time of updating.  Though that can be challenging, it’s worth the effort to checkpoint yourself each day given the new info (or lack there of) you are exposed to.  Also, doing this checkpoint daily will get quicker and quicker as time goes on given the amount of practice you will get doing it.

Next in this series: Best Sprint start days and how long you should expect (on average) a sprint planning session to take.

Agile Planning: Remaining Work Hours > Completed Work Hours

80DoneTeams I Scrum Master do not track completed hours.  Remaining work hours are the ticket.  That is where the real information is held.  This is not an easy transition for the Project Manager in all of us.  Even for the team members, many of whom have been asked to track completed work hours for years and years, it can be difficult to give up the mentality of reducing a bank of hours predefined prior to the task starting. 

So you ask: by tracking completed hours, don’t you simply subtract the completed hours from the original estimate and then you have Remaining work hours anyway?  No.  The only way that would be true is if all the original estimates were perfect from the start.  That simply isn’t true, and contrary to Agile thinking where you expect change, embrace it actually. 

Statements like “I am 80% done” go away.  Any experienced Project Manager will cringe at the sound of that statement as we all know the PM truism that it’s that last 20% that seems to take longer than that first 80% reportedly done did.  The remaining hours are all you hear about and doesn’t that really tell the story you want to know anyway, mainly: how long until the work is done?

A big question I have heard regarding this switch is: “If we don’t track actual hours, how do we ever know if our estimates are getting better?”  Scrum’s answer: the Velocity metric will take care of that.   It really isn’t about being ultra accurate estimation wise, but instead it’s more about sizing tasks well to allow for achievable Sprint goals when picking tasks to commit to for the upcoming sprint.  Tracking actual completed work hours does not directly help with that goal what so ever.

When the team switches to reporting just Remaining work hours, they also need to switch their mentality to one that has them reevaluating how much work is left on the task at least once a day and updating the task to reflect this info.  It’s important to stress that the tally can go up… it’s not a number to decrement only (an old habit of completed hours reporting that can be hard to break).

Next up in this series, the importance of making it E-A-S-Y for the team to update Remaining work hours at any time.

Agile Planning: Have To See What You Plan

cardsFor both Sprint planning, and Product planning, teams I have been part of have found that being able to see (visually) the backlog is very important. 

If you are using good old fashion index cards/post-its to record your User Stories and tasks, or using a electronic tool to keep track of them (maybe you have a distributed team), all team members need to be able to see the Sprint / Product backlog and should be able to look at each anytime. I would go one step further and say that you also need to be able to visually order items in addition to being able to see them.

Providing the ability to the Product Owner to visually prioritize User Stories is a must in my opinion.

To do this, all User Stories need to be easily viewed, side by side.  Teams I have been part of have used software to track our User Stories and Tasks because we have some team members that are not at the same site as all other team members.  We have tried to have the P.O. prioritize User Stories without a visual tool, and it simply requires too much memorization to do efficiently/effectively.  Once we implemented a tool that allowed the P.O. to see all items on screen, next to each other, as well as drag and drop them to quickly prioritize, the process became much more streamlined and we were able to focus on the tradeoffs between User Stories instead of trying to remember what we set to what priority previously.

The Team needs to be able to visually see the backlog to be able to efficiently prepare for Sprint Planning.

blThis point is more a call to ensure that all team members have access to look at the backlog at their convenience.  This empowers them to be able to prepare for upcoming planning meetings, as well as get a overall feel for what the P.O. currently feels are important User Stories to tackle in upcoming sprints.  I add the ‘visual’ part to this statement for similar reasons as the P.O.’s need.  Being able to see work items side by side is powerful from a relationship basis.

It’s imperative for the team to be able to see all User Stories while executing Sprint planning.

The team members need to see all User Stories side by side when committing to individual User Stories for the Sprint.  If the team isn’t allowed a full view of choices, they will have difficulties choosing the best stories to commit to given the Sprint goals.  Certainly the highest priority User Stories will be shown first, but those aren’t always the stories the team chooses to implement (for a number of reasons outside the scope of this post). 

Next up in this series, the importance of tracking Remaining Work Hours as opposed to completed hours.