Is the Agile Manifesto outdated?

Looking through the program for GOTO Aarhus, I saw that one of the tracks is about people and processes. This is a track they have had at GOTO Aarhus for some years, and one that I usually go to most talks at. After looking at the program, I don't think this year will be any different.

The reason I go to this track, is that I feel that the greatest challenges in software development is not related to technology, but rather to the interaction between people - exactly what this track is all about.

Looking back at all the conferences I've been to the last few years, it has been talks about organizations and processes that has challenged my world-views the most, forcing me to re-evaluate my assumptions, and decide whether or not they were right or not.

A simple example - last year I listened to talks by both Jez Humble and Dan North, where they mentioned the fact that one has to understand the trade-offs in order to make informed decisions. Otherwise you don't know whether it is the right choice for your situation or not. This is a simple message, and one which is easy to grasp on the surface, but also one it is easy to ignore, when there is a choice that seems obvious.

Lets take source control, which most of us would always insist on.

Source control is without a doubt a must in just about all projects where there is more than one person working on code (and the majority of projects where there is just one person working on the code). Does that mean that we should always use a source control system? Well, no - we need to look at the individual situation, and decided whether it is appropriate or not, evaluating the trade-offs.

In most cases the trade-off is between risk-reduction versus speed and/or cost. Here most would err on the side of risk-reduction, but it could be that speed is of such paramount importance, that the time to set up the source control would make the project worthless, and in that case, then risk-reduction would be the wrong choice.

Personally, I have never been in this situation, and find it highly unlikely I ever will, but it is important to keep it in mind, even when the choice seems obvious.

This is just one of the ways talks related to people and processes has changed my way of thinking.

Another obvious way such tracks have changed my way of thinking, is to make me more cautious about Agile and especially the Agile Manifesto.

At GOTO Amsterdam 2013, Kai Gib gave a interesting talk How to Focus Agile so it delivers Value to your Stakeholders, where he correctly pointed out that the Agile Manifesto has very little focus on actually providing value to the business side (though it does pay attention to value in the principles). Since providing value is the actual reason for doing a project, it would seem problematic that this is left out of the actual manifesto.

Kai Gibs talk, and similar talks I've heard the last few years, have left me wondering if perhaps it is time to retire the Agile Manifesto, or at least put less emphasis on it. Given the fact that I see it presented less and less often as part of slides at a talk, I don't think I am alone in feeling this way.

Actually, looking at the GOTO Aarhus program, it seems like that even the original signees of the Agile Manifesto might feel this way, since there are two sessions on the first day of the people and processes track called A retake on the Agile Manifesto (part 1 and part 2), where five people will be takein "a closer look at what has happened in the last 13 years since the Agile Manifesto was published and evaluate where the development community is going in the future".

Three of those five people are co-signers of the original manifesto (Martin Folwer, Andrew Hunt and Dave Thomas).

I am very much looking forward to these sessions, and to to what they will bring. Maybe something new and exciting will come out of it.

One thing is sure, I expect that I, and everyone else listening, will learn a lot.

GOTO Aarhus changes format

It is no secret that one of the conferences that I really love is the GOTO Aarhus conference which takes place at the end of September. I've been there the last couple of years as a blogger, and expect to go there in that capacity again this year.

One of the things I've loved about the GOTO conference is the format, where there are several concurrent tracks spread across 3 days, where some tracks take up a whole day, while some only take up half a day. Many of the tracks are related, but the format allows you to spread your attention and explore areas you don't really have much knowledge about, without having to invest too much of your conference time.

Given this, it is with a bit of worry that I see that GOTO Aarhus has cut down the length of the conference to two days, and at the same time changed the format, so there are 5 tracks (including the vendor track) running across both days.

This seems like a step back to me, removing the possibility of the more quirky tracks like the open data / eGov track last year, which was only half a day, but which had some really fascinating speakers, presenting unique perspectives and problems.

Now, such tracks would have to be embedded in one of the more mainstream tracks, which is something I highly doubt will happen, especially given the fact that the conference is now one day shorter.

Having said that, I am sure the conference will still be great, and given the quality of the speakers I can see on the list, I am still looking forward to going there. I just think that the chances of having my mind blown has been diminished.

GitHub as a recruitment filter

When I was at QCon San Francisco, I heard a talk about recruiting software engineers, and one of the points of the speaker, was that you should check out the GitHub profile of the candidates. This is something I found a little worrisome, not only because I don't have an (active) GitHub profile, but also because it seemed to me that this would lead you to exclude a number of good candidates.

I am all for open source, but I don't spend time on them, since I have enough work to do on work and non-programming related projects for me not wanting to add more to it. Does this make me a bad programmer? Perhaps. But probably not. Currently I am mostly doing business analytics (i.e. trying to help define the needs of the customer), but when I am on a project as a programmer, I tend to average more than a full days work each day - I could spend the overtime on open source projects, but I frankly don't see how this is a better use of my time, in the eyes of optential future employers.

There are also numerous other reasons why using GitHub profile as a recruitment filter is a bad idea, and there are two great blogposts that explains this:

Ashe Dryden: The Ethics of Unpaid Labor and the OSS Community
James Coglan: Why GitHub is not your CV

They should be read in the posted order, as Coglan's post is an expansion on Dryden's post.

We got to do better - diversity at conferences

I have just returned home from San Francisco, where I and nine of my colleagues, spent 3 days at the QCon San Francisco conference.

As often happens at these conferences, the gender diversity was not impressive - according to the speakers page, there were 7 women out of 110 speakers, and none of them were keynote speakers.

This is, to put it mildly, abyssal, and we got to do better.

On the last day of the conference, they displayed a slide of all the track hosts in the conference. When I saw it, I immediately thought to myself (and of course tweeted): I think I now understand the gender imbalance at the conference.

 

 

 

At conferences like QCon SF, track hosts are heavily involved in selecting the speakers, and they tend to look at their own network when doing so. Unless you've done an explicit effort towards that not happening, your network tends to look a lot like yourself, and when people like the track hosts use their network to get speakers, the speakers end up looking like themselves.

 



Not all track hosts are like that of course - one of the track hosts in that picture is Jez Humble, who is very much involved in fixing the gender imbalance (2 of his 5 track speakers were women), and who has written a great blogpost about this: How To Create A More Diverse Tech Conference. That blogpost should be required reading for all conference organizers, and certainly wasn't read (or at least not followed) by the QCon SF organizers.

If the organizers don't want to follow the guidelines laid out by Jez Humble, then they could consider something as simple as trying to find a couple of female track hosts. That alone should help in the gender imbalance. Or perhaps just ask the vendors if they could use female speakers, rather than male speakers, on the vendors track, if possible - I know that at least one of the vendors had a great female speaker sitting in the booth on the first day, and she could easily have spoken on either the vendor track or in one of the other tracks.

Before anyone goes on about conference organizers having to choose the greatest speakers they can get hold of, I will say that that has been addressed by Jez Humble in his blogpost, and that at QCon SF, the level of the speakers was generally sub-par compared to similar conferences I've been to the last couple of years (which includes both QCon London and QCon New York), so looking towards diversity probably would have increased the quality.

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.

A must read blogpost

I was linked to this great blogpost "To my daughter's high school programming teacher, where a tech writer writes an open letter to her daughter's teacher, explaining how that teacher failed his duty to help foster an environment that welcomes young talented people, regardless of their gender.

The comments under the blogpost are unfortunately predictable - men denying the problem etc., so don't read them, unless you want to get annoyed.

Why you should allow your employees to go to conferences

A few days ago, I was talking with a friend, who I used to study together with. We were talking about GOTO Aarhus, and whether he thought he would be going this year.

He told me that it was unlikely, as the company he works for, has a limited training budget, which also covers conferences.

While I can understand why some companies might have to be careful about costs, it seems to me that this is short-term thinking, which will cost them in the long run.

In my experience, and in the experience of other people I have talked with about this subject, the people who ask for conferences, usually belongs to a group of people that the company would like to keep in their organization. This doesn't mean that the company wants to get rid of the people who don't ask for conferences. Rather, it means that innovation within the organization tends to happen from people who likes to seek inspiration everywhere (and what are conferences other than a giant source of inspiration?).

Conferences are, in other words, a great way to introduce new ideas and solutions into the organization, as long as someone who wants to go there, get to go. For the people going there, conferences are often a vital part of getting new ideas, since they will spending days together with like minded people, who might offer new insights. I think most of us have tried to hear someone say something, and suddenly have your brain go "click", realizing that you've dealt with a problem the wrong way. A conference offers you thousands of opportunities to get such "click" moments.

People like my friend, comes back from a conference with fresh new ideas, and new ways at looking at old problems, perhaps allowing for a novel new solution to a problem the organization has had for a long time.

So, all in all, my suggestion to companies would be, that if you have a employee who wants to go to a conference, think twice before saying no.

On the other hand, don't force employees to go. It is quite fine to suggest to someone that they go, but if they don't think that it's worth the time, it is pretty much a self-fulfilling prophecy, and a waste of money.

