Tell me this never happened to you ..
You ask a question ..
”Hey, how are we doing on the project? Will we deliver the agreed upon business capabilities? Are we on track to deliver?”
And the answer you receive is … “It depends … you know, we are Agile, so I will not be able to tell you”.
And you want to go and tear your hair out.
We lived unhappily ever after under the beautiful Waterfall …
In the olden days of the 1980's, we really didn’t think too much about SDLC (software Development Life Cycle). In those days, massive books were written, with extensive table of contents, executive summary, headers, lots of footnotes, appendices … Yes, you got it! Those books were the infamous BRD’s or the Business Requirement Documents. A group of magical creatures walked around the halls of the menacing corporate offices, read people’s minds and spent months writing those books!
In most cases, technical designs were finalized way before the BRD finalization, at least in the minds of another set of wizards who called themselves architects. They couldn't care less about the BRD’s or any other form of requirements, because they belonged to the hallowed “know-it-all” clan! And they were not good writers, so not much was actually written down. It was mostly communicated using Vulcan mindmeld.
And then, all these were handed to the hapless bunch of people like me, who were the lowly programmers. Good luck if there was a slightest change in the requirement! The all-powerful “Change Control” was summoned, revisions to BRD’s had to be made and … you needed to rewrite the programs while everyone else was busy finger pointing and throwing each other under the bus.
We gave a name to this process … we called it Waterfall. The general managers, who repurposed themselves into IT leaders and eventual CIO’s and CTO’s, barely understood any of these and relegated to asking two questions … “how much” and “how long”. And, we came up with an estimation method using a brilliant measurement … “man months”! Fun times!
We evolved into RUP (Rational Unified Process)
Not too different from Waterfall, but more like a bunch of little cascades, RUP was all about learning iterative development. In the late 1990’s we were riding high on the dotcom boom and it seemed like the new gold rush where all of us migrated to Silicon Valley to get a piece of the action. The traditional Waterfall model was too slow, too expensive and too unpredictable. With our focus on object oriented programming and web-enabled processes, we scrambled to learn this new framework for organizing work and teams. It worked well for the new initiatives.
The confluence of Product Management and Agile
A phoenix rose from the dotcom crash in early 2000. With some rudimentary maturity in web based product and technology, we really started understanding the power of “digital” and it led to the confluence of traditional product management and software development. SDLC started evolving into PDLC or Product Development Lifecycle. Along came Agile, the new way of thinking and collaborating. We retained the best part of RUP - iteration - into Agile and moved from organizing teams into truly managing the lifecycle of a product.
Agile has Failed! The sky is falling!
And, now, there is a new war cry … Agile has failed! It did not work. We could not deliver solid products. Must be the fault of Agile.
The first question I will pose is - do you even know what Agile means? A lot of people “pretend” to speak Agile, without absolutely any clue! Very similar to “mansplaining”, I call it “Agilesplaining”. People don't really understand the fundamental principles of Agile and instead repurpose the usual way of doing work and call it Agile. I have seen organizations jump into Agile without realizing that a certain maturity in product management is a prerequisite! You cannot just go create some “Agile teams” without establishing a product hierarchy, and then happily interchange Scrum, Kanban, SAFe ….
And … then all the KPI’s! Agilesplaining in action! How cool is it to just call an IT ticket a “User Story”! And then with no understanding of story pointing, assign a random value in, yes, you guessed it, “man hours”!! You don’t know what a sprint means, yet you track “burndown charts”! Ooh, another good one … “velocity”! And .. don’t even get me started on Quality Management metrics!
Think about it this way … you are driving a car, but don’t know how to read the gauges. You don’t know how to assess fuel, speed, temperature, or RPM. You start driving without realizing that you did not fill the tank. The car comes to a stop in the middle of a freeway! Should you blame the car for malfunctioning or should you be honest for one second and realize it has been you all along!
Don’t blame Agile for the failures of your initiatives. First assess whether you even know what Agile means. Not the car, but the driver!
The second question I will pose is .. how does work get done in your organization?
There are some people who can get shit done, no matter what. In effective organizations, you have more GSD’s (Get Shit Doers), and in ineffective organizations, you have much fewer. Typically you have between 1 and 20% GSD’s in an organization. And there are the rest of the folks, who spend time in corporate politics, weaving stories, playing blame games, and yes, taking credit for the work the GSD folks do.
GSD’s are not constrained by methodologies or frameworks. They know how to adapt and learn newer and more efficient ways of doing work. They don’t spend time making excuses for lack of delivery. They figure out a way. Most importantly, they know when to use which framework. For example, when you are doing a large scale system implementation, they know how to blend in Waterfall and Agile. They know Agile is not an excuse for not planning or committing. They know what it takes for a new product launch versus subsequent functional releases.
The problem with any framework is the rest of the organization. Sadly, many of the corporate leaders belong to the Non-GSD clan. You can only imagine what crazy stuff happens in those organizations! New product launch is planned without a clear understanding of the “Final Product” or a product roadmap. Large system implementation projects are planned with a bunch of Agile teams without any idea how to synchronize and orchestrate to plan for launch. And the list goes on and on and on.
Stop blaming Agile and take accountability
I suggest taking a pause from the corporate games. They are, frankly, boring. There is no real excitement and they don’t even have fun things like Taylor-Travis romance to spice things up!
Stop talking about whether Agile has failed.
Instead, take accountability. Focus on the GSD’s of your organization and empower them. Remove roadblocks so that they can shine and deliver.
And, then, you can jump back and take credit for their work :-)
Related Posts
