Monday, October 5, 2015

Looking back on the first day of GOTO Cph - missing a bit of edge

I am at GOTO Copenhagen these days, and thought I'd post a quick overview on my thoughts on the conference.

First of all, unlike last year, it seems like the venue is too small for the conference. It is hard to get around, and many of the sessions are filled up 10 minutes before they start. It was said that the conference would be at a different venue next year, which I think is a good idea.

The first keynote was by Dr. Sengupta and was about the Mars Curiosity Rover. It was absolutely fantastic, and when there were some technical problems with the sounds in the middle of the talk, she managed that brilliantly as well.

Then there were the sessions.

I mostly went to talks in the tracks "game changing methods and practices" and "fast and continuous delivery".

I am not going to talk about the individual sessions, but I am going to quote a couple of tweets I wrote during the sessions there

There is no doubt that the process/method track gave us new techniques for doing Agile, but in my opinion, it would have been greater if the process/method track would have challenged us, and made us re-evaluate how we do systems development, rather than just provide new tools for doing it the same way.

An example of how this could have been done, would have been to find some organization that did waterfall projects with success, and get them to come an tell us about how they manage. One such organization is probably NASA, since I have a hard time imagining that the software for the systems used for landing the Mars Curiosity Rover was developed in an Agile project.

I think many of us would have loved to have our preconceptions challenged this way.

What I wrote could equally apply to the "fast and continuous delivery" track.

Sunday, September 20, 2015

Code of conducts at conferences

Looking at the GOTO Copenhagen website, I notice that there is a code of conduct linked at the bottom. The only reason why I found it, was probably because I went looking for it.

As far as I know, this is the first year that has one for a GOTO conference in Denmark, though there might have been one last year as well.

I am quite happy to see one, since I wasn't sure that there would be one, as Danes seems to have an aversion against codes of conducts for some reason or other. Earlier this month, I was at the Coldfront conference, which does have a code of conduct, but where one of the organizers felt it was necessary to half-apologize for it.

I am glad to see that code of conducts become more widespread, since I think they are necessary in order for conferences to become more inclusive.

A code of conduct is important to conferences, especially with an international crowd, for several reasons:
  1. It sets up clear boundaries of acceptable behavior.
  2. It helps enable people to speak out if they feel harassed or uncomfortable.
  3. It explains people what they should do, in case of harassment.
  4. It helps unveil the scope of the problem.
In regards to the first point, many people say that it shouldn't be necessary, and to some degree I agree, but unfortunately, experience shows us that it is necessary - especially at conferences where there is a large disparity between the genders.

It is also worth remembering that at an international conference, there will be people will different social and cultural backgrounds, and there are different boundaries in different cultures and social circles.

Regarding the point about enabling people to speak out, the existence of a code of conduct demonstrates that the conference cares about the well-being of all the participants. This in turn, encourages people to speak out when they feel that the boundaries are being pushed.

Since it often comes as a surprise for people that they are making others feel uncomfortable with their jokes or behavior, it allows those people to change their behavior in ways that makes it a pleasant occasion for everyone.

And even if there are some people that don't care if they are making other people uncomfortable, then there is the option of reporting them, which the code of conduct should provide clear instructions for.

For the organizers, it also means that they will hear about serious incidents straight away, and not through some backdoor channel long after the fact.

I think most of us would prefer that there was no need for a code of conduct, but history has shown us that this isn't the case, and it would be naive to think that if we ignore the problem, it will just go away. Instead, provide a code of conduct which provides clear boundaries and guidelines.

It seems like GOTO Copenhagen is more or less adopting the code of conduct provided by the Ada Initiative. Note that it has a public version, and an internal version for the conference staff, which includes clear instructions on how to enforce the code of conduct.

The later part is an important part of the code of conduct, which all too often was lacking in the past, creating situations where conference staff either overreacted or ignored any reports they received, and where documentation of incidents were non-existent - allowing some conferences to claim that there had been no reports of harassment at their conferences, even though several people have reported such.

