How To Create an Engaging and Collaborative Delivery Team For Your Business

• Does your team feel its alignment with business where what it delivers solve business problems and achieve business desired outcome?
• Is your team able to influence solutions or how to solve business problems?
• Does your team grow and learn on problem solving skills?

In this post, I am going to share with you the way my team works and a couple of changes and experiments we have done along our journey (with different people).

All the credits go to the people that worked and still work with the team.

In organisations that apply waterfall process or teams work in silos, work normally get handed over between teams. For example, business team defines and provides requirements, solution architecture team figures out solutions and designs, development or delivery team implements solutions and so on.

As you can imagine, because of less engagement and collaboration between different functions, desired outcome may not be achieved and rework normally occurs because each team focuses on their own domain and do what they are asked.

In Agile organisations, team is cross functional with all the skills it needs to ideate-build-run. It is the team that starts from understanding problems to delivering solutions. With a team of 8 to 10 people, how do they agree on solutions, how do they collaborate and help other success, how do they grow, etc?

In this post, I will walk you through a couple of experiments that aim to solve those problems.

Principle

Product Owner approaches problems with outcome, rather than solutions. This helps create engaged and collaborative culture (delivery team is not doing what it is told by business) and helps team deliver solutions to solve right problems.

We did not reinvent the wheel. The idea of Shaping Team helps.

Basically, it is a team of PO, BA, developer or architect, UX and security (if required) to understand problems and requirements and work out solutions. Then a Solution Review meeting is held for team to give feedback and agree on the solutions.

In my team, we agree with our architect that developers are responsible for architecture (the architecture doesn’t come from him) and once they have an architecture it’s reviewed with him. The role of an architect likes QA and is to coach, review and teach, not do the architecture.

Iteration 1 — Rotate Developers

Typically, only lead developer is part of Shaping Team. It implies that other developers have less opportunities to grow in areas like technical leadership and design and problem solving experience. It also creates single point of failure and makes team less sustainable, i.e. what if lead developer is on holiday or moves on. This version of experiment creates a Feature Lead role and we rotate between all the developers.

Because everyone has different level of experience, in order to help everyone success, it is also recommended for Feature Lead to find a design buddy. In addition to being part of Shaping Team, Feature Lead is also in charge of end-to-end of delivery to increase ownership.

Iteration 2— All Developers

We have had this Feature Lead experiment for more than a year and it had been working really well to create equal growth opportunity for every developer and help build trust and collaboration, and share learning/knowledge/skills.

In last a few months, there were changes to the team and we found what had worked was not working well anymore (It is expected because of those changes). We had a problem a few weeks ago where a lot of feedback was given right before sprint started.

Although feedback is always welcome but they were a bit late and large (majority of feedback is supposed to be given in the Solution Review meeting held earlier) and caused rework and delay, etc.

We reviewed the process and the problems (potential improvements) we found are that waste, i.e. rework on design and solution, still occurs even if feedback is given in Solution Review meeting and Feature Lead becomes a mediator between PO and other developers which does not promote involvement.

This 2nd version of experiment gets every developer to participate at early stage of Shaping process, before figuring out solutions, to understand problems, brainstorm ideas/solutions/options and give their early feedback. It is understood that everyone is different so it is totally up to individual developers to decide if they would like to participate the discussion.

Then Shaping Team works out solutions considering feedback received and holds a meeting for team to do a final solution review.

What does it mean for Feature Lead role, does it still exist?

Yes it still exists and its role does not change but she or he now has more chance to success given the early feedback received. We hope to improve team efficiency from early feedback.

What do you think about this approach? Let me know at the comments section.