Why do developers disdain to go to regular meetings? Besides, Why managers consistently call for such a variety of meetings everyday?
As a developer, we understand, how tormenting it is to pick your notebooks and go to the conference room for an extensive management meeting amid an occupied busy day. Particularly, when you are profoundly involved in brain-teaser design and development work and desperately need solitary confinement to squeeze your brain cells to get the technical problem solved.
As a manager, we always believe that developing communication structure within and between teams for tenacious, persistent, continuous communication is of significant importance for developing an incredible product. If you are an ‘Agilist‘, you are committed to required daily stand-up meetings, iteration planning meetings, iteration review meetings, user story pruning meetings, iteration and milestone retrospection meetings. These meetings are important to close the feedback loop between teams, within teams and for an individual developer at different phases of product development. These feedback loops enable and empower continuous improvements in an iterative and incremental development environment. Agile needs regular feedback loops to drive the time-boxed iterations, get the team in a shared mindset and align product development activities with the product plans and milestones.
In a 2 week iteration, if a developer dedicate 15 minute per day on a daily stand-up meeting, 4 hrs for iteration planning meeting, 4 hrs for iteration review and retrospection, 2 hrs for product backlog pruning, It is 15.6 % of the total time(80 hrs) an individual developer has in a 2 week iteration. Investing 15% of you time in an iteration on effective meetings which enable development activities is not that awful for developers. The problem comes, when developers are frequently interrupted in their core hours, during the time when they are deeply engaged in design and development activity. This interruption can be in the form of unplanned meetings, interviews, cross-cubical talks, manager’s room chit-chat, unnecessary on demand sink-ups, management updates, group task reviews, and so on..
Development, particularly coding is a complex activity. It requires collective, cognitive alignment of numerous elements – mental models of problem definition and the environment, understanding of requirements and acceptance criteria, conceptualized solution options, approaches, design decisions, risks, assumptions, constraints, experiences, influence, understanding of the evolution and emergence of code and design etc. It is a challenge to bring all these elements in-resonance to discover and code the ideal solution. Interruptions, derails the cognitive processing. Interferences, crashes the cognitive transformation of ideas to working code. It makes developer mind to do a context -switch from one problem to another. Problems which are different. Problems which requires different cadence and mindset. When developer returns to development activity, it require them to re-build the mental structure and state. It can be like starting again.
Now, if you are repetitively doing the same kind development activity for a long time and your mind is hard-wired to repeat, you wont’ psyche getting intruded on, and your manager will love you for being so effectively accessible to him for on-demand dialogs. But, development brings new insight and learning every time you code. Each coding circumstance is different. You have to be alert, investigating, exploring to get the right code artifacts. Yes, even when you are using Google to cut and paste, your mind need to be active to learn and adapt it to your problem needs.
I ponder, why managers require these frequent sink-up meetings with team members. Particularly, if you are doing agile and committed to iteration deliverables. Why do they need to chit-chat regularly with the developers and discuss what you are doing now. Can’t managers join the daily stand-ups and get the status? Don’t manager trust the team’s sprint commitments, skills, knowledge, ability and capacity to deliver on planned work. Particularly, when they are themselves involved in building the team. Shouldn’t the manager spent more time facilitating the iteration review, iteration planning, retrospection meetings, and work on cross-teams communications, competency and skills development, individual’s objective alignment etc.to achieve bigger and broader goals?
The bigger question is – What do managers do in agile development?
This is not the topic of this article. I will answer it in another post.
Management and development work require different cadence to achieve its goal. When you are on developer cadence – designing and coding; the daily cadence cycle is longer. I see, 2-5 average non-stop hours required to achieve development tasks. Interruptions during these development core hours break the rhythm of a developer. This context switching can make developers loose the thread and blow away the entire day for them.
 |
Developer’s and Manager’s work cadence |
When your in Test-Driven-Development mode, a management call to discuss status updates can get us out of the context instantly. Here, we just composed a test to express what we intend to code, Interrupted! we lose the rhythm, the context and the mental-model of it. It takes time to re-build context, to go through the code again, and understand what we were thinking when we actually coded those tests. Everything requires significant re-investment of time and effort- A rework, a big waste. Not to mention the frustration it brings with it.
If you are working on management tasks, cadence cycle is shorter. Managers can switch between tasks within minutes, multi-tasking is accepted and recognized way of doing day to day management work. Management tasks – email updates, co-ordination meetings, status updates, risk assessment and mitigation planning, work facilitation, task planning, resource and capacity assessment etc. all can be composed in of shorter time activities.
Managers need involvement and participation of development team members to accomplish their work. Since, in most of the projects, managers are in more authoritative and legitimate positions, their call for unplanned short gatherings tend to drastically affect the developer’s development activity.
Manager’s tend to disrupt and upset the development activities several times a day. They are unknown of the fact that this regular interruption is causing a context-switch for developers which takes time to reconcile and is prone to loss of information, ideas, approach, problem modeling and solutions. It will reduce the quality of output, lower the productivity, increase re-work, affect the developer’s motivation and commitment and leave them exhausted.
Have you observed the complex behavior of a swarm of ants who have discovered a food source? Disrupt it! What amount of time it takes for the ants to return to the same behavior?
What can be done to bring these two required but distinct behaviors(Managers and Developers) in collective-cadence to achieve the desired shared behavior?
Give some attention to these important points:
- Managers should understand and recognize that there are two distinctive types of task schedules in the software development teams – management tasks and development tasks schedules(which require involved coding and testing).
- Everyone should understand the effect and waste caused by context-switching of development activities.
- Managers should learn to avoid frequent interruptions and allocate time for co-ordinated tasks which require involvement of development team members. Like, fixing the meeting timings in the afternoons or sending the meeting request, instead of an on-demand interruption.
- Managers should avoid the habit of frequently dropping by the developer’s desk or making calls for on-demand meet-up. Instead, keep a list of required communication and interruption logs and allocate time to do it when the developers are relatively free. Have empathy for developers schedule.
- The impact and intensity of waste due to context switching will depend on the type of development(especially coding) work. The more involved and collaborative a development task is, the more will be the waste in context switching.
- Developers need to understand the importance of accomplishing the management tasks for the project, and dispense time for it as a team in coordination with managers.
- If the developer feels that interruption and context switching is going to create waste, he should inform the managers and appeal for alternative time to meet. Yes, I understand, many managers will get offended if you request for a change in meeting schedule. They always want it now! I ask to these managers, isn’t ensuring high productivity, quality and facilitation of uninterrupted development activities your primary goal on the job?
- Are you an involved manager? Do you understand and have feel for complex coding exercises? Or Do you think, coding is like any other monotonous task which developer can perform without much attention? Because if you do, then believe me, you are soon going to get the team down. Good developers will leave you to work with better managers.
- Listen to your developers, and develop a working schedule for shared activities.
- Developer needs to structure their day. Know your schedule, what development tasks you need to accomplish, there complexity and communicate the same to managers.
- If developers can’t avoid some interruptions, it is recommended to record their last thoughts before joining the meetings. It will help in resuming the task again.
- Developers can move to meeting rooms when they are working on complex, involved activities which require uninterrupted focus.
Technodeation 