Suits you?

Last night I went to a ‘Product Tank Birmingham’ workshop on ‘Empathy Mapping’. As an exercise, we looked at ‘a product meeting group’ and tried to identify its customers. There was a brief discussion about ‘Product Owners’ (from agile software development) and ‘Product Managers’ who often have a more marketing-led approach. Someone then commented on what ‘Product people’ think. I found I didn’t agree. I reflected on the difference between Product Owners (in this context: me), who care about giving people the product they want and Product Managers, who seem to care more about people’s relationship with the product.

I realised there is a half-way house and I have not, to date, worked in it. My experience in agile software development has been about “custom” development of software products for small teams with a shared view of what they want. I’ve realised for a while that my experience is very different to those Product Owners who have to develop a more generic product to ‘optimise’ across a set of potential or actual customers who have differing needs. There is an extra role there which is far more like my understanding of Product Management. I think the key difference is the need to correctly judge the closeness of fit needed to achieve mass market appeal vs the bespoke tailoring trade that I’ve worked in.

Early in my career, I worked as a programmer on a software package for pharmaceutical companies. We coded to specifications provided by 2 people, a salesman and our technical manager, who both travelled the world visiting customers’ sites. Looking back, I think the salesman was much better at identifying the features that would be valued by most customers. Is marketing USEFUL?

Advertisement

Apple Mac Mini 4,1 running Ubuntu Linux

An old Mac Mini server was ‘going in the skip’ because it had been replaced as an office server. It was handed to me instead, due to my reputation as an IT dumpster diver.
https://everymac.com/systems/apple/mac_mini/specs/mac-mini-core-2-duo-2.66-mid-2010-server-specs.html (server model: 2.66 GHz Core 2 Duo (P8800))

I did MANY upgrades to get it to the latest release, 10.13 High Sierra. A couple of weeks later, Apple announced that they were stopping further updates. I understood at the time this was because this generation of hardware had a 32-bit EFI boot system, despite being a 64-bit processor and that it was only possible to boot Ubuntu by modifying the Ubuntu OSI image. This may have been true at the time. I’ve tried to get to know MacOS but it sometimes feels really sluggish on this hardware and now I’m not seeing the latest features, I decided to consider giving up the struggle.

Today, I tried to boot an Ubuntu 64-bit image from a ‘live’ USB memory stick I’d built on another Ubuntu system. I wanted to see how it would fail. To my surprise, it booted. I had to go into Settings to add a WiFi connections. The only problem I had was that tinny sound came from the Mac Mini’s internal speaker. When I plugged the headphone socket to the TV, rather than being routed by HDMI and the TV’s stereo sound inputs as Mac OS would do, I had no sound. A full install might fix that.

You get (this) Mac to boot from another device by pressing the <Alt> key at startup.
(This didn’t work on a white iMac with a Core 2 Duo processor when I tried months ago but that was probably an earlier version of Ubuntu.)

A new target for Software Developers: Sensei.

I originally wrote this as an answer to a question on Quora but I’m increasingly concerned at the cost of higher education for young people from families that are not wealthy. I had parents who would have sacrificed anything for my education but I had clever friends who were not so fortunate. The system is bleeding talent into dead-end jobs. Below, I consider other models of training as I hope it might start a conversation in the technology community and the political infrastructure that trickles money down into it.

Through learning about ‘Agile’ software development, I became interested in related ‘Lean’ thinking. It borrows from Japanese cultural ideas and the way the martial arts are taught. I think the idea is that first you do, then you learn and finally you understand (as illustrated by the film ‘Karate Kid’.) That requires a ‘master’ or ‘Sensei’ to guide and react to what s/he sees about each individual’s current practice. It seems a good model for programming too. There may be times when doing is easier if you gain some understanding before you ‘do’ and advice and assistance with problem solving could be part of this. I’m not alone in thinking this way, as I see phrases like “kata” and “koans” appearing around software development.

I’ve also seen several analogies to woodworking craft which suggests that a master-apprentice relationship might be appropriate. There is even a ‘Software Craftsmanship’ movement. This could work as well in agile software development teams, as it did for weavers of mediaeval tapestries.

A female Scrum Master friend assures me that the word “master” is not gendered in either of these contexts. Of course, not all great individual crafts people make good teachers but teams with the best teachers would start to attract the best apprentices.

If any good programmers aren’t sure about spending their valuable developer’s time teaching, I recommend the “fable in novella form” Jonathan Livingston Seagull, written by Richard Bach, about a young seagull that wants to excel at flying.

