lean (7)


The methodology elastoplast

Does methodology really make anything any better? I think it’s better to latch onto the principles that underpin Lean, Agile, Scrum et al. The principles are sound software engineering and project management ones. Ones that predate any of the current favourites. Iterative and incremental development, continuous integration, automated testing … these have been around for decades. If you need an analogy, think of true innovators in tech – it isn’t Apple, Microsoft, Facebook etc. They used what was already there, and commodotised them effectively. Who invented C, or the GUI, or the mouse? Does anyone care? Iterative and Incremental development has long history ….

[blue_box]IID [terative and Incremental Development] grew from the 1930s work of Walter Shewhart, a quality expert at Bell Labs who pro-posed a series of short “plan-do-study-act” (PDSA) cycles for quality improvement. Starting in the 1940s, quality guru W. Edwards Deming began vigorously promoting PDSA, which he laterdescribed in 1982 in “Out of the Crisis”. Tom Gilb and Richard Zultner also explored PDSA application to software development in later works.

Computer Iterative and Incremental Development:A Brief History[/blue_box]

I particularly like the fact it was a QA guy behind it – it makes total sense that evolutions of quality and efficiency in coding would come from QA. QA is another area that in fact does not care what badges people carry. We adapt, recommend but ultimately work to same goals of code quality and client satisfaction – and the two are not mutually exclusive. You don’t have to sell good coding, but showing actual coding. It often manifests in performance, usability and maintainability – words a client will understand. Whilst I am a little weary of the same circles that happen with the saleable methodologies, one approach rejuvenated my interest in newer development practices, which as you can tell from most posts over last year, is BDD – Behaviour Driven Development. It can be viewed as a strict Lean approach – the stripped-down development/client model. I like Lean – there is little room for “project wallflowers”.

Ironically, I have been on Lean projects, where management heavily outweigh the number of developers. Such is the pull of these buzzwords, management gravitates towards them like moths to a “another skill for the old cv” flame. I have said it many times, that fundamentally things don’t change that much – a strong team with good cross-functional skills will cut through any methodology bullshit and deliver. My opinion is that it is management that lagged behind, and is still area that can do far more damage than a bad developer ever could. But it is still not seen that way round. If all a manager is doing is acting as interface with a client, then they are simply an obstruction – by Agile or Lean philosophy. Empowering the team does not mean empowering their manager.




[blank] manager

  • December 18, 2013
  • Agile, BDD, ...

I believe the problem with the implementation of many of the software development approaches (both fashionable and unfashionable), is the focus on management over development, when applying them. This is endemic of issue with business world in general, and older concepts of management struggling with newer concepts of a different structure new development approaches demand, which relies on technical and soft skills, over line management and reporting processes.




It’s not like the good old QA days …

I am starting to think those of us who grumble about misuse of term “QA” (Quality Assurance) are maybe in the realms of grumpy old men/women. I now beginning to realise that yes, people use the term far too loosely without thinking it through. But more is expected of the tester these days, than simply testing – and those expectation do fall within the realm of Quality Assurance. Quality Assurance and Testing used to be distinct areas, though testing came under the overall remit of a QA manager, as it’s a quality gateway task.




Lean Runner

I like running late at night, past 11pm. It adds a new dimension to the running, by relying more on the senses, as they become more alert at night, with primitive expectations of danger and challenge. There are less pedestrians at night in London, but still busy with cars, and more challenges to the brain and sense. Cities are less safe at night, and less predictable. You need to have ability to think ahead (if you don’t want to stop moving). I see plenty of runners happy to stop at pedestrian crossings – gives them time to browse their media players.




End-users as security testers

Increasingly security testing of web applications are left to the end-user to discover. The web is generally seen as an imperfect thing, so it is not surprising that most users do not expect a website that works well 100%. What I have seen on the best Agile and Lean projects, is this is omitted to much further down the cycle, if at all – but why? Yes, they are skilled testing areas (and hence higher cost to secure fully skilled resource), but there is a lot that can be done, with the right tools and approach.