Andy's Mind

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.

In one of the recent episodes of Dilbert agile gets mentioned (not for the first time). One of my friends said that “Dilbert turned against us” but in fact I think this cartoon very pointedly shows how much a typical manager (Pointy-Haired Boss) knows about agile. Managers like the PHB from Dilbert cartoons do exists in large corporations for real, I’ve met some. But much more managers, accustomed to reporting, WBSs, Gantts, PMSs, 3 months requirements analysis, specifications documents, acceptance documents etc. do think that getting rid of all that means complete chaos and lack of all rules.

That the rules are scaled down it doesn’t mean they don’t work. In fact, rules have a much higher chance of working if there is just a few of them, not a whole 200 pages handbook. Same goes for documentation and almost everything else. Things have to be scaled down so that the rules and information are manageable to humans.

Take Scrum – it is just three roles (the Team, the Product Owner, the Scrum Master), two lists (the Product Backlog and the Sprint Backlog) and three meetings (the Sprint Planning, the Daily Scrum and the Sprint Review). That’s all, not much to tweak around, simple to introduce and then follow. Same goes for XP – simple ideas, easy to understand directions.

But simple doesn’t mean easy. Building unit tests for everything also does require labor, though most who don’t know agile regrettably don’t associate it with extensive testing. Same about management -Scrum may be simple but being a Scrum Master is a demanding work – and requiring certain personality traits PHBs usually don’t have.

This ignorance about agile I’m sure leads to many failed projects when people don’t read up, don’t learn and really believe agile is the same as “cowboy coding”.  This gives agile a bad name, but I’m sure this will change with time.

I don’t know how many people realize that, but the roots of modern project management are in the early 20th century and stem from heavy industries, military logistics and… civil engineering. Gantt himself was working in the late 19th century steel industry, his chart (in its current form invented in fact by Karol Adamiecki) was used in the major construction projects of the New Deal (like the Hoover Dam). It was long before any software projects that it has become an icon of project management along with a whole set of methods, practices and theories.

There is no doubt that these methods were proven to work for the industries they were invented for. They got refined over the years, getting to the point where they could be considered scientific. A whole body of knowledge was gathered over time, institutionalized in bodies like the PMI, their PMBOK and certifications. Then all that was applied to software engineering, which someone erroneously mistook for another form of engineering or even manufacturing.

The problem is that a typical software project is very unlike an assembly line, but also differs very significantly form any civil engineering construction project. Let’s take my favorite example – building a bridge – and compare it to a software project.

When you build a bridge the environment (layout of the river, hills around it etc.) is largely known and very unlikely to change, as opposed to modern software projects. Also the requirements of the client are very simple, clear and not likely to change – no one sane will ask the bridge to be drastically changed midway into the project. The complexity level of the object being created is much lower than in an even small software project – depending on how you count even a simple software package contains hundreds of functions and thousands of variables.

The human side is also very different. In traditional industries, like civil engineering, organization is based on few knowledgeable individuals having a picture of the whole at the top and a command chain that transmits their design to the workers executing it. A typical construction worker doesn’t have to know the whole design of the bridge, nor is he required to be capable of understanding it. He has to be able to do well some specialized task (like pouring concrete or laying reinforcements) where directed. It doesn’t mean he is stupid – don’t get me wrong – but his training and knowledge are very different from that of the civil engineer who designed the whole structure.

This is quite contrary to a typical software developer who not only has to be capable of understanding the whole of the project he works on, but also has to know and understand the design to be able to effectively contribute. This is why organizing software development with command chains and “architects” leading the (largely ignorant) flock is wasteful and wrong. There is no doubt that developers with bigger experience are better at design and are better suited to lead juniors, but there is no fundamental difference between them.

There is nothing new going on here – humanity has always tried to apply methods from the past to the problems of today. It mostly worked, but sometimes it didn’t and the visible failure of existing methods or assumptions usually led to a positive change. The same is now happening with the software engineering. After realizing that the classical waterfall approach rooted in other industries from another time led to poor quality and even worse predictability the IT industry moves forward with the agile movement.

Agile is now quickly becoming mainstream because it reflects the reality of software creation. That’s why itn most cases it delivers on its promises of delivering better product and increasing teams effectiveness.

Building a bridge is my personal favorite example, because that’s what my father was doing before he moved into materials science.