Saturday, August 22, 2015

Social science and systems development

A couple of weeks ago, I wrote a blogpost on Agile and pseudo-science, which led to an interesting discussion on my Facebook wall about the lack of science and data in systems development.

As I wrote in my post, there is an unfortunately tendency of systems developers to rely on pseudo- or popular science, rather than proper science. A lot of decisions are made on assumptions for which there is no real evidence, but which somehow has become embedded in the world of systems development - be it project management, programming, testing, or some other aspect.

We tend to think of systems development as off shot of computer science with some cognitive psychology thrown in. While computer science and cognitive psychology certainly are important for creating systems, they are very much related to the "systems" part of systems development, while they hardly add to the processes, methods etc. that adds up to the "development" part.

A comment in the before-mentioned Facebook discussion suggested that we should look at social science when talking about science and systems development.

This seems like a good idea to me. A lot of what goes on in systems development is about humans interacting with each other, rather than about math, algorithms, cryptography or other aspects of computer science.

I once worked on a project where we had a horrible high turnover, which is definitely a well-known sign of a doomed team. Yet this team was one of the best teams you could imagine - continuously over-performing in the sense of delivering over scope, under budget and without flaws. From everything we know about team dynamics, this team should not have performed like this, but it did, and it could have been good to have had someone qualified there to analyse how this could be the case.

Equally it would be good to have someone look at the opposite type of teams - the ones which in theory should perform well, but which continuously under-perform. The ones where good developers suddenly seem unable to actually finish anything, where simple requirements turn into hideous bloated things, and where the only cure seems to be to kill of the team, never to let them work together again.

In both cases we know the anomalies relate to people, the interaction between them, and the culture of the team and the organization surrounding it. We just don't seem to be able to figure out how to create the first type of team, while avoiding the second type.

Given how many systems development projects fail, maybe it is worth looking at these things? And if we do, maybe we should try to find the proper tools?

Social science would seem like a good fit, and it would seem like a good idea for large organizations with many systems development projects, to take a look at how the research methods of social science could be applied to systems development, in order to become better at it.

What sounds interesting at GOTO Copenhagen 2015?

The GOTO Copenhagen conference is still a couple of months away, but I have taken a look at the talks, and spotted a few that I think will be interesting.

Generally speaking, I don't go for technology specific talks - by which I mean that I tend to go for talks about processes (e.g. Agile), concepts (e.g. Big Data) or general architecture, rather than talks about specific languages, or even worse aspects of languages, or about specific programs (e.g. a specific NoSQL database). I don't mind examples at a talk being language specific, but I prefer to be able to apply the concepts from the talk broadly.

Having said that, I am as prone to follow hype as everybody else, so if something new and exciting is presented, I might very well go there, even if it breaks my general preferences for talks.

When you see my list, you'll notice that I haven't filled my schedule. This is quite common for me - I rarely know what I want to see at a conference when I begin my day. Instead I like to hear the talks getting presented in the morning, and then decide what to go to.

If you tend to skip those talk presentations, I think you're really missing out. Some of the most exciting talks I've listened to was not remotely on my schedule until I heard them presented at the start of the day.

So... onwards to my list.

The first talk I noticed was Richard Lander's How to train your corporation to prefer open source.
Microsoft has gone through an incredible change in regards to their stance on Open Source in the last few years, to the degree where now they have Open Sourced most of the .NET platform. This is hardly something one would have guessed a few years ago (even though Microsoft has never been as anti-OS as some people think it has), so I definitely want to hear how this happened.

I don't usually go to IOS-related talks, but I might just go to Jorge D. Ortiz Fuentes' Test Driven Development (by controlling dependencies).
There is no description of the talk, but I am always interested in seeing how people handle dependencies, as I think this is an overlooked problem-area in my software development Projects. Given it is in the IOS and Swift track though, there is a high likelihood of me giving the talk a pass.

