I’m on my way home from a great SharePoint Saturday event in Ottawa Canada, where I attended an amazing session by @David Drever on "Leading Practices for Planning and Implementing a SharePoint Environment". His guidance around requirements gathering, stakeholder engagement, technical roll-out, governance, and adoption was excellent. However, when he was comparing waterfall to agile project management approaches, I was surprised at some of the comments and questions that were raised by the audience during his presentation. Agile has been around for some time, but I find that there are still some common misconceptions around what Agile really means, which compelled me to share my thoughts on the topic. Here are some of the classic examples
The Invisible Client
Some clients expect to give you their requirements and then deliver a project that will meet their needs. In most cases, if you deliver to your client exactly what they ask for, they will realize that what they asked for is different from what they need.
Agile projects run in short iterations called sprints, which typically last 2-4 weeks. At the start of each sprint, there is prioritization and refinement of user stories (that’s agile requirements) to ensure the developers know what they need to work on. At the end of the sprints, you review the solution with the client and give them a chance to provide feedback. With these iterations happening throughout the project, it’s important that you get the necessary participation from your client. As well, there may be questions that need answers while a sprint is in mid-flight. If your client is not available, your sprints and overall delivery are bound to delay and fail.
Change Happens!
If your client is expecting to get all the requirements they defined in their scope, STOP!
Clients are often stuck in the past where they commit to a budget and timeline and expect a certain set of scope (if not more!) This reality works when you are executing your project using a waterfall approach. However, when you’re agile, your scope is, and will most likely change throughout the project. When discussing the budget, time, and scope with the client, you need to make them aware that the budget is assumed fixed. The timeline, which is broken down into sprints will vary based on the resources required for each sprint but is directly controlled by the budget. Scope, on the other hand, is flexible. Create your backlog of user stories and review them at the start of each sprint. The only certainty of scope should be what gets delivered in the current sprint. Everything after that is subject to change.
Don’t Document – Just Code
The whole idea behind agile is to be light-processed and not create any documentation. Right? WRONG!!!
Although one of the four core pillars of the Agile Manifesto is “Working Software over Comprehensive Documentation,” it does not mean that you don’t create any documentation. Yes, you eliminate for the up-front investment of heavy, detailed requirements and/or specifications document. However, you still need to capture the requirements at a high level as user stories in a backlog and prioritize them with the client. Once a sprint begins, business and technical details for the sprint tasks also needs to be documented. You create your document piecemeal as opposed to in one large step.
Agile Requires Smaller Teams
By being agile, you achieve more with fewer people. That’s like saying you can work twice as fast by having two keyboards. No true.
The skills required and responsibilities are different. However, to achieve quality results, you still need to have the right people and allow them the necessary time to complete their work.
I hope my thoughts help clear some of the misconceptions around the topic. I'd like to hear if anyone else has experiened similar scenarios. Please reach out to me if you'd like to discuss this further.
