Skip to main content

Author: Paul Antelman

Lights! Camera! Software!

I admit to a penchant for analogies and allegories. I’m a self-confessed liberal arts graduate after all.

I once gave a speech at Toastmasters comparing male pattern baldness to urban flight population shifts (the hair moves from the “central core” to the suburbs of the back, ears, nose, and eyebrows). That being said, I think I’m on to something in comparing software development in an agile-transformed organization to the machinations of making and delivering successful feature films. Stay with me here.

I’ve used a movie industry metaphor before when describing what tends to (or should) happen to requirements that are compiled at the start of a project, listed in a project charter or business case proposal document. They end up on the “cutting room floor.” On reflection, there are a number of striking comparisons worth noting between the endeavors of making a movie and making valuable software. When you consider all that goes on behind the scenes to make a successful feature film, the parallels are there for what happens to make “magic-in-a-can” software, especially if the latter is delivered in an agile-transformed environment.

Start at the beginning. Like with software and most any type of project, the movie industry has its holy triangle of Cost, Schedule, and Scope (or Plot), with, of course “Quality” gratuitously emblazoned in the geometry’s center. The filmmaker has an idea and often has a script to go with that idea. That the idea is compelling and interesting to ticket buyers is kind of the universal “business problem” that movie people are proposing to solve. In contrast to software project proposals, the cost of doing nothing is more subtle and only revealed in retrospect, but, on the other hand, most business cases for software have an ROI that is only teased out in hindsight as well, right?

The script could be an original idea, a derivation of other works done successfully, or an upgrade/remake of a proven commodity. Software solutions are likewise a) innovative and ground-up “greenfield” efforts; b) derivations that improve established functions, or c) upgrades to an entity with established value. For b), think “adding machine learning or AI to search engines,” “automating keystrokes,” or “reworks using new user-friendly building blocks (4G languages).” And for c) there are applications that have worked just fine, but they’re written in VB and need to be modernized. Cinematically, when I think ”c),” I think of the movie “A Star is Born,” a classic example of a proven commodity that filmmakers believe needs an update/remake every couple of decades, from Judy Garland to Barbara Streisand to Lady Gaga.

Any way you look at it, the pitchperson must present a package and justify expenditures to the sponsor. Given that the story, or charter, is compelling, the producer is usually on the hook to propose a schedule and delineate needed resources (that is, what the money will buy). Scripts, like large backlogs of user stories at the start of a year-long software project, describe objectives well enough, but there is tacit understanding that the crew and cast will do what makes sense to make the script work. After all, some things look better on paper than in execution. How true is that for many software development projects?

[widget id=”custom_html-68″]

If we applied all the trappings of a waterfall-method project to movie-making, “sticking to the script” becomes a virtue. I’ll grant you that we’ve seen movies that stepped too far off the story and have failed miserably. Think Bonfire of the Vanities, such a bad movie, compared to the book, that it spawned another book and a documentary about what went wrong. But what is usually true is that the script is just a starting point and successful cinema magic making involves continuous improvisation, compromise, and even abrupt, sometimes seismic, changes.

In software, the executive producer is the group of stakeholders who are investing in the outcome to address a justified need that the application can address, or has addressed and needs to continue to do so. The producer might be the Product Owner, their associate producer the software designer/architect. The director is the project manager or scrum master. The editors and film crew are the analysts and testers who shine the light of daily reality on the script that is the backlog. And, I would argue, when creative self-organization, collaboration, and chemistry underlie the effort, the film, er, the software, hits the mark and delivers the value promised when it was pitched, priced, scheduled, and more or less scoped at the very beginning.

The cast logically parallels the development team. As with the movies, there are stars and supporting cast, there are designers, perhaps front end developers, who are prominently associated with the show itself, just as there are vital builders of all the plumbing and back room magic that makes that search engine do new and amazing things ever faster than before. I just read a column about the importance of supporting actors in ensemble shows and movies. Star power can sometimes carry a film, but chemistry is more often the winning formula. Either way, the director will put their stamp and style into the results by the way they foster chemistry and, in no small way, roll with the punches as the cast (or development team) forms, storms, norms, and performs.

Audience screening and user acceptance testing, as well as all types of testing, are always wise before unleashing the production on the buying public. User experience specialists aim for effective cinematography to make the software click with the audience. The value proposition (what is most important) is continuously in play, whether in the editing room or during backlog refinement. Just like scenes get dropped, despite their promise, if they don’t support the film’s narrative, not all requirements in the backlog become reality if, upon scrutiny, they don’t improve on the software’s treatment of the business problem.