Other than the mentioned talks, I will probably spend the rest of the first day listening to talks in either the Game Changing Methods and Practices track or the Fast and Continous Delivery track.

On the second, and final, day of the conference, there are four tracks that all sounds interesting - Reactive Architectures, The State of Data, Front-end: The Bleeding Edge, and Security, Safety and Privacy.

In the first track, Reactive Architectures, I am probably going to Jonas Bonér's The Sadness at the End of the Happy Path and Dave Farley's Reactive Systems: 21st Architecture for 21st Century Systems.
Building resilient and high-performance systems is hard to do, and any ideas on how to do it better, are definitely welcome.

If I am not going to Dave Farley's talk, I will certainly be going to Dave Thomas' The State of Data 3.
I have seen Dave Thomas talk a number of times, and his talks are often quite amusing, but also, more importantly, highly informative. Big data is his field, so I expect the talk to be as great as always.

A talk that sounds interesting, is Phil Winder's Modern Fraud Prevention using Deep Learning, which is at the same time slot as  Andreas Halberg's Secure Coding Patterns - another talk that sounds useful for when developing systems.

As always, when at multi-track conferences, there are often several talks I find interesting at the same time, and which I won't choose between until the last minute. Again, much depends on how the talks are presented, and whether I have heard the speaker before. Usually there are a few speakers that are "must-go-to" for me at the GOTO conferences, but this doesn't seem to be the case at this conference. This is not a bad thing - it gives me the opportunity to get to know new great speakers.

Disclaimer: As a blogger who blogs from the conference, I get a free ticket (like I have done for the last couple of years). The deal comes with no strings attached, except for an agreement on me writing a certain number of blogposts about the conference. The conference has no say over the content of the blogpost.

Sunday, August 2, 2015

Agile and pseudo-science

Back before I started blogging about IT-related stuff, I used to write about pseudo-science on my other (very quiet) blog Pro-science, and before I had that blog, I used to comment a lot on a number of science and skeptic blogs.

First commenting and later blogging about science and pseudo-science has helped enable me to be better at detecting woo and pseudo-science in my daily life. Woo is a term used in the skeptic community to indicate something which is based on anti-science and have no scientific validity or data to back it up.

Woo and pseudo-science exists everywhere, and I have found that the field of IT is absolutely no exception. Rather, there are certain areas which is rampant with pseudo-science, often bordering on woo.

One such area is the field of Agile.

The field of Agile is not a well-defined field, but is a loosely collection of methodologies, techniques, and tools, used for systems development. It is commonly understood as having formed as a result of the agile manifesto, but in reality, it started developing before then, and would probably have come into existence as a field, even if the manifesto hadn't been written.

As a software developer, I use Agile methodologies, techniques, and tools on a daily basis. I also go to conferences and meetups about Agile frequently.

Due to that, I can't help noticing that there is not a whole lot of science behind Agile. Not only that, many of the arguments people use to promote Agile is not exactly based in science or data, but rather on pseudo-science, often in the form of popular science.

This summer, I went to a conference which had a talk on Agile and NLP. I didn't go to the talk, so I can't say anything about the actual content, but let's be perfectly clear: NLP is pseudoscience (.pdf) - see also Thirty-Five Years of Research on Neuro-Linguistic Programming. NLP Research Data Base. State of the Art or Pseudoscientific Decoration? by Tomasz Witkowski (.pdf).

If you do a search on the words "Agile" and "NLP", you'll find articles like NLP Patterns and Practices for High-Performance Teams and Achievers by J.D. Meier. If you look at the blogpost, and are in any way familiar with the writing of people pushing pseudo-science, you'll notice the patterns there. There are appeals to effectiveness and popularity, but no actual data to back those claims up. 

It is highly likely that Meier actually believes that NLP helps, but there is no science to back it up - neither in the form of an explanation of how the NLP mechanisms works or in the form of data, backing up the claims of improvement.

