Written by Mahad Khan
Mahad Khan is a Certified Agile Practitioner currently working as Project Manager. Dedicated, team driven and most importantly passionate about providing the best experience to the customers. His ability to coordinate internal resources and vendors results in the flawless execution of projects. He believes every day you have an opportunity to improve, learn and explore new things in IT.
I have learned, anything which has been planned well and analyzed thoroughly in corporate life or non-corporate life will always lead towards a satisfying result because you are already aware of the expected outputs.
Similarly planning in each stage of the Project helps you to analyze the future and the critical paths of the project especially when your set of requirements is not rigid.
To achieve such results Organizations should consider to start moving from Waterfall Project Management Techniques to Agile Project Management Techniques. As this will help the organization to plan the project dynamically and analyze the risk on every change in requirement.
The waterfall approach may work well for simple, straightforward projects, but it won’t work well with complex projects, including digital projects, typically involving many unknowns.
Before we kick off, we need to understand the limitations and challenges we have with waterfall:
• It’s impossible to predict every potential result with a rigid set of project requirements created up front.
• Its framework doesn’t allow you to course correct based on learning that occurs throughout any project; otherwise, your project can be a victim of Scope Creep.
• For Business Team it becomes exhaustive to estimate and plan waterfall projects accurately. Though this can also be a reason that RFP’s can be problematic.
• Always welcomes the changes/new requirements, even late development. Agile processes tackle change for the customer's competitive advantage.
• Frequently delivers working software, from a few weeks to a few months, with a preference for shorter timescales.
• Satisfies the customer through early and continuous delivery of valuable software.
Sure there are more points to share, but the above three points are general points which will give you an overview of how agile is flexible while delivering the project and not neglecting the changes in the system.
Agile breaks large, complex projects down into a series of manageable chunks, or “sprints” in agile jargon, that each focus on a core component/module of the larger project. Each sprint/iteration has clear functioning deliverables that can be tested against organizational goals and desired outcomes—with real end users whenever possible.
• A sprint planning session where you divvy up tasks among the team, rate the difficulty of each task, then have the product owner (in our case the client) prioritize them.
• Working in two-week sprints with demonstration/feedback at the end of each sprint.
• Having a daily stand-up during each sprint where team members talk about tasks they’ve accomplished and potential blockers that could impede progress.
• Testing is incorporated into every sprint, rather than saved for the end.
• Using a system to track the daily backlogs in order to avoid the over committed deadlines.
Below mentioned points can help get your team ready for a waterfall to agile transition:
Team Capacity: Measure your team capacity. This is the total number of billable hours per week for your team. Always try to add buffer so there’s flexibility in the schedule for non-billable tasks, which always come up.
For designers, developers and devOps in an agency setting, a 70-80% billable utilization rate is common.
Individual Capacity: Plan each individual’s workload rather than planning the workload by team. This will help you better when you have a change in project requirements & also maintain your team’s sanity.
Note: A core agile team of designer, developer, and project manager working equal time on a project may sound nice, but it’s not practical in reality if you have multiple projects going on at once.
Estimating: A key part of successful sprint planning is estimating task difficulty. Start first by using hours as your scale of difficulty (i.e. how many hours will something take). I use Critical path analysis which helps to track down that which module can be expensive in terms of changes and time.
Sprint length: Sprints are typically two weeks long, but this may vary from project to project. Consider adjusting sprint lengths mandatory until you find something that works for all project stakeholders.
If you think of agile as per clients perspective, they will just love agile as it gives them the leverage to change the requirements and offer feedback at the end of every sprint / iteration.
Here are some steps that can help an easy transition of clients from waterfall to agile:
Discovery: Start with conducting a solid discovery process that incorporates agile methodologies. This will get them to work collaboratively.
Check-Ins: Use ongoing communication to break down formalities and kickstart the collaborative process. Collaborative project management tools, regular calls, and holding sprint demos in person can help with this.
Uncertainty: Help your clients understand the value of embracing uncertainty and continuous learning whilst being clear with them about expectations within timing, budgets, etc. Features they think they want in the beginning might be re- or de-prioritized during ongoing user tests. And that’s okay.
Agile, AgileMethodology, AgileProjectManagement, Sprint, Waterfall,
3 mins read
Today, project managers are more likely to be termed "chief risk officers" rather than "directors." They are thought to be direct managers. Yet, the changing role of the pr...
Start Reading
