You’re a project sponsor and have owned a portfolio of work for years.  You have a PMO staffed with certified PMPs.  Waterfall is safe. It’s life. It’s ordered. Predictable. Measurable.  Sure, everyone knows projects frequently deliver late or over budget, but that’s just how projects go, right?

You’ve heard the whispers though.  There’s ceremonies. There are artifacts. Someone guiding the team called a “master”. They have a manifesto and legions loyal.  They start work before all of the requirements have been completed?!  What is this “agile” madness?!?!?!

Agile is not the sleeping Elder God that will destroy your world, though many an organization misunderstands what it aims to accomplish. Viewing it as a short-cut to increasing the bottom line is where many end up with a poor transformation, unhappy team members, and chaos reigning over the portfolio.  How do you make sense of it all and avoid the same pitfalls?

What Agile is

Agile is an iterative based approach to project delivery that when done well, delivers functional, testable pieces along the way. This insures scope is being met and provides value along the way.

What Agile is not

• It does not mean doing more with less people.  
• It does not accommodate scope change without impacts.
• It does not deliver everything faster.
• It does not eliminate planning.
• It does not eliminate project governance.
• It does not eliminate documentation.

Agile isn’t one-size-fits-all

Don’t get caught up in the hype of the superiority of Agile methods.  It’s great. I love it, practice it and am certified.  It’s also not the answer to all projects ever.

Waterfall is still the best fit for projects with well defined requirements and repeatable tasks.  Perfect examples would be hardware deployments, semi-custom home building, or configuration and implementation of an enterprise system in a business.  There are some requirements to gather, but the path is straight forward and executable, and an iteration approach could actually slow the work down.

Agile shines where the work to be tackled is fuzzy in definition for any number of reasons, or is a new undertaking.  It allows the team in conjunction with the product owner and end users to discover together the best way forward for project success.  

MVPs  

In the transition to an Agile mindset, many struggle with the concept of an minimum viable product (MVP).  For a product owner and leadership, everything is important and that’s what they have approved budget to complete.  Being asked to parse out what bare bones looks like can sound like they might be asked to give up the rest at some point.

In reality, defining the MVP is setting the goals for what success looks like by setting a common understanding of what objectives need to be met. By defining this, the team and product owner have a measuring stick by which to prioritize the backlog and any changes requested along the way. An MVP can still be a very large complex system, so long as there is understanding there is a rough order of magnitude to be considered and applied to the budget and timeline for buffer.

Of particular note, while an MVP may be completed, there is no obligation to release to production without the additional features they may want for go-live.  In some cases, it may run behind the scenes to support other initiatives and have a front end integrated at a later date.  In others, the budget may have only allowed for the foundational work to be done to create a proof of concept and an additional project will be green-lit to make it customer-ready.

Slices

Similarly at the team level, there is a fundamental shift in design that must be embraced for an agile project to truly fulfill the benefit of delivering usable functionality along the way.

That is, I have seen agile teams insist on taking a sprint to develop a full database before working on the front end work to capture information in another, and still later a query interface.  Assuming 2 week sprints, that’s 6 weeks before a user may be able to complete a task to look up a student in a class.  Bluntly, this is simply iterative waterfall. 

There can benefit in more simple projects where you want the adaptability to make small changes along the way but the work is largely common, such as this example.  However, you are introducing much more repetitive user acceptance in that you are testing each step of the way (and they may not have the expertise to truly test some items like a database), only to have them test the entire function at the end and still may have an issue that needs to be reworked.

By taking an entire slice of functionality, such as being able to change a password, and building out enough of the steps along the way (database, ability to create an account, and then the means to change it) to show what the end user should expect the flow to look like.  Even with stubbed in pieces as place holders, they can better see what the end product is shaping to be and can give appropriate feedback to tweak now or to incorporate into the over all delivery.  This is where the value of Agile really resides.

In Part 2, I will dive into the team-focused shifts required for success.