Of software development methodologies, teams and individuals

Whilst pushing new methodologies into a software development team, one should understand the difference between methodologies of team relevance and of individual taste…

At least in my small software developer’s world, I observe some controversy on how a team is to do software development the right way and which methodologiesa team got to adopt. Overstating the case (yes, I am guilty), opinions regarding software development methodologies might look as follows:

“… our team must do Test-driven development - we are TDD …” - “… we ought to integrate TDD into our development process ‘cause that’s how individual developers will deliver better results - period!”
“… living the spirit of Kanban means that the team must do Code Kata to get better …” - “… practicing Code Kata is the way for you developers to get a good coder …”
“… Scrum is the way (methodology) we organize our software development process …” - “… our team is settled upon agile software development for seamless teamwork…”
“… coding is done in our company by strictly doing XP …” - “… everyone must do pair programming to deliver better code …”
“… you’ll get your work done when you are confessed to GTD …”

You might have heard them statements above here and there? I surely have. It is on the teamto do this, it is on the teamto do that. You may truly believe that the one or the other statement hit the bull’s eye? You think if everybody in the team would obey them above stated methodologies, the team would finally deliver good software (as of your point of view)? … You feel uncomfortable with (some of) them statements?

Are all statements above correct or is none correct? Have you noticed that I highlighted the words team, individual and methodology throughout this text? To me it seems that the answer can be boiled down to those three keywords and the question:

What do the above mentioned methodologies have in common? Where are the differences? Is there any differentiation regarding the team, the individual and everything in between?

The buzzword cloud

Let’s take closer look at the buzzword cloud of methodologies to be applied to a team:

Agile Scrum Kanban Code Kata Coding Dojo Test-driven development TDD Extreme programming XP Pair programming Getting Things Done GTD

I experienced that supporters of the one or the other methodology from above believe in them in terms of an ideology. As of discussions I observed, I got the impression that the ideological view on them methodologies gets vastly overemphasized, underemphasizing other aspects.

I believe each of the methodologies from above has its right to exist, though take care to take an experienced look at your given circumstances …

Are we all equal?

I observed that there is a big misunderstanding between the methodologies for the team to work together seamlessly and the methodologies for the individuals organizing and structuring their own work and the methodologies for individuals teaming up. Them methodologies seem to be considered applicable to a team as a whole. This leads me to the question: Are we all equal? Can a methodology be expected to work for each individual the same, if we only try hard enough? I don’t think so. Let us take a closer look at the team and the individuals of a team teaming up:

The team

The team is represented by all the participating individuals. It somehow has to organize its goals to get some deliverable in time and in money.

The individual

The individual has talents, weaknesses, strengths, preferences as well as antipathies, not to forget the individual’s experiences. Just to mention some characteristics where individuals differ from each other.

In the 1970s, the discipline of the Psychology of learning worked out the concept of learning styles (Lernstile), identifying three learning modalities:

Visual: The individual prefers digesting information in a visual style. Such as working out a mind map. Such as drawing a UML diagram. Such as highlighting a text’s passages of importance. Or such as mentally visualizing the circumstances of interest.
Auditory: The individual prefers digesting information in an auditory style. Such as explaining issues to another individual. Such as reading aloud a text’s passages of importance. Or such as recording relevant issues on tape.
Kinesthetic: The individual prefers digesting information in kinesthetic style. Such as being in motion whilst working on topics of relevance. Such as writing down keywords on post-its. Or such as ticking off digested issues of importance.

Guess what? Not everybody equally prefers the same mixture of them learning styles. Oversimplifying - for the techies amongst us - an individual may be 65% visual, 25% auditoryand 10% kinesthetic whereas another individual may be 30% visual, 55% auditoryand 15% kinesthetic.

The team consists of individuals who are not equal and not equally exchangeable.

Individuals teaming up

Now often individuals work together in small groups to accomplish some goals. They team up and have to find a way (methodology?) on how to best challenge the given goals.

Methodologies

Methodologies give you a good guideline, being a set of balanced best practices, on how to accomplish a goal.

Methodologies can be seen as a tool-set tackling various differing types of challenges.

So let’s take a closer look at them methodologies and how they team up with an individual and the team and everything in between there:

Some methodologies are relevant for the team
Some methodologies (may) belong to the individual’s tool-set
Some methodologies are a good approach for individuals teaming up.

What I am missing is the classification of methodologies such as: Team methodologies, Personal methodologies and Team-up methodologies.

Categorizing methodologies

Let me catch up on this. Oversimplifying I would categorize the methodologies as follows:

