More Continuous #NoProjects questions

QA-2018-10-24-14-20.jpg

Three short questions and answers to finish off my series of left over questions about #NoProjects, #NoEstimates and the Continuous model.

Q4: How do we prioritize and organize requests on a product that are from opposite business owners? – for example legal (who wants to reduce the risk and annoy more customers) and sales (who want to increase the features and simplify life) can be arbitrated in a backlog?

You can think of this as “which is worth more apples or milk?” It is difficult to compare two things which are actually different. Yes they are both work requests – or fruit – and each can make a case but at the end of the day you can’t make everything number 1 priority.

In real life we solve this problem with money.

Walk into your local supermarket. Apples, oranges and milk are both price in the same currency, sterling for me, Francs for the person who asked this question, maybe Euro’s or Dollars for you. So if we can assign value points to each request we are half way to solving the problem.

Now sales will argue that without their request there is no real money so whatever they ask for is worth more. And legal will argue that nobody wants to go to jail so their request must be worth more. You can set your analyst to work to calculate a value but a) this will take time and b) even when they have an answer people will dispute it.

Therefore, I would estimate a value – planning poker style. With an estimates value there is no pretence of “right” or “correct”. Each party gives a position and a discussion follows. With luck the different sides converge, if they don’t then I average. Once all requests are valued you have a first cut at prioritisation.

Q5: How to evaluate the number of people you need to maintain software?

I don’t. This is a strategic decision.

Sure someone somewhere needs to decide how much capacity – often expressed as people – will be allocated to a particular activity but rather than base this on need I see this as another priority decision. If a piece of software is important to an organization then it deserves more maintenance, and if it is not important it deserves less.

You could look at the size of the backlog, or the rate of new requests and contrast this with the rate at which work gets done. This would allow you to come up with an estimate of how many people are needed to support a product. But where is the consideration of value?

Instead you say something like: “This product is a key part of our business but the days of big changes are gone. Therefore one person will be assigned to look after the software.”

If in three months more people in the business are demanding more changes to the software and you can see opportunities to extract more value – however you define value – then that decision might be revised. Maybe a second person is assigned.

Or maybe you decide that maintaining this product isn’t delivering more value so why bother? Reduce work to only that needed to keep it going.

Q6: How do you evaluate the fact that your application becomes twice as fast (or slower) when you add a new feature in a short period of time?

Answering this question requires that the team has a clearly defined idea of what value is. Does the organization value execution speed? Does the organization value up-time? Does the organization value capacity?

Hopefully some of this will have come out of the value estimation exercise in Q4, if not the analysis is just going to take a bit longer. The thing to remember is: what does the change do for the business/customers/clients? Being faster is no use in itself, but doing X faster can be valuable.

The real problem here is time. Some changes lead to improvements which can be instantly measured. But there are plenty of changes where the improvements take time to show benefit. Here you might need to rely on qualitative feedback in the short run (“Sam says it is easier to use because it is faster”). Still I would keep trying to evaluate what happens and see if you can make some quantitive assessment later.

Notice that Q4 and Q6 are closely related. If you have a clear understanding of why you are doing something (Q4) then it becomes easier to tell if you have delivered the expected value (Q6). And in trying to understand what value you have delivered then you refine your thinking about the value you might deliver with future work.

Another feedback cycle.


These questions concludes the series of question carried over from the #NoEstimates/#NoProjects workshop in Zurich – see also How should we organize our teams?Dealing with unplanned but urgent workHow do we organise with a parallel team? – if you would like me to answer your question in this blog then please just e-mail me.


The #NoProjects books Project Myopia and Continuous Digital discuss these and similar issues in depth and are both available to buy in electronic or physical form from Amazon.

CDMyopia-2018-10-24-14-20.jpg

How do we organise with a parallel team?

Question000009042425XSmall-2018-09-25-15-04.jpg

