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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How Project Managers and Technical Leads compliment each other

 

For new practitioners of Scrum and other agile methodologies, it is tempting to think of the scrum team as operating in some kind of Nirvana where the team works in isolation constantly producing value.

This is never the case. As far as businesses go, the scrum team is still part of the business and needs to be in alignment with the greater goals of the organisation.

To this end, most teams have some kind of project management and technical lead roles.

Understanding the difference between this roles even if you don’t have individuals exclusively assigned to them is critical for smooth relations and alignment of project goals and organisational goals.

What does a Project Manager do?

The PM acts as the interface between the team and the outside world. She has responsibilities to all stakeholders to ensure their interests are served.

To the leadership, she acts as an advocate of the team ensuring that the team’s interests are adequately represented.

While XP, an agile methodology insists that a member of the customer’s team must always be available to act as the Product Owner, this is not always possible in practice. In such cases, the PM helps explore the product owner’s conditions of satisfaction. These include the usual items—scope, schedule, budget, and quality.

In the course of the project, the PM will be expected to provide the development team with all the resources they need to get their work done. This includes physical items such as laptops whiteboards etc and enabling environment such as protecting the team from requests in the middle of the sprint. She will also be expected to provide progress reports during the sprint to the stakeholders as required.

The PM need not be technically savvy but she must have strong collaborative skills.

In a scrum team, the scrum master can take on this role.

What does a Technical Lead to?

The TL is in charge of the technical output of a single team. He is in charge of operational excellence. That is, he ensures the team produces high-quality products with high rates of productivity while meeting target costs and dates.

Typically he is a senior engineer who has the respect of the rest of the team members.

He will actively write code along with the rest of the team while simultaneously reviewing their code to ensure quality and provide pointers as to how the developers can grow. The TL will be the one tasked with leading code reviews.

Where the whole team can not attend, the TL will represent them on estimation meetings. He will be best suited to appropriately break down the client’s requirements into epics and give a rough estimate. It is, however, important that the final commitment comes from the entire development team.

The TL will typically be in charge of the architecture of the application being built. This means that in addition to leading design meetings, he should be able to provide feedback on the ramifications of individual developers commits on the rest of the system.

Conclusion

In teams where the roles are clear, development goes smoothly and the individuals in charge of the roles complement each other avoiding responsibility overlaps and vacuums.

Do you have a clear separation of the roles and duties of PMs and TLs in your own organisation? Talk to me in the comment section below or on my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Hidden Tension Between Sales and Development

Our boss once said:

 “There are people whose superpower is getting the signature on the dotted line”.

This may seem fairly obvious to other people, but to me, it was not. After all, a sale is an agreement to deliver a service (we are in the consultancy business) wouldn’t the people best placed to make the sale be the people who will do the actual delivering?

Well, I was wrong, as it turns out sales is an entirely different process from development. Sales tend to be more aggressive and charging while the development is more gentle and steady. These two forces complement each other, except when they don’t.

In this entry, I will be exploring some causes of conflict between the two teams and how they can be resolved for a stronger overall team.

Commitment to deadlines

Sales tend to be the first contact with the client. In some cases the client’s deadline is not arbitrary, something in their business environments such as trade show, shopping season or investor pitch is coming up. As the sales person, it is in your best interest to promise the client that whatever they need to be done will be done by that date.

The engineering team, on the other hand, has another belief set concerning deadlines, specifically:

    You can manage to deadline and let scope vary or manage to scope and let deadline vary.

This means that the engineering people can either work on a stripped down version of the product before the deadline or make no hard commitments but get it all done.

The problem then comes when the development team is given an engagement that just can’t be delivered within an already committed timeline.

To resolve this issue, the sales team should never give a time commitment. I mean this in the strictest sense, not a date on the calendar, not a range of days not even a ballpark figure without first consulting the development team!

Handling of issues

Let me let you in on a little secret, the dream of building a product from solid success to solid success is a beautiful one but only a fantasy. Nothing can save you from missteps in any non-trivial development.

