agile

Why don’t people Test First?

In my last blog I describe two potential silver bullets: working test first and reducing work in progress. I finished by promising to discuss why they aren’t used more. This post briefly discusses why people don’t work test first, the second one, looks at why it is hard to reduce WIP, work in progress.

It is easy to understand why people don’t work test first: we (humans) are optimistic. Test first is hard and historically test comes at the end of a process. Because testing is traditionally (almost) the last thing that happens moving testing requires change which is counter intuitive and often perceived as risky. (That risk is very really for when work is sub-contracted: there is an incentive for the supplier to delay testing to make it harder for clients to change suppliers.)

The thing we call “Testing” has several parts. The first, should, involve working out what tests to do: test writing. Later those tests are executed (manually or automatically) against the candidate solution. If the candidate does not pass there is more work to do. While the test execution cannot occur until the is a thing has been created the tests themselves can be decided in advance. This is what I call test first: decide what tests you intent to perform. Thinking about the tests up front is an act of learning and informs the work of creating the solution.

Working test first requires thinking and it requires thinking about something we would rather not happen. Since we are optimistic we see this as waste, or something that should be done by people paid less than us. So it requires discipline to do it. You need to be able to project yourself into the future and ask “What will the result look like?” Thinking test first is often better done with others, e.g. pair programming or “power of three” analysis sessions, so keep each other disciplined.

While it is relatively easy to work test first when programming the skills required to write automated test first require some time to master. This skill still isn’t taught at most schools or colleges so people need to learn it later in their career. Since people are optimistic, they often lack the motivation to learn to write tests first so they never master the skills. Since they are always on the learning curve test first coding takes longer and they often give up before they master it. If they stay the course, if they master the skills then they will find that while coding may still take longer the elapsed time is less because they no longer need to fix things afterwards (“debug later”.)

(As an aside, I’ve long been of the opinion that when we get AI technology to write programs (which is now starting to happen) writing tests will become more important than code. While machines will write more code which executes and doesn’t crash there is still a need to test the code does what is wanted. If we have a good test set then machines can be left to iterate and mutate code until it passes the tests.)

Outside of code the testing skillset is less well defined and people are less accustomed to thinking about tests anyway. Consequently working test first is more difficult. Add to that the fact that there are many more parameters to consider, and people are more forgiving than machines and it become more difficult still.

So, while test first working might be a silver bullet it is not easy to adopt. But then, because it is hard to do it is also hard for your competitors to do which means test first can be the source of competitive advantage.

Next Why is it hard to reduce WIP?


Enjoyed this post? Subscribe for updates and download Continuous Digital for free

Why don’t people Test First? Read More »

Two unspeakable Silver Bullets?

There are no silver bullets” wrote the late, great, Fred Brooks. Consequently most writers and evangelists avoid claiming they have a silver bullet even when it sounds like they are claiming just that. I’ve cautioned against silver bullets several times in this blog. I often find myself telling clients “The devil is in the detail.” Meaning: there are lots of things to address and no single big fixes.

Anyone claiming to have found a silver bullet deserves to be faced by scepticism. Still…

I find myself coming back to two solutions again and again. They are the closest thing to silver bullets I know. Even if these are not silver bullets in their own right applying either makes it easier to work the detail and tackle problems.

Yet these silver bullets dare not speak their name. To do so risks endless debate and damaging your own leverage.

Keep reading for the Silver Bullets

Writing this I’m avoiding naming the potential silver bullets because I even feel many readers will stop reading the moment I name them. Please, keep reading.

Both are widely discussed by the agile cognoscenti but both are controversial. Suggesting either may lead people to think you fail to comprehend the situation or are just stupid. Thus in both cases you are likely to end up in long discussions.

Both are disliked by opposite ends of the organizational hierarchy. Both ends are optimistic, and prefer to believe people should be able to rectify problems themselves (the people problem problem again.)

Both bullets are rarely applied with vigour. Perhaps because of the previous points. When I raise the points people plea helplessness, “My boss doesn’t understand.”

Both bullets scale: in the small and large, although they manifest themselves in different ways at different scale points.

Neither is an instant fix but both start to deliver returns relatively quickly. The problem with both is you need to keep the faith and keep applying them for weeks to see a difference. In both cases, people often give up before they see the benefit.

Bullet #1: work Test First

Specifically in technical teams applying Test First coding; whether Automated Unit Testing (e.g. TDD, test driven (first) development), Behaviour Driven Development (BDD) or some other form of Acceptance Test Driven Development (ATDD). Away from code, at team and organizational levels OKRs are implement the test first principle.

Test first will not fix all problems but it will remove a substantial number of problems. That makes managing the remaining ones easier. And as to where the “extra time” comes from, that is easy: the time you don’t spend fixing defects and misunderstandings. Test first is faster than debug later.

I’ve written a lot about test first so I won’t say more just now.

Bullet #2: reduce Work in Progress (WIP)

Most commonly WIP limits are applied through limited columns on a Kanban board or limiting the work taken into a sprint. Done right OKRs limit WIP too. However, reducing WIP requires discipline.

At the higher levels companies and Government entities seem quick to reduce staffing numbers but slow to reduce work. Accepting new “projects” is easy but resourcing them difficult. Rather than prioritise, say “No” and push back on work, everything is taken on. Individuals who push back as seen as pessimists, “not team players” and “obstacles.” Pushing back does not help your chance of getting promoted so leadership ranks tend to be populated by those who accept.

The result is salami sliced people and slow progress across a broad front rather than rapid progress across a narrow range. But, reducing WIP also seems to be the hardest medicine to administer. In fact, I sometimes find myself hiding WIP reduction measures.

As an aside, I feel WIP has gotten worse since the pandemic struck, the move to remote working means every conversation is now a meeting in the diary. Our diaries are now overrun with “Meeting WIP”. An ad hoc 10 minute conversation at the coffee machine is now a 30 minute Zoom call planned days in advance.

WIP reduction is applicable at all levels: reduce the number of pieces of work the individual is switching between, reduce the number of pieces of work teams are tackling, reduce the number of projects a department has in flight, and most of all: reduce strategic WIP.

Next time

There are lots of benefits of reducing WIP so let me ask: why is WIP so difficult to reduce? – that is the question I’ll address next time. So too is Why don’t people Test First?

Finally I’ll just note: I sometimes wonder why I stop being an OKR-cynical to learned to like them. The thing is, I see OKRs as a tool to address both these problems: OKRs are test first, and limiting OKRs is WIP limiting.


Two unspeakable Silver Bullets? Read More »

Why OKRs require a strategy rethinking

OKRs offer a way to connect strategy – high level abstract goal type things – with delivery – low level concrete detailed task level things. OKRs offer a middle level planning. They are replanned often enough to be flexible while lasting long enough to give enough stability to take on bigger, more ambitious work.

As with so much else about OKRs there is a more agile way of going about this and a less agile way of going about it. Connect strategy to OKRs in the less agile way and you end up back at command and control. The give away sign is that OKRs cascade down the company so teams don’t control their own destiny, ambition is neutered and motivation is lost.

Which approach you take will largely depend on the seemingly academic question: “what is strategy?”

Many people see strategy as a one way street. Strategy making and execution is hierarchal with decisions made at the top are passed down. Alternatively strategy can be seen as emergent property of a cooperating network. Strategy is a two way street, each node both informs strategy making and execution is guided by the resulting strategy.

Depending on how you view strategy you are going to implement OKRs very differently.

Is strategy a kind of planning?

Sad to say, the predominant view of strategy is that it is some sort of grand plan. The plan sets out the “place” the company aims to get to (price, position, etc), plus the route for getting there. Anyone who has studied a little strategy will recognise this as the “Porter view of strategy.”

Strategy as planning inherently sees strategists as master planners, all the relevant information is fed into the strategy/planning department. Experts analyse the data and rationally decide what needs doing. The plans are sent out.

This is inherently hierarchical so it natural to use cascading OKRs as the implementation mechanism. But because teams have little say in setting their OKRs motivation is lost and ambition is neutered.

The is a machine like view of organizations, inherently top-down, deviation from the plan, the strategy, is an error. When OKRs do not directly support strategy OKRs need to be changed.

Study a bit more strategy and you will find that while Porter’s view has appeal it is not the only view. There are in fact many different schools of thought on what strategy is.

Emergent strategy is more agile

To my agile mind the “emergent view of strategy” fits better. Strategy emerges over time from the activities of the organization, part planned, part reactive and part backward looking to explain the past. Professor Henry Mintzberg describes strategy as “a pattern of behaviour over time” which chimes with my pattern thinking.

Strategy is a two way street, teams are edge sensors: detecting technology changes, production techniques, putting products in the hands of customers and gathering feedback. This allows learning and adaption. The organization as a whole is a learning entity: discovering customer need and mastering new capabilities. Teams have the authority to act in the best interests of the company and customers. Over time strategy emerges.

When OKRs do not reflect stated strategy it is a learning opportunity. Ask: why do team OKRs deviate from strategy?

Is the team seeing something which the strategists do not? – in which case the OKRs are signalling back from the edges to the centre.

Is the team able to follow strategy? – maybe it lacks skills or capacity, or maybe it is overloaded with “business as usual.”

Has the intended strategy has been clearly communicated? Or maybe there is no explicit strategy?

Strategy, OKRs and agility

OKRs, like other agile tools, are problem detectors exposing opportunities for improvement.

Perhaps obviously, the “Strategy as a plan” view is going to limit agile to a back-room delivery thing because it passes over the opportunities for feedback and centralises decision making. Conversely, the “Emergent strategy” view entirely compatible with devolved authority, independent teams, experimentation and “the agile mindset”.

When teams act on their own initiative the organization will be more agile. When teams wait for instructions everyone is less agile. There may be a price for agility: teams may repeat work, teams may pursue the “wrong” goals but the price of that efficiency is lost agility which costs in missed opportunities and improvements.

If you want high levels of efficiency and believe in planned strategy you will look to decide strategy and align OKRs with the strategy before you do anything else. However, that results in less agility.

If you want to using OKRs and maximise agility then you need to take an emergent view of strategy. In many ways, we back to the Theory X or Theory Y question.


Download Continuous Digital for free when you subscribe for Allan’s updates

Why OKRs require a strategy rethinking Read More »

New year resolutions & improvement days

Happy new year!

Traditionally new year is the time for making new resolutions. We resolve to change our ways, try new things, give up bad habits and make an effort to do things differently, for the better.

So why not try that in your work? Why not try that with your team?

A few years back I organised a “New Years Resolution” session at the company I was working for. Engineers gathered, we suggested ideas, we talked them through and we resolved as a group to do some new things. The fact that everyone was still fresh from a break and had been hearing about, and perhaps deciding on their own, new year resolutions, gave it an extra boost.

Yes, it was a bit like a retrospective and you could set it up as a retrospective on the past year.

Which leads me nicely on to: Agile Improvement Days – maybe I can help you?

Last year I visited Scandinavia several times to run a series of improvement day workshops for a client. The days were based around a series of well tested exercises, group discussion, reflection and action planning. Most of the days focused on teams but one of the days was specifically for product owners and another for business representatives.

These workshops came to mind when I was reviewing the survey I ran a few weeks ago: over 27% of respondents said their agile initiative “needs a reboot”. (Another 27% said it was early days and 33% said they were “in search of great.”) In thinking about how I could help these teams I realised I had a ready made, tried and tested answer: the improvement days!

As much as we talk about kaizen and continuous improvement it doesn’t always happen. Teams need reminding sometimes. I’ve long been a fan of the lesser know kaikaku – also called a “kaizen-blitz”. Even the best teams can benefit from trying something different. In fact, the best teams probably need something different simply because they have tried everything else.

So, I’m now offering my Agile Improvement Days workshops in their own right. You can have a single one off day, a package of days for multiple teams, different days over several weeks or have the days customised to your own need.

Feel like rebooting your team? Help your team move from good to great? Or deal with a specific issue? Have a look and let me know what you think,

And please, forward this on to anyone who you think might benefit from such days.

New year resolutions & improvement days Read More »

Objective Driven Agile, BLDD & Reactive styles of development

Looking across the state of teams today I can clearly see three different styles of agile: Backlog Driven Development, Reactive and Objective Driven Agile. All have their place, all have their uses but the first two of these are a dead end. I’ve been speaking about the third, which I’m calling Objective Driven Agile, for years but in the last few months, since writing Succeeding with OKRs in Agile and speaking to many people about how OKRs and agile fit together, it has become clear to me that ODA allow us the industry, and teams, to address a number of problems that have arisen with agile in recent years.

1) Backlog Driven Development – BLDD. Teams are typically working in a Scrum fashion with a backlog and short sprints. Such teams are sometimes called “feature factories” because they are aiming to “do the backlog” – and the backlog is inevitably a lis of features.

While the Scrum these teams practice is a lot more agile than what came before they haven’t really moved very far from the big requirements documents of old. Backlogs are frequently bottomless pits, the team can never reach done. The loss of change review board might well be making things worse because Product Owners often lack the authority to say “No” or remove items from the backlog.

Still, not only are these teams agile but in many places this is success. The team are churning out stories, customers can see progress and are persuaded to part with cash. If the backlog can be tamed they might even declare done one day. But then, if the team is being operated by a consultancy or other outsourcer for a client the last thing they want to happen is for work to be done.

2) Reactive. Reactive teams gravitate towards Kanban but some are compelled to work in a Scrum fashion which doesn’t match their real work. Such teams may see backlogs are an anathema because they do “what is needed, right here, right now.” Team members here will say “true agility is listening to what customers want and getting it done as quickly as possible.” And in a way they are right.

Again, these teams are a success story, particularly if they are supporting a live system, running DevOps or if customers previously had to wait months for results.

The problem here is that these teams don’t have much capacity for doing the backlog or anything else and yet they are frequently still expect to “do the backlog”. If such a team have been tasked with immediate customer support then that isn’t a problem but frequently these teams face competing demands.

3) Objective Driven Agile, ODA: this is the approach I’m focused on at the moment. With Objective Driven Agile teams have a mission and a higher purpose, something more than “do the backlog” or “keep the system working.” Such teams might be considered “Empowered” and might practice “Dual track agile.” The key thing is, they are not beholden to a prepared list of things to do. The team are responsible for deciding what customers need, what will add value and what will meet team and organisational objectives, and then, delivering that thing.

These teams have “Product Owners” who are more than mere Backlog Administrators – I’ve started calling them “Product Specialists.” These people are tasked with understanding what will add value for customers, users and other stakeholders. Importantly they have the power to decide what gets done and to say “No”. With that power comes responsibility: responsibility to the team, to stakeholders and to other leaders in the organization. That means Product Specialists can explain – in a business case or in a star-chamber – how work on the product adds benefit and how the desired outcome – the objective – is moves things forward.

All three of these styles have their advantages and disadvantages but the real problems occur when the styles are not clearly stated.

Consider the team trying to deliver the backlog BLDD style but who have to “keep the lights on” and support a live system. It is mathematically impossible to make accurate forecasts about delivery when events can derail you. It is also nye on impossible to deny customer requests when they are waiving a large sum of money or escalating their ask through your organization. But again, this can blow up any plan or roadmap.

Nor is is possible to pursue objectives when teams are committed to supporting live or delivering a backlog. At best the objectives duplicate the role of the backlog and at worst increase work-in-progress and add stress to individuals on the team.

So my advice: decide which type of team you are and focus.

In the last few months I’ve been speaking a lot both about objectives and “just in time backlogs”. I’m fired up and want to pursue this idea, if you are interested please let me know and I’ll write more.


Subscribe to hear more from Allan Kelly and download Continuous Digital for free

Objective Driven Agile, BLDD & Reactive styles of development Read More »

How fresh is your backlog?

Do you struggle with an overwhelming backlog?

Do you count the number of product backlog items in your backlog in tens? hundred? or thousands?

Does your backlog contain many stories which have been there for months, if not years, and yet never raise to the top of the backlog?

Is your success judged on your ability to do the backlog?

Backlogs were a good idea when they were introduced a bit over 20 years ago but today many teams slaves to the backlog – see my posts on the Tyranny of the backlog and Purpose over backlog. One of the benefits I’ve called out for OKRs is the ability to move away from backlog driven development (BLDD).

In Succeeding with OKRs in Agile I ask suggest you either need to prioritise your backlog over OKRs (in which case OKRs are derived from the backlog you intend to do) or OKRs over backlog (in which case OKRs are derived from strategy and the backlog plays a supporting role.) In my podcast with Jenny Herald earlier this year I even say “Let OKRs drive… nuke the backlog.”

Filipe Albero Pomar recently shared his backlog freshness blog which I think is great. Freshness is a great way to think about the state of the backlog that separates the size of the backlog from the relevance of the backlog.

Filipe’s idea is simply to talk about the backlog in terms of freshness – you have a fresh backlog if your backlog items are fresh: written recently, relate to current opportunities, problems and things people currently want.

And of course, the opposite of fresh: stale, stories that have been sitting in the backlog for months, even years, stories that relate to yesterday’s problems and project, stories which people wanted last year. The existence a big backlog of stale stories means the team is seen to be not delivering, the end-date is far off because people still expect all the work to be done.

Filipe suggests backlog freshness can be measured:

1. Set a cut-off date

2. Categorise stories as fresh or stale: fresh stories have been written since the cut-off date, those which are older are stale

3. Calculate freshness as a percentage of fresh from the total: if 25 stories out of 60 have been written in the last month then the backlog is 41% fresh, and 59% stale

Thats a useful metric, I think we can do better, look at the graphic above. I group backlog items into age groups and graphed them. For completeness I added a line to indicate average story age. Clearly this backlog is not fresh – nearly half the stories are over a year old.

I like the idea of graphing backlog freshness because it is easy to understand and makes an impact. In the graph above I’ve categorised backlog items into age groups and added an average line. Clearly this is not a fresh backlog. Whether this is the way to demonstrate backlog freshness I’m not sure – I’m playing with a histogram and quartile ranges.

With some clients I’ve thought of the backlog like a mortgage. There is the principle (the existing backlog), the interest rate (the growth rate of the backlog) and the monthly repayments (stories reaching done). Unfortunately when you do this you sometimes find the mortgage will not be paid for many years, and perhaps never. (Don’t worry about estimating the size of stories, for this sort of analysis the number of stories will get you started, and if your backlog is measured in hundreds of items the small will offset the large.)

I’d love to talk more about this and experiment with some ideas, I think it could be a very useful way of thinking about the backlog.


Subscribe to my blog newsletter and get Continuous Digital for free

How fresh is your backlog? Read More »

Scrum or OKRs, which comes first?

“Hello Allan , I followed a few of your seminars on OKRs and I am reading your book. I do have one question. I will start a transformation soon. The company has the ambition to move to Scrum and also OKRs; Do you have any advise on where to start? OKRs first or SCRUM first. Thank you a lot !”

This question appeared in my mailbox – or rather my LinkedIn box – a few weeks ago and I thought other readers might be interested in my answer.

My answer is: do both together.

That will sound ambitious if you see Scrum and OKRs as distinct things but I don’t, to me they are synergistic and can be viewed as one change. In the process I see the opportunity to create a simpler form of agile, or simpler version of Scrum if you prefer. Let me describe.

The Scrum Master role remains pretty much the same as regular Scrum. The main change is that in addition to facilitating planning meetings and sprint retrospectives the Scrum Master will additionally facilitate OKR setting sessions and OKR retrospectives at the end of the cycle. They will want to ensure the OKRs are known by everyone and people reference to them during sprints.

Similarly the Product Owner role remains pretty much the same with the additional need for the PO to lead thinking on what OKRs to set. This means the Product Owner needs to do more horizon scanning, talk to more stakeholders and prepare to set objectives that will last several sprints rather than just one at a time.

Simplification comes in that there is no need to build up and administer a product backlog. Set the OKRs, then go straight into a planning meeting and ask “How do we make progress against this OKR?”. Write the stories you need to do that. Use the OKRs as a just-in-time story generator. If you generate stories you cannot do this sprint then put them in a product backlog for the next planning meeting.

In the next planning meeting review progress and ask yourself again: “what do we need to do to make progress on these OKRs?”. It might be that you have some stories from last time to work with, if not write some more. OKRs in effect become the Sprint Goal and you generate the stories from there. (If you are using a Product Goal as well then reference that when setting the OKRs at the start of the cycle.)

Estimation is reduced because you have fewer stories in play and in the backlog. If you want you can use story points and velocity to determine if the sprint is full or you can just ask the team “Is that enough work to keep us busy?” and “Do we have space for more?”

If you want a more sophisticated system then get the stories out on the table, put them in the order they are likely to be done, then go from top to bottom asking “On a scale of 1 to 10, What are the chances we will get this story done in this sprint? – where 1 is unlikely and 10 is almost certainly.” If the probability is below 8 you probably take action, break the story down, reorder the work order or just accept that you probably won’t do everything you would like to.

In the longer term you can count the stories done to build up a record of capacity.

I would aim to do end of sprint demonstrations and better still release to live. The OKR may not be complete but the stories in the sprint can start delivering value early. As usual keep quality high, aim for zero bugs and automate everything that needs testing.

If you are new to both Scrum and OKRs then I would probably run one week sprints and a six or eight-week OKR cycle the first time. Do a retrospective at the end of the OKR cycle, after that you might move to two-week sprints and 12 week OKR cycles but keep an open mind and decide what works for you.

All the way through keep delivering benefit to customers, hitting OKRs is icing on the cake, and there are no prizes for doing perfect Scrum.

I’d like to think I outlined this recipe in Succeeding with OKRs in Agile but I suspect I wasn’t as clear as I could have been. Increasingly I’m seeing OKRs as a means of stripping agile back and simplifying it.


Subscribe to my blog newsletter and download Continuous Digital for free

Scrum or OKRs, which comes first? Read More »

Agile OKRs extra – yet another book

I blogged last week that I had begun work on a new book – How I Write Books which is now a work in progress at LeanPub – signup and be the first to know when the draft is published.

Well a funny thing happened while I was setting up my tool chain to write that book: I found another book! Well, perhaps half a book is a better description.

Succeeding with OKRs in Agile Extra is a companion to last year’s best seller, Succeeding with OKRs in Agile. But it isn’t a complete book in its own right, it isn’t really a sequel, it is a companion. It contains a mix of material. Material which didn’t really fit in the first book, material with was’t needed, ideas which didn’t develop far enough and some unfinished chapters.

As such it is like my Xanpan Appendix, unused material which is still interesting and might appear elsewhere in time.

I really want to work on How I write books so I don’t have any immediate plans to progress extra. If you enjoyed Succeeding with OKRs in Agile, if you would like to know more, or if you would like to just see how a writer’s mind works check out Succeeding with OKRs in Agile Extra.

Agile OKRs extra – yet another book Read More »

Its the engineers, stupid – one from the heart

When I engage with company and teams I’m always keen – nee desperate – to get to meet the engineers and teams who are doing the work. If days, maybe even weeks, go by and I’m not doing that I get very frustrated. More importantly I’m not sure what to believe from those I am talking to.

There was once a bank I spent time with. As soon as I got to the office I discovered almost all the engineers were in a far away country and I wasn’t going to get to visit that country. The few engineers in the London office spent a lot of their time hand-holding those in the far away place. When you looked closely, when you spoke to the engineers far away you found things didn’t add up. One delivered a perfect 10 story points every iteration without fail. Another team increased velocity sprint after sprint. One engineer fell off his moped and broke his arm, the work was still delivered on time – it took all my wiles to discover another engineer had worked all weekend to meet the deadline.

Why am I so desperate to meet the engineers? – well there are several reasons, some more rational than others.

First off, the engineers are where the work happens. In lean parlance they are the gemba, source of truth.

Second, these are the people who will need to change or be changed. There is only so much you can change with an organigram – and to be honest, I’m doubtful reorgs really change much. Sometimes I imagine managers moving their workers around like pawns on a chess board while the reality of work is hand-to-hand combat.

Thirdly, and perhaps most importantly for me: I see my role as helping these people. I am, by profession, by temperament and by ancestry an engineer. I am motivated by the desire to help those who do the work have a more fulfilling life. I still remember the frustrations I faced as a coding software engineer.

Thats why it hurts – really hurts – when engineers tell me “agile is rubbish”, that “agile has nothing to offer”, when they tell me that I’m not helping. Its not that I’m precious about agile, “agile” is just the toolset I’ve found helps. I also know that tool kit allows me to go outside the toolkit.

I was hired by a Californian company to give agile training to their Cambridge team. A few minutes in, one of the engineers told me directly “Agile can’t help us here, we can’t go any lower.” The other engineers in the room were of the same opinion. It turned out the managers had been to Scrum training and come back pumped up about high performing teams and faster-better-cheaper. Sustainable pace, autonomy and quality weren’t on the table.

That hurt and it may have been the toughest training gig I’ve ever had but I think I turned it around. I demonstrated the need for quality and explained the managers were missing essential parts of the puzzle. Unfortunately I didn’t get to meet the managers – they were off playing chess.

But I do engage with managers. Often they are the route to the engineers. Unfortunately some engineers see that as a problem in itself: “our problem is tech debt, sprinting won’t help us” so I’m discounted. In my world – the world of Xanpan – sprinting is a rod you put up your back to make yourself better, if you don’t address quality (e.g. tech debt) issues then you won’t succeed at time-boxed iterations.

(BTW I talk about engineers because most of my work is with engineers, and software engineers at that. I’ve worked a little with other professions and I’m sure most of what I say carries across directly but my experience and empathy is greatest with engineers.)

To deal with managers one needs to understand their concerns, one needs to listen and speak in ways they understand. Engineers may struggle with managers and technical issues but managers also struggle with their managers, organizational debt, customers and the market.

The same is true when I wonder over into the world of product ownership – Product Managers and Business Analysts. Engineers have a bad habit of seeing these roles as “Management” but if you spend time with the “demand side” people you find their concerns are almost identical to coding engineers. BAs worry that what they are being asked to do is unreasonable, that it doesn’t make sense, that something else needs to change first and that people don’t appreciate how things really work. The biggest difference between programmers and BAs is simply that, on average, BAs dress more smartly and are more likely to put on a tie.

One can’t understand a system and one can’t get to the truth if one can’t visit the place where work happens. When manufacturing things that place is the production line, in the digital world that place is the mind. Constructing software is an intellectual exercise that happens in the mind and is only manifested via a keyboard in code. To see the truth one has to speak to engineers.

I’ve seen some awful work environments: a room packed with 28 engineers, very few windows, little fresh air, a development manager on a raised platform at one end, the HR manager at the other end, her desk right by the single door in and out with the clock-in-clock-out cards on the wall.

More recently a large project at a matrix managed organization. The complexity made it difficult to know who was actually on the project and what teams existed. Management existed in its own bubble.

I feel pain simply seeing such places. What it can be like to work there I can only imagine. I assume people become dumb to the pain, switch off to the failing and accept the normalisation of deviance. Or, to put it another way: a culture of failure.

Both of these two examples shared one thing in common: massive Gantt charts which claimed to plan the work. In one case I saw someone scheduled to spend a month writing a manual in two years time. While these charts claim rationality they are so disconnected with the gemba as to be fantasies. I feel cognitive dissonance knowing that the managers who put their faith in such mechanisms are both rational and totally mad.

Encountering such places is painful for me. On the one hand I want to help, I want to make the engineers lives better – that is what I do! The challenge can be great. On the other hand it can be mentally and emotionally draining. Because I am passionate about what I do I feel that. If I switched off, if I treated it as a money paying gig then I too become part of the same culture and loose my efficacy.

On the other hand, when things go right I love it – perhaps because I’m an engineer and I see fixing the organization as a way of fixing the code, its called Conway’s Law.


Its the engineers, stupid – one from the heart Read More »

Réussir avec les OKR en Agile (French OKRs)

I am delighted to say The French translation of Succeeding with OKRs in AgileR̩ussir avec les OKR en Agile Рis now available thanks to the hard work of Nicolas Mereaux and Fabrice Aimetti.

The book is available right now on LeanPub as an e-book. After Easter we’ll start work on getting it a print version available.

Until then a big thanks to Nicolas and Fabrice!

(Please get in touch if you are interested in translating the book to your favourite language.)

Réussir avec les OKR en Agile (French OKRs) Read More »

Verified by MonsterInsights