Balancing Project Needs

Balancing Project Needs

Quick Read

Balancing project needs requires 100% commitment throughout the project. It would be as if we created our product backlog, prioritized it and called it good. For anyone that has worked on a Scrum team knows that this is not possible.

When internal ideals get ahead of the project needs, they can be costly to the project timeline and to the price tag. On the other hand, internal ideals can provide value if it is an opportunity being missed. Scrum has been a methodology that has provided mechanisms to balancing the project needs and facilitating new ideas to work through the process in providing value.

Here are some quick tips to consider in keeping that balance:

  • Know your project, window to deliver and end goal.
  • Adopt a cadence and keep it.
  • Keep a product backlog groomed and prioritized.
  • Recognize when gold-plating is happening by the team.
  • Get continuous feedback such as providing a demo with the client.
  • Make data driven decisions.
  • Embrace a facilitator and the negotiator.

Full Article

BRDs is what they called them. Business Requirements Documents. It was great for waterfall and where I worked at the time was very very detailed. It was seen as a contract. The stakeholders signed off on it and used it to every detail.

When the project began and sometimes much later from when the BRD was drafted, the development team would pick up the requirements and head into development for a couple months or longer. When the development team said they were done and it was the end of the project, the progress was good however the expectations changed or some things were missed in the project. We did the Agile thing. Iterations were planned that broke down the enormous BRD.

What did we do wrong? How did the project needs become less represented? Or, why did the needs change?

In a new era of development at the company, Scrum was the new buzz word. It brought:

  • delivering the best value first with cost in mind
  • failing faster with a realistic schedule
  • continuous feedback to maintain proper scope

Scrum was helpful and it provided the mechanisms for everyone to be transparent and collaborate on a project. However, there is no one size fits all. Even with Scrum, there are internal ideals that can get ahead of the project needs. And, sometimes internal ideals that should be considered as part of the project needs provide more value.

Here are few things that might be worth considering when you head into your next project:

  1. Know your project. Be sure to understand where your client is coming from and make sure there is a plan for going to market. Is there a short window to get to market in order for the client to take advantage of an opportunity? This can be very important information as it will determine what can be built for the amount of time and cost. It will also help the team establish how the project will get built.

  2. Adopt a cadence and keep it. Sprints are there to keep the lines of communication going for continuous feedback in where the project team is heading. Never put off a sprint and avoid extending sprints especially if the sprints are failing. A team starting out will fail 50% of the time and should improve as the project progresses. Knowing that the team is failing will drive the team to complete a successful sprint and one that is realistic.

  3. Keep a product backlog groomed and prioritized. Priority should always be re-evaluated on a sprint to sprint basis. It is important for keeping project needs first. The priority will help the development team bring the most value first. Grooming and re-evaluating with the client's interests and with the team's feedback allows for the project to adjust to change.

  4. Recognize when gold-plating is happening. The development team will have some internal ideals. Great ideas can come out of the development team. The client should be able to determine if it is what the project needs, would it be better suited for a later release, or not at all. There are some common traps for teams. Some examples may be arguments for reusability or design that suggests too much functionality.

  5. If scope creep is an issue or things are feeling a bit ambiguous. Get the product owner and client involved to help make the decisions. Get some time with the client to quickly prototype to help with decision making. Demos should be an integral part of the sprint schedule and be adventurous to let the client drive. Give them the keys and find out what is not working or what is working.

  6. Make data driven decisions. It can be easy to fall into the trap that the client or the development team can assume what the end user wants. Be sure to use mechanisms that will let the end user tell you how a feature should work. There are lots of ways to collect this data for example hallway usability testing, canary testing, feature toggling and A/B testing. Be sure to get the right mechanisms in place to collect information especially with analytic services like Google Analytics. Also, consider ways you can ask the end user to provide some feedback on their experience. Keep in mind that there might be features that may never or rarely be used by the end user. Find out what works and what doesn't work.

  7. Embrace a facilitator and the negotiator for the team. The roles of a Product Owner and Scrum Master are very important. It allows for the communication between the client and the team to happen in a productive way. There is going to be a need for someone to help facilitate and negotiate the needs and priorities between parties for everything to work effectively and realistically.

Balancing project needs with internal needs requires everyone to be committed to work together to self organize. Scrum helps us realize the transparency that is needed for teams to get work done and for change to be accommodated. Every project is at the mercy of cost, scope and time. And the product backlog could merely be seen as one big long wish list which some items that consists of project needs and internal ideals. But value should be provided quickly, proven with a plan and data to make informed decisions, and hopefully with return on investment.

These are really observations I've made over the years moving from a Waterfall/Agile environment to a Scrum environment. It is difficult to do any methodology 100% and I've ran into teams that do things a little bit different. Teams find approaches that work and there are different ways to get leaner and compromise to get to the end goal. Don't worry if your team is not doing Scrum a 100%. It comes with experience, willing to change and working together to strive to provide the best value.