Monday, 27 June 2016 07:05

Done and the Human Condition – Can you Handle the Truth?

Written by

Truth is not the same as “fact.” Truth is an intellectual construct only grasped and pursued by humans on this planet.

Truth is a belief system that is sometimes passed off as a conclusion that is factual and logical from verified premises. It is only the subjective sense of truth, what you believe, that will “set you free.”

I start with this philosophical premise because I think it’s critical in explaining how I have come to embrace the Scrum approach to Agile product development. As a seasoned (read “battle weary”) project manager, I needed to absorb and understand that converting entire development, nay corporate, environments to the Agile way was not simply invoking another silver bullet to rescue them from sub-performing IT systems. As one who has participated heavily in my employer’s course to prepare project managers for their PMP certification, I also appreciate and stay sharp on the foundational principles of running a good project. I have looked at the project management “triangle” as a self-evident truth of most any endeavor that companies launch.

Related Article: From the Sponsor's Desk: A Moment of Truth

Keeping costs at bay and finishing things on time are constants in the everyday work of the project manager. The ideal, as it has been presented in traditional development environments, is to have a solid road map, well-thought requirements that clearly define the prize at the end of the project. I have done my part in “educating” my clients about the triangle and, in discussing the scope lattice, elevated the importance of “what must be done to provide value.” Scope, and what affects scope, drives risk management, change management, and closure of projects and project phases. The pre-eminence of good requirements elicitation can’t be underestimated, and entire industries have thrived in supporting the business analysts’ tasks to get scope nailed. Measure twice, cut once, right?

Traditionally, project managers have looked at scope as the immutable prize that defined successful projects and truly pleased the client. It works on the premise that the business knows its pain and clearly articulates its treatment of that pain. Projects are chartered that set objectives achievable in a month, 6 months, a year, 5 years, and even more. We do our best to manage costs and stay on schedule, but when we discover that achieving scope will take more, or take longer, we, as project managers, reach into our trusty tool kit of escalation and change control to keep everything on track. I have stayed in this lane for over a decade, shaking my head at those who would speed around me or, worse, get off the highway completely to find the ever elusive shortcut. I can see more clearly now. My treatment of scope has ignored the immutable truth about the human desire for closure, for a sense of finishing what was started. And Agile, specifically Scrum Agile, has shined the light.

Agile turns scope on its head. This is the truth that set me free because I’ve been a disciple (slave?) of scope since my early days in project management. I always go beyond software to defend scope, because I accept the premise that businesses don’t ever totally understand what they want from software. I say, “what about building a house?” If the owner’s top priority is the features of a second-floor bedroom, how would we do that first? How would we apply the notion of incremental and potentially releasable product to a house? So, in my old persona of defender of scope, I shout, “know your business requirements, know what you need, write it down, and test the requirements, the “what must be done to add value””and you might find that you don’t need new software at all. But define that scope and hold it like it’s a precious possession.

Adopting principles as truth goes beyond assembling logically progressive facts into an evidence-based conclusion. You need to believe in the principles and make their truths self-fulfilling prophecies. And this is not a negative imperative because part of the human condition is to make things work in the face of constraints and apparent imperfections. I’ll go beyond that and suggest that getting things done is the most central tenet of the organizational human condition. And guess what? The central tenet of Scrum Agile is getting stuff done.

So the fundamentals of Agile, and we’ll focus on Scrum here, are about getting stuff done. There is nothing more satisfying in the human experience than completing something. Stuff in progress is maddening. The more “in progress”, the less satisfying the human experience. We all say “life is a journey” and philosophers prod us to focus on being happy with “in progress” but our minds contort those journeys, we look for milestones, we look for signs that something is complete. It might be part of a larger thing, but some chunk is complete. This is why the long distance runner wants to know about his splits, why we have “legs” of a journey, why those who simply don’t care about or perceive their progress are likely high or mentally ill. I’m not being flippant here. I think this is true, and I think it is a core truth.

Just as true is the notion that we’re never done with everything that should be done. We’re all Sisyphus, pushing the rock up the next hill, only to watch it roll down. There is no such thing as “done” for a business. It can meet needs, make a profit, and give people a living, but if it doesn’t increase its profit, meet more or unmet, or invented, needs, then it is deemed “unsuccessful.” And this is why we need to be suspicious of scope.

There’s another hill on the horizon. Another set of realities. Are you coming around to accepting truth as more about cosmic beliefs than worldly facts? Agile has. Scrum has, in an elegantly succinct way. That being said, truth is always hard. Scrum is simple to understand and difficult to master (Schwaber and Sutherland, p.3). Difficult? Yeah, like running a two- hour marathon is difficult.

So Scrum is also based on the notion of done. The Definition of Done, as set by the product owner, is the contract of the Scrum Agile “project” outcomes. .If there is merit in my claim that we yearn for a sense of doneness in a world where nothing is ever completely “done,” then Scrum Agile is my highway. But this journey is going to be rocky, believe me. Be humble and realistic in your notion of done. If you take this fork in the road, you won’t produce an inferior product as opposed to the grand rollout of traditional SDLC-produced software. But there will be a learning curve and some painful revelations. It might seem like you’d be better off doing it the old way. Don’t be fooled; don’t listen to those “enjoy the journey” charlatans.

Working toward a progressively elaborated definition of done is a marvelous thing, only appreciated fully in retrospect. Measure what you have and consider how quickly you started making it. The painful phases of “forming” and “storming” have to occur before we get our footing on this tough road.

Scrum is presented as a pure framework; it doesn’t compromise on its core principles. All the constraints that make it less than successful can be addressed by making organizational changes, by transforming the corporate truth proposition. We all know, we all sense, that this is very hard. The real challenge is to convince those who control the purse and see product development goals only on calendars that the truth is about change, and that taking this on means reuniting the seemingly incongruous forces of change with our yearning to get things done. Done, in the new reality, is a to-be-continued construct. Scrum is hard, and tiring, and frustrating in a genuinely Sisyphean way. Hell, I’m not even an Existentialist, and I can’t ignore that rock ascending, only to roll down again.

But it doesn’t mean that we shouldn’t try. It certainly doesn’t mean that we shouldn’t believe in the truth about our quest for done. Colonel Jessep’s quote in a Few Good Men, that “you can’t handle the truth” might be a fact. But you don’t have to “believe” in that and walk away. And if you won’t even try to find the truth, then the truth will never set you free.

1. The Scrum Guide™, The Definitive Guide to Scrum: The Rules of the Game, Jeff Sutherland and Ken Schwaber, July 2013.
2. “Maximizing Value with Scrum / Agile” two-part course, developed and delivered by Maclore Christensen, CSM, CSPO, November 2014.
3. Camus, Albert The Myth of Sisyphus and Other Essays, New York: Alfred A. Knopf, 1955

Read 4479 times
Paul Antelman

Paul is a seasoned project manager and business analyst with 20 years of experience in project / portfolio management, requirements elicitation, and systems analysis. Paul brings a robust array of technical and business skills to each of his assignments, which often require a combined skill set. He has managed traditional SDLC projects as well as agile-based efforts. He is certified in Lean Six Sigma, ITIL, and Project Management as a PMP®. Paul coaches colleagues and clients for PMI certification for his current employer's PMI-sanctioned prep course.

Latest from Paul Antelman

© 2017

macgregor logo white web