Allan Software Strategy

Patterns for Highly Autonomous Teams & Team Energy Theory

Agile / / / , , , ,

A treat for those who like a longer read, two new papers. Both of these come from this summer’s EuroPLoP 2024 conference. As with all my other patterns papers these are on my website.

Patterns for Highly Autonous Teams

The first, Patterns for Highly Autonomous Team is a joint work with Tsvetelina Plummer and gives three patterns for, well, highly autonomous teams:

  • Autonomy over Money
  • Everyone a Manager
  • Simple Financial Reports

In addition to the patterns the paper contains a long pre-amble on the nature, naming and history of autonomous team – which also explains why the terms “self-organizing team” and “self-managing team” may not be the best.

Perhaps controversially the pre-amble also described why management and leadership are in not different things but, in fact, inseparable.

The patterns themselves seek to recast existing ideas in the pattern form supplemented by our own observations and additional examples. The origins of the paper was a desire to writer and research Autonomy over Money. When we went looking for new case studies we got two surprises. First, there were fewer examples to find than we expected – although they certainly do exist. Second, most of the examples we found were outside of technology and software development in particular.

So, read the paper and let me know what you think.

Team Energy Thoery

Second up is a write up of a focus group discussion of little theory which I’ve had for some time. To explain, let me quote from the paper:

“Team Energy Theory proposes using the metaphor of energy to describe team work. Specifically, TET explores how the rules of energy can be used to describe team work.

This paper describes a workshop which explored the theory. The workshop decided the theory was useful and provides some insight. It was agreed the model could be usefully applied with other groups to discuss what made for an effective team and how less effective teams came to be.

Several parallels were explored, e.g. natural tendency to minimise energy expenditure, and several more were identified for further exploration, e.g. the different forms of energy and conversation of energy between these forms.”

Again get in touch if you have any questions or would like to continue the discussion.

Both these papers best thought of as late drafts. They will officially be published as part of the ACM Digital Library proceeding of EuroPLoP 2024 in the coming weeks. However, I prefer these versions because the font and layout make them much more readable. (It is beyond me how anyone can read the ACM format.)

Patterns for Highly Autonomous Teams & Team Energy Theory Read More »

Help – a survey about product leaders

Agile / /

I’m running a little survey – 5 minutes of your time – about the people and roles who decide what should be done, or perhaps what should be built. The people who are often called Product Owners or Product Managers, and often Business Analysts, perhaps Requirements enigneers or… a myriad of other titles. I’m generically calling these people Product Leaders or Product Authorities.

Anyway, if you can spare me 5 minutes it would be grate to have your answers – survey is here, just a few questions.

Help – a survey about product leaders Read More »

Fixing agile failure: collaboration over micro-management

Agile, Management / / / , ,

I’ve said it before, and I’m sure I’ll say it again: “the agile toolset can be used for good or evil”. Tools such as visual work tracking, work breakdown cards and stand-ups are great for helping teams take more control over their own work (self-organization). But in the hands of someone who doesn’t respect the team, or has micro-management tendencies, those same tools can be weaponised against the team.

Put it this way, what evil pointed-headed boss wouldn’t want the whole team standing up at 9am explaining why they should still be employed?

In fact, I’m starting to suspect that the toolset is being used more often as a team disabler than a team enabler. Why do I suspect this?

Reason 1: the increasing number of voices I hear criticising agile working. Look more closely and you find people don’t like being asked to do micro-tasks, or being asked to detail their work at a really fine-grained level, then having it pinned up on a visual board where their work, or lack of, is public.

Reason 2: someone I know well is pulling their hair out because at their office, far away from software development, one of the managers writes new task cards and inserts them on to the tracking board for others to do, hourly. Those on the receiving end know nothing about these cards until they appear with their name on them.

I think this is another case of “we shape our tools and then our tools shape us.” Many of the electronic work management tools originally built for agile are being marketed and deployed more widely now. The managers buying these tools don’t appreciate the philosophy behind agile and see these tools as simply work assignment and tracking mechanisms. Not only do such people not understand how agile meant these tools to be used they don’t even know the word agile or have a very superficial understanding.

When work happens like this I’m not surprised that workers are upset and demoralised. It isn’t meant to be this way. If I was told this was the way we should work, and then told it was called “agile” I would hate agile too.

So whats missing? How do we fix this?

First, simply looking at small tasks is wrong: there needs to be a sense of the bigger thing. Understand the overall objective and the you might come up with a different set of tasks.

Traditionally in agile we want lots of small work items because a) detailed break down shows we understand what needs to be done, b) creating a breakdown with others harnesses many people’s thinking while building shared understanding, c) we can see work flowing through the system and when it gets stuck collectively help.

So having lots of small work items is a good thing, except, when the bigger thing they are building towards is missing and…

Second, it is essential teams members are involved with creating the work items. Having one superior brain create all the small work items for others to do (and then assign them out) might be efficient in terms of creating all the small work items but it undermines collaboration, it demotivates workers and, worst of all, misses the opportunity to bring many minds to bear on the problem and solution.

The third thing which cuts through both of these is simple collaboration. When workers are given small work items, and not given a say in what those items are, then collaboration is undermined. When all workers are involved in designing the work, and understanding the bigger goals, then everyone is enrolled and collaboration is powerful.

Fixing this is relatively easy but it means making time to do it: get everyone together, talk about the goals for the next period (day, week, sprint, whatever) and collectively decide what needs doing and share these work items. Call it a planning meeting.

The problem is: such a meeting takes time, it might also require you to physically get people together. The payback is that your workers will be more motivated, they will understand the work better and are ready to work, they will be primed to collaborate and ready to help unblock one another. It is another case of a taking time upfront to make later work better.

Fixing agile failure: collaboration over micro-management 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 »

Naked Objects and ACCU London January 2010

Agile / / / 1 Comment

I am very excited about the next ACCU London meeting when Dan Haywood will be speaking about Naked Objects. The meeting is open to all and is free, just check the ACCU website for details.

I’m excited about this talk because Naked Objects is one of the few technology based approaches to software development which I think holds real promise for better development. This is because the Naked Objects philosophy is based on a very different approach to most software development. Rather than view the end user as some kind of inconvenience Naked Objects treats them as a problem solver who wishes to solve something.

I read the original Naked Objects book by Richard Pawson and Robert Matthews a few years ago and the idea has been with me ever since (I reviewed the book in an earlier blog entry). Its the difference between treating users as adults and not children to my mind. Rather than the designers defining processes in the software they give users the tools to resolve the issues their customers raise. This approach respects the person using the software. It moves the conversation from business processes to customer service; and it fits far better with piecemeal growth over big-bang change.

Dan has just published a new book on Naked Object, Domain Driven Design Using Naked Objects and I’ve been lucky enough to have a sneak preview. This is the first technical book (i.e. one with lots of code) I’ve read for a while and I enjoyed it. So here is potted review… Dan sets out to explain the Naked Objects framework. Yes, Naked Objects is not just a philosophy it is the framework too. No need to invent the wheel, here it is; and it seems that framework has matured quite nicely.

He is passionate about his subject, I’m almost itching to download this stuff and start coding myself – arhh, if I could only prioritise coding for fun above the other things going on in my life. The writing is very clear and to the point with a little bit of humour. His instructions for getting the environment set up for the example code and case study is clear.

There are plenty of code samples and screen shots to illustrate what is going on which is nice but… On the downside the book is nearly 400 pages long which means it yo are unlikely to carry it around much. I read a PDF version so I didn’t suffer too much.

I sometimes seem to be the only person I know who has not read Eric Evan’s Domain Driven Design book. Initially I thought I might be at a disadvantage reading Dans book but he explained just enough to get me through. Indeed, I’m now intrigued and plan to get a copy of the DDD book.

Sometime ago I asked Steve Freeman “Whats all the fuss over domain driven design? What is it?” to which Steve said: “Its about doing objects correctly, the way we should have been doing them all along.”

Everything I’ve learned about domain driven design since then fits with Steve’s description. It seems to me that domain driven design and naked objects were made for one another so I’m glad to see Dan’s book.

Naked Objects and ACCU London January 2010 Read More »

Another month, another book -The Living Company

Agile / / / 1 Comment

Sitting on planes is boring, one of few advantages is that gives you a chance to read, and so it is that idea to read yet another book. This time the book is “The Living Company” by Arie de Geus – 1997, Nicholas Bealey Publishing.

This is a very good book, as one might expect from the title its thesis is that companies resemble living organisms. As a living thing the primary objective of the company is not to make profit but to survive. Profit therefore is not an end in itself but merely a means to an end, for without profit there firm cannot survive.

Arie de Geus is the author of a well-known Harvard business review article entitled “Planning As Learning” – if you have not read this it is well worth the $6.

As one might expect this book expands on this theme, the important point about planning is not produce a schedule that allow individuals to consider possible scenarios so that their thinking goes beyond a mere projection of the past.

Continuing on from this he argues that everyone affected by a decision should be involved in the making of the decision. On the face of this might appear to slow down decision-making process that is not the case. Because making a decision is only half the story, what is the key is made in the acting upon by involving more people in the decision-making process we ensure that action happens sooner.

It was only as I came towards the end of this book of the obvious occur to me. As regular readers of this blog will know I write Patterns, the originator of patterns, Christopher Alexander, calls on us to create patterns that live, in the same way Arie de Geus callers are those to create companies that live. To my mind there are obvious parallels here and further validate the use of patent theory when considering the business domain. Hopefully I’ll explore these parallels further in future patterns that are.

Another month, another book -The Living Company Read More »