Systems Thinking in 'ORGAN'-izations

What is systems thinking?  Systems thinking is the process of understanding how things influence one another within a whole. That definition and many like it are found all around the internet, but do we know what it looks like in action?  I found it confusing in many cases due to these same resources stating that a systems thinking approach is the opposite of breaking a larger system down into its parts to be analyzed and/or improved.  It is my opinion that using a systems thinking approach in an organization is a balance of both.   

I've read a lot about tearing down these functional areas as if they are some kind of barrier standing in the way of a systems approach.  I am going to disagree with this and state that we simply need to work with them differently.  I strongly agree with the need for these teams, but the information within should be openly available to all other teams and the communication paths should be directly available.

In every business we have a product, service, solution, etc... to provide to someone and in many it is important to have expertise organized into functional teams within the organization.  These functional teams need to be in place for organizations to provide important pieces such as expertise, accountability and responsibility.  Building a culture of relating these functional teams to systems that are part of a larger system and promoting collaboration between them is how I would describe getting your organization to a systems thinking approach. 

A systems approach provides many things from efficiencies and cost savings to feedback loops and product improvements.   It can even have a positive influence over morale. 

After recent discussions on systems thinking I was looking for an example of an organization that utilizes a systems approach effectively.  What I realized is that not only is the human body a great example of many things working together for a common goal, but that we study and teach on this subject recognizing each of these parts as systems working together. 

If you were to look up the Human Organism and write down the highlights, you are probably going to write something like skeletal system, muscular system, nervous system, etc...  See the common factor? 

 Now hold that thought and let's look at the human body as we look at our own organizations.

This makes sense to us right?  For the sake of size I left out plenty of boxes, but you get the idea.  From atoms to molecules to organelles  that form cells which form tissue which leads to organs that make up an organ system and results in an organism. 

If the body worked vertically it probably wouldn't function let alone be what it is today.  The body maintains our functional groups that allows for expertise, responsibility and accountability; but still has many interworking systems.    

Referring back to the first image I placed above, you'll notice that when we speak of the functional teams that make up the body, we refer to them as systems. The body has 11 major organ systems as indicated in the org chart above, but what you cannot display in such a standard org chart representing the body is the overlapping of these systems.  Nearly all of the major organs of the major systems have other organs from other systems connected to them.  Notice that I said there are 11 'major' systems.  Choose your belief here, but whether fantastic evolution or a genius creator, the need for interworking systems was obviously not overlooked.  In the chart above I listed some organs that fall under their organ system, but what happens when I ask you where the hypothalamus resides?  It is a gland so let's say its functional area is the endocrine system, but it's function is being responsible for the activities of the autonomic nervous system.  This happens to us everyday right?  Your software developers are not writing software to develop software. 

We've decided that with the org chart of the human body if you will, it needs a system to link the system, hence we have what is known as the neuroendocrine system.  This is found again and again throughout the human body where functional areas overlap.  The muscular and skeletal systems work so closely and are dependent on each other for optimization of movement and support that we have a musculoskeletal system.  Genius right?

The musculoskeletal system is not a whole new functional area of the business with new management, etc...  Consider instead that it is a space where representatives from both systems come to collaborate on their ideas of how to reach the common goal and then returns to their own system.

Aside from not addressing dependencies from multiple functional areas to optimize the outcome, silos cause other issues in the organization.  Regardless what your functional area is, it is better than the others right?  If you are an installation tech, you could meet your goals if development had it together and if you are in development  your product is fine if only your installation guys were smart enough to implement it.  

We've got to tear down these silos and interact.  Every decision made in a functional system is going to change the overall system.  If your change is not matched and/or countered by other changes the result has changed.  What the chart above (silos) doesn't do is help us identify where a problem is or visually instill the idea that what one does has a greater consequence to the common goal.  As an example, let's assume you have hypoglycemia. 

Well, hypoglycemia is a condition that occurs when your blood sugar (glucose) is too low.  Now you have double vision, fast heart, nervous, shaking, sweating, etc...  Each system is reacting.  If you take medicine to rectify the symptoms without understanding the true cause you could damage your pancreas or cause other systems to work harder to counter the new effects while not actually curing the problem. 

Hypoglycemia can be caused by medications or alcohol so it could be the fault of the mouth.  If not the mouth maybe the overall digestive system for not breaking down the carbohydrates or back down in that functional system to the pancreas for not producing insulin.  Maybe it's the blood stream and maybe it's that the liver and/or muscles aren't storing glucose properly.  It very well might be a digestive system problem, but unless we understand how systems overlap you might of just replaced your director of digestion when in fact the problem could of been any one of circulatory, muscular, or endocrine systems. 

Similarly, defects in the muscles and bones can be the result of neurological problems, metabolic or vascular disorders, nutritional imbalances, etc...  If any one of the systems that make up the human body were to over/under produce or change what it does all together, it can drastically change every other system and the overall result of what they were previously working together to do. 

The body has 5 vital organs being the brain, heart, lungs, kidneys, liver, and pancreas.  Scroll up if you need to, but I'll just tell you that the blocks are red and each resides inside of a functional system.  What?!  The brain isn't higher than bones?  All of these systems work together and due to this the information uses the nervous, muscular, circulatory, and other systems to share information where they overlap and transport it to another system it interacts with.  If you were to put your hand on a hot surface the body reacts by sending signals to other parts of the body.  Your muscles contract to pull away, it notifies your brain of the incident, your blood pressure increases while you breath heavier, your pupils dilate, and you start releasing hormones like adrenaline. 

Many systems in the body just worked together to notify, react and rectify and it did so by communicating within interworking systems rather than all information leaving the critical areas and coming back via the same point it went it out.  Good thing or you might just still have your hand on a hot surface waiting for that single point of communication to be available. 

Any living organism is amazing, but remove any one system or even tamper with it without proper communication to the others and if you are still alive, you've just caused cancer. 

To do this an organization needs to instill a culture of collaboration and team building so that the vital organs can work together while the functional manager acts as a servant leader to keep his experts focused, trained, and with the tools they need to do what they do.    

With all of the communication that the body has going on, you can provide it with the right nutrients and not only is it healthy, it becomes self healing when the unknown arises.  Shouldn't your organization be self healing?

ACHIEVING MORE EFFICIENCY WHILE USING AGILE TECHNIQUES

Have you ever wanted to introduce Scrum or any other agile practice for that matter and find that the organization  won't embrace it? Once upon a time I did so I had to ask the question, “Is being agile by applying individual techniques simply enough?”

For a long time I struggled with being an Operations Manager introducing Project Management into a Functional (silo) environment. Originally my core duties were to manage personnel within IT including application development, the help desk, and an infrastructure team.

Many businesses have changed significantly over the past few years with the economy the way it has been. In this case, the number of staff members decreased, current applications and their need for infrastructure remained the same, and the need for new and upgraded applications grew. Simply put, it was a bit chaotic. It is also overlooked that while downsizing there is additional work for the IT staff with security, asset management, and requests from the user community trying to pick up their added duties in their own functional area.

Though the company wanted to “go back to basics” there was an opportunity to introduce agility into this group. Without the business buy-in I won’t claim that they are doing Scrum, but they are now agile while following the Scrum Framework.

Acting as the ScrumMaster I often had to mask some ceremonies with calendar invites and facilitate the meeting according to Scrum so that it appears that the team was working with a Product Owner. Truthfully they were. In each case this person fits the profile of the Product Owner, yet doesn’t claim to have time for an actual process. Since they show up to meetings on their calendar and it appears to them as being my meeting they allow me to facilitate.

Sprint planning meetings become what they are without the title. The Product Owner joins the rest of the team in our open workspace filled with whiteboards marked up as task boards, markers, posters, and index cards with in arms reach no matter where you are. S/He runs through what they and their stakeholders (of course we call them co-workers and customers) need, we turn them into stories, and have them prioritize. After discussions around each of these, work is pulled for the next two weeks and the team is good to go to work.

Meanwhile we have our daily standups and I work to keep the team clear to continue. One more invite to the Product Owner and s/he shows up with their stakeholders to see what the team has created.  When that group gives us feedback and leaves we wrap up with a retrospective and start again. After a few iterations of this the team was solid and department heads were happy to once again be getting what they were looking for.

Now that you have results, do they now want to embrace this? In this companies case no, but as a Scrum Professional I was able to use agile techniques to create efficiency so yes, sometimes it’s enough.

Of course nothing had been upgraded in the past few years and standardization did not exist so my understaffed help desk and infrastructure team were stressed out and overworked. From closing facilities to bandaging computers, servers, and network failures the problems were constant. Ad Hoc requests were coming in and they were simply expected to change gears multiple times in a day.

Since this organization still insisted on being Functional I used that to suggest how our functional area would work going forward. My newly formed team had picked up some of the Scrum Framework from being around it and I brought them up to speed on the particulars. Remember that room with all of the whiteboards, etc…? Well we used one to create a Kanban board and apply Scrum techniques to it.

The team met and starting writing down everything they had been tasked with except for everyday work and trouble tickets. All of this work went up on the board for anyone that wanted to walk in to see.

We assigned complexity to each and since it was our first run out we estimated our capacity for the first Sprint. Using the Director of our functional area as a Product Owner for the business we had him prioritize what needed to be done until there was no more room to add complexity. In this case the team committed to an amount of work and not necessarily the work itself. As the Ad Hoc requests came in the Director maintained the ability to blow up work in progress by making it higher priority even while in the middle of a sprint, but he must then remove an equal or greater amount of complexity points and he answered to the business as to why that product will not be delivered until the next sprint.

This accomplished multiple things. First, it accomplished the original goal which was to make the work visible so that each individual in the business could see that they are not the only ones asking for things from this small team. Second, it relieved the team of the stress from being over their head and improved the quality of their work. Third, it aided in cross training and identifying training opportunities, by allowing them to pull the work rather than being assigned tasks repeatedly.

The Ad Hoc requests continued to come, the requests for an increase in head-count continued to be ignored, and everyone still thinks their need is the company’s highest priority. The difference is that it is no longer on the shoulders of the team. Once again, “being agile” greatly increased efficiency amongst other things while not actually “doing Scrum”.

On the Same Page or In the Same Boat?

What is a ScrumMaster Really?

Are you asking yourself what Scrum is?  Search for it on the Internet and you will find either Rugby references or a bunch of diagrams with arrows or big blocks turning into little boxes.  Now, do you know what Scrum is?  Yeah...  That’s what I thought…

You or someone that you know is one of the millions in today’s world who has had to pull their belt tighter.  You find that your mailbox is filling with bills that you cannot fully pay.  Sitting down at night you lay out each of the bills on the table and now you can see what is in front of you reflecting on the pay changes and economical responses of the company you work for.  At this point you have a few choices.  You can do nothing and drown in debt, plan how to pay them when you find a new job, or you can get started and dig out.

You only have so much money in your account and won’t have any more until payday so you call each of these companies and ask if they can wait for two weeks.  Some of them work with you, some don’t, and others would accept a partial payment now.

At this point you know what has to be done so you turn to the wife and kids and ask who can do what to get this done.  Your child says he can mow the lawn so you no longer have to pay for lawn care and the wife speaks up to say that she is going to start cutting coupons.

Each morning before everyone heads off to get gas for the mower or pick up the papers for coupons, you briefly hold a family meeting to find out what they did towards their goals yesterday and what it is that they plan on doing today.  Before everyone takes off to do just that you ask, “What problems are you running into?”  The wife found that often she needs a coupon from each side of the paper.  When she brings this to you, you decide to get a second paper while she cuts the first allowing her to acquire both coupons.  Maybe you instead have her continue cutting and filing while you search online for a website that allows her to print these coupons.

Doing this just got you to next payday and it is time to pay up on what you put off so you begin this routine again.  It worked so far, right? Pay off the some and pay on others.  Now that you have once again determined what has been done and what needs to be done you go back to the family and thank them for what they did.  Your child turns and says,  “Hey, I can take the bus to school with my new friend so you don’t have to use gas money to drive me each day” and the wife says, “I had some time the other night and found a new user group online that shares coupons allowing for more relevant coupons to the household.  We no longer need the papers.” Now you’ve speak up to suggest that next time the lawn is mowed that it should be cut shorter to extend the time between cuts, thus saving on gas and time.  Again, whew, you are on your way to the next pay check and everyone has picked up a piece of the solution to get you they’re allowing for optimization along the way.

Now let’s look at what you have accomplished.  The companies wanting their money (Product Owners) laid out what they need with some foresight (The Bill and Summary).  Some could wait and others were ok as long as you gave them something and got started towards the end product via negotiation, even though they have independent agendas as product owners.  You just groomed your Product Backlog.

Next you met with your family (Team) (Sprint Planning Meeting) and each member took on what they could establishing your Sprint Backlog.  While they worked on what needed to be done, you managed to keep them on those goals by removing any problems (Impediments) that came up.  These impediments were discovered as they worked and put on the table at breakfast, the Daily Scrum.

You – Scrum Master – Removed Impediment, checked the psychology of the team, provided feedback and alternative solutions to the product owners, and negotiation prioritization for seemingly unrelated products.

Family – Team – Worked to improve the way the work was done, let the product drive the work being done, and kept their promise to keep communications on the table.

Companies – Product Owners – stated what they needed, worked with the team to establish a common acceptance criteria, and left the team alone during the sprint. 

Two weeks went by (Sprint) and you got another paycheck.  In contacting the companies you review what was done (Sprint Review Meeting).  Then you met back with the family, talked about how it was great that they accomplished what they needed to and how you can do it better, such as mowing the lawn shorter (Sprint Retrospective).  You plan for the time between now and the next paycheck (Sprint Planning Meeting) <-- again...Life finds a way.

What did Scrum do for you?  You might be thinking at this point that this is no way to live.  Why are you living paycheck to paycheck rather than planning long term and getting out of this?  So, let’s go back to the original options…  You can do nothing, plan long term while acquiring late charges and possibly having your cable turned off, or you can start the work and dig out.

Break this nightmare down into to manageable sizes (Sprints) and start working with those that you owe (Product Owner).  As you find a new job, get more information or whatever steers you away from the chaos you will find that you are not two months behind on your bills now.

Now for the most important lesson in Scrum.  So now you have a new job and rehired the lawn crew.  Apply this framework to something else chaotic in your life and simply pay your damn bills going forward.

Establish and apply standards for your time/place in time boxes and congratulations!  You are now a Scrum Master.