This is a response to a great summary of the recent survey posted here:
1. Time constraints
Get Agile. Release in iterative cycles instead of a monolithic delivery. It allows for better evaluation of progress, forecasting, and customer feedback.
2. Setting a goal and sticking to it
Get Agile. Use cases and user stories are better than “the system shall…” at understanding the true wants and needs. Scrum then makes the entire team focus on a set of those user stories in bite-sized chunks. Then protect your team from distractions like a junk yard dog during their sprint. Changes or additions are fine, but they go in the product backlog for a future sprint, this one is locked down.
3. Budget limitations
Get Agile. When sprints are so well-defined in little chunks, you know exactly what you are going to spend. EVM combined with Agile is a powerful forecasting tool, and new user stories = new scope which you can and should run through a change control process – those changes either don’t change effort or they do – and if they do it’s additional cost or a trade-off with other work.
4. Poor communication among contributors
Get Agile. Daily stand-ups, the formality of sharing and negotiating with stakeholders over what’s highest priority in the product backlog for the next sprint, and user-centric user stories with the “why” built in so you know what “done” looks like – these are some of the ways Agile solves many communication and coordination problems.
5. Organization and coordination
This is a leadership issue. If someone isn’t looking out for the long-term strategy or contract turnover is frequent and disruptive, that must be fixed at the top. No amount of awesome execution is going to compensate for a lack of vision and strategy.
I fully believe that agile is a great framework for developing and delivering products and services. The deliema i face as a financial planner and controller is extracting information from the agile framework to build and maintain a long term plan. I need to build a PMB and then feed that into the organizational business system for revenue recognition.
Small sprints do not allow for a full resource loaded network of activities. I understand that rolling wave planning will have to be the methodology for building a time phased plan. But linking to a sprint is not the right answer. So what would an activity list look like under a sprint.
Having goals that lead to milestone completion are great. How would I measure the performance within the sprint. More importantly, how does that roll up to the work package and therefore the control account.
When performing scrums, do you or would you ever include a project controller. Don’t scrum masters think Controllers work for the dark side. 🙂 I think communication is great, but having feedback loops that transfer information through the management system is critical for success at all levels.
To your last point, there are two fundamental aspects you must consider, strategy vs. tactic. Strategy is what you say as an organization, project, or team. Tactic is what you do in the same. Keeping those two aspects in alignment is the real challenge. Hopefully there is a good mix of managers and leaders. Manager are concerned with sustaining the current state of operation. Leaders are concerned with changing the current state, even (especially) when the current state is working.
Nice post. Maybe you could include some links for further research on the topic of agile within the context of EVM and financial planning and controls.