Are we ready to adopt Agile ?

If you are determined to adopt Agile there are a few things you need to understand and embrace before you begin a journey into what many people assume is something close tp Ninja-like Agility.

Agile ? has been defined by the Agile Consortium as a philosophy. You really should read and discuss the Agile Manifesto with your executive team. There are four core values that Agile? embraces. There are also 12 principles of Agile you will put into practice, and to keep things interesting, there are over 40 known variations to what is loosely called Agile ?.

Agile is definitely not an excuse to avoid documentation or planning. Agile embraces change and dynamically adjusts the requirements (Scope) to keep the budgets, schedules and quality as they were intended. Read this again: Agile does not give you carte blanche on getting a Christmas wish list completed in June. You will get the most important features (requirements), but it is rare to get everything you want because features and entire feature sets are eventually prioritized into Must Have, Could Have, Should Have and Won't Have "buckets". . . insert a new feature (requirement) and there is a chance that a Should Have item of equal or lesser value is prioritized into the Won't Have category. Note: my use of terminology is not 100% correct for Agile - this was done intentionally.

Predetermining all the outcomes (Scope, Schedule, Cost and Quality) is actually the single largest complaint about the traditional / Waterfall methods. "That's not how we do it . . . is a classic way to talk yourself into being one of the 80% of all IT projects that fall short in meeting customer expectations. Use this excuse on Agile projects and the probability of falling short is still 80%... Ask Gartner, Forrester, ivy league Academia. Agile is all about embracing change gracefully and deliberately.

The most widely used frameworks are Scrum and DSDM - Atern. Both planning and documentation are done on a (more or less) continuous basis. These methods account for up to 80% of all Agile projects completed annually. What Agile teams don't do is to assume that we they know what will happen very far into the future. Their detailed planning horizon is often 1-4 weeks and the team will iteratively elaborate / update their plans on a scheduled intervals that are not dependent on alignment with earnings calls, board meetings, incentive payouts, etc. . . . if the team is subjected to out of cycle diversions, then the probability of losing team focus, enthusiasm and collaboration is significantly greater.

Agile teams are self managing, so be prepared to be un-invited from daily and routine meetings. A cast of pseudo experts creates havoc, delays and change at these meetings. If they are allowed to attend it is often with the understanding that they only observe and not speak. That's a big ask for type "A" personalities. The traditional command structure doesn't exactly work on a Agile project. To keep everything clean and tidy, I will interject that Agile KanBan has its origins in the Toyota Production System TPS; not in software.

Did I mention that Agile is a software oriented philosophy that leverages some proven methods that date back to the 1400's? The Venice (Italy) arsenal used Lean methods to safe guard their city and efficiently move goods in and out of the ports. Venice went from 100% commerce to full combat readiness before the pirates could get close enough to fire a shot.

Now for the good stuff. Ask yourself and your executives if they will unequivocally support the following:

1. Is your organization willing to dedicate a full-time business expert, called a product owner?

2. Is your organization willing to dedicate a full-time delivery team?

3. Is your organization willing to provide a business analyst to elicit just-in-time (JIT) requirements?

4. Is your organization willing to time box each iteration?

5. Is your organization willing to put the right people in the right roles?

6. Is your organization willing to support a collaborative environment?

7. Is your organization willing to apply the necessary discipline?

If you or the executives hesitated in answering yes, then read from the link below. Chances are high that you will need an external Organizational Change Management Consultant and a professional facilitator to get started on your Agile journey.

https://www.pmi.org/learning/library/determine-organization-agile-scrum-ready-6129

If you hesitated two or more times, you are normal. Welcome to "cowboy coding", IT, Financial and GRC audit findings (ouch). Clients are worse if you claim to be Agile and fail. Agile isn't hard . . . it is a new mindset for most businesses in spite of their own self assessments to the contrary. Microsoft has been at this for ~40 years and they are still improving. Agile is not a cure-all and you need to embrace a continuous improvement mindset that tracks the results with metrics and accountabilities. Get external help because myopic perspectives tend to yield that same old results.

Kevin Clark, MPM, PMP, MLSSBB is an enterprise PMO savant, Agilist and former CIO with over 35 years of experience across multiple industries. As a former Board Advisor, my mission in life is to help others have a more diverse perspective and a new willingness to continually improve. With well over $1.0B in major project deliveries and literally hundreds of smaller products, there is an Agile project method that can help your organization break the more than 30 year paradigm of IT lead projects failing to meet expectations. Start by asking how and get over your tendency to want everything to stay the same. Still expecting better results ? Albert Einstein said that was insanity. A repeatable process produces repeatable results. New process produces different results . . . it's that simple.