2) Offshoring – When Project meets #NoProject
In our department, we maintain products, … we deliver small features. In parallel, we have some offshore teams working in traditional project mode
The hard part comes when we need to integrate/merge our code. We have different cycles, schedules and objectives. How do we manage code handover code from offshore? – we feel we are inheriting a pack of legacy and tech debt that is added to our own stack.
No matter the handover contract agreement we set, … they don’t make the right choices for a long term maintenance vision.
They deliver the requested features, it works from a business point of view, but they deliver it in a way that can be difficult to maintain in production.
Of course, they do not maintain it, so they don’t have the experience of it.

This is the second question carried over from the #NoEstimates/#NoProjects workshop in Zurich last month.

While the question is phrased as “working with offshoring” I don’t see this as an offshore specific question. I think the question is about working with a second team, a team which does not hold maintenance responsibility and a team which perhaps doesn’t have the same quality standards as the primary team. I am sure that offshoring – and probably outsourcing – complicate matters because issues need to navigate additional boundaries.

One question in my mind is: if the second team impose such additional costs on the primary team are they actually making more work than they are doing? That is, every hour the primary team spending dealing with the liabilities of handover is an hour not delivering their own work. I’d want to look at that but lets assume the second team are worth it.

Something which worries me here: “No matter the handover contract agreement we set”. Are the second team listening? Are they making an effort to work with the primary team? Or are they ignoring the primary team?

If that is the case then it is a big problem because there is little the primary team can do to fix how the second team work. So a question comes into my mind: are those responsible for having the second team aware of the issues? Would they like to improve things?

If not then, as the second team and those employing them are not concerned, the problem may be unsolvable. The only solution the primary team have is to insulate themselves from the problems of the second team. In the short run that removes the pain for individuals but in the long run it will make things worse.

To my mind it does fall on the primary team to make a case to both groups that they would like to make things better and to work with the second team and management to make things better.

So how do we make things better?

The good news is there is lots that can be done here, there are people changes, process change and technical solutions. The bad news is, there is no silver bullet.

People changes: team members should visit each other.

I know travel budgets get cut but there is a clear case here that if team members could visit each other, understand each other, known each other then they will both work together better and be in a better position to improve things.

Process changes: ask the second team to do smaller pieces of work and deliver more often.

I don’t know the mechanism by which work reaches the second team but someone somewhere is asking them to do things. That person needs to change their requests. Of course, this means moving the second team away from the Project Model and towards a Continuous model.

Technical changes: there are a lot of options here but each of these options is gong to work best if people have visited one another and the process has been changed to lots of little.

So:

  • Have both teams practice continuous integration (if they are not already).
  • Reduce the number of branches, move towards trunk based development.
  • Have both teams practice automated unit testing (preferably TDD) and automated acceptance testing (ATDD).
  • Add static analysis tools to the build.
  • Do manual live code reviews, i.e. developers at one location talk to one at the other location while they do the code review.

None of these changes are unique to the scenario described in the question. They are common quality improvement practices. The only addition I’m making is on the code review, I want the second team to review the primary team’s code, not just the primary reviewing the second. I want this because I want teams to learn from each other.

Hopefully you can spot two themes to my suggestions.

Firstly, I’m treating both teams as equal. That is only fair but it makes sense too. If the onshore team makes the offshore team feel as if they are treated as second class then they will act as if they are second class.

Second, most of my suggestions are straight from the Continuous Delivery playbook: have both teams do lots of small high quality pieces of work and integrate them without delay.

Underlying here is a problem: the second team don’t do maintenance. They have little incentive to do better work and maybe unaware of the problems their style of working is causing.

Now having said all this I might be accused of ignoring the question. The question stated: the offshore team work in project mode. And I’ve just given suggestions which could be considered not project mode. Put it this way, I think changes need to happen one way or another. If the second team want to cling to projects then so be it, but they can still improve their quality as they do so.


If you have any questions about Continuous Digital, Project Myopia and #NoProjects please mail them over and I’ll do my best to answer them in this blog.

Receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”