The repetative (sic) steps that a single worker performs on an assembly line is a good example of a simple task

This is a terribly Fordist/Taylorist view to take of assembly work. That most beloved of industrial examples, Toyota, takes weeks to train its process-line workers to be able not only to do the simple repetitive steps of assembly, but also to be able to identify and rectify problems with the assembly-line. As Steven Spear, author of Chasing the Rabbit (my review here) might say, anyone who thinks that “assembly line” work is simple task probably doesn’t understand the nature of their process enough to keep up with their more innovate competitors, let alone outdistance them. Understanding your process, well more importantly, your organisational goals and how your process does or does not fulfil those goals, is critical to improving your organisation, and it leads me onto the idea of “evangelism”.

I both agree and disagree with Coder Friendly’s position:

Don’t become an evangelist yourself : look at your project and decide which methodologies is the most adapted. Sometimes, Agile is not the right one but if you see that your requirements are far from agreement or certainty, Agile approaches are probably a good choice.

I agree that “evangelism” can be politically off-putting.People don’t react well to being told their old kool-aid contains poison, and to uncritically drink this new kool-aid instead. However the main problem I have with a statement like this is that non-Agile companies use this “adaptation” argument and approach, in order to keep their poor contexts alive. This is the fallacy that’s found in ‘scrum butt’: “Oh we do Scrum, but …”. The clauses after the ‘but’ are typically critical. The organisation concerned is usually trying to keep some essential organisational dysfunction alive, because of politics, resistance to change, simple misunderstanding, lack of understanding about their own process, or maybe even simple laziness. I’ve got no problem with an organisation that is mature in its use of an agile method adapting it to their local circumstance – in fact if you are doing it properly, with its emphasis on empowering teams to own their process and carrying out regular ‘inspect and adapt’ at the end of every iteration, after six or twelve months of this the process will most certainly be adapted to the local conditions.

However, the real danger is at the start of the agile adoption process, when you have people hand-waving about “can’t do that here”, for whatever value of that there is. I’ve seen it said about: pairing; story boards; acceptance criteria; automated testing; retrospectives; daily stand-up; adaptive and emergent design; and just about every other aspect of XP or Scrum process. The reason is, I think, that these organisations rarely understand what the real organisational goals actually are, and they understand even less about their existing process, to the point they just “do” the process that “is”. “It is what it is”, is a great term, and if anyone says this to you it’s just a fatalistic attempt to accept as unchanging something you can change. Accept the bad. Don’t think it could be better.  Attempts to meddle in the process, i.e. change it, induce fear, and with fear often comes timidity.

This is where you need a real agile evangelist. This is not someone who just thinks that Scrum or XP or whatever other process should be blindly substituted for the existing one, but someone who understands that process is about competitive advantage, eliminating waste, and that you have to start from a known position and continuously work towards improvement. Change is not just good, but necessary, and you need those change agents. Passion for doing things better is bad? Only in a change-averse company. So learn your existing process, thoroughly, and then learn the proposed agile process, thoroughly, and only then will you be able to ‘synthesise’ a replacement. Only I think you’ll find that replacement will look a lot more like the plain old agile process than your existing unagile process. After all, if your existing process already has adequate inspect-and-adapt cycles within it (not lip-service ones, real ones), probably you are already doing and agile or lean process even if you don’t call it that, and you’re already number one in your marketplace. If not, perhaps you require the passion of an evangelist.

First, I no where made any “assertion that if you are putting ‘//TODO’ markers in your code, you’re somehow not properly following the Scrum process” – I said if you find yourself using ‘//TODO’ markers in your code you are being prevented from getting to done-done and that you should “Identify the problem, propose a counter-measure and fix the process“. I can’t emphasise that enough. “Fix the process” does not mean “follow scrum” but rather to use your team’s collective brain to work out what stops you from fixing the code then and there and propose a solution to the problem.

I think ‘//TODO’ should either be in the current story (I will concede that you might want to use a ‘//TODO’ to remind yourself about tasks in your current story, i.e. “come back here tomorrow when I add the validation”) or in the “backlog”. I put “backlog” in quotes there to point out I mean “backlog” in the broadest sense, if you using Scrum or XP that’s actually where the work-to-be-done is physically kept, but if you have some other process then your “backlog” is kept somewhere else, and what is preventing you from adding to it?

I will ask a question of the anonymous poster – at what point exactly  is a ‘//TODO’ comment left decaying in the codebase without a story for days or weeks a good idea? Or is it that you just do not want to make what it is being done in the code base transparent to those who are paying your bills?

I will contend; ‘//TODO’ never gets done because the product owners never see them. They act as an opaque barrier to open communication. If you find a ‘//TODO’, lets say a big major refactoring will be needed to support a story you already see in the backlog, what’s the problem with having an open and honest communication with the team about the story’s estimate? If it’s a future story, i.e. feature related, it should be in the “backlog”; if it is code or design related which impacts you now, either it should be done then and there (refactor mercilessly) or it’s a bug which you either fix or raise a bug report for, and if it’s just some nebulous “improvement” either do it now or YAGNI. If you’ve got great tooling like Mylyn for Eclipse you can drop a “task” at the code point and move on. The point there is the “TODO” isn’t obscured away in the code but rather visible to all because the ‘//TODO’ is now either in your Wiki, your task-tracking tooling via it’s Mylyn integration, or is included as part of a story card on the story board.

If you can’t refactor mercilessly – what the post is really about – all the usual excuses apply, i.e. “we’re not confident about the code base not breaking in unknown ways” (i.e. no tests), “it has to be done by tomorrow,” et cetera, and all of these are symptoms of dysfunction in your organisation.

People love their little comfort zones and they don’t like being pushed out of them, that’s for sure, programmers included (yeah, and that’s a me too). Habit is not an excuse for avoiding improvement.

Here’s a great imaginary conversation from the C2 wiki entry about YAGNI that I think applies here:

“But Ron, I know how to do it right now, and later I might not.”

“So, Sam, you’re telling me that this class you’re writing is so complex that even you won’t be able to maintain it?”

Firstly, I found the second day much better than the first. I did see Michael Nygard’s two talks on Monday morning and got a lot a lot of useful information from those. Titled ‘Failure comes in flavours’ the first was a great overview of the types of failure that applications running in production encounter, the second ways to avoid those failure modes. Basically it’s how many of the non-functional requirements can eat your app (and even the entire integration if you let the failure propagate easily) if you don’t give careful consideration to them. He’s got a book so I’m going to check that out next.

The first day for me was severely spoilt by a poor vendor presentation (hint: one that is not Oracle, not that they would have necessarily done any better), which I should have known better to avoid. I already swim in the BPEL/BPM/SOA soup, I fully understand just how broken it is as an actual development concept (e.g. anti-test-first to name just one). I was fooled by the title to thinking maybe it had some insights to avoid the worst of these busted concepts, but no, the vendor’s tooling is all the rage if you drink the poor-tasting conceptual kool-aid. This stuff is marketed at managers and non-coding architects who choose to buy this stuff then dump it from a very great height into the laps of the poor developers who have to mangle it into a deliverable system (half the time with a development budget just a tenth the cost of the licence). Anyway back to the good stuff.

Mike Cannon-Brookes from Atlassian (which makes great development tools, highly recommended) gave a mostly great closing speech on the first day which made me think about a couple of things. It wasn’t until the next morning however that it crystallised in my mind. It’s a bit of a minor criticism.

Mike threw out a minor line, an aside really, talking about Atlassian’s agile development methodology, and basically that said, people who say ‘you must do this’ are wrong, because they miss your context. Here ‘this’ is some type of agile process artefact like maybe, pairing, or estimating in story points, or whatever. Well, it’s wrong and on two counts. The first count I realised just after the talk but couldn’t articulate it correctly in semi-drunken conversation. That first count is very simple. Mike’s timeline on his Atlassian experience has him, if I recall correctly, starting his company and creating the great tool Jira, in his early twenties. Now as he dissed “old people” in his talk I’m going to give some back. In your twenties you’ve got no idea what works, in a general sense. You might know (or think you know) what works for you, but that’s a completely different kettle of fish to what works generally. Why not? The word is experience. Its not until you reach … oh … I’ll say around 35 (and so maybe lose the capacity to build technical innovation, perhaps, as Mike asserted) that you can have real insights into process and people. It’s just because at this point, you just have not got enough practice at it (see Malcolm Gladwell’s recent book for some basic data about the power of practice).

But the bigger point I think is the word context. The phrase ‘my context is different’, is this classic phrase which really means ‘that won’t work here’ and that really means, I don’t want to change. As a consultant , you hear this stuff all the time: … “We’re unique, our company is not like those other companies. We can’t do that here. Detailed estimates are really the most important part of the development process. The budget and the features must be fixed. We have a reporting process that allows the budget and features to be fixed. Pair programming doubles the time it takes to deliver the features. Quality doesn’t matter. Technical quality is a business decision. The business are too busy to talk to you.” … And a whole other other bunch of epic agile fail. Someone’s context is exactly why they aren’t as agile as their competitors and are looking at using ‘agile development’ to help save them … but as long as they insist on my context trumps all, they will only get a fractional improvement and not an order-of-magnitude one. But Atlassian make great products, so it doesn’t mean you have to have ‘scrum’, or ‘XP’ to do that, the greatness I guess, is orthogonal. However if you are looking to ‘do agile’, then do agile. Pick a method like Scrum or XP then do it all. How do you know pair programming will fail in your organisation if you don’t try it first? You don’t. Do it like it says to do it (e.g. the Kent Beck books) and after a few months experience for your team, use the lessons from the retrospectives that the team has discovered to improve the process. Do not cripple the process with your ‘context’ before you even try.

And right on cue, on the second day along comes Steve Hayes with a great presentation on exactly this topic: “How your choices affect your agility”. Steve is a fantastic speaker, entertaining and pretty insightful too I thought. I rated his talk the best talk of the conference. He said he got lots of red cards (participants could rate each talk as green==good, yellow==ok, red==bad) in his Sydney session – what is the matter with your people? It was a great talk. I loved the part about naivety. To propose a solution from the most naive perspective possible, and what an epic win it is when a customer says “ok”! It means I understand the problem! I even tried this today with my client, I didn’t get the instant “OK” but working from the basis of that incredibly naive solution we did manage to eventually envisage the simplest thing that could possibly work. And I love that. So thanks tons for that insight, Steve!

Another great talk on the second day was Linda Rising’s ‘Deception and Estimation’ talk. Turns out (via psychology and evolutionary biology) we engage not in rational decision making but in emotional choices all the time. All choice is emotional. So we engage ourselves in self-deception all the time. And none of this is bad … it’s good. People who don’t engage in this constant self-deception are generally clinically insane. So get over it, and yourself, and when you’re estimating (and from the sounds of it, doing any sort of major-impact decision making) and get as many perspectives as you can from the most diverse range of people you can manage (to avoid groupthink, which is I guess, the situation where everyone’s self-deceptions all align). Joshua Bloch’s second-day keynote was also highly worthy of praise. Good insight and excellent effective code examples (yes, in a keynote). Also worth the greatly discounted entry ticket price was the many interesting conversations I had with past colleagues and new friends on many different development issues.

In short, JAOO was generally of very high quality and I hope is keeps coming to Brisbane! Will definitely be going next year. Many thanks to all the organisers, presenters and sponsors.

Link: http://www.viddler.com/explore/sergiopereira/videos/7/.

Sprint to the lead in your industry – and stay there!

So says the back of the dust cover on Chasing The Rabbit: How market leaders outdistance the competition and how great companies can catch up and win by Steven J Spear (McGraw Hill, New York, 2009). I referenced this book last week in my post ‘Let it fail then learn to succeed’ which is about using failure as a signal for process improvement.

It’s a great book. Obviously it is not addressed directly to software development, and as I said, Spear covers its application in a range of different settings, including engineering and health-care as well as manufacturing. There’s a distinct lack of focus on the buzzwords kanban, kaizen, and just-in-time, all of which Spear says are merely artifacts of a deeper underlying approach that he proceeds to illustrate extremely well in the course of the book.

The approach might be illustrated by the asking of some fairly simple questions: ‘What did you do?’, ‘What happened then?’, ‘What did you expect to see?’, ‘Was it successful?’, ‘What did you do to correct it?’, ‘What did you learn?’ (my list is not exhaustive). Spears characterises it as:

… a systematic approach to designing and operating systems, a simple set of rules for problem solving and improvement, a clear way to share learning, and a well-defined role as a manager. (p 358)

More formally, the organisation exhibiting these qualities shows two characteristics and four capabilities.

Two characteristics:

1. Managing the functions as parts of the process. A high-velocity organisation orientates its processes away from functional ‘silos’ (without ignoring the necessary competency of individual functions), and towards “the way the work of individuals, teams and technologies will contribute to (or impede) the process of which they are part” (p 20). For example, Spear describes his own experience while at Toyota: he is asked what a particular factory he is being trained at makes. At first he interviews the management of the factory, and returns with a list, only to be told he doesn’t really know. Then he looks at invoices of the shipped items, which is still said to be wrong. In response to this, he examines what the receiving factory actually paid for, but he is still told he doesn’t know what the factory makes. Finally, he stands at the shipping dock, as as each shipment was sent out, ignoring the shipping label, took a note of the part number stamped onto the part. Then he checked that the factory actually possessed the die for stamping the part number. In response, he was told; “Well, that’s probably not wrong. But I have another question: How are these parts made?” (p 280).
2. Continually improve the pieces and the process. High-velocity organisations are always learning about all the work they do. Workarounds, tolerating problems, putting out fires, and heroic efforts are simply not tolerated. Every time you have to put out a fire, or devise a workaround, or engage in a heroic measure to get work done, you’ve found a process problem that should be eliminated. Your highest priority isn’t engaging in the workaround, or performing heroic efforts of late-night last-minute production delivery effort. Your highest priority, and that of your management, is swarming the problem to fix the process that led to the situation. Doug South described it to me as “not tolerating things”. Instead you should fix their causes rather than developing a workaround to the immediate problem.

Four capabilities:

1. Specifying design to capture existing knowledge and building in tests to reveal problems. Make explicit the most effective approach currently known to you to successfully achieve the task. Make sure that the approach has the capacity to detect failure as soon as it occurs. You need to be sure what outcomes you expect, not from a “perverse Taylorism” (p 23) but as an investment. By specifying expectations, you can more easily capture when something unexpected happens – that is, what the gaps in your current knowledge are. Go out of your way to build in these tests. Alcoa for example, focused exclusively on improving safety – with the goal of zero injuries, because this “meant perfect processes based on perfect knowledge of how to do work” (p 94). The test therefore, was the occurrence of workplace accidents. When an accident occurred, it highlighted a dangerous ignorance, and had to be rectified.
2. Swarming and solving problems to build new knowledge. When you encounter problems, at the time and place of the encounter, the problem should be swarmed. Contain the problem to prevent it from spreading. Diagnose and treat the cause so the problem cannot reoccur. Problem-solving skills are built by solving actual problems, and those doing the work are responsible for improving the process by which the work is done. Doing this will allow you to “build ever-deeper knowledge about how to manage the systems for doing [your] work, converting inevitable up-front ignorance into knowledge” (p 24). For example, at Alcoa, it was made a rule that business-unit presidents had to not only inform the Alcoa CEO within 24 hours of an injury or injury near-miss, “but within two days they had to report what the initial investigation had revealed about its causes and what was being done to prevent the problem from recurring” (p 96). This ensured a discipline, a warp-speed cycle involving real-time problem recognition, diagnosis and treatment.
3. Sharing new knowledge throughout the organisation. It’s not just that you learn. It’s that the entire organisation learns. Toyota did this for a joint-venture plant it created with General Motors. Toyota’s approach was a one-variable-at-a-time tuning. The American plant would make an existing model and not an all-new car. Rather than creating an entirely new plant, or swarming the old GM plant with Toyota managers, it took newly hired American managers and coached them in the Toyota way. They didn’t just drop them into the plant. They first made similar products (Corollas) at a Toyota plant. Then they went back to the American plant and Toyota gave the new managers continuous support from Japanese experts. The joint-venture plant was far more successful than the old General Motors plant it replaced. In 2003, in order to be abale to accelerate organisational learning, Toyota created the Global Production Center, which was staffed with experienced cadres of trainers in areas identified as critical to production success. They developed standardised practice equipment and had other groups test the new equipment to identify problems with it. And because these practices are orientated around the discovery of solutions via practical experimentation, and rapid cycles of concepts and validaty testing, they can “smoothly converge on solutions that were agreeable across disciplines” (p 253). Having done all this, it shared it’s newfound knowledge with representatives from factories around the world, and trained managers and group-leaders who were setting up a similar centre for Toyota’s North American operations. Just as important as creating new knowledge and sharing information about particular capabilities, it’s just as critical to spread problem-solving capability throughout the organisation.
4. Leading by developing the first three capabilities. Managers are not there to measure, berate, and exhort their workers in a command-and-control environment. The role of management is to ensure their organisation becomes “ever more self-diagnosing and self-improving, skilled at detecting problems, solving them, and multiplying the effect by making the solutions available throughout the organisation” (p 26). The process of finding out what the plant made which I outlined above was part of learning this fourth capability by observing a system at four levels – output, pathways, connections and activities.

At the end of the book is an illuminating conversation about golf. Now personally I can’t stand golf but I suppose lots of middle-aged businessmen do, and the conversation was about the simplicity of the game. Despite protestations about bunkers, traps, and hazards, roughs and fast greens, and how difficult it really is, in the end it’s actually a simple game with very simple rules. Keep hitting the ball with a club until you get it into the hole. Simple rules that require a lot of practice to do it right. And like golf, making your organisation high-velocity might run with a fairly simple set of rules, but they require a great deal of practice at the various skills needed to make it happen.

That gives a general overview of the content of the book. It’s written in a very accessible style which communicates the essential concepts very well without trivialising them. If you are a software developer who is interested in thinking about development process, and general business process, then I definitely recommend this book. Sometime in the next few weeks I will try to produce a further post relating some of these specific concepts that Spear has identified and apply them to software development process. In the meantime, buy and read this book.

It maps the various agile practices like TDD, Iterative Development, Retrospectives, Backlog, Continuous Integration, User Stories and so forth onto common business categories like Increased Quality, Process Visibility, Repeatable Process, et cetera, in other words, shows you what sort of business issue each agile practice is aimed towards. I don’t think it’s perfect (veers off to a house-building metaphor, for example, which I don’t think is completely successful). It doesn’t also contain a section explaining the overall reasons and philosophy for Agile development. However for a manager who is thinking about Agile, and is confused about some of the jargon they’ll hear from experienced agile practitioners, it does a strong enough job at mapping the practices onto traditional process management categories for me to recommend its reading.

“Oh, my God! You’re going to let a sprint fail, just so you can determine the optimum length?” Yes.

In other words, failure lets you learn your limits. But more importantly, as suggested here, is that failure can be deliberately introduced in order to improve the process – to decrease your limitations. I would say, for an organisation committed to process optimisation, you should shorten the sprint until it fails, but rather than just accepting that limit, learn why it fails and then experiment with optimising it until it succeeds. Let me explain.

Courtesy of a tip from Doug South at the Brisbane XP user’s group, I’m nearly finished reading a book at the moment, Chasing the Rabbit by Steven J. Spear of MIT and formerly of Harvard. The book’s full title is Chasing The Rabbit: How market leaders outdistance the competition and how great companies can catch up and win. It’s a business book that describes the essential feature of successful companies such as Toyota and the Toyota Production System.

Before you roll your eyes and think I’m just another one of these lean software guys who’s about to rave over kanban, kaizen, and just-in-time, and applying manufacturing production-line process, possibly inappropriately, to the professional practice of software development, let me assure you I’m not. Neither does Spear. Basing his book on years of hands-on research into these high-velocity organisations (including time spent actually working on real production lines) he characterises kanban and friends as merely an artifact of a deeper philosophy towards building a successful company. In some ways its breathtaking simple, although hard to practice. The theme of the book is discovery.

The factory was not only a place to to produce physical products, it was also a place to learn how to produce those products and – most important of all – it was a place to keep learning how to produce those products. In fact, this is exactly what so much of the early research about Japanese management had revealed – that learning and discovery were intrinsic to success. But that idea had gotten lost as people focused on the particular tools and artifacts used in the workplace at the expense of understanding the principles of how those systems where managed. (p 15).

These companies don’t succeed or fail. They succeed or learn to succeed.

Now it is of course slightly more complex that just that. There are two characteristics and four capabilities that high-velocity organisations exhibit. The four capabilities are:

1. Specifying design to capture existing knowledge and building in tests to reveal problems.
2. Swarming and solving problems to build new knowledge.
3. Sharing new knowledge throughout the organisation.
4. Leading by developing the first three capabilities.

Now these capabilities can be developed – in different manifestations – in any sort of process, not just production-line processes. Spear shows it in action in health-care, in nuclear engineering, in aluminium production, and of course automotive production. I’ll into further detail perhaps in a later post. Here I’m going to discuss a simple example illustrating not just capability 1, in which a process not only captures knowledge but has built-in tests, and also capability 2, involving problem solving and process improvement, where the process is tested to failure, in order to reveal what knowledge is missing about the process.

In the book he describes a mattress factory, Aisin, that, after a long capability improvement process ends up with two production lines each capable of making (e.g.) 100 units a day to custom order. On some given day, imagine they have a requirement to make say 180 units. Rather instead of running one line at 100 the other at 80, or both at 90 units, they will instead deliberately overload one of the lines (e.g. ramp it to 110 or 120 units) in order to discover the process failure modes (that is, the process’s bottlenecks) so as to to improve them. They already know how to make 100 units a day. They can learn more about their process if they try to make 120. The reason they do this on days of lighter loading, is that the can use the unstressed production line as a back up, if the test was too stressful for the line under test.

Experienced software engineers might recognize this stress testing from their performance testing toolkit. Loading a software system to the point of failure is one quick way to learn where a system’s bottlenecks are, and what to do about eliminating them, and thus making your software architecture more efficient, and discovering new knowledge about how your architecture performs and what needs to change.

The point is of course, I’m not talking about stress testing software. I’m talking about stress testing software development methodology so you can discover what you don’t already know about your process, and therefore improve it. I don’t mean, just arbitrarily place more demands on your software teams to produce more with less. That’s just the most retarded type of management-by-objective.

Think about all the moving parts in your development process. What do you know about them? What do you assume? What do you just take for granted? How much do your team members know about the process? Can they identify problems and propose solutions? Do they need to learn that capability? Where are your failure modes? Do you just accept them, and perform a work around, or do you understand them as signals to elicit further discovery about the things you don’t understand about the process? Embrace failure. In fact, actively seek it out. Use it an opportunity to discover unknown information about your business and to improve your team’s skills.

Chasing The Rabbit is a great book, highly recommended that all software development practioners read it, and special thanks to Doug for bringing it to my attention.

The past couple of years though I’ve been thinking about how Agile engages with the management culture of Australian firms.  One thing I’ve been trying to grapple with is the perception of XP as a ‘developer culture’ – from outside it’s typically seen as geekdom infinity raised to the power of nerd, times pi + the square root of two. In other words, management really perceives the XP practices and disciplines as part and parcel of the software developer’s particularly obtuse culture. They don’t like it, they don’t understand it; therefore they fear it (typical of the conservative Australian corporate culture if you ask me). But what to do about it?

All this was brought to a head last night, when I attended the Brisbane Scrum user group meeting. I went to the first meeting (very well attended) and this was my first follow up meeting (Unfortunately I missed Dave Thomas of Bedarra Labs in the December meeting due to unavoidable circumstances). Last night was a presentation by Martin Kearns of Renewtech in Melbourne. He was presenting the results of the Australian Scrum Survey.

As discussion ensued regarding the state of Scrum versus the other agile methods. There is some fear and loathing amongst the developer community regarding Scrum. I believe this is due to a single factor. The Scrum Alliance is quite open about engaging with the PMI (Project Management Institute) and other “mainstream” project management organisations. Now developers, generally (and often rightfully) fear this type of “suit culture” – the suit-and-tie, project managed, management-reporting, Prince II, ISO9000, driven culture of the MBA. And Scrum is trying to talk to these people! Therefore, the Scrum Alliance is these people. Well such a misconception is ill-founded in my view. Philosophically, in my opinion such a  view is akin to the “pure but powerless” view that people often take in relation to politics. In my experience, it is trivially easy to convince a developer of the benefits of agile methodologies. And even though agile is focused on delivering real business value to the customer, it’s much harder to break through organisational inertia to have agile methodologies accepted by the “business” – the customer – and practiced in a really healthy way.

The eXtreme Programming “brand” just doesn’t really help. Even my wife, when she saw the title of one of the Kent Beck  books I had put into our new big bookshelf, made some joking comment about “to the eXXXXXttttrrrreeeeemmmmeee!“. You know, dude, four guys snowboarding off the top of a Nissan Xtrail down some gnarly 300 metre vertical drop with a can of Pepsi Max in one hand and the rock-and-roll “devil’s horn” sign on the other, all cranking to some totally bitchin’ death metal soundtrack, I mean, totally sick mate – or some parody of same off The Simpsons. And it’s also really not productive to have a thousand businesses describe themselves as “agile” or “lean” when what they really mean they’re under-resourced, focussed purely on flogging the team to meet spurious deadlines, committed to fixed-price-and-feature outcomes, and generally planning-light and completely quality-adverse. We need to lift our game so these cowboys are seen as such by the business community.

Scrum, in my view, has the best game plan of all the agile methods to break down this conservative reaction to agility and achieve some real results.

In short, then, I’m looking at spending my own money on a Certified Scrum Master course sometime over the next month in Brisbane and continuing my journey in Agile on the Good Ship Scrum.