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

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

Sources of change in a software project

 

Change is an integral part of the software development process. It’s what makes software soft. In fact, change is so important in software that it get’s it’s very own line in the agile manifesto

    Responding to change over following a plan

It’s been a long time since software teams believed in the unchanging quality of requirements documents, but we are yet to fully understand where change comes from and how it affects us.

It costs far much more to make core changes during development than it does at requirements. Boehm and Papaccio estimate it at 50 – 100 times more. Even with the advent of agile techniques, it is still worth it to control change as much as possible.

In this entry we shall be exploring the various sources of changes, this should hopefully help you anticipate and identify impending changes as soon as possible.

Change from the customers

Of all the sources of change, this is the one worth most consideration. The reason is that as a consultancy or even engineering department, you want to harness change as a competitive tool for your client.

No matter how well you run your requirements gathering sessions, there are requirements you are bound to miss. This is because knowledge builds on knowledge ideas on ideas.

To illustrate this point, think of a car. The first car was a very basic box with wheels that happened to move. But from this idea, people began asking questions such as:

  • Why can’t the seats be more comfortable?
  • Why do I have to be hot in the car?
  • Why do I have to manually change gears?

Today, these previously extraneous features are deal breakers.

In the same way, once development has started, your customers are guaranteed to have new ideas as they see your progress.

In this kind of situation, you want to carefully weigh your options. You don’t want to do exactly what the customer wants you may end up always chasing after the new shiny thing. You also don’t want to completely ignore their wishes under the guise that you know best.

Change from sales and marketing

This part particularly affects product companies.

The product owner declares this Big Hairy Audacious Goal

    We will build a one stop best in class application within the next 6 months

This is a great goal and everyone is excited about it. The engineers get to work “banging” it out. Somewhere within the development window, the competitor does a release that you had not even thought about. The sales team also wants to be able to sell the new feature so they insist that is also put in the product after all our product is best in class right?

It is tempting to think of your application as a big checklist of features, this is dangerous because then you will be locked in competition with other firms to produce more and more.

Kelly Walters makes a compelling argument in Agile Principle 8: Enough Is Enough! that you likely don’t need to develop 80% of the features.

Perhaps then the product owner should have come up with a better goal say

    We will build a product in the next 6 months that will improve our customers margins by atleast 10%

Change from developers

Developers, my favourite group!

More than any other stakeholder, developers have the highest intellectual and emotional investment in the project. They are the ones who had to deal with the design flaws, unexplainable bugs and late night coding.

Yet to them, requirements are usually provided as a checklist. In this case am also looking at a list of user stories as a checklist. Without an organising theme, developers will do what they do best, write the best-designed code that they can conceive off.

The problem here is that the devil is in the details. Your DBA may end up writing code that shortens query time from 10ms to 1ms. This is great, except for the fact that no one really specified that they have that requirement. Another example would be where your front end engineer goes out of their way to guarantee that the settings page will work for all screen sizes.

I believe by actively watching out for this sources of change, you will be in a better position to manage them when the changes do come.

What are the sources of change in your own projects? Talk to me in the comment section below or on my twitter @ jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to proactively motivate your developers

 photo adventure-1807524_1280_zpsp9fxvtwy.jpg

If your business relies on developers for its success, you are worried about losing some of your best within the next year. If you are not, you should be, the turnover rate is surprisingly high.

In an industry where anyone of your employees can become a competitor with virtually zero cash investment, to begin with, you best find a way to build loyalty.

In a previous entry, we talked about some of the things that you may be doing to demotivate your developers and how to fix it. In this entry, we will be seeing how to be more proactive in motivating your tech workforce.

Build shared purpose

In 1995, Stephen Hawkings came up with a rather colorful description of the human race.

    The human race is just a chemical scum on a moderate-sized planet, orbiting around a very average star in the outer suburb of one among a hundred billion galaxies. We are so insignificant that I can't believe the whole universe exists for our benefit. That would be like saying that you would disappear if I closed my eyes.

