Author: AllanAdmin

AllanAdmin from Allan Kelly Associates

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

The post Questioning the great work from home experiment appeared first on Allan Kelly Associates.

AllanAdmin from Allan Kelly

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

The post Questioning the great work from home experiment appeared first on Allan Kelly.

AllanAdmin from Allan Kelly Associates

For the record there are a few words I avoid using if I can.

Should: “we should feed the starving millions”, “we should create world peace.”

Should is useless.
It is also a declaration of what should be but also an admission of defeat, we give up immediately, we don’t even try.

Empower and empowerment: “I will empower the team”

It was Henry Mintzberg who alerted me to the problems with this word: empowerment is a loan. Empowerment is not real power, not real authority.

That I empower you means “I have the power, I am going to lend it to you… but I am still responsible and if you screw up I’m taking right back.” Thats why I prefer to talk about devolving, distributing and even sharing authority.

Commitment: “The Scrum team committed to delivering 20 points”.

Actually my dislike of commitment is usually confined to software teams and older implementations of Scrum specifically.

First commitment tends to be one sided: the development team are expected to commit but not their customers. And in an environment were the team is not completely independent (i.e. there are times when it needs non-team members to do something) it is unfair to ask them to commit.

This is very true in large companies where teams are often restricted by a multitude of rules, demarcation lines and restrictions. Such teams don’t have the power to commit on their own, they need others – and superiors – to join in making thing happen.

Second, because of those problems the word “commitment” itself has changed meaning. Originally when a team said “We commit” it meant “We are going to make this happen, come hell or high water, we will do everything in our power to make this happen.” Over time, because the team couldn’t move heaven and earth due to company policy, commitment has become devalued. Today, “commitment” has come to mean “This is the work we plan to do this sprint and we will try out best (but don’t get your hopes up too high).”

I’m sure there are some more words I avoid using but less often, I’ll make a note of them next time I’m temped and report back.

---

Subscribe to my blog newsletter and download Project Myopia for Free

The post Words I avoid using: should, empower, commitement appeared first on Allan Kelly Associates.

AllanAdmin from Allan Kelly Associates

My old ACCU friend Derek Jones has been beavering away at his Evidence Based Software Engineering book for a few years now. Derek takes an almost uniquely hard nosed evidence driven view of software engineering. He works with data. This can make the book hard going in places – and I admit I’ve only scratched the surface. Fortunately Derek also blogs so I pick up many a good lead there.

🔊 Listen to Post

One of Derek’s most thought provoking finding is: most software has a very short lifespan.

At first this finding worried me: so much of what I’ve been preaching about software living for a long time is potentially rubbish. But then I remembered: what I actually say, when I have time, when I’m using all the words is “Successful software lives” – or survives, even is permanent. (Yes its “temporary” at some level but so are we, as Keynes said “In the long run we are all dead”).

My argument is: software which is successful lives for a long time. Unsuccessful software dies.

Successful software is software which is used, software which delivers benefit, software that fills a genuine need and continues filling that need; and, most importantly, software which delivers more benefit than it costs to keep alive survives. If it is used it will change , that means people will work on it.

So actually, Derek’s observation and mine are almost the same thing. Derek’s finding is almost a corollary to my thesis: Most software isn’t successful and therefore dies. Software which isn’t used or doesn’t generate enough benefit is abandoned, modifications cease and it dies.

Actually, I think we can break Derek’s observation into two parts, a micro and a macro argument.

At the micro level are lines of code and functions. I read Derek’s analysis as saying: at the function level code changes a lot at certain times. An awful lot of that change happens at the start of the code’s life when it is first written, refactored, tested, fixed, refactored, and so on. Related parts of the wider system are in flux at the same time – being written and changed – and any given function will be impacted by those changes.

While many lines and functions come and go during the early life of software, eventually some code reaches a stable state. One might almost say Darwinian selection is at work here. There is a parallel with our own lives there: during our first 5 years we change a lot, we start school, things slow down but still, until about the age of 21 our lives change a lot, after 30 things slow down again. As we get older life becomes more stable.

Assuming software survives and reaches a stable state it can “rest” until such time as something changes and that part of that system needs rethinking. This is Kevlin Henney’s “Stable Intermediate Forms” pattern again (also is ACCU Overload).

At a macro level Derek’s observation applies to entire systems: some are written, used a few times and thrown away – think of a data migration tool. Derek’s data has little to say about whether software lifetimes correspond to expected lifetimes; that would be an interesting avenue to pursue but not today.

There is a question of cause and effect here: does software die young because we set it up to die young or because it is not fit enough to survive? Undoubtedly both cases happen but let me suggest that a lot of software dies early because it is created under the project model and once the project ends there is no way for the software to grown and adapt. Thus it stops changing, usefulness declines and it is abandoned.

The other question to pondering is: what are the implications of Derek’s finding?

The first implication I see is simply: the software you are working on today probably won’t live very long. Sure you may want it to live for ever but statistically it is unlikely.

Which leads to the question: what practices help software live longer?

Or should we acknowledge that software doesn’t live long and dispense with practices intended to help it live a long time?

Following our engineering handbook one should: create a sound architecture, document the architecture, comment the code, reduce coupling, increase cohesion, and other good engineering practices. After all we don’t want the software to fall down.

But does software die because it fails technically? Does software stop being used because programmers can no longer understand the code? I don’t think so. Big ball of mud suggests poor quality software is common.

When I was still coding I worked on lots of really crummy software that didn’t deserve to live but it did because people found it useful. If software died because it wasn’t written for old age then one wouldn’t hear programmers complaining about ‘technical debt” (or technical liabilities as I prefer).

Let me suggest: software dies because people no longer use it.

Thus, it doesn’t matter how many comments or architecture documents one writes, if software is useful it will survive, and people will demand changes irrespective of how well designed the code is. Sure it might be more expensive to maintain because that thinking wasn’t put in but…

For every system that survives to old age many more systems die young. Some of those systems are designed and documented “properly”.

I see adverse selection at work: systems which are built “properly” take longer and cost more but in the early years of life those additional costs are a hinderance. Maybe engineering “properly” makes the system more likely to die early. Conversely, systems which forego those extra costs stand a better chance of demonstrating their usefulness early and breaking-even in terms of cost-benefit.

Something like this happened with Multics and Unix. Multics was an ambitious effort to deliver a novel OS but failed commercially. Unix was less ambitious and was successful in ways nobody ever expected. (The CPL, BCPL, C story is similar.)

In fact, this all starts to sound a lot like Dick Gabriel’s Worse is Better argument. Perhaps there is a pattern here.

Finally, what about tests – is it worth investing in automated tests?

Arguably writing test so software will be easier to work on in future is waste because the chances are your software will not live. However, at the unit test level, and even at the acceptance test level, that is not the primary aim of such tests. At this level tests are written so programmers create the correct result faster. Once someone is proficient writing test-first unit tests is faster than debug-later coding.

To be clear: the primary driver for writing automated unit tests in a test first fashion is not a long term gain to test faster, it is delivering working code faster in the short term.

However, writing regression tests probably doesn’t make sense because the software is unlikely to be around long enough for them to pay back. Fortunately, if you write solid unit and acceptance tests these double as regression tests.

Subscribe to my blog newsletter and download Project Myopia for Free

The post Most software dies young appeared first on Allan Kelly Associates.

AllanAdmin from Allan Kelly Associates

From time to time I come across software platform team – also called infrastructure teams. Such teams provide software which is used by other teams rather than end customers as such they are one step, or even more, removed from customers.

Now I will admit part of me doesn’t want these teams to exist at all but let’s save that conversation for another day. I acknowledge that in creating these teams organisations act with the best intentions and there is a logic to the creation of such teams.

It is what happens with the Product Owners that concerns me today.

Frequently these teams struggle with product owners.

Sometimes the teams don’t have product owners at all: after all these teams don’t have normal customers, they exist to do work which will enhance the common elements and therefore benefit other teams who will benefit customers. So, the thinking goes, coders should just do what they think is right because they know the technology best.

Sometimes an architect is given the power of product ownership: again the thinking is that as the team is delivering technology to technologists someone who understand the technology is the best person to decide what will add value.

And sometimes a product owner exists but they are a developer, they may even still have development responsibilities and have to split their time between the two roles. Such people obtain their role not because of their marketing skills, their knowledge of customers or because they are good at analysing user needs. Again it is assumed that they will know what is needed because they know the technology.

In my book all three positions are wrong, very wrong.

A platform team absolutely needs a customer focused product owner. A product owner who can appreciate the team have two tiers of customers. First other technology teams, and then beyond them actual paying customers. This means understanding the benefit to be delivered is more difficult, it should not be the case of ducking the issue, it should be a case of working harder.

If the platform team are to deliver product enhancements that allow other teams to deliver benefit to customers then it is not a case of “doing what the technology needs.” It is, more than ever, a case of doing things that will deliver customer benefit.

Therefore, platform teams need the strongest and best product owners who have the keenest sense of customer understanding and the best stakeholder management skills because understanding and prioritising the work of the platform team is a) more difficult and b) more important.

A platform team that is not delivering what other teams need does more damage to more teams and customers – in terms of benefit not delivered – than a regular team that just delivers to customers. Sure the PO will need to understand the technology and the platform but that is always the case.

So, to summarise and to be as clear as possible: Platform teams need the best Product Owners you have available; making a technical team member, one without marketing and/or product ownership experience, the product owner is a mistake.

The post The big mistake with Platform Product Owners and what to do about it appeared first on Allan Kelly Associates.

AllanAdmin from Allan Kelly Associates

“I’m frankly amazed at how far the #NoProjects throwaway Twitter comment travelled. But even today, in the bank where I work, the same problems caused by project-oriented approach to software are manifest as the problems I saw at xxxx xxx years ago.” Joshua Arnold

Once upon a time, 2 or 3 years back, #NoProjects was a hot topic – so hot it was frequently in flames on Twitter. For many of the #NoProjects critics it was little different from #NoEstimates. It sometimes felt that to mention either on Twitter was like pulling the pin and tossing a hand grenade into a room.

I never blocked anyone but I did mentally tune out several of those critics and ignore their messages. However I should say thank you to them, in the early days they did help flesh out the argument. In the later days were a great source of publicity. If we wanted to publicise an event one only had to add #NoProjects to a tweet and stand back.

And now?

There are at least 3 books on the subject: #NoProjects by Evan Laybourn and Shane Hastie, Live happily ever after without Projects by Dimitri Favre and my own Project Myopia, plus the companion Continuous Digital. (You can get Project Myopia for free by signing up to the email version of this blog.)

The hashtag still gets used but far less often, the critics have fallen back and rarely give battle and as I’ve said before #NoProjects won. But, as a recent conversation on the old #NoProject Slack channel asked: why do we still have projects? why does nobody activity say they do #NoProjects?

In part that is because No doesn’t tell you what to do, it tells you what not to do, so what do you do?

In retrospect we didn’t have the language to express what we were trying to say, over time with the idea floating around we found that language: Outcome oriented, Teams over Projects, Products over projects, Product centric, Stable teams and similar expressions all convey the same idea: its not about doing a project, its not even about doing agile, it is about creating sustainable outcomes and business advantage.

The same thinking is embedded in AgendaShift, “The Spotify Model”, SAFe and other frameworks. These are continuity models rather than the stop-go project model. One might call all these ideas and models post-project thinking.

In many ways the hashtag died because we found better, and less confrontational, language to express ourselves.

There was a growing, if implicit, understanding that this is digital not IT, it is about digital business, and that means continuity. The project model of IT is dead.

Which begs the question: why aren’t these approaches more widespread?

The thinking is there, the argument has been made against projects and for alternative models, and you would be hard pressed to find a significant advocate of agile who would argue differently but companies are still, overwhelmingly, project oriented.

When I’m being cynical I’d say, like agile, it is a generational thing. The current generation of leaders – or at least those in positions of management authority – build their success on delivering IT projects. Only as this generation relinquishes leadership will things change.

Optimistically I remember what science fiction author William Gibson once said:

“The future is here, its just unevenly spread around”

For digital start-ups this isn’t an issue: they are born post-project, they create digital products, the business and technology are inseparable. The project model is counter to their DNA.

Some legacy companies have consciously gone post-project and are recognising the benefits: the capitalist model suggests these early movers 9 risk takers – will gain the most. Other legacy companies have adopted parts of the continuous model but cling to the project model too, some will make the full jump, some, most?, will fall back.

Unfortunately Covid, the hang over of bail-outs from the 2007-8 financial crash and failure to break up monopolies (Google, Facebook, Amazon specifically) mean capitalism is not exerting its usual Darwinian force.

Projects will exist for a long time yet, #NoProjects will continue small scale disruption but in the long term the post-project organizations will win out. Hopefully I’ll be alive to see it but I have no illusion, the rest of my career will be spent undoing the damage the project model does.

The post What ever happened to #NoProjects? – post-projects appeared first on Allan Kelly Associates.