Category Archives: Lean

Right Size First, Then Split

There is a hell of a lot going on in Agile Space on Story Splitting.  On the internet and I hear it in interviews and conversations.  It’s as if the only solution to smaller batches is to split ad infinitum.

Now don’t get me wrong, big batches are not good.  They hurt feedback mechanisms, create silos and delay delivery of value.

And there is the point, delivery of value.  Getting value to the customer is important.  Story Splitting is one way.  It doesn’t need to be the starting point.  We may be losing our focus on delivery of value by thinking about a process.  Value is not defined by the splitting of stories.

Something to consider then is to understand the nature of your work.  Are there different types of work, or another way to put it, sources of demand?  Can you use that information to help?

Maybe your team is predictable in it’s delivery.  That’s great and congratulations to you on that.  That data on delivery time can be leveraged.  If you can say we can deliver product enhancements on one product within a time frame and be confident about that say 85% of the time.  There you go – you have the makings of a Service Level Agreement or SLA.  Your customer may even be happy with that!

How can that help in sizing stories?  Well Dan Vacanti describes it in his book Actionable Agile Metrics for Predictability.  It’s called Right Sizing.  In essence it shortens the sizing conversation by asking does this work which we are about to take on fit in within our SLA.  If so then pull the work.  If not have that splitting conversation.

It’s that simple.  However, if you are experiencing problems in predictability and expanding delivery times then you’ll want to deal with those.  Dan’s book describes how Little’s Law and its components gives you ample information to help discover issues in your process.

Story Splitting is an option to start with.  You can consider others like this.  I think it will help you understand work to a higher level of fidelity.  Your customer will hopefully feel the difference as you deliver to them more meaningful increments of value from the increased understanding.  Coincidentally, you’ll also be on your way to be being better Systems and Lean Thinkers which are interesting subjects that will aid you being of best service to your customers.


Where’s the teamwork when we can’t see each other

I’m an Australian working in the USA coaching highly distributed teams. We speak English but even then there are slight differences, like Australian English and American English and even within America like from South to North.

We find it’s hard to get people to use video cameras. They are cheap however the culture tends to not encourage use of them. It’s always hard to collaborate at the best of times and distribution would be a good excuse not to do that.

Seems most distributed companies can’t get past just the phone and a little screen sharing.  When we use just these, we can’t see each other’s facial expressions and body language.  It’s hard to know how to react to feelings and we have to assume or turn up our intonation sense when listening (perhaps even speakers and listeners can make more us of their voice to relay feelings).  Another big issue is having attention – where I work inattention is called ‘multi-tasking’ and we know that don’t work.

Overall, this is more a problem around the difficulties in collaborating and the fears around that.  We’ll need to work on that to allow the tools to be useful.  Make it safe.  Create the culture and camaraderie of teamwork and reward that.  Highlight even when people are doing things that harm teamwork via a team working agreement.  Realization can quickly occur after that and a team can self correct.

Then there is technology, my friend Agile Bill Krebs, is teaching and coaching on tools to assist the distributed work place.  There are simple tools like join.me which is down the low end of the spectrum through to immersive environments like Minecraft.

The technology is there – it just needs a willingness to try using it and adapting to use it to it’s utmost advantage.

Your last resort is to abandon the distributed model.  That can be avoided I suggest.

 


Ask Why – To Understand

This is a follow on post from my post called Ask How (Don’t say No). Sometimes in some situations it makes more sense to Ask Why to increase understanding.

Sometimes we find ourselves in a passionate conversation about a topic.  Someone says something, perhaps in a strident tone, this can force a reaction from others that implies that what has been said is wrong.  The response can stop conversation dead in it’s tracks as processing of the remarks take place.

Now a facilitator can help keep the conversation going and relieve the tension and let the point carry on to it’s final conclusion.  We don’t have a facilitator all the time though, so we can train ourselves to react quickly still but thoughtfully as well.

I suggest the first response is ‘Why?’, ‘Why do you say that?’  This could help create a response that helps the person retrieve an important item that adds further context.  Sometimes excitement causes that person to forget to mention that important piece of context.  Asking Why is an Open Question and keeps the conversation going rather than perhaps escalating into an out and out disagreement.


Moving to the United States

An opportunity has arisen for me to travel to the United States to help out with a large transformation using Scrumban (combining Scrum, Agile and Lean Kanban).  CodeGenesys a company that specializes in consulting in this area has invited me to come over and help out with the transformation at a large Health Insurance company.  CodeGenesys also make a online visualization board called ScrumDo which I have written about in the blog articles Managing work with ScrumDo – Part 1 and Managing work with ScrumDo – Part 2.

About Agile still operates and the courses and training are still available.  They will be available on an as needed basis in Australia and elsewhere and will be subject to my availability.  So inquiries are still welcome. I hope to give training in the United States as well.  I will look to schedule public classes again after settling down in the US and the picture becomes clearer.

My relationship with CodeGenesys will be a symbiotic relationship.  I hope to learn a lot from my secondment to the US  and spread new knowledge on my return back to Australia.  Training from CodeGenesys will be combined with the About Agile courses to offer a greater suite of courses.

These will combine with consulting and coaching to provide a full array of services to help out with transformations and ongoing improvement efforts.

My time in the US will be at least 6 months and depending on conditions could go on for longer.

Please stay in touch through my email address info@aboutagile.com.  I tweet through the handle @n_zdunic.


Lean Coffee Meetup in Perth 21st May 2015

For those of you in Perth, there will be a Lean Coffee Meetup next Thursday the 21st of May 2015 starting at 5:45pm.

AgWorld are sponsoring by providing the space and some drinks and snacks. They are centrally located in Leederville and there will be parking on the street available for those driving or it is easily accessible from Leederville train station.

A Lean Coffee is a formal, yet informal, discussion where you come with your ideas and requests and start a conversation.

The meetup link gives a bit more information. You’ll find out more on the night and it promises to be an engaging evening.

Please signup via the meetup link. http://www.meetup.com/Lean-Perth/events/222450260/

There will be a limit of 15 attendees.

Hope to see some of you there.


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.