This is, unfortunately, widespread in the field, and not just when it relates to NLP.

Agile (as all things related to systems development) is very much dependent on people, and since most realize this, there is a lot of focus on this aspect. 

This results in many speakers on the subject on Agile, will pepper their talk with references to neuroscience, but rather than looking at the actual science papers, they will get their knowledge from popular science books, by people like Malcolm Gladwell.

In 2012, Steven Poole wrote an article for The New Stateman on the subject of popular science books on neuroscience, called Your brain on pseudoscience: the rise of popular neurobollocks. While he, in many peoples' opinion, painted with too broad a brush, there was an important message in the article, which we'll do well remembering - popular science books often have an agenda, and they are simplistic, and, in many cases, get the science completely wrong.

E.g., as a rule, one should expect anything written by Malcolm Gladwell to be wrong.

I understand why speakers and authors tend to use popular science books as sources, rather than the real science articles. With popular science books, there is a good chance that the audience has already read them, and the science is presented in a form which is easy to digest and regurgitate.

Just a pity that the science is often presented simplistic at best and wrong at worst.

Some speakers, such as Linda Rising and Kevlin Henney, instead read the original science papers, and refer to them instead. Given that those two speakers are among my favorite speakers, I hardly think it takes anything away from their talk. It just makes them more accurate.

Having addressed the use of pseudo-science and popular science, I think it is also important to address the fact of data on which to evaluate things.

This is obviously connected to the other problems. Lack of data, leads to bad conclusions.

A simple example of the lack of data, is this: How do we know Agile works? 

Or put in another way: On what basis do we conclude that Agile works better than what was there before?

As far as I've been able to find out, there is no real data to support such claims.

Yes, there have been studies that indicate that Agile works better, but those are somewhat doubtful, since there was no baseline to compare to, no clear definition of what went before Agile, or even what Agile is.

People tend to compare Agile to Waterfall, but as Laurent Bossavit wrote in his excellent book The Leprechauns of Software Engineering, there is no clear evidence that Waterfall was ever used - at least not in the form that people commonly think of when talking about the Waterfall method. 

Personally, I believe there is great value in using Agile, but I am not willing to make any claims without data to back me up, and in order to have that, we need to try to not base the field on pseudo-science and misrepresentations in popular science, and instead try to use real science, and to collect and evaluate data.

Not everything fit into the scientific method, and in a field that is so heavily dependent on people, there will be times where personal preferences will lead the way, but this doesn't mean that we can't do better.

Think of it this way: We would not accept a new UX design without an AB test or some other empirical data to back it up. So why would we accept it when it comes to our methodologies, techniques, and tools?

Monday, September 29, 2014

Privacy should be a priority

Ever since Snowden started telling the World about the doings of the NSA and other government agencies, privacy has become much more of a focus area for a lot of people - this includes Tim Bray, who debuted a new talk at GOTO Copenhagen called "Privacy and Security, Policy and Tech".

At GOTO Copenhagen, the room was unfortunately full, and I didn't get to see it, which is why I was quite happy to get a second chance the week after at GOTO Aarhus.

The overall message of Tim Bray's session was that privacy is important, and that we, as developers, should make sure to project the privacy of our users' information as much as we can.

A lot of people have a quite relaxed opinion about privacy and security, though this has started to change after Snowden. As Tim Bray said:

A lot of people has realized that the internet is a bad place, and that their information is hanging out places where it shouldn't be.
Also, people have started to realize that just because they have nothing to hide now, it doesn't mean that they won't have in the future - if nothing else, then when laws change, and formerly perfectly legal things become illegal.

A historical example of that could be membership of certain political organizations in the US, which was prefectly legal, until the red scare and McCarthyism kicked in.

Another, more recent example, is simply being a LGBT activist in Uganda, which carries high risks of prosecution, even if their "kill the Gays" law was Struck Down.

