Well, This Doesn’t Seem Agile
I’ve worked in Agile Theater before. It’s pretty ineffective and disappointing. Most companies that claim they’re “doing Agile” are just trying to avoid requirements or accountability for delivery altogether.
I’m not the first person to write about their distaste of Agile when companies do it poorly. One of my favorite quotes comes from this article by Michael Church where he discusses the false dichotomy when compared with waterfall:
Waterfall replicates the social model of a dysfunctional organization with a defined hierarchy. Agile, quite often, replicates the social model of a dysfunctional organization without a well-defined hierarchy.
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
I would normally burst into a regular tirade about MVP, but that’s for another post.
At my current organization, it’s even worse than that. We like to say we’re “doing Agile,” but in reality, we’re just making a bad system worse. We have a long track record of letting IT overrule the business when it comes to deciding what to deliver. It’s common for the business lead to submit requirements asking for X, only to hear back months later that IT has decided they instead need Y, and that it’s being built to the specifications IT has defined for them. This obviously is a terrible way to do business.
Making it worse, we’ take projects and split them into sub-projects, which we call workstreams. Then we charge each of those workstreams with drafting their own charter, thereby making them technically individual projects. OK. maybe that’s acceptable, but not really. This dilutes accountability for the project that has now been carved into a bunch of pieces.
Just Do Some Agile Charters
So each of the workstreams gets assigned a product owner, who has to complete a project charter. Fine. And then they update it every week with milestones and current status, which is very much not how a project charter works. The fact that the “project charter” is a single PowerPoint slide leads me to believe there’s some general misunderstanding about what a project charter is and the purpose it serves. There’s room for a sentence or two to describe the business justification, another couple sentences for the goals, and a block to accommodate a scope definition of maybe three or four sentences. What’s not to love about this? I guess you just throw in some weekly status updates and revise your charter every week, amiright?
Anyway, so the product owner puts together the business requirements and then works with the development team. He or she does this via the product owner on the development team. Because you always want to have multiple product owners, right? It stands to reason that if one product owner is responsible for the business vision and its delivery, then having two product owners much make the delivery output twice as much. Or the speed twice as high. Or something. On a serious note, the idea behind having a product owner responsible for prioritizing business needs and delivery is so that there’s one single point of accountability. Having two (or more) product owners eliminates that accountability and creates confusion as to who is responsible.
We went through one two-sprint development window after I handed off requirements that are completed, reviewed, and approved by all stakeholders. I was pretty happy with getting sign-off in August for an October-November development window and delivery by end of November.
Just Do Some More Agile Requirements
I was told I couldn’t add requirements directly to the backlog as user stories (because — you know, that’s the other product owner’s job) and they really need to also do the requirements first. I assume this meant they had to do technical requirements. Nope. They drafted a business requirements document. Much of it was copied/pasted from mine. My concern was that it could deviate from what my requirements (which I would think are the binding ones) laid out and had been been approved by stakeholders, but that didn’t happen. But the other product owner did have to go back and work with the business to “flush out the requirements” for her document. She included me as a courtesy, though was clear her customer was “the business” (also: that’s me!) and scheduled all of her meetings for times that I had conflicts.
Eventually her document was complete, though nobody approved it because they realized while there was only a few days of work effort, they were now in the fifth week of the second three-week sprint, which means they only had a week left, so they wouldn’t be able to do the development. They literally spent five weeks doing requirements for a project that already has completed requirements, instead of delivering product.
Just Reschedule Everything
So, when can we do it? Q2 of the following year? Sure, that’s a recipe for success.
But now it’s technically on time!
It would be dishonest to say this wasn’t expected. I’ve had this experience before. More than once. It’s just incredible we never learn from it.
Just Do Some Agile Documents
While we’re waiting for the next development cycle, we’ve revised the templates for our Epic document. I don’t know what that means in the context of how it’s being used, but it appears to be a hybrid of a business case (justification) and scope document. My project has four phases, three of which are complete. I’m being asked to go back and create “Epic documents” for the first three phases. You know, since we have a new document version.
The work is done. I don’t know why you would draft a business case or try to define the scope of work that’s completed, but when I raise these questions, I’m told that it shows we have thought through it.
Please send help.
