Behind the Scenes at Global-Roam

I know that someone recommended I read this one – I apologise for forgetting who it was!  Was it you, Justin?

I read this book as it claimed to answer some questions I had been pondering along the lines of “what’s this AGILE thing all about?” .

Shane’s review helped, but I still had loads more questions – as a result of which we loaded up our Amazon cart with quite a few books on the topic, of which this is the first I have reviewed.

1)  Binary Review

This book is written as a fictional tale of two separate software development projects within the same large company – one using “Lean and Agile” Software Development, and one using a more traditional (e.g. waterfall) approach.

The Book	What we thought
“A Tale of Two Systems”by Michael K Levine	. Useful (and very timely for us)!

Full Disclosure – yes, that’s a tracked link to Amazon shown above. We buy quite a large number of books on a wide range of topics, all relevant to our business in some way.  If you did happen to purchase the book from Amazon, they’d throw a few shekels our way, which would help us to buy (and hence publish reviews of) even more books.  Hence, Karma would return the benefits to you…

.

As a novel, this book certainly does NOT qualify as “Un-Put-Down-Able”.

In fact, I basically read the book in two spurts, with many weeks separating the two halves as the prose just bored me senseless.

Hence, if you are looking for a bit of suspense, mystery, drama, or perhaps even romance, pass this one up.

However, if you are curious (like I was) about what’s the substance behind the latest buzzwords (this time in the software domain), then the book was useful, and has included some very helpful take-away summaries at the end of each chapter.

Apologies, in advance, for what has turned out to be a lengthy post (the book was certainly good enough to stimulate this much thought for me) …

.

2)  Need to “Get” the Paradigm Shift

Central to this book is a paradigm shift that the reader has to make in order to understand what is being said.

I gather it is to try to assist in this paradigm shift (Jesus spoke in parables, yada yada…) that the author has penned this book in this manner.  Perhaps it is just because I was already (always?) thinking along these lines I found the story a little tedious.

Nevertheless, it is an essential concept to grasp, so here’s my shot (note – I know it’s not as simple as the picture I paint):

(a)  When talking about Cars

The book makes numerous references to Toyota (as, after all, they are held up to be the showcase of Lean Manufacturing techniques).  The important distinction to get is this:

(a)  When Toyota wants to design a new car, there are a large number of uncertainties that they have to deal with.  Because of these uncertainties, Toyota does not know WHAT the outcome will be or even WHEN it will arrive.  Speaking literally, they won’t even know for sure IF they will arrive at a product that does everything they want it to do – though, based on their track record they might have some confidence.  As a result, Toyota adopts a flexible process (more based on people than on rigid structures or procedures) to produce a good design at the end.

(b)  When it comes time to manufacture that same car (once basically designed), there is much less uncertainty involved and, as a result, the people at Toyota can use techniques like [Insert Latest Buzzword Here – like TQM or Six-Sigma] to drive out waste and inefficiency, etc…

Keys to understanding the above are that design and manufacture are very different processes, with greatly varying degrees of uncertainty, and hence a markedly different approach required to achieve greatest effect.

(b)  When talking about Power Stations

Back in our domain, the same contrast holds true:

(a)  When engineers are trying to design a wholly new process, there are a large number of uncertainties that they have to deal with.  Currently the industry has a number of these, such as:
i.  Carbon capture and storage
ii.  Pump-primed geothermal power
iii.  Large-scale solar thermal
iv.  Nuclear fusion
v.  Distributed, “embedded” fuel cells
– as engineers, we have no idea IF initiatives like these will even ever work (at least on a commercially feasible level).  By definition, a significant number of these types of (experimental) projects will fail.

As a result, the engineers working on projects such as ZeroGen would need to adopt an approach centred around having a number of supremely capable people in the team.

(b)  For existing technology, however, a manufacturing paradigm is somewhat more applicable.

For instance in QLD in the 1990s the approach was taken to standardise on 10 x 350MW Hitachi gensets for various reasons all stemming from the desire to reduce capital and O&M costs in these stations.  The same approach was taken in NSW and VIC (the names and sizes vary).

The main point here is that, under these scenarios, the construction phase could be more regimented.

That’s not saying that there were not uncertainties (and VM studies were one tool used to alleviate these) – it’s just saying that the uncertainties were fewer relatively speaking – hence allowing planning to become more structured.

(c)   When talking about Software

This brings us to the book, and its fundamental premise:

(a)  Many software projects are one-off developments which, by definition, contain many uncertainties.  As such, a design–based methodology (which is based more on people than processes) is more likely to provide a greater chance of success (the book uses the term “empirical process control” to refer to the plan-do-check-adjust methodology). .

What is uncertain?

At this point, it is important that I digress for a minute.

In most of what I have read about software development, the focus on uncertainty all revolves around the technologies used (languages, platforms etc…).  As we have learnt from experience, these are certainly core considerations.

Our business model is such that we aim to recover costs (and hope to profit) over numerous clients and multiple years of licence fees.  Hence, from our point of view, what’s even more important (in terms of uncertainty) is that we don’t know, in advance, how our products will be received.  It’s simply not possible to conduct an all-encompassing “market research” study, though there are things we can (and do) do as initial steps.

Given this greater range of uncertainty than might be the case on other software projects (e.g. for a single client, with funds committed up-front) it is even more important (essential) that we follow a more design-based development methodology.

Hence our need to utilise Lean/Agile…

In the book (p9) the following point is made:

“… in software development… we aren’t as good at understanding and writing out all the requirements and designs before beginning to build … we need to accelerate learning as much as we can. It’s normally much more effective in software development to get the overall architecture and a high-level plan in place**, and then do requirements, design, build and test in iterative phases, adjusting as we go along.”

(b)  In other types of ICT projects, which are more based on the roll-out of standard software, a manufacturing paradigm will be useful (the book uses the term “defined process control”).

For instance, when we have finally finished a version upgrade for a piece of software, the process by which clients upgrade, and obtain support etc, is fairly standardised.

As such, it can be (and is) the focus of our process development.  There is more we can do, however, and increasingly will do in future.

Similarly, because our market-share is broad (albeit in a narrow, vertical segment) we can also utilise process-based methodologies to support our marketing efforts – hence Kim’s interest in the world of internet marketing.  It won’t be possible for us to be 100% online, but (so long as we keep that in mind) there is much we can gain from these approaches.

(d)   Bringing it home…

On this point, I’ll leave the last word to the author (p41):

We need to be really careful to separate two kinds of work:  predictable, repetitive work, which we need to standardise and continuously improve, and unpredictable, creative work, in which we need to focus relentlessly on knowledge creation and application.

3)  Hence, what is Agile/Lean?

The best concise description I found was on page 69 in one of many monologues:

We do quite a bit of up-front work thinking through the business value, typical user scenarios, and testing out technical options until we are settled enough to start coding.

Then we put together a rough iteration plan, make sure it looks like we’ll get business value from the cost and time frame we seem to be facing, and then get going.

We only plan in detail for the coming month.

We look ahead to some end point of business function (usually a release) in as much detail as we need to be sure that the investment we are making will be justified by what we anticipate delivering, and to be sure that we identify any long lead-time items we need to start working on now.

Then, we build code and test every month from the inception of the project, and we keep adjusting the plan as we go.

4)  Some Highlights from the Book

What follows is really my reading of what are the key points the author himself was trying to make about Agile – hence it suffers the same fate as Chinese whispers.   Complicating this further, the author clearly supports the Agile/Lean method of development, and it does appear aligned with some of my own personal philosophies as well.

As a result, this post hardly qualifies as a truly objective view of “the key points about Agile”, but I trust it will still be of some use…

(a)  Start with real Research

In my view, a key point made in the book (beginning p7) was that the Agile/Lean method was initiated with a long period of extensive, but practical, market research.

In the words of “Neville”, the Chief Engineer in the Good Project:

“We’ve spent the last 6 months or so listening to potential users, understanding needs, figuring out who would pay how much for what, noodling on what we would build to meet the needs, thinking through options on how to build it, and then putting all this information into two documents” (which are discussed below).

Perhaps it was deliberate (I can’t be sure) – it is certainly aligned with my thinking that there is nowhere in the above that says something like “we came up with an idea in isolation and then went to the market and said ‘will you buy this’?” – in my view, that is not the focus of market research.

The key point here is that research is just that – research – by which I mean you have to have a genuinely open mind to what you will find out.  Or, in scientific terms = pose hypothesis – test – refine hypothesis – repeat forever.

(b)  What to document?

As noted above, two documents were produced.

Keep in mind that (in section 2c above) it’s better to “get the overall architecture and high-level plan in place” and then get started on actually doing something to accelerate learning.  Hence, the two documents support this purpose.

Document 1 – Concept Document

According to the book (p8) this “laid out the ‘what’ and ‘why’”.

[I have shifted the rest of this commentary here, for ease of reference]

Document 2 – Statement of Work

According to the book (p8) this “laid out the ‘how’, ‘who’ and ‘when’”.

[I have shifted the rest of this commentary here, for ease of reference]

A key point here, not explicitly stated in the book, is that these two documents are relatively brief.  That’s not to say that they are single pages – just that they have a purpose, which is to establish the principles under which the product will be developed, with the details to come later…

(c)  Why document?

This brings me to another question – why have documents? In the author’s words (p12):

“The documents are to facilitate the discussions and to identify and resolve conflicts, rather than an end in and of themselves”.

In my view, the documents are primarily useful for two interrelated purposes:

(I initially had this discussion here, but thought I would need to refer to it in other posts, so have put the discussion on another page)

On this point, I’ll leave the last word to the author (p40) when describing documentation under the Agile/Lean methodology:

QUESTION from Beth (outsider):  Have you written this all up in a detailed guide.  Something like ‘The XXX Development Manual’?.

ANSWER from Mary (Agile chief engineer):  That would be silly – why would we do that? By the time we wrote it up it would be obsolete, and if people really followed it, the process would freeze in place.

I understand, and agree!

(d) Plan, but only as far forward as is reasonable

I wish I had thought about this earlier – in the early days, my cash flow charts led me to being pilloried by others, who unfortunately adopted a mindset that they implied a greater level of certainty than was intended to be the case.

In the software domain, the author gives his characters a good monologue (p49):

“We could plan for the larger scope – BUT actually do something more quickly, with less risk, and with some earlier business benefits on the way.”

This is not dissimilar to the concepts espoused in “The Rockefeller Habits” about there not being too much point in making detailed plans for an in-between time horizon.

Again, my reading of that book was that the reason for this stance is that you make detailed plans only out as far as the level of uncertainty allows.  Beyond that, you just establish a “light on the hill” (call it vision/mission/whatever) which guides you in the general direction you want to head.

(e)  Clear Communications

Refer to part 4c (above) for a discussion about why to document.

One of the revelations to me in the book were a couple specific formats which appear to be very useful in communicating about elements of a software project.

1)  Burn-Down Chart (p179)

Rather than try to explain it, I thought it best to pinch the image and include it here:

Should be self-explanatory!
1)  the x-axis, which is not labelled, is the date at which the forecast was made
2) the y-axis, which does not come out well in the scan, is the estimate of person-hours remaining (for that sprint).

This is certainly something we can use.

2)  Neil’s Psychedelic Chart (p204)

A single-page report showing a load of information about project status, and inter-relationships.  Get the book to see it!

3)  User-Stories (p144)

The author made a point about the distinction between User Stories in Agile (i.e. higher-level scenarios more linked to the real world) and Use Cases.

Furthermore, he encourages us to dramatically act out the User Stories, to an audience, as a simulation method through which to actually test (prior to any code being written) if there are any flaws in the underlying logic.

The clear communication of information is especially relevant to us, as we pride ourselves in developing software that makes the electricity market understandable – hence, if we can’t make reports simple and easy for ourselves, what hope can we give to our clients?

(f)  Self-Managed Teams

It should be clear from the above that the Agile/Lean approach is predicated on having one or more self-managed teams, made up of experienced and emotionally-mature individuals, who are aligned to the organisation’s goal – and hence motivated to contribute.

This was very much aligned with my experiences in working with Stanwell power station, which I will talk about further in my review of “The Myth of Nine to Five” – a book co-written by the former manager of the station.

From our point of view, we have fairly good alignment of purpose, and I have been a firm supporter of self-managed teams since the company started (though certainly not the best at facilitating them).

However, we do still suffer from having a relatively inexperienced team (i.e. everyone well below 30 except me).

The book makes another important point (p86):

Leadership of knowledge workers must create conditions that support team commitment and rigorous decision making.

Once leadership shows it cares about neither of these things, team members may still continue to do their best to accomplish tasks, but the full flow of information, ideas and knowledge stops.

I know I am far from perfect, but I do hope that I have managed to get someway down the path to establishing these two pre-conditions.

(g)  Wrapping up – The author’s 4 core lessons

To wrap up the book, the author includes an epilogue (from p281) that presents him an opportunity for him to write with his own voice, and highlight what he sees are the 4 Lessons for Success:

Lesson 1) Teams of Responsible Experts

In the author’s own words (p283) -

“… success comes not from trying to reduce the impact of individual people**, but rather from rejoicing in and leveraging what talented, committed people can do working together toward a common goal.  It also encompasses the requirement of having a single unified team, with everyone focused on the business goal, as opposed to “business” and “technical” teams trying to stay aligned”

** earlier, the author clarifies that some companies mistakenly try, instead, to:

“make  projects ‘repeatable’ and ‘predictable’ by enforcing rigid process methodologies, putting people into neat categories, and defining how tasks get handled from role to role”.

I agree, which is why I am concerned whenever I hear people talk with religious fervour about the need to map and document every process, and to document job descriptions.  In our company, there would be some benefit in our having a small number of procedures mapped (a single diagram for each process would do), but it’s not what’s holding us back the most.

Our situation (in the paradigm of lesson 1) is not ideal – as we have grown our company by hiring graduate software developers, or recent graduates.  As a result, we are lower in the true “expert” stakes than we should ideally be – especially in the light of the 10,000 hour rule.

This inexperience has been compounded as some of our staff have left for backpacking adventures at various stages in the past (who otherwise might be a long way towards 10,000 hours now).

This was one of the reasons for establishing our Employee Share Ownership Scheme – so that  their experience was not lost entirely, and so that they would eventually be enticed to return.  This seems to be having some positive returns on both accounts.

However, I well know we’re not out of the woods yet…

Lesson 2) Project Leaders Acting as Entrepreneurs and System Designers, Rather than as Bureaucratic Managers

As the author notes, Toyota calls these people “chief engineers” – furthermore the book notes (p5) that this is “a tough role to fill because it was an unusual combination of marketing manager, technical lead, and project manager”.

For us, this is a real challenge (and the primary root cause of the underlying malaise that led to our autopsy a few months ago).  Basically, we have no-one who fits all 3 categories, and really only me with much experience in marketing and project management.

However (not that I needed it) the book does provide some encouragement as it provides clear instructions (p288) for how we can build our own chief engineer.

“You begin with someone with deep and strong skills in one of the central disciplines… it could be a developer, an analyst, a process engineer, a financial manager, an operations manager, a marketer, or a tester.  Then the budding chief engineer needs to broaden his or her experience and expertise, and grow by leading parts of projects and then his or her own small projects**.  These people need training, mentoring and challenging.  They need to understand the business…”

** note here the key point (in my view) is that the learning must be experiential, and that the training provided supports the experiential learning (not the other way around).

We’re on the way to delivering this.

As noted in other posts, we’re a small company, which means there’s nowhere for anyone to hide – as a result of which everyone gains exposure to the commercial aspects to our business from Day#1, really.

Some people have taken to this expanded focus better than others, hence:
1)  these are the people we have called our Product Managers and
2)  these are the people now receiving the focus of the “training, mentoring and challenging” required
We all need to remember to be patient along the way!

The book makes what I see as another key point (p289):

“Keep project managers who have only process guidance skills  subordinate to team members with substantive skills and knowledge” – otherwise, in my view, the “process automatons” will screw everything up.

I can understand the tendency for people to retreat to the allure that processes and procedures offer, when confronted with uncertainty.  We need to learn to grow through this to a new paradigm that will deliver us real benefit.

Lesson 3) Focus on Business Value, and Delivery

For me, this is two points in one:

1)  Everyone in the team needs to be focused on the commercial benefits of the project.

As noted before, I’m a firm believer that ICT is just an enabler of real business value (which is generally created in another industry).  In other words, ICT is not an end in itself.   It does surprise me, however, when others don’t see things this way.

2)  In the words of the author (p291) “working code is the only meaningful measurement of project progress, and teams need to focus on that above all else”:

(a)  For us, this has meant I have needed to combine the two (i.e. to see a releasable increment that delivers real value to me, initially, and to potential clients as well).  As Shane has noted, the reasons why I have asked for this are not always understood…

(b)  It’s important to note that this does mean that the detailed documentation is secondary, and often should be done after the fact (though, in our case, we did not have the revenues in the early years to allow us to do much documentation at all, as we were basically trying to get stuff out the door to keep our heads above water).

A little later on the same page he makes the point, in another way:

“Continually ask the question - ‘what is the minimum set of functions we can put into production and get business value?”’  Then do that.  Then do it again.

It’s for this reason that I have been pressing for short release timeframes.

Lesson 4) Be Humble

By which the author notes (p292) that:

“I mean respecting the complexity of our tasks; respecting the knowledge, skills and opinions of others; and avoiding arrogance about our own capabilities to proceed flawlessly.”

To me, this sounds like the concept of “Level 5 Leadership” written about elsewhere.

5)  What does it mean for us?

In summary, my perspective is that “Lean with Agile” is just a framework developed for the application of (uncommonly applied) common sense – this time in the domain of software development.

It certainly aligns with a personal philosophy developed and refined over 20 years of engineering experience in other fields:
1)  In manufacturing in general;
2)  In power station design, construction, commissioning and operations;
3)  In HR management; and
4)  In electricity market design.

It also fits with my view that the pleadings I’ve read written by some software developers (stemming from a belief that software engineering is somehow more complex than any other form of engineering) reflect a fairly myopic view of what “engineering” really is, and hence imposes limitations on the degree to which practices developed for other domains can be co-opted to provide value in the software engineering domain.

My reading of this book is that (with Lean/Agile) there have at least been some software developers learning from a volume of knowledge in other engineering disciplines.

6)  Not “One Size Fits All”

In summary, it’s not a “one size fits all” approach.

There will certainly be situations (even in a faster economy/society) where a more central “command and control” approach works better – indeed, as noted above, the book makes this point.

My philosophy is ultimately that:

1)  Everyone, as individuals, will have a preference as to the way they would rather work.

2)  For organisations, as well, the main principle is that “you can’t be a servant to two masters” – which is the same sort of principle espoused in books such as “The Discipline of Market Leaders”.

Hence – both people (and organisations) will find that they have the inclination and capacity to gravitate to a particular point on the spectrum.

The extension of this is (obviously?) that everyone should choose a company that is aligned with their inclination – or create your own, as I did.

Tags: Agile Software Development, growing pains, leadership, Lean Product Design, management of software company

This entry was posted on Saturday, September 19th, 2009 at 10:06 pm and is filed under Book Review, Design, Development, Requirements Gathering, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.