Skip to main content

One Simple Trick To Combat Date-Driven Development

Nothing sucks worse than a company touting itself as "Agile" while failing to adhere to Agile philosophy. It's easy to spot - just pick any leader from your organization and ask them to recite one of the core values of the Agile Manifesto.

Yeah, sure, let me just go grab the CEO and put him on the spot. That'll work wonders for my career.

 Good point. That's not exactly the smartest political move in the book. Besides, there's a far easier way to tell, especially if you're on the receiving end of task- or project-requests. Simply pop that email open and scan for the tell-tale signs of a fake Agile mentality: everything is framed around time.

Any of these ring a bell?

"We really need this review quickly."

"Any chance you can push this out today?"

"The team is looking to have this all wrapped up by next Wednesday."

So much for the sprint, right? But even if you're using Kanban instead of Scrum (ostensibly allowing for tasks to constantly flow in), you still aren't plugging these tasks into a Gantt chart...so why would these folks think you could commit to a date?

Because no matter what stage Agile has (or hasn't) yet been embraced by your organization, there is still a department somewhere that doesn't feel like it applies to them. They get special treatment. Their leadership still dictates dates, and that urgency bleeds over to your team when it comes time to ask for your help.

The solution is very simple:

  • When drafting a user story / kanban task based on this request, strip any / all references to time - keep the details of the request front-and-center.
  • Tell the customer their request is in the queue and will be examined in the next sprint (if Scrum), or will be delivered per your SLO (if Kanban), based on your cumulative flow diagram's estimates.
If / when the discussion turns to delivery dates (and not being able to meet them), remind them:
  • You'd be happy to discuss your team's allocation in further detail...where you will make it painfully clear where the constraints lie, and
  • The constraints are necessary, as your team has committed to being Agile, per the company's guidance.
You'll get push back. You'll get folks that consistently inject time-based expectations into their requests. You'll even see the dreaded "I'm CCing my manager as an additional strong arm" tactic. 

Stick to your guns.

If there's one complaint most naysayers receive about Agile failing them is "oh well you didn't do Agile correctly." Understandably, this criticism lacks a nuanced perspective of the larger picture -- that very often, other parts of your org fail to embrace it (or are unsure of how to). 

So. Set the stage. Lead by example. If Scrum, then Scrum...and if Kanban, then Kanban! And be sure to communicate those constraints back...even if you sound like a broken record.

Yes. You're right. They should know this stuff already. But something...just out of your reach...is getting in the way of that. So the best thing you can do is adhere and be firm. With time, they'll get it and adopt (or give up)...but at least you'll be able to state the company gave you the plan (Agile)...and you followed it.


Labels:

Popular posts from this blog

10x Developers, Compassionate Bosses, and Other Mythological Creatures

The myth of the 10x developer is so pervasive, debate as to whether it actually exists continues to this day. Crazy talk! Next thing you know, they'll be claiming there's such a thing as a manager that actually cares about your psychological well-being. The audacity of such a thought! How foolish! How positively naive! Allow me to propose a radical notion: What if they do exist, but are just so hard to find, nobody believes it? Allow me to propose one more: What if we're having a hard time finding them because we can't agree on what defines such a creature? Not A Thing Let's start with what a 10x developer is not (something we can all agree on!) A 10x developer is not a developer that writes ten times more code than their peers, A 10x developer is not measured by SPH (Semi-colons Per Hour), and A 10x developer is not someone who makes their teammates 10x better. 1. Amount of Code: Doesn't Matter Ask any programmer worth their salt and the...
Read more

How Do I Use Myers-Briggs To Assess My Team?

Question: How do I use Myers-Briggs to Assess My Team? Answer: You don't. Seriously. That's my answer.  Don't do it. Still reading? (sigh) Alright, if we're going to do this dance, let's get it over with. Myers-Briggs is Junk Science When a hypothesis is tested in a controlled experiment, proven, and those results are vetted by independent peers, you have yourself a little thing we like to call scientific evidence. Leave any of these on the table (eg. you make a hypothesis but don't run an experiment), all you have is opinion . The missing piece in Myers-Briggs (or MBTI) is that last part: independent verification by peers . Scientists uninvolved in the hypothesis need to be able to reproduce the experiments and put their career on the line by saying, "Yeah, this other scientist I don't know anything about...they're 100% correct." The only "verification" that Myers-Briggs has is via the Center for the Application...
Read more

A 10x Developer != A Leader (And Why That's OK)

In a perfect world, we'd enjoy teams bursting with natural leaders, self-driven individuals who can handle any situation under any degree of pressure, identify and prioritize the tasks, assign and delegate said tasks, encouraging and mentoring each other, until the team jells with profound efficiency. In the real world, there are plenty of teams adept at software construction that produce amazing creations and are comprised of developers that possess   absolutely zero interest in becoming leaders . Nor is it necessary. In order to get to the bottom of this, you're going to need to know the secret ingredient: Band-aids. The Life of Expertise Let's start this rant by understanding what it means to be a 10x developer: a developer that is  measurably proficient  at what they do (for a greater breakdown of the 10x developer, read this related post ). Gaining proficiency in a trade is a result of either: increasing depth , or increasing breadth of knowled...
Read more