Three Common Pitfalls of Implementing Agile Methodology

By James Dobbs (https://www.linkedin.com/in/james-david-dobbs)

The Agile methodology is a powerful tool that can increase the success rate for project delivery, decrease delivery time, lower the rate of troubled projects, control budget overruns, and increase team morale. As a result, many organizations are hastily moving projects onto the Agile methodology that may not be suited for it. This can cause massive negative impacts and destroy entire programs.

Issue #1:

Determining when Agile is effective and when it is not.

When properly applied to projects where it is well suited, Agile is an extremely valuable tool with myriad upsides and few to no downsides. If Agile is misapplied to a project, the results can be disastrous. Every project should be reviewed on a case-by-case basis to determine if the Agile methodology will be useful. One can do this by asking themselves the following about a project:

Q: Is the problem to be solved simple or complex?
A: Complex projects are a better use case for Agile.

Q: Are the solutions initially known or unknown?
A: Agile works better when project solutions are unknown.

Q: Are requirements set in the beginning and unlikely to change?
A: The Agile methodology is better for projects with changing requirements.

Q: Are end users able to collaborate and give feedback?
A: Agile is better for projects in which end users can collaborate closely and provide feedback.

Q: Is the work modular, and can it be conducted in rapid iterative cycles?
A: If the work is incremental, Agile is a more favorable methodology.

Q: Are late changes manageable, or are late changes expensive/impossible?
A: Agile should only every be used when late changes are manageable.

Q: Are end users unable to start testing parts of the project before the whole project is complete?
A: Agile only functions properly when iterative testing can successfully inform development.

Q: Are mistakes during the project low-cost opportunities to learn and make improvements, or are mistakes catastrophic?
A: Agile should only be used when mistakes are low-cost opportunities for improvement.

Issue #2:

Management must trust teams to set their own velocities for issues.

When a cross-functional team comes together to evaluate an issue that needs to be addressed, they determine their collective domain knowledge, experience, and the ability of all necessary parties to sync up and collaborate on aspects of the issue. These factors create an inherently unique team to which past teams (or hypothetical ones) cannot be compared. These are the factors that a team uses to determine the velocity on a project and for Management to collapse or expand that timeline can introduce chaos and undermine the Agile methodology.

Issue #3:

Agile must be customized, but not too quickly.

Do not use the Agile approach to customizing Agile. Only after using proven approaches, rules, and methodologies that have delivered success in thousands of companies for hundreds of thousands of projects (and perfecting them) can an organization move to customizing Agile to fit their needs.

Agile must be iteratively improved. Once a team is ready to make changes, the should track not only the metrics they’re looking to improve, but also any effect on key performance indicators, including team morale. If slowly and systematically optimized, an organizations homebrew version of Agile can become more powerful than the base Agile methodologies. If properly implemented with skilled cross-functional teams on appropriate projects, the Agile methodology can set an organization and its teams up for unparalleled success.

IT Projects – What’s Most Important

I just finished a project to upgrade a state university to Citrix Virtual Apps and Desktops (formerly XenApp & XenDesktop) v7.15 LTSR CU5 and Citrix ADC (formerly NetScaler) v12.11.55.

We follow a engagement methodology we refer to as A.D.I.M.E.. An acronym for Asses, Design, Implement & Evolve. Obviously some engagements are heavier on some of these phases, and lighter in others; however EVERY engagement will have each one of these phases to some degree.

Our customer came to us with this project stating their business need to upgrade their entire Citrix deployment. They are a returning customer to us so naturally we’re glad to work with them.

As we do with every engagement we start out with the “A” for assessment around the customers stated business need and put a Statement of Work (SoW) document specifying some engagement milestones. At this point we have a good idea of how much work (and perhaps product) will be needed and the customer knows how much the work costs and can schedule around it as needed.

Great! Everyone knows exactly what to expect and is getting what they want out of the engagement for agreeable consideration. All is fine right?

Except in the real world, the customer says :

“we think it should only take half the time”

WHAT?!?! I thought we were in agreement!

OK, regroup, perhaps we had differing pre-conceived notions. Go back to the customer and find out which milestones the customer can do without in order to cut the time in half. after that conversation the customer comes back with :

 “we still want to get it all done, just in half the time”

Ah. I get it now. the customer has time constraints or a deadline to meet. No problem, we can work with that. We’ll assign a second resource or another person to get twice as much work done in the same amount of time. OK! we’re all good with that. Now in this third exchange the customer gets to the point with :

“we only want to do this for half the price”

Grrrr….. regroup, perhaps we again disconnected on proprieties here. We like business, we like to keep busy, heck we certainly like to have customers. We can make this work. After all, half of something is always better than all of nothing. I got it. let us push out the schedule to a time when we’re slow anyway or have resources sitting on a bench – unutilized. Lets get back with the customer and see how flexible they can be. Of course, guess what we get back in return :

“we need it done right away”

What the…!?!?!? We started out so good with everyone in agreement – didn’t we?

So let me summarize. We have to get everything done in half the time, for half the price, done right away – right? That’s not too much to ask is it? no mention yet of the quality of the work. No worries if we deliver on time and on budget, but the system falls apart in 10-days.

Naturally our quality is our reputation – so we cannot compromise on that. Even if no one has considered it once in the course of this conversation.

So how did this engagement go for this university? We got it all done on time and it will last.

So what was lost? A) a lot of hair (as it was pulled out from stress) – both for the customer and the consultant. Moreover the assessment, design & evolve in the A.D.I.M.E methodology was stricken from the list – no time for it.

Foraging ahead to get this done meant working with blinders on. Ignore anything not directly related to the objective. See a misconfiguration, determine relevance to the objective and ignore it if none. Documentation, knowledge transfer – skip it. Recommendation for improvements – no time.

Even when you know exactly what you are getting for your money, you will never know what you’re compromising with the savings.

– by “The Resource”
11/16/2019