Small software companies ‘have a lot on’ but how much would they need to be paid to take on an apprentice in their development teams, perhaps with weekly day-release to a local training organisation? I’d expect a sliding scale to employment as they became productive or were rejected back into the cold, hard world if they weren’t making the grade.

Agility vs Momentum

[ This post is aimed at readers with at least basic understanding of agile product development. It doesn’t explain some of the concepts discussed.]

We often talk of software development as movement across a difficult terrain, to a destination. Organisational change projects are seen as a lightening attack on an organisation, though in reality, have historically proved much slower than the speed of light. Large projects often force through regime change for ‘a leader’. Conventionally, this leader has been unlikely to travel with the team. Someone needs to “hold the fort”. There may be casualties due to friendly firings.

Project Managers make ‘plans’ of a proposed ‘change journey’ from one system state to another, between points in ‘change space’, via the straightest line possible, whilst ignoring the passage of time which makes change possible. Time is seen as distance and its corollary, cost. The language of projects is “setting-off”, “pushing on past obstacles” and “blockers” such as “difficult customers”, along a fixed route, “applying pressure” to “overcome resistance”. A project team is an army on the march, smashing their way through to a target, hoping it hasn’t been moved. Someone must pay for the “boots on the ground” and their travel costs. This mind-set leads to managers who perceives a need to “build momentum” to avoid “getting bogged down”.

Now let us think about the physics:

•  momentum = mass x velocity, conventionally abbreviated to p = mv.
  At this point it may also be worth pointing out Newton’s Second Law of Motion:

• force = mass x acceleration, or F = ma
  (Interpretted by Project Managers as “if it gets stuck, whack it hard with something heavy.”)

What about “agile software developments”? There is a broad range of opinion on precisely what those words mean but there is much greater consensus on what agility isn’t.

People outside the field are frequently bemused by the words chosen as Agile jargon, particularly in the Scrum framework:
A Scrum is not held only when a product development is stuck in the mud.
A Scrum Master doesn’t tell people what to do.
Sprints are conducted at a sustainable pace.
Agility is not the same as speed. Arguably, in agile environments, speed isn’t the same thing as velocity either.

Many teams measure velocity, a crude metric of progress, only useful to enable estimation of how much work should be scheduled for the next iteration, often guessed in ‘story-points’, representing relative ‘size’ but in agile environments, everything is optional and subject to change, including the length of the journey.

If agility isn’t speed, what is it? It is lots of things but the one that concerns us here is the ability to change direction quickly, when necessary. Agile teams set off in a direction, possibly with a destination in mind but aware that it might change. If the journey throws up unexpected new knowledge, the customer may wish to use the travelling time to reach a destination now considered more valuable. The route is not one straight line but a sequence of lines. It could end anywhere in change-space, including where it started (either through failing fast or the value of the journey being exploration rather than transportation.) Velocity is therefore current progress along a potentially windy road of variable length, not average speed through change-space to a destination. An agile development is really an experiment to test a series of hypotheses about an organisational value proposition, not a journey. Agile’s greatest cost savings come from ‘wrong work not done’.

Agility is lightweight, particularly on up-front planning. Agile teams are small and aim to carry everything they need to get the job done. This enables them to set off sooner, at a sensible pace and, if they are going to fail, to fail fast, at low cost. Agility delivers value as soon as possible and it front-loads value. If we measured velocity in terms of value instead of distance, agile projects would be seen to decelerate until they stop. If you are light, immovable objects can be avoided rather than smashed through. Agile teams neither need nor want momentum, in case they decide to turn fast.

Women’s Day Intuition

The first thing I did yesterday, on International Women’s Day 2017, was retweet a picture of Margaret Hamilton, allegedly the first person in the world to have the job title ‘Software Engineer’. The tweet claimed the pile of printout she was standing beside, as tall as her, was all the tweets asking “Why isn’t there an International Men’s Day?” (There is. It’s November 19th, the first day of snowflake season.) The listings were actually the source code which her team wrote to make the Apollo moon mission possible. She was the first virtual woman on the Moon.

I followed up with a link to a graph showing the disastrous decline of women working in software development since 1985, by way of an explanation of why equal opportunities aren’t yet a done deal. I immediately received a reply from a man, saying there had been plenty of advances in computer hardware and software since 1985, so perhaps that wasn’t a coincidence. This post is dedicated to him.

I believe that the decade 1975 – 1985, when the number of women in computing was still growing fast, was the most productive since the first, starting in the late 1830s, when Dame Ada Lovelace made up precisely 50% of the computer software workforce worldwide. It also happens to approximately coincide with the first time I encountered computing, in about 1974 and stopped writing software in about 1986.

