Licensing Pain

It’s a very long time since I’ve used any software that requires a licence but I decided to try the patented MPEG2 codec licence for my Raspberry Pi, to decode MPEG2 in hardware. Now I remember why I disliked software licensing so much. This was the process I followed for the Pi’s default Raspbian operating system.

Step 1: Find my Pi’s serial number. At the command line, type:  cat /proc/cpuinfo
The last line, starting Serial: is the unique number of your Pi.

Step 2: Find where to buy it.
Enter the serial numer of the Pi you wish to buy the licence for..
Pay £2-40 and wait for an email. It may take up to 72 hours. I assume this is because a unique(ish) key must be generated.

Step 3: Add the following line to “the config.txt file in the FAT partition of your SD card:

decode_MPG2=0xfdb4a3ac” You may note that this is not the 10 digit hex you were expecting. That doesn’t matter. The first two digits must be implied zeros.

Others told me this meant sudo my chosen editor to add the line to /boot/config.txt then save and reboot.

and “If you want to verify that the codecs are now enabled, the following commands will report their status:

vcgencmd codec_enabled MPG2”

Step 4: Wonder why that didn’t work.

In my case, I was typing:
“vcgencmd codec_enabled mpg2”. It said mpg2 was disabled. In reality, there was no “mpg2”, because it’s “MPG2”. Case matters.


Moderately Grouped

One of the rules I try to live my life by is: “Small pieces, loosely joined”

Then this happened.

I don’t know who I am any more. I already feared de-selection from the cult of Unix and now this.

Then I realised that although I favour hi-fi separates, I don’t  design my own amplifiers and hand-wire the components. I don’t compile Linux from source every time. I’m not a fanatic.

Tooling-up for agile state-transition

This post started out in life as an answer to a question about ‘backlog tooling’ on the LinkedIn ‘Lean & Agile’ group. Someone had given the culturally acceptable answer that the best solution is simple cards or post-it notes on a board or wall. I normally just let that pass because I don’t have a better solution to offer but this time, THIS happened:

I’m about to be intentionally provocative. We know that we are engaged in transforming a multidimensional network of business functions from one poorly understood and transient state to another, currently ill-defined, future state that we hope will emerge from the mist as we travel in it’s general direction. In organisations of any size, this change process is likely to run in parallel with other change programmes, some of them probably deliberately kept secret by people whose pay grade exceeds their ability to make rational judgements about the basis of who “needs to know”.

Amongst this chaos, the chosen tool of ‘the Agile Community’ is a single, 2-dimensional view of a ‘list of lists’, sometimes known as ‘a tree’ or ‘a star’, all of which are topologically equivalent representations of items’ states in the backlog of each Product development. Our best software tools are little more than a model of cards on a board.

Why do we expect the complex, dynamic agile change process to map any more adequately onto a tree of cards than it does onto a hierarchical management structure? Have we learned nothing from our mistakes of modelling within the limitations of the filing cabinet and the typewriter? Perhaps agilists don’t value tools because our tools aren’t fit for purpose.

If all you have is lists representing vague descriptions of changes between two mental models you hope your whole team all share, perhaps the limited nature of the backlog tool isn’t your biggest problem. The backlog items reference changes to an implicit model of roles and the objects in the business domain of your product. My advice is to make it explicit.

Popular Scrum tweaks

Contentious, I know, but the Scrum framework for agile software development may not be completely perfect yet. That’s fine because because we can improve on it, like science.
A few problems that often come to light are:

  • Very few people agree what Agile is. I’m one of them.
  • Few people agree exactly what Scrum is (despite it being defined by a very short document, The Scrum Guide.) “Like chess, Scrum is very simple.”
  • There is a lot of common agile practice that is used by Scrummers and taught on courses but isn’t part of Scrum.
  • Many people think they are ‘doing’ agile and/or Scrum but may not be. Who knows? The rules are: there are no rules.

In my last post I mentioned pragmatic changes to Scrum. Below are some that seem common and I’m not sure are always wrong. I think they come from the fact that Scrum makes assumptions about the mere humans who fill the Scrum roles that are, to be polite, idealistic:

  • The use of Business Analysts to supplement the Product Owner’s knowledge and skills and the developers ability to listen and ask the right questions. Developers are not all good at dealing with people or at business analysis. The people who are, are not all good at development. Part-people who add up to a whole role may be the best a team can realistically achieve.
  • The use of stakeholders who know areas of business better than the Product Owner (PO.) Product Owners need to be super-human: trusted by whoever is paying, knowledgeable, decisive, able to write good stories and constantly available. The PO is there to make dangerous business decisions, so the Team don’t have to. If they make bad decisions, it isn’t the Team’s fault. They are allowed to have help. By this logic, any BA who helps the BA should be outside the Development Team because business process is not “IT”. I have not yet seen any organisation with a business process department. I think we will soon. Process design is often considered a management responsibility but very few managers have appropriate experience.
  • The use of technical/engineering/architecture specialists to supplement the skills of the Development Team. One small team is assumed to consist of generalising specialists with knowledge of everything that will be necessary to complete the project, though you don’t know what that is yet, so ‘be lucky’
  • Network communicators/organisational specialists. Scrum assumes autonomous teams but at scale, organisational efficiency considerations start to apply pressure to centralise scarce and expensive skills. Co-ordination of networked teams becomes necessary. Traditionally, managers are likely to have filled similar roles but in future there may be more collaboration than typical managers have experienced while fighting for influence and resources inside a hierarchical organisation.

Agile as something you do

I have spent the last 2 evenings in Birmingham listening to talks by @diaryofscrum at @ScrumUK and @stevejpitchford at @bcsbrum about management and ‘Agile’ software development, which brought some of my own concerns into sharper focus, particularly about the Scrum framework. In many discussions with practitioners over the last couple of years, I’ve heard the following phrases:

“Agile is an adjective not a verb”
“Agile isn’t something you do, it’s something you are”
“Agile is a philosophy not a method”
“Agile isn’t a process”

Someone who ISN’T agile has to start somewhere. They typically need to DO something, to write software. Would we claim,”Scientific” is an adjective not a method? We wouldn’t, because it is both. The scientific method is a function which delivers what we call “scientific knowledge” as its value. If it didn’t, it would be pointless.

Managers are generally trying to get things done. Each team must agree its own Agile Operating Model (thanks to BCS’s ‘Agile Foundations’ book for that useful phrase.) What came out of the last couple of evenings was pragmatic application of philosophy. Many organisations take Scrum as a starting point, without realizing that “framework” is to be taken very literally. Scrum doesn’t paint the complete picture. It is (part of) a process to organize work. It says almost nothing about how to do that work. It is an alternative to writing a project plan “up-front”, when you know least.

An Agile Operating Model is a process which delivers a value, so it is a function. My scientific hypothesis is that it delivers valuable business function change, sometimes in the form of software. It is itself a business function. Agility has business functions as first class citizens. It doesn’t meet general expectations of a process because it can recursively self-modify. That doesn’t mean it isn’t one. As the kids say, “get you an agile function that can do both”.


On Hacking and Sharpening Tools

Mrs. Woo watched Monty Don. That always means trouble. Monty said ‘we’ must stake our raspberries at the weekend. He appeared to use brand new fence posts for the job but our raspberries came under the fence from next-door, so I wasn’t going to spend money. Last year, I replaced half a dozen cross-members in fence panels, so they’d  do. They were triangular in section, like carpenters’ pencils, which I sharpen with a Stanley knife. I couldn’t see any reason why the operation wouldn’t scale. I fetched my hand axe and started to whittle, at industrial scale. In my head, I was already writing a Tweet about hardware hacking.

I soon knew that I should have sharpened the blade before I started but it might take me ages to find the sharpening stone and some oil. I could even remember thinking the same the last time I used it. It might have been worthwhile if I had a bigger herd of yaks to shave but this wouldn’t take long.*

An axe is an interesting tool, relying on the momentum of the head, once the cut has started. Unfortunately, when hacking tangentially at a lump of wood, getting started is the biggest issue and this depends on blade sharpness. The more my efforts honed each giant pencil, the slower I progressed. When I was close to finishing each one, any possible last stroke seemed to have a more than equal chance of breaking off any point I’d created. It wasn’t until I’d had a particularly frustrating time with the last piece and was gripping the axe head between both hands, trying to use it like a chisel that I remembered my Dad’s old spoke-shave. I was long past the point where going and sharpening its blade, so I could use an appropriate tool, would have been a wise move. If I was going to do that, I might as well have sharpened the axe two hours ago.

There IS a point to this story, beyond self-flagellation. Hacking techniques are great for immediate, fast progress, and the sharper your tools the faster you’ll travel, so investing in preparation can be cost-effective but sharp, crude tools can only take you so far. I hadn’t been aware enough to see that I’d moved into the precision stage of pointy-stick development and should have changed to precision tooling, the low gear of change implementation.

The archaeology bit

Have you ever watched a pre-historic archaeological dig on TV? Sometimes they find a few flint axe-heads which they get very excited about and loads of flint scraping tools which they say were probably used for scraping animal skins. They should try sharpening a stick with a hand axe. I think our ancestors were busy incrementally inventing the spoke-shave. I wouldn’t be at all surprised if the wheel was invented by a stick sharpener, probably a woman, as she chuckled at the men showing off how many rolling-logs they could carry at a time.

* – For “yak shaving”, see The Jargon File.
Beware: it is a yak watering-hole and many of them could do with a trim.

Practising your Process

My very sincere thanks to Simon Powers for posting the ‘onion diagram’ in his ‘What is Agile?’ post on LinkedIn and for answering my question. The post is also available on his own blog
It shows ‘tools & processes’ separate from ‘practices’. I’ve been thinking for a long time about whether there is any real difference between process (what) and procedure (how) or if they are simply different levels of detail. I think I’ve just been convinced that the equation I’ve been searching for is:

  • process + practises = procedure

Simon actually listed in his answer to me, ‘roles, interactions and artifacts’ as the difference between the set of Agile practices and the set of Agile processes, so I’ve corrupted his definition for my own purposes but I haven’t broken his diagram so I hope he’ll forgive me. (Or maybe I don’t understand whether the layers of an onion diagram are inclusive or exclusive.)

I think making the process one of the practises would make the function recursive and this is supposed to be one of my Lisp rest-days. If my process diagram shows roles or artifacts then I’m sure I’ve moved into the realm of specifying practice. Interactions may be input-output that is part of the definition of the process, so it is probably necessary to split them down more, into message type & format.