Team methodologies: Team methodologies are applicable to a team as a whole. The team knows and has to know the rules of the methodology in question in order for the team to work together seamlessly.
Personal methodologies: Personal methodologies are adoptable by an individual supporting that individual coping with daily business. Whether personal methodologies are applicable depends on the bias of that individual. The individual should have knowledge on the personal methodologies out there for choosing the ones which individually fit best. Though an individual cannot be demanded to adopt a given personal methodology.
Team-up methodologies: The team-up methodologies are applicable to a group of individuals teaming up to challenge a given goal. Which team-up methodology to use for a given group of individuals teaming up depends on the mixture of biases of those individuals. The individuals should have knowledge on the team-up methodologies in order to decide which one suits them. They “speak the same language” which makes finding the best approach (team-up methodology) much easier.

“… As of the categorization from above, many methodologies are wrongly considered as being team methodologies …”

Methodology categorization table

Below find a table which categorizes the mentioned methodologies accordingly:

	Team methodology	Team-up methodology	Personal methodology
`Scrum`	X
`Coding Dojo`	?	X
`XP`		X
`TDD`		X	X
`Code Kata`		?	X
`GTD`			X

What do I think?

Let me examine the statements right at the beginning of this text. Here some individual seems to propose methodologies which that individual believes are good for the whole team and therewith for all the individuals building-up the team. As of the categorization from above, many methodologies are wrongly considered as being team methodologies:

1. “… our team must do Test-driven development - we are TDD …” - “… we ought to integrate TDD into our development process ‘cause that’s how individual developers will deliver better results - period!”

TDD should belong to an individual’s tool-set; also for teaming up. TDD in conjunction with REST enables unexperienced developers to magically build good interfaces. The more software designing experience you have, the less you require to follow TDD in every detail. For my taste TDD is a tool one can use to solve a problem in a well structured manner

I am the visualkind of person, so I happily do software design and sound interfaces using UML. By the way, what happened to the cool round trip engineering tools like TogetherJ and Together Control Center?

I guess an experienced developer picks some TDD best practices for her / his individual’s tool-set. With TDD the junior is taught on how to approach a problem in a well-structured manner. It is not a team methodology.

2. “… living the spirit of Kanban means that the team must do Code Kata to get better …” - “… practicing Code Kata is the way for you developers to get a good coder …”

A Code Kata every now and then can be fun, especially doing it with other developers, exchanging ideas.

Being Code Katas an event for exchanging ideas looks fine to me.

I also believe that a good developer is a curious and creative developer. Always trying to find out new and better ways to solve some problem. Therefore a good developer won’t need Code Katas to try out different solutions for a given problem. An experienced developer most probably mentally tries out various approaches before deciding on one or two of them; given that the experienced developer is a good developer ;-). Same again: Code Katas are not mandatory. Each individual in the team should know on Code Katas and that them are a tool which one might use to sharpen one’s skills; keeping in mind that it’s not everyone’s cup of tea. It is not a team methodology.

3. “… Scrum is the way (methodology) we organize our software development process …” - “… our team is settled upon agile software development for seamless teamwork…”

Now we got a team methodology whose tool-set and roles are to be known by the team. As it is a team methodology it is mandatory - nothing much more to say.

4. “… coding is done in our company by strictly doing XP …” - “… everyone must do pair programming to deliver better code …”

A very individual thing, there are some factors which influence whether XP will work for two individuals teaming up or not. So it is very much up to the individuals in question whether they want to practice this team-up methodology. As dislike or affection regarding XP is very individual, it should not be treated as a team methodology. Being a team-up methodology it should be up to the individuals whether they want to practice XP on a regular basis.

5. “… you’ll get your work done when you are confessed to GTD …”

It’s a good thing to know how Getting Things Done works. Each individual might pick some best practices working best for her / him. By the way: Decades before, secretaries applied similar schemes to get their filing system organized. As each individual is different, there is not one way which is the right way to get things done. Some people can keep everything up in their brains not forgetting anything. Usually people believe that they can remember everything, usually they are wrong - and it would be a good idea for them to take a look at GTD…

Upshot

Actually methodologies are all about structure. Unexperienced developers need more assistance for structuring their work than experience ones need. So the personal methodologies and the team-up methodologies are good exercises to teach on how to tackle a problem in a structured manner.

Methodologies should make appetite fore more …

Regard methodologies being a tool-set making the best of an individual’s talents, strengths, preferences and experiences. One cannot level out each individual to like or dislike the same things, to have the same experiences and so forth. Trying to push personal methodologies into a team most probably will fail. Pushing team methodologies successfully into a team requires you to take a close look at the team constitution (the individuals) for you to apply the right adjustments to them team methodologies.