Andy's Mind

The last day of the Agile Development Practices kicked off with a keynote by Jutta Eckstein on scaling agile development in really big organizations (Deutsche Telekom I suspect). I have to say it wasn’t all that interesting – the delivery was not spirited and the way they did in Germany smelled of trying to make good all command&control chains sound agile. I used the time to jot down some notes before the Open Space session that I initiated.

It turned out few people were there, but there was another session started by Chris Spagnuolo on agile contracting – which was pretty much the same thing – so we merged the two and had a very good discussion with his other colleague, Zvonimir Durcevic and Rachel Weston of Rally Software. It turned out each of us were in a bit different position even though we all do outsourced agile. Chris’ clients are mostly government agencies, so sadly they are stuck with fixed bids – their clients even if sold on agile just can’t go around the straitjacket of regulations. Rally in turn does what I called “being agile wolf in sheep’s skin” – they first play their clients by the book, offering a bid etc. and then once they have them signed off try to sway them to agile modifying (amending) contract later on. That sounds like an interesting way of getting in, but there is always the risk they will have go against the fixed contract anyway – with known bad results (money lost, quality degraded etc.). Still, again, with some types of clients that the only thing you can do.

Next, I got immersed in a discussion with Richard Sharpe of Enerjy and another guy doing testing, measurement and qa analysis. Guys at Enerjy did some really cool research they are about to go public with, which will basically allow to programmatically find areas in software likely to have bugs based on certain metrics. Now, I’m a metric-skeptic but I think if they really have an algorithm that can do that it’s a big thing. In the course of that discussion I learned they have quite an interesting blog there – and a video blog too, for which Richard was making recordings there. I’d have to check it out.

We also discussed some pretty crazy stuff about how Europe is going more and more socialist – and in stupid ways too. It turns out, for example, that in Germany one is not allowed to track individual performance of employees, for example software developers. When they tried to sell some software that tracks different quality metrics in software they were not allowed to enable the part that does this per developer. Complete utter idiocy.

Because of that interesting chat I kind of missed one session – so I went to next one, which was about thing called Fit. Fit is of course an acronym (it’s US after all) for Framework for Integrated Tests and the idea behind it is to follow business rules and check whether software we build meets them. So it’s not unit test – and it’s not functional test, but rather something in between. James Shore presented all that in a rather dry, academic style which I think scared some of the audience away. I had hard time trying to stay focused as the room was so cold in the end my primary concern was staying warm. But anyway, that was interesting stuff – I’d have to point it to my team, even though I think right now we don’t do anything that we could use it for. And the tool itself is working mainly with .NET – or in other words crap we stay away from.

Last strong accord of the conference was Andy Hunt‘s keynote, which he himself called “a dessert”. It was again a broad reflection on research into generations, their characteristics and the fact, there is certain repeatability to general trends in how generations view world. The catch is that this repeatability goes on every four generations more or less – so the one entering the world has no chance to meet their grand-grand-parents and see how much in common they have. That would explain a lot of the cycles that are clearly visible in history, though it obviously opens another question: what causes this pattern to occur.

In any case Andy’s point was that surprisingly – or not so – the what is considered a good method for developing software reflects very well the outlook on life and everything typical of the generation dominant in a given time. Which means that at some point even waterfall might make sense again. On the other hand, Andy was wise enough to point out that this cozy picture of a generations wheel turning predictably through history can and probably will be disrupted by a black swan event – or a huge event no one can possibly foresee.

Well, we’ll see how it all goes. For now let’s say that this conference was a great learning and networking opportunity. I’ll do my best to return next year.

It’s day three and the proper conference opened after two days of tutorials with a keynote by Mary Poppendieck. She officially recognized that agile has become mainstream now, referencing a book about how ideas cross a chasm separating them from mainstream. But instead of cheering and encouraging the audience to indulge in feeling good about it she warned us about possible ways in which we could fail with agile. What I did carry out from that speech was that we shouldn’t become too attached to “agile methodologies”. We shouldn’t follow what others are doing but rather constantly inspect what we do and adapt to our own circumstances. Mary’s keynote was full of references to books and cases showing the progress continues – some even see iterations as a transitional stage to a state of perpetual release, constant improvement.

Mary’s overall message was important to me. I represent a small team working from a little country at the outskirts of Europe – and hence I have a tendency to look up to those great organizations at the bleeding edge of the new. But we can be great too – and in fact, as I already observed, my team is well ahead of most of the people I spoke to during breaks. And that there are teams that are even better is great too – at least we know we have to keep on improving. Our clients can only benefit from that.

Afterwards I attended a session led by James Waletzky from Microsoft, which was… well, boring. He had this great idea of using two of his friends as actors playing a pair of developers – a waterfall-ish one and an agile one – talking about emerging vs. upfront design while he commented on it. It was maybe a nice idea, but the actors were not in sync with his presentation and what they discussed was so basic I got bored quickly. I didn’t want to disrupt others by leaving so I opened my laptop and responded to some e-mails thanks to Wi-fi reaching into that particular room.

Luckily, that was the only disappointment of the day. The afternoon sessions by Andy Hunt about the workings of the mind and improving how we learn and handle things in our heads were quite interesting. Some practices – like GTD or mind mapping or the left-brain vs. right-brain thinking – I was already familiar with. Others were new or I’ve just read about them but didn’t use them.

I always like to listen to people who have broad knowledge, research many things and can talk about them in an interesting way. I feel I have lots in common with such people, whom I call “searchers”. It is great that there are others who don’t just use the mind, but try to understand what it is and how it works.

During the break there was a small discussion and it turned out some insights I gained from my meditation practice were quite interesting for the others. I was surprised that Andy – being interested in the workings of the mind – started some kind of meditation practice only recently. We also exchanged some ideas – I’m now researching what EMDR is, Andy will – I’m sure – go through the website of the Global Conscience Project. As it is frequently the case – questions and discussions during breaks can be as valuable as the sessions themselves.

The day closed with another keynote, this time by Mike Cohn. His presentation – as usual powerfully delivered – concentrated on reservations and fears people have against switching to agile. Not much new material for me, but again, hearing it in an organized fashion was quite refreshing.

Tomorrow I’ll be leading an open space session on agile in outsourcing. I don’t count on many people being interested in such a discussion but I thought it’s worth a try especially as the subject is really underrepresented in the conference (and most of agile literature).

I opened my second day of Agile Development Practices on a high note with Mike Cohn‘s “Agile estimating and planning” session. Mike is one of the best speakers and trainers in the whole agile movement – he conveys ideas in a very powerful way, yet despite his experience and knowledge he remains friendly, accessible and laid back. I think the biggest value in his sessions is always in his replies to questions from the audience and the chance to talk to him during breaks – or listen in on others doing that.

Even though we have been estimating and planning with the team for quite a time I still found going through it all in an organized fashion very refreshing. It did rejuvenate my idea of moving the team from ideal days to story points in estimating the product backlog. Also quite interesting was Mike’s point that people are better at relative than absolute estimating yet favor precision over accuracy. A few exercises were designed so that participants could see how their minds make implicit assumptions to arrive at a number which is in fact less accurate and more misleading than a range.

One of the examples: how long will it take to drive from Orlando, FL to Seattle, WA? No one could answer it with a number, but most tried to making certain assumptions about speed, conditions etc. An accurate answer would be a range – let’s say 7 days +5/-3 days – but people would strive to give a single number. Precise seemed better than accurate. This is important to remember – as Mike underlined good decision making has to be based on accurate information. If precision is not possible at a given time it is better if the decision maker knows that. Hiding uncertainty behind a seemingly precise number denies decision maker important information hence leading to wrong choices.

It’s another point to what I and others have been saying about fixed bids being wrong. The whole concept of a fixed bid is requiring a precise answer (an amount, a date) at the point in the project where the certainty is lowest and the risk is highest. Is it ok if a client is served an illusion of certainty when there is in fact lots of uncertainty? Wouldn’t it be better if he was honestly informed that it is indeed at that stage a range rather than a precise number?

Afternoon I spent on a session about retrospectives led by Esther Derby and Diana Larson.

I read their book on the plane from Europe but I put it down a bit disappointed. The whole approach seemed a bit artificial. I imagined it would feel awkward and stupid to use the activities and techniques described with my team. I have to say this workshop changed my mind on this – seeing it all in action made the book kind of spring to life. Now it will become a resource to bring some fresh air to our retrospectives. I hope the team will enjoy that.

The day concluded with a reception (I was amazed that some were still able to eat after all the food we are served all the day during breaks) – a chance to chat with the others. Always an interesting experience – and uplifting, since I see that as a team we are much more advanced in using agile than most participants of this conference. I’m looking forward to another day – the format now will be less interactive, I’m afraid, but I’ll go to the open space – maybe I’ll have a chance to share some of my insights about using agile in outsourcing.

I attended Ken Pugh‘s session on agile requirements management today on the SQE‘s Agile Development Practices conference. What surprised me was that most participants were newcomers to agile – stuff like user stories, planing poker, story points etc. were a complete novelty to them. Judging from the questions & teamwork during the session and the chats during the breaks I have to say that we are doing pretty good as a team in this area. We have a pretty good process for starting projects and getting requirements from clients in an agile way. We get the most important user stories within one few-hour long initial backlog creation session – and then refine and evolve the backlog together with the client as the project develops.

Many of the techniques presented by Ken were applicable mainly to projects ranging from large to huge – and in corporate environment. But still I walked from that sessions with few ideas how we could improve what we do – and add to our toolbox for a bigger project when it comes our way.

One of the things Ken demonstrated was Business Value Points technique. The idea is to capture the relative business value of each user story as seen by the customer. It works pretty much the same as story points for effort or difficulty: stakeholders can do “planning poker” on perceived business value of each user story. As with each poker-style estimating only stories where there is a disagreement in the group get discussed at length and a consensus is achieved. The result can be then one of the factors in the planning sessions. Or it can be used along with story points to calculate how much value for the effort could be obtained. It is – I think – a great process for fostering some agreement on the priorities when instead of one product owner we have a group with different interestes.

Overall, this was an interesting day and I’m looking forward to tomorrow.