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

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.

Continue reading

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. Continue reading

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. Continue reading

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. Continue reading

How many ways can you code

lean kanban

Not surprising our leaning towards manufacturing, given the budget production line obsession of business towards development.

The recent story on the cheapest meal, put me in mind of some dole/student classics. Poor mans pizza was rice and ketchup. Anything new can taste interesting, as with the toast sandwich. But you will find after 2/3 experiences, that culinary surprise will dissipate into reality of cheap vinegary tomato flavoured starchy rice. Adding tuna will allay that feeling for a few more meals but ultimately you have to spend more and more to get it to taste nicer. By which point, you may as well have gone for making a decent budget casserole or lasagne.

Basically, you can go too cheap. And many saw Agile as a way to do it on the cheap – why? Because the traditional structure of a project was changed, with generally less roles which immediately followed was less people.  First error – assume downsizing was part of Agile solutions!  They don;t need repeating, but the 4 core statement in the Agile manifesto were:-

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Of the four core Agile Manifesto directive, the overall experience for myself was that: (1) was done the wrong way round, (2) highlighted development wasn’t that agile, (3) companies couldn’t separate the two and (4) led weak/poor project management.  My favourite of the principles regards development was: Continuous attention to technical excellence and good design enhances agility.   For myself, Agile was about doing things better, not doing things cheaper.

With Lean, there isn’t so much room for subterfuge or being dogmatic.  A startup illustrates to benefits of Lean (and Kanban), as it is more given to dynamic decision-making and calculated risks. Whereas Agile collated principles from existing, though disparate, methodologies; Lean has far more focused sense of continium and improvement – not principles for development but any kind of engineering, where the process to produce a product is just as important as the product.  To manage such a demanding development flow, Kanban provides ideal based to manage a project.  The “Work in Progress” principle behind Kanban, illustrates acknowledgement how rapidly things can change, and the balance work evenly and maintain a realistic map of progress.

Lean and Kanban are deceptively simple, because of course as we all know, management is by far the riskier element on modern web projects.  It takes skill and ability to think on your feet.  Some of us actually enjoy that!