Project Management

The Reluctant Agilist

Adam Weisbart | Agile | Agile 2013 | agile 2014 | agile 2015 | Agile 2017 | Agile 2018 | Agile Alliance | agile coaching | Agile Estimation | Agile for Humans | Agile Metrics | Agile Practice | Agile Teams | agile transformation | Agile Transition | Agile Uprising | agile2014 | agile2015 | agile42 | Agilistocrats | Alistair Cockburn | Atlassian | 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 | Change | change management | Chet Hendrickson | Chris Li | Christine Converse | Coaching | collaboration | commitment | Communication | conteneo | Craig Larman | cross functional teams | CSM | CSPO | DAD | Daniel Gullo | Dave Prior | David Anderson | David Bernstein | David Bland | David J Anderson | derek huether | Dhaval Panchal | diana larsen | Digital Agency | Digital PM | digitalpm | Disciplined Agile | Disciplined Agile Delivery | Distributed Teams | Don Kim | dpm | dpm2013 | drunken PM | drunken pm radio | drunkenpm | drunkenpm radio | eduscrum | emotional intelligence | empathy | Enterprise Agile | Essential Scrum | esther derby | Excella | Fixing Your Scrum | 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 | Leadership | LeadingAgile | lean | Lean Coffee | Lean Kanban North America | LeanKit | LESS | lkna | luke hohmann | lyssa adkins | Maria Matarelli | Mark Kilby | Marshall Rosenberg | Melissa Boggs | Michael Sahota | Mike Vizdos | Modern Management Methods | modus cooperandi | Modus Institute | 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 Backlog | Product Development | Product Goal | Product Owner | Product Ownership | productivity | project management | Project Management Institute | ProKanban | Rally | Release Planning | reluctant agilist | Renata Lerch | retrospective | Richard Cheng | Roman Pichler | Ron Jeffries | Ross Beurmann | Ryan Ripley | 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 | SparkPlug Agility | sprint planning | Systems Thinking | Team | teams | Temenos | The Improv Effect | Things | Tom Perry | Transformation | Troy Lightfoot | troy magennis | User Stories | value | Vivek Angiras | waste | Waterfall | Weisbart | What We Say Matters | why limit wip | WIP | women in agile | Woody Zuill | show all posts

About this Blog


Recent Posts

Lead Without Blame with Tricia Broderick

In Defense of Frederick Taylor with Christine Li

Story Points are Good AND Evil with Ryan Ripley

Value Stream Management with Derek Huether

Improving Value Delivery In Your Organization with Gil Broza

In Defense of Frederick Taylor with Christine Li

In this episode, I am joined by a very special guest, Christine Li, for a conversation I have been waiting to record for quite a while now. 


I am closing in on 30 years of work in Project Management and for most of that time, I, like many of you, have been talking smack about Frederick Taylor. My opinions were based on the things I learned from others along the way and were (obviously) deeply informed by moving from traditional PM over to Agile. As far as I was concerned, this guy was the birth of work misery.

But over the past few years, I’ve started to develop this weird compulsion to stick up for the good bits that came out of his work. I mean, literally, no one working in project management or agile would have a job without this guy. You can also make an argument that without him the United States never would have made it through WWII. 

Even though I was willing to have Taylor’s back in an argument, there was one thing missing… 

I had never actually read his work. 


So I did. I read The Principles of Scientific Management. And, to my shock, not only was it easy to read, but it was fun to read how this guy figured out the things he figured out. Yes, there are a few critical issues with his approach (and they are big issues), but there is a TON of good stuff in there that we all ignore because he’s such an easy target.

(And I really want to go back in time and get hired as SPEED BOSS)

After reading it, I was at a lunch and happened to mention my newfound Taylor Fanboy-ness and Christine Li showed up like Yoda, deep with the PM history geek. She took me to school and that is where this conversation starts. 

My hope is that even if you think Frederick Taylor is the Sauron of Project Management, you’ll give this a listen. Maybe it will challenge your understanding of him and his work. Maybe it will (I hope) entice you to read his work. And even if you’ve read his work and can see the good in it, the things Christine shares will level up your understanding as well. 

I am very grateful to her for making time for this. It was a really fun conversation. 

drunkenpmradio · In Defense of Frederick Taylor w Christine Li

For Further Reading
The Principles of Scientific Management by Frederick Taylor
Scientific Management; a History and Criticism by Horace Drury

Contacting Christine

Posted on: January 17, 2023 10:16 PM | Permalink | Comments (1)

Distributed Agile Teams White Paper Review


ProjectsatWork has published a study called DistributedAgile Teams: Achieving the Benefits. The report was put together by Elizabeth Harrin  (@PM4Girls), who is the author of the website A Girls Guide to Project Management. The results of the research cover a lot of ground with respect to what makes distributed Agile projects work and what can contribute to their failure.  The report is very insightful and definitely worth the time it takes to read. While some of the findings may seem like common sense, knowledge workers in the IT space (myself definitely included) seem to possess a remarkable capacity for periodic loss of grip to that tether.


My favorite part comes at the very end during the summary of recommendations. Number One on the list is:

Don’t act like your project is co-located – pay the tax for distribution.


This is one of the most simple things that so many of us forget when we are working at a distance. I believe this applies whether you are working down the hall from someone, or across the globe… there is a price that has to be paid when you are not sitting in the same room. With the transparency that Agile offers, this tax becomes far more obvious. There is no doubt that distributed teams provide a number of benefits, but those benefits come at a cost. The reason (IMHO) so many people struggle so much with distributed is that they keep thinking that the ride is free ... which it theoretically could be… unless you actually want it to work.

Posted on: April 24, 2012 11:10 AM | Permalink | Comments (0)

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

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)

Following up on Commitment, Evolution and Britney Spears

Since I posted my comments on the change to the Scrum Guide, I have had the chance to teach two Certified Scrum Master classes.  Despite my issues with the change, my desire to be transparent about things won out. I am still teaching commitment and explaining why, IMHO, it is so critical to the Team. However, I am also explaining the change in the most recent Scrum Guide and the argument for use of the word “forecast”. In both cases this has generated some healthy discussion within the class and my hope is that the participants will leave the class well enough informed to make up their own minds about it. 

Talking through the commitment vs. forecast question in the class offered a great example of one of the truly awesome things about Agile. Regardless of which flavor(s) of Agile you are working with you can expect that the standard will continue to evolve and change – and that is baked right into the different frameworks. So, as the workscape continues to grow and transform, expectations for productivity continue to increase and as knowledge workers continue evolving how they approach the overwhelming volume of information they have to deal with on a daily basis, it is safe to say that the techniques we apply in Agile will continue to evolve as well. This may not sound significant on the surface, but I would like to offer two points to illustrate why I believe the organic nature of Agile is so critical.

1.     Knowing that you are working with a methodology or framework that is going to continue to evolve and change places a different sort of demand on the practitioner. When working with a standard that is more, or less, locked down, many people reach a point where they believe they have finished learning it. Hopefully this is more the exception than the rule, but the problem is that they are able to get to this point in the first place. With a standard that is not locked down, that continues to keep pace with the changing workscape, the only way for the worker to remain viable is to continually grow their own knowledge and experience in step with the practice.  This forces Agile practitioners to approach their work as a learning experience, which requires a level of awareness and attentiveness that is not called for  by someone who has already “learnt” it.

2.     For the practices themselves, once they are locked down, the change control process can become such a burden that the framework, or methodology becomes static. As soon as this happens, it begins to lose its’ ability to provide value in a continuously evolving workscape. If Critical Chain really was the last new tool added to the PMBOK, than that means that the process most of us have come up with reached a static point during a time when:

·      Most of us used Windows 98 or NT

·      Most of us probably got online using AOL and a 14.4 Baud dial up modem

·      The iPod did not exist

·      We had never heard of Monica Lewinsky

·      We had never seen the Matrix

·      We were probably still watching George Clooney on E.R.

·      We were still two years away from hearing the phrase “Hit Me Baby One More Time.”

It is clear that our world of work has changed significantly since 1997. The way we deal with our work has also changed significantly since then. Why then, wouldn’t we require that of our process as well?

Posted on: August 23, 2011 11:50 AM | Permalink | Comments (2)

"Each problem that I solved became a rule which served afterwards to solve other problems."

- Rene Descartes