TechBiz


The empiricism underpinning all agile methods means that people live in a constant inspect & adapt loop. It is primarily about the product being worked on – but it also applies to teams themselves. The idea is that with agile not only the product evolves and gets better, but also the teams – and thus people teams are made of. This is one of the claims as to why agile is inherently better than waterfall – it not only produces better products, but also better teams. Some agile methods recognize improvement in teams’ ability as an important part of the process and prescribe tools to foster it – for example a retrospective producing actionable improvements every sprint is a required part of Scrum.

This is all very nice & good, but the problem is that improvement is a slow, monotonous process. It is rarely achieved by doing something spectacular. It usually means adjusting work methods, coding styles, design habits and daily routines. Often those are small adjustments or they are achieved by a series of small steps through time. It means taking the actionable improvements seriously and honestly striving to implement them every day, every iteration (sprint to use the Scrum term).

Why is this a problem? Because there is little joy in this as the change happening every day or every week is so small it is imperceptible for those involved.

How can we solve it? By making the improvement visible – and by keeping the work itself fun and engaging.

One great tool is retrospectives – they should not be solely about hunting down problems, but also recognizing, even celebrating improvements that the team achieved. There is a strong tendency to be negative during retrospectives, to concentrate on what didn’t go well as opposed to recognizing what was right. A more balanced retrospective gives team a chance to realize how much they have improved since the last time.

Another idea for making improvement visible is encouraging both internal and external sharing of knowledge and work through talks and conferences. If you talk to peers about a craft you share you will frequently find that what is already part of daily work for you is a discovery for others. This is the moment when you realize how much you have improved. Organizing a monthly, internal “tech talk” or encouraging people to submit talks to conferences is a way to foster this.

In any case I think it is the Scrum Masters (or Agile Whatevers) role & responsibility to make improvement visible, at least from time to time. It also part of the responsibility of managers overseeing the overall development organization. And it all starts with recognizing that improvement is boring…

Update:
This problem is not exceptional to software development. It is exactly the same in other crafts/skills – path to mastery leads through small improvements.

In fact, it should be easier for software developers, because in their case the improving quite frequently means learning something new – and this rewarding in itself. Others have it harder, because in other activities improvement comes through repeating same things over and over again. Musicians play & play same tunes for hours to get better. Soccer players repeat same standard moves as part of their training.

What is common, however, is that a) it takes discipline and willpower to improve and b) from time to time the improvement made is made visible (a musician plays a concert, a soccer players plays a match).

Bob Marshall wrote on his popular blog, that retrospectives make no sense if they are not about a hypothesis – or in other words, if they are not about analyzing why things didn’t go as we envisioned. This was followed with others voicing their agreement (example). While I agree with Bob on many things this time I think he missed the point of retrospectives as such.

Retrospectives for me are not a part of the process of “manufacturing” software per se, as they are not related to the product (software). Their purpose is not testing some pre-formulated hypotheses about the process – their point is discovery leading to self improvement. This discovery is achieved by stepping aside from the process, stopping and taking a look back to reflect on what happened, then considering our present state as a team and finally looking into our future. And key focus here should be us as a group of people – humans – being (experiencing our existence) together: how we related to one another, how we related to those not on the team, how we felt about what we were doing and – lastly – how we were doing it. By discussing this as a group we also develop stronger bonds – retrospectives are an important part of the true team-building process (as opposed to silly, artificial “team building” trips and parties).

Retrospectives – at least the way I treat them – are akin to group therapy sessions for teams. I’m not using this analogy lightly, I think some elements of retrospectives are therapeutic. That’s why I see value in them being led – at least from time to time – by outsiders (coaches). Paradoxically it is easier for groups to open up with the assistance of a stranger, who is not part of teams’ internal dynamics nor local politics.

No matter who leads a retrospective any pre-formulated hypotheses or (worse) outcomes are an impediment to the discovery process. We should approach a retrospective totally open-minded, curious maybe as to what will surface this time.

That is why we should retrospect regularly, using varied techniques to avoid routine and stagnation. Retrospecting only when there is a hypothesis to test (as a lady from Target Processes said they do) is, in my humble opinion, a suboptimal practice – it is loosing most of the value retrospectives can bring.

Something I wrote the other day to a team I was coaching:

As you may remember at the end of the second day I made the observation that if I were to describe you with one word I would choose “everything”. This is so because many times you collectively tried to cover everything in your designs, plans and other considerations in an attempt to get it perfect on the first try. That’s why you were unable to complete your sprint planning within the timebox.

It is easy to get drawn into discussing all the possibilities, options and potential risks in the end producing nothing. Our minds get overwhelmed with complexity and paralyzed with the desire to get the right solution on first attempt. Agile approach is to break big, complex problems into small chunks and then fully solve them within small iterations producing working software. So, the agile way is to do something rather than everything – but to do it well and keep on doing something each and every sprint all the time improving both the product and ourselves. By keeping doing something well each day, week, month you can build anything in the long run.

That is how agile breaks complexity with consistency.

When I talk to software developers[1] I always stress that as professionals they have an ethical obligation to deliver good code quality. I’m not alone in this – people far more known and respected, like Ken Schwaber for example, keep on saying the very same thing for years now: if you are software professionals you have to act like professionals.

This obligation is very much linked to the so-called structural quality (how well the code is built), because this aspect of software has a great effect on our clients and future users of the software we produce, yet it is completely hidden from the clients. Clients can, for the most part, detect visible functional defects (application no doing what was intended, system ill-behaving etc.), but they are usually not equipped to assess how well the software they pay for has been built internally. However, in the long run it is the structural quality that has a higher impact on the total cost of ownership and other financial parameters of a software project. The customers are obviously not professionals in the field of software development, but they trust that developers they hire are. Therefore, clients have all the right to expect good quality (understood as well built, testable, extendable, maintainable code) even if it was not explicitly requested in the contract. However, for now software developers yield to pressure and produce horrendous code just to meet time constraints (commonly known as “deadlines”).

A good parallel is civil engineering. If we hire a construction company to build a building for us we expect it to be structurally safe, built from safe materials and adhering to widely accepted engineering standards. Clients are not expected to be civil engineers or construction foremans capable of personally ensuring it is the case – clients trust builders will do their job properly and by virtue of clients’ trust it is the builders’ ethical obligation. This ethical obligation is so widely recognized in societies, that is has became a legal obligation almost everywhere in the world.

It is only logical then that the same will happen to the software development profession at some point. What I wait for now is a lawsuit that will claim damages from a software development company for poor structural quality of a working software product “delivered on time and within scope”. A client will finally come to claim damages after they find out two years after delivery that while the product works its code is unreadable, it doesn’t have an automatic test harness (unit testes, automated acceptance tests etc.) and it is therefore very costly or impossible to extend it further. I am not a lawyer, but I do think it would be a winnable case.

I wonder if those in the software development profession really need such a wake-up call from the legal system before they will understand that it has their obligation to do things right – not just “on time, within scope”.

[1] By “developers” I understand everyone involved in building a software product – not only programmers, but also test engineers, DB gurus, usability designers etc. etc.

« Previous PageNext Page »