Agile Development and Organizational Buy-in
The edict is passed, and now your organization is going to be Agile. Congratulations! What does that mean? For most, this means implementing morning stand-ups, user stories, acceptance criteria, and story points. It doesn’t end there, though. The rest of your organization needs to adapt as well.
Agile is about communication. Not just in your team, though. The communication needs to flow both up and down the chain.
The product team provides guidance on what is required in conjunction with the finance and sales departments. The expectations need to be communicated to project managers.
The project managers should communicate these requirements to their team, who will then break them down and provide estimates. These estimates guide the team on how long it will take to implement the desired product, whether it be a new feature or changes to an existing one. This, in turn, will be communicated back to the product team, allowing the organization to update its expectations.
This part is where things often become tricky.
Too many times, I have seen product teams say that they want something to happen within a specific time frame. Still, when the reality of estimations comes back, they are unwilling to work out whether they need everything they asked for, or are willing to expand the timeline (and incidentally the costs) of implementation.
If your organization is going to “Go Agile,” then it needs to be something the entire organization does. The sales team shouldn’t make a time or cost promise without receiving feedback from the team that will be working on it. Instead, they should inform the client that they will determine what is feasible and get back to them. If finance indicates that a specific budget is available and there is no wiggle room, then the product team should determine what is needed to make it all work within the budget. It shouldn’t be on the team to “suck it up and make it happen.”
Finally, the executive level should trust their employees’ expertise on the matter. This doesn’t mean they should push to see what they can achieve. What executives need to do is accept the limitations of the situation and work on ways to either improve it (i.e., hiring more staff to handle an influx of work) or adjust their expectations of what they will receive.
Too often in my career, I've encountered individuals who believe that a development team is comprised of wizards who can “magic” everything their hearts desire. I wish that were the case, but we do not live in a fantasy world. Bring your ideas to the table, explore what's possible, and collaborate with your team to discover what may be achievable in the future.
There is nothing wrong with dreams, but it is also essential to understand reality. Your teams will thank you. So will the clients you keep making promises to and failing to deliver to. That tends to make them look elsewhere.
