Agile

I’d like to share my answer to this question, it came as a follow up to a presented “Reawakening Agile with OKRs” to a company last week. This is also an opportunity to expand my thinking.

First we need to make some assumptions and decide policies.

I’m going to assume that the team know what OKRs are, why they are being introduced and what is expected of them in setting OKRs. So, if this assumption does not hold true then before you set the OKRs establish some shared understanding on these points. Perhaps get an introduction to OKRs for the team. (I’ve started work on another video tutorial series, an introduction to OKRs and agile.) Next get some guidance from those suggesting the team use OKRs on what they expect.

I’m sorry to say I hear of plenty of cases were these things don’t happen. Teams are told: “thou shalt use OKRs.”

It would also help if those suggesting OKRs have spelt out what they see as success (100% of OKRs complete? 70%? Or, as I prefer: benefit delivered.) But you know what? If you don’t know this you can clarify it later, nice to know in advance but in a pinch, not essential.

Next I suggest Think Team – I’m skeptical about individual OKRs so don’t set OKRs on anything smaller than a team level. While it might help if the “next level up” set OKRs first if the team start first then the team clearly own the OKRs. So, while there are advantages to knowing the priorities higher up there are also advantages to taking the initiative.

If you want to set some kind of individual objectives then my advice is: wait while you learn. Get some experience at the team level with OKRs before thinking about individual goals. Or perhaps, for the first two quarters make everyone’s individual goal “learn how to work with OKRs by working with OKRs.”

It will also help if you have some idea of how your OKRs are going to line up against any backlog you have. Are the OKRs reverse engineered from the backlog? Or do the OKRs have priority over the backlog? Or, as I suggest, use OKRs as a story generating machine instead of having a backlog?

Similarly, if you team needs to “keep the lights on” and do “business as usual” stuff in addition to OKRs you need to know in advance. That will soak up capacity. So how do you reflect that in your OKRs? – in Succeeding with OKRs in Agile I suggest a OKR-Zero for this type of stuff.

Now to set OKRs I suggest at least two meetings – and preferably not too many more. The first meeting is a drafting meeting. You might think of it as a big brainstorm. Get ideas out on the table, talk about priorities. Aim to get a rough draft of some candidate OKRs.

Before that first drafting meeting someone – Team Leader, Manager, Scrum Master, Agile Coach, whoever – needs to confirm what the timeline is. Are the OKRs to run over 13 weeks? – or is it Christmas so this a 15 week quarter? Or maybe you only have 10 weeks this time. The deadlines are important. Don’t plan OKRs without knowing when the first and last days of the cycle are.

It helps if team members have given a little pre-thought to what they would like to see in the OKRs. Now I don’t want a lot of pre-work. And I especially don’t want lots of planning because that a) detracts from they current cycle and b) potentially limits ambition when setting the OKRs. Still a little forethought – think of it like writing your Christmas list.

This suggestion is particularly important to the Product Owner. Since team team are aiming to delivery benefits to others (customers, users, stakeholder, whoever) it is natural that the Product Owner takes a lead in drafting meetings. Whatever title you give this person this is the person who is charged with listening to customer requests, understanding non-customer users, liaising with stakeholders and understanding the business/product strategy and knowing what would be beneficial to who. So it makes sense for this person to have plenty of ideas on what to do.

In the run up to OKR setting is Product Owners need to bring all their homework together and decide what outcomes they would like. The Product Owner needs to present this thinking to the team in OKRs setting and work with the other team members to craft OKRs which reflect those asks. Most importantly of all, they have to understand the implications when some items don’t make the cut.

Thus the Product Owner will walk into the OKR planning meeting with the longest Christmas wish-list of any team member. But they will not get everything on that list, far from it.

Once you have your draft OKRs take a break. At least an overnight break, or maybe a few days.

Do any more homework that is needed (e.g. check requests with customers, show draft to partner teams and managers for feedback, check availability or timelines of people or equipment that might expect to need, etc.)

The second meeting is there to firm up the draft. Ideally after some reflection and some homework everything in the draft looks good, all you need to do is tighten it up and declare it final.

But there is every chance your draft contained six desirable objectives and it needs some reflection and some homework before you can reduce it to three. It may also be that that homework turns up a problem, a priority that had not been appreciated or a block that wasn’t foreseen. In which case you need to revisit the draft.

Setting OKRs inevitably means making choice about what will be done and what will not be done. I’ve heard of teams who have “do not do” lists in parallel with OKRs. This is because OKRs implement strategy and if the strategy is lacking or unclear then OKRs will make that clear, and hopefully seed a conversation.

Enough for now. I hope you found that interesting. If anyone out there has any more questions about OKRs please let me know and I’ll see if I can answer them here.

Subscribe and download Continuous Digital for free

---

Child at steps in image Jukan Tateisi in Unsplash.

You might think that I’m a really organized person. After all, I spend a good chunk of my life helping other people be more organized about their work – and not just organized, prioritised, effective, and all those other good things. That might be true, people who know me well say I’m really well organized. But I always feel I’m faking it. I’m really disorganized.

As I spend a lot of time working by myself, for myself, and interleaving clients I need to organize my days. Over the years I’ve tried man different ways of organizing myself. Todo lists in my notebook are the main mechanism. Notebook and todo-list works well for the medium range but for the actual work of today its not so effective. I have, and sometimes use, a whiteboard: write out a list of things todo today and tick them as I do them. I’ve use post-it notes: write out all the things I need to do on one post-it each, prioritise them down the side of my desk and tick them as I do them.

In general I find that a system works for a while, maybe even a few of weeks but it decays. Perhaps its too routine, perhaps I’m over familiar. After a while I need a change. So after a period in the doldrums I bring back an old system or invent a new one.

During the last year of house-arrest I’ve found organizing myself really hard. A few months ago I came up with a new system: good old index cards. Extra big ones. On the left are the mundane or household things I need to do. On the right the important business stuff todo.

The keys to making any one of my systems work are:

1. The power of the (big red) tick. Being able to tick things off and mark them as done. Perhaps thats why electronic systems never work for me.

2. Prioritisation: Recognising that some things are more important and need to be done sooner or require more time. Accept some things fall off the bottom and don’t get done.

3. Limiting WIP, work in progress. It is easy to put too many things down, not do them, and write them down again tomorrow.

4. Sticking to the list and not getting distracted.

5. Rewrite the list every day

Now the last three there: prioritisation, limiting WIP and not getting distracted require personal discipline. I have to force myself to work within my system. Sometimes that is hard but if I don’t do it the system breaks down. And actually, that is usually why the system periodically requires reinventing.

For example: many of my cards list “EM, SL and LN” – short for E-Mail, Slack and LinkedIn. Messages arrive for me on all three and there are conversations I sometimes want to join in. But, very little on any of them is so important that is needs to be looked at at 9am. Everything on Slack and LinkedIn can wait, and almost everything on e-mail can wait. So a quick e-mail triage at 9am and pushing the rest until later in the day allows focus on important stuff. Unfortunately, because EM, SL and LN all generate dopamine it it very difficult to prevent myself from being distracted by them.

Rewriting the list everyday helps focus because I’m saying “this is what I will do.” For years I found that every time my notebook todo list ran out of space and I rewrote it I was much more productive that day – plus it was a cathartic experience. Arguably rewriting my list everyday is a waste of time because some items carry over and some items repeat. But the actual process of doing it, the planning rather than the plan, creates focus and motivation.

As you might have guess by now, a lot of this carrie directly over to my clients and their teams: prioritise the work, limit wip, let work fall off, stick to the system and the difficulties of discipline. Of course, what I’m describing is a system that emphasises planning over plans.

Another issue I regularly run up against is the “second priority” problem. Once all the pressing, really important and urgent stuff is done where do I put my attention? When I have three or four lower priority things to do it can be hard to choose which one to do and to stick with it. It can help to time-box the work, write “45” next to the work item and when I start work on it set a timer to stop after 45 minutes. I may not have done everything but I will have made progress and will at least have broken the second priority logjam.

Sometimes it’s hard to address an issue because it not clear what needs doing. When todo items are transactional “call X”, “write Y” it is easy to close them off. But sometimes hard to know what “Website” actually involves, I’m the one who decided I should work on my website, I’m the one doing the work, but what exactly should I be doing? And even if I know I should be, say: “updating keywords” what keywords? where? Even thought I can see something needs attention I don’t know what.

So, am I organized? or disorganized?

Well, I think this goes back to my dyslexia. Dyslexics are frequently disorganised because many (including me) suffer with poor short term memory. Left to myself I can be very disorganized.

But, dyslexics over compensate. A reoccurring pattern with dyslexics is that we have to create our own learning strategies and solutions to our own problems. Sometimes we over compensate and something we are bad at naturally becomes something we are very good at.

That I think is why other people think I’m really well organized and I think I’m badly organized.

And it is those ways of thinking and approaching organization – and work to do – which carries over to my professional work. Call it neurodiversity if you like.

---

Subscribe to my blog newsletter and download Continuous Digital for free

18 months ago everyone who worked in an office was sent home, and told “work from home.” Suddenly even the most anti-work from home companies and bosses had to accept it. Even the slowest, bureaucratic, IT departments had to support remote working.

In many ways it has been a great experiment – an experiment that is judged a success because people have been more productive than expected. And look… the western economies are still here. Indeed, some businesses have boomed.

But, I don’t think that was the great experiment. To my mind the great experiment starts now – now that people are getting the option to work in the office or work from home, now that big-bad-managers can lean on people to go into the office and start using “presenteeism” again.

There are a few of points about the great work from home which I think are generally missed. It is because these points no longer apply which makes me thing now is the true experiment. I’ve also got a bunch of concerns, I’m not convinced that surviving the last 18 months by working-from-home is the way we should carry on.

First, the great work-from-home was egalitarian: it wasn’t a privilege or a punishment. Nor was it self-selecting: whether you wanted to or not you did it.

Second, everyone had to do it so everything was online. There were no meetings with some people in one room and others hanging on the end of a telephone, the kitchen was no longer a place for side chats and the smokers couldn’t have their own meetings outside the back door.

Third there was no end date: there was no option to say “we’ll decide it when we are all in the office.”

Finally, last but not least: at least initially it was existing people and teams so relationships and social-capital already existed People were used to working together already.

Bringing in new people, “onboarding” and “enculturing” is always hard, its a lot harder online – and being honest, one of the things I find hardest is finding my way into a new team when everything is online.

As work-from-home has gone on teams have had to learn to recruit and incorporate new people online.

Now, as people drift back to the office – at different paces in different places – these points don’t hold. Now being in the office or not is often a choice, it is no longer whole teams so those side conversations are back.

To my mind this is an even bigger experiment than the great work-from-home; and I think it is going to prove more difficult for companies and teams to navigate.

Personally, I’m really lucky, I’ve had my office in my home for years so I’m all set up for it. But I’m sick of working in the same place day-after-day for months on end. While I’m sure many people never want to see an office again I think there will be many others who are keen to go back to the office.

Next, I have a few fears about the extended remote working model. First off is mental health: without an office, without the journey to and from the office, without the change of clothes that all involves there is less separation between work and home. Without dividing lines that means work impinges on home time and it is difficult to escape work stress.

Second, online working is far more dependent on the written form. That means that those of us who struggle with the written form are at a disadvantage.

Yes I know I’m a bad example, I write too much. But look at all my grammatical and spelling foibles – I’m dyslexic. I’ve learned to be good at writing but really I’d rather be talking.

As e-mail replaces the telephone, Slack replaces the talking across the desk, WhatsApp replaces coffee conversations those of us who struggle with writing are disadvantaged.

Next, I’m concerned for younger people, those who only entered the work force recently. How are they to learn about their job? How are they to learn work culture, let along specific company culture if there is no office?

And most those same people are often in a more difficult position. They are stilling with their parents in their childhood bedroom, or they are living in a house share with problematic internet. In short, younger people need the office more and they need older people as role models and teachers.

Finally, I feel a lot of technology people – programmers specifically – are very keen to push back on any suggestion that face-to-face communication, and co-location, has any advantages. It seems very acceptable to say “We can do everything online, there is no difference.”

I beg to differ. If only because without body language, without facial expressions, without seeing how people react then communication is less – the old “80% of communication is non-verbal” idea. You can do a lot online, but you can also do a lot in person.

Unfortunately I don’t see this debate. I don’t see people discussing “what is best done online” and “what is best done in person.” I see my fellow digital workers being very quick to push back on anyone that questions online working.

Perhaps it’s me, but I feel the technology community is so anti-office work that I have hesitated even to voice these concerns. Anyone else share these views? Or am I persona non-grata?

---

Subscribe to my blog and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

“Should unplanned work be allowed after the sprint starts?”

One of those questions which comes up again and again. And it came up last week when I visited a clients offices – yes I actually visited a client! The answer to this question is, as often happens: It depends. So let me give you my thinking.

First, many teams have a rule that work must be scheduled in the sprint planning meeting, after which this is fixed. Teams have a right to make this rule so if this is a team rule – what Kanban folk call a policy – then work is not allowed in.

This rule is based on a strict interpretation of Scrum. The thinking – particularly in early implemenations of Scrum – was that changing priorities was a big problem for teams and therefore fixing the work to be done for a few weeks made sense. In the event of that things did change the team would declare an “abnormal termination of sprint” and move to start a new sprint with new priorities.

Now for some teams this makes complete sense. Barring work from entering the sprint after planning makes complete sense. Equally it makes sense for team members to only do work scheduled in the sprint and refuse all other work. So, it depends… when a team is troubled by new work appearing, priorities changing, and when a team are expected to deliver something new – when their overarching priority is not support but building something new – then this approach makes complete sense.

But, don’t follow this rule just because you think Scrum says so. I just had a quick look at the latest Scrum Guide doesn’t actually mention abnormal termination of sprint. It does say “No changes are made that would endanger the Sprint Goal” which then leads us into a conversation about the sprint goal but let’s hold that for now.

Now ring fencing the team and the sprint like this solves one set of problems but it creates another set. If the team are aiming to be reactive why would they not pick up work?

And as teams increasingly become DevOps or SecDevOps, or BizDev, or whatever, things get more complicated. It would be irresponsible to hold a “no work enters the sprint” if the live server was down or a security hole had been found. But at the same time, being hyper-reactive has a downside because the team would be constant distracted.

Ultimately it is the Product Owner who should have the final say on whether work is unplanned work is accepted or not but when you have a customer on the phone someone else may be forced into a decision.

I apply two tests: is the unplanned work really urgent? – or could it wait a few days and be considered in the next sprint. (Or even queued in the backlog for longer.)

Second, is the unplanned work valuable? – namely, is it more valuable than the work the team are doing and would be displaced by this work. Ideally it would valuable enough to justify the disruption it causes by late entry too.

Hence I like to talk about urgent but valuable unplanned work. Just because something appears after sprint planning doesn’t mean it is not valuable. If the work is urgent, and if it is valuable enough, then it deserves to enter the sprint and get done.

However I like to build in two feedback loops. First, as the work arises, does the person raising the work understand the disruption this will cause? Are they prepared to accept that some other work may not get done?

I like to make this real: pull up your board and show the requester the consequences. Let them prioritise the work against the current planned work. This can make the unplanned work go away.

Second, mark the late-breaking work so you can track it through the system – on a physical board I would use a yellow card. At the end of the sprint review how many yellow cards you have and talk about whether the right decision was made.

Over time, as you build up your data – and stock of done yellow cards – you can reason about the cards and decide your long term action. For example,

You might want to make an allowance in sprint planning for unplanned work: suppose your team averages 3 yellow cards a sprint, then, when you are planning the sprint allow space for them.

If you have many yellow cards regularly you might even want to move to a Kanban model or split the team.

Review the requests, what are the common themes? – is there a module which is particularly troublesome, would some remedial work help reduce the unplanned work.

Or is there someone in particular who raises unplanned work? Should the team leaders talk to this person and see if they could change their behaviour, perhaps they could make their requests a few days earlier.

Maybe you want to ring-fence a team member to deal with unplanned work while the rest of the team pushes on with the main work.

As I said at the top of this post, the unplanned work question comes up a lot. I discussed it in Xanpan so if you want more examples go there. And if you have any other suggestions please comment on this post.

---

Subscribe to my blog newsletter and download Continuous Digital for free