At the end of the post, I should probably also mention the fact that some people, myself included, consider conferences so essential that it is something we take into consideration in relationship to employment (my current employer, NineConsult, also considers conferences essential, so in that sense we're a good match).

This year's GOTO Aarhus conference

It looks like I might be going to the GOTO Aarhus conference again this year as a blogger, like I did last year. It is not completely decided yet, but there is a high likelihood.

If I am going, this would be 4th time I'm going to this particular conference, which is favorite conference (perhaps together with QCon London). Not that I have been to that many different conferences - I go to more than many people in IT, but I've only been to just over a handful of different conferences.

So, what am I looking forward to?

I haven't taken a full in depth look at the schedule yet, but glancing at the speakers list, I see several great speakers among them. People I'd hate to miss out of a general principle, would be Dan North, Jez Humble, Dave Thomas, and Ola Bini. Though I am considering Dan North, as I think I might have heard that talk before (I will have to hear the introduction to the talk).

I also noticed Kevlin Henney among the speakers, but unfortunately he is only there as a trainer for the training days. If you ever get the chance to hear him speak, I highly recommend it - he is an fantastic entertainer and teacher rolled into one.

Subject wise, I tend to avoid technology specific talks, and rather go for talks that can apply broadly across technologies. This means I have a tendency to go for talks related to processes, people, and principles across technologies (e.g. architecture or big data).

This year I think I will be spending my time mostly on the following tracks:
Monday: Architecture and "When the Agile Manifesto isn't enough"
Tuesday: "Lean IT Enterprise" - this is only half the day, so I need to find other stuff to fill it out.
Wednesday: "DevOps In Depth" and Career. Perhaps "Data in Reality", but there is so little information about the track right now, that I cannot really tell what the talks will be about.

The schedule can be found here

Another thing I am going to spend my time on at GOTO Aarhus is networking. I think it is incredible important to take advantage of the opportunity such a conference gives for meeting your peers and the masters of the field. And GOTO Aarhus is especially good at facilitating this, throughout the conference. I have been to other conferences, even other GOTO conferences, where this important aspect was lacking, but somehow GOTO Aarhus manages - especially during the conference party, where you have the chance to meet not only the other participants, but also the speakers.

So, if you're going to the conference, I highly recommend not missing out on the party. Who knows, you might end up having beer with someone like Michael Nygard or Jim Webber, both of which I have drunk beer with at conference parties. OK, probably not those two, as neither of them appear on the speaker list, but you get my point.

One should of course not forget to network with the vendors. People have a tendency to think that the vendors are just someone you should visit to get free stuff or win something, but this is a mistake. Often the people standing at the vendor booths are passionate about the company or product they represent, and they are often highly knowledgeable about the things they talk about. Remember, the vendors often send their best representatives to the conference in order to convince people.

A round-up of my GOTO Aarhus experience

Let's pretend for a moment that it is not nearly two weeks since I got back from GOTO Aarhus, and thus this blogpost really should have been written at least a week ago. Let's instead say that I've let my thoughts mature, before writing this blogpost.

No, the truth is that I've been busy both at work and in my private life, so I haven't really had the time to sit down before now, and put my thoughts into a blogpost.

So, what can I say about this years GOTO Aarhus conference? Well, first of all, it was awesome. Great speakers, great people. Just generally great. GOTO Aarhus is definitely still one of my favorite conferences, and they manage to get some amazingly inspiring people to come and talk. Among the speakers at GOTO Aarhus I'd definitely recommend other people to listen to, if they have the chance, are Jez Humble, Dan North, Linda Rising, Michael Nygard, Scott Hanselman, and Martin Fowler. Each of them are not only very knowledgable, but are also great at speaking.

Overall, the tracks were well thought out, and it seemed like there had been some thought given to who was invited (though I think the conference could have benefitted from a bit more focus on diversity, if possible). One thing I did find problematic though, was that the level of the talks were a bit too diverse, even within the same conference track - some were obviously aimed at beginners while others were aimed at more trained people.

That is actually one major criticism I have of the conference: They were not very good at indicating the level of the talk. Often you went to something which seemed interesting, and found out that the level was too basic for you to get anything out of it. This is something that the organizers should aim at improving.

Another point where the conference might be improved would be the agile track. The speakers there were generally great, and the subjects interesting, yet I couldn't help feeling that they were generally covering ground that had been convered many times before. Maybe it is time for an advanced agile track for those of us who have worked with agile for a while? I can't imagine that I am the only one who feels this way.

This was actually something they aimed at with the dev-ops track, and it seemed to me that this was a good approach.

So, what was the highlights for me?

The absolute highly must have been Dirk Duellmann's keynote about Distributed Data and Storage Management for the Large Hadron Collider. It was a facinating insight into problems the rest of us never faces (who else have to take the moon's orbit or the amount of rainfall into account when analyzing data? huge, huge amounts of data).

Other than that, a few other things stood out:

• The Ada Aarhus meeting, where Linda Rising gave a great talk, and Martin Fowler argued that quotas might be the only way to get more women into IT (he finds quotas problematic, but empirical evidence points towards them being the only options).
• Talking with the vendors. A lot of people going to conferences don't speak with vendors, and they are really cheating themselves.
• Listening to Dave Thomas explaining something about the problems he work with to Jim Webber.
• Catching up with friends and former colleagues and meeting new people.
• The noSQL panel, where bloated claims by noSQL vendors were talked about. Panels can be either dead boring or brilliant. Any panel which have both Jim Webber and Martin Fowler on it, is bound to be the latter.

As can probably be gleamed, I had a great time, and I am definitely looking forward to going there again. Still, as I said, I would love for better markings of the levels of the talks, and also for there to be an advanced agile track.