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:
- Business stakeholders want something when they want it; they don't care how well the project adhered to a particular development methodology.
- 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.
- 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.
- Successful agile requires focused business user involvement through design, development, and testing. None of this "let me know when it's done" stuff.
- Top down project management orchestration is crucial. Empowering teams is important, but can't be taken to a point of anarchy.
- 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.
- 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.
- 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.
- 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.
- 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".
- 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.