We have so far seen a couple of schemes for identifying clusters in sets of data which are subsets whose members are in some sense similar to each other. Specifically, we have looked at the k means and the shared near neighbours algorithms which implicitly define clusters by the closeness of each datum to the average of each cluster and by their closeness to each other respectively.
Note that both of these algorithms use a heuristic, or rule of thumb, to assign data to clusters, but there's another way to construct clusterings; define a heuristic to measure how close to each other a pair of clusters are and then, starting with each datum in a cluster of its own, progressively merge the closest pairs until we end up with a single cluster containing all of the data. This means that we'll end up with a sequence of clusterings and so before we can look at such algorithms we'll need a structure to represent them.
Officer: Well why don’t you move into more conventional areas of confectionery, … I mean look at this one, ‘cockroach cluster’, ‘anthrax ripple’. What’s this one, ‘spring surprise’?
Shop keeper: Ah – now, that’s our speciality – covered with darkest creamy chocolate. When you pop it in your mouth steel bolts spring out and plunge straight through-both cheeks.
That like Agile to me. In AgileLand everything is sweetness and light. Agile has all the answers. Everything works. Agile is utopia.
I’ve taught enough Agile Introduction courses to know this is so – and pushed ti too. There is no scenario I can’t fix in the classroom with the application of the right Agile principles, tool or mindset. And if I can’t… well in that case, Agile is helping you see the problem more clearly and you have to find your own solution.
Honestly, part of the appeal of Agile is that: Agile is a damn good story. Agile paints the picture of a better world, and so it should. Particularly when delivering an Agile training course I see my role as two fold:
In-part enough information so that teams can actually try Agile
Energise people to want to try it this way
Except, there are some dirty little secrets in the Agile world which do’t fit with this picture.
First up is Micromanagement (#1).
As I said in Devs Hate Agile, the Agile toolkit can be used for good or evil. If someone wants to be a micro-manager par-excellence then Agile – and particularly Scrum – make a great toolkit for micro-management too.
The intention behind the Agile/Scrum approach is to give those who do the work the tools and approaches to take control of their own work. When they do so then great things happen – the workers control the means of production! However those same tools can be used by very effectively by those who would control the workers.
What micromanager would not want every team member standing up to justify themselves at 9am each morning? Surely a micromanager would want working software at every opportunity? – and if you fail to deliver working software then…
In part this is because Agile is a great tool for apportioning blame (#2). When builds fail you know who did the last check-in. when tests fail you know who broke it, when cards don’t move on a board, sorry I mean Jira, then the powerful can hone in on those not pulling their weight.
Kanban is even better than Scrum here. I remember one Project Manager who used the Kanban board (26 columns!) we constructed to demonstrate why everybody apart from him was slowing work down. Try as I might I couldn’t get him to see each of problem to be worked on. To be fair to him, he was the product of a system where almost every step was undertaken by a sub-contractor, he had no power to change or reward sub-contractors, only to whip them.
Both these points illustrate the second dirty little secret: you don’t need to do everything (#3).
Simply holding stand-up meetings and end-of-iteration activities is a massive improvement for some teams.
Developers who adopt Test Driven Development will produce fewer bugs, waste less time in the debugger, and the testers who come after them will spend less time reporting bugs. Thus fewer bugs will need fixing and schedules will improve.
A Kanban board with WIP limits will improve workflow even if you do nothing else.
Yes, if you do every part of Scrum things will get a lot better.
And if you do every part of XP the total benefit will be better than the sum of the parts.
Part of the genius of Agile is that it can be implemented piecemeal. But that also means organizations and teams can stop. I’ve seen this a number of time: I introduce a bit of Agile, the immediate pain is relieved and the company looses the will to go further and improve more.
After all, who am I but an external consultant to tell them they could do better?
Once the pain if gone then the need to change goes too.
Now some dirty little secrets are being exposed. Most readers will know I have been active in exposing the dirty secret of Agile Project Management: the idea that Agile and the project model (aka project management) can work together.
Sure they can work together but… why? what is the point? Why go to the trouble of integrating Agile and Project Management?
Once you start working Agile the project model looks absurd. Hence #NoProjects – and why so many people have arrived at the same conclusion about projects independently.
In fact, it goes further than that. Companies that introduce full blown Scrum – including self-organizing teams – risk destroying themselves. In traditional, top-down, hierarchical companies Agile and self-organizing teams must be contained otherwise it will destroy the whole hierarchy. That is why banks struggle with Agile, the chocolate on the outside is really nice but sooner or later what they are eating runs up against what they are.
Finally, you might notice that in this post – and indeed in many of my other post – I don’t agree with other Agile advocates. Go and read Jeff Sutherland (I don’t agree over self-organization), Mike Cohn (I don’t agree over stories and points), Keith Richards (not the rolling stone, the APM man, I don’t agree over projects), Jim Coplien (he doesn’t agree over TDD), Joanna Rothman (we don’t agree on stories), Dan North (we don’t agree on teams) and just about anyone else and you’ll find I don’t agree 100% with anyone.
But the thing is: none of these people agree with each other.
Everyone in the Agile communities interprets it slightly differently.
The final dirty secret of Agile is: the experts don’t agree – there is no one true way (#5).
I feel sorry for new comers to Agile who expect to read the one-true-way but I’m also saw none of us “gurus†would want to any other way because we want variety and experimentation. And perhaps that is why one-size-fits all Agile scaling is always doomed.
Frog image credit: Argentine Horned Frog by Grosscha on WikiMediaCommons under CCL ASA 4.0 license
Like this post? – Like to receive these posts by e-mail?
Technological innovation allows organisations to do more with less. As well as improving innovation and productivity, new technologies will help us with some of the key challenges ahead – making better use of limited resources like energy and water, mitigating the effects of climate change on food and poverty, disease prevention, and improving healthcare for an ageing population.
Technological innovation has generally been a powerful force for good, creating new jobs and improving salaries. But new technology also threatens jobs and whole industries, with devastating consequences in some communities and with the benefits unevenly distributed. So is the future utopian or dystopian?
Whichever, technological change will continue, so If we are to realise the potential of new technologies, like artificial intelligence and machine learning, we will need responsible innovation approaches and new regulatory frameworks.
We will need to develop future technologies using multidisciplinary perspectives and methods so that we better consider the future of work, protect our privacy and data, build consumer trust, and respond effectively to ethical and safety issues.
Norfolk Developers are facilitating this by bringing together its members and speakers to debate and shape a healthier technological future.
1.JPG){kind=link}