Whilst the project management gurus and Agilistas talk about methods such as Scrum as if developers only sit on a single project, the reality is that they don’t. Developers are charged with concurrent projects, each with their own constraints which require autonomous scheduling of development effort according to resource availability or even what is considered easier to focus on at the time. On top of this, the inevitable support obligations of applications previously delivered will undoubtedly pick away at development time. Sure, this is not an ideal situation and is known to be an inhibitor of Agile, but it is often reality for those developers not working within sexy start-ups with a single product or the larger software houses.
Within this multiple project, support intrusion reality, it is easy to fall in to the trap of starting projects with much enthusiasm but then seeing the initial sprints turning into a drudge as developers fight to keep the project and their own enthusiasm alive amidst the chaos of a demanding multi-project portfolio. Priorities change, resources are re-allocated and interest wanes across the business.
My suggestion in this circumstance is to keep project iterations small, and keep them warm.
Consider this example team, with their own project portfolio.
The projects are spread across the team members with multiple developers able to work on the same project. Projects are worked on in fixed timeboxes, which allows developers to apply Scrum-style working to generate velocity metrics that help improve predictions of future performance.
Longer projects cause developers to “go dark” from the team and the client. They are less visible and accessible to the client and become less available within the team’s portfolio of projects without sacrificing their existing project effort and therefore attention. Instead, breaking the projects into smaller iterations and spreading across the team means they can be switched in and out predictably and with minimal friction.
Johanna Rothman suggests using a “Parking Lot” to hold projects in a warm state in between sprints. This provides an ideal opportunity for users to become involved and fulfil their obligations as part of an Agile project and provides the client with a predictable obligation within an existing workload as part of their day-to-day business.
Developers can be switched in and out of projects, allowing for cross-skilling and redundancy for support obligations. In the three-developer team illustrated, each project has a minimum of two developers who have worked on the project and who would be able to support it.
The team lead will remember when their team has booked their holidays, right? Adding them to a project plan helps visualise the team member’s absence ahead of time, allowing developers to collaborate beforehand about possible risks or support obligations and applies redundancy.
The method (Scrum, XP, Kanban, etc.) is unimportant. I’m not a consultant selling ideology, this example is based on experience of working on multiple software teams.
- Balance between developer focus and availability to the portfolio. Developers work best with focus on the task, but must be available to the portfolio often at short notice. Allowing a project to be parked facilitates selection of the most-able developer in their own individual schedules within their own timeboxes to attend to an unexpected task. Equally, having fixed timeboxes allows the business or client to be promised attention by a point in time, backed up by a known and published schedule.
- Maintains sharp focus for developers who must develop within shorter iterations. Shorter timeboxes bring sooner objectives and deliverables. Tighter management of developer effort, particularly in larger projects, will help reduce drift in terms of scope and attention. This also reminds the business/client of their own role on an ongoing basis, with regular status updates and predictable resource requirement.
- Less cost for developer to rediscover context. Distractions cost time which cost money, though this is rarely quantified. The reality is often that a developer will need to context switch from project-to-support-to-project-to-chat-to-project. But this can be reduced and controlled. By limiting the demands on a developer’s contextual concentration within a period of time (timebox) to a single project, one can maintain a developer’s attention on the day-to-day support and collaboration requirement but maximise attention per project. Perhaps individuals may be designated “hot” for support tasks within a timebox on a rotating basis to minimise team-wide disruption.
- Keeps the user engaged. The role of the customer is often misunderstood and under-represented in Agile. Agile approaches are dependent on early and regular contact with the customer to gather feedback on project deliverables thus far. However, the client and wider organisation already have a job to do which the development team must respect. Keeping the cadence of user involvement to a regular and predictable timetable helps the user plan their own time within their existing obligations. It may be unsuitable for the user to be expected to contribute to projects at the end of every sprint, but regular contact will keep the user engaged, particularly if they can see improvements.
There are frameworks and whitepapers and methods and processes and the rest, but these don’t interest me. What works for the team is what works for the business. However, perhaps this structure may be integrated into your processes, formal or not. The use of timeboxes enables integration into a wider process, such as the SAFe Framework, where individuals and teams can be “plugged in” to the wider project as required.