Finally, release planning needs to consider readiness of the products’ beneficiaries, like targeting a blockbuster action film to hit theaters in the summer or bold message-driven productions to be released in alignment with the Oscar nomination season.

I imagine that there are a few movies that have succeeded because of religious adherence to a great script, a seminal story, or a transcendent novel. Perhaps there are directors that dictate all that must happen in every scene, or work in an environment where the producer and executive producer want a full-blown cost benefit analysis to justify any improvisation or adjustment to the originally submitted script. And, as with software, there are cases where all involved, including the carefully chosen stars, completely missed the point despite spending tons of money and energy around all that is supposed to wow us as consumers of the silver screen (I’m thinking “Waterworld” here).

But ask any development team if they prefer rigid and sequential building of applications, based on a distant and thick set of meticulous specifications, over collaboration with the business to deliver what is truly valuable and making the adjustments, through continuous inspection and adaptation, to deliver software in the most elegant way that is financially feasible. To understand why you should guess that the latter is true, think of the Oscar acceptance speech. You know who the star is, maybe even the director, but from acceptance speeches you also hear a list of names of whom you’ve never heard of who “made it all possible.” So too would the software development team prefer Inspection, Adaptation, and Transparency in a collaborative setting to get the most satisfaction, and provide optimal customer value, when the credits roll. **

**As a postscript, I would like to acknowledge and thank Ryan Abrahamson, a senior developer from my company who is surely the equivalent to a movie star when it comes to making great software, for the idea and inspiration to write this little polemic. Lights! Camera! Software!

Pulling Value

There’s no turning back.

It’s not whether a company’s IT functions are agile or not, it’s whether they are “really” agile, how they are agile, whether they can “scale” agile, whether they have adopted continuous integration, are a true DevOps shop, and on and on. With this sea change there are victims; methods and paradigms that look hopelessly out of touch and frantic in their attempts to keep up with the times. My company recently dropped the requirement to be certified by the Project Management Institute as a prerequisite to earning their own internal certifications for engagement management. ITIL is reinventing itself as I pen this missive, claiming they never promoted a particular “process” and blogging that “ITIL can be agile” practically as an apology.

In some ways, this reaction is unfortunate. What we’ve learned from the shiny objects of decades past—Lean, ITSM, BPI/BPM, PMI, Requirements traceability—still has real value to offer value to today’s IT environments. Much of what we’ve learned still offers insight on how to get work done that needs to be done.

Let’s give agile credit where it’s really due… not to the planning poker cards, the shirt sizing, the scrum boards, sprint length, the bake sales, the epics/features/stories/, the pigs and chickens, the BDD / TDD, the “get to done” mantras, the anti-documentation, the “no deadlines” nor to its latter day offspring of continuous integration and DevOps, but to core principles that make agile a truly valuable contribution to the way we do work. If we changed nothing about the trappings of how the corporate polity does IT but adopt several important principles of agile, organizations will truly transform in important ways that will shake off some of the lipstick we’ve been putting on pigs’ lips these past few years.

The first, and most critical, principle is to pull value. This is to contrast with pushing scope. If the organization truly emphasizes, and puts controls in place that enforce that emphasis, on doing only what is valuable, doing what is most valuable first, and honestly, continuously, assessing the value of previously sacrosanct IT practices, then it will be a more agile organization.

More agile than what? More than one that has implemented every metaphor of SAFe and managed to retain all of its middle managers in the process, as the program increments of its months old project plans yellow with non-valuable age. Or more valuable than stoplight status reports without plans of action, just like typical issue / risk logs. Or adding layers and layers of functional testing, possibly at the expense of doing more pertinent testing, like security scans and performance testing that address what users in today’s environment need to have be true about their software.

So how do we pull value? It really boils down to hard work, especially from the business. Software is never an end in itself (unless you’re a software vendor, and then you only exist because of a marketable business need). The agile principle that “business people and developers must work together daily throughout the project” is a literal principle. It’s a daily thing, there’s no work around. I know I’m challenging the hard-core agilists here, but I would also suggest that the efficiency gained by insisting on only one product owner as a conduit for evaluation of all that is valuable might be over-emphasized. If the product owner shows any sign of lacking the insight and/or necessary feedback cycles to know what is valuable, or worse, is over-assigned with other work, then the development team needs to work at getting the value verdict from all possible sources before doing the work. Every single requirement, every single story, needs to be subjected to the question “what is the cost of doing nothing?” It is not true that agile is not cost-conscious. It is not true that agile is easy. Simplicity is not easy.

