Agile

Why I don’t like pre-work (planning, designing, budgetting)

Continuous, Requirements / / /

You might have noticed in my writing that I have a tendency to rubbish the “Before you do Z you must do Y” type argument. Pre-work. Work you should do before you do the actual work. Planning, designing, budgeting, that sort of thing.

Why am I such a naysayer?

Partly this comes from a feeling that given any challenge it is always possible to say “You should have done something before now” – “You missed a step” – “If you had done what you were supposed to do you wouldn’t have this problem.” Most problems would be solve already, or would never have occurred, if someone had done the necessary pre-work.

There is always something you should have done sooner but, without a time machine, that isn’t very useful advice. Follow this line of reasoning and before you know it there is a great big process of steps to be done. Most people don’t have the discipline, or training, to follow such processes and mistakes get made. The bigger the process you have the more likely it is to go wrong.

However, quite often, the thing you should have done can still be done. Maybe you didn’t take time to ask customers what they actually wanted before you started building but you could still go and ask. Sure it might mean you have to undo something (worst case: throw it away) but at least you stop making the wrong thing bigger. Doing things out of order may well make for more work, and more cost, but it is still better than not doing it at all.

Some of my dislike simply comes from my preference. Like so many other people, I like to get on and do something: why sit around talking about something when we should be doing! I’m not alone in that. While I might be wrong to rush to action it is also wrong to spend so long talking that you never do it, “paralysis by analysis.” Add to that, when someone is motivated to do something its good to get on and do something, build on the motivation. Saying “Hold on, before you …” may mean the moment is missed, the enthusiasm and motivation is lost.

So, although there is a risk in charging in there is also a risk in not acting.

Of all the things that you might do to make work easier once you start “properly” some will be essential and some till not. Some pre-work just seems like a good idea. One way to determine what is essential is to get on with the work and do the essentially when get to them. Just-in-time.

For example, before you begin a piece of work, it is a really good idea to talk about the acceptance criteria – “what does success look like?” If you pick up a piece of work and find that there are no acceptance criteria you could say “Sorry, I can’t do this, someone needs to set criteria and then I’ll do it” or you could go and find the right person and have the conversation there and then. When some essential pre-work is missing it becomes job number 1 to do when you do do the work.

Finally, another reason I dislike pre-work is the way it interacts with money.

There are those who consider pre-work unnecessary and will not allocate money to do it (“Software design costs time and money, just code.”) If instead of seeing pre-work as distinct from simply doing the work then it is all part of the same thing: rather than allocate a few hours for design weeks before you code simply do the design for the first few hours of the work. That way, making the pre-work into a just-in-time activity you remove the possibility the work is cancelled or that it changes.

My other gripe with money is the way, particularly in a project setting, pre-work is accounted for differently. You see this in project organizations where nobody is allowed to do anything practical until the budget (and a budget code) is created for the work. But the work that happens before then seems to be done for free: there is an unlimited budget for planning work which might be done.

Again, rather than see the pre-work – planning, budgeting, designing, etc. – as something distinct that happens before the work itself just make it part of the work, and preferably do it first.

Ultimately, I’m not out to bad pre-work, I can see that it is valuable and I can see that done in advance it can add more value. Its just that you can’t guarantee it is done, if we build a system that doesn’t depend on pre-work being done first, then the system is more robust.

Why I don’t like pre-work (planning, designing, budgetting) Read More »

Nuke the Backlog in Digital Agencies

Agile / /

When I make my “Nuke the backlog” argument (use goals not backlogs to drive work, throw away the long term backlog and generate the work you need to do from the goals) there will often be someone in the room who says:

“We are a digital agency, our clients come to us with a list of features, a backlog, and ask us to deliver it. We can’t throw away the backlog.”

This is a fair point, and if you are an agency for hire, this has long been the model: clients list features they want, agencies quote for each item, the cheapest wins the work and everyone is happy.

