Allan Kelly's Blog, page 48

Ameba Teams and Amoeba Management

I’m probably going to upset some people with my spelling here but as far as I can tell, there are two ways to spell the unicellular lifeforms most of use learn about in school: Amoeba and Ameba. I believe Amoeba is the more, shall we say, classical way of spelling the name but Ameba is also acceptable. I tend towards using Ameba because I’m lazy. On this occasion its useful to have two ways to spell the same word.

What, you might be asking, has all this to do with software development?

For a while now I’ve been talking about the concept of Ameba Teams. Specifically I talked about this in my Conway’s Law and Continuous Delivery presentation (SlideShare and an earlier version on recorded on Vimeo). In my model the team is a self-contained entity:

It contains all the skills necessary for under taking its task: developers, analysts, testers, what-ever.Ideally the team extends all the way into the business, there is no them-and-us divide.The team is responsible for its output. The team crosses the finishing line together - developers don’t win while testers lag behind, analysts don’t win while developers struggle too keep up, they win or loose together.Team and management should aim to minimise - even eliminate - dependencies on other teams.Work flows to the team.Teams start small and grow as they are seen to work.Initially teams may start understaffed, even with key skills missing, a Minimal Viable Team (MVT).A team contains more than 1 person (name me a sport where team size is 1 please). That probably means a team must have at least 3 people, but applying MVT the minimum size for a team is 2. (With the anticipation that it will either grow or die.)The team may work on more than one product or project at one time - actually the concept of project should be avoided if possible. See #NoProjects - why projects don't make sense and #NoProjects becomes #BeyondProjects.Everyone aims for team stability: yes people occasionally leave and join but we aim for a stable team.The team can grow when there is more work and contract when there is less work. Growing takes time if it is not to undercut the teams productive capacity so needs to be done steadily over time. Shedding staff can be done quickly it is difficult to recover capability after the event.The teams historic past performance is used as a benchmark and to judge (velocity) how much work the team can take on and even forecast end dates.

We start small and grow to work with, not against, Conway’s Law. If you start with a larger team, with more skills and roles defined in anticipation of what the team must then the software design is set by the team designers.

Although I don’t say “Ameba” explictly this is the thinking behind teams in Xanpan - and I promise to say more about Ameba teams in ‘Xanpan Volume 2: Management Heuristics” which I’ve now started work on.

Yes there is a tension, a friction, here: I say you want a fully staffed team but I then tell you to have an MVT. Life isn’t easy! You start with an MVT and if they can produce something useful you decide what other skills they need and add them when you find the need.

I’m happy for teams to grow relatively large, say up to 15 people. Because:

Larger teams can handle greater variability in workload and task variability and still have useful data.It is easier to justify full time specialists (e.g. UXD) on a larger team.Larger teams aren’t so susceptible to unexpected events (e.g. people leaving).Larger teams loose less of their capacity when they have a new person joining them.

Once a team gets to a critical mass, say 14 people, then the team - like the creature - should split in two. The two resulting teams need not be equal sizes but they should each be stand alone. Each should contain all the skill necessary to continue their work.

My thinking on team splits comes from reports of Hewlett-Packard I read a long time ago (and I’ve lost the reference). When a successful HP unit hit a particular size the company would split it in two so that each unit was manageable.

The tricky bit is finding where to split the teams. We need to respect Conway’s Law. Ideally each resulting team would have its own area of responsibility. So if a large team looks after three similar products they might split into two teams, say 5 and 9 people each with the smaller team taking responsibility for one product while the larger team retains responsibility for the other two.

What you must absolutely avoid is splitting the team so that one team now depends on the other. For example: one team is the UI team and the other the business logic. Shipping anything requires both to complete work. That means co-ordination, it means complication, it makes work for managers to do, it means expense and it means moving at the pace of the slowest team.

The ideas behind Ameba Teams have formed over the years in my mind. In fact I started using the expression several years ago. So when, nearly two years ago, I came across someone else describing Amoeba Management I was a little crestfallen. Fortunately the ideas are compatible and I’ve recently gone back and re-read the article. It therefore seems the right time to bring it to the party. (I’m sure the article has influenced my thinking since I originally read it too.)

