Enabling team collaboration on an Agile project

Digital transformation in organisations should not be difficult. Careful analysis feeds good requirements into application development. This then enables learning though testing at each stage, and facilitates productive scrum meetings. Using this process framework, an organisation can be guided through a smooth process that delivers a successful project delivery lifecycle.

1. How can benefits be delivered at pace with minimal delivery cost impacts?

This can be achieved by adopting a Software Delivery Lifecycle Model into client’s transformation programmes.

The key to getting developers and users working together is to listen, allowing the users to do all the talking. Often stakeholders will be frustrated about similar things, but they will be coming to a situation from their own perspective. By listening to what challenges they face, what pain they are feeling and how they think, measures can be taken to improve.  This is not only enlightening, but will also help to identify emerging themes; so the trick here is look for patterns. Once we know what these patterns are, we can then look at the best way to help resolve them.

2. What is the delivery lifecycle model?

Project delivery lifecycle is a technical sounding term used to describe the process that guides teams through delivery from start to finish.

It provides a methodology for teams to follow that identifies individual phases. These range from ideation and capturing the user story, through to development, testing and finally to deployment. The model outlines what is expected at each stage, who will be providing it and how. Crucially it will describe who will be accountable for the delivery, i.e. who approves it when it’s ready to move on. The model neatly aligns testing to the ‘thinking’ and delivery stages, which in turn limits the need for change later in the process. The beauty of is that it can be used for both traditional, waterfall and agile projects.

3. How do we understand the problems that organisations face?

Within any organisation, it is important to understand what processes are being followed, what documentation is being produced and how well teams are working together. It’s equally important to know what problems teams are facing and understanding team dynamics, roles, and skills.

The best way to do this is to let all stakeholders in the process talk. By listening to them, we get to the centre of the problem; and it can be surprising what we find! Observing client teams allows us to see how they function and work together.

We are seeing more and more often that teams are working in a matrix style. By doing so they are working on projects and “business as usual” activities in parallel. However, this often leads to targets not being met.

4. Bringing the team along with us to co-design the model

Although this can be a little chicken-and-egg, I find that the best way to do this is to co-design the model with the team. We shouldn’t do this without the team’s input and the team shouldn’t do it alone. Developing the model together and designing it with everyone’s input is the key. By using this method, everyone has a common purpose to fix the issues, the teams feel included, they can be coached and good relationships are built and sustained, which will lead to a successful project delivery lifecycle.

5. Developing and documenting the model

Visualising the model has proven to be invaluable in communicating with the team and enabling the model to be embedded into daily working practices.

We generally develop the model at a high level and then play it back to the team. This allows the chance to obtain feedback which helps us refine the model and increase the depth where required.

During this process, the team will be able to refine and understand their role as well as the part that they play in the process. Being part of the creation process, helps the whole team adapt to the change. It’s all about bringing the requirements to life and keeping the benefits front of mind throughout the project delivery lifecycle.

Then comes the fun bit: documenting the model. We adapt how it is documented based on what works for the client and team. It’s about having the model to hand, having it accessible, storing it in a place that is available to all. More importantly, it’s about producing documentation in a way that is easy for individuals to understand and maintain.

6. Adoption and piloting the model

The proof is in the pudding as they say! Once the model has been developed and documented, how do we test it to see that it works? We run real world deliveries using the model, using one or two epics as pilots. If using Agile methods, scrums can be run with the model to hand, the scrum master keeps everyone honest when it comes to roles and deliverables as agreed in the model.

The feedback received during the process will allow the team to refine the model, to a state that works for them.