Project Management

How Much Do We Actually, Really, Totally Need To Do?

From the The Reluctant Agilist Blog
Adam Weisbart | Agile | Agile 2013 | agile 2014 | agile 2015 | Agile 2017 | Agile 2018 | Agile Alliance | agile coaching | Agile Metrics | Agile Practice | agile transformation | Agile Transition | agile2014 | agile2015 | agile42 | Agilistocrats | Alistair Cockburn | autism | Bas Vodde | BigVIsible | Bob Tarne | book review | Brian Bozzuto | business agility | carson pierce | Center for Non-Violent Communication | Certification | Certified Scrum Master | Certified Scrum Product Owner | Chet Hendrickson | Chris Li | Coaching | commitment | Communication | conteneo | Craig Larman | cross functional teams | CSM | CSPO | DAD | Daniel Gullo | Dave Prior | David Anderson | David Bernstein | David Bland | David J Anderson | Dhaval Panchal | diana larsen | Digital Agency | Digital PM | digitalpm | Disciplined Agile | Disciplined Agile Delivery | Distributed Teams | Don Kim | dpm | dpm2013 | drunken pm radio | drunkenpm | drunkenpm radio | eduscrum | emotional intelligence | empathy | Enterprise Agile | Essential Scrum | esther derby | Excella | Gangplank | Gil Broza | Howard Sublett | Individuals and Interactions | Jean Tabaka | Jeff Sutherland | Jesse Fewell | Jessie Shternshus | jim benson | johanna rothman | john miller | Jukka Lindstrom | Jutta Eckstein | kanban | Kanban Pad | kanbanfor1 | Ken Rubin | Kenny Rubin | Kim Brainard | lacey | Language | Large Scale Scrum | Larry Maccherone | LeadingAgile | lean | Lean Kanban North America | LeanKit | LESS | lkna | luke hohmann | lyssa adkins | Maria Matarelli | Mark Kilby | Marshall Rosenberg | Michael Sahota | Mike Vizdos | Modern Management Methods | modus cooperandi | Natalie Warnert | Nic Sementa | Non-violent communication | North American Global Scrum Gathering | NVC | Olaf Lewitz | ├średev | ├średev 2013 | organizational agility | Organizational Change | overcommitment | Patrice Colancecco Embry | Paul Hammond | personal kanban | personal productivity | personal project management | Peter Saddington | PMBOK | PMI | PMP | podcast | portfolio management | Product Development | Product Owner | Product Ownership | productivity | project management | Project Management Institute | Rally | Release Planning | reluctant agilist | Renata Lerch | retrospective | Richard Cheng | Roman Pichler | Ron Jeffries | SAFE | Safety | Sallyann Freudenberg | scaling agile | Scaling Scrum | Scott Ambler | Scrum | Scrum Alliance | Scrum Gathering | Scrum Master | ScrumMaster | self organizing teams | SGPHX | SGPHX 2015 | Shane Hastie | social engineering | SolutionsIQ | SoundNotes | sprint planning | Team | teams | Temenos | The Improv Effect | Things | Tom Perry | troy magennis | User Stories | value | Vivek Angiras | waste | Waterfall | What We Say Matters | why limit wip | women in agile | Woody Zuill | show all posts

About this Blog


Recent Posts

Ryan Ripley - Fixing your Scrum

Leadership is Language with David Marquet

Agile for Non-Software Teams w/ Gil Broza

Understanding Trauma w/ Brandon Brown

The Power of Volunteering w/ Reese Schmit

When I am teaching CSM classes one of the commonly asked questions usually doesn’t show up until almost the very end. When it does, it comes disguised in various explanations and wrapped in deeply detailed back story. In the end, it always boils down to the same question… “How much of this do I actually have to do?”

What strikes me as ironic is it always seems to come at the end of a 2 or 3 day class where we have spent the time discussing an approach to work that is more lightweight than has been used in the past.  So, we’ve removed all the extraneous process, lots of the burdensome paperwork and a kitchen sink’s worth of other stuff but the question is still centered around on defining the bare minimum (of the less burdensome process) that must be done. 

If the person asking the question is specifically concerned about reaching a state of Agile Nirvana-ness, or works for a company that awards gold stars for Agility, my recommendation would be apply no less than the amount of <methodology or framework of choice> as is required to deliver working product. This is one of the primary way we measure success in Agile. But most organizations do not give out a prize for being “TOTALLY AGILE”. And at the end of the day, the job is to deliver something that works, which can improve the company’s financial position in one way or another. In order to reach that goal, one must apply no less than the amount of <methodology or framework of choice> as is takes to reach that state.

But for many of us, especially those trained in traditional project management, we need a line in the sand. We want something helps us know when we are fighting for the Empire or the Rebel Alliance. (One more reason we should all be issued orange jump suits when we take CSM training.)

There are specific elements in the Scrum framework that (IMHO) when left out result in the practice of something which is possibly Agile, but no longer Scrum. However, my list is based on my own personal understanding of what SCRUM. This begins with what is defined in the Scrum Guide (and related documentation) and is then filtered through my own empirical approach and experiences. I’m quite sure solid arguments can be made to dispute each item I would include (or not include) on that list of what is required to do Scrum.

In my own personal practice of Scrum, there are two parts to the answer. The first part of the answer is that each person involved needs to apply no less than the amount required to complete work that can drive revenue. The second part if that in order to truly see the benefits that Scrum (or any Agile practice can provide), I have learned that it is best to start as close to a pure version or the practice as the individual’s organization can tolerate. Each iteration offers an opportunity to plan-do-check-act over and over again. Each time we go through those steps we should making adjustments until an optimal practice of Scrum emerges. Once this optimal practice does emerge, they must  never stop finding ways to break it and make it better.

What I am more curious about is what drives the desire to find the bare minimum of the newer, more lightweight process. My expectation is that it stems from a perception that Scrum would be difficult to implement within the context of whatever waterfall-esque process is currently in place. This could easily lead to the question of how much can we leave out and still technically call it Scrum.  But again, at the end of the day, bonuses are rarely awarded based on Scrum purity. And there are, unfortunately, far too many organizations, teams and individuals out there who have jettisoned all but the vocabulary and still feel comfortable calling it Scrum.

Posted on: February 17, 2012 02:23 PM | Permalink

Comments (4)

Please login or join to subscribe to this item
Hi Dave, I found this article very interesting and I think it clearly conveys the essence of using agile methodologies and the fact that a pure agile method is seldom met in practice (if at all encountered). The question you raised on "how much from the lightweight framework is to be adopted in projects" made me think about Extreme Programming. Most of the time software projects that claim to be agile use a combination of Scrum and Extreme Programming (XP). The question on how much to adopt from all main 12 XP practices is often encountered. This is for me a valid question since the way to apply XP heavily depends on the project and organization type, respectively. In case of green field development projects applying XP in its entirety is relatively easy but in case of maintenance projects or in case of projects inside stricly phase based organizations it is more advisable to start with a subset of XP practices and then expand based on the feedback received from the Plan-Do-Check-Act process. In case of XP the question of "how much from the agile process should be adopted" makes sense.

Hi Andreea,

Thanks for your feedback. I'm glad you found the article interesting. My concern is more about the desire to dismiss part of it before it has even been tested out. While it certainly may be my interpretation of what is asked. The question is usually hear is not posed in a way that suggests implementing the practices a few elements at a time. It is more along the lines of "Yes, a standup meeting sounds great, but we want to sit at ours because that is just how it works where we are. Also, we probably will only want to have it once a week because more than that will not be useful to us, and it will probably take us at least an hour because that is how long it takes when we start ... .

My request is always the same - first try, then change. I think this applies even if you are implementing XP. First, try it out the way it has been proven to work. If you only do a few practices, do them the way they've been set up to work first, then modify them if/when you need to.

Thank you, Dave!
The article is interesting and useful to read.


Thanks for sharing!

Please Login/Register to leave a comment.


"In youth we learn; in age we understand."

- Marie von Ebner-Eschenbach