Progress is slow if you ignore the past

I have just returned from spending my Sunday at the 1st day of the 21st Danish GOTO conference (not all of them were named GOTO, there has been some name changes over the years).

As expected, it was a great day, with some great talks - if you want to see my running commentary on those talks, go look at my Twitter stream @kriswager

Most of the talks I attended were great, but I especially enjoyed the keynote Engineering You by Martin Thompson, and Dan North's talk Beyond Developer, both of which focused on how software engineers/developers should expand their knowledge and become better programmers.

Both of these talks started out by looking back at the roots of the field. Dan North took us all the way back to Ada Lovelace:

Taking us back to the roots. @tastapod starts his talk with going back to Ada Lovelace #Gotocph pic.twitter.com/exmt9OcroE

— Kristjan Wager (@kriswager) October 1, 2017

Martin Thompson, on the other hand, only took us back to 1967, where "software engineer" was coined. He spent some time on the 1968 Software Engineering conference sponsored by the NATO Science Committee, where many of the issues raised, and experiences expressed, would fit well into a conference today.

It is interesting how little we have learned in 50 years. Words on slide is from meeting in 1968 #Gotocph pic.twitter.com/XV1AxclpmQ

— Kristjan Wager (@kriswager) October 1, 2017

The above tweet only shows one of Martin Thompson's examples from the conference.

While it is easy to despair over how little progress that has been over the last 50 years, I think it is probably better to think about it this way: while our methodologies change, the problems we face are the same, and it makes sense to look at what people did in the past, to see if they have solved problems we face today.

A lot of people tend to think of pre-Agile days as a period of endless, mostly failing, waterfall projects, but the truth is, that this generally wasn't the case in the early days, and probably wasn't as common later, as legend makes it sound.

It is worth remembering that back in the early days of the field, people were not only building programs, they were also building the tools (e.g. compilers) they needed in order to build programs. These tools have evolved since then, but they are still based on the same solutions that we base our tools on today. Why should solutions to organizational problems be any different?

Disclosure: This blogpost mentions the GOTO Copenhagen 2017 conference. As a blogger who blogs about that conference, I get a free ticket from the organizers. The organizers don't dictate what I write about, and don't have any say about the content of the posts. 

My schedule at GOTO Copenhagen

GOTO Copenhagen 2017 is just around the corner, and I have taken a look at the talks that I definitely want to go to this year.

Unlike earlier years, GOTO Copenhagen starts on a Sunday this year, which makes some demands to the quality of the speakers, trying to lure people in early Sunday morning.

Luckily, the conference delivers - there are two keynotes on at 9:00, and while both looks interesting, I am going for Martin Thompson's talk. I have heard him speak a number of times, and every time the talk have been engaging and informative.

After the keynote, there are some interesting talks, but the next talk I really look forward to, is Dan North's Beyond Developer talk. Not only does the talk sound interesting and relevant, I also know that anything Dan North presents is going to be fun.

Skipping to the talks on Monday, I have spotted the following talks I'd be interested in:

• Eoin Woods: Secure by Design – the Architect’s Guide to Security Design Principles 
• Emma Arfelt: Privacy in Software

The many security breaches in recent months, shows that security is still a hugely important topic, which is all too often ignored or neglected. These two talks addresses different, but equally important, aspects of security.

Tuesday, there is a track called Herding Cats: The Human Factor, where I plan to spend most of my time, for reasons I explained in my last blog post

Other than that track, I am looking forward to the end keynote by Linda Rising. Linda Rising is one of the most engaging and brilliant speakers I have ever heard, and it is a pleasure to go to one of her talks.

Disclosure: This blogpost mentions the GOTO Copenhagen 2017 conference. As a blogger who blogs about that conference, I get a free ticket from the organizers. The organizers don't dictate what I write about, and don't have any say about the content of the posts.

Agile won't cut it alone

During the first day of GOTO Aarhus conference there was a track called When the Agile Manifesto isn't Enough, where a bunch of speakers talked about stuff related to agile, but not converted by the Agile Manifesto.

I didn't see the whole track, but I did saw 2 of the first 3 talks (I left during the second talk), and enjoyed Dan North's Agile doesn't scale, and what you can do about it, and Russell Miles' Without Simplicity there's just no Agility, both of which addressed why agile projects tend to fail at being agile over time, but in different ways. I thought I'd write a little about the first of those talks.

Dan North's talk was on how agile doesn't scale well (as the title indicates), and he started out by trying to explain what he meant by "scale", and basically he means working on bigger problems in bigger programmes. Big problems in individual projects are well handled by agile, but when you have many projects working together on bigger problems, agile doesn't help.

Simply put, the domain of agile is within the projects, but when we're talking multiple projects, we need to think about delivery assurance and governance (which put together is portfolio management).

Delivery assurance covers areas like cross-team concerns, product trade-offs, and technical trade-offs. Or put differently, covers the coordination between teams and the decisions which should involve several, if not all, teams (such as choosing the same database or even programming platform).

Governance covers areas such as organisational concerns, investment trade-offs, and portfolio balancing. In other words, this is where there requirements of the organization, as a whole, is evaluated, and decisions relating to which projects are prioritized are made.

Agile has no opinion on delivery assurance or governance, and this is why it doesn't scale. This doesn't mean that we should stop using agile, it just means that we have to recognize that we need to do something on top of agile. So agile should be done in the projects, while portfolio management should happen between/across projects.

What I've written above, is, of course, a rather simplified version of the nearly hour-long talk Dan North gave, but I think those are the important points.

Dan North's talk covered an area which I've been thinking of recently, since I've come across the problems with agile across multiple projects in the past, and I think he is absolutely spot on. I think agile is a great idea, and something which you would be stupid not to use in one form or another in your project, but I also think that the allure of agile has been harmful, since it has made a lot of people think that they could reject all classical project management, including such things as portfolio management. This is probably one of the major reasons why projects still fail when doing agile.

One of the reasons I think Microsoft is currently good at creating programming languages and tools that support them, is that they put a lot of effort into portfolio management. The different language teams coordinate on what they want to add to the languages, and they make sure that the tools (e.g. Visual Studio) are up to date, so they support the new features in meaningful ways. It obviously also helps that they have some great people involved in this, but without the coordination, the best people in the world would not be able to make something that anyone could use.

So, to sum it up, agile is useful within projects, but we must not forget that there often is a need for coordinating, or even prioritizing, between projects, and agile is inadequate for that purpose. Instead one should turn to classic project or even organizational management tasks covered by portfolio management.

Impressions from the 1st day of GOTO Aarhus

This is just a short blogpost with my impressions of the 1st day at GOTO Aarhus 2013 - longer, more detailed blogposts will follow, based on specific talks.

My schedule for the 1st day of the conference was:

1) Introductions to the tracks - this was basically just the track hosts that introduced their tracks. There were a lot of great speakers and several interesting tracks, but the track hosts should practice giving short introductions to their tracks and the speakers on it.

2) Something completely different: an opera singer showed up on stage and gave a short performance. I haven't seen this before at a conference, but it was a pleasant surprise.

3) Keynote speech: There and Back Again - Software Security in the 21st Century by Brian Chess.
I plan on writing a separate blogpost about this talk, but I found it interesting and it contained som important reminders to everybody.

4) Dan North: Why Agile doesn't scale, and what you can do about it (when the agile manifesto isn't enough track)
It was an intentionally provokative title, but the main message was that agile is not focused on scale, and we need to look at other things in order to get agile to work on large scale projects.
I will write a separate blogpost about some of the talks on this track.

5) Mads Troels Hansen: Do's and don'ts for Distributed Scrum (when the agile manifesto isn't enough track)
This talk was about a number of patterns for doing distrubuted scrum succesfully. It would have been a great series of blogposts, but as a talk it was lacking the overarching narrative, which made it interesting. I left this talk early.

6) Russell Miles: Without Simplicity, there's just no Agility (when the agile manifesto isn't enough track)
The theme of this talk fitted pretty well with the theme of Dan North's talk, and will be covered in the same blog post.

7) Ola Bini: Working on cancer (Architechtures track)
Ola Bini talked about a project he had done together with 3 other Thoughtworks developers, where they had created a system which could help ensuring that people get better treatments for their cancers.
The first part of the talk was a (brief) introduction to the microbiology behind cancers, and even if it was simplified, it was a rather good, short introduction. The rest of the talk was about the solution they built, and the technologies used. It quickly ended up as a long list of technologies, but there was not enough time for him to get into details or even show code, which is a pity, and would have made the talk more interesting for a lot of the people in the room.

8) Work break. There wasn't any talk that I really wanted to see, so I spent the time doing some work that I needed to do.

9) Keynote speech: Computing like the brain: the path to machine learning by Jeff Hawkins
Jeff Hawkins talked about his work on machine learning. It was an interesting talk, but I had some serious problems with Jeff Hawkins using the termology of computer science to describe the brain, as it erases the very real differences between the brain and machines. I am also doubtful about whether he is really as close to creating machine learning as he thinks he is (for many of the same reasons as described here)
One thing I really did like about his talk, was his endnote that we are never going to upload our brains into computers, and anyone who thought so, clearly didn't understand neuroscience.

10) Exhibitor reception and conference party
I am a big proponent of using conferences to network, and the exhibitor reception and the following conference party are definitely great places to do that. I got to talk with a lot of interesting people - some I knew already, but a lot I didn't know.