Practical Agile - 6 Implementation Principles to Secure Project Success

 A couple of years back I was engaged on a project to help recover an agile project run amok.  The project was one of the first in the organization to use an agile development methodology and consisted of eight four-week sprints with six capability development teams.  The project manager was a very theoretical scrum master who was more concerned with having an agile "design win" than he was with ensuring the business sponsor was satisfied with the project result.  After about the third sprint there were significant issues with capabilities not working together, interfaces with external systems breaking, and problems with meeting sprint dates for committed capabilities.  To save the project, we had to take a number of steps that violated the purist agile model but were necessary if we were going to keep moving forward on the project.  Our implementation looked like a mishmash of agile and waterfall.  It wasn't pretty, but we eventually got the project done.

---

Ah, agile development.  I love the speed, focus, and excitement of seeing capabilities roll off the agile  assembly line.  I've had the pleasure of running some very successful projects where we delivered capability much faster than under waterfall.  I've also been involved in recovery projects like my earlier example where the brand of agile being used was fraught with schedule and scope issues and management was demanding change to get the project righted.  Through these experiences a few tenets became painfully clear:

1. Business stakeholders want something when they want it; they don't care how well the project adhered to a particular development methodology.
2. Agile principle adherence shouldn't become the focus of the project.  It is the vehicle in which a project gets implemented, not the reason for the project.
3. Agile doesn't mean skipping any kind of testing, particularly integration and regression testing. It just means you are compressing and overlapping and being less "over the wall" in test stages.
4. Successful agile requires focused business user involvement through design, development, and testing.  None of this "let me know when it's done" stuff.
5. Top down project management orchestration is crucial.  Empowering teams is important, but can't be taken to a point of anarchy.
   

Depending on where an organization is at in its systems development methodology journey, it may not be able to jump to a purist agile model and be successful.  I've learned that the following six principles are paramount in a successful agile project.

1. Embedded Power User - Having an experienced and forward-thinking dedicated user who can guide capability development and bring other users to the table as needed ensures that the capabilities under development will align to the business and will minimize capability gaps after implementation. The embedded power user also has a responsibility to know and communicate the current shortcomings as well as clearly articulate future state capabilities.
   
2. Time Fences - Rather than having team members set their own delivery dates, the project team needs to work to defined time fences and flex the work to hit the time fence.  Key to this is the project manager having some flexibility to alter a time fence if it makes sense to do so.
3. Governing Architecture - I watched an agile project with six capability teams go off the rails because each team was given too much architectural freedom of choice.  About five sprints into the project the capabilities didn't fit together because of individual decisions made by capability teams, creating massive rework.  There needs to be a concise functional and technical architecture that capability teams must snap to.
   
4. Small, Frequent Deployments - I like executing plans that have monthly capability releases.  It keeps the energy going, gives business users and stakeholders something to look forward to each month, and gives everyone something to celebrate each month. it also exposes weaknesses and integration challenges sooner than later.
   
5. Persistent Testing - Developers tend to like "grand reveals." where a capability isn't shown to others until the developer is sure everything works 100%.  I prefer to have testing and power users involved as close as possible to development to find problems early on.  There is a big trust issue that has to be overcome when you take this approach; the developer needs to not be randomized by "Are you done yet?" questions and needs to know that if something breaks during development the power user won't start launching flares that the product is of poor quality.  The developer, in turn, needs to avoid  the grand reveals where fixing problems later in the schedule becomes more expensive.  This also keeps the power users honest by minimizing late-breaking statements like "that's not what I want".
   
6. Strong Project Management - Agile isn't code for anarchy, and it's not a time when the PM is relegated to administrative errand-running.  The PM needs to be driving accountability, ensuring issues are being addressed,  risks are being mitigated, dates are being met, and scope is being adhered.  The PM also sets the communication rhythm for the team and works to keep the team on the same page. At the end of the day, the PM gets the first bullet if the project fails and needs to ensure everyone is doing his or her job to meet scope, schedule, and budget goals.
   

I've never seen a project manager get points because he or she followed the rules of agile on a failed project.  The first and foremost goal is agreed-upon scope delivered on time and within budget.  Keep the above principles in mind as you take on your next agile implementation to better ensure success and not get tied up in whether or not you're doing agile right.

Lonnie Pacelli
Keynote Speaker | Board Director | Autism Advocate | Author | Project Management Expert | Microsoft/Accenture Veteran 
See his books on Amazon.