Category Archives: Testing

Design Thinking and its Relevance to Agile Testing

 Design Thinking Cover

Here I present a review of Design Thinking: Integrating Innovation, Customer Experience, and Brand Value at the same time connecting it to Agile Testing.  Quotations are from the book unless explicitly mentioned otherwise.  The good news, I think, is Agile Testing and the Quality mindset has an important part to play.  Does it resonate and connect with you?  Can they work together?  Are you doing something like it already?  Can we learn from each other? Let’s see.

Many things that model Agile Testing map to Design Thinking.  The techniques are either knowingly or unknowingly being applied.  Let’s make it them explicit.

We can connect this immediately to this from the book’s introduction:

‘The point of the story is that our innovation was successful, better products came to market, and people were more satisfied because a few open-minded designers teamed with some thoughtful engineers and with users who liked to experiment, developed and tested very rough prototypes, discovered flaws and reworked quickly, and included business analysis during the development process.  I call this design thinking…’

Well, I also find it a very good definition of Agile Testing!  Or near enough – there is a missing piece for most teams, it has key words, thoughtful engineers (testers and developers), users, business analysts combining with designers (the missing piece?) to create the process.  The missing piece is that testers and developers rarely get to participate in the well strategy defining tests that design thinkers are doing.  There may be cases where they are, and certainly in smaller companies it happens.  In larger organisations, the more traditional, I haven’t see it.  The real customer facing side of the business is often obscured and obfuscated.

Here is some more on the missing piece for us from the book’s introduction:

‘design thinking is primarily an innovation process.  It is a way to help discover unmet needs and opportunities and create new solutions’

Phil Best says it’s ‘a five step process that includes immersion and understanding, discovery of opportunities, creating a vision, validation with key stakeholders, and finally, integration and activation’

Testing is not usually considered a player in innovation.  I think it is when it is allowed to flourish it can really excel.  We may not even notice but some very innovative ideas come out of good agile testing (requirements) workshops,  which leads on to …

Everybody is Connected to a Goal

‘A big part of modern product development is the workshop exercise.’

And this too is what we do with ATDD, BDD and SBE.  These are focussed discussions of what the software for a product should do.  They encourage discussion and importantly dissension.   We call this a cross functional gathering.

Design Thinking takes it further.  It more than cross functional, it’s interdisciplinary.   Design thinking calls for a heightened view of Customer needs.  Often this is given lip service.  Many enlightened teams do mind mapping and paper prototyping, all of which fit nicely in the Design Thinking toolkit.

Can we take it further.  Customer Empathy,  generates real value.  Do we understand what makes the Customer happy or are we just order takers.  Design Thinkers spend their time on the options that determine these.   As testers can we take it to another level, amplifying the techniques we already use and supplementing them with others to achieve better value.

Let’s continue with more excerpts from the book, making direct connections to what we do:

‘start any new design activity or change program with an intent workshop.  This involves inviting all key stakeholders …’  p. 27

Liftoffs are one way to approach this,  Strategy Deployment is a more detailed and focused approach.

Exploratory Testing

Exploratory Testing, is just testing according to

‘The role of thinking, feeling, communicating humans became displaced.’ from

We need to link to a human process and unleash from the straightjacket of the script.   Context Driven Testing (CDT), seems to line up somewhat with Design Thinking.

To further align with CDT definitions, would be to identify with a humanistic and even all of body experience of testing.   It’s bringing in abduction, what might be.  Less on deduction, what it should be – that could prevent innovation.  Testing would still be somewhat aligned to induction, proving it does work but the continuum slanted to a mindset of abduction, particularly early on.

From Elizabeth Hendrickson’s book Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing,

‘No matter how many tests we write, no matter how many cases we execute, we always find the most serious bugs when we go off script’,

the message in going off script helps even when discovering what the user needs.  That’s how we can debug the process.  That’s how testers can help in Design Thinking.

Let’s turn Hendrickson’s definition of Exploratory Testing around to suit Design Thinking:

‘Simultaneously designing and executing tests to learn about the system, using your insights from the last experiment to inform the next’

Changing only a few words for

‘Designing and executing experiments to learn about the system, using your insights from the last experiment to inform the next’

Almost the same and perhaps I could have left it the same.  Tests are experiments, but I put experiment in to convey a larger gravity to idea.  The experiments do not have to be the real thing, they can be a role play and will generate immediate feedback from real customers.

Exploratory Test Charters may in fact be useful and its template of Target, Resources and Information (to find) could be a useful model for Design Thinkers to use.  Importantly the charter’s are designed to leave enough room for exploration, ignoring the specifics.

During requirements sessions, design thinking sessions, candidate charters can be constructed for later on.   You can be testing the requirements with an inter-disciplinary group of people.  It would shortcut assumptions even they can have.  Formulating tests, is an expression of requirements and all their shortcomings are realised earlier.

Design Thinkers may not understand the -ilities part of software.  Here’s the chance to bring that to bear. Listen out for the reliability, performance, load abilities often expressed in the language they are familiar with.

Testers Question

Testers have the opportunity through their knowledge of how products work to be innovators.  A frequent example I see in websites is not dealing with ethnographic qualities.  Different font sets for non English languages are often neglected.  That can give rise to interesting bugs as well.  But what about the experience for that group.  Could that experience take them elsewhere.  Was it even considered and what of the cost if it was.

Accepting requirements as is, and from the book: ‘This form of research is really just being an order taker, not an innovator’

Accepting requests as is, is leaving out innovation.  Testers know this as well as ‘test infected’ developers.

It means encouraging the proverbial dog with a bone:

‘Remember, the key is to solve the right problem, and the right problem is not often the first identified’ p. 89

‘Only if you take people out of their comfort zone you get meaningful answers’ p. 116

Use your testers doubting mind to check on assumptions.  Some examples are documented by Gojko Adzic in his book Specification by Example: How Successful Teams Deliver the Right Software.  I include my own example in my training.

As mentioned previously, also make sure it always connected to a goal:

‘Ideas need to be based on some relevant insight about connection to the desired outcome – otherwise they are just ideas’ p. 148

Here’s something where we can probably all improve, most of us are just not exposed to this.  We should be.  We should (be allowed to) take the plunge and learn more.

‘The more brands understand that it is not just the features of a brand that create consumer pull but the benefits as well, the more leadership they will attain within their categories’  p. 101

Leaders need to allow that, there will be failures and will need to be needing to accept that.  Risk taking leaders will excel here.  Their companies generally do better. Office furniture maker, Herman Miller, is an active risk –taker factoring that into their strategy.  p. 166

Here is something that links to overall goals of good product development:

‘Designers, however, prefer to proceed with a flexible toolbox of heuristics and an agile, curious mind. They don’t know yet what the outcome will be of their creative explorations, and therefore cannot define what specific steps may be required to get there’  p. 25

So for testers to shine, then following this is key.  Following this quote is a table of dysfunctions that describes the cults and the corresponding antidote for a design friendly environment – instead of copy and paste take a look yourself.

Behaviour Driven Development – BDD

BDD fits in very well with Design Thinking.  Two areas that work in complex domains that sprung up, it seems, independently but share many of the same values.  BDD brings in automation to shorten the feedback loop between the what and the how, however the front end of BDD is the most valuable when executed in the spirit it was intended.

Dan North, coiner of the term, has spoken and written about Deliberate Discovery.   It means admitting to fallibility in ego, in skillsets and what the user truly needs.   Ethnography is a key plank, but few people in the process get to witness what the user does and feel empathy for the user.  Usually the ‘budget’ and resource utilization thinking means this is usually siloed with business people responsible for what the user needs, and delivering personas perhaps, and the devs and testers making sure it’s built and delivered.  As an aside, Rachel Davies uses the word ‘research’ for user stories.  She coaches the developers in XP teams to write the story and do the research to build it and therefore connecting fully with customer needs rather than a build all those stories and demo in a sprint review.  Seems to fit in nicely, building on empathy for customer needs.

Often the disconnect to needs and delivery is not felt till later when the unhappy user gets something they didn’t want or need.  This can result in expensive re-writes, which I’ve seen and no doubt others have as well.   Design Thinking and BDD both want to eliminate this possibility as much as possible.   Testers and Devs have a key role to play.   (Some teams only have Devs – so being Design and Test infected is even more helpful for them)

Connecting to What is Human

Because ultimately it comes down to what people feel and if you aren’t doing something that connects to them positively then we haven’t passed.  Connecting the head, heart and gut.   Usability testing, often neglected for pure functional outputs, is important then.

head heart gut

 This is where innovation can arise and testers can have the eye for this.  Being connected from the beginning and during execution through to the end fits right in.  Here’s some more to back up starting at the beginning:

‘Customer experience mapping, or the process of storyboarding and documenting a variety of possible scenarios with detailed interactions and outcomes, is a useful means of probing and uncovering opportunities to design a better service’ p. 200

This example actually refers to service design, Design Thinking goes beyond ‘things’ to design experiences, but the concepts are still valid.  A tester is learned in thinking through scenarios and different outcomes,  and continuing on to the details is another area testers thrive in:

‘This reminds us that service design is about attention to detail, as even a staff member’s failure to say “thankyou” can leave the customer with a perception of inferior service.  Looking for opportunities to influence positive perceptions should be part of the service design process.’  p. 200

Again it refers to service design, yet it is still applicable to the software world.  The little details get noticed, they might not be obvious but they still accumulate.  Testers know through asking questions, and with an exploratory mindset they can sniff these things out.

At the same time that you are building your technical skills in automation, keep this in mind

‘If you want long-term profits, don’t start with technology – start with design’  p. 19

It so tempting to resort to and keep to the norm of reductionist silos and let others do that.  Rather it’s more relevant today than it was previously, that it is the interdisciplinary collaboration in all it’s initial messiness is where the insights, innovations and opportunities lie.

‘All too often, it seems, businesses either excel at the creative side, in which case innovations usually fail, or they excel at the analysis side, which generally leads to only incremental innovation, or more likely, stagnation.’  from the introduction of the book

What does it mean, for testers, it means knowing that this important:

‘a shift from using design to make things simple and easy to design being about making people care’  also from the book’s introduction.

It will mean that you’ll need to factor in the ‘Social, Economic with the Technical’  These SET factors are forces that interact in emergent ways, and only through probing can the preferred state be discovered for customers.

Role of Quality

The probes will not all be a right!  Generally accepted that 50% will fail and sometimes 80% will fail as observed at a recent client.  Still much learning occurs from either state.   Testing will execute on quality and that is still important.  Quality will enable the emergence of the right, and only after the market has had a chance to validate it.  We can’t know that upfront, it may exceed or underperform expectations.   Just know that the quality has its part to play. That helps with the punt that the business is taking.

Agile Testing therefore has a very relevant part to play in innovative product development.


Keeping up Technical Chops

Got asked to do this for a Coaching job.  It was nice to do.

There is an important and underestimated place for technical excellence.  Heck, it’s a principle!  Combine it with the others 🙂  Standing on the shoulders, Thanks Beck, Rainsberger, Meszaros,  Fowler, Wake, Prag Programmers and  many more unnamed.  It has 36 commits to demonstrate the process.  Feel free to take a look at it.  #agile #tdd #quality #emergent

Read the notes:

‘Keep hands on, that includes the code!’


Webinar: Case Study Agile Testing results in DevOps Success

I recorded a webinar for CodeGenesys on a case study on Agile Testing involving my Australian Client called AgWorld.

Hopefully it conveys that quality is owned by everyone and quality starts well before a line of code is written.

Quality right through the value stream is cornerstone of DevOps success. This carries on right through the software development life cycle starting with requests and turning those into executable specification with BDD/ATDD, automation of unit and integration tests and with the aid of automation tools (Build and Deploy) to increase the delivery rate of completed software to increase the frequency of feedback lloops.


Realizing the Power of Agile Testing

In this interview with AgWorld, a company that undertook the Agile Testing course that I present through my company About Agile, we learn about their journey to Agile Testing. In the six months since the course they have applied the ideas and reaped massive benefits from doing so.

I presented the course in a coaching style which they responded to positively and subsequently they really picked up the ball and ran with it afterwards. They did all the work to achieve the benefits and recognize that the journey is not complete either.

The full interview transcript is reproduced below.  I can give this course to your company or combine it with a coaching engagement for even better effect.  Use the contact details on the About Agile website to get in touch to find out more.  I also run the course in a public setting if you prefer to use that avenue.  A schedule appears on the About Agile website for that as well.

Interview Transcript

Here we have an interview with two participants to About Agile’s Agile Testing course.  Stephen Baldry is Chief Technical Officer at AgWorld and Michael Holmes is QA and Testing Team Lead at AgWorld.

The interview was conducted over Google Hangout whilst I (Nick) was in Croatia on a break, and Stephen and Michael are in Perth.  We find that the central theme is that Agile Testing is a collaborative and whole of team effort and this has been the main benefit of the course.

a 50% reduction in bug count

The course is not a Scrum or a Fundamentals of Agile course, rather it overlays the Agile principles over testing activities and the biggest outcome is better communication and sharing of responsibilities.  The course does delve in details like types of testing, the testing quadrants and Exploratory Testing and Testing For Requirements.  We don’t talk so much about these important facets in the course during the interview.  Read on to find out more.

Nick: Hi Guys, lets do a freeform chat and just start with the results you got in the last 6 months since you did the course.  For instance reductions in bug counts and also that you had the first release without any known defects.

Stephen:  Michael might want to take this answer and you’re closer to the QA process.

Michael: Sure, I posted recently on LinkedIn a major reduction in defect count and finding the issues earlier rather than later.  Weekly builds have helped, but also (more so) having a tester involved from the outset (i.e. doing Scrum rather than ScrumBut).  We are finding the issues before they become issues.

Nick:  Any specific examples you could give?

Michael:  There have been many none of which spring to mind at the moment, it’s more rather a continuous feeling of getting requirements right for all the stories we take on.

Nick:  Essentially testing the requirements, is that right?

Michael:  Yes, that’s right

Nick:  Be great to get a specific anecdote 🙂

Stephen:  It’s been something that we have been observing more externally (i.e. when the product goes to production).   Let’s expand a bit more, a year ago QA was discovering requirements when it was time to start testing.  Now QA is discovering requirements when we are planning development.  Beginning rather than at the end.

Nick: So you have been keeping track of this via metrics and stats have you not?

Stephen: Yes we have year on year stats for bug counts.  So year on year we have a 50% reduction in bug count compared with the previous twelve months.  And as we said earlier, this is the first major release we have released with zero known defects.  This is a massive change for us, this has never occurred before.

customers are taking the time out to give us the bouquets rather than the brick bats

Nick:  How did everyone feel about that?

Stephen: Ahhh, we didn’t care  (we all laugh in unison)

Nick:  Ah, it’s a bit of a nonchalance there…. It’s just what we do now

All:  Agreement 🙂

Stephen:  We have come to expect it now.

Nick:  That’s great to hear, so drilling down a bit more on that, what sort of effects has that had on the team and has it had any effects on a company wide level?

Stephen:  We’ve had contact with customers both via telephone and email, where customers have told us specifically that what we’ve been doing with the product in the last 12 months has been amazing.  The quality has gone up so much and it’s really saving them a lot of time, and they wanted to commend us on what we’ve done in the last 12 months and a lot of that has been around improved quality.  It has flowed right from the development team to the support team to the sales team and all the way through to customers.

Michael:  It’s great that our customers are actually cognizant of that and actually the taking the time out to give us the bouquets rather than the brick bats.

Nick: That’s got to be a good morale booster?

Stephen:  Yes, and it’s completely unprompted. For example, our CEO got a message on his phone where the customer said: “You don’t need to phone me back, it’s nothing urgent – just wanting to tell you that what you guys have done with the product lately has been amazing, a big increase in quality.”  It’s really good to get that kind of feedback from customers.

Nick:  Yeah that’s great, that’s the best kind of feedback – the feedback that you don’t ask for.  How has it helped with the team dynamics?

Michael:  I’ve heard back from the developers that it helps them get on with doing it.  Because we find the problems earlier, it’s still fresh in their mind.  They also don’t need to second guess themselves as to what was I thinking when I did that bit of code.  They can just go in the make the fix. It makes the turnaround time on detected issues much faster because of the freshness (Nick:  It can take 24 times longer to fix a bug after the fact).  Because the turnaround is fast they are much more efficient and deliver much more with better quality.

If your sending a rocket to the moon, if you’re off by a small degree at the launch point, you are totally going to miss.

Nick: Certainly, still having a developer hat at times, achieving milestones quickly and reliably is a great confidence booster.

Stephen:  We have made plenty of improvements over the last year, but there is still plenty we can still improve upon.   We haven’t yet reached our objectives with all of this, but we have seen significant improvements and we’ve seen the benefits of making these changes.  Including QA earlier in the process, we clearly are gaining the benefits from that, we feel there are other things we can improve as well.  (Nick:  Good improvement culture)

Nick:  Please tell us more of what you’d like to improve in the coming year?

Stephen:  Not specifically pertaining to QA, but more Agile process like the Scrum Process and better prioritization.  Part of the analogy that you covered in the course which showed making a cake whereby traditional software development if you don’t get to complete things you get holes in the cake.  Whereas in Agile development the layers that you have done are fully functional perfect layers of the cake.  Whilst we have a good agile process the prioritization of issues within the sprints is an issue, we sometimes still end of up a cake with holes in it at the end of a sprint (Nick: Probably requiring a hardening sprint) Note: The Cake Analogy is courtesy of Ilan Goldstein.

Nick:  Get a less holey cake?

Stephen:  And developers still like to cherry pick issues, so we tend to end up with a holey cake.

Nick:  Yes this is a common issue, i.e. thinking of the what I like first at the expense of the product overall (hard one to manage especially if innovation is what you want)

Stephen: So we still also want to understand the problem.  This can still be disconnected from the development team, the people who do they initial gathering of requirements are not part of the development team.  Not necessarily a problem, but if you can’t articulate what the problem is to the development team then you have a gap.  We would like to see that gap close.

Nick:  We are getting in the Product Ownership area and Agile Business Analysis area and making that more collaborative.  I still tend to think that Agile Testing overlaps quite a bit with techniques like Impact Mapping and Story Mapping are applicable in Agile Testing as well as in Business Analysis.

Nick:  One of the quotes I had back from the feedback from the initial delivery was from Tristan which was quite good and I wonder if it resonates with you?  He said: ”I got a lot out of this course (Agile Testing). It has changed the way I work subtly but the effect has been dramatic. I feel quite a few things have crystallized in the week following as the information is sinking in”  from:

Does that resonate with you?

Stephen:  I think that’s right. The changes that we’ve made are kind of subtle but the the impacts are much larger than the changes would indicate.

Michael:  If you were to make an analogy.  If your sending a rocket to the moon, if you’re off by a small degree at the launch point, you are totally going to miss.  Whereas at the start if your accuracy is correct you are more likely to arrive on the target and successfully land on the moon.

Stephen:  One of the things that I have noticed that is kind of small and subtle is just having QA involved early and continually through the process has often led to discovering missed requirements.

Nick:  Discovering Gaps?

Stephen:  Yes and that’s often because of the different angle QA is looking at it I think.  Because of that they are asking questions that developers aren’t asking and we are discovering it early on.  We add those requirements as we go (Nick:  still fulfilling the sprint goal, not going out of scope so to speak).

Nick:  During the course you mentioned that errant requirements were missed, do you think they are being captured as well.

Stephen:  Not yet I think, I was was referring to earlier this is about understanding the problem.  Gaps in understanding between those building and those asking.  We can only have a subset of the team understanding the problem and that subset need to articulate that to the other team members.  This is our next place of improvement.

Michael:  We had a coaching session with our organisational coach and it ties back to the trust that develops between people.  You need to believe what the other person is saying and not doing something stupid but doing that intelligently.  I’m not asking this to be done because I say so, but because it makes sense.

you don’t know it because if you knew it you’d be doing it

Nick:  So you know the Why?

Stephen:  Yes, the session was the speed to trust.  What sometimes happens is that we may do a lot of work in requirements gathering then trying to articulate those requirements we can say ‘You need to build it like this, just trust me – I’ve done all the work to figure it out and you need to do it like this.’  That actually doesn’t work because we are knowledge workers and we need to understand the rationale behind things and we need to trust that the right methodology and process has been used and if that is not transparent then it’s hard for us to trust that.  We had a workshop to promote transparency in the process and the outcome of what has been learnt is that this aligns really well with the requirements and the team understands this.  That speed to trust increases because the process of how they were gathered is transparent.  (Nick:  Specification by Example is deliberate in this respect and well as Deliberate Discovery)

Nick:  Exploring a little bit more around the testing side of things.  Michael are there any specific areas from the course you may have felt were immediately applicable?

Michael:  Just this week, we’ve had feedback from developers that we hit a problem and the feedback was that the tests around the work we were doing can improve and be doing that better.  We as ‘developers’ are not bashing QA anymore, as we have all these other lines of defense that come into play.

Stephen:  So what I think Michael is trying to say is that the course helps us better recognise that QA is everyone’s job and that it’s everyone’s responsibility and that we just don’t hand it over to QA.  They understand not doing this is breaking down the QA process and they now understand they have a part in this as well.

Nick:  That’s cool, do you find yourselves doing more things like triads, increasing T-Shaped skill sets?

Stephen:  To a small degree.  A lot of this is the change in mindset.  So changing from testing is only QA’s problem.  Previously, if a bug appeared it was because QA didn’t test it properly.  Now it’s everyone’s responsibility and this is the first step? That’s the biggest benefit in my mind, the change in mindset and the accountability for all of the process and not ‘just their part.’

It’s like a lot of things, sometimes you can have a course and you say to yourself – we know this why are you telling us this.  We don’t need to be in this course.  What you discover is that you don’t know it.  It’s like common sense and you do know it, but you don’t know it because if you knew it you’d be doing it.  That is what I found this course is that there is a lot of things in it that are from our experience was like we already know this stuff but then it becomes apparent that you don’t know it because you aren’t doing it.

Michael: Everybody has their own take and perspective on it, but here we are as a group have the same perspective and the same picture, so everyone realizes the gaps that exist between each other and at the same time those gaps get filled.

Nick: Once the gaps are apparent you can then deal with them?

Stephen: Yeah, and also agreeing on a common vocabulary and common ideas because you had common training just made it easier.  Therefore when we talk about X we all know what X is.  This is also helping us to be more effective.

Nick:  That is a common statement about Common Sense.  It’s very easily mentioned and agreed but rarely practised in a coherent way.  I read a quote this week – ‘It’s common sense to treat adults are adult human beings but in fact it’s rarely practiced’

Thanks guys for sharing your learning’s since taking the Agile Testing course.  Good luck and all the best in your ongoing journey.  I’m sure there will be more tangible and intangible benefits to AgWorld’s bottom line.

Stephen:  Thanks Nick, no problem.  Thanks for staying up at 1am to do the interview.

All: chuckles

Nick: That’s not a problem, not a problem at all.  Once again, I’m happy that you’ve received positive outcomes from taking the course as well and achieving the results to your bottom line. Those intangibles you get from the customer are going to result in tangibles to the bottom line.

Stephen:  Yes, I think it has definitely been contributing to changing results and changing the bottom line and changing customer feedback.  I definitely think that the changes we have made, some of which are directly attributable to the course are having definite effects in our efficiency and effectiveness and our customers perception of us as a company.

Nick:  Once again thanks!

All: Bye

ICAgile Agile Testing Expert Gate

In this recording of a webinar I participated in on January 28th 2015, Janet Gregory who is one of the track authors and has written the immensely popular Agile Testing with Lisa Crispin and now More Agile Testing again with Lisa Crispin, tells us about the criteria for achieving Expert Status in Agile Testing.

It’s quite a jump from taking a course and we learn that demonstrated experience over a number of years is key.  No exams here we emphatically say.

We also talk about the new book, More Agile Testing, and I pose some questions as well.  Janet and Lisa bring up Organisational culture early in the book and I commend them for this rather than assuming that it takes place.  I also liked the balanced reporting of views of the testing quadrants.  It’s mental model that has been in some quarters taken down in an unkind manner.  They report on the better variations and tell us not to take a ‘cookie cutter’ approach to its application.

We also had other panelists involved bringing in their expert views.  Thanks to Aldo Rall, Devin Hedge and Agile Bill Krebs.  Elinor Slomba once again handled the facilitation brilliantly over a difficult medium at times.

“It has changed the way I work subtly but the effect has been dramatic”

The title is some feedback from a recent running of About Agile’s Agile Testing Course.

There were some photos taken.  And some more should have been taken 🙂


Agile and Lean Bookshelf

Some books on lean and agile software development.  The list is still in development.  I’ve read all of these books and will not place books here that I have not read. Some books resonate more than others, but still don’t expect instant recall of all the detail – rather the key ideas and concepts and then drive into the detail if required.

You’ll find some books are relevant to more than one section, so they will be repeated in the sections in which they have relevance.

The Lean and Lean Startup Side

Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated  The archetype Lean book for the Western Reader from leaders in the field. Real life case studies of people over process.
This is Lean: Resolving the Efficiency Paradox
Running Lean: Iterate from Plan A to a Plan That Works (Lean Series)
Kanban: Successful Evolutionary Change for Your Technology Business  Start with this for Kanban, let it sink in, read others and then come back to this.
Leading Lean Software Development: Results Are not the Point
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
The Goal: A Process of Ongoing Improvement
Kanban in Action  I nice start for those wanting to learn about Kanban, don’t ignore David Anderson’s book though!
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win  Systems Thinking for IT People.  Be nice to those Brent’s they only work in a system.
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Kanban and Scrum – making the most of both (Enterprise Software Development)
Personal Kanban: Mapping Work | Navigating Life
Lean-Agile Software Development: Achieving Enterprise Agility
Lean Software Development: An Agile Toolkit
Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale

The Agile and Lean Frameworks Side

Essential Scrum: A Practical Guide to the Most Popular Agile Process (Addison-Wesley Signature Series (Cohn))
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley Signature Series (Cohn))
Kanban: Successful Evolutionary Change for Your Technology Business
Scrumban – Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Lean)
The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series)
Real-World Kanban: Do Less, Accomplish More with Lean Thinking
Agile Project Management: Creating Innovative Products (2nd Edition)
Agile Software Development with Scrum (Series in Agile Software Development)
Kanban in Action
Agile Project Management with Kanban (Developer Best Practices)
Agile Project Management with Scrum (Developer Best Practices)
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Kanban and Scrum – making the most of both (Enterprise Software Development)
Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)
Lean Software Development: An Agile Toolkit
Succeeding with Agile: Software Development Using Scrum
The Art of Agile Development
Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (IBM Press)
Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)
Scaling Software Agility: Best Practices for Large Enterprises
The Software Project Manager’s Bridge to Agility
Scrum and XP from the Trenches (Enterprise Software Development)
Actionable Agile Metrics for Predictability: An Introduction

The Technical Side

Domain-Driven Design: Tackling Complexity in the Heart of Software
Pair Programming Illuminated
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Agile Testing: A Practical Guide for Testers and Agile Teams
The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)
Clean Code: A Handbook of Agile Software Craftsmanship
Code Complete: A Practical Handbook of Software Construction, Second Edition
The Pragmatic Programmer: From Journeyman to Master
Growing Object-Oriented Software, Guided by Tests
Agile Software Development, Principles, Patterns, and Practices
Patterns of Enterprise Application Architecture
Refactoring: Improving the Design of Existing Code
Refactoring to Patterns
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
Continuous Integration: Improving Software Quality and Reducing Risk
Test Driven Development: By Example
Pattern-Oriented Software Architecture Volume 1: A System of Patterns
Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
Design Patterns: Elements of Reusable Object-Oriented Software
Extreme Programming Applied: Playing to Win
Writing Solid Code (20th Anniversary 2nd Edition)
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
Working Effectively with Legacy Code
Dependency Injection in .NET
Effective Unit Testing: A guide for Java developers
The Art of Unit Testing: with Examples in .NET
Pragmatic Unit Testing in C# with NUnit

The Product Ownership and Agile Requirements Side

User Story Mapping
Scrum Product Ownership: Balancing Value from the Inside Out
Working Effectively with Legacy Code
User Stories Applied: For Agile Software Development
Agile Estimating and Planning
Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn))
Impact Mapping: Making a Big Impact with Software Products and Projects
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
The Principles of Product Development Flow: Second Generation Lean Product Development

The Agile Tester Side

Agile Testing: A Practical Guide for Testers and Agile Teams
More Agile Testing: Learning Journeys for the Whole Team
The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers)
Testing for Continuous Delivery with Visual Studio 2012 (Microsoft patterns & practices)
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration (Net Objectives Lean-Agile Series)
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
xUnit Test Patterns: Refactoring Test Code
Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing
Effective Unit Testing: A guide for Java developers
The Art of Unit Testing: with Examples in .NET
Pragmatic Unit Testing in C# with NUnit

The People Side

The Five Dysfunctions of a Team: A Leadership Fable
The Introvert Advantage: How to Thrive in an Extrovert World
Emotional Intelligence: Why It Can Matter More Than IQ
Fearless Change: Patterns for Introducing New Ideas
Turn the Ship Around!: A True Story of Turning Followers into Leaders
Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))
Peopleware: Productive Projects and Teams (3rd Edition)
Drive: The Surprising Truth About What Motivates Us
Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency
Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
Death March (2nd Edition)
Agile Retrospectives: Making Good Teams Great
Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision
The Core Protocols: A Guide to Greatness
Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers
Dynamics of Software Development
Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Project Retrospectives: A Handbook for Team Reviews
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
Who Moved My Cheese?: An Amazing Way to Deal with Change in Your Work and in Your Life
The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change
Liftoff: Launching Agile Teams & Projects
The Fifth Discipline: The Art & Practice of The Learning Organization
Switch: How to Change Things When Change Is Hard
Start with Why: How Great Leaders Inspire Everyone to Take Action
Team of Teams: New Rules of Engagement for a Complex World
Principles Of Software Engineering Management
Emotional Intelligence 2.0
How to Win Friends & Influence People
Smart Questions: The Essential Strategy for Successful Managers
Great Boss Dead Boss Recommended by David Anderson in KCP Training. A model of identity.
Lessons in Agile Management: On the Road to Kanban
Thinking, Fast and Slow Science on how parts of the brain work. Involuntary vs Logical parts
Nonviolent Communication: A Language of Life, 3rd Edition: Life-Changing Tools for Healthy Relationships (Nonviolent Communication Guides) Judging or helping? Which is more helpful?

 The Organisational Side

Reinventing Organizations
Team of Teams: New Rules of Engagement for a Complex World
Maverick: The Success Story Behind the World’s Most Unusual Workplace
The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer
Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results
Why Plans Fail: Why Business Decision Making is More than Just Business (MemeMachine) (Volume 1)

 The Coaching Side

the act of coaching is distinct from the People and Organisational Sides although strongly linked

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) It’s a start but it won’t be enough
Executive Coaching with Backbone and Heart: A Systems Approach to Engaging Leaders with Their Challenges For real meat on the act of coaching. Years of experience here
Co-Active Coaching: Changing Business, Transforming Lives More meat on the idea that people have the ability to solve/change/improve their lives. Partnership wit a coach
The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever A good start, go to other sources still for more detail
A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas Build that muscle of inquiry first before jumping to a solution
Flawless Consulting: A Guide to Getting Your Expertise Used A consultant’s book every coach should have!