What project management methodology do you use? I hear a lot of people talking about different project management styles and methodologies. The two that I hear most frequently and that I am most familiar with are Agile and Waterfall. I hear a lot of business owners, who are terrible at planning, throw agile around a lot. I have seen companies retool their development and shift to agile, hiring a certified scrum master only to leave a bad taste in their mouths when things don’t go as expected. To get to the root of this you have to understand what each of these processes is and their strengths and weaknesses.
In the end, the development you do needs to meet a specific business need, but you’ll find this difficult if the business owners are unorganized or aren’t able to put together a marketing plan that they can stick to. Many business stake holders think that agile is perfect in these situations because, you know, it’s agile…right?
Well, agile is flexible because you are able to redefine targets, goals or priorities through the length of a project, but agile has a very strict and rigid process that needs to be followed or the whole thing could come apart. I like to define sprints based off of how quickly items need to be introduced into the trunk code for either testing or releases. Everything revolves around these sprints and you should be able to set up your teams so you can keep everyone busy within each sprint cycle. If you look at the diagram below, illustrating what everyone should be working on in any given sprint you’ll see you can evenly spread your team across all of the tasks. When you are in Sprint C, different teams will be working on different pieces of all of the surrounding sprints. It is up to the project manager to keep the project teams on task as well as managing the business stakeholders to make sure they are assessing the work done in prior sprints and comparing the priority of the backlog to any shift in organization wide business objectives and any modifications needed from prior deploys to prioritize for future sprints.
Now this is an idealized example and the real world is way messier and can’t always fit into these boxes. I have found that agile seems to work best as either a support queue methodology or in a phased project where a business knows they need something, but aren’t sure of the details during project initiation. This will give the project the flexibility to adapt as things are fleshed out in the discovery phases. This can be very tricky though because this is not conducive to strict timelines or budgets.
If you have access to strong account managers and BSAs, the first half of the waterfall process tends to work well. Many times, a strong account manager, BSA or business strategist can help draw out all of the requirements from the business stakeholder as well as helping them define their goals and priorities continually keeping the business focused on them. If you can get through the discovery and definition phases of project, you can often times assess whether you can stick to waterfall or potentially shift to an agile process when you go into development. The key to this is to make sure that you not only prioritize the development by urgency of the features needed, but also, define the items that you know are needed but will benefit from testing in the wild and move those to the earlier sprints so you have time to iterate on these steps as are working them out. You must also plan for the extra time and budget that will be needed to iterate.
If you switch to an agile methodology, the project manager will need to be able to take into account the amount of iterations that will be needed while they are forecasting budget and timeline. If you cannot come up with an estimate for the total amount of budget that is needed, you would benefit from defining the amount of time and resources that you can dedicate to iteration so your project doesn’t spin endlessly. Keep some of the team dedicated to getting through the full scope of the project while some of the team dedicates time to iterating on earlier development. Again, this gets tricky for the project manager who will have to maintain strong communications between the business team and the project team keeping everyone in line and making sure that the iterations stay aligned with the main project goals and don’t negatively impact the core development.
Agile development is great for being able to shift priorities in rapidly evolving industries where market needs shift regularly, but it should not be looked at as a solution to poor planning and marketing strategy. I personally prefer a waterfall approach because everyone knows what the target is but if you don’t have the insight into the work that will need to be completed for a project or you are working in an industry that is constantly shifting I would recommend defining your sprint cycles and doing everything in your power to stick to them. Remember, agile is a process to allow iteration, but there is a process that should be followed.