What project management methodology do you use? I hear a lot of business owners, who are terrible at planning, throw agile around a lot. I have seen companies retool their development lifecycle for agile, hiring a certified scrum master and setting up a scrum process 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 stakeholders 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 strict and rigid process that needs to be followed or the whole thing could come apart and often times, what leadership doesn’t understand is that the agile process was created to get something quick to market and then iterate and improve after launch. What this means is you need to be very disciplined in defining your minimum viable product vs your minimum desirable product and you have to be able to clearly prioritize your features to help you define your product roadmap.
One of the best ways to assess priority is to clearly understand what the organization’s goals are over the next year and how these features roll up to support those goals. It could be brand recognition, brand awareness, marketing, sales, user growth… if you understand what the goals are it will help you better align features and functionality to support those goals. You can choose biggest impact, lowest effort, strategic partnerships or any other number of criteria and then work on features that support those efforts.
The next step is to brake down the different features or functions into their most basic deployable components. Once you have done this, you can work with the engineering team to start estimating level of effort. I like to have a work breakdown structure for each of these features and the level of detail I break these into depends on the accuracy of the engineering team’s estimates. If you have a seasoned engineering team, you can leave everything pretty high level, but if you have a team that isn’t very accurate with their estimates or are new to a product architecture, you should break everything down. If you ask an engineer how long it takes to build a KYC form and they quote you a couple of hours it’s best to ask them about setting up the database, validating fields, will they have to integrate with any 3rd party APIs to validate those fields, how is the data going to be stored…?
After you have the estimates, you can loop the business back in and start to build out the roadmap. You can question the business with how this feature will tie back to their over all goals and how those will support the companies goals. Compare this against the engineering effort to try and get the most impactful features in the product in the quickest amount of time.
Agile is great for a maintenance queue, when iterating and improving on a product that is out in the wild or when launching a net new product, but the scenario that I have to really consider the pros and cons of agile in would be a major replatform. In many cases, a replatform is replacing a system that has been custom built over many years with an off the shelf enterprise solution. These enterprise solutions are usually very robust with a lot of best practice features, but I have found that a lot of organizations have customized their systems to follow a legacy process and support a team who may have created their process 15 or 20 years ago. In these scenarios, it takes a tremendous amount of customization to the new system to reach parody of the legacy system and this is what they often look for when they are defining the minimum viable product. If you try and implement an agile framework in this case, without hiring a separate team to implement the new system, the business will feel like they are losing out. The engineering team will not be able to keep up with the maintenance requests handle the day to day and the new systems program will suffer because the business will constantly be changing priority. If the business does some work to the legacy system while the replatfom is underway, they will most likely lose that functionality when the new system is set up and everything is switched over.
Most of the agile projects that I have set up, work well in two week sprints, planning out five to six sprints ahead of development. That means that product requirements and user stories are defined ten to twelve weeks out. In other words, we lose velocity, efficiency and have waisted effort if we try to make changes to the roadmap in less than ten to twelve weeks. It is because of this, leadership and business who don’t understand the process are left with a bad taste in their mouth.