I think it’s fair to say that the Agile literature encourages us to have a lighter touch with regards to how many processes and structures we set up relative to what we’d put in place in our pre-Agile work lives.  I’m open to discussion on this, to a point, but anyone hoping to engage me in an academic, theoretical, borderline-religious discussion on what “pure” this or that methodology “really” said is in for a disappointment.  I don’t really go there anymore.  I used to be willing to jump into the octagon and throw down at a moment’s notice, but now, I like to spend my time talking about what works and what doesn’t in the real world with real projects and real challenges and leave those discussions to others. 

My take is that part of the spirit of Agile (Scrum to be more precise) is for us to survey the situation, look at the bag of tools we’ve acquired and become so skilled in using over the years, and then only pull out the tools that are needed.  Even if it would be fun to try that one or show off our skill with the other, we have the professional discipline to apply the principle of “barely sufficient” not just to our developers or system architect, but to ourselves.  Besides, that’s where the artistry and craftsmanship of what we do shows up. 

With that in mind, it’s an interesting and instructive exercise to periodically step back and consider what the minimal processes and systems and tools really are.

When I walk into a new environment with the task of analyzing the needs of the situation and pulling out what I think would be the ideal set of tools for the scenario, one of the most important bits of structure I set up first is the Scrum concept of a “retrospective”–a meeting held at the end of each sprint where we take time to reflect back on how we did, what we just accomplished and got into the “Done” column, and what we could improve upon in the next iteration. 


Because this one discipline allows the team to become what Peter Senge called a “learning organization” and to morph and tweak its processes over time to 1) make them their own (instead of the vanilla, cookie cutter version directly out of a methodology text); and 2) to remove friction points in the system in order to become increasingly-effective and streamlined over time.  In my experience with multiple teams, as soon as one developer or release manager raises her hand to break the awkward silence in the first retrospective, and puts something on the table that we all experienced and all agree didn’t go well in the last sprint, we candidly but professionally talk through it, come up with a solution, and then implement it in the very next sprint cycle.  People start to think, “Holy cow!  That just happened.  We saw a problem and fixed it, ourselves!  We own this.  We can change and improve things and don’t just have to accept whatever the PM says to implement from his books…”

Then, things start to get exciting as many more hands start to go up in future meetings. 

So, I’m sold on some form of a retrospective being part of the minimal tool kit for teams.  What I’m just learning is that this same practice and discipline is at least as important (if not more so) for the project manager.  Let me explain.

In Garrett J. White’s book, The Warrior Book, he encourages his readers to do a personal retrospective-—what he calls “going into the general’s tent” each Sunday.  Covey encouraged us to do almost the same thing in the weekly planning session he outlined in his wildly-popular 7 Habits work.  Ditto from David Allen’s Getting Things Done work.  The idea is that we get so wrapped up in playing whack-a-mole in what the 4 Disciplines of Execution (4DX) calls “the whirlwind” that we lose all perspective, forget why we’re doing all of this, burn ourselves out, and start into a downward spiral of becoming less and less effective as a leader over time. 

So, what do we do?  Step One is to take a weekly step outside of the wind tunnel we live in Monday through Saturday in some sort of personal retrospective.  This is going to be very different for each person, but the big idea is to look at the big picture—our long-term roadmaps and intermediate goals for each major area of responsibility or dimension of life and take a deep breath.  Covey suggested we do this by looking at our roles and goals.  Garrett suggests we look at our lives through four lenses: body, being, balance, and business which works for me and is the system I use, but it doesn’t really matter.  The point is to get perspective, connect back with purpose, review where we want to go and why, and then get brutally honest about where we are now and the gaps remaining that we need to fill. 

If we don’t do this as project managers, we burn out.  We lose our zeal for what we do.  We no longer show up to work with the drive and curiosity and motivation our project teams expect from us.  We start to just go through the motions and…that doesn’t end well.

If, however, we incorporate this one discipline into our personal and professional lives, week-after-week, we stay on course, keep our passion, keep our cool when things get spicy (as Garret would say), and get stuff done. 

Project managers are like a big battery walking around where everyone is always coming up and saying, “Oh just in time!  I need to plug in my phone…” or, “Well it’s about time!  My laptop is down to 9 percent!  How am I supposed to do my job if I don’t have power…” and plugging in all of their electronics not giving the first thought to where the power is coming from.  It’s coming from the project manager.  And no one is offering to come up to the PM and charge her/his battery—they just need a quick charge for their phone or tablet and they’re gone. 

We have to charge our own batteries.  We have to monitor our battery level and be sure to take time away as I’ve outlined, so we’re always ready to serve and lead.  I’ve found building in weekly, protected time into my schedule for a personal retrospective is a fantastic way to recharge and renew.  Hopefully you can too. 


Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.

Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE
We hope you will consider joining our Facebook Community as well.  Click on the image to your left to visit and join, or you can CLICK HERE



Reading this article qualifies you to submit a request for PDU's from PMI.

This Article qualifies as follows:



For more information on registering your PDU's with PMI - CLICK HERE


At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!

If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.

This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE


You may republish this article in whole or in part with attribution to the author and a direct link back to the full article on this site. Attributions MUST include a hyperlink to the original article, as well as a "Canonical Link" reference embedded in the <head> section of the page.
#pmfortoday / #projectmanagement / #pdu / #pmi / #pmo / #pmbok / #pmblog / #pmoblog / #pmp / #pmi-acp / #pgmp


Randy Cox

Randy Cox

Contributing Author

Randy received his undergraduate degree in Business, Corporate Communication, and Applied Information Technology from the University of Baltimore, and his MS in Information and Telecommunication Systems from Johns Hopkins University.  He also has five professional certifications: PMP, PMI-ACP, CSM, SAFe, ITIL along with a certificate in Finance and Accounting from the University of Utah.

He’s worked as a business analyst, senior business analyst, IT project manager, IT program manager, and now as a senior IT project portfolio manager for a variety of organizations that include mom-and-pop companies as well as such household names as T. Rowe Price and The Washington Redskins.

Randy has a particular interest in the nexus of Agile and the Theory of Constraints, and consults on a limited basis with select clients through Epiphany Associates, LLC.  Randy is the founder of the Projects and Systems Podcast

LinkedIn Profile - CLICK HERE
LinkedIn Group - CLICK HERE
Articles by Randy Cox - CLICK HERE

Projects and Systems Podcast - hosted by Randy Cox - CLICK HERE

Advertisements B