Qcon London 2013: Agile User Group Meeting

Speakers: Dan North and Ward Cunningham 

Time: March 7, 2013, 18:30-20:00

Place: Room Mountbatten 6th floor, The Queen Elizabeth II Conference Centre, London

Yesterday me, Jem - our super Scrum Master/Agile coach - and his wrestler brother went to Qcon London 201 for the Agile User Group Meeting where we had a chance to see two big Agile names sharing bits of their minds, Dan North and Ward Cunningham. Cunningham is one of the chubby geeks that were in the ski resort when they first created the Agile Manifesto. He actually hosts the Agile Manifesto website.

It is pretty much like if Jesus have had the help of the apostles to write his commandments and now you can have a chat with one of them about it… :-)

The whole thing was mainly a serious of questions posed at them who would them debate and give their perspectives about it. This is another one of my long brain dumps with the notes I took during the meeting.

Agile, the Manifesto, ...

The whole Agile thing started with these geeks "confined" in a ski resort mainly discussing "lightweight methodologies" which would help in the delivery of software. Because each of them had a different interpretation of what these methodologies would be they decided to scope the whole lot under the name Agile, an umbrella term.

When asked if they would add anything to the Agile Manifesto? They said - NahIn the past it was pretty much about fat documentation, RFCs, ISOs, and all kinds of crazy agreements. You don't need that. Just these 4 principles are more than enough.

When asked if they would change anything to the Agile Manifesto? They said - Nah. Actually  Cunningham said if he could he would probably choose a different pinky tone for the background of the Manifesto :-) More than 10 years after first writing it they still think it is all right. Wrong is the way people actually get it. The main goal with the manifesto was to tackle the problem of software delivery while the main thing with agility is to let you be able to adapt to your present situation.

Extreme Programming Principles:
1. Simplicity, 2. Communication, 3. Courage, 4. Feedback.

Further study notes: check on Alistair Cockburn and Cristal methodologies (family of Agile methods).

 

Where is Agile going next?

On their view the new big thing with Agile is extending to other levels: DevOps, UI, UX, there is still a lot to be done in order to bring these areas under the Agile methodology. They stressed the importance of a CI environment and new trends like Agile DatabasesVirtualization (VM) and the cultural shift still required to get all these things in place.

Risks are based on two things: Likelihood and Impact. A CI environment mitigates the impact because it brakes the build and it won't let the problems get to the clients. Plus, your newly hired dev can learn by breaking the code instead of being coding blindly without knowing the full impact of their changes.

Further study notes: check on Agile Databases and Lean Business.

 

Client Collaboration

Jem made a nice question - if they think "people over processes" would be more of a "processes over people" in the sense of having to be strict and reinforce Agile in places where people would try to do a "dirty Agile" or cut corners. On their view this is not the case. Most technology problems are really about communication and feedback. The problem is not Agile.

Based on a few questions from the audience about client relationship and how to engage with them in order to have their collaboration they also made very interesting points. It all starts with the basics: - Tell me about your company? What do you really want? What's going wrong? This simple questions will highlight what needs to be changed. The thing is, nobody really wants Agile in their organisation  Most of the time they don't know what they want and sometimes they don't even know what is wrong although there is something wrong (more than one thing, on most cases). From all the problems, select 3 to be tackled. Forget about the rest. Stop where you are. Stay where you are. Don't try to embrace the whole Universe all at once.Be situation specific. What an improvement would be? Sometimes is just about finding where is the miscommunication.. it is still about people over processes.

So how do you drag clients into the Agile mentality? "When you talk to a farmer use farmers language". Clients don't want to hear about your sprint, times, reviews, points and all this nonsense. They want ROI, precise dates, transparency. So maybe you call him and suggest about twice a week meetings where you could show work and get their feedback for example. You can not mention anything about cycles or interactions but still be able to transmit the Agile mindset.

Further study notes: read "Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience", check on the fact that the UK government is going Agile.

 

Scrum of Scrums? Scaling Agile?

This was another cool topic. When I went on my Scrum Master course with Scrum Alliance, I remember Nigel Baker going through this topic. On Cunningham's opinion Agile does not scale. Teams cannot be international, teams cannot scale. At the end it is still about having a small motivated number of people. You have different approaches that have shown to work amazingly well like Open Source initiatives, a clear example is Github where most employees are remote, they have a virtual office culture in place but these guys are not doing Agile. They probably use a few elements of it but it is still Open Source or something else. According to him,this is not Agile.

North had a similar opinion but thinks you could make it work and mentioned he himself have seem a few cases of big teams using Agile and making it work. The point here is that you wouldneed great developers who could split up a big piece of work into interesting smaller parts that would be splited between teams and you would need a big funding on air miles.Information moves with peoples. It is not about phone calls, writing emails. People are the information and you need these guys to fly and shift around.

 

Different Agile methodologies - If is all about people over process should we kill all processes and just get on with it?

That was another good one and the answer was with another question. How much do you have to know to say a certain methodology does not work? You need to balance things and study a lot in order to come up with your own way of doing stuff. Once your own methodology has proven effective it is up to you to let people know about it. Even if you fail you still learned something and at the end of the day your success will quickly pay off your failures because it will come  quicker since you are failing quicker. Agile is about failing fast.

 

Agile and Outsourcing - How does Agile fit with the current trend in outsourcing code and trying to make software cheaper?

The job of a programmer is not to produc code but to solve problem. Code is not valuable. The utility given is where the value lays. If you can tackle the issue without any code the better. 

For a certain software, 25% of its features are used 80% of the time, 30% will be used on and off and the rest is probably never used. Take Word for example.. or Excel.. you get the picture right? What if you agreed to deliver only this 25% instead of the less 75% used? You instantly decrease the amount of money and devs needed to get work done. Outsource normally end up more expensive and creating problems that will come to haunt you in the future.

 

Agile and Communication - So how do you make geeks talk?!
Interesting ways to deal with this and regarding a general improve in communication were giving by mentioning as example a bank where before people had their bonus based on how tech they were or how many lines of code they had done during the year. To improve communications they changed this scheme to 30% based on how tech you are, 30% based on your work mates perception of you and the other 30% on how DevOps think you helped. There was a great improvement in collaboration between devs and devOps. You can "force" people to interact. A lot of the lack of communication comes not because devs are reserved geeks without the appropriated interpersonal skill set but to how the organisation promotes and rewards such interactions.

 

Nice quotes....

"Every time I have someone new at my company I would ask them after a couple days what's the suckiest thing you see in here? Ok, now go on and fix it."

"An idea has 3 stages: Impossible, Dangerous and Obvious."

"Sometimes is easier to write code in the wrong place and then move it around than spending ages trying to figure out the right place for a piece of code."