Agile Development Constraints : Hitting Dates & Budgets
Agile Development Constraints
Wouldn’t it be great if life operated in an agile capacity? You could bite off small chunks of progress towards a goal and work on them for a pre-determined period of time. Pick some functionality, commit to it, complete it, repeat. Like most things that sound too good to be true, this is as well.
Business needs rarely conform to the agile methodology. People are still subject to constraints, the two biggest always being time and money. Budgets and timelines still rule. Clients want to spend as little money as possible and business executives want product shipped ASAP. Nonetheless, agile is still the leading project management philospohy for software development firms today. Turns out that building small, getting user feedback, and iterating is a sound way to build great software.
While agile is great for building software, it will clash with other business units. What product feature is marketing supposed to push when the product management team is still busy getting user feedback after the development team deploys every two weeks? Agile teams can’t plan too hard into the future since their feature set can easily change. The breakdown is clear. While agile development constraints exists, hitting dates and budgets within the agile framework is still possible.
What Are Your Constraints
First, know your constraints: what budget and timeline are you operating with. Revelry’s CEO, Gerard Ramos, wrote about why we always ask about clients’ budget first . Not understanding the budget you are working with or the timeline you have to deliver a product by will muddle expectations and stakeholders will operate under different assumptions.
Look into the basis for the constraints. Whether or not a timeline is a hard release date or a random date on a calendar can leave delivery dates to negotiation. Budgets are always more murky and a tough subject to talk about in general. Gain an understanding of how the client has structured their overall budget relative to their technology budget. Is building this application the financial priority of the firm or is there potential for development to take a back seat?
What Can Your Team Accomplish
Second, know your team and what they are able to accomplish in a given amount of time. Story points are a great way to develop velocity for your team based off of past performance. Velocity is a simple equation: number of story points completed divided by the time of the sprint.
Start off every sprint with a kickoff meeting that involves planning poker. Planning poker is system for a development team to measure the level of complexity to complete a feature; time estimates do not come into planning poker. Not only does planning poker spark conversation over the deliverables for the sprint, it gathers actionable data about your team. This data will give insights into how your team is estimating the level of complexity to build certain features and, most importantly, what your team can accomplish in a given timeline.
Once a client comes to you with feature requests, gather your team, throw an estimation on the issues, and compare the total number of story points to what you know your team can accomplish in a sprint. Before you know it you have a sound estimation on a timeline to deliver the new feature set. If you have an accurate reading on how many points your team accomplishes in a set period of time, estimation becomes much easier.
What Are You Trying To Accomplish
Third, know your project. Understand who it is being built for and what their exact needs. What workflows are you trying to automate? Make sure that the information has been communicated to your team. They may be solving the design or technical problem but if they do not understand the problem or who they are solving for, engineering time can be wasted.
Knowing the project will also give you insight on whether or not the constraints that have been placed on you are realistic. Once you and your team understand what is being asked of you, you can start to estimate time frame (see second point.) Is the client requesting a feature set to be done in three months when it will take your team double that time? What features can be shortened or slashed all together to get the product to market faster? Asking these questions will help both you and your team as well as the client understand the overall project much better.
Software development is known for being over budget and late. It doesn’t have to be that way though. Start new projects with these three points in mind and see what happens. You’ll have a happier team and a happier client.