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.
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 Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin 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.