Amoeba Management: Lessons from Japan’s Kyocera appeared in the Sloan Management Review in late 2012 - you can buy the article from Amazon too. You can find more information about it both on Wikipedia and on Kyocera’s website. And there is a book I’ve yet to read: Amoeba Management: The Dynamic Management System for Rapid Market Response.

According to the Kyocera website the objectives of Amoeba Management are:

“Establish a Market-Oriented Divisional Accounting System: The fundamental principle for managing a company is to maximize revenues and minimize expenses. To implement this principle throughout a company, the organization is divided into many small accounting units that can promptly respond to market changes.Foster Personnel with a Sense of Management: Divide the organization into small units as necessary, and rebuild it as a unified body of discrete enterprises. Entrust the management of these units to amoeba leaders in order to foster personnel with a sense of management.Realize Management by All: Realize "management by all," where all employees can combine their efforts to participate in management for the development of the company, as well as work with a sense of purpose and accomplishment.”

They look very compatible with everything in Agile to me, they look compatible with Conway’s Law and Continuous Delivery too.

Some other highlights from the MIT Sloan Management piece

“Kyocera is structured as a collection of small, customer focused business units”“Each unit, generally made up of between five and 50 employees, is expected to operate independently and to develop its own ways of working with other amoebas to achieve profitable growth.”“Like other decentralized management systems, amoeba management is designed to spur market agility, customer service and employee empowerment.”

There is also some hints at Kyocera’s accounting systems. They use a simplified system for transparency and leave details to teams. While this is a long way from Beyond Budgeting it does suggest, like Beyond Budgeting, that sophisticated long range budgets get in the way for actual performance.

The article does point out that Amoeba Management, indeed any management approach, depends on the context. This is an important point that is often missed by Agile-folk, although one may forgive them as long as they confine their believe to software teams where there is a lot of shared context.

Rather than go on about Amoeba Management right now I’ll let you read about it yourself - although that will cost, the article and the book. Although right I promise to return to this subject in the near future.

Right now let me conclude with two thoughts.

Ameba Teams (my ideas) share a lot in common with Amoeba Management (Kyocera), my thinking has been influenced by Amoeba Management but frankly I don’t know enough about them (yet) to speak with authority so I retain the right to define Ameba Teams in my own terms.

While Agile and Lean people have been watching Toyota (the company that gave us Karōshi, death by overwork) another Japanese company has some interesting ideas we should consider.

Loose ends: Continuous Delivery & Conway's Law

A few weeks ago I did a presentation entitled “Conway’s Law and Continuous Delivery” - although it was also at some point entitled “Conway’s Law and Organisational Change” or possibly “Conway’s Law and Change for Continuous Delivery” - to the Pipeline Conference in London.

The presentation was very well received at the time and I spent most of the next hour talking with people who wanted to talk about the presentation. One tester came to be later and said “Thank you, I understand what I’m doing now, I’m testing the organisation.”

Since then the presentation has had a lot of interest on Twitter and on SlideShare - at one time it made the front page of SlideShare (my 15 minutes of fame I guess).

I should say I took a slight liberty with the “organisational change” bit. I didn’t so much describe how to bring about organisational change as describe how the organization might (even should) change to align itself with Conway’s Law. Sorry about that, I don’t have a potted “how to change your organisation” recipe (although if you want to call I’m available for hire!)

Actually the Pipeline conference was the second time I’d made this presentation. The first outing was for the London Continuous Delivery group and hosted at the Financial Times. If you missed these two outings the good news is that the FT delivery was recorded and is available on Vimeo. This presentation is also on SlideShare but isn’t significantly different from the Pipeline version.

(Personally I feel that was the better of the two presentations but others have told me the second was the better, perhaps what the second lacked in raw freshness was more than made up for in being a little more polished and debugged.)

I’m really grateful to Matthew Skelton, Steve Smith and Chris O’Dell who are the people behind both London Continuous Delivery and Pipeline. Although I’ve known about the idea of continuous delivery for a while I know much more and I’m really excited by it.

They have also furnished me an opportunity to revisit Conway’s Law. Nearly 10 years ago I ran a workshop exploring Conway’s Law at EuroPLoP 2005. Both my co-organizer and I learned a lot, in fact the fuss about our write up rambled on for a couple of years - I’m not going to reopen that here and now. (The full report “What do we think of Conway’s Law now?” is available for download from allankelly.net.)

Ever since then one of my mental models has been the organisation structure is the software architecture, I may no longer change code but by changing organizations I am practicing software architecture.

Right now my head is buzzing with thoughts on Continuous Delivery, Conway’s Law, Team Structure, Scaling Agile and how this all fits with the Beyond Projects / No Projects agenda. I feel that if I can just make sense of all this I’m on the verge of some great breakthrough!

Software Developmers: prototype of future knowledge workers?

‘‘Knowledge work is not easily defined in quantitative terms, . . . To make knowledge work productive will be the great management task of this century, just as to make manual work productive was the great management task of the last century.’’ Peter Drucker (1969)

In recent months I have repeatedly been reminded of an argument, or perhaps a hypothesis, I advanced in my 2008 book Changing Software Development. In the introduction chapter I suggested that software developers might be regarded as the prototype of future knowledge workers. I’ve republished “Prototype of Future Knowledge Workers” as a blog post yesterday.

I’ve been reminded of this in a number of casual conversations recently, like the one I had with Laurie Young (@wildfalcon), again when rereading some Peter Drucker and because of media pieces like one in the Financial Times (“Do it like a software developer” by Lisa Pollack) suggesting that companies with successful software development teams might have something to teach other companies, and also by the topics submitted to the Agile on the Beach conference.

Let me explain, firstly let me explain why I make this argument, then let me explain the significance - and with reference to Agile - and finally, for completeness let me quote from the book…

Software Developers - programmers, testers, and everyone else - are what academics would call knowledge workers. We work with our brains rather than our brawn. We generate value because of what we know and what that knowledge allows us to do.

There are lots of other knowledge workers, teachers, lawyers, doctors, and during the twentieth century the number of knowledge work professions and number of knowledge workers grew.

In many ways software developers are no different, but in one very important ways they are very different. Software developers are able to create new tools for machines which allow them to change the way they do knowledge work.

Think about some of the tools your common knowledge worker uses during the typical day:

E-mail: invented by Ray Tomlinson, a programmerSpreadsheets: invented by programmers Dan Bricklin and Bob FrankstonThe Web: invented by programmer Tim Berners-LeeWiki sites: invented by programmer Ward Cunningham

Even if Twitter, FaceBook, Video conferencing, Voice over IP and countless other knowledge sharing and collaboration technologies were not invented by programmers I will bet good money on one common factor: software developers, programmers, had early, if not first access to these technologies. That is very very significant.

Lets be clear:

Unlike other knowledge workers software developers have the ability to create new tools which can change their work.Software developers have early, if not first, access to tools which benefit knowledge work.

One might also add that people working with technology welcome and embrace new tools and technologies (on the whole) so the barriers for technology change are lower.

This means those working in software technology - and particularly those developing software - have more experience and most history of using these tools, and consequently are the likely to be the most adapted to working with these tools.

Thus if you want to see how new technologies, new tools, will change knowledge work look at those who create the tools and those closest to them. This shouldn’t be a surprise, after all knowledge work is about managing and using information, and these technologists create the tools we use to store, retrieve, manage, manipulate, combine, and share information.

(And there is a difference between knowledge and information but I’m not going into that here, its in the book.)

By itself this argument is interesting and perhaps good for developer self-esteem. We could leave it there but…. it also begs a question:

If software developers are the prototype of future knowledge workers what does it suggest will happen next? Specifically, how can this insight help answer the challenge posed by Peter Drucker above?

As a step towards answering those two questions let us rephrase the question:

What are software developers doing today which might benefit other workers? Or to put it in Drucker’s language: what can managers of non-software staff learn from software teams which will make their teams more productive?

One way would be to look at the tools software developers are using today which might benefit other groups.

Version control springs to mind but version control has existed for at least 30 years and hasn’t caught on with the masses. We could continue to examine the toolset, one of my favourites is Markdown. Or we could look at the way software developers are managed. This was the thrust of the FT piece which looked at personnel management (I refuse to say HR) practices.

But there is something else… Agile itself.

One of the reasons I believe Agile came about was that the tools we use changes. Cobol gave way to Java which gave way to Ruby. OS/360 gave way to VMS which gave way to Windows (or was it Unix?) which gave way to Unix derivatives. One might say paper gave way to the web and wiki’s, telephones gave way to VOIP, telegraphs gave way to Twitter.

Our tools changed which allowed - even forced? - our processes to change. As knowledge workers outside of IT embrace these these tools its possible that their working practices will change in a similar way. My favourite example is a presentation given by Kate Sullivan at Agile on the Beach two years ago in which she described how the legal department at Lonely Planet adopted Agile.

There are several Agile practices which area are easier to imagine outside of software than others. For example:

Visual boards: lots of places!Standup meetings: example abound and usually predate Agile, e.g. bar staff, Japanese office workers, NATO commanders (in Bosnia and probably elsewhere)Test driven working: consider many of the business examples from Lean Start-UpPair programming: airline pilots and surgeons have been doing this for a long time but Kate added Pair LawyeringIterations: although I’ve yet to get a concrete example most news organizations clearly operate in daily iterations

During the second half of last year I was involved with a client whose project was to write documentation. Specifications to be precision but not specifications for software - there was an element of that but that was not the aim. We used iterations, visual board and other techniques. We even used a walking skeleton. It worked. We delivered to schedule.

We in software have developed something good. Something that is spreading beyond software. Now I wonder, whats next?

The Prototype of Future Knowledge Workers

The following is an except from my 2008 book “Changing Software Development: Learning to be Agile”. I’ve been thinking about this suggestion a lot recently and have a blog post in the works. Hence I thought now would be a good time to share this, it also means I can reference this post in the one that comes next… and who know, I might even rustle up a few sales for the book!

The Prototype of Future Knowledge Workers

Highlighting IT workers as knowledge workers allows us to learn from the existing body of knowledge on the subject. IT workers are not alone; they are knowledge workers and there’s much to learn from other knowledge workers, and from research and literature about knowledge work in general. There’s no need for IT managers (and writers) to re-invent the wheel.

Yet, in another way, the existing literature, research and experience can’t help IT workers and their managers. This is because IT workers, and software developers in particular, are at the cutting edge of knowledge work. In many ways, they’re the prototype of the future knowledge worker; they’re pushing the boundaries of twenty-first century knowledge work.

This occurs because, to paraphrase Karl Marx, software developers control the means of production. Modern knowledge work is enabled by and dependent on information technology: e-mail for communication, web sites for distribution, databases for storage, word processors for writing reports, spreadsheets for analysis – the list is endless! These technologies are created by software developers and used by legions of knowledge workers worldwide. The key difference between software knowledge workers and the others is that other knowledge workers can only use the tools that exist. If a tool doesn’t exist, they can’t use it. Conversely, software developers have the means to create any tool they can imagine.

Consequently, it was a programmer, Ward Cunningham, who invented the Wiki. Programmers Dan Bricklin and Bob Frankston invented the electronic spreadsheet. Even earlier, it was another programmer, Ray Tomlinson, who invented inter-machine e-mail. This doesn’t mean that non-programmers can’t invent electronic tools. Others can invent tools, but for programmers the barriers between imagining a tool and creating the tool are far lower.

Lower barriers mean that programmers create many more tools than other types of worker. Some tools fail, while others are very specific to a specific problem, organization or task in hand, but when tools do work it is programmers who get to use them first. In addition, because IT people have had Internet access for far longer than any other group, the propensity to use it to find tools and share new tools is far greater. So tools such as Cunningham’s Wiki were in common use by software developers years before they were used by other knowledge workers.

Early Internet access has had other effects too: IT workers were early adopters of remote working, either as individual home workers or as members of remote development teams; IT people are far more likely to turn to the Web for assistance with problems and more likely to find it, because IT information has been stored on the Web since the very beginning.

The net effect of these factors and others means that software developers are often the first to adopt new tools and techniques in their knowledge work. They’re also the first to find problems with such tools and techniques. Consequently, these workers are at the cutting edge of twenty-first century knowledge work; they are the prototype for other knowledge workers. Other knowledge workers, and their managers, can learn from the way in which IT people work today, provided that we recognize these workers as knowledge workers.

From “Changing Software Development: Learning to be Agile” by Allan Kelly, 2008.

Notes to students doing research about Agile

The dissertation/thesis writing season is approaching so I expect the recent set of questions from a student is the first of many. Actually they occur all year round but March to September is the busy period. So, to pre-empt any students bearing questions about Agile - and so I can just repeat my stock answers - here are some ideas you might want to consider first.

Lets start with the request itself.

I and many other people who are silly enough to write and blog about Agile software development get plenty of e-mail from students doing research on Agile. Fair enough, I like to help but if you don’t ask nicely I’m unlikely to respond.

I won’t be answering stock surveys that are sent from a mail program.I’m much more likely to answer a personal request which indicates you actually know my name and even read some of what I have written.

I’m skeptical of most quantitive research (e.g. surveys) research on Agile simply because the question that I normally see are rubbish. Qualitative research is probably better but

It is not as satisfying as quantitive, you can’t conclude “58% of teams use Agile” you come up with some wishy-washy case studies You actually have to go and talk to people, you can’t just compile a mailing list and feed it into Survey Monkey. That means getting out and finding people to talk to

If you must go down the quantitative route please do your homework, do some qualitative before you begin so you can ask good questions.

Now the number one mistake made by students who approach me is: Assuming there is such a thing as Agile.

That is to say assuming:

one is either Agile or not Agile,secondly: one knows that one is, or is not Agile andthirdly: one is prepared to openly and honestly state it.

Agile is not binary. Nor for that matter is Waterfall. While we are about it Agile and Waterfall are not necessarily binary alternatives. Have a look at my Agile Spectrum article: the thing that is called “Agile”, and the thing that is called “Waterfall” are simply points on a spectrum - probably the two extremes - and most teams are somewhere in-between.

Nor is there anyway (at the moment) to objectively determine where a team is on the spectrum. Well actually there are plenty of people who will do an assessment of one sort or another but you have to look at what criteria they are using. My suggestion is get away from Agile as a whole and look at Agile practices.

Likewise get away from the methods - Scrum, XP, Kanban, etc. If you must look at different methods look at them in the context of practices. Agile methods are sets of practices, sometimes with values and principles thrown in.

Practices are the easiest of these things to observe and measure. They are objective, the other bits are subjective.

If you really want to dig deep - and make work for yourselves - you might want to investigate team values - do teams actually value the things Agile claims to value? This is going to take some doing. You probably want to look at what actually happens, shadow a manager for a week and see if their decisions accord with the values.

You might do it quantitatively by composing one of those surveys that asks people to choose between answers, e.g. “Under pressure to ship more often which are you most likely to do: a) make your stories smaller, b) offer financial incentives to the team, c) reduce unit testing, d) increase unit testing”.

Now some suggestions for some research, Agile research questions:

Validate my spectrum: its a hypothesis, come up with some criteria and do a survey to see if you can determine the spreadPractices: what are the practices that teams actually use? Specifically, what are the practices they say they use and which ones do they actually use?Which practices are the most popular?What difference do the practices make?How does Agile differ between product development companies and corporate IT? Add “solution providers” (e.g. Accenture, EDS, CapGemini and thousands of smaller companies) for extra marks.Correlation of practices to approach: do teams which call themselves Agile actually use practices associated with Agile? And likewise for Waterfall. A couple of years ago a student at Loughborough University, Adam Williams, rose to my challenge. He tried this, his survey was small, 20-odd companies, and he found little correlation at all. In fact he found some teams who described themselves as Waterfall but used several Agile practices. I would love to see this study expanded.What do Scrum Masters really do and how are they different from Project Managers?What are the recruitment practices of Agile teams and companies?Forget Agile, look at Waterfall, find teams who actively claim to do Waterfall and find out what happens, how do the unsuccessful ones differ from the successful? Are there any successful waterfall teams?Examine some of the more controversial practices: TDD, pair programming, refactoring. Do a meta-analysis of the studies to date or do your own studies.Extend Keith Briathwaite’s work the correlation between TDD and cyclomatic complexity.TDD, benefits and the power law - I should blog about this but for now just take my word for it.

Finally the big one.

Real Agility is not about methods, practices or names, it is the state of being Agile. (Something that was meant to be in the title of my first book but was messed up.)

What is the state of Agile? - in theory and in realityWhat advantage does the state of Agile confer?

So if any student out there wants to raise to the challenge on these questions please get in contact, I’d love to help and to see the final research.

#NoProjects becomes #BeyondProjects and online

On Monday night I delivered a talk at Skills Matter in London entitled “Beyond Projects: or the end of projects and what to do about it.” This was the latest evolution of the #NoProjects meme being advanced by Steve Smith, Joshua Arnold and myself.

Steve, Joshua and I have been thinking that #NoProjects is a bit negative and something like #BeyondProjects would be more positive but we didn’t reach a final decision. Having read some of the Tweets after Monday I’ve decided.

#NoProjects is now #BeyondProjects - that also sidesteps the problem of teenagers on Twitter using the first of those hashtags to denote the end of their coursework.

The talk was well received and I’ve got mails and conversations to follow up.

The #BeyondProjects slides are now online at Slideshare and Skills Matter have published a video of the talk.

If you want to know more about this see my blog last year "Beyond Projects, Beyond #NoProjects” see too Steve’s past blogs and Joshua’s blogs, particularly “The Problem with Projects.” What is really interesting is Steve, Joshua and I all started rethinking projects from different points of view.

My thinking originated with the cognitive dissonance that exists because successful software doesn’t end but projects do. I think projects don’t make a good model.

Steve comes from a continuous delivery point of view.

And Joshua emphasises risk and value more.

Gradually these three points are being woven into one story.

 

Xanpan update

As regular readers will know I have been working on a new book, or rather a new ebook called Xanpan. Indeed, since I am using the LeanPub system some people are now reading the book.

The content in this volume stabilised a few months ago but as always my English is a little eratic. The book needed a professional copy edit - indeed even better writers than I have their books professionally copy edited. This was done a few weeks ago but I’ve only now been able to complete all the other changes.

So today I am proud to announce a new version of Xanpan.

I would like to offer readers of this blog a buy the book at a discount, half the recommended price. If you follow this link to Xanpan on the LeanPub site or enter the code “BlogMarch2014” when buying the book the price will be reduced. These discounts should be good until the end of next month.

(I’m sorry, LeanPub works in US dollars so although most readers of this blog are in places which are not the USA, particularly the UK, I have no choice.)

Apart from the copy edit the most significant change is I’ve changed the subtitle from “Personal reflections on agile software development” to “Team centric software development.”

While this book still contains my reflections - and sense making - on the development process, and particularly agile, the feedback I had from several people suggested that Xanpan differs from other methods by its emphasis on the team.

I expect the team centric aspect to be more noticeable in a second volume I plan to write “Xanpan: Management heuristics”. And I have a thought for a third volume “Xanpan: Requirements” but not for a while yet.

The next task is to make this version of Xanpan available as a hard copy. That should happen in the next few weeks.

In the meantime, if you have any comments or feedback please let me know.