What to consider when growing a software team

A few weeks ago, we had the chance to do Myers-brigs at our office. As it turns out I am an INTJ. You can find your own type on this site human-metrics.

As a base rule, mixing individuals from different personality types leads to better creativity albeit at the expense of efficiency.

Developers, in particular, have an even more nuanced environment. Fred Brooks famously said:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures....

This means as you grow your team, there are certain things to look out for. In this entry, we will be exploring the factors I think are the most important.

Does the team structure compliment individual’s strengths?

We perform best from a position of strength, yet somehow team leaders assign individuals to tasks optimised for the organisation rather than for the individual’s strength.

A simple test such as the MBTI can help you easily see who would work best with who.

As Wegner proposed in 1985 the greater intelligence born of the group mind which comes about from great collaboration is guaranteed to benefit your organisation.

Is anyone multitasking?

Human’s can not multitask. The illusion feels so powerful that the team leads don’t even need to push this agenda, the developers will take it upon themselves to do it!

Despite numerous studies, including this one Who Multi-Tasks and Why? Multi-Tasking Ability, Perceived Multi-Tasking Ability, Impulsivity, and Sensation Seeking we still assign developers to multiple projects.

Two projects are optimal for an individual developer, in this way, they can switch to a different task to give their mind a break and some room to chew on the project. Anything more is likely to lead to reduced productivity as the mind becomes too clouded.

Have you limited the team size?

We have limited cognitive ability in terms of the number of individuals we can maintain in our circle. Known as Dunbar’s number, it is shown we can actively keep at most 150 active social contacts.

I believe working groups are even smaller. Once the team size gets to more than 5, communication issues start sipping in. It becomes that much harder for the team to build and maintain a shared mental model.

Mike Cohn has an even simpler rule, no team should be so big it can’t be adequately fed by two pizzas!

What is the team’s purpose?

Shortly after joining Moringa, I was having problems getting the team to work together let alone towards any goal. I explained my dilemma to the CEO. She asked me, “Have you carried out a values exercise?”.

This question changed how I think about teams, yes we can impose what we want to the team, but the team just like any other complex system will work towards its own goals.

The only way to get your team to succeed is to imbue them with a sense of purpose which aligns with the organisation.

Can the team deliver the product from end to end?

A basic tenet of the scrum and agile methodologies, in general, is the concept of the cross functional team. The simplest definition I could find of such a team was:

A cross-functional team is a group of people with different functional expertise working toward a common goal.

Cross functional teams are the killer feature of agile. They bring about diverse views to the teams enabling good ideas to be quickly tested, built and shipped.

How long do the teams stay together?

In a previous entry, Stop killing your teams now! we discussed the tragic fate of most teams.

I believe now as I believe then, teams should be built for the long term. Like the tired cliche of the good wine, good teams get better as they mature.

How do you grow teams in your own organisation?

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Core technical practises for your scrum team

 

Scrum is a fast moving development style. There is obviously a lot of advantage to this, but just like a sports car needs a better technical design to function at top notch, so does your code.

In this entry, we will be looking at the top three technical practices that you must adopt to ensure you are moving as fast as you could be.

Test driven development

A few days ago, our team was faced with the challenge of stress testing one of our applications. One particular use case proved particularly hard to do, the only way to run it was to literally have an actual human run through the steps!

This might be fair if we were doing UX testing, but in this case, it proved to be a big red warning sign on our architecture.

We have since worked to correct our process, but the point here is TDD helps you unravel problems before they become Problems.

By writing the test first then the code, you are forced to think through what it is you actually want to do. This makes your code clearer as well.

Not to mention, by having a “second opinion” on the validity of your code, you can deploy far faster knowing another system is checking the integrity of the entire product.

Continuous improvement

If you have ever struggled with your weight, I am certain this thought has ever come up in your mind at one point or another

Let me just eat this burger, I will work it all out later in the gym

A fantastically bad idea! Not because you will procrastinate later and not visit the gym, thou this is likely, but because you essentially threw a good chance of working towards your goal and worse compromised your future self.

In the same way, almost every day you jump into your code, you will come across an opportunity for improvement perhaps a better design pattern to adopt or even just to maximise on an opportunity to reuse code. Here you have the choice of either saying you will just do a patch now and fix it in the future or just fixing it now.

The formal term for it is refactoring and there is a wealth of knowledge out there on how to do it.

By continuously improving your code, not only will your code not rot but you will have code that gets better with age.

Collective ownership

Open source software tends to be of a much higher quality than propriety code.

We all care more about what we know someone else will look at than what we are sure only our eyes will see.

The long and short of it is you want as many eyeballs on your code as possible. Obviously open sourcing your code may not be the ideal solution, but what about having your team members work on the code together?

There shouldn’t be a part fully designated to only one developer, this gives you two key advantages:

  1. Not everything goes to hell if the developer goes on holiday
  2. Everyone cleans up their code just a bit better

Continuous delivery

In 2001, Paul Graham wrote one of the most prescient essays I have ever come across, it is titled The Other Road Ahead.

One of his key arguments revolves around the fact that faster code-test-deploy cycles lead to higher quality code.

I fully agree with this argument. Continuous delivery is guaranteed to significantly reduce if not eliminate the stress which comes naturally with software development.

No longer will demo day be a day of panic. For all intents and purposes, it will just be another day in the life of the boss developer.

I hope these pointers will help you towards a better scrum experience.

Which practices here do you use in your own practice?

Facebooktwittergoogle_plusredditpinterestlinkedinmail

What are the different types of requirements and why does it matter?

 

A software product is usually built with a purpose in mind. There is a reason a good number of web application domains end with “.io “. It literally means Input Output.

Your product takes in some raw information and returns more valuable processed information.

As usual, the devil is the details. What does raw information mean? What does output mean?

Scrum typically adopts user stories as its template for expressing its requirements.

This simple structure of:

    As a __
    I want to___
    So that __

Elegantly captures what the software should do and why.

Still, as the product gets bigger and the requirements pile on, I find it useful to impose some categories on the backlog.

In this entry, we will be looking at some categories which I have found to be useful.

User requirements

At iHub, we pride ourselves in our Human Centered Approach. The simple reason is it works.

The software serves people. At the end of the databases, activity streams, object storage etc is a person trying to get something done. Your success is measured by how successful this person is.

It then helps to acknowledge user requirements as a category on its own.

A typical requirement would be

    As a *researcher* I want to *have my results sorted by relevance* so that *I can get my work done faster*

Business requirements

We talk about the wonders of technology, from the aeroplane to the mini computer in our pockets. Yet, I would argue the biggest invention by humans was the enterprise.

Businesses, are the engines of our society, working behind the scenes, they provide us with all our material needs.

No matter how good, the software or how well it serves the users, if the business does not provide value to its owner then it’s as good as dead.

With this in mind, you must seek to also clarify why it is the client wants the software product built in the first place.

This is usually captured in the client’s vision statement. Of this, the software serves only a part of it.

An example of vision statement from Amnesty International

A world in which every person enjoys all of the human rights enshrined in the Universal Declaration of Human Rights and other international human rights instruments. 

If you happen to be contracted by Amnesty International, you need to remember to imbue this inspiring vision in every line of code you ship.

Non-functional requirements

Robert Gardy in his 1992 book Practical Software Metrics for Project Management and Process Improvement

Came up with the acronym FURPS+

This represents:

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

The “+” in FURPS+ also helps us to remember concerns such as:

  • Design requirements
  • Implementation requirements
  • Interface requirements
  • Physical requirements

The idea is in addition to doing what it does, software is also required to do it well.

How effective do you think Google would be if it took 5 minutes to give you a response to your query?

I believe by categorising your backlogs in this way, you will able to get more ideas on what is to be included in the final product as well as appropriately prioritise the various backlogs resulting from it.

How do you categorise backlogs in your own organisation? How did you handle it? Talk to me in the comment section below or on my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail