"Simple to Say But Hard to Do"? or "Saying Simplistically What is Hard to Do"?

March 20, 2016 — Posted by Al Shalloway

I have been doing “Agile” for 17+ years consciously and on and off for 30+ years if I look at times in past I created one-off Agile practices without knowing what Agile was (e.g., the time I did automated acceptance testing in 1984).  Almost from the beginning of Agile I have heard people defend it by saying “simple to say hard to do” as if that meant the failures in adoption didn’t reflect badly on what people were saying to do.

I am not saying Agile is or should be easy to do.  Doing it properly requires a transformation of the people involved and personal change is difficult and time consuming.  But this doesn’t excuse us from not continuing to look at how we are framing what we need to do.

As an experiment, on Twitter I asked for simple things that are hard to do.  The responses I got mentioned:

  • Motivation
  • Conversation
  • Empathy
  • Programming
  • Adoption
  • Do what we say is most important
  • Start and finish one thing
  • Commit to a decision made

I hadn’t expected these answers at all. But they underlined a thought I had.   A little reflection on each of these will reveal what I had suspected – that it’s easy to state an objective, but not easy to say what to do to get the objective.  However, this is not quite how the statement "easy to say hard to do" has been used predominately in the Agile community.  Most of the time I have heard it said about the practices, not the objectives (which are rarely, or only partially, given oddly enough).   For example, Scrum is defined almost entirely in what to do.  Rarely are the objectives of the practices mentioned.  For example, what is the purpose of iterations?  Initially it was described as providing quick feedback on both what is being built and how it is being built.  But that is only a small part of the reason for objectives.  Other objectives (or reason for doing iterations) are:

  • require small stories
  • provide discipline (make it clear after every iteration whether you are really done or not)
  • limit work in process (can't have more than what will fit into an iteration
  • encourage the use of cross-functional teams 
  • provide a cadence for both developers and those interacting with them
  • allow for short planning cycles

I believe this is an important insight because most of our popular frameworks and methods are defined by “what to dos” with little statement of “objectives.” Very often I see people caught up in the doing because they have no objectives to keep them focused on learning what they have to do.  Furthermore, one has to "do" the provided practice or you are doing "whatever-but."  You really want to focus on the objective, who cares what approach it comes from.  In other  words, all of our practices need to be defined in the context of the objectives the practices are for.

If you are having troubles with implementing Scrum, Kanban, SAFe, eXtreme Programming, ... , it may be that you have not been properly trained in the objectives for each of the practices you've learned.  Let me know if you think we can be of service.

Al Shalloway

CEO, Net Objectives

 

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