The Danger of Point Solutions

September 21, 2014 — Posted by Al Shalloway

The software development world has created several approaches to improving the work at the team level. These include eXtreme Programming, Scrum, Kanban, Kanban Method. While all of these solutions are based on some degree of reality, much of their organization and practices are based on the belief systems of their creators. I think we can get the best of what these all contribute not merely by mixing and matching practices but also by coming from a mindset of adopting practices in a cohesive manner based on where we are – not on the not-always-accurate assumptions of the creator of the approach. In other words, be guided by the laws of software development and how they apply to your situation instead of taking a one-size fits all attitude.

The practices of these approaches can’t just be combined willy-nilly with each other. They represent a cohesive set based on the mindset of their creator. However, it is possible to discover a bigger mindset that encompasses all of the beliefs and helps guide us as to when which ones are valid. I have found that Lean-Thinking can explain why all of the above approaches work well in certain situations as well as reasonably accurately predict when they won’t. This common mindset of Lean is more powerful than merely having a set of collections of practices.

To understand this, let me make an analogy with cooking.  Many folks use recipes to do their cooking.  Think of the different types of cooking: Italian, BBQ, and others. Each type suggests cooking a particular way using particular ingredients. Beginning cooks like to be given recipes and venture from the recipe with risk. What may appear to be a simple substitution can often cause poor tasting meals if you don't understand what makes a good meal.

Once we start considering that a recipe is merely a way of implementing a desired result, we can start seeing similarities between what looks like fairly divergent recipes. For example, one can think of Chicken Piccata with vegetables and BBQ ribs with potatoes as two completely different types of meals.  But one can also think of them as different point solutions in a space of what’s possible to eat for dinner.

We do this by seeing how each component of each meal has a purpose and that, perhaps surprisingly, each recipe shares to these purposes to a surprisingly large degree. This is illustrated in the following table:

Purpose Chicken Piccata “implementation” BBQ ribs “implementation”
Protein Chicken ribs
Vitamins / fiber Vegetables potatoes
Taste piccata sauce BBQ Sauce

Note that while these can’t be intermixed (I don’t think I’d like sauce used in piccata on my ribs), the components work together well for each recipe. And note that each of these has a better application in different situations – chicken piccata in a sit-down meal while BBQ ribs where you don’t mind getting a little messy.  Each also implements its purpose to different degrees – BBQ ribs may not be as healthy as chicken piccata but it tastes better to lots of people.  Substitutions are fairly easy – veal instead of chicken for veal piccata would make sense.  Not sure veal in place of ribs would for the other recipe, although chicken would.

Thus, we can think of these recipes as point solutions in the space of the food we can make. Some make more sense than others and some are more applicable than others.  We get flexibility in doing this if we know something about combining food.  We may limit ourselves if we think only in terms of “Italian cooking” or “BBQing.”  In other words, we want a more common space from which to come – one that encompasses all cooking.  This is what differentiates a great chef from a common cook – the chef knows what makes something great while the common cook is merely following a recipe and can’t adjust.

In the software world, the common approach for improvement has been the adoption of one of two point solutions – Scrum and the Kanban Method.   I’ve organized the practices of each in a table so that you can see that each one has a corresponding practice to the other.

Scrum Kanban Method
Eco-system structure, roles and transition model
Eco-system structure, roles and transition model
Organize in cross-functional teams
Team structure is orthogonal
Create new roles: PO, SM, Team
Use existing roles
Start with a pre-designed structure
Start where you are.  Avoid making eco-system changes until after a kanban system has been put into place
Planning and Estimation
Planning and Estimation
Use time-boxed sprints for planning and guidance to finish things quickly
Do not have sprints nor plan work ahead. Focus on flow
Estimate work and use velocity based on estimates and work done to assist planning
Do not estimate – estimation is considered wasteful activity
Do planning at the beginning of every sprint
No planning done, but keep product backlog loaded on a regular cadence
Artifacts
Artifacts
Use burn-down graphs for tasks & burn-up graphs for stories
Use cumulative flow charts and scatter diagrams for work being done
Impediment list
Impediments should be visible on the board but can be listed as separate items if need be
Product backlog
Product backlog
Sprint backlog
Work in process is listed on the kanban board
Work decomposition
Work decomposition
Have a product owner to help break down stories and to sequence the work to be done
Work on value added items.
Improvement
Improvement
Have learning retrospections at the end of every sprint
Have explicit workflow policies that enable the use of kaizen to improve flow on a daily basis
Have a daily standup to reset the work being done and to communicate what’s happening with the team
Have a daily standup to discuss blockages. 
Use a kanban board with explicit workflow so people can see what’s happening without meeting
Role of Management
Role of Management
Teams self-organize without management involvement
Teams self-organize to improve the flow of their work
Teams coached by a Scrum Master with no authority over them
Teams use existing team-leadership approaches in place prior to Kanban Method
Create visibility of work going into and out of sprint as well as status of work being done.  But don’t explain workflow rules.
Make all work visible to management including work status and workflow agreements.

Looking at these two approaches this way, you can see the assumptions underneath the practices.  For example, the way of starting Scrum and the Kanban Method shows the considerable different attitude about how much change can be accommodated at the beginning.

You can use these insights to help decide what you really want to do instead of the all too often approach of just doing the practices as we've been encouraged to. While the popular Shu Ha Ri metaphor may have this make sense, it doesn’t in our situation. In the martial arts you are trying to learn a particular martial art. Saying you’ll abide by the sensei’s decision makes sense.  But in our world, the approach we take should be based on our needs.  All too often companies go to a coach who only has one approach in his wheel house.

Before implementing our approach, we should step back and see which approach will be best.  But we shouldn’t pick between these two.  And we should just pick and choose the practices we ant.  Instead, by looking at the different approaches Scrum and the Kanban Method take, while understanding the Lean principles from which both sprang, we have the opportunity to create an approach that will work well for our situation.  This is not unlike substituting chicken for ribs to tailor BBQ ribs to our needs. But we must be aware that picking and choosing practices has its risks.  We must recognize the purpose (intention) of a practice and make sure any substituted practice will achieve that intention.  Without this view, changing one practice can leave us without a needed result.

We can now see the danger of point solutions:

  1. We may not recognize that there are better alternatives to a particular practice
  2. We may not understand how changing one practice in the solution has an adverse effect on the system
  3. We may become myopic to other solutions (see Framework Myopia)

Unfortunately, all three of these are fairly common.  Regarding #1,  I see organizations struggling with Scrum attempt to achieve cross-functional teams when they would be better off sharing those folks that represent constraining capacities (e.g., SMEs, architects, those with knowledge of legacy code, specialists, …).  I also see those adopting the Kanban Method ignoring the creation of cross-functional teams while doing so would make their workflow much better. Regarding #2, I often see people mis-interpreting how the practices need to be viewed as a system and merely take Scrum, drop the time-boxing and call it Kanban (it isn’t, and this doesn’t work well).  This type of behavior happens less with the Kanban Method since it is more of a systems approach and people adopting it usually understand this. Regarding #3, newbie Scrum teams tend to not manage WIP inside the sprint and Kanban Method  folks tend to not create cross-functional teams even when easily achievable.

I’ll leave to my next blog how to define an effective team level framework/method that goes beyond the point solutions and assumptions listed here.  I’ll show how one can readily do this by attending to which practices achieve the outcomes you need in your particular situation. 

Please discuss this blog at the Lean Systems Society Discussion group

As always, if this blog makes sense to you and you would like help at the team level with an approach adopted to you instead of you adopting to it, please drop me a note.

Al Shalloway
CEO, Net Objectives

If you are having troubles running Scrum or the Kanban Method, maybe it's because the approach you are trying is the right one for you.  Take a look at our New Team Process page.

 

  1.  
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban