Tag Archives: Agile

Attention to Quality gets Results

Most managers, and some ‘Agile’ coaches, I encounter shudder when the subject of quality comes up.  They think quality hampers delivery.   In some ways they are right, you do want to achieve balance, avoiding polishing too much because it can cause being late in delivery  (in mission critical projects it may be better to over polish if the cost of failure is high).

Some managers may shudder because, ooops I may have been found out and I’ve been pushing my teams to push out code which is not really ready.

Other managers, maybe the inexperienced ones but not always, have no idea what quality is.  They tend to believe the lies their development teams’ say when they say it’s ‘unit tested.’

As a manager, quality is one of if not your biggest concern.  Addressing quality is an economic concern as well and managers are responsible for economic outcomes.  Bad quality will slow down your team.  But not just that, it will also slow down your organisation.

How does this occur?  How does it slow down your organisation?  Well I’ve seen this time and time again when I come to a new client.   Work is at a stand still and when I dig a bit deeper I see the same issue appear.

Yes, teams are overwhelmed with work.  So limiting WiP will help.  Using workflow mapping and lean techniques will identify bottlenecks.  Yes address those.   Importantly, in the bottlenecks I find that the reason for those delays is the negative feedback of poor quality.

I see upstream, product ideas waiting to be developed and tested with the customer because there is a wave of poor quality slowing down the delivery pipe.   Overwhelmed with defects teams struggle to pull new work into development.  When they do eventually pull that work in, it is developed with such poor quality or worse the facade of quality (e.g. formal QA) that it further feeds into the negative feedback loop.

That loop gets even slower to run such that it turns into ‘3 month Stabilization’ phases or an entire quarter whereby the organisation freezes any new releases into production to avoid an outage.

These sort of mitigating steps often occur after some sort of disaster has occurred which has its root cause in poor quality.  One big example is releasing a new version of software such that it shuts down an assembly line at a factory and affects thousands of customers who are prevented from using their mobile devices.  The cost there was millions of dollars.

So asking for quality is easier said than done.  Or does it have to be that hard.  Usually workers are over-burdened.  So limit WiP as was mentioned earlier.  But then ask for quality.  Now that they are not over burdened they can put their efforts into producing quality output.

Give teams the space to improve and they usually will.  Sometimes as a coach I can give them some training and they will do it all by themselves (this interview demonstrates this) to a point, and sometimes being involved with them is needed from the outset or when levelling out or stalling out occurs.

In my experience, results can happen very quickly.  For an organisation I was recently involved with it took three months to go from a cycle time per feature of 40 days to 3 days.  This involved addressing quality and bringing in aligning practices from extreme programming and specification by example.  Reducing WiP and batch size also assisted.  This happened in stages, guided by data from a Cumulative Flow Diagram that mapped the stages of delivery and guided improvement efforts.  The first stage got it down to 9 days (by applying WiP limits, Policies on size and changing the Test Strategy) and then, the next stage, amplifying the unit testing practices to remove an archaic and slow UI testing bottleneck (sunk cost fallacy associated with that) really accelerated the flow of work.

AgWorld, the published case study, did it in 6 months.  They did chose to do for themselves which is fine.  They can achieve a lot more with a coach who can bring the practices quicker and help avoid stagnation which does tend to happen as well.

Find a slow process, you more often than not find poor quality.  Address quality and just observe how things get better for everyone.

 

Advertisements

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

https://github.com/nzdojo/spellchecker

Read the notes:

https://github.com/nzdojo/spellchecker/wiki/Notes-on-Implementation

‘Keep hands on, that includes the code!’

 


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.


The Importance of Shared Purpose

My latest blog is actually one written for my employer here in the United States, Code Genesys.

You can take a look at it here and is on the importance of shared purpose.  Keep practicing that because it’s hard for first timers and anyone whose experienced for that matter.  Well worth the investment in time 🙂

I have an example of a company who go to great lengths to maintain their purpose.  An old blog article written 2 years ago.


Agile before it was cool

This is a page from a great book by an important author in the software development field, Tim Gilb, called Principles Of Software Engineering Management.  It came out in 1988.

20160119_202722

The language is reminiscent of the time and the practices that were in place then, but it was ground breaking in that it talks a lot about what we call Agile Values today.  In fact Tom Gilb invented his ‘Agile’ and ‘Iterative’ EVO methodology in the early 1970s.  It’s mentioned in the book as well.  This was well before Agile became what it is today – a business.   Tom was so ahead of his time, I remember back then that Iterative development was never ever mentioned in schools and in the workplace.

And therefore, I think this Bill of Rights still holds relevancy.  I made the challenge on twitter and some thought point 9 was not relevant, rather a relic of the past.  I tend to think it’s misinterpreted in the twitter response.  Here’s the link to the twitter feed and a snap shot below.

 

There is power in this for the worker here, even on performance.  Leaders can use this to create an ethos of transparency.  Looking back to look forward.


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.

 


The Ladder of Leadership and Kanban

Here’s a comparison of David Marquet’s Ladder of Leadership which derives from his work as a nuclear submarine captain and writing his book Turn the Ship Around and then subsequent workshops and writings and the Kanban Method.

The Kanban Method says start where you are.  Other frameworks require a more explicit transformation to new roles and ceremonies.  The Kanban Method also says Improve Collaboratively and Evolve Experimentally (using models and the scientific method).  Of it’s 9 values it also states Leadership.  Acts of Leadership from every level.

A model that you can use to improve and create leadership from everyone is called the Ladder of Leadership (although not explicitly steeped in the scientific method, it is a model).  It starts where you are.  Everyone, and this doesn’t matter what position one holds, is looking to be told what to do.  This is where mostly everyone is.

The Ladder of Leadership recognizes this.  Everyone can use the model as a frame to help each move up the ladder to become more intentional.  By recognizing where someone is on the ladder whilst in conversation, a colleague can frame a question using the next rung on the opposite side of the ladder.

The Ladder of Leadership – Capt. Marquet

Measurement of success comes via a proxy from other measurements like faster cycle times, better quality (less failure demand) and people should be happier and if they aren’t something is still awry.

It takes some time to achieve this.  One must be prepared to stay the course despite the bumps in the road.  If it doesn’t work on one occasion, reflect upon that.  Realize we are humans, have a laugh and try again using what you’ve learnt.  The ultimate aim is to create leaders not followers.  Leaders can relieve bottlenecks and fix problems quicker and with more knowledge than someone further away from the problem.