Continuous integration, continuous deployment, and continuous delivery are creating a buzz in Agile circles. All these strategies must exist and work together seamlessly to reap the benefits of Agile. In addition, their continuous implementation help deliver business value.
Before integrating its work, the development team does its best to write amazing pieces of code that work well individually as well as together to achieve a particular objective.
During this coding or development phase, there is a fourth element of continuity that works behind the scenes and impacts future efforts. This fourth element is called continuous attention
. I've been marinating this idea for a while, and I felt compelled to share my thoughts and experiences about it. This is not something new; every developer understands and exercises continuous attention. But this is normally veiled by other terms, such as context switching
, that do not express the concept in its entirety.
Continuous attention means a developer is fully focused and attentive to a task, a user story, or a project that he or she is working on. We as developers dive deep into projects, but most of the time we are forced to come out of one ocean and jump instantly into another in the name of multitasking, performance, and productivity. This happens everywhere. Agile has no room for such shifting of focus, if there is an unwillingness to understand its impact.
I would like to illustrate this dilemma of shifting focus through a scenario that every developer can relate to.
Work on A, and finish it by Thursday.
OK. It will be done.
Later . . .
Work on B; the client needs it urgently. It’s just a small thing.
But . . . this . . . OK.
It happens again.
Work on C; the CEO needs it right now, and you know the boss is always right.
But . . . this . . . OK.
What’s the status of A? Is it done?
Uh . . .
When we have agreed on certain tasks and schedule them, continuous attention is required to complete the task on time with the desired output. There is no silver bullet to get things done when attention is not continuous and we face distractions. Sometimes these distractions are due to unforeseen circumstances, but mostly they are caused by a change, a new requirement, or something else that we are forced to work on.
Humans are not computers, nor must they be expected to work like them. A study cited in Gerald Weinberg’s book Quality Software Management: Systems Thinking
shows that approximately 10% of time is lost due to lack of continuous attention. When changing our attention from one project to another, we actually have to make a drastic shift in context about many things, including audience, architecture, conversations, and last decisions made.
Responding to change is good, but one must understand its impact and the trade-offs. Developers working in traditional settings have no way to visualize their work flow and fall into the trap described in the scenario above. Even bad practices in Agile settings can cause similar problems. Although, if an Agile method is in place, the chances of this happening are low. However, in situations in which developers are working on multiple projects, they are prone to such shifts in focus.
The development team, whether or not they are working in a traditional or an Agile setting, must adopt the practices below:
- Learn to refuse distractions.
- Concentrate on the tasks that are truly significant.
- Avoid multitasking as much as possible. It only keeps you busy, not productive.
- Visualize your work.
- Use a Kanban board or something similar to show work in progress.
- If a change is being forced, raise your concerns regarding time, and convey the impacts clearly and straightforwardly.