So you dont know what your team is doing

Hello friends. In this article, I will explain what to do when you don't have a clear picture of what your development team is doing. Not having a clear understanding of what the team was doing was the first measure discussed. It may sound quite weird that a manager doesn't fully understand what their team is doing; however, it can be common for this to occur primarily in an experienced team or when the manager is new or non-technical. So with that, let us get started.

Problem statement

You have responsibility for the management or oversight of a development team. Details such as the size of the group or what they do don't matter. But primarily this team will develop and support a particular application (or system) for a company. The team never seem to be slacking off, and they always seem to be busy. The team has a group of users that seem to be happy with their app and love the development team. So far, so good right. 

The issue is that no one knows what exactly the team does all day. When asked the members of the group give vague answers designed to deflect the question rather than answer it. The team doesn't do any reporting or have any development management systems in place that you could get an idea of what exactly they are doing. When you try to understand, them to do something they are too busy and try to deflect the request hoping you will give up and leave them alone. The team is happy doing what they are doing, and they do not want tasks or directions from anyone outside of their team. 

What could be happening here

There are several reasons why a team would be behaving in this way; these include:

Happy with status quo The team are glad to maintain the status quo of their current work arrangements which include their tasks, schedule and technology that they use. They enjoy the work that they do and are comfortable doing the same thing. When quizzed they will find some busy work to make them appear busy so people will give up and leave them alone, however more often than not the business won't notice if this work gets done or not.

Propping up a legacy system The team could be spending most of their time propping up a legacy system which needs intensive maintenance (at all hours of the day) to keep operational. By investing this time, they keep their application users happy, and the team may feel that by keeping the lights on for this system they are doing their jobs and don't need to waste time with managements requests. Work such as this may seem like productive work to the team; however, the business would benefit more in investing in a modern system which doesn't require the sizeable manual overhead to operate. 

They don't know better  Some teams have never worked with formal development methodologies or development management systems and as such don't understand the benefits these things bring. Their day to day activities become so chaotic and unorganised they actually may not know what they are doing day to day themselves. 

A better approach

Ideally, a good team should be able to tick several boxes with their development activities.

• Business drives priorities: The company actively prioritises work that they want to be delivered. 
• Work is planned: All work tasks are planned out according to the business priorities with everyone understanding what is required and the due dates.
• Visibility of tasks, status and issues: Updates to a task board (scrum/kanban) are made daily with current status providing visibility to anyone interested. Daily standup meetings used to discuss progress or seek assistance for issues.
• Progress is visible: Showcases of development held regularly to demonstrate progress and to provide a way for feedback from the business 
• Focus on improvement: Regular retrospective meetings to discuss the things that went well and the things that need improving. These are opportunities for people to discuss ways to make improvements and take ownership of these actions.

Where to start?

Every journey starts with a single step, and the same is true of making improvements to an engineering team. Typically it takes 12-18 months for an engineering team to hit their straps and be fully capable, so some degree of planning is required to map out the improvements that we wish to implement. We can, however, expect to see gradual improvements take hold of every sprint/retro. With that said, let us dive into each of the points above to discuss.

Business drives priorities Business-driven priorities are guiding a cornerstone of any effective development team. Development teams don't just exist to work on their side projects; they exist to serve the business. As such, it is critical to set up a framework whereby the company can capture, review and prioritise the work that needs to get done. Typically this is done via a product or program management function, but in reality, anyone can step in and fill this role. Business requirements or priorities are gathered on an ongoing basis and collated into a list that can be reviewed and stack ranked by the business in priority order. The frequency of this activity should align with the release cadence of the development schedule. Once the priorities are agreed, the development team can work down the list in priority order safe on the knowledge that they are always working on the highest priority items.

Work is planned Plan to work and work the plan. The old saying is relatively accurate when it comes to software development. Once we have our prioritised list of requirements, we can now work to deliver these items. There are a few critical areas that the development team needs to consider and plan out in the delivery of these business requirements. These are: How often will be releasing our software to production?, What will requirements will the team commit to delivering in the release? How are we going to get the work done? 

Once the decision on the release frequency (i.e. annually, quarterly, monthly) is made the rest of the planning of the work can start, the work items added to the schedule; our sprints can be mapped out and work spread across these for completion. Each sprint is planned just before the end of the previous sprint and is dependant on what the team completes against their last sprint goals. Sprint planning continues until the end of all the sprints, and the work is delivered. We can write a whole book on this topic, but you get a good idea of how important some fundamental decisions are concerning our planning.

Visibility of the roadmap, tasks, status and issues So by this stage, we have our prioritised list of business requirements and have done planning around our release (inclusions and schedule). The release plan or release roadmap needs to be communicated to the business stakeholders to ensure they have visibility on the delivery schedule and additions. The roadmap should be accessible to all key stakeholders. 

The next level of visibility focuses around visibility of the daily tasks, progress and issues. We can get this visibility in a couple of ways. The team should be tracking their tasks (user stories, defects, work items) in a development management software such as Jira or Azure DevOps. These tools provide reporting on sprint status by setting up Agile boards (Scrum, Kanban) to give a visualisation of the work in progress. 

One of the most useful tools for the team to manage their delivery process is the daily standup. The daily standup is an opportunity for the team to meet each day to give a quick status update on their tasks and whether they need some help with a problem. This daily feedback loop enables the team to keep on top of their delivery plans and jump on issues collectively before they burn too much time.

Progress is visible A team is judged on its output at the end of the day. To ensure the team retains focus on their deliverables at each stage, we can schedule in showcase events, regular meetings during the release schedule in which the team demonstrates the progress of their development efforts. Showcase has a two-fold benefit. Firstly this incentivises the team to stay on top of their delivery schedule and produce software which can be showed to the business. Secondly, it provides an opportunity for the company to review the software to ensure it is meeting their needs and will work as expected. This feedback loop enables the company to ensure they are getting the software they need to deliver the value they require.

Focus on improvement Finally, the team needs to have a continual focus on improving their work and the way they work. Ideally, after each sprint, the team will have a retrospective meeting to enable time to consider what's has gone well and not so well. The retro meeting is a time for complete honesty in the team and allows the team to record the good and bad without fear. The retro also provides time for the team to consider how to improve and make the issue better next time.

Conclusion

I hope I have provided some clarity around how we can set up a development function that focuses on delivering business value and is transparent with the work that is under development.