Your Project Has Gone Sideways…Will Agile Help?

<cue Mission Impossible theme music>

We have a project in distress. For some reason it has gone completely sideways. Your mission, if you choose to accept it, is to figure out why and see if Agile is the miracle pill that will make all the project worries go away. 

This blogpost will self-destruct. 

<end Misssion Impossible theme music>

Ok. Chill out. My blog won’t self-destruct. 

…Although you may want it to…if you don’t agree with what I have say! ??

Is Agile the answer to your problem project? 

Well, 9 out of 10 Agile Practitioners agree that the answer is…

“Maybe?” 

I’m just kidding, 9 out of 10 Agile Practitioners are going to blame your lack of agile, because what else would you expect an agilist to say?  

But I’m the 1 out of 10 that is here to tell you, the answer is maybe. 

Apologies if that isn’t the answer you were looking for. Maybe you were hoping it could be more binary than that. The reality is that I have never seen a project fail in a way that can be traced back to the particular methodology. Typically projects fail because 1) a business wanted it to fail or 2) because the team felt pressed/coerced/or opted out of following whatever methodology was supposed to be in place. Agile is awesome and I am all in. But, the reality is that it is only as good a methodology as the people involved. 

Regardless, let’s take a look at what might be going on and, based on that, what the right solution to your broken project is. 

Case #1: The project is behind schedule because business and technology groups are not aligned. Development teams are unsure of the requirements and there is too much lag in the feedback loop such that deliverable commitments are slipping.   

Ok. Cool! Yes, this is easy. This is a classic example of a situation where transitioning to Agile will absolutely help bridge this gap and accelerate the project. Without knowing how far behind the project is, I can’t guarantee that the project can be returned to its previous schedule, but I can guarantee that putting business and technology in the same room creates more solid results that allowing a wall to persist between the groups. 

Case #2: Business owners won’t show up to meetings. 

<cue needle skipping sound on the turntable>

Hey friend! We’re Scrum Masters, not Magicians. We can’t pull rabbits out of hats. If your project teams are working harder than the business to make sure a project is successful, then you have a problem that is bigger than the project.  All the methodologies in the world can’t fix an apathetic business…

BUT…

..and there is a big BUT…

…take a moment to look in the mirror. Ask yourself? Is there something I have done or my team is doing that would have turned the business off? I’m not trying to victim-shame here, but a little self-awareness is always healthy. 

If your business has stopped participating in the project it may very well be that they are frustrated about something. Maybe they see no value in your meetings. Maybe they suck time and don’t add anything positive to your business leader’s day. Most detrimental, maybe they are disengaging because they have lost confidence in your ability to deliver. Maybe, you’re completing project cycles, but failing to delivery anything that moves the needle for your project stakeholder?   

If either of these are the case, then ABSOLUTELY and WITHOUT A DOUBT…this may be a good time to discuss changing how you organize; and, in so doing, maybe agile is a viable alternative to how you are currently delivering. 

Agile is 100% about constant, repeatable, predictable value creation. Want to keep your business users interested in what you’re doing? Make sure you’re constantly proving your value and all of a sudden your meetings will be SUPER interesting to them. 

I would suggest you schedule a come to [insert deity of choice] meeting and discuss why the business owners have stopped prioritizing your meetings or the project you are running. Maybe they are waiting for your teams to produce something that gets them excited. Discuss that valuable something that might make the business believe in the project again. It might just be that increasing the cadence of delivery and ceding some control to the business owner will change their view of the project and make them feel like they are part of the solution.   

Case #3…this is complex stuff and we don’t know what we don’t know.  

Oowa! (sorry, Hebrew moment). This is a good one. This is a classic case where Agile is such a great project de-risking agent. When what you are tackling equates to the size of an ocean, it would be daunting to try to tackle building the entire ocean in one fell swoop. Agile is the perfect solution to this because the methodology would NEVER recommend you take on something that large. You might recall in our Waterfall days, we would take the entire scope and attempt to distill it down into some Work Breakdown Structure comprised of Activity Definitions and Activity Sequencing that would show on a broad scale, the work items that needs to be prioritized and the relative order in which those items would be completed. Agile is really quite similar, in this regard. Except the effort to create super small chunks is far greater. Why? We won’t to wait 2 months to course correct on something that should have been redirect in week 2 of said 2 months. We are going to ask, what can we focus on for the next 2-,3-, max 4-weeks that would validate a project requirement or assumption. 

Here’s a cautionary rub, though. This process may make the project take longer…overall. BUT, during the project, consistent valuable widgets will be delivered to the business that will validate project decisions and prove that the project is directionally heading against the right vector. Additionally, along the way, the business will be actively engaged and will be validate their assumptions on the same cadence. Remember the project you delivered after 12 months of sleepless night, long weekends and time away from your family, only to find out that what you delivered was completely useless? Take that feeling and now imagine it manifesting after 2 weeks instead of 12 months. You can fix something after 2-weeks. After 12-months, the project funds are exhausted. 

So, I can’t promise that by shifting to Agile the sideways project will be able to return to the previous project deliverable schedule. But, I can promise that the revised plan will provide a working product in Production of verifiable value to the business that has been tested and approved and is ready for adoption. Concessions may be made along the way, but the super complex business problem will have been tackled.   

Case #4…the project team supports Agile…but the overall organization doesn’t. 

This is a tougher one and, frankly, it is the situation I am faced with most often as I continue to navigate through my journey as an Agile Coach. A lot of companies think that they can “pilot” Agile in a single business unit or even a unit within a unit. The fool’s errand in this is the false hope that a little bit of Agile creates a lot more Agile. This sadly is not a strategy that I have seen deliver sustainable results. Very typically, as soon as the Scrum Master leaves the building, so, too, do all the agile ceremonies and rituals that were so dutifully followed when he/she was around. 

Moreover, in my experience, what happens is that the executives not “required” to adopt agile take no responsibility for making sure the pilot is successful. In a sense, this actually undermines agile as a practice because it conveys a top down attitude that agile is optional. When a methodology – any methodology for that matter - waterfall, agile, spiral, XP, whatever – is viewed as optional; it creates a self-fulfilling prophecy that the project will fail. Totally my opinion…it’s just cheaper to cancel the project. If how your organization executes is optional, then clearly persistently creating value is optional, too. 

Think of any iconic brand or product or service. Simultaneously, try and think about where that brand would be if their commitment to who they are how they deliver were viewed as optional. Your project methodology should be no different. How you deliver is fundamental to your success as an organization. Success should never be viewed as optional. If this is the case for your project, I would encourage you and your leadership to reconsider why you are doing the project in the first place. Perhaps the capital dollars could be better spent on something else. 

Even organizations as large as AT&T are starting to take heed of this notion. Look at their latest line of commercial around the tagline “Just Ok is not OK.” (Here’s a link in case you have not seen their commercials yet, AT&T - OK Surgeon Video) . Agile is no different. We are not seeking “Ok.” We are seeking “Yes, this is what I want!” Definitive. Unequivocal. Binary. I like binary. I’ll even take “Yes, but…” that’s acceptable. But not “Well, it’s ok…”

I could go on, but I’m sure I have exhausted your attention. There is so much that could be unpacked here and I’m sure I could write on a book on it. 

What cases have I missed? Feel free to offer your comments and feedback.  Feel free to suggest a topic for a future blog! 

Best,

Jonathan Goldstein

McKinney, TX