The idea that you can write down everything you want is baked into our procurement processes. It means that before you can ask the question “how long will it take?” or “how much will it cost?” you have to spend time and money saying what “it” is.

Although if we are being honest, it is only after signing the contract that things go horribly wrong. The client never really knew what they wanted, the requirements gathering process didn’t satisfy them, when they see something (a bit of solution or an invoice) they get new insights and “change their mind.”

If you haven’t read my tongue-in-cheek “Dear customer” letter now would be a good time to do so.

I am not disputing that this “feature factory for hire” model is the way a lot, most, of the industry works. Nor am I disputing that for your company right now, or even for yourself, to move away from this model is a big ask.

The first problem is the race to the bottom: if you are competing on price then there is always someone, somewhere, that will offer to do it for less. And if you cut yourself to the bone to win the work you are making it less likely there will be a successful outcome. Economists call this “winner’s curse.”

Unfortunately, as an industry we have trained our clients to believe there is an unavoidable gap between awarding the contract and seeing the outcome. Which means, by the time the client realises something is wrong, they have spent so much money it is a career ending decision to admit it is wrong.

So, what is the solution?

We need to change the rules of the game. Are you a tailor or an image consultant?

Is your digital agency competing on price? Are you just making suits?

If you want a better way you need to rethink how you sell, you need to work with objectives and outcomes. Throw the requirements document away and nuke the backlog. Think holistically, consider this an all in process. You aren’t just building the features a client wants, you are helping them towards their business goals.

Now there are two problems here. That is a more difficult sell, you need to get involved sooner and few people really know how to do it. (Everyone claims they can but they usually end up selling features.)

Second, not every client is ready for it. Client’s have been conditioned to think technical types want big long documents – and so have their procurement people. So you have to say No to some clients. That is scary, especially for a small agency that lives one deal at a time.

The good news is: there are clients out there who are open to working in new ways. Offer up something different. Most agencies don’t, most agencies are racing to the bottom so you have less competition.

Otherwise, you will be forever competing on price and racing to the bottom.

Nuke the Backlog in Digital Agencies Read More »

Are you a tailor or an image consultant?

Agile, Business / /

The best tailor

You go to the best tailor in town, and you say: ‘I’m getting married, my betrothed is beautiful, make me look one million dollars, I don’t care what it costs.’

The tailor measures you very carefully then stands back. He rubs his chin, he is clearly troubled by something. ‘Tell me’ you say, ‘Please tell me.’

‘Sir’, he replies, ‘I don’t think it is my place to say’

‘Tell me’ you beg, ‘I must look fantastic on the day’

‘Well Sir, …’ he talks slowly and cautiously, ‘… if you really want to look $1,000,000 can I suggest you lose 5kg?’

What do you say?

Is the tailor a master of clothes who just makes beautiful clothes?
Or are they, because of their long experience making people look beautiful in clothes, an image consultant who can help you look beautiful?

This is the dilemma many a consultant finds themselves in. More importantly it is the dilemma that I find again and again in corporate IT and digital agencies: Is an agency a service which is expected to build what is requested without answering back?

Or, Is an agency a group of experts who know the best way to maximise benefit and gain value from digital investment?

Is your agency a tailor who is expected to produce something brilliant no matter what the request is?

Or are they people who, because they work with technology every day, have experience and knowledge to help their customers maximise their benefit? (Even if that means the original request should be reconsidered.)

I distinctly remember a senior IT manager at an American bank telling me that his department was definitely a service department: it was not his job to answer back to business requests. His job, and that of his team, was to build what was asked for. The implication being that even if his people knew the (internal) client was approaching the issue from the wrong point, and even asking for the wrong system, then his people should not correct them. They should just build what was asked for.

Perhaps this dilemma is most acutely felt by Business Analysts who are sometimes expected to just write down the orders that someone wants to give to IT. Some brave Business Analysts will challenge, and lead their customers to ask different questions.

