Month: May 2017

 

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

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

 

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