The universe is large and for the most part doesn’t care about us. John Truant explains the concept further on his own blog. Crucially, he highlights the fact that we have to create meaning for our own lives.

Your greatest developers are acutely aware of how short life is. They want to do something meaningful with their life. Luckily, at this moment, they are working for your business, their passion and zest is thus available to you. Your task is to continually reflect the meaning of their work to them.

Are you providing medical care to the poorest of the poor? Take some of your techies to the ground. Are you streamlining government operations? Let your techies see the appreciation of your countrymen as they get service in minutes that would have taken weeks.

Let them make and own their decisions

Command and control as a strategy is just not feasible for a tech company.

Tim Hartford in his book Adapt: Why success starts with failure puts it beautifully.

    All you need are people with good judgement in other parts of their lives who care about you and will give you their honest opinion with no strings attached

Becoming a master software engineer is hard, even getting to a decent level requires a great amount of skill and effort. If on your staff you have someone who has achieved this status, they should get bonus points for resilience, patience and self-drive. In short, all the qualities you want in a good decision maker.

By providing only the higher objectives of the product or the business and letting the team hash it out. You will be pleasantly shocked at the novel ways that will come up with.

Provide time, space and resources to grow

I find it ironic that some companies will invest in expensive gaming equipment for the office but find conference costs to be wasteful. Even worse are organizations that give a ton of lip service to growth but provide no means of making this possible.

A while ago, I tried writing out an application using one of my favorite frameworks, Laravel. Shamefully, I no longer write as much code as I used to. The last time I wrote a production level app, Laravel was in version 5.2. At the time I was trying to write out my application, Laravel was at version 5.3. This should be easy peasy, right? Wrong! The entire framework had pretty much changed. Even the underlying language, PHP, has changed from PHP5 to PHP7! The migration doc qualifies as a mini-book!

The point is that technology tools and processes change really quickly. Thankfully the change is mostly for good. You want to harness this change to serve your customers better.

You must then provide your developers with the time they need to learn new technologies. As they are learning them, you must allow them the space to experiment.

In his book Curious: The Desire to Know and Why Your Future Depends On It Ian Leslie makes the point.

    A system will learn more of it explores more possibilities. But it will be more effective if it acts on the most likely one.

You want your developers exploring as many possibilities as possible.

Exploration is no cheap endeavour. It cost USD 13.25 billion to find the Higgs Boson, arguably the greatest discovery of our time. You can afford to factor in professional development in your budget.

How do you motivate developers in your own team? Talk to me on my twitter @jchex or in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

5 ways to keep your client in the loop

Software is expensive to develop. We all know that and are more than happy to charge our clients our true worth. For worthy clients the amount is not the issue, the project will likely net them multiples of whatever you charge.

Imagine yourself as a businessperson running your own bakery. You sell cakes to the local neighbourhood residents. You meet this awesome developer who promises you that they can boost your business by 100* if only you could enable customers to order online. This sounds like a good idea and you are all in, you invest 5 month income worth of your business to building the product.

A timeline of 8 months is agreed, contracts are signed, deposits are paid everyone is happy.

One month down the line you walk by the developers office to see the progress done so far. The developer tells you that they still are setting things up but are fully confident they will make the deadline.

3 months after commencement you once more walk to the developers office and you find that they have not started yet but claim their machines are all setup. You are told that there was sufficient slack allowed in the schedule and there is still so much more time to get work done. You are a bit apprehensive but you comfort yourself, after all this guys are professionals, surely they must be.

5 months later there is now some progress and they call you to their office. Eagerly you wait as they open up the first page of your brand new web app which looks freaking fantastic! You love the landing page, the color scheme is amazing, truly reflects the essence of your business. You try to click the link to login and are promptly stopped from doing so. As it turns out the page you are looking at is the only thing that has been developed.

Our story ends here, you see it does not matter even if the developer somehow delivers the project in the three months remaining, the project is already failure. The obvious reason is that the product will not have taken the clients feedback into consideration. Even more insidious, the developer forgot a basic tenet of software engineering.

    Perception of slow development can affect your project as much as the reality of it.

You see, it is part of the developers job to provide their client with steady signs of progress.

So how could the developer have gone about this task? That is what this entry is all about.

Standardized requirements and checkoff

In a previous entry I talked about Investing in user stories. A side benefit of using user stories is that they easily avail themselves to be broken down into developer tasks.

Developer tasks are actionable items to be carried out by developers.

By breaking down the project into such tasks. Progress can be made visible as tasks are checked of and then entire user stories are marked as done.

Status meetings

Now I hate meetings as much as the next guy. But truth is that the most effective form of communication happens face to face. This meetings don’t have to be long, they just need to be regular.

Scrum practitioners have mastered the art. Their meetings are called daily standups and last a maximum of 15 minutes. All team members answer the three questions:

  1. What did you do yesterday
  2. What will you do today
  3. Are there any blockers

Status reports

Ok maybe the idea of regular meetings is too hard to swallow, what about regular reports? The basic idea is the same as meeting but now people submit their progress via email or chat.

This can be more convenient since a record exists and the reports can be done asynchronously.

Milestone reviews

As a developer, you should only write enough code for the client to review. At project onset, you can decide this review periods and set them as milestones.

Bonus points if you can tie compensation to this events.

By having clear milestones and reviews, the client is kept in the loop and their feedback is integrated on future iterations.

Walking around

Yes I know developers are professionals and don’t need someone watching over them. But this has nothing to do with the developers. By giving the client a chance to come to your office and basically walk around seeing your scrum board, burn charts, design diagrams etc. They get pleasant warm feelings about the progress of their project.

I hope it’s clear to everyone why its important for clients to have this feeling.

How do you keep your own clients in the loop? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How NOT to debug

They say patience is a virtue, if you are a developer you need saint like patience to handle the notorious case of the bug.

Ever since Grace Hopper coined the term debugging our applications have gotten much better at creating harder bugs to debug. At this age, a moth in your machine would probably not even register as a fuss worthy bug.

While there is no “right” way of finding bugs, there certainly is a “wrong” way. Today we are going to be looking at some of the most common.

Output statements

God bless Taylor Otwell for this little tidbit

    dd($value);

The dd function dumps the variable passed on to it and then halts the script. By carefully using this function and some binary search chops, you can quickly identify problem areas in your code.

Most programming languages and frameworks provide this functionality in one form or another. Also it’s very easy to implement yourself.

Just like any other good thing, if it’s overused it becomes a problem. Just like any other good thing, its frequently overused!

It’s quite easy to tell yourself that I will put this code here to test if a bug is here and remove it later, but why test the memory gods?. Perhaps you will leave it nested in a conditional with a branch that is rarely executed. At least, rarely executed when you are testing your code. Guess when the branch will get run? Did you guess in production?

So what can you do about it?

Invest in a proper debugger. A tool like xdebug may take far longer to grok but once you master it, the rewards will be worth it.

Code like hell

This one is for all the Code Ninjas out there.

Fortunately I am not a ninja myself (See Why I am not a code Ninja). I am yet to change my sentiments on the matter.

The Code like hell style of development is where the code ninja pops up his/her favourite code editor and starts spitting out code. Damn the requirements and design.

Codebases that we’re coded in this way have a tendency to hide very hard to find bugs. The bugs are usually due to ninja level stupidity that mere mortals just can not comprehend.

If you find yourself debugging such an application, I am sorry my friend, the app is the bug.

So what can you do about it?

Follow a standard development methodology. Yes, even waterfall is better than code like hell. However if you are the unfortunate soul tasked with maintaining the application, start refactoring the code as soon as you can.

Versioning? For who? For what?

Git as defined by wikipedia.

Git is a widely used source code management system for software development. It is a distributed revision control system with an emphasis on speed,data integrity,and support for distributed, non-linear workflows.

Git as commonly used.

Git is a folder that can be pushed to a remote folder called github.

This mismatch in intend and use is characterized by thousand line codebase with one commit.

Unfortunately this scenario is all too common, even today. The effect of course is if you accidentally introduce a bug. You have no way of tracing it back to its point of origin.

So what can you do about it?

Learn to use version control properly. It really is not hard. In fact by simply using gitflow 90% of your problems would disappear into thin air.

Who cares about the need

Surprise surprise most applications we’re actually created to serve a need. Digging your grimy hands into the code’s innards without the slightest clue on why it works the way it does is simply disrespectful.

What you think is a bug just might be a feature.

    My software never has bugs. It just develops random features.

Ok that was just a joke, but seriously take the time to know the original intent.

So what can you do about it?

Take sometime to first check out the documentation and unit tests before starting the debugging. None of those exist? Refer back to the section on “Code like hell”.

Fix the symptom

With a few notable exceptions, a good number of clients just can’t explain their problem well. Instead they focus on what they can easily observe. As a developer you (hopefully) can see more. You see not just a misaligned form, but a missing tag. So what is a busy developer to do? Hard code the position and fix the immediate problem or rework the entire page to bring in all missing elements?

In the first scenario, the developer has just chased away the bug, be sure it will be coming back with its brothers, sisters and beer buddies. In the second scenario the developer solved the problem that caused the bug, not just the symptom of the bug.

If it took you more than a second to figure out the right choice you may want to check out How you pay for technical debt

So what can you do about it?

Don’t settle for the obvious, dig deeper. Try to find out what is the true cause of the issue you are now experiencing. The client will be happier and you will gain insights that will help you through your entire career in software.

How do you debug in your organization? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Invest in user stories

Meet Timmy. Timmy is a freelance developer with several years of experience. He has previously worked on small to medium size projects and has a good feeling about his ability to execute.

Meet Sarah. Sarah is head of sales at BigCo Consulting. Since she started at the organization as an intern, they have grown leaps and bounds. She now runs a team of ten people but managing communications within them is becoming unwieldy. She has at best, a vague idea of how tasks she is assigning are getting completed and in what time.

Sarah has heard of the good work that Timmy did for her friend. She believes that her organization would benefit a lot from his services. Seems everyone is making it big in tech this days and she wants in on it.

A kickoff meeting is set off between Sarah and Timmy. Sarah explains that she needs a system to manage her workers more effectively. They discuss about potential features on the product and come up with a list that Timmy is to develop.

  1. Secure authentication
  2. Task management
  3. Accessible from anywhere

This feature list seems good and Timmy comes up with a time estimate and tells Sarah what she needs to pay him. A contract is signed and they both leave the table happy.

One month later Timmy is back with the first MVP done. In the MVP the app enables Sarah to assign tasks to her staff but is still unsatisfied with the product. She can’t really pinpoint it but she doesn’t feel that the app will be particularly useful especially because she could have just as well sent out an email to the team member with the same task.

Sarah decommissions the app having only paid the deposit and leaves the table thoroughly dissatisfied. Timmy feels the deposit paid was barely enough to cover the work done and loses a potential referee for his work. What went wrong?

The curse of knowledge

KRS One has a lot to teach us in the software world. Everyone perceives the world from the prism of their personal experiences. Sarah and Timmy come from vastly different worlds. In Sarah’s mind she saw that she had properly communicated her intent, she assumed meaning to her words were built from the same pool as Timmy’s. Timmy assumed the same.

Unfortunately whilst Sarah was thinking of automating her existing process, Timmy was imagining all the bells and whistles he could build on top of her task list program.

Is there a way out of this conundrum?

The bad news is that there isn’t. The good news though is that we can mitigate it.

User stories

A user story is tool used to capture a description of a software feature from the users perspective.

A good user story outlines specific software feature while keeping all the requirement in a consistent format.

They are easy to write, read, evaluate and dare I say fun.

A user story comes in the format:

    As a ______
    I want to ______
    So that ______

User stories come with goodies that would have saved Timmy and his client from the situation they found themselves.

The goodies I speak of are the characteristics that all good user stories share. They have a convenient Acronym

    INVEST

Independent

Good user stories are independent. That is they can be developed separately from each other. By putting the requirements in form of user stories. Sarah would have been able to prioritize the user stories that had the most value to her. This action would have informed Timmy on what Sarah’s actual needs were.

Valuable

Each user story comes with a non-codable part, the So that _____ bit. That part of the story gives meaning to the requirement. Sarah would have a good platform on which to elucidate not just what she wanted built but why she wanted it built.

Estimable

Software estimation is hard to get right. You can tell when the leading material on the subject is called Software Estimation: Demystifying the Black Art.

Yet we humans can better estimate smaller components than we can larger ones. User stories enable Timmy to get a more realistic view of how the project is and Sarah to understand the effort required to build her application.

Small

User stories should be small enough to fit on an index card. A side effect of this property is that each story can be developed rather rapidly. The quicker the story is developed the faster the feedback loop between Sarah and Timmy can be closed.

Testable

Written in this format, it is fairly easy for Sarah to run the user story through the application to see if it actually meets her expectation (Technically called Acceptance test)

There we go. I am convinced next time, Timmy and Sarah will use user stories to capture their requirements. What about you?

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to give critical feedback

You get a frantic call at 2am at night from your most valuable client, their payment processing page is returning a 404. You jump quickly out of bed and login to github to see what changed in the code. You note one of your junior developers merged his local test branch to the main branch. What do you do?

The story above may seem convoluted but many product owners have nightmares of it and even more have seen a version of it play out in real life.

But today we are not going to go technical and talk about version management, no, today we talk about the developer. Yes that is the human being who just messed up.

Faced with this situation your initial reaction maybe to simply jump at this persons neck and strangle them, 18th century style. Yet doing this would be the most ineffective way to handle the situation.

In this entry we talk about techniques of giving critical feedback.

Bad news does not age well

Don’t keep the feedback to yourself no matter how bad it is. Tell the concerned individual as soon as is reasonable.

Telling them the news early allows them to see the effect of their mistake on you, the client and the organization.

The devil vs the person

Back in primary school, our disciplinarians used to cane us while saying “It’s not you am caning, its the evil inside you”.

In our anger it becomes hard to separate the person from the behaviour. No, your developer is not the devil reincarnate she just made a mistake, thats as human as it gets.

Point out the specific behaviour and have her correct that.

Get to the point

Illusion of transparency is a phenomena in which an individual overestimates the degree to which their personal mental state is not known to others.

With this information in mind, you may realize that the developer probably has no idea why you are fuming. If you fail to give specific feedback he will overtime come to the conclusion you are neurotic, a person to hide from, not listen to.

As a power tool, you may want to have the offender rephrase the problem he caused and the steps he plans on taking to prevent such an occurrence in the future.

The folly of sandwiching

The sages of old said it “If you wish to give bad news, first start with good, then the bad and finally more good”. This is really tempting to do since we want to protect the feelings of the recipient of the bad news. Yet in practise it never works as expected!

You see we humans are particularly adept at selective hearing. The developer will hear all the words but only remember the good parts. Not ideal to inspire any changes wouldn’t you agree?

Positive reinforcement

Sandwiching maybe a bad idea but that doesn’t mean you should throw appreciation out of the window! What you need to do is actively look out for changes that you want to see and reward them as they occur.

Negative actions and behaviours have a powerful emotional impact compared to positive ones. You must always be looking to compensate for this bias. Better to err on the side of compliments.

How have you dealt with mistakes in your workplace? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail