Category Archives: People

Shaping software development teams #3: autonomous teams vs. technical integrity of shared components

This is a follow-up to https://oliverbaier.wordpress.com/2019/03/06/shaping-software-development-teams-2/. Initial post at https://oliverbaier.wordpress.com/2019/03/02/shaping-software-development-teams/.

There are those day where I’m not sure why I bother writing. So I have tried—and failed—to provoke a discussion in this series of posts using quite a few words. Turns out, Simon Brown (of C4 Model fame) can do it in a single tweet:

Autonomous feature teams tend to weaken technical integrity of shared components

While the discussion on my blog isn’t happening, I hope that this Twitter thread will trigger an interesting discussion and yield valuable insights.

The service concept revisited #3: where are the people?

Johnston, Clark & Shulver write about the service concept mainly from the customers’ perspective. They also allude to relevant others (specifically, ‘business leaders’) when discussing the service experience, outcomes and operations. However, this only seems to be a subsidiary concern.

Their version of a service concept does a good job of summarising key aspects of a service in an informal manner — and I use it in this way. However, more structure is clearly needed when going beyond that informal summary.

We need to think about employees (more generally, service providers) first. If we take good care of employees, they will usually take good care of customers, too. So we need to think about the employee experience, outcomes for employees, and the value a service creates for employees as much as about the customer experience, outcomes and value.

But other people are involved in or affected by the service. These may include others in the organisation providing the service as well as people external to it such as investors. Furthermore, there may be regulators, the community the organisation operates in, and even society at large (think ecological or ethical externalities).

When thinking about customers (or clients), we ought to also think about non-clients and anti-clients. Tom Graves (2010, loc. 254-256) describes non-clients as “people who are not and will probably never be customers of ours, such as people who live in a different country than one we serve” and anti-clients as “people who don’t trade with us in the normal sense but who don’t like us or what we do”. (Also see Tom’s blog posts on anti-clients here.)

A good way of approaching this is creating a map of actors and their needs or stakeholders and their interests. See also Service ecology maps and the enterprise canvas on my old blog as well as Enterprise Design Framework: Big Picture on this blog.


A conversation with Tom Graves contributed to this post.


References

Graves, T. (2010) Mapping the enterprise. leanpub.com.

Johnston, R., Clark, G. & Shulver, M. (2012) Service operations management: improving service delivery. 4th ed., Pearson.

Johnston, R. & Clark, G. (2005) Service operations management: improving service delivery. 2nd ed., Pearson.

Not having all the answers

We thought that we had the answers
It was the questions we had wrong

 — 11 O’Clock Tick Tock, U2

I’m afraid I’ve been a bit of a disappointment to some of my clients and to some of my managers. Rather than dropping into a situation and having the right answer to the issue under discussion, I tend to ask questions. Many questions. Way too many questions. And it’s getting worse with age.

Why does he ask all these questions? Isn’t he an expert?

Truth be told, it hasn’t always been like that — but the result’s weren’t always pretty. I can provide an answer quickly even today, but this is probably not a good answer to your question. At least not to the question you should be asking.

I can’t know what that question is until we’ve had a good conversation. Even better, you might be able to decide what that question should be during or after our conversation. And while we’re at it you might be able to determine what a good answer to that question is, the one that considers the specifics of your situation — which you understand so much better than I ever could.

I’m with you all the way on this journey. I’ll try to ask smart questions, give you food for thought, identify issues and risks, but also opportunities, probably make some suggestions or recommendations. And I’ll tell stories about similar or related things that I’ve seen, of things that worked and things that didn’t.

We’ll explore a situation together and co-create insight.

I’m lucky that I meet more and more people — clients, managers, colleagues, partners — who value this approach.


Ruth Malan has a somewhat related Twitter thread right here.

Visual design, visual architecture, software architecture: Ruth Malan

As a software developer, software architect or anyone else who influences software, you’ll want to know about Ruth Malan. Ruth writes about software architecture and, particularly interesting, about visual design in the context of software architecture.

She runs renowned software architecture workshops with her husband Dana Bredemeyer.

Ruth has published tons of fabulous material. I think the links below make for a good start:

Ruth’s work is full of insights and — perhaps even more importantly — utterly enjoyable to read and work through.

Change mapping, tools for change: Tetradian on Patreon

I think you might be really interested in what Tom Graves (Tetradian) and Joseph Chittenden are doing on Patreon.

Their work is relevant for anyone involved in making change happen in organisations, i.e. you, me, regular people, and those in roles such as line managers, project managers, programme managers, product managers, product owners, system owners, business architects, enterprise architects, business analysts, software architects and so many others.

Beyond labelling

Project management is bad, product management is good. Estimates are bad, forecasts are good. Management is bad, leadership is good. MBAs are bad, MFAs are good. This is agile, that is not. This is lean, that is not.

Such focus on labelling and promoting one idea at the expense of another does not give me much these days. Instead, I am much more interested in learning about different schools of thoughts, hearing nuanced perspectives, and understanding in which context and for which purpose different traditions developed.

I am much more interested in attempts of integration, such as Jesse James Garret’s The Elements of User Experience: User-Centered Design for the Web and Beyond and Milan Guenther’s Intersection: How Enterprise Design Bridges the Gap Between Business, Technology and People, than any attempts of establishing one tradition’s superiority over all others.

This is also true for topics beyond technology, and perhaps even more important there.

We need all the help we can get if we want to deal successfully with the big and small challenges we are facing today. This means selecting our tools wisely and not rejecting potentially useful tools because of their origin or any label they may carry.

The Oath of Non-Allegiance promotes a similar view. I begin to wonder whether signatories (myself included) should be required to re-read it, reflect on it, an re-sign it if they still believe in it every quarter or so.

Lead architects and collaborative design

Brenda Michelson had this to say on Twitter yesterday…

..and all I had was a smartass response. Brenda shared a valuable idea.

Somehow “lead architects” rubbed me the wrong way…so let’s get rid off it:

Considering…

All architecture is design… —Grady Booch

…we can just speak of “lead designers” who need to know all the questions…or at least many…or know folks who know questions.

Let’s also include “lead developers” and lead whatevers in that description and use this broad definition of designer:

Everyone designs who devises courses of action aimed at changing existing situations into preferred ones. –Herbert Simon

With that out of the way, why do we need lead designers when we’re all subscribing to collaborative design? What does leading design mean in the context of collaborative design?

What if we considered a lead designer to be an expert who then should be considered a knowledge manager as described by Andy Grove in High Output Management? From this perspective, leading (managing) is then much less about making (design) decisions than about gathering & distributing information and influencing decisions (nudging).

Leading design would then become facilitating and supporting collaborative design, i.e. helping the group design and designing with the group. Leading would then become helping the group figure out whom to follow with respect to different issues. Leading would then mean ensuring that all voice have a chance of being heard, especially the quieter ones.

Leading design would then be about helping the network make better (design) decisions (hat-tip Harold Jarche via Lisa Sieverts).

Leading design then wouldn’t rub me the wrong way.

 

 

Courage

“Courage is not the absence of fear; rather it is the strength to overcome fear.”

Warfighting, United States Marine Corps

I’m about halfway through this little book. There is a lot of wisdom in there even for people like me whose profession is not war. In other words, if social interactions are your business, this book may well be worth reading.

Whole-of-system architecture

Tom Graves writes about whole-of-enterprise architecture, where the enterprise is far greater than any single organisation or even individual markets. Similarly, whole-of-enterprise architecture concerns go far beyond the technology domain.

When working at the scope of individual systems, I have realised that we can benefit from taking a similarly whole perspective: I suggest thinking in terms of whole-of-system architecture can be useful and, in my work, necessary. Software systems certainly play an important role in my work, but people play vastly more important roles. As do relationships between people, groups of people and various forms of organisations. Furthermore, we need to talk about processes and data. The list goes on an on.

Even when thinking only about the technology aspects of such whole-of-system architectures, we usually have to consider runtime (or deployment) architecture concerns, development-time concerns (form, function and structure of code) as well as the tools and processes for helping us to build, deploy and manage the technology components of the system.

Thinking about this further, we might consider a system in this broad sense to be a fractal element of a larger enterprise, and therefore, perhaps, a small enterprise in itself. Consequently, whole-of-enterprise architecture insights may well apply. If so, whole-of-system architecture can then be understood as a specific type of whole-of-enterprise architecture (i.e. one tied to the system scope).

Having gotten the above out of my system, I can now start to sort it out. Would you care to help?