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?


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?


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


Where do unrealistic schedules come from?


This situation is so common, it is by now something of an industry standard. There is almost no project that I have stepped into that had an appropriate amount of time scheduled for it.

You have to wonder why after all these years we still suck at allocating enough resources to get the project done in time.

In this entry, we will be looking at some of the common factors that lead to unrealistic schedules.

External deadlines

Development happens in a context. Unless it is a hobby project, you can be sure that whatever you are working on, someone else is depending on your work output for them to do their job.

A special case would be where the bid specifies the timeline in which the product must be built. In this case, submitting a longer timeline, even if justifiable may mean losing the project.

Since the project is still of interest to the team, the team takes it on knowing full well how tight the deadline is in the process displaying a mix of childish optimism and wishful thinking.

Best case estimates

Murphy warned us:

    Whatever can go wrong, will go wrong

Scrum and other agile techniques give us robust estimation tools. But even with those, we more often than not end up with a range, say 3 – 5 months.

Unless you don’t like promotions, who wants to go to the boss with the higher estimate?

Of course, the problem with the lower estimate is that it holds the implicit assumption that everything will go right.

This is a dangerous assumption, you take it for granted that you have the best tools, language, physical environment, skills etc. When something does eventually go wrong, you find yourself with an unrealistic schedule.

Feeling up to a challenge

For reasons that are beyond me. Some developers prefer working under insane conditions. Something about an all-nighter makes them feel like heroes.

Whether inspired by cut throat work environment or personal bias, teams in these kinds of environments will consistently underestimate how long the project will take.

Even if the pressure is acceptable in the short run, the effect on the team morale and product quality are bound to suffer. Better to have a reasonable schedule and spend any extra time beefing up the quality.

Belief that developers work better under pressure

Authors of the Design Sprint state:

    Times of need can be artificially manufactured by creating deadlines. Our brain doesn’t know the difference. When you create deadlines, your brain stops procrastinating and gives you what you need.

It is easy to extrapolate this kind of thinking to the entire project.

While you do need to pace yourself, you need to be very careful of the kinds of commitments that you make. In a previous entry Estimates, Targets and Commitments. We looked at the dangers of confusing the terms.

You don’t want to make a commitment to your client based on the belief that somehow the deadline will boost productivity if you must make such a commitment, let it be internal.

Scope creep

Inevitably, new ideas will come in. Change is a core part of the software development process.

The problem arises when new changes are introduced to the project but nothing is removed from the backlog. As new features are added, eventually the entirety of the work pushed the project to an unrealistic one.

We have looked at this problem in greater detail here Managing scope creep. The TL;DR is any new change is also a chance to renegotiate commitments.

Have you faced unrealistic schedules in your own practice? How did you handle it? Talk to me in the comment section below or on my twitter @jchex


Why you should do estimation in groups

More than any other activity, estimation of size or effort it will take to build a digital product is based on individuals. Even worse, the responsibility tends to rest on the team lead.

In the midst of the flurry of proposal writing, it may feel like a waste of time to bring in the development team to work on the estimates using a practice such as planning poker. Better use a shortcut and just call the most senior developer and have them give you the estimate.

In this entry, we will be looking at why this is a bad idea and why group estimates tend to fair better than individual estimates, no matter how senior the individual doing it.

The elephant in the room

An old Chinese parable explains this concept very well. Here is the story quoted verbatim:

    Once upon a time, there lived six blind men in a village. One day the villagers told them, "Hey, there is an elephant in the village today."
    They had no idea what an elephant is. They decided, "Even though we would not be able to see it, let us go and feel it anyway." All of them went where the elephant was. Everyone of them touched the elephant.
    "Oh, no! it is like a rope," said the second man who touched the tail.
    "Oh, no! it is like a thick branch of a tree," said the third man who touched the trunk of the elephant.
    "It is like a big hand fan" said the fourth man who touched the ear of the elephant.
    "It is like a huge wall," said the fifth man who touched the belly of the elephant.
    "It is like a solid pipe," Said the sixth man who touched the tusk of the elephant.
    They began to argue about the elephant and everyone of them insisted that he was right. It looked like they were getting agitated. A wise man was passing by and he saw this. He stopped and asked them, "What is the matter?" They said, "We cannot agree to what the elephant is like." Each one of them told what he thought the elephant was like. The wise man calmly explained to them, "All of you are right. The reason every one of you is telling it differently because each one of you touched the different part of the elephant. So, actually the elephant has all those features what you all said."

    Source: [jainworld](https://www.jainworld.com/literature/story25.htm)

The idea behind this story is that we all have different viewpoints. Until the software product is complete, it is mostly a jumbled mess. Everyone in the team sees only a small part of what the work would entail.

In short, you need the whole team to see the elephant.

Human folly

As a species, we named ourselves Homo Sapiens literally translates to wise man. We couldn’t have been any more wrong in this assessment.

Human reasoning is terribly flawed. The list of our biases is so long that not even a single volume would be able to contain it all. That is not to say they have not tried, see Predictably Irrational, Misbehaving and many other such titles.

Wikipedia has a list so long that it would fit a couple of articles and that is not considering their definitions.

In short, when an individual does the estimates. They will probably seek reasons why their estimate was right rather than getting to the right estimate.

Thankfully, we also evolved a way to combat our biases, arguments. Constructive arguments around the estimate will help everyone think more carefully about their estimate and thus raise the overall quality of the final estimate.

Deep understanding

In an article Minding matter, the astronomer Adam Frank says something very interesting

    When I was a young physics student I once asked a professor: ‘What’s an electron?’ His answer stunned me. ‘An electron,’ he said, ‘is that to which we attribute the properties of the electron’

He does go on to explain the statement. For the sake of this entry, it suffices to acknowledge that the reality of what the product will be is as much what the developers will make it, as it is what we think is an objective product out there.

If this is the case, then understanding the different viewpoints can help us get a far clearer picture of what the developers intend to build and thus a better estimate of the size and effort required.

The rule of five

I like the quote

    Always remember that you are absolutely unique. Just like everyone else.
    Margaret Mead

It reminds us that at the end of the day, our estimates will likely cluster. This is not folksy wisdom. It is a statistical fact. There is a 93.75% chance that the median of a population is between the smallest and largest values in any random sample of five from that population.

Take this rule in comfort, it means that while there is a great benefit to having a group do the estimates, the group needs not be bigger than just 5 individuals.

Do you do estimation in groups in your own organisation? Talk to me in the comment section below or on my twitter @jchex


Sprint is over, now what?

You have just completed your development sprint, done the demo and the review, what next?

The easy answer is jumping into the next sprint. That is of course until the end of the year when reviews are up and you are asked to specify what you have been doing the whole year.

Showing working products is great, in fact, the agile manifesto clearly states:

Working software over comprehensive documentation

Note that they didn’t say No documentation!.

Even if they did, what seems very clear in your mind right now about how the days were used may not be so clear months from now.

Thus my recommendation is that you write a brief report for yourself. It does not need to be official. You can even just call it skipper’s log.

Below are some suggestions on what to include in the report.

Notable events

Not everything that happens in a sprint will be seen in a demo. Perhaps Rico, your new developer, mastered SQL or your team was acknowledged during all hands and other search achievements.

If you do this consistently enough, you will have your team’s story, one that perhaps you can celebrate at your end of the year party, use to review salaries or make decisions on how and what to invest in the team.

Sprint dates

Of course, the start and end dates of the sprint are obvious, how could they not be? Still, the past has a way of blending into what seems like one long day. In this cases, it helps to know that the Sprint commenced on 5th June and ended 15th June and that within this period there happened to be one public holiday or a team mate’s birthday.

This information may give you insights in future planning sessions, specifically how blocked of days for development play out in practice.

Team velocity

Thankfully, most project management tools aimed at software teams will automatically compute this for you. If yours doesn’t. It may be worth it to do the computation yourself.

Velocity = Total story points done in this sprint
Average Velocity = Total story points complete/Total sprints done

You can then chose to plot this information in a burndown chart.

You may want to consider printing out the burndown chart and hanging it on your team wall if you have one.

Retrospective actionable

Your retrospective will likely come up with good practices for the team to implement in the future. While this information is already captured in the retrospective document, I consider this information so important that a little bit of redundancy is allowed. In short, have it in your skipper’s log as well.

This will allow you to quickly reflect on what you thought at the time was important to improve on and thus see how things have evolved since then.

Sprint summary

This would be a subjective account of how the sprint was. With all the talk about objectivity in our industry, telling you to record your subjective experience sounds rather counter productive.

Still, I have found that AHA moments can come from reflecting on your state of mind in action.

What do you, as an individual do at the end of the sprint? Talk to me in the comment section below or on my twitter @jchex


Successfully working with a remote product owner


In today’s connected world, your client is rarely next door if even they are on the same continent as you!

In fact, with the rapid rise of the gig economy, the scrum master, development team and product owner may all be on different continents.

For the team, this is obviously a challenge. After all, you need your product owner to prioritise and guide development activities.

In this entry, we are going to be looking at some of the things that the PO can do to ensure that they are successful in their role even whilst being remote.

Out of sight, out of mind

Humans have an affinity to activities that physically engage them. Working on a project where the only contact with the other person is through screens is not natural, at least not from the perspective of our roots in the Savannah.

It is thus very easy for the PO to invest their energies in more immediate teams or even just their local friends at the pub.

To be successful, the remote PO must be mindful of this effect and constantly recommit to being engaged in the project.

Trust is the key

Rapport and trust are the drivers of all successful teams. Without it, the team would spend too much time bickering over trivialities.

As the Arbinger Institute put in Leadership and self-deception

No matter what we are doing on the outside people primarily respond to what we feel about them on the inside

It is easy to fall into the trap of thinking of your remote team as somehow less superior or skilled because well, they are far.

Even at a distance, this sentiment will be registered.

It is thus important for the PO to ensure not only that his attitude is one of camaraderie but to engage with the team as much possible even in non-core work activities. Perhaps check into slack’s #random channel every once in a while.

Let’s quickly jump into a call

I normally don’t like long business calls. They are uncomfortable to sit through, I have problems hearing what is being said and God help us if the connection is poor.

Still, compromises must be made. The bandwidth provided by even a shaky call is far more than anything that email can provide.

The PO thus must commit to remain available to the team. Sometimes this may mean working after or before their usual work hours. This sucks, the only saving grace I would say is that sacrifice deepens commitment.

I will get back to you

Ok, so calls are not always an option. In this instances, it’s useful for the PO to at least be responsive on email.

Yes, I know our inboxes are flooded, but the commitment to the project means that the PO gives priority to his development team queries.

This should also be done within a reasonable time frame. A response received three days later is a guaranteed flow killer!

Have you ever worked with a remote product owner in the past? Talk to me in the comment section below or on my twitter @jchex


Why we don’t count incomplete stories


It is the end of the sprint. This has been a fairly good one, we had set to complete several user stories among them the following:

  • As a customer, I want to be able to manage my notification frequency
  • As a merchant, I want to be able to quickly see what time my customers like receiving information from me
  • As a merchant, I want to be able to alert customers of new product offerings

To each of this stories, you had given an estimate of 13 story points. You have managed to completely deliver on the first and last item. For the second one thou, you are not quite done. While the API is ready, the feature is not all wired up yet. You feel like you are about 90% done. But the sprint is over so some work has to roll over to the next sprint. Do you assign it’s 13 points to this sprint or the next? Or maybe you assign 90% of the points to this sprint and 10% to the next?

This is a scenario that often gets played out in development shops everywhere. My simple answer would be, don’t assign any points to this sprint. In fact, don’t assign points until the story is fully complete.

Here is why.

The incomplete space is virtually infinite

It is easy to understand when I say the feature is complete or not complete. The space in between can mean almost anything. Here are some examples:

  • Can mean not coded but tests written
  • Code has been written but no tests
  • Currently being refactored

Thus my opinion of 90% done and yours may be dramatically different. I may mean that am yet to push changes to the server. You may be an advocate of measure twice, cut once and thus are now just done with the design and starting out with the code.

It’s much easier to just take a binary stance.

Feedback times increase

A key principle of Kanban is to limit work in progress

In software, this matters because work in progress increases feedback time.

Cycle time = Weeks / Feature

Let us combine that with Little’s Law

Average wait time = No of features in progress / features completed per week 
Average wait time =  No of features in progress * Cycle time

From the above, we can see that each incomplete feature increases wait time by a cycle.

With increasing WIP we get increased time to feedback. This is a vicious cycle. Eventually, you kill off all benefits that would have been accrued from the faster learning granted by agile.

Trust is lost

Agile runs on trust. The development team trusts the client to communicate the problem, give truthful deadlines and appropriate priorities. The client expects the developers to give them estimates that are correct and to deliver the best possible work that they can.

In fact listed in Values of extreme programming is the virtue of courage:

    Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes when ever they happen.

Immediately the development team discovers that the feature can not be completed in this sprint, it behoves them to start a conversation with the client. Perhaps the story can be broken down and part of it moved back to the backlog? Or with this new information, the client can decide to simply de-prioritize the entire feature from the sprint.

Either way, by involving the client in the discussion, a much more holistic solution can be found.

How do you manage incomplete stories in your own agency? Talk to me in the comment section below or on my twitter @jchex


Selecting a new tool? Think about this first

Software tools are some of the most expensive products in the market. For example, to give your designers access to the Adobe suite, you are looking at $80/Month. Of course, the designed product needs to be coded, so again we are looking at $400/year for Intellij. And this are just the basics!

Yet this is not even the important metric. Each tool comes with its own learning curve, this means lost hours that could have been used productively.

In this entry, we shall be looking at the various questions that you need to ask yourself before adopting a tool.

Who is the vendor?

This is a very important question. We had previously explored it in Selecting the best vendor for your product.

Everything feels the devastating effects of entropy. This means that the shiny new tool that you just bought will one day require support from the vendor.

This can either be in the form of a scheduled regular update or a support call. Either way, you want to make sure there is someone to help you on the other side of the line.

What is the gain?

In the classical book Filters against folly, Garret makes the following statement:

    The numerate temperament is one that habitually looks for approximate dimensions, ratios, proportions, and rates of change in trying to grasp what is going on in the wold. Given effective education–a rare commodity, of course–a numerate orientation is probably within the reach of most people.

Aditya gives an example from the person we all know and love, Elon Musk. Simple Math Is The Reason Why Elon Musk Does Things That Seem Impossible To Others

Clearly, the ability to articulate the benefits numerically is important. Software vendors will typically promise you the world, unfortunately, the world is just not up for sale. You need to be able to at the very least do some back of the napkin calculations to assert if the tool will give you meaningful gains.

E.g if I currently use my personally hosted git on say AWS. I then come across a salesman for say Github, who promises that by hosting my application on their platform, I will gain 5X productivity. The fist thing to ask is how are they measuring productivity? Is it time to code? Time to checkout? Ease of finding the code? Then I would give a measure to how important this is to me. Comparing this metric and the expected gains, I can see if truly the gain is 5X and if it’s not, is it still enough to be worth adopting it?

How long has the tool been in the market?

Change is inevitable. In the world of software, this means that the tools you just bought are amenable to change. The question then is, in what direction is it likely to change?

The startup world has a term for it Pivot. This is where a startup shifts strategy in its effort to find its business model.

Obviously, the ability to pivot is of great value to the startup, to your business, however, this may not be so good. The initial strategy may have focused on speed which aligned with your own strategy, they now maybe focused on user experience and in the process trading of the speed.

How well does the tool fit within your existing systems?

Each organisation has with time built its own ecosystem of tools. More often that not, the business has figured out how to make its various components from accounting to planning tools work.

Any new tool then needs to somehow fit into this ecosystem. For example, if your entire business is made up of remote workers. Then acquiring a system that only works when all the devices are connected to the same network is going to be a disaster.

You may also want to consider how the new tool constrains future tool adoption. Tools typically provide multiple interfaces to interact with. If the new tool say exposes only JSON interface for integration, then you will have a problem adopting a SAML-based tool.

How much training is needed?

Some tools are necessarily complex and need training time. This by itself is not a bad thing. Unless of course there are no trainers or even worse, a community of practitioners for your staff to interact with.

Popular tools have a leg up in this cases, this is because there is usually a community to answer any esoteric questions that you may have. Unfortunately, the popularity also means that the tool gives you less of a leverage over your competitors.

Less popular tools may have a defining edge that takes you to the top, but then getting access to trainers maybe problematic and expensive. Not to mention, you may not be able to get help once you learn on edge cases that are just not documented in the manual.

What is your process for adopting new tools? Talk to me on the comment section below or on my twitter @jchex


Defining a criteria for product owners


Scrum has a role called Product Owner. This is basically the individual from the client team who represents them. She is the custodian of the vision and in charge of prioritising the backlog.

When introducing this role to the client, I see a lot of teams just blurt out this definition and ask the client to nominate who the PO (Product Owner) will be.

With no further guidance, the client team usually ends up selecting the biggest boss. This almost always does not end well.

In this entry, we will be looking at the criteria for selecting a PO for the project.

Are they committed?

There is a world of difference between complying and commitment.

Asked in the middle of a meeting by my boss:

    So Chencha will you be able to work on this role that has been suggested?

What do you think am likely to reply with?

    Yes I can.

No one wants to seem like they are not being a team player.

Yet when things get tough as they always do, compliance will just not cut it. The PO needs to strongly identify with the vision, to understand not just what is being built but why.

If they lack commitment, eventually the lack of energy will show and drag the team morale down. After all who wants to work on a project where the client cancelled the demo meeting the last three times.

Do they understand their business?

If you ask a child what his dad who is an Engineer does, his response at 5 years of age will be Engineer. This will be the same answer at 10 years and 20 years. Yet each time he means something different, he gains a better understanding of what his dad does as he grows.

The truth is even with strong commitment, if the PO is not competent, then she is not worth much to the scrum team.

The PO needs deep knowledge and experience from their field. The kind of knowledge that comes from being deeply immersed in their domain for years. This experience can then be translated to insights that the scrum team can use in building their products.

Can they communicate?

Good communication is typically understood as articulating your views.

Acting as the client, the PO may then interpret her role as one of issuing commands

A good PO must be able to balance advocating her views and inquiring on the views of the scrum team. She Should be able to communicate assumptions their business is making and how they inform the decisions that she is making now.

In case of differences between the client and development team, she is best positioned to mediate and bring the teams to a common ground.

Can they decide?

A good decision maker is both competent and courageous.

The PO must be able to understand options on a more granular level, as the sum of their characteristics rather than as distinct and indivisible items. For example, if there is a requirement to build in multithreading into the system, the PO should be able to see it not only as a faster vs slower application but also how this impacts their various users, the benchmark their competitors are using and resources available to the system once in production.

Decisions that don’t pan out well can be very painful experiences. Yet decisions must be made, the PO then must be courageous enough to take on the decisions without unnecessary delay.

What criteria do you use to select POs for your teams? Talk to me in the comment section below or on my twitter @ jchex