Lean coffee – Where the cool Agile kids hangout

Twas the last Thursday of the month and we once again head off to Lean coffee at Westfields shopping centre.

A small coffee house before you go into the main shopping centre houses this group of Agile discussionists.




Once through the secret door using the magic Agile handshake we have the tricky decision to make….croissant or pastry.

Deciding butter might affect my Agility I opted for neither.  Although on hearing that the event was sponsored I quickly opted for a large latte……….



Enough of the coffee banter we thought….on to the Agile.

We had a dis-proportionate amount of fashion retail attendees, but given the free flowing pastries and their experience in Kanban and Scrum i didn’t broach the subject.

“Think of ideas for discussion” one said, “I don’t a have pen” I exclaimed.  “Ill have an expresso” I heard.  “Can I have another glass said another”….” where do I put them” interrupted someone


After a frantic first few minutes we soon put our mental wares on the table for all to see, quite an image you’ll agree.

With lots of great discussion points we took time to hear from each idea creator.


“Dot vote” we were told.  “3 votes” they shouted.  “vote on my own” said one rather cheekily


We settled on 4 ideas to discuss, ordered by dot vote rank, a backlog if you like.  We would have 8 minute timeboxes and agree as a team should we wish to discuss for another timebox after the first expires.  Using the age old thumbs up thumbs down technique.


The ideas on our backlog were:

– How to prioritise MVP features

– Black Swan events

– How do you split your Products / Dev Teams?

– How we measure the effectiveness of Scrum / Agile


Belters you’ll  agree.

So here we go………..


How to prioritise MVP features


We had to try and steer this discussion to something more useful as unfortunately one of our Agile friends had a mis-understanding about the purpose of the lean coffee group.  He was trying to survey our views on his product backlog.  Answering questions with questions can only go on for so long.

I hope as a group we were able to help him articulate the thought processes that MVP (viable), MLP (lovable) and MMP (marketable) and other such acronyms involving ‘ M’ & ‘P’ require


As the Agile manifesto explains….Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

So MVP is going to come from understanding our customers needs.

*Kudos if you get the picture above.

Black Swan events


Stemming from a conversation regarding a book by Nassim Nicholas Taleb (The Black Swan: The Impact of the Highly Improbable)

We discussed how unknowns unknowns might be dealt with within Agile companies.

Known unknowns (things we know we dont know) can be planned for by things such as continuity planning.


Things such as unknown unknown (things we dont know that we dont know) Agile should put us in a great place to deal with.  The ability to react to change however large or small.

It’s all a little philosophical but ill let you know once ive read the book.



How do you split your Products / Dev Teams?

This will really depend on your organisation but was good to hear what others were/are doing.   Some split by physical sites, channels or sub domains.  Then by goal within the site – search, browse, checkout etc – looking at different phases within the purchase cycle


How we measure the effectiveness of Scrum / Agile

We discussed the measurements by which we show Agile and in particular Scrum is effective for the organisation.  After much discussion we considered that the Agile manifesto statement above ie. delivering working software and Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  If we can show that the customer finds the software valuable and we know what quality is then this is what we should measure.  Clear metrics that define customer satisfaction. Whilst velocity and points and other team metrics are useful its the customer satisfaction and the growth of the business that defines success.


We had time for one more……..

Should all testers code in order to be effective on Agile teams?

We discussed how some companies have testing roles that code unit tests and automation scripts.  They have a distinction in role between manual testing.


We discussed that the ideal is team members to have a T-shape of skills and be able to work as a team to reach a goal.  The historic role of a tester was to test all items in a sprint.  Ideally the team would all test with a QA team member helping support the approach and execution of testing.  If we want quality then we must test.  Some forms will be automated but they won’t find all bugs and edge cases.  A good old fashioned conversation about how we would test something before we start coding mixed with some automation was the remedy here.


The analogy of a team of chefs preparing a dish and no one tasting the meal before it went out was used.  In a kitchen the team would create the recipe together sampling ingredients and dishes would be tasted and checked before they are put together for the customer.  Whilst someone would still be a final quality check it was exactly that.  Very rarely faults would be found as quality was tested all the way through.


We don’t want to be left with a bad taste in our mouths……


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: