Throughout this 3 Part blog series, we’ve talked about where managers and business stakeholders fit in an agile world and what changes for them. Now that you know what to expect from the agile delivery teams, what can you do to help facilitate a great working relationship?

Be Patient

When companies are new to agile, there is an initial period of “trust me, it gets better.”  You are engaged in a new process and there is a learning curve to cross.  Teams aren’t going to be better right away and velocity will be slow at first. But if you give the teams several sprints (could vary widely by team) without interrupting or changing their structure/work, they will generally gel and get better.

Use the PO as your ally

The Product Owner (PO) is your most direct conduit to the team (not that he should be a bottleneck, but he will be the one responsible for keeping you up to date on work). Use the PO to understand where the team is going, where it has been and what is being delivered.

In that same vein, empower your POs to make decisions on behalf of the business and the customer. POs are most valuable when they can give the delivery team immediate feedback on the details and importance of a user story in the backlog. To do that, the PO needs to understand the product and its customers, have time to devote to the delivery team and have the authority to make decisions in scope. This is tough to do but if you can dedicate your PO to one team, get him the training he needs to be successful and empower him, you’ll get the most out of your PO.

Trust the team!

Also, you will need to trust the team more than you might have in a waterfall framework. Agile needs a certain amount of trust in order to succeed. This is on all sides- for the business/management, this involves telling the team the goal or vision of the product, working out the details of features and epics just in time for development and trusting that they will build the most valuable features first and that they will do it in a manner that will give the highest quality product.

The backlog is not a queue

Learning about the product backlog, you might be tempted to think it is just a requirements document in list form. That is not true! The backlog is an ever-living item, constantly changing from new information, with new stories added, superfluous stories removed, and high value or importance items being pulled to the top of the backlog to work on. If there is a user story that is extremely important and valuable, even if it is added late in the game, the team will work on that next.

Don’t interrupt a sprint!

Once a story/feature has been taken into a sprint for development, it should be “locked” so to speak for scope changes. Additionally, what the team agrees to take into a sprint should remain constant throughout the sprint. If you want to get the most out of your teams, try not to change or add scope to the delivery team during a sprint. Changing the scope of a story or a sprint in flight requires re-negotiation and will slow their velocity considerably as they try to switch contexts to work on the new items.

Attend sprint reviews/demos

Sprint reviews are where the delivery team demonstrates functionality to the PO and the PO either accepts or rejects the user story as done. This is a great time to see what the team has been working on and their progress. Additionally, if the team does any additional demos outside of the sprint review, that is another opportunity to see the software as it is being created.

Co-locate the team (if you can)

Realizing that is not always possible, co-location of the delivery team with its PO is the best way to increase the productivity and velocity of the team because the turnaround time on questions and decisions is faster when everyone sits next to each other. If this is not possible, try for some alternatives like co-locating a PO proxy to answer questions on the fly or having the PO visit the team from time to time.

Additionally, always try to co-locate the delivery team. Having the developers distributed, with or without the PO, really hurts the velocity of the team because it inhibits their ability to swarm to solve problems and implement other tools and techniques that agile brings.

Get a coach to help your team

This is one of the most cost effective things you can do upfront when moving to agile- bring in an agile and PO coach for your teams. These coaches can come internally from other agile teams at your company or externally from someone who has been doing agile for a while, but they can coach the team and the PO through the first few sprints to truly be agile.

Is transitioning to agile worth it?  The answer is “probably”.  There have been agile projects covering the full range of software products, so whatever you are looking to build can be done in this approach. The bigger question is whether your organization is ready to make the changes needed.