The Sprint Goal, as defined by the creators of Scrum, is a selection of product backlog items that form one coherent feature, which helps a development team to work together rather than pursue separate initiatives. Ian Mitchell, a writer on agile software development, summarizes the usefulness of the Sprint Goal by writing the following statement on a blog post:

What we are getting at here is that the whole purpose of a sprint is to meet a Sprint Goal, and Scrum is framed to support sprint-based delivery. Take away the Sprint Goal and the rationale for using Scrum disappears with it. You might as well operate on the basis of continuous flow. Without a Sprint Goal to meet, sprint backlogs can serve no useful purpose.

The Sprint Goal is a description of the coherent increments that will be delivered at the end of the sprint and it provides guidance to the development team on why it is building an increment and how it should do so. If the development team discovers that they won’t be able to deliver that coherent feature during the sprint, they can negotiate the scope with the PO.

We can go even further by describing all the advantages of a well defined Sprint Goal and how it helps to get things done effectively. It helps …

• The team to understand the purpose of their work beyond the description of individual PBIs, which stimulates intrinsic motivation and compliance. This leads to better implementation as the team can keep the big picture in mind. A well known man built an empire on this concept alone.
• To keep the team focused on a small objective and avoid the negative impact of context switching. It can be seen as mini projects. These are clearly achievable multiple goals instead of a big one that is divided into chunks used to fill sprints (Waterfall disguised as Scrum). Focus is a very important concept to understand when you work with knowledge and creative workers (in the case of the vast majority of people in software development); it is probably the most important thing to work on in order to deliver value and quality to your customers.
• The team to collaborate on a single objective with required flexibility and empowerment (cohesion vs individualism). This leads to better shared responsibility as the success of the sprint will be evaluated based on whether the goal has been met, instead of counting all the individual tasks that can lead to individual developer comparison in the worst implementation of Scrum. This helps in getting cohesion which is the most important factor for a high performing team.
• The PO provide clear value beyond the selected product backlog items (PBI) and therefore improve prioritisation. This helps getting a realeasable product increment at the end of each sprint, which is the whole point of agile software development.
• The PO to communicate on progress based on working software, instead of a percentage of a list of individual tasks that means nothing to the customer. This also helps to create a valuable roadmap to communicate to users.
• The PO to get structured feedback from each meaningful increment instead of individual tasks. This provides the next sprints with new insights which automatically leverage the power of Scrum or any other iteration based framework.

The Sprint Goal, when properly used, is a proof that Scrum is understood and correctly implemented. Together with the (potential) release of a new product increment, this makes the Scrum Sprint really useful. Therefore, this is the first thing I check when I’m asked to audit an existing Scrum implementation. Sadly, this is the most overlooked artifact of Scrum, so if you begin a new implementation, start with the sprint goal and explain why it’s useful.

I realize that it has been nearly a year since I have posted on this blog. I was short of time rather than short of ideas. To make amends, I have come back with something slightly more ambitious than previous publications, the first of many I hope. In this article I will explain to you the results of a small study that attempts to verify a stereotype that was often mentioned to me during my career in IT: that software developers are introverts. This vision of the programmer runs counter to another persistent stereotype you might know: that software developers are attracted to novelty. Indeed, it has been shown that novelty seeking is positively correlated with extraversion and emotional stability (De Fruyt, Van De Wiele, & Van Heeringen 2000). This was confirmed to me by Michel Hansenne, professor of differential psychology at the University of Liège (2014). If these two stereotypes are contradictory, which one is true?

The first clue I found was in the search for novelty: it may be noted that headhunters specializing in the recruitment of software developers have not waited for the results of scientific studies to use this argument to entice new recruits by telling them about new technologies, they address this before even the issue of finance. This aspect of the personality of the average developer seems quite plausible because I have noticed many times that some of them adopt what I call “CV Driven Development” This is a counterproductive practice (for the company) which is to focus almost always new technologies, not for objective technical reasons but to be able to add this new knowledge to their resume or only for the pleasure of experiencing something new.

I then asked if anyone else had asked the question. Although I found no academic scientific study on the issue, I can still quote the Evans Data Corporation report “Developer Marketing Survey 2014“, the results were included and discussed in the popular online specialist magazine InfoQ (Avram, 2013). The report from this company, specializing in the analysis of the target population for this study attempts to provide an answer to this hypothesis through a questionnaire sent annually to its panel of over 75,000 developers in 85 different countries. Their results confirm the absence of introversion and confirms novelty seeking as a very common characteristic in the target population. My study attempted to determine whether similar results can be obtained using a standardized personality survey rather than self-evaluations in simple questionnaires.

To test my hypotheses, I used two personality surveys which compared the results to the mean population using the Student t test. One is the Temperament and Character Inventory-Revised (TCI-R: wiki) Cloninger. The second is the Revised NEO Personality Inventory (NEO PI-R: wiki) of Costa & McCrae.

The sample consisted of a total of 50 subjects, all masculine, some of whom responded to both questionnaires (32) and some only one (TCI-R: 38; NEO PI-R: 44). Note that this is a convenient sample since all these subjects are final year students of computer science who participated in a specialized coaching program of my design for which access was conditional on performance in an entry test.

If the results shed light on our question, they also give some interesting insight on other matters. First, with the TCI-R, there is a strong difference in the temperament “Novelty Seeking” (p = 0.000), which confirms the hypothesis that the developers would be eager for the new, this is not very compatible with introversion. One can also note an interesting way that the character “Self-Transcendence” which is associated with spirituality, is also significantly different from the mean population (p = 0.037), despite the fact that the sample was culturally eclectic.

The results from NEO PI-R found one statistically significant difference in the factor “Neuroticism” (p = 0.015) which determines emotional stability. This could be explained by the fact that most of the sample consisted of placed (ie successful) students. One can also note the interesting way that extraversion is a slightly above average level, which also confirms the hypothesis.

My results show that, for my sample, the dominant personality type is far from introversion. In fact we can demonstrate a clear difference from the general population in the dimension of novelty seeking, the opposite of introverted behaviour.

It is possible that the origin of this stereotype comes from a misunderstanding about what introversion is. The concept could be confused with another facet of the personality: ie sociability. But even here, the results of my survey do not support the idea of introversion (Agreeableness in the NEO Pi-R or reward dependence of the TCI-R). I think the genesis of this stereotype is in the very nature of computing that by its apparent complexity, may have created a divide between IT and others, in specific contexts, and perhaps even at different times. To test this idea would require the development of a larger study.

With the limitations of this study, one might assume that the difference is only statistically significant due to a sampling problem. Indeed, the subjects were all involved in an internship supervised by a center for innovation and creative projects. One could easily imagine that these subjects have applied to do their internship with us because they were originally already very interested in innovation and new technologies.

In conclusion, I would say that this study and the various initiatives in this area show that studying this particular population could prove to be a very interesting opportunity. The financing of an international study could also be possible: most customers mentioned on the website Evans Data Corporation consist primarily of multinational technology companies like Microsoft, IBM, HP, Google or Adobe for example. It seems to me particularly appropriate to find collaborators with one foot in the industry of these companies and the other in an academic institution doing research in psychology….

Want to participate in one of my future studies? Please fill in this form and I will contact you: http://bit.ly/psydevform

References

• Avram, A. (2013, Février 20). Are Developers Introverted or Extroverted? Are They Intuitive or Logical? Retrieved from InfoQ: http://www.infoq.com/news/2013/02/Introverted-Intuitive-Logical
• De Fruyt, F., Van De Wiele, L., & Van Heeringen, C. (2000). Cloninger’s Psychobiological Model of Temperament and Character and the Five-Factor Model of Personality. Personality and Individual Differences, 441-452.
• Hansenne, M. (2014). Entrevue & echange d’emails. (P. Mengal, Interviewer)

All software development team project managers hope for a dream team of successful developers working to assist the company to achieve its objectives. Unfortunately, this type of team is very rare in all professions, including in the area of ​​software development. I am thinking particularly of enterprise applications or software companies where teams of developers are working simultaneously on the same code base of the same product.

The reason probably lies in the way we generally go about increasing developer productivity. It is probably too focused on improving the hard skills of the individuals (e.g. sending them on technical training and evaluating them individually on these points) and not their soft skills which without doubt positively and significantly impact on the effectiveness of the whole team. We should also consider “groupal” improvements: organizing the team so that it can naturally grow and reach a much desired level of maturity.  Raising awareness of the groupal phenomena is an example that I will specifically address in a future article.

I propose here a brief introduction to the concept of team dynamics that I will discuss more thoroughly and specifically in future posts. To begin with, I offer a definition from “high performance teams” research in group dynamics and organizational psychology. This approach is put forward by Katzenbach & Smith (1993) in their book “The Wisdom of Teams” and seems to me to be a particularly interesting way to begin addressing this issue. Both authors propose, as a first step, to clarify the difference between a single group of individuals and a team:

“A team is a small number of people with complementary skills who are committed to a common purpose, performance goals and approach for they hold themselves mutually accountable.”

We will see how this breaks down operationally. According to Katzenbach & Smith, the characteristics that differentiate between a normal team and a successful team are:

1. A limited number of members

As the number increases, it is less easy to maintain high efficiency. As suggested by the authors in their work, it is clear that problems of communication grow along with the size of the team.

2. They are composed of people with complementary skills

We immediately think of the different technical skills, but it goes further than that. The authors propose three categories of skills:

• Technical & functional expertise
• Problem-solving and decision-making skills
• Interpersonal skills

In software development, we tend to wrongly focus on the first category (hard skills) while neglecting others. One of the best ways to increase the efficiency of an entire team is to invest in developing their soft skills. This should also allow them to see things from a “groupal” perspective as opposed to the “individual” view which is overwhelmingly the case. In addition it should be noted that the multi-complementary members of a team involves active support – and that even within the same skills category. Thus, the developer of the backend will fully rely on the expertise of the DBA when needed and vice versa. All promotion of individualism, for example by individual evaluations (explicit or implicit), would make a good team ineffective.

3. Committed to a common purpose and performance goals

This is a common objective defined in agreement with the team. The goals should never be imposed by any individual (eg the team leader). The performance of the team to achieve the goals must be measurable. The measurement method is paramount and should in no case enter into conflict with the above principles, for example by measuring the team members individually and not collectively.

4. Committed to a common approach

This approach should also be clearly defined. It seems to be that the first requirement is the establishment of coding guidelines that must be enforced by a continuous integration server and / or frequent code reviews. The latter, to be effective, must not be made by the same people but by the team in rotation. This allows different members of the team to share learning and leads to a mutually enriched team. The criteria should be re-discussed and re-evaluated in a retrospective sprint (if you work in an iterative model as Scrum). The team should also have overall responsibility for development tools it uses. If they have a strategic interest in the company, its main users should be involved in one way or another in the discussions. Which brings us to the last point.

5. Mutual accountability

This element seems to me particularly important to ensure good cohesion in the team. If you want to get to an optimum efficiency level, you must delegate some control over the project to the team (eg the choice of tools as mentioned above). The worst situation would be to make the team fully responsible for the result but taking away any means of control over their performance. This would create very severe stress that would be counterproductive for the entire organization.

As you may have noticed, there is plenty of room for discussion. And this is just based on the findings from a single study. There are hundreds of other studies that will allow me to return to these questions of team dynamics (aka group dynamics) very frequently in the future.  I think that this is a fundamental element in the field of software development. The specifics of this sector will allow us to approach things differently. I am thinking especially of the psychological profile of the developer in general (myth or reality), but also the technical means available to create an optimal working environment to meet the criteria for achieving optimum performance. For example the use of the continuous integration server but also the various meetings organized within the framework of a method of iterative development.

If you are interested in the subject, do not hesitate to share your experiences in a comment or by contacting me directly.

Breaking the build is highly prejudicial to the productivity of a development team. Since it’s pretty easy to avoid it by ensuring that the code compiles locally against the latest version and doing continuous integration, it is often taken as an act of rudeness.  The person responsible for the act must therefore be punished.

Photo courtesy of seeb’s Photo Stream

The punishment often consists of making the guilty party wear a specific hat (we use a Sombrero) or any other very visible humiliating clothes, until they solve the problem themself.  In addition to this, some teams may want to signal breaking builds with a specific sound played on speaker (we used a darth vader or homer simpson voice).  Some teams get even more creative as you can see in this video.

I found the whole thing very funny and I always promoted it in every team I worked in to reinforce team spirit.  That is until I met a couple of people who were really reluctant to join in and did not want to publicise their actions.  Even when I broke the build on purpose to wear the hat, it did not change how they felt about it.  One of them was from a different country where such humiliation could not be taken to this degree (as we can, I hope).

I think this kind of game is one of the many things we see online and we want to replicate without thinking, but it is not always a good idea. While it can be a very good team building feature, it can also contribute to making some team members very uncomfortable.

If you really want to do it as the manager/team leader, ask every one in the team individually. Asking in front of others will prevent you from getting honest feedback.  In fact, it’s usually better not to implement such a rule in your team unless it’s really something everybody wants.