1975 – 1985:
As I entered: Punched cards then a teletype, connected to a 24-bit ICL 1900-series mainframe via 300 Baud accoustic coupler and phone line. A trendy new teaching language called BASIC, complete with GOTOs.

As I left: Terminals containing a ‘microprocessor’, screen addressable via ANSI escape sequences or bit-mapped graphics terminals, connected to 32-bit super-minis, enabling ‘design’. I used a programming language-agnostic environment with a standard run-time library and a symbolic debugger. BBC Micros were in schools. The X windowing system was about to standardise graphics. Unix and ‘C’ were breaking out of the universities along with Free and Open culture, functional and declarative programming and AI. The danger of the limits of physics and the need for parallelism loomed out of the mist.

So, what was this remarkable progress in the 30 years from 1986 to 2016?

Good:

Parallel processing research provided Communicating Sequential Processes and the Inmos Transputer.
Declarative, non-functional languages that led to ‘expert systems’. Lower expectations got AI moving.
Functional languages got immutable data.
Scripting languages like Python & Ruby for Rails, leading to the death of BASIC in schools.
Wider access to the Internet.
The read-only Web.
The idea of social media.
Lean and agile thinking. The decline of the software project religion.
The GNU GPL and Linux.
Open, distributed platforms like git, free from service monopolies.
The Raspberry Pi and computer science in schools

Only looked good:

The rise of PCs to under-cut Unix workstations and break the Data Processing department control. Microsoft took control instead.
Reduced Instruction Set Computers were invented, providing us with a free 30 year window to work out the problem of parallelism but meaning we didn’t bother.
In 1980, Alan Kay had invented Smalltalk and the Object Oriented paradigm of computing, allowing complex real-world objects to be simulated and everything else to be modelled as though it was a simulation of objects, even if you had to invent them. Smalltalk did no great harm but in 1983 Bjarne Stroustrup left the lab door open and C++ escaped into the wild. By 1985, objects had become uncontrollable. They were EVERYWHERE.
Software Engineering. Because writing software is exactly like building a house, despite the lack of gravity.
Java, a mutant C++, forms the largely unrelated brand-hybrid JavaScript.
Microsoft re-invents DEC’s VMS and Sun’s Java, as 32-bit Windows NT, .NET and C# then destroys all the evidence.
The reality of social media.
The writeable Web.
Multi-core processors for speed (don’t panic, functions can save us.)

Why did women stop seeing computing as a sensible career choice in 1985 when “mine is bigger than yours” PCs arrived and reconsider when everyone at school uses the same Raspberry Pi and multi-tasking is becoming important again? Probably that famous ‘female intuition’. They can see the world of computing needs real functioning humans again.

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.
http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html
Beware: it is a yak watering-hole and many of them could do with a trim.

The Tao of Corbyn

Owen Jones wrote an article called ‘Questions all Jeremy Corbyn supporters need to answer’ on Medium. This is my response.

I am not a ‘Jeremy Corbyn supporter’. I may sometimes support the same ideas as Jeremy Corbyn but not all of them. I am not ‘of the Left’.  I would defend Owen Jones right to hold different views to his party leader (though posibly not “to the death”), and to express them in a non-destructive way. I am over 50. I may be atypical.

I like Jeremy Corbyn because seems a decent bloke. All his enemies admit that he is. In a world of spin and misdirection by politicians and the media who are supposed to hold them to account on our behalf, that’s his greatest strength. “But he’s not a leader”, they say. Corbyn’s been described as a signpost rather than a weather-vane. He knows what he thinks and so do we. That’s his appeal to those outside the Westminster bubble, to those of us who have taken the trouble to fight through the media smoke screen. We are really sick of being lied to and the EU referendum feels like the final straw that broke unrepresentative democracy for many.

Is a clear political message important? #Leave won with a very clear pack of lies. Is that what we want more of? I think the next General Election will be won by whoever the public trust. I think the rebel MPs may have ensured that it won’t be a Labour leader but I am 100% sure that it won’t be Owen Smith because he’s a flag. He follows the wind AND he flaps!

This entry on a current leadership style  https://en.wikipedia.org/wiki/Servant_leadership demonstates that Corbyn is both ahead of the political game and very far behind it:

It contains the following passage from the Tao Te Ching,  Lao-Tzu written, between 570 BCE and 490 BCE:

The highest type of ruler is one of whose existence the people are barely aware.
Next comes one whom they love and praise.
Next comes one whom they fear.
Next comes one whom they despise and defy.

When you are lacking in faith,
Others will be unfaithful to you.

The Sage is self-effacing and scanty of words.
When his task is accomplished and things have been completed, All the people say, ‘We ourselves have achieved it!’

View at Medium.com