Learn how I can make a difference #thatsIntelligence


read more @ www.agileatwork.co.uk

LSD? - The truth about Lean Software Development!

Hi Guys,

Yes - I thought I'd stick with the 'Hi Guys' intro for a while... see how it works out, I've been meaning to write a number of Agile articles for a while - I've covered Scrum, Kanban and now I thought I'd do a quick blog all about LSD.... I hope to eventually add all these articles to my website christianmiles.com (yes... that line was a blatant plug for my website)
Lean Software Development shares very similar concepts to lean manufacturing principles - of cause being a software developer I know nothing about manufacturing and prefer to keep my hands clean and my nails well manicured. 
For those who might think that this blog doesn't tell you everything you really need to know there's a famous book written by Mary Poppendieck and Tom Poppendieck all about Lean Software Development. The book presents the traditional lean principles in a modified form - but to be honest I'm not sure people still buy books? do they? don't we all just use Google? 
LSD can be summarised by the following seven principles:

  1. Eliminate waste
  2. Amplify learning
  3. Decide as late as possible
  4. Deliver as fast as possible
  5. Empower the team
  6. Build integrity in
  7. See the whole

Eliminate waste

If it's not an advantage to the customer/client.... it's waste! That might be bit of a literal interpretation, but actually if it isn't offering a real advantage why do it?

But basically the following list sums it up... well more or less:
  • Unnecessary code and functionality
  • Any delays in the software development flow 
  • Unclear requirements (Read 'Decide as late as possible')
  • Insufficient testing  
  • Bureaucracy (My personal favourite) 
  • Slow/inefficient communication

It's also worth reading by blog about Kanban (yes... another plug!)  and see if lanes can used to help to identify bottle necks! and also remember when it comes to eliminating waste.... take an iterative approach! have regular retrospectives! You can't won't do it in one attempt and overtime new inefficiencies will sneak in that need identifying and eliminating! 

Amplify learning 

Software development is or probably should be a continuos learning process!

Look at ways that you can learn from the process to 'Amplify Learning'! Running tests and demonstrating software as soon as it's developed is a really good way on cutting down on defects and the lengthly process of defect fixing and retesting! this is really important when working in sprints when development and testing does tend to get disjointed!

User requirements can be improved my mocking up screen shots and walking through with the client before a single of code is ever written!

Short iterative cycles of development and deployment speeds up the feedback loop.

Customers and IT teams should sit together and go through the system... thus aiding understanding on both sides.

Open dialogues should be promoted between all members and clients.... and an open culture... forget about the blame game! if you want to encourage openness, transparency and 'Amplified learning'

Decide as late as possible

Software development isn't really an exact science... in my view it's more on an art! (some people might argue with that point) but software development is always associated with uncertainty!
The more complex a system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. Take an  iterative approach and remember you NEED to have the ability to change!  
An agile approach can move the building of options earlier for customers, thus delaying certain crucial decisions until customers have realised their needs better!

This DOES NOT MEAN that no planning should be involved!!!! on the contrary, planning activities should be concentrated on the different options  as well as clarifying confusing stories by establishing patterns for rapid action.  

Deliver as fast as possible 

Well everybody loves this one, don't they!... especially the PM!
The sooner a product is delivered without 'Big' defects, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. 
Taking this approach also feeds into the 'Decide as Late as Possible' mantra and as your client receives what they want/need now.... not what they wanted last month or more likely last year! which also means that mistakes are discovered sooner and fed into the next iteration! Remember the cost of defect curve that you probably studied in Uni, 
Also... and I think is often overlooked but from a personal perspective... as somebody who loves a bit of PR and creating a buzz around software releases it gives me the opportunity to 'boast' about every release iteration rather than just once at the end! Why have one good news story about delivering a project when I can tell the story half a dozen times?

Empower the team

This is scary for most managers and PM's - You just can't trust a team to organise themselves! and if you turn your back on them...... 

It's scary how many managers try and micro-manage every aspect of their teams! - telling 'Workers' how to do their job! when to do what and who does what! These managers are living in a bygone era (sorry if anybody reading this is one of them, well actually I'm not sorry - you are!)
STOP viewing team members as resources... or product units or slaves! Software developers although scruffy and shy and usually a bit arrogant really are skilled professionals!  Yes they are and deserve to be treated as such! A well motivated team is a real asset! p1ss them off and you will loose their good will and in such a buoyant market  they will leave! or at least the good ones will!

Trust your team to self organise, to decided how to deliver and collectively commit and 'buy in'

Build integrity in

The customer is after an overall experience of the System – apparently this is now called 'perceived integrity' it covers how the product is advertised, delivered, deployed, accessed, how intuitive it is, price and how well it solves problems. (I must admit I had to Google that)
There are an awful lot of fancy buzz words in this part of Lean development... you might want to research 'Free from flaw' , 'Free from defects' and 'Free from Decay' - To be honest it's all a bit complex isn't it... but having a well groomed ordered back-log where the client/product owner is actively involved should help to achieve these points.
And also, Don't forget to Refactor -  refactoring is a brilliant term!! when I was a young COBOL developer (last century) I used to call it not getting my code right first time and I need to go back and re-work it! Today I can tell people that I'm refactoring the code base! That sounds far better and my boss walks away nodding his head knowing that refactoring must be really important and its a good job I'm on the job - phew... one of the advantages of being more experienced and senior is that I now know the right words to use! 
But honestly as more features are added to the original code base, the harder it becomes to add further improvements. Refactoring is about keeping it simple!! (I like to think KISS - but that says more about me!)

See the whole

Software today is ridiculously complex!!  - remember why you are developing the product and who the client is! also remember that commercial software isn't a university project that shows off how clever you are! It's about solving a business problem in a cost effective manner... actually it's about making money, saving money or gaining a competitive edge - which equals money! 
Try and decompose the big tasks into smaller tasks, The larger the system, the more organisations, teams, departments that are involved in its development and the more parts that are developed by different teams, the greater the risks become and the importance of having well defined relationships becomes apparent!

Once again think about how to empower your teams! and strive for good communications and openness between teams! insular thinking has no place in a modern IT department and nor for that matter does dogma! I fairly recently had an interesting argument/discussion/robust conversation with a team that flatly refused to assist because by doing so would break their rules! a rule that nobody could sensibly explain the reason for having... but it was a rule and therefore could not be broken! tough if the customer has to wait another month! dogma is a sure way to make any IT team look and become irrelevant to those who pay our wages (once again it comes down to money)

And finally you've reached the end or some of you hopefully have! Sorry this has been a long blog hasn't it! I'll try and keep the future ones short, snappy and perhaps interesting!

"Think big, act small, fail fast; learn rapidly"!

Christian Miles