To the sales team, problems are there to be solved. After all, we promised we will get this thing done and by God, we will!

The development team on the other hand does not like playing catch up, rather they would prefer to have a new planning session where commitments are renegotiated.

My take is that during times of great political risks, candour is a vital behaviour that maximises your chance of a positive outcome. After all, maybe, just maybe what you think is a big issue may turn out to be trivial to the client. Or it may be so important that they chose to have your work exclusively on that issue. Either way you have allowed them to exercise their proper role as custodians of priority of their product.

Unexpected “Aha”

During the normal course of development, the team may land on a great idea that would make the product 10X better. Of course, the same idea would also have the same impact on a competitor’s product.

If this is not a perfect opportunity for up-selling, I don’t know what is.

Perhaps because engineers are not typically compensated on basis of sales per quarter, they tend to see things in a different way. You see, human knowledge is never contained in one person. It grows from the relationships we create between each other and the world, and still, it is never complete.

Then to the engineers, this new knowledge seems like a gift to be given to the client team.

I believe the aim of any good engineering team should not just be to deliver to spec but also to delight the client with a beautiful product. Yet in the same vein, no development work should ever be done without explicit approval by the client. What may seem brilliant to you maybe garbage to someone else.

I will sue you

Whenever someone blurts out the words “I will sue them, you wait and see” I immediately get the impression that they have no idea how arduous the legal process actually is.

When serious issues arise in the project such as the client trying to poach the development team, the immediate reaction may be to channel all the energy used to win the client to now battering them.

Engineering culture, on the other hand, carries with it a different tone:

    Customer collaboration over contract negotiation

Yes, the client signed a contract, yes it seems like they are now trying to screw us over, no we will not aggravate the situation.

I believe that any contract is undersigned by a genuine human relationship, furthermore, this relationship is worth more than any piece of paper. Barring cases of outright hostility, all measures should be taken to preserve the relationship.

Have you ever experienced any tensions between your developers and your sales team? Talk to me in the comment section below or on my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Is your backlog still relevant?

 photo loading-652297_1280_zpsmlmpdbv8.jpg

Requirements management is a problem for all fields. It is particularly hard in software where the end product is “soft”.

We have already discussed the dangers of going overboard with scoping and how to work with user stories for more concise and agile requirements. A user story simultaneously deals with the problem of over and underspecification elegantly.

A collection of user stories is organized into a backlog. We have already seen how a backlog looks like

Mike Cohn describes a backlog simply as:

    A prioritized features list, containing short descriptions of all functionality desired in the product.

The short description he is talking about is of course a user story.

Once your initial backlog is written out, your task as the scrum master is to ensure that it remains a valuable asset to the team and not left to atrophy and finally abandoned.

In this entry we shall be looking at some of the questions that you can ask yourself to gauge the health of your backlog.

Is the backlog prioritised?

Scrum is based on the belief that you deliver most value by working first on stories that have the most value to the customer. This is achieved by ensuring all stories are prioritized.

Most teams are disciplined enough to do this the first time the backlog is written. Over time, the order is lost as more stories are added or as change happens and other stories suddenly become more important. This by itself is not a problem, the problem is that the change in priority is not reflected in the backlog.

If this continues long enough, the client then loses faith in the backlog as a tool to express what is important to them.

Is the backlog and its stories easily changeable?

Scrum has no hard specifications on how the backlog will be encoded. It does however have a preference towards a paper based system, only because this kinds are the easiest to change. If a story is no longer useful simply rip it up.

Easily changeable here will depend a lot on context. Putting up your user stories in the middle of say a product strategy document is likely to introduce a lot of drag. Who wants to go through a monstrous document just to change one sentence?

Requiring multiple authorization levels to make changes is also likely to cause the same problem. Rather than go through the hustle of asking for permission, the team member who has noted the change would rather not document it.

Finally using an unnecessarily complex tool is likely to discourage any kind of engagement with it. We all have too much to deal with in our life, taking the time to master a new tool is just not likely to get done.

At this point I must emphasize that change still happens whether your tool accommodates it or not. In the unfortunate case that it does not then it becomes obsolete.

Are the stories estimated?

Estimates are incredibly important to any story and the resulting backlog. Typically estimates are given in story points. A story point is an arbitrary measure of effort required to implement a user story.

By its nature, story point estimation forces you to triangulate story size and have heated discussions with other team members so as to come up with an agreed upon estimate. This process then helps destroy any illusions of agreement that may exist and build alignment.

Eg if there is a story such as “As a new customer I want to be able to register using either my phone number or email” and the developer gives an estimate of 8 while the client gives an estimate of 1. A discussion can ensue upon which the client can understand why this is a hard feature to build and maybe rework it or the developer can see where she misunderstood the client.

Hence, a backlog that lacks this estimates and the discussions associated with them is likely to drift away from the client’s dream both in terms of scope and delivery time.

Are the stories detailed appropriately?

A common mistake I see is teams specifying to great detail work to be done in months or even years time.

Prudent as it may seem, you are likely guessing what is going to happen. Complex systems necessarily arise out of adaptive processes. By the time the months lapse, your story will probably be invalid.

Unfortunately, even when we discover that the story that was written months ago is no longer relevant, if enough effort was put into crafting it, then we will feel guilty about abandoning all that work. Thus the work will continue to stay on the backlog with no chance of ever getting done creating a drag on everyone’s psyche.

How do you keep your backlog relevant? Talk to me in the comment section below or on my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Working with minimum specifications

 photo lost-places-1838041_1280_zpskc08gujf.jpg

In a previous entry, we took a look at the dangers of over specification.

Over specification is simply where the client not only tells the developers what needs to be done in great detail but also how and when.

We now know this is not a good strategy for building your products, but then what is?

You guessed it, minimal specification!

A minimal specification consists of the minimal amount of information needed to meaningfully specify the product.

Let us go right ahead and look at some of the tools available to us to employ this methodology.

User stories

We have already discussed at length what user stories are in invest in user stories.

In the world of software, user stories are the best thing since sliced bread, maybe even better.

A user story follows the format:

As a [persona]

I want to [do something]

so that I can [derive some value]

This very simple format conveys deep meaning. When well done, everyone understands what value they are offering and to who. This has the virtuous effect of providing a rich backdrop for conversations between developers and clients to take place.

Also, because of its concise nature, there is far less attachment. Which means that if the requirement is no longer valid, it can just be torn up and a new one written up.

Diagrams

We use words so much in our daily lives that at times we forget that they have no real existence, they only point towards concepts.

    Truth has nothing to do with words. Truth can be likened to the bright moon in the sky. Words, in this case, can be likened to a finger. The finger can point to the moon's location. However, the finger is not the moon. To look at the moon, it is necessary to gaze beyond the finger, right?
    ~ Buddhist saying

Words then create a new layer of abstraction over the requirement that is being conveyed.

To mitigate this effect, get down and dirty with the work. Have the client draw what it is they want, they can sketch out the UI views or even mind map how their ideas connect. Do everything you can to break down illusions of agreement.

At iHub, we use pidoco a wireframing tool that anyone can learn to use within minutes. This may be useful for you too if say your clients are remote.

Delegate decisions to developers

Developers routinely resolve ambiguities in requirements before it even bubbles up to the client’s consciousness.

  • Will we use InnoDB or MyISAM for our DB?
  • Will we first register the use on our newsletter and then send them a welcome email or the reverse?

In a day, such decisions may number in the hundreds. It would simply not be practical to have all of them conveyed first to the client for resolution. Yet as is the nature of our work, a few of those decisions will come to the attention of the client and they may not like the path taken by the developers. In such cases, it is important that the impact of reversing the decision be weighed down soberly.

In this way, development can proceed fast with decisions leaning on “What and Why are we building?” being made by the client and the question of “How are we going to build it?” being made by the development team.

What is your theme?

Almost everything is noise. This simple heuristic applies to everything from the candidates who have applied to a posted position to the tweets showing up on your timeline.

The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes. This law applies to requirements just as much as it applies to land ownership where 80% of the land is owned by 20% of the people or business where 80% of a company’s profits come from 20% of its customers.

In the same way, only 20% of the requirements are going to provide 80% of the value to the customer. You must then focus on this 20%.

A theme provides an easy and intuitive way to do so. They map out the landscape upon which decisions are made.

For example, if the theme of our product is “make it as easy to use as possible”, then a requirement that provides sophisticated ways of modifying the behaviour of the product is de-prioritized.

A theme then gives meaning to minimal specifications by providing them with context. This also has a nice side effect of providing a toe-hold for new team members to understand what the project is all about.

Do you use any minimal specification techniques in your own projects? Talk to me in the comment section below or on my twitter @ jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Stop killing your teams now!

 photo bonding-1985863_1280_zpsnbio5b4y.jpg

You have just met an architect, let’s call him Bill. Bill works on the design of a new skyscraper, he has the designs approved and funding awarded. He gets straight to work and builds the most beautiful building in town. Immediately after he destroys the building having met his goal of building the most beautiful structure in town.

What do you think of Bills behaviour?

Crazy?

Well, tech organisations do this kind of stunts all the time. They put in massive resources to build a team that will work on a project, once the project is done the team is disbanded and assigned to different projects. This is a massive waste of time, money and human capital.

In this entry, we are going to be discussing how this happens and why it is so costly to your organisation.

How do teams form?

A group of people does not become a team because you call them a team. In fact, Jon Katzenbach and Douglas Smith in Wisdom of teams argue that teams go through 5 distinctive stages:

  1. Working group
  2. Pseudo team
  3. Potential team
  4. Real team
  5. High performing team

Dr Bruce Tuckman in Tuckman forming storming norming performing model proposes a model by which teams form.

In my experience this process manifests in the following steps:

  1. The team members have just been assigned to start working together. Being human and thus social creatures, they spent a good amount of time studying each other personalities.
  2. The members have discovered differences in how they work. This points of difference become fertile ground for blame games. If you are lucky the members move past this stage.
  3. The team has started experiencing some success working together, points of synergy have been found and exploited. They are actually starting to like each other more and leaning on their own judgment rather than the team leads.
  4. The team is now performing at optimum. At this point, we can confidently say your team has jelled.

This is not necessarily a linear process or even a four-day process, rather an iterative process that the team members work through to get their stride.

Why should you care about having a strong team?

You may be thinking “Chencha, this is a self-evident truth, just get on with it?”. You would be wrong. Cooperation can be achieved successfully without going through the trouble of forming a team. In fact, this happens all the time. Think about your trip to work this morning, if you drove, then you had to cooperate with all the other drivers to ensure a safe trip.

Real teams matter the most where you need the sum to be greater than the parts. Companies whose primary work is innovation need teams.

In The Lean Mindset: Ask the Right Questions, the Poppendiecks assert.

    Peer pressure is far more effective than the concept of a boss and much more powerful

Therein lies the power of teams. Organisational goals tend to be abstract and far removed from the everyday lives of the team members. Millions of years of evolution, however, guarantees that each member cares a lot about the other members.

Evoking this old instinct means that the team will serve the goals of their “tribe” loyalty. When this happens, the chances of success dramatically shoot up.

So then how am I destroying teams?

For consultancy firms, projects have finite timelines. At the end of the project, the default action is to disband the team and allocate them to different projects. The other option would be to keep them on the same team but with some downtime as you wait for the next project to come. This does not reflect quite well in your financials.

Yet, I firmly believe that it is better for a jelled team to have some downtime than to incur the cost of growing a whole new jelled team just to serve a new project.

My former boss always said, “When it comes to it, I would rather be loyal to my employees than to my clients”.

Don’t you think it is about time you made the same commitment?

Talk to me on twitter @jchex or in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail