Category Archives: Reviews

Mary and Tom Poppendieck on the Seven Principles of Lean Software Development

“Requires a change in culture that some companies can’t achieve, those that have achieved massive performance improvements”

A summary of the principles from the Poppendieck’s momentus book Lean Software Development: An Agile Toolkit

The 7 Principles

Eliminate Waste – coding more features than required, handoffs, low or no value documents (shelfware), defering of decisions

Build Quality In – this also encompasses integrity which is wise leadership, communication, healthy discipline, relevant expertise.  This can’t be replaced by processes, procedures and measurements.  Technical practices like  Test Driven Development (TDD), Continuous Integration, Definition of Done assist.  UX design helps the customer attain a feeling of perceived integrity.  Supple architecture allows the system to gracefully grow.

Create Knowledge – also known as Amplify Learning.  This is where Lean for Software differs from Lean Manufacturing.  Development is a constant learning exercise in discovery.  There is an expectation that mistakes will be made but we learn from them and make the adjustments.  Learnings should be shared e.g. in a showcase, in a retrospective.  Feedback loops are present throughout.

Defer Commitment – also known as Last Responsible Moment in Lean Manufacturing.   Delaying decisions can be valuable because more information is available.  In Agile this means detailed story development is deferred, design and implementation should occur when it’s needed at not before hand.

Deliver Fast – To enable feedback to occur.  Also smaller batches reduces errors inherent in large batch work because of the missing feedback loop.  Compression the value stream helps here – i.e. eliminate or reduce wait time.

Respect People –  people on the coalface backed with good leadership are best placed to combine knowledge of the technical with the requirements of the customers.  It will lead to excellence and morale will go up markedly.  There is a wisdom in Crowds/Group Expertise

Optimize the Whole – the common good can suffer when people attend only to their specialization. Therefore this should not be measured at this level as it promotes sub optimization.  It will hurt the system overall.


On Lean Principles according to Womack and Jones

One of the best introductions to Lean Thinking is a the book ‘Lean Thinking‘ by Womack and Jones.

What follows is a summary of the book I used for my own purposes and hopefully is useful for you as well.  I’ve added some counter points from other authors as well.

According to Womack and Jones there are five steps:

  1. Identify the value for each product
  2. Identify the Value Stream
  3.  Create flow without interruptions
  4. Let the customer or consumer pull value from the produce
  5. Pursue Perfection

On Muda – is waste – anything that does not create value and includes waiting in queues, mistake rectification, over production and movement.

On Lean – this should be not been seen as a job destroyer.  It should create work – more valued work.

Value can only be defined by the customer.  It’s not created by engineers with complex ideas.  It needs a dialogue with the customer to supply the needs – this could be abstract – did the smart phone customer say they needed the iPhone?

Visualising the value stream will expose the MUDA.  You should be able to extend this to suppliers to flow the entire value stream from without your own organisation

When waste is removed – make the system flow!  That means work with smaller batches.  This will generate faster feedback.  (Simulations are available like paper plane making to illustrate this).  Jim Benson however suggests start with flow and eliminate the waste from there.

Furthermore to get flow, ignore traditional boundaries of jobs, careers and functions.  These are impediments to flow.  Keep the product in sight at all times (early delivery).  All workflows and tools are up for scrutiny.

Once flow is established time to complete work can come down from months to days, days to hours.  David Anderson did this with a team working for Microsoft.  The team was based in India.  There were many problems in reliability in estimates and quality of the work and delivery of that work.  He (and colleague Dragos Dumitriu) used Kanban to achieve this.

This leads to the ability to Pull.  You can do the work and make the product when the customer asks for it.  For example DELL Computer makes PCs to order.  Inventory is waste and for DELL large inventory is massive waste due to obsolescence.  Toyota is capable of making cars to order because of the value stream includes the supplier.  Toyota can build a car on order in one week.  If there is no PULL then there is still waste or MUDA.

Now with everything visible, flowing and pulling, transparency is a natural by product and therefore it’s much easier to discover other ways to create value.  When employees are involved in the entire loop, then employee satisfaction goes up – less need to financial reward systems (a dysfunction maybe)

A transition should not be costly.  Going from large batches to smaller batches for example.  If it’s expensive then you’ve yet to understand lean thinking.

And on society – Womack and Jones also say “Stagnation has also led to a frenzy of cost costing in the business world, which removes the incentive for employees to make any positive contribution to their firms and swells the unemployment ranks.”  Lean Thinking is the way to turn this mindset around.

And be aware or beware – Lean Thinking means layers of management get permanently stripped away.  However this does not preclude the idea of succession plans, rewards for experience and higher pay.  You lose the title not the experience.  You will find yourself becoming a coach.

A transformation can take years.  There are several examples in the book with Toyota and Pratt & Whitney being the most famous.

Running Lean by Ash Maurya

Recommend this book Running Lean: Iterate from Plan A to a Plan That Works (Lean Series). I will review when time allows. Here’s a great video introduction.

Keep along side Lean Startup by Eric Ries

Book Review/Summary: Turn the Ship Around by L. David Marquet

I heard about Turn the Ship Around!: A True Story of Turning Followers into Leaders through Agile Coach, Erwin van de Koogh last year.  I finally got round to reading it, and a great read it was.  I finished it within a day – thanks Erwin for recommending it.  This warrants a review and summary 🙂  As usual in my reviews I include key points I think are worth mentioning as well as my thoughts.  My policies on thoughts are best represented in these blog posts: Ask How, I merely state and Take Notice.  I like to include my views as it helps me understand – maybe it helps others as well 🙂

As the title suggests, the belief and the benefits of leadership occurs at all levels is the recurrent theme throughout the book.  It’s the common catchphrase along with this – ‘Move decision making to where the information is’  It’s a book about empowerment but not just a cowboy, ad-hoc approach to this or even the official approach of traditional empowerment/change programs.

“The steps were evolutionary. The result was revolutionary”

The book presents a real life account of Lieutenant David Marquet and his successful approach to turning the Santa Fe, a submarine in the US Navy, from the worst performed to the best performed.  He did this by empowering the sailors under his ‘command’ to make decisions by stating intent.  The journey starts with immediate results, within 24 hours, but took 2 years to fully bed in.  ‘The steps were evolutionary. The result was revolutionary.’

Empowerment programs aren’t new, they’ve existed for some time, however Marquet tells us from a prior experience on another ship, the simple exhortations don’t get the job done.  They tend to fail and regression back to old ways is the common result.  He tells us of several dysfunctions that are viewed as ‘normal’ but really could be described as anti-patterns.  For example: ‘When the performance of a unit goes down after an officer leaves, it is taken as a sign that he was a good leader, not that he was ineffective in training his people properly.’

How do you start?  Establish trust.  Realise that the system is the problem not the people.  The system rewards local and short term performance.  Here’s an example: ‘each CO is encouraged to maximize performance for his tour and his tour alone.  There is no incentive or reward for developing mechanisms that enable excellence beyond your immediate tour.  Imagine the impact of this on the thousands of decisions made by the commanding officers throughout the Navy.’

The system encourages aversion to mistakes ‘the crew was becoming gun shy about making making mistakes.  The best way not to make a mistake is not to do anything or make any decisions.’  A common joke sadly was ‘Your reward is no punishment’  (Marquet’s website has a seven step process for learning from errors on a nuclear submarine)

Enablers: Control, Competence, Clarity

The preceding paragraphs summarize the pain described in the first seven chapters of the book.  In parts II, III and IV we find out more of the enabling actions of control, competence and clarity (this is subsequently strengthened with courage).  We begin to see real practices that back up the hollow statements and calls to action that can sometimes be felt in empowerment programs.

Marquet recommends that you find the genetic code for control and rewrite it.  He tells us that many organisations lack a central principle, a genetic code, behind their empowerment programs.  Further, empowerment programs cannot be directed as they imply authority has been given by someone else to become better.  In other words delivery of empowerment is paradoxically dis-empowering.

To put it into action, you will need to ‘Act Your Way to New Thinking.’  For example, to improve morale was the first step and a simple suggestion for the sailors on board was to welcome visitors by greeting then with the name of the visitor, own name and a welcome aboard the ‘[name of the ship]’  This is an example a culture changer and an important early step.  In this instance bring back pride.

To establish control, one should institute SHORT, EARLY CONVERSATIONS.  The crew relayed what they were doing to commanders rather than being directed.  This enabled feedback (to improve) and importantly allowed them to retain control.  They last 30 seconds but save hours of time.

Marquet also tells us about the Power of Words.  Sailors used to ask permission, but were then asked to use start their sentences with ‘I intend to …’  Asking permission is an example of dis-empowering phrase and I intend an example of an empowering phrase.  One must also resist the urge to provide solutions.  You must allow time for others to react to the situation as well.  Only provide the solution if they recommend it.  Some decision making though is urgent – you will have to make it but allow the team to evaluate it after.  Other times a delay can allow team input.  In making input cherish dissension – ‘If everyone thinks like you, you don’t need them.’

The level of informal conversation is a good indicator for team health.  In a strict hierarchical environment discussion is repressed and frowned upon.  The opposite approach actually gave a better gauge of how the ship was operating and whether information was being shared.  A lack of certainty can be viewed as a strength!  Certainty implies arrogance.  There is a linkage – arrogance leads to silence and therefore chances for mishaps to occur.

To emphasize the point more, actions are deliberate in that they are vocalized. Intent to do some action is stated with the view to eliminating automatic mistakes.  This forces the vocalizer to deliberate action.  There doesn’t have to anyone else around to do this. (Sounds similar to Rubber Ducking)

“I learned the hard way that control without competence is chaos”

Competence is built up via learning and we learn all the time.  We learn by doing and do this everywhere, all the time.  An increase in competence allows divestment of control.  One wonders if you’d want anything different – incompetence breeds all manner of dysfunction.  Learning increases competence which allows confidence for control to occur where the information is.

Certification is another mechanism (the book is interspersed with numerous mechanisms of which I’m covering a few here).  So it’s not just a meeting or a brief.  To certify means that we are ready for the job and failing certification is less costly than bungling a task.  Study to learn and be responsible for their jobs became an omnipresent atmosphere amongst the sailors aboard the ship. Meeting briefs became a thing of the past. Repetition is a well known mode of human learning, and therefore there is no redundacy in constantly repeating a message.  Continually and consistently repeat a message.

I personally felt affinity for the story of Sled Dog, a hard worker who came to be over worked and under appreciated.  This lead to him going AWOL.  The natural course of events would have meant a severe disciplining.  However, Marquet dug deeper and found the root causes.  Sled Dog was an admired member of the crew.  His skills were invaluable.  Too lose him would mean a regress for the US Navy and for Sled Dog personally.  Knowing the causes Sled Dog was retained and his issues were dealt with in a humane way and he continued to improve and excel.


A key enabler is to specify goals and not methods (reminds us of the Scrum Guide – the team and only the team decides how to build the solution).  By specifying the method we have control diminished.  This leads into delivering clarity.  It requires trust, which occurs over time, and then also taking care of your people – in work and outside of work.  Work at overcoming your own in-tolerances of inadequacies.  Taking care of people does not mean protection from consequences, more about supporting their ongoing education and less about irresponsible behaviour (is nepotism, playing favourites a symptom?  Certainly seen this, and I’ve been coerced into being a favourite which I revolted against).

Clarity requires guiding principles and there are several listed such as Initiative, Innovation, Intimate Technical Knowledge, Courage, Commitment, Continuous Improvement, Integrity, Empowerment, Teamwork, Timeliness and Openness.  Openness resonated alot with me, this from the book – “We exercise participative openness: freedom to speak one’s mind. Additionally, we exercise reflective openness, which leads to looking inward.  We challenge our own thinking.  We avoid the trap of listening to refute.”  It follows that from these guiding principles we need leadership at every level.  Guiding principles should be well know as they aid with clarity.  Displaying your motto in Latin is not advised – an example from the book – not many people will know Latin.

And when something of merit does occur – give recognition immediately to reinforce the designed behaviour.  Do not let this occur later.  Further, providing feedback and comparing against other teams can be positive (called gamification).  This is the good side of gaming.

“Begin with the End in Mind”

This is a repetition of Stephen Covey’s statement.  Look out years in advance and devise ways of measuring performance against the goals.  Employees can write down their own goals which should flow hence forth from the company goals.

“We realized that resilience and effectiveness sometimes meant questioning orders”

Blind obedience can lead to catastrophic results.  Perhaps someone should have questioned the captain of the Costa Concordia prior to allowing the ship to change course to be closer to the dangerous reef.  Does your culture allow this? What would you rather?

Marquet’s journey from Leader-Follower to Leader-Leader turned traditional leadership on it’s head.  I include a table from the book and hope he doesn’t mind. It’s a summary for my benefit as much as anyone else’s 🙂

Don’t Do This! Do This!
Leader-Follower Leader-Leader
Take control Give control
When you give orders, be confident, unambiguous, and resolute When you give orders, leave room for questioning
Brief Certify
Have meetings Have conversations
Have a mentor-mentee program Have a mentor-mentor program
Focus on technology Focus on people
Think short-term Think long-term
Want to be missed after you depart Want not to be missed after you depart
Have high-repetition low-quality training Have low-repetition, high quality training
Limit communications to terse, succinct, formal orders Augment orders with rich, contextual, informal communications
Be questioning Be curious
Make inefficient processes efficient Eliminate entire steps and processes that don’t add value
Increase monitoring and inspection points Reduce monitoring and inspection points
Protect information Pass information

Words are important, so replace Empowerment with Emancipation.  Emancipation recognizes the inherent talents of your people.  Empower implies to give permission.  An emancipated team is one that does not need empowerment. That freedom (my word not Marquet’s -is  a related word to emancipation) is importantly backed by competence and clarity.

If a nuclear sub commander can give control to those under him and achieve amazing results, so can you.  But be careful – it’s not a prescription and your organisation will be different from others.  So tune for your particular circumstance.





Review: Scrum Product Ownership by Bob Galen

As Bob rightly says there’s not a lot of coherent writing on the role of the Product Owner in Agile.   One of my previous blog posts outlined the importance of the role, but then also provided links to find more information from guys like Roman Pichler, Mike Cohn and James Sutherland.  Scrum Product Ownership: Balancing Value from the Inside Out is one of a couple of books that attempt to give pragmatic advice on the role of this pivotal and important part of the agile machinery.

Pragmatic is the operative word.  Bob sensibly applies the knowledge and thoughts of others including current sparring partners Ken Schwaber ( and Dean Leffingwell (SAFe).  All ideas are up for grabs it seems including his own.  He quite obviously, to me at least, doesn’t remain dogmatic to one particular point of view and applies ideas as appropriate to the context at hand.  This is a good thing, and in such a guide the reader needs to be informed of the best thinking from all points view.

Bob is candid also about previous writings shortcomings as well.  For instance, the role of Product Management is quite large and Product Ownership only deals with a portion of the activities of Product Management.  Therefore it’s important that there be symbiosis between the two roles and not a hand-off.

I also like the idea of no single wring-able neck.  The PO can be assumed to be person in the gun when things go wrong.  I also do not hold this view as it’s the team who are collectively accountable and in fact usage of the term in my opinion is an anti-pattern and indicative of something wrong in organisational culture.

And to further add to the pragmatic nature of the book, there are many practical tips.  Bob talks a lot about management of the backlog more than the a list of items.   For example, I like his 20/30/50 rule for backlog refinement.  That is the top 20% or product backlog items should be at or near a level of detail for it to be immediately pulled into a sprint when required.  Meaning work to groom these items is constantly occurring driven by the PO with expected assistance from the entire team.  And by near enough ready there are 30% left during the sprint to fine tune and make new learning as work progressing which lines up with Scrum Guide statements.

Overall, the book emphasizes the immersive and totally involved nature of the PO role.  This is backed up with concrete examples of the types of activities required for success.  From this it can be seen that it is a full time role that needs firm backing and support from management.   I’d recommend it for the reading list of upper management as well.  It’s easily read and not overly long so can be read in a few sittings.

Project Phoenix: A light introduction to Systems Thinking, Theory of Constraints, Lean –> DevOps

 For me this was not a great read despite the hype surrounding the book.  But don’t let that stop you from reading this book.  In fact if you are interested in learning something about Systems Thinking, Theory of Constraints, Lean and Kanban this is the perfect introduction in the form of a business novel.

Now a novel is usually read for enjoyment, but I found the rubber doesn’t hit the road till about Chapter 14.   It’s a bit a long introduction til we start getting into solutions.  Then it starts to shine and the disaster looking like having a horrible death goes through a remarkable transformation.

Again if you’re not familiar with any of the concepts this is a great introduction.  If you’re interested in improving the state of your workplace grab yourself a copy.  It’s especially important for demonstrating the need for a more symbiotic relationship between all parts of service delivery and hence the rise of DevOps.

Slack by Tom DeMarco

I just finished reading Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency by noted author Tom DeMarco, famous for Peopleware (with Tim Lister) and Waltzing With Bears and for those who go back further author in the 1970s on Structured Systems Analysis and Design.

It really did strike a chord with me and I dare say with similar veterans of the software development field.  DeMarco has been writing about people side of software development work since the 1980s, however as respected as he is my experience indicates that not much of his learned writings have hit home with the software project community.

The overall premise of the book is to ironically and paradoxically juxtapose efficiency and effectiveness by inserting the variable of slack.  With slack the organisation can position itself to be more effective which in turn means turning down the efficiency dial.  The question is what does one what value more effectiveness, how much we delight our customers, and efficiency – how well we do are jobs (eliminating the customer in this definition).   The answer is hopefully effectiveness.

What is slack?  In short it’s the small amount of time we spend not directly generating customer value but learning how we increase customer value long term, that is short term vs long term gains.    Perhaps the best known example that Google incorporates Slack into their work week.  They are famous for the 20% budget for the week for employees to work on their own pet projects.  This has spurned many useful products that we take for granted today.  That is they budget for innovation.

Google’s example is perhaps the most famous example of slack we know of today but there are other forms of slack that we use to keep the organisation healthy and people working in those organisations healthy which for me is the most resonate element of the book.  Tom covers alot of other elements which are very important as well but they all come back to the idea of healthiness.

Without this this ‘health’ as I like to call it, it becomes difficult to work effectively and grow. DeMarco notes Slack – ‘It is the lubricant of change. Good companies excel in the creative use of slack. And bad ones can only obsess about removing it.’  Thereby removal of slack, that is the aim of 100% utilization, invariably consigns a company into morbidity and perhaps even death and the accompanying distresses that entails.

The book is as much a catalogue of fallacies, some of which we already know about but are fearful to deal with.  Tom does provide some guidance here and in some cases advises best be looking for a new job in others.  Some fallacies and maladies:

  • People under pressure do not think faster – from Tim Lister.  Pressure has limited capcity to reduce delivery time – 10 to 15%
  • Do more work and more we get done – but we don’t think about context switching. Lean Principles tell us that doing less increases throughput.  That is limit work in progress.
  • Overtime – causes reduced quality, burnout (and poor health), staff turnover, zombie workers.  Ineffective long meetings or meetings with no basis are the main culprit
  • Creative Time Accounting – spending 12 hours at work only recording 8.  I witnessed a guy regularly do this but I do credit him for negotiating a longer holiday afterwards – but I see this as a reverse gaming of the system as well.  Maybe still recovering from that.
  • Cutting useful support staff when there is a downturn.  That’s a great opportunity to innovate!  Furthermore support staff do the little things like printing and binding.  Expensive thought workers should not to do this, generally speaking.
  • Replacing cut stuff with yourself (being the manager) – now all your slack is gone and your team attending to team health and innovating activities is lost.  You’ll look busy and be commended for it, perhaps, but take a look at the bigger picture.
  • Unsafe to fail – using your power to instill fear and therefore limiting the revelation of new information and learning opportunities
  • Applying Process thinking to Knowledge Work – a great example from 1980’s Volvo using a single team to build a complete car.  Here the team decides how to do its work.  Empowerment has wondrous effects on people!
  • Lip service paid to quality and when it is used it’s the quality program to stifle and frustrate rather than assist
  • Management By Objectives is still alive e.g. sales selling to quota over time diminishes customer satisfaction.  This is aligned with the idea of local optimization.  Sales is doing well but oblivious to the health of the entire company.  But we mustn’t blame them people, the System caused this.
  • Lack of robust Vision – content free baloney as James Shore puts it.  A vision needs to motivate – resonate through truth and excite the future
  • Leadership – it comes from all and not just the anointed few
  • When change occurs it is done inhumanely.  People are expected to learn a new way and then perform at the same rate as before.  The Satir change model graphically illustrates that this doesn’t occur.  Kanban (David Anderson) hopefully to the rescue here with change more gradual and respectful to people’s current roles and responsibility and evolution into new roles.

Those are the main takeaways from the book.  I enjoyed it and must get and revise Peopleware again.  It’s been a while.