[widget id=”custom_html-68″]

This of course means that the principle of “welcoming changing requirements… [to] harness change for the customer’s competitive advantage” needs to be embraced. Don’t stop efforts to “scope out” a complete solution when deciding that software (or any “ware”) needs to be built, but appreciate that much of what you think is important today can and will be on the cutting room floor tomorrow. It’s always a good idea to think about and study a business problem to determine if the problem is really even solvable with software. The notion of “start with an index card and write code on day one” is romanticized and a bit silly. But rework is like death, taxes, and the weather. You won’t avoid it, so minimize its deleterious effects by continuing your gravitation to what is truly valuable.

What I have found in my coaching assignments is that if we start with structure and constraints—how long will our sprints be, do we use points, should we do Gherkin, how many testers do we need on a scrum team—instead of principles—what will promote inspection, adaptation, and transparency, do we build around motivated individuals and do we trust them to get the work done, and are we maximizing the work not done?–  then we get results that resemble the very real problem of having the cart positioned ahead of the horse. Time is always precious, and you’ll risk not having enough to get to teaching, promoting, and implementing right principles. So start there.  

The power of Covey’s “Seven Habits” is really its admonition to live a principle-based life, and the wonderful thing about agile is that it is girded with great principles. The four manifesto tenets, the five values, the three pillars, and the overriding almighty law to “do what makes sense” are exactly what really matter to achieve an agile transformation.

Becoming agile requires a sea change in the hearts and minds of people who run organizations. Frankly, the growing prevalence of “solutions” that scale agile are too often thinly veiled attempts to preserve mechanisms that reflect old ways of thinking—most poignantly, of preserving management functions that simply don’t contribute[i] value. The old-schoolers have been steeped in the cult of scope. “Scope creep” needs to become a meaningless concept because we’re not slaves to scope any more, we’re evangelists for value.

Focusing on pulling value doesn’t de-value the lessons we learn from ITIL about running IT and delivering customer-centric value every day, or the importance of recognizing and mitigating risk that PMI teaches. Budgets are still important and all the skills of bottom up estimation and planning based on available resources are needed. It’s PMI’s emphasis on some holy place for “full scope” that need to be deprecated, not all of the valuable management skills PMI demands and tests for in its grueling PMP exams. You can have the best hammer and be motivated to use it, but you still need to know where to put the nail and understand how many you have available to build the house. Expectations about when and for how much are still important.

Start with value, end with value, and every day self-examine what you are doing to provide value by asking if what you’re doing is the most valuable thing you can do today, given time, resources, and the needs of your customer. If your organization can do that together, it’s already transformed. [ii]


[i][i] The Agile Manifesto, from  Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim HighsmithSteve Mellor; Arie van Bennekum; Andrew HuntKen SchwaberAlistair CockburnRon JeffriesJeff SutherlandWard Cunningham; Jon Kern; Dave ThomasMartin Fowler; Brian Marick (2001). “Manifesto for Agile Software Development”. Agile Alliance. Retrieved 14 June 2010. [i]

[ii] Scaled Agile Framework, from Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley. 

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

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

Program Management and the Four 8s

To borrow from Mr. Clemens, “reports of project management’s death are an exaggeration.” Despite the scrum alliance’s attempt to bury the Caesar that is PM, not praise it, project, program, and portfolio management are still viable roles in information technology development projects. While I believe in eternal principles of project management and appreciate the rigor with which they are put forth in PMI-endorsed literature, I also am keenly aware of the need to adapt and learn new strategies to add value in agile development environments.

So I will try to stay a step ahead and package a paradigm to succeed as a PM in our digitally transformed world. I’ll also spare you the tired catch phrases and buzz words that you’ve consumed over the last couple years in exchange for different catchphrases and buzz words that I’ll expound upon in this little writ. Four 8s (think phonetically here). The project manager in a digitally diverse world needs to pay attention to the four 8s. Assimilate, Integrate, Mitigate, and Escalate.

Even the most humble development effort in today’s environments implies multiple work streams. “Stand alone” and “desktop” are quickly leaving our collective IT vocabulary, delegated to proofs of concept at best. Connectivity isn’t everything, it’s the only thing. The PM needs to approach any development effort with a mind to assimilate all of the working parts into her universe. If the project is to create an app, where does the information come from and where does input go? What happens when I put down my phone and go to my computer to engage the application or solve the same business problem? What is feeding the app, what secures it from hackers, and how does the sponsoring corporation productively disseminate the fruits of their digitally transformed labors?  That small, self-organizing scrum team, replete with cross-trained developers, testers, and a product owner, actually need to get with others before their creation is in the market. If they move swiftly and the supporting infrastructure and its requisite data stores don’t keep up, what happens then? Or, more to the point, who might get in trouble?

Assimilation presumes layers. The PM needs to assume that each layer, each contributing part, needs to be organized and managed so that they are stacked in a way a good cake is stacked; ready for the frosting, ready for market, ready for some return on investment to the sponsoring organization. The PM might be charged with managing the production of an app, but in today’s world, needs to become intimately familiar with all the parts of that app’s ecosystem (ugh, there, I said it, with sincere apologies to biologists and scientists everywhere).

Familiarize yourself with each work stream that together will compose the whole when that scrum team produces working, marketable software at the end of a three-week period. Diagram the work streams, noting who owns them, what tasks are done to have them ready to play, and what distinct outputs you’ll want to monitor. For example:


PMs create work breakdown structures as a matter of course. The “assimilate” output example above might be called a work stream breakdown structure. Understand the whats and the whos of your world, even if you don’t control all or most of the streams. Assimilate.

The next “8” would seem pretty logical. Unless the project is to build a bunch of silos, you need to know where and when the outputs of these work streams touch. “What” and “Who” need to dance with “Where” and “When.” You personally might not be able to control the outcomes of all the dependent efforts, but if that is the case, you had better know where, when, and how those dependent outputs control you (and objectives that you own). Even those silos, to stand and function successfully on your farm, will likely need contributions from more than one vendor if you want to ship in one truck or store in one barn. Integrate what you have assimilated.


So Assimilate and Integrate now march along like the proverbial horse and carriage. Out of what dark space might I have pulled “Mitigate” as a third component of said quartet? I’ll admit to cheating a bit here for effect, because there are other ways to address risk than to lessen its likelihood. But risk is really what all PMs need to manage. Mitigating risk is more often than not the treatment strategy, especially when the risk is around dependent work streams.

Everything on a RAID log is the spawn of risk. There’s risk that’s called risk (that’s the R). Assumptions are actually thinly veiled risks. We assume something to be true and state it so that we have currency to react and take action when it is not true. Issues, per PM 101, are realized risks or just plain stuff that flew through the air and landed in your project–that is, risks that you didn’t plan for. And dependencies are the nourishment of risk. In some textbooks it’s called “convergence” or “convergent” risk. In the programmatic sense, it’s dependencies that demand extra scrutiny and require mitigation so that someone or something won’t move your cheese into the other room.

Any time we depend on something outside of our circle of influence or control to achieve our objective, we put our objective at risk. The PM needs to assess all of the touch points and measure the burn, if only to be in a position to say, with all humility, “I told you that this might happen.” But more than that, the responsible PM will work to assure that all the “self-organizing” teams going about their business are traveling to the same destination. As the PM, you are the road smoother and the air traffic controller. Mitigate, mitigate, and mitigate again.

Murphy wasn’t the only one to be vulnerable to the inevitable, the worst case scenario. Actually, we should call it “Everyone’s Law” or maybe the second law of thermodynamics, the tendency to chaos. Stuff happens, and the fourth canto of the PM’s psalm is to escalate. What I mean is “get it out there” and institutionalize escalation so that it’s a fire drill executed, not a tragedy akin to running with bulls.

So what if something does go wrong? Of course we want to have a plan B, but even more importantly, we need a process to assure that everyone who needs to know will know that plan B is in effect. Escalate departs from the other three in that it’s not something we want to actually do. But we want to know how to do it when it’s necessary.

I perhaps could have gone with “illuminate” to emphasize the importance of transparency and full disclosure when things go awry, or even “communicate” to make my paradigm less jolting. “Illuminate” is a bit too allegorical for your average, anal-retentive PM, and “communicate” is just too damn pervasively self-evident, worth its own screed. As PMs, we can relate to escalate. We escalate every time we submit a change control. We escalate when we can’t make bad things go away through our own efforts, which is often. Escalate can refer to simply dealing with conflict. Escalation is not for the timid. The PM that delivers the bad news in a timely and actionable way is the PM you want to hire. I probably struggle with this 8 more than any of the others, but as I get better at this moving target called project and program management, I realize that I’ll need to do this verb more often in the future than I’ve done in the past.

Project managers need to be agile too, if only to dodge the flying debris and live to manage another project another day.

Don’t forget to leave your comments below.