Reasons to Switch
I'm passionate about APF and have observed firsthand the impact it can have. In case I haven't convinced you already, here are the 15 most important reasons for using APF. If these reasons resonate with you, it's time to switch to APF:
- The approach thrives on change rather than avoiding it.
- The approach is not a "one size fits all" approach.
- The approach utilizes just-in-time planning.
- The approach is based on the principle that you learn by doing.
- The approach guarantees "If we build it, they will come."
- The approach seeks to get it right every time.
- The approach adjusts immediately to changing business conditions.
- The approach is client-focused and client-driven.
- The approach is grounded in a set of immutable core values:
- Client-focused
- Client-driven
- Incremental results early and often
- Continuous questioning and introspection
- Change is progress to a better solution
- Don't speculate on the future
- The approach assures maximum business value.
- The approach squeezes out all of the non-value-added work.
- The approach fully engages the client as the primary decision maker.
- The approach creates a shared partnership with shared responsibility.
- The approach empowers the team.
- The approach works 100% of the time[md]no exceptions!
APF is used on projects whose solution isn't known but must be discovered. Through successive iterations, the project manager and the business analyst collaborate to learn and discover the complete solution and deliver expected business value.
Projects are unique. No one would argue that. So why isn't the approach to managing them unique? APF adapts to the project's characteristics.
Developing a complete plan when change is a certainty makes no sense. When in doubt, leave it out, and only plan what you know to be part of the final deliverable.
The solution must be learned and discovered, and that's where the real value of APF is found. It utilizes concurrent probative and integrative swim lanes to learn and discover the solution.
At the completion of each iteration, APF delivers the best solution possible given the time and money invested to that point. The solution is continuously aligned to true client needs.
Once the client is certain that a function or feature will be part of the final solution, that function or feature is integrated into the then-solution. At the completion of each iteration, the then-solution, even though it's still incomplete, can be implemented because it has been vetted by the client as aligned to the client's needs.
Between iterations, the business analyst and the project manager review what has been done and how the business situation may have changed to require an adjustment in the future iterations.
Meaningful client involvement is essential for any Agile project to succeed. The client (perhaps through its BA) is the co-PM along with the PM. This design creates client ownership and a vested interest in the success of the project.
The client (or its BA) is empowered to choose what goes into the solution and what doesn't, using any desired criteria. Presumably the criterion is to do whatever maximizes expected business value.
APF doesn't waste time by speculating on the future. If there is any doubt about a particular function or feature being part of the final solution, it's not integrated into the solution until that doubt is removed.
The client is really responsible for successful project completion. The role of the PM is to keep the client pointed in feasible directions. The PM does this by presenting the client with only feasible alternatives and letting the client choose.
Attaining and maintaining client involvement and ownership of the project and its deliverables is the key determinant of the success of an APF effort.
The team may start out much like a herd of cats, but through the active participation of the client and the BA it quickly forms into a "lean, mean fighting machine." The motivation to succeed where others may have failed is the kind of challenge to which technical professionals respond.
The APF project is either terminated early because the direction chosen by the client or BA is not converging on an acceptable solution, or a different approach is discovered during iteration. That arrangement frees the project resources (time, money, and people) to redirect the project toward a more likely solution.