The original metaphor came from Benjamin Mitchell – who didn’t recall it last time I asked him. As I recall it was part of a very deep conversation we had in Cornwall back in 2011 (the same conversation led to the “Abandon hope all ye who enter Agile” blog post.)

For me the story is about missed opportunities, about frustration and about what you might do to change the position. For Benjamin it is about asking “Do we all expect the same thing? – If you think they consider you a service group how can you confirm this?”

Either way the core problem is about a mismatch of expectations. Your IT department might be a service department, that approach could work and it is how many big corporations operate. For a digital agency the question is more important: do they exist to do what the customer ask? “2kg of WordPress, certainly, sure” Or do they exist to advise the client on to live digitally? – and perhaps build a WordPress site.

I’ve used this story many times since 2011, it comes up again and again. If anything I use it more today than in 2011 or 2014 when I first shared it online.

What has changed since then is not so much the story but the world around it. Digital technology dominates business and requests to “build these 10 features” make less and less sense every year. The best ways of organising and managing work is to work with a tailor who knows what they are talking about and help both sides find the best solutions to meet a goal. Both sides need to respect each other.

I originally published this story in 2014. Nearly 10 years on it is even more relevant than when I first published it.

Are you a tailor or an image consultant? Read More »

3 ideas until you nuke the backlog

Agile / /
  1. Lead with goals
  2. Write an “use by” expiry date on new backlog items
  3. Keep an ideas list, maybe

When I deliver “Honey, I shrunk the backlog” and when I tell people “Nuke the backlog” there are a few questions and talking points which come up again and again. So, if you read my last post and have been asking yourself how you live with a backlog you want to nuke… read on…

Lead with goals

“My boss won’t stand for me deleting the backlog” I empathise. I know it happens.

At the same time I wonder: does your boss really care? – I’m sure some of them do, I see many Product Owners who are really “Backlog administrators.” Their boss is certainly leaning over their shoulder checking on what being done. If this is your case then your boss is the real Product Owner, sorry to say this but you are really a goffer.

In this case you want to educate your boss, you want to start having discussions about a better way. This is going to be a long and hard path. There is no sure fire advice I could give you here, except to suggest you give me a call.

Assuming your boss give you some leeway then go and start a conversation about your bigger goals. Beyond “delivering backlog items” what are the goals your goals? More specifically, what are driving at for the next 10 weeks?

Start to have a conversation about goals bigger than backlog items. Build a routine, a super cycle, around your sprints with the boss and team to discuss bigger goals. Then, during the cycle drive with the goals. If there is a suitable backlog items that contributes towards the goal(s) then do it. If not, write it out and do it immediately.

Either way, whether you are doing this to work around a boss or as a mechanism to tradition to a backlog-less world the same idea applies: create a super cycle, set goals every 10 weeks (approximately) and then drive through the goals rather than the backlog.

Drive with the goals and put the backlog in the back seat, it is secondary. The aim is to avoid nuking the backlog by letting it fad into irrelevance.

Write an “use by” expiry date on new backlog items

For any item you do add to the backlog make sure it has an expiry date. That is: a date after which it will be removed from the backlog. Giving every backlog item a life expectancy won’t help you today, but it does mean that in the months ahead some items will “self delete” from the backlog.

After a while you might want to visit older items in the backlog and (if you can’t delete them immediately) assign them “use by” date.

I am sure a few people will say “O this need will live for ever.” In which case you can put a long date on it, say 10 years. But that also tells you: there is no urgency. You can do this item anytime in the next 10 years and add value, it can wait.

Better still, write a “best before” and a “use by” date on the item

The best before date will tell you the date by which an item should be done to maximise benefit. After that date the benefit will decline, it might still be worth doing but it is not as beneficial. The “use by” date now tells you the date on which it has no benefit.

Now when you are reviewing the backlog you can see which items can be pushed back and which items need doing sooner. This is a little bit of a double edged sword for the requester, if they say “If I don’t have it in 2 months it will start loosing value” then it is more urgent, but also if it doesn’t make the cut soon then it can be removed soon.

Keep an ideas list

When you have a great idea, or when someone suggests something you could do add it to an ideas list – not the backlog. In fact, don’t show the list to people, don’t promise anything to anyone. This is your list for things you don’t trust to your memory.

Some people operate their backlog like this already but many people assume that if an item is in the backlog it will be done one day. Others measure the backlog and forecast dates. But ideas may never be done so they complicate this thinking.

Personally I like to think that great ideas will either get remembered or rediscovered. That said, I also write down lots of ideas. However, I frequently throw my ideas lists away. So if at 11pm I think of something I’ll write it down, three weeks later if it is just moving from one list to another I’ll cross it off. I rewrite my “todo” and “priorities” lists regularly.

If it helps then just keep ideas some other place. One team I worked with created a “Sprint 99” – a sprint so far off in the future it was never going to done. They parked all the good ideas there so they had them for reference and if they needed them but there was no suggestion they would ever be done.

You will also want to think carefully about what you tell people when they say “I’ve got a great idea, can you add it to the backlog?” You want to be honest, but you don’t want to create a long conversation. So you might want to say something like “Great, thanks, I’ll add it to our ideas list, if it becomes a block please come back to me and we can talk some more.” In other words, put the ball back in their court to show the value of the idea.

I’ll admit I’m nervous about this suggestion. Part of me things it will inevitably become to be seen as a backlog. I think important things will get remembered, and things which aren’t important can just as easily get lost when put among 1000 other things. Still, I know some people will take comfort in this idea so give it a try and let me know.

This piece was originally published on Medium.

3 ideas until you nuke the backlog Read More »

Nuke your backlog?

Agile / / / , ,

When I deliver “Honey, I shrunk the backlog” and when I tell people “Nuke the backlog” there are a few questions and talking points which come up again and again. So, if you read my last post and have been asking yourself how you live with a backlog you want to nuke… read on…

Lead with goals

“My boss won’t stand for me deleting the backlog” I empathise. I know it happens.

At the same time I wonder: does your boss really care? – I’m sure some of them do, I see many Product Owners who are really “Backlog administrators.” Their boss is certainly leaning over their shoulder checking on what being done. If this is your case then your boss is the real Product Owner, sorry to say this but you are really a goffer.

In this case you want to educate your boss, you want to start having discussions about a better way. This is going to be a long and hard path. There is no sure fire advice I could give you here, except to suggest you give me a call.

Assuming your boss give you some leeway then go and start a conversation about your bigger goals. Beyond “delivering backlog items” what are the goals your goals? More specifically, what are driving at for the next 10 weeks?

Start to have a conversation about goals bigger than backlog items. Build a routine, a super cycle, around your sprints with the boss and team to discuss bigger goals. Then, during the cycle drive with the goals. If there is a suitable backlog items that contributes towards the goal(s) then do it. If not, write it out and do it immediately.

Either way, whether you are doing this to work around a boss or as a mechanism to tradition to a backlog-less world the same idea applies: create a super cycle, set goals every 10 weeks (approximately) and then drive through the goals rather than the backlog.

Drive with the goals and put the backlog in the back seat, it is secondary. The aim is to avoid nuking the backlog by letting it fad into irrelevance.

Write an “use by” expiry date on new backlog items.

For any item you do add to the backlog make sure it has an expiry date. That is: a date after which it will be removed from the backlog. Giving every backlog item a life expectancy won’t help you today, but it does mean that in the months ahead some items will “self delete” from the backlog.

After a while you might want to visit older items in the backlog and (if you can’t delete them immediately) assign them “use by” date.

I am sure a few people will say “O this need will live for ever.” In which case you can put a long date on it, say 10 years. But that also tells you: there is no urgency. You can do this item anytime in the next 10 years and add value, it can wait.

Better still, write a “best before” and a “use by” date on the item.

The best before date will tell you the date by which an item should be done to maximise benefit. After that date the benefit will decline, it might still be worth doing but it is not as beneficial. The “use by” date now tells you the date on which it has no benefit.

Now when you are reviewing the backlog you can see which items can be pushed back and which items need doing sooner. This is a little bit of a double edged sword for the requester, if they say “If I don’t have it in 2 months it will start loosing value” then it is more urgent, but also if it doesn’t make the cut soon then it can be removed soon.

Keep an ideas list

When you have a great idea, or when someone suggests something you could do add it to an ideas list – not the backlog. In fact, don’t show the list to people, don’t promise anything to anyone. This is your list for things you don’t trust to your memory.

Some people operate their backlog like this already but many people assume that if an item is in the backlog it will be done one day. Others measure the backlog and forecast dates. But ideas may never be done so they complicate this thinking.

Personally I like to think that great ideas will either get remembered or rediscovered. That said, I also write down lots of ideas. However, I frequently throw my ideas lists away. So if at 11pm I think of something I’ll write it down, three weeks later if it is just moving from one list to another I’ll cross it off. I rewrite my “todo” and “priorities” lists regularly.

If it helps then just keep ideas some other place. One team I worked with created a “Sprint 99” – a sprint so far off in the future it was never going to done. They parked all the good ideas there so they had them for reference and if they needed them but there was no suggestion they would ever be done.

You will also want to think carefully about what you tell people when they say “I’ve got a great idea, can you add it to the backlog?” You want to be honest, but you don’t want to create a long conversation. So you might want to say something like “Great, thanks, I’ll add it to our ideas list, if it becomes a block please come back to me and we can talk some more.” In other words, put the ball back in their court to show the value of the idea.

I’ll admit I’m nervous about this suggestion. Part of me things it will inevitably become to be seen as a backlog. I think important things will get remembered, and things which aren’t important can just as easily get lost when put among 1000 other things. Still, I know some people will take comfort in this idea so give it a try and let me know.

This pieces was first published on Medium, Nuke the backlog.

Nuke your backlog? Read More »

Comments, off, sorry

Agile / /

I’ve always enjoyed the comments people leave on this blog – even when people disagree.

Unfortunately, for the last few months the vast majority of comments I am receiving are spam – people trying to add links to their own websites and such. The same comments are made again and again, sometimes a dozen in a day.

So, with a heavy heart I’ve switched comments off for now. I’m happy to receive your comments, please e-mail me allan AT allankelly.net.

Of course, as I’m experimenting with Medium at the moment most of my content is appearing there and you can comment there. So please follow me over there.

Comments, off, sorry Read More »

Pull, don’t push: Why you should let your teams set their own OKRs

Agile / / / ,

There is a divide in the way Objectives and Key Results (OKRs) are practiced. A big divide, a divide between the way some of the original authors describe OKRs and the way successful agile teams implement them. If you haven’t spotted it yet it might explain some of your problems, if you have spotted it you might be feeling guilty.

The first school of thought believes OKRs should be set by a central figure. Be it the CEO, division leadership or central planning department, the OKRs are set and then cascaded, waterfall style, out to departments and teams.

Some go as far as to say “the key results of one level are the objectives of the lower levels.” So a team receiving an OKR from on high take peels of the key results, promotes each to Objective status. Next they add some new key results to each objective and hand the newly formed OKR to a subordinate team. The game of pass the parcel stops when OKRs reach the lowest tier and there is no-one to subordinate.

The second school of thought, the one this author aligns with, notes that cascading OKRs in this fashion goes again agile principle: “The best architectures, requirements, and designs
emerge from self-organizing teams.” In fact, this approach might also reduce motivation and entrench the “business v. engineer” divide.

Even more worryingly, cascading OKRs down could reduces business agility, and eschew the ability to use feedback as a source of competitive advantage and feedback.

Cascading OKRs

Cascading OKRs are handed down from above

We can imagine an organization as a network with nodes and connecting edges. In the cascading model information is passed from the edge nodes to the centre. The centre may also be privy to privileged information not known to the edge teams. Once the information has been collected the centre can issue communicate OKRs back out to the nodes.

One of the arguments given for this approach is that central planning allows co-ordination and alignment because the centre is privy to the maximum amount of information.

A company using this model is making a number of implicit assumptions and polices:

  1. Staff at the centre have both the skills to collect and assimilate information.
  2. That information is received, decisions made and plans issued back in a timely fashion. Cost of delay is negligible.

However, in a more volatile environment each of these assumptions falls. Rapidly changing information may only be known to the node simply because the time it takes to codify the information — write it down or give a presentation — may mean the information is out of date before it is communicated. In fact the nodes may not even know they know something that should be communicated. Much knowledge is tacit knowledge and is difficult to capture, codify and communicate. Consequently it is excluded from formal decision making processes.

The loss of local knowledge represents a loss of business agility as it restricts team’s ability to act on changing circumstances. Inevitably there will be delays both gathering information and issuing out OKRs. As an organization scales these delays will only grow as more information must be gathered, interpreted and decisions transmitted out. Connecting the dots becomes more difficult when there are more dots, and exponentially more connection, to connect.

This approach devalues local knowledge, including capacity and ambition. Teams which have no say in their own OKRs lack the ability to say “Too much”, they goals are set based upon what other people think — or want to think — they are capable of.

Similarly, the idea of ambition, present in much OKR thinking, moves from being “I want to strive for something difficult” to “I want you to try doing this difficult thing.” Let me suggest, people are more motivated by difficult goals that they have set themselves more than difficult goals which are given to them.

Finally, the teams receiving the centrally planned OKRs are likely to experience some degree of disempowerment. Rather than being included and trusted in the decision making process team members are reduced to mere executers. Teams members may experience goal displacement and satisficing. Hence, this is unlikely to lead either to high performing teams or consciences, responsible employees.

Any failure in this mode can be attributed to the planners who failed to anticipate the response of employees, customers or competitors. Of course this means that the planners need more information, but then, any self-respecting planner will have factored their own lack of information into the plan.

Distributed OKRs

Distributed OKR setting

In the alternative model, distributed OKRs, teams to set their own OKRs and feed these into any central node and to leaders. This allows teams to factor in local knowledge, explicit and tacit, set OKRs in a timely fashion and determine their own capacity and ambitions.

One example of using local knowledge is how teams managing their own work load, for example balancing business as usual (or DevOps) work with new product development. As technology has become more common fewer teams are able to focus purely on new product development and leave others to maintain existing systems.

Now those who advocate cascading OKRs will say: “How can teams be co-ordinated and aligned if they do not have a common planning node?” But having a common planner is not the only way of achieving alignment.

In this model teams have a duty to co-ordinate with both teams they supply and teams which supply them. For example, a team building a digital dashboard would need to work with teams responsible for incoming data feeds and those administering the display systems. Consequently, teams do no need to information from every node in the organization — as a central planning group would — but rather only those nodes which they expect to interact with.

This responsibility extends further, beyond peer teams. Teams need to ensure that their OKRs align with other stakeholders in the organization, specifically senior managers. In the same way that teams will show draft OKRs to peer teams they should show managers what they plan to work on, and they should be open to feedback. That does not mean a manager can dictate an OKR to a team but it does mean they can ask, “You prioritising the French market in this OKRs, our company strategy is to prioritising Australia. Is there a reason?”

A common planner is but one means of co-ordination, there are other mechanisms. Allowing teams the freedom to set OKRs means trusting them to gather and interpret all relevant information. When teams create OKRs which do not align it is an opportunity not a failure.

When two teams have OKRs which contradict, or when team OKRs do not align with executive expectations there is a conversation to be had. Did one side know something the other did not? Was a communication misinterpreted? Maybe communication failed?

Viewed like this OKRs are a strategy debugger. Alignment is not mandated but rather emerged over time. In effect alignment is achieved through continual improvement.

These factors — local knowledge and decision making, direct interaction with a limited number of other nodes and continual improvement — are the basis for local agility.

Pull don’t push

Those of you versed in the benefits of pull systems over push systems might like toes this argument in pull-push terms. In the top down approach each manager, node, pushes OKRs to the nodes below them. As with push manufacturing the receivers have little say in what comes their way, they do their bit and push to the next in lucky recipient in the chain.

In the distributed models teams pull their OKRs from their stakeholders. Teams ask stakeholders what they want from the team and they agree only enough OKRs to do in the coming cycle.

This may well mean that some stakeholders don’t get what they wanted. Teams only have so much capacity and the more OKRs they accept the fewer they will achieve. Saying No is a strategic necessity, it is also an opportunity to explore different options.

Pull, don’t push: Why you should let your teams set their own OKRs Read More »

Nuke the bug list when you nuke the backlog

Agile / / /

“Nuke the backlog” originally a quick comment in a podcast about OKRs it summed up what I had come to believe. “Honey, I shrunk the backlog” presentation expands on that idea and outlines why I think teams should replace backlogs with just-in-time story generators – powered by OKRs or some other goal setting technique.

So I shouldn’t have been surprised when this question arrived in my mailbox:

“Throw away the backlog, is that for old bug tickets too? How does that work?”

The short answer is “Yes, throw away the bug list too.”

What do you mean, “Bug” ?

Basically the things we call bugs can be divide in two. Some are actual defects – things the system should never have done and quite possibly are detrimental to the running of the system. Everything else might be considered an enhancement. Logical right? Only where do you draw the line?

If I hit return 50 times and the system crashes the machine that is clearly a bug, the machine should not crash. But then again, how likely is someone to press return 50 times? Let me suggest not very often. And if they do, what are the chances of them doing it again? After all, there is a very easy work around. So while this might be a bug it might also be considered an enhancement request.

Ultimately, where you draw the line between bug and enhancement is subjective. This becomes really clear when you can count known bugs in single digits, 5 instead of 500. Until then calling a “change request” a bug is little more than an attempt to exert leverage and prioritise work. Calling it a bug might also have some other beneficial effect: apportioning blame might further another argument and moving a change from CapEx to OpEx column might help balance the books.

Consider all bugs from a priority point of view instead. While many different scales are used there are basically 3 categories: #1 must be done and done soon, #2 really should be done but not right now, and #3 should done but can be put off indefinitely.

Categories #1 and #3 are easy: the first are just done, the third are ignored forever but we kid ourselves that one day we’ll do them (right after we fix climate change, famine, war and pestilence.) Still, it is relatively easy to close all #3 reports over 12 months old. And next month close those over 10 months old. And so on. By all means keep a list of them somewhere but don’t pretend they will be fixed.

The only real debate are around category #2. We keep these on file in the hope that the Bug Fixing Fairy will fix them one day. In the absence of the fairy any work will require time and people to fix. That means they need to fight against all the other #2s and all the new shiny stuff. It is the same people who fix bugs as make shiny new things. It is a choice. A choice made probably by someone with the title Product Owner or Product Manager.

Which means if that fix isn’t more valuable than everything else then it won’t be done. This is the same argument I use when I say “Nuke the backlog.” If the fix isn’t valuable enough to justify being done, then it waits in a queue. The longer it waits the less important it is, leave any #2 bug there long enough and it will transform into #3.

What do I do?

The whole “is it a bug or is it a change request?” discuss is an utter waste of time. Whatever you call it work is needed, it s work to do, that work costs, that work creates benefits – the cost and the benefits are independent on what you call it. Benefit should the overriding criteria.

So

1) Fix the bugs you think need fixing

2) Don’t pretend you will fix the others, throw the bug list away

Of course, throwing away the records does not fix the “bugs”, they still exist – the same way cockroaches seem to survive everything. But we are recognising that, like cockroaches, the cost of action is not justified. This is simple honesty, a list of 100 items that we pretend will be done one day is dishonest. If that honesty creates a debate then good.

I have more advice – and more subtle advice in my “Bug management strategies” which outlines six strategies for addressing bugs and can be found in my lesser known “Xanpan appendix: Management and Team“.

Nuke the bug list when you nuke the backlog Read More »

Announcing the Succeeding with OKRs in Agile 2nd edition

Agile / /

The rumours are true, I’ve been working on a second edition of Succeeding with OKRs in Agile.

Now I’m ready to share, the content is stable, some polishing to do (mainly copy edit).

You can buy it now on LeanPub with free updates as they are ready.

In addition there is an OKR bundle available with give you the second edition and the first edition plus the unfinished Succeeding with OKRs in Agile Extra addition which contains additional chapters, journal articles, blog posts and Q&As. Buying the bundle will get you free updates to both the second edition and Extra as they progress.

No time scale for finishing Extra but I hope to have the second edition done by the end of the summer.

Announcing the Succeeding with OKRs in Agile 2nd edition Read More »

AI will undermine offshore & WFH programers first

Agile / /

A postscript, continuing from AI might effect the world of software engineering and programming. I’m supposing the power of AI real and it can replace the people we now call programmers. What next?

Spoiler alert: This post if going to upset a lot of people, who like working from home or work as offshore.

Where will the first job losses come? – let me suggest the Indian IT industry has the most to loose from AI.

In past technology cycles the first jobs to go are usually the low end jobs. The jobs which are more easily replaced are the jobs which require less skill and knowledge. Initially new technology is far from perfect so it is applied narrowly to the simpler bits of work. For example, the co-pilot feature now appearing in programmers tools which can write part, but not all, of the function.

These are often the low wage jobs (that is not always true, sometimes low wage jobs survive because the cost means they aren’t worth replacing.) So, assuming AI programming starts at the low end and works its way up market who has the most to fear? The low wage coders, who are the low wage coders? – overwhelmingly the offshore, and often outsourced, jobs.

So, expect to see India’s tech sector hit before the USA and Europe, more generally, anyone who competes on price.

For similar reasons expect to see Stackoverflow and engineers who cut-and-paste code to be hit early.

Next, recall from my last post I said that Business Analysts and others who are tasked with understanding what is needed will benefit even as programming jobs are hit (assuming AI is true). That extends to programmers, again, many programmers actually spend a lot of their time working with customers, users – and even BAs – to understand what is needed. Such programmers, like BAs, will be safer than those who code-to-order.

Such roles are less transactional in nature. The problem, the solution, and even the role itself is vaguely defined. Understanding what is needed often requires understanding to turn a vague request into something much more specific. It requires empathy, it requires background information, it requires trust and a willingness to explore together.

Let me suggest that those things are still better done in person. Doing them online is possible but in general a much greater degree of communication and understanding is needed. Nuance can be important. For that reason I believe they are better done face-to-face, in the same location, time zone and even culture. Even if some work can be done remotely having a bond which comes from physical interaction can help.

Human’s will still have a role to play in working through vagueness. That is best done face-to-face so there is a premium for working in the office. If it isn’t vague then an AI can do it.

Again, offshore programmers will loose out here. Onsite engineers will be valued more. But also, engineers who work from home will loose out, especially those who work from home every day.

It is true, you can code from anywhere: the office, a coffee shop, your house. But acquiring deep understanding, empathy and trust requires you to be there. Right now is the worst time to stay at home.

AI will undermine offshore & WFH programers first Read More »

Verified by MonsterInsights