Again, quoting (or rather, paraphrasing) Tim Bray:
Most people at this conference probably live where the government is fairly civilized, and won't get their door kicked in at the middle of the night. But while it is probably true for people at this conference, it is not true for a majority of the World population as a whole.
This is an important point. Even if we have nothing to hide, and don't expect ever to have anything to hide, the same doesn't hold true for most of the World's population, perhaps including a large proportion of your end users.

This should be obvious, but a lot of people tend to forget that, and don't even enforce the most basic of methods for enabling privacy such as HTTPS.

HTTPS was an area that Tim Bray dedicated a lot of time to, exactly since it is such a basic method, and so many systems don't support it.

This has to change.

Using HTTPS is such a low-cost, easy solution that there is absolutely no reason not to use it at all times, no matter whether privacy is needed. And as Tim Bray also pointed out, there is an asymmetrical cost to using vs. not using HTTPS. Using HTTPS costs a little all the time even when it is not needed, but not using HTTPS can come at a huge cost when it was needed. This is an unacceptable risk.

One thing Tim Bray didn't get into, which I also find important, is that if everybody runs HTTPS, and thus encrypts their Communications, it offers a type of herd immunity to those who really need to protect their privacy - their communication doesn't stand out from the rest.

This is the reason why Google encrypts its user's traffic (they were actually inspired by Cory Doctorow's book Little Brother).

So, all in all, the overall message of the session was that we need to think about how we can protect the privacy of the end users, and at the very minimum we need to ensure basic privacy measures like HTTPS.

Sunday, September 28, 2014

Size doesn't matter

Big data.

A couple of years ago, at a GOTO Aarhus conference, I took a break from the sessions, and walked around in the vendor area. Here I was lucky enough to be able to listen in on a conversation between Dave Thomas and Jim Webber, where Dave Thomas was explaining to Jim Webber why graph databases, like neo4j, were not suited for the type of stuff he was doing. Basically, what Dave Thomas did, was to take all global stock data several times a day, and run some analysis on it (I am obviously simplifying it, and probably explaining it wrong).

This is the sort of things I think of when I hear the words "big data".

Since that's the case, I have been somewhat skeptical when people start talking about big data in Denmark, because we have very few domains where there are anything remotely close to such data amounts (health care probably being the one exception).

It turns out that I've basically misunderstood the concept of big data, and that I underestimated the amount of data out there.

At GOTO Copenhagen, I went to a talk with Eva Andreasson, where she gave an overview of the big data landscape, mostly at the vendor level. During this session, she made a number of important points, which made me realize I have to change my view on big data and its usage in Denmark.

First of all, Eva Andreasson made clear that only about 10% of all data out there is what we traditionally would consider data (e.g. data about companies or people). The rest of it is all the trace data that people leave around when they navigate the internet, doing whatever shopping or browsing they want.

Such trace data, put together with traditional data, allows companies to analyze end-user behavior much better than traditional data alone. E.g. while traditional data will tell you what customers bought, trace data will tell you what products customers spent a long time looking at, without buying them at the end - allowing the company to do some further analysis on what it would take to get the customers to buy the product.

Another thing that Eva Andreasson made clear, is that big data isn't just about working on large data amounts. It is also about aggregating new data sources into existing use scenarios of existing data, and about making new use scenarios of the data that you work with, allowing you to look at things in new ways, hopefully gaining new insights.

Based on these two points, it is clear to me that I have to reevaluate my understanding of when big data is relevant. And judging from the conversations I've had with other people about big data, I am not alone in this.

Saturday, September 27, 2014

Aim for the stars

One of the great things at most conferences is the keynote talks, since they are usually picked by the conference organizers in order to expand the mental horizons of the conferences goers.

The organizers behind the GOTO conferences are, in my opinion, particularly good at this.

Every time I've been to a GOTO conference (or a QCon conference where they have been involved), there has been at least one keynote talk, that made me rethink things, and look at the field in new ways.

At GOTO Copenhagen, there were several such talks, but one of them stands out in particular.

On a two-day conference, the least attractive keynote slot must be the early one on the second day (after the conference dinner the evening before), and I am always impressed by the speakers who can go on stage at that slot, and leave an unforgetable impression.

At GOTO Copenhagen it was Russ Olsen who gave his "To the Moon" talk.

I hadn't heard Russ Olsen before, but judging from the keynote talk, he is a great speaker, and I'll definitely check out any talks of his I come across in the future.

So, what was so great about Russ Olsen's talk?

Well, as my tweet embedded above states, it was about the Moon landing and what we, as a field, can learn from it. Most people would probably find this interesting as it is, but my description doesn't do the talk justice at all - Russ Olsen manages to express the feelings of nerverousness and wonder behind the whole process, especially during the last 10 minutes of decent towards the moon.

Russ Olsen also has a great message - quoting Kennedy, he reminds people that they shouldn't do something because it is easy, but because it is hard, and that nothing is impossible.

So, if you're at GOTO Aarhus, I would highly recommend going to Russ Olsen's keynote talk on Tuesday, even if the conference dinner made you get to bed late. But in case you miss it, it can apparently be found online.

Ahead of my time

If you follow me on twitter, you'll undoubtfully have noticed that I've spent the last couple of days at the GOTO Copenhagen conference.

If you look at my last couple of blogposts, that might surprise you, since they were about going to GOTO Aarhus, not GOTO Copenhagen. Well, that's because I am going to GOTO Aarhus in my capacity as a blogger, while I went to GOTO Copenhagen as a "civilian" (i.e. together with some of my colleagues). Since GOTO Copenhagen and GOTO Aarhus have the same sessions, this means that I probably get to see more of the sessions than anyone else, perhaps excluding the speakers themselves.

Even though I didn't go to GOTO Copenhagen as a blogger, it won't keep me from writing a bit about my impressions from the sessions I attended there - this also allows me to make some suggestions for what people should go to at GOTO Aarhus.

Below is my schedule during GOTO Copenhagen:

  • New Linting Rules - Kyle Simpson (Enterprise Architecture)
  • From 'Agile Hangover' to 'Antifragile Organisations' - Russell Miles (People & Process)
  • Fast Delivery - Adrian Cockcroft (People & Process)
  • Deep Dive into the Big Data Landscape - Part I - Eva Andreasson (Enterprise Architecture)
  • Lean Enterprise - Part II - Jez Humble (People & Process)
  • The Future of C# - Mads Torgersen (Enterprise Architecture)
  • What I Learned About Going Fast at eBay and Google - Randy Shoup (People & Process)
  • Responding in a timely manner - Microseconds in HFT or milliseconds in web apps, its all the the same design principles - Martin Thompson (Enterprise Architecture)
  • A retake on the Agile Manifesto Part I - Katherine Kirk/Prag-Dave Thomas/Jez Humble/Tatiana Badiceanu/Martin Fowler (People & Process)
  • A retake on the Agile Manifesto Part II - Katherine Kirk/Prag-Dave Thomas/Jez Humble/Tatiana Badiceanu/Martin Fowler (People & Process)
As with most conferences, there is a rating system, where one can indicate what you feel about a given session. At GOTO it is the classic green-yellow-red system. All of the sessions I attended, with one exception, I gave a green - and the one I gave a yellow, I actually think in hind-sight also deserved a green.
I should probably add that I give a green based on either of two critierias:
  1. Was it interesting/informative/entertaining
  2. Did I get new insights out of it
This means that theoretically a speaker can be less than stellar, but able to give me new insights, and then receive a green vote. In reality, however, this happens very rarely, so green votes are usually given to great speakers, who usually are also able to provide me insights.

Sunday, August 10, 2014

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.