I propose that there are (at least) three types of regular project rhythms for individuals, teams and development organizations, and there are corresponding forms of unsustainable pace that accompany each rhythm.
Day to Day Development
For an individual, the day to day rhythm of development may include rituals such as getting a morning coffee, reading /. before work, eating lunch, and any regular team-related events. For a team, daily rituals may include a morning stand-up, switching between driving and navigating when pair programming, or switching pairing partners every few hours. Disturbances to a normal pace might include a dentist appointment, illness, oversleeping. These occurrences rarely harm a project because they tend to be infrequent. More insidious are consistent distractions that become an irregular part of the regular day-to-day pace. For example, in a non-pairing environment, there are often a few members of a team who are in charge of code quality control, who are domain experts, or who have specific technical expertise, and these superstars face constant interruption from other team members asking questions or needing code reviews. This type of interruption drives down the productivity of the individual, but can improve the team through the spread of knowledge. One benefit of pairing is that this type of knowledge transfer and the constant review of code quality becomes a standard part of the day-to-day pace, instead of an interruption.
Any form of active notifications, such as instant messages or Outlook and Mylyn popups provide more intrusions. Open web browsers with unread articles of interest are a more passive distraction. Given enough open browser tabs, a developer will certainly notice a decrease in performance of other applications, such as development environments. Also, programmers will often justify reading technical articles on the job as a form of continuing education, even if the article is not related to the current project, or they will justify reading an article by saying that they will make up the time by working later or by working from home to finish the task that they should be working on. This line of thought is particularly dangerous and directly contributes to what is often called unsustainable pace. When developers bring laptops home to work on stories that should have been completed during the day, that is a sign of unsustainable pace. When developers start thinking that they can put personal, non-work related programs or other distractions on their laptops, that practice can lead to a decrease in productivity and to unsustainable pace. Maintaining good pace is not just a matter of estimating tasks in manageable chunks or of sitting at a desk for no more than eight hours per day. It is a matter of having the discipline on an individual and on a team level to minimize distractions that can lead to incomplete work and to long days.
Sprint to Sprint Development
For a team, the rhythm of inter- and intra-sprint development may include rituals such as release and iteration planning, retrospectives, or weekly drops of code into production. Intermittent disruptions to this pace might include temporary (vacation) or permanent (termination, death, quitting) loss of team members. Such disruptions will affect team velocity but should not affect the occurrence of rituals. One form of sprint to sprint unsustainable pace comes from the repeated disruption of sprint rhythms and the cancellation or postponement of rituals. For example, when teams over-commit to a group of stories or set stretch goals, often the pressure to finish billable work will cause individuals to question the time spent on retrospectives or daily standups, which do not directly generate revenue. Consistently falling short on point commmitments undermines the morale of a team, which is another form of unsustainability; it leads to unsatisfied product owners; and the rolling-over of committed stories or the unfinished work from one sprint to the next may result in the pushing-back of sprint deadlines. Stretching a sprint from two weeks to three because commitments were not met treats the symptom and not the cause, i.e., that past velocity should dictate point commitments and not that committing to an artificial stretch goal will inspire a team to work harder. Repeated sprint extension degrades the meaning of sprint boundaries and reduces the satisfaction of knowing that a sprint is really complete.
Project to Project Development
For an organization, the rhythm of project to project transitions may include rituals such as kick-offs, code hand-offs, post-mortems. Teams may fragment or may move in toto from one assignment to the next. The smooth transition of individuals and teams is especially difficult because it often entails accurately predicting the end of one project, while the beginning of another often depends on the timelines or budget deadlines or product launches that need to be coordinated with another team in the same or a different organization. Often, when one project runs past its expected end-date, the transition period is especially difficult because over-allocated individuals may be put in the position of working 60-hour weeks to meet commitments to multiple projects. One individual split between two teams can also cause disruptions in sprint rituals because of scheduling conflicts and because of unavailability for consistent pairing on both teams. A long overlap between projects is certainly unsustainable.
The immediate dove-tailing of individuals from one project to the next, even despite some over-allocation, is a healthy sign. Inconsistent transitions with breaks of weeks between revenue-generating work, however, is unhealthy. The persistent lack of proper coordination of an individual's time can lead to a very insidious form of company-wide unsustainable pace. One particular example of this would be the feast-or-famine professional services company. New project work comes in waves. As a new wave arrives, there is a rush in one department to hire new developers with a specific skill set, rather than to double-up some developers temporarily or to transition developers from a starving part of the organization and re-train them. Self-organizing teams sometimes fail to see the bigger, company-wide picture and are only focused on the immediate success of individual projects. As the wave subsides, the sales pipeline looks sparse, so some developers are let go instead of transitioned onto established teams temporarily to help out, put on internal projects, or put into other roles (e.g., writing RFPs, going on sales calls) that have the potential to generate revenue. This cycle of hiring and laying-off is incredibly wasteful. The hiring process and the acclimation of any new employee to a company's culture and processes is very expensive. The lay-off process, as well, is expensive, and any number of lay-offs in a company for non-performance reasons erodes morale by generating fear, uncertainty and doubt, not necessarily about the quality of what is produced by the company, but about the position of the company in the marketplace.
The term sustainable pace means more than just 40-hour work weeks. Maintaining a company-wide sustainable pace may require interruptions to the normal rhythms of day to day or sprint to sprint development. It may require individuals to work long days or weeks for some period of time. It may require that individuals leave their comfort zone by stepping into other roles and being re-trained. Mostly sustainable pace means knowing when to be flexible and when to rigidly follow ritual.
No comments:
Post a Comment