Agile teams are neglecting design.
I can already hear your objections. Surely, you will say, many Agile teams these days do test-driven development and TDD is all about design. I absolutely agree, after all, I dare not question Uncle Bob who, in his “Agile Principles, Patterns, and Practices in C#” book clearly says
“The act of writing a unit test is more an act of design than of verification”.
The problem, however, is not if we are doing TDD but how we are doing it. Writing unit tests before production code, watching the tests fail, writing corresponding production code until the test passes and then refactoring requires discipline. Many new Agile teams lack that discipline. To gain the full benefits of TDD also requires a lot of practice and teams may simply have not had the time to accrue enough.
These two obstacles aside, I still don’t see the practice of TDD shaping the design of teams’ code in a way that Steve and Nat describe in their excellent “Growing Object-Oriented Software, Guided by Tests” book. I think among the reasons sits this one: frameworks.
I see this time and time again: a new engaged, eager and energised Agile team sits together to start a new project. They want to break away from the old ways of working. They have already been freed from the heavyweight processes which required lengthy documents, endless approvals and then subjected them to a stream of bugs arriving weeks or months after they last touched the affected code. They also take this as an opportunity to break away from the technical baggage accumulated over the years. Not doing so would be to neglect the Conway’s law.
And then what does a team do? They pick a framework. Chances are, if you are an Agile team writing a website in .Net you will go for the ASP.NET MVC framework. If you are trying to move away from the monstrosities of Java Enterprise frameworks or got tired of Spring you might be moving to grails. If you are more daring you drop you old technology altogether and pick rails. Add an ORM on top or something from the NoSQL pallet and your fresh new architecture is ready waiting for you.
While there is absolutely nothing wrong with these frameworks and technologies, making such choice means you have given up design decisions that you would have otherwise had to think about. You start working within a framework and then your thinking re-focuses to consider how best to fit your problem into the skeleton which is already in place. It might be slightly awkward to write some of the unit tests but you just blame that on your inexperience with the new technique.
Isn’t it ironic, that as we free ourselves from the rigidity of the organisational processes we are willing to subject ourselves to the rigidity of the framework structures.
In the short time, we go astonishingly quickly, new functionality flows into releases, new pages appear, database expands magically and there is none of that old hand-crafted SQL to worry about. Many Agile teams are probably still at this stage. The will go on to neglect design, they won’t question the structure of their code at various levels, they won’t reevaluate their architecture. Then strangely, release by release, they start to slow down. Features become more difficult to implement, changes solidify, codebase stagnates.
I just hope it’s not your team.
Catia, thank you for inviting me to pair-write. Here is a story:
I walk into my daughter’s bedroom. She’s only three so there is still time before she slaps her favourite band, actor or a Moominvalley character poster on the wall. So far we have been doing all the writing. There is her name in nice red serif on one wall and a pale-pink “sleep tight, sweet dreams” next to her bed. I think she likes it.
However, we didn’t write “we value you as an individual” or “we care about your wellbeing”. She wouldn’t get it. We wouldn’t write it. Who would?
We were talking about companies though, so back into the corporate world, here is another story:
I used to work at a company. You might say I was engaged at a company. (How funny it means both to be busy or occupied and pledged to be married). Guess what? They had the list in their pocket. It had four values on it. People were supposed to aspire to be brave, decent, imaginative and supportive. Not a bad set you might say? I agree. I have certainly done my share of being brave, too brave at times 😉 I hope I was supportive.. and so on. There was also this one director who couldn’t care less to remember what people did or what their names were. A project manager who would report one status to the stakeholders and another to the team. Team leader who would rarely leave his desk or a senior developer who would jeopardise any attempts to use new bits of technology. There was also the appraisal system to evaluate your performance against a stale set of artificial objectives with a cap on how many people can score well.
It was too painful to look at the bold and ambitious declarations and at the constant actions undermining them. Eventually I filed for a divorce. I have left. It turns out, others did too. Recently I’ve checked again. Now, this company has only three values: brave, imaginative and decent. Somehow begin supportive didn’t work out? Maybe it’s better that way.
I agree, values work best when they are embodied in what we do: in our relations, in our decisions and attitude. We’re generally pretty good at picking up hints from around us, we notice quickly when colleagues are friendly towards each other, when managers trust their teams, when directors are honest. We do not need a map for that. To single out a set of values is perhaps too constraining is such case. Would it mean we don’t care about other values?
There is also another important problem when we fly the values on a poster, especially it it’s done superficially. Ask Argyris (well, you might not want to bother him, read instead). Each of us has a set of espoused values. Values we think we put in practice. There is however also the other set of values, the values in use – those visible through our actions. No matter how “good” we think we are there is always a gap between the two and our brains are extremely good at hiding that gap from us. It’s hard and sometimes painful to look into the void, especially if the sides are feet apart rather than inches. What happens when we make the espoused part explicit and fixed? We don’t close the gap, we disconnect the two. It’s almost like saying: “Look, we’re done with our values, here they are, move on”
If you still think it’s a good idea to list your values, here is a real example, snapped somewhere ‘in passing’. A list of corporate values…
Over to you Catila, so what’s wrong with these values?
A company decides to follow the current trend and finally adopt this whole “agile” thing. They’ve been using the adjective for some time now in their job offers and eventually got some people who have done it before. The scrum framework is chosen, as the most popular, and instantaneously the project managers become CSMs, work is chopped up into fortnightly iterations, user stories are written, demos are given, … the whole lot.
Weeks and months go by, senior managers review progress and they are pleased.
- User stories: we are finally able to lock the requirements down into the finest detail. Win.
- Daily stand-up: never was there so much opportunity for regular micro-management. Win.
- Demos: now also the more senior people get to play the micro-management game. Win.
- Retrospectives: we did the best job we could, pat on the back, morale boost. Win.
- Sprint planning: at last we know exactly how long it will take and we know whom to hold accountable. Win.
- Scrum board: there is a new system, now we can track everything, Every. Single. Smallest. Bug. Win.
Eventually the “agile” adoption creates an environment precisely like the one manifesto signatories were working so hard to avoid.
I’m sure it doesn’t happen.
I’m sure it shouldn’t happen.
Or should it?
release cow courtesy of Rachel Davies
When software development teams start with the practice of Continuous Integration (CI) coordinating check-ins and keeping the build clean can be a challenge. Some habits like making sure all unit tests pass locally, project builds correctly, and all relevant files are included, are not yet established. Introducing a simple build token is often helpful. This is how Rachel and Liz describe it in their “Agile Coaching” book:
For this [CI] to work, developers need to avoid treading on one another’s toes by attempting to integrate changes at the same time. Lots of teams use a build token, which can be any object that makes it obvious to the rest of the team that there’s an integration in progress. Teams have a bit of fun with this, which helps establish the CI process as a team ritual. We’ve seen teams use a rubber chicken, a moo cow, funny hats, and even a “Sword of Integration” made from index cards.
by energizer (Energized Work)
Mature and experienced teams usually no longer need to use a token yet they often choose to keep it or adopt its use. At Energized Work, for example, we use a broken build token. If a pair breaks the build, they pick from a selection of fancy hats to let the team know who is currently working to fix the problem. It is important as a broken build can impede others’ progress. (It is also in line with the stop the line Lean approach.)
Using a build token, however, can also have some unintended consequences if dysfunctions obscure its intention.
The token only works if it is visible to the whole team. If the team is distribution across the office there are probably other priorities that need attention other than synchronising the use of source-code repository. For distributed teams on-line tools may be helpful but co-location is usually better.
Remember the (now ancient, I guess) token ring network topology? The build token should be able to travel around the team like a token in the token ring network. No one should permanently claim its ownership. This can be particularly problematic if the owner happens to be the most senior developer or a manager trying to control the token. Rather than helping to establish a common ritual and improve collaboration it becomes yet another whip for the team. With process becoming formalised and controlled, people begin to avoid it. The most likely outcome – integration frequency drops and one of the main benefits of CI is undermined. There is also the negative effects on morale when people feel treated like children who must ask mum every time they want to watch TV.
A build token is a tool to help with a concrete problem. Just because it worked for one team (in a specific set of circumstances and at a given time) does not mean it will be useful for everyone. Making it a company-wide policy is another case when it may backfire. Some teams will be more experienced and will have established robust communication paths, they don’t necessarily need a token (it can slow them down). Others will only share a code repository without a build server, they don’t need it (yet). Above all, however, it is a tool for the team and it is the team who should reach a consensus on using the tool if it is to work to their benefit. Even, if a practice is generally helpful but have been forced upon you, there will simply be no desire to tap into its full potential.
This is probably a minor problem and only relevant for immature teams. Yet if you notice someone in the team is less keen on holding on to the token they may be embarrassed by it. While intended to be funny or cute the choice of the token must meet everyone’s approval.
Token of shame
For the practice similar to that of the failed build token there is another aspect to consider. If the level of trust is not high enough, especially for new people who join the team after it has been formed and bonded, holding a token that clearly indicates who broke the build can be discomforting. It might be fine generally but sometimes there is a fine line and crossing it will put people off. A practice of pair programming helps greatly in those circumstances as there is always someone else in the same situation.
Have fun with your build token and use it wisely.
Three months ago we got a small gadget from our energy provider – a smart meter. I didn’t think of it much, but we’ve got it up and running and located it on the kitchen worktop right on top of the coffee maker. The coffee maker is broken anyway but it serves as a good stand and makes the new toy difficult to miss when going around the kitchen business.
The meter itself is fairly simple, it shows the current energy consumption. It also lets you set a daily target for energy use. It then displays how you’re doing against your target today, how you’ve done yesterday and over the last week. Since now the information was there and available to us, we started looking. To my surprise the single most demanding consumer in the house turned out to be the kitchen lighting. Upon reflection, twelve 50W halogen lights turned on for at least a few hours every day do need a lot of energy.
Now that the kW were flashing right in front of us we had a good incentive to change our habits and it proved very simple too. Just turn the light off when you leave the kitchen – a glance on the meter and you know why. Within a month we started saving energy. With the first wave of improvements were able to look further and decided to replace halogen bulbs with LED equivalents.
Today, only three months later, we are using 40% less energy and this improvement was neither costly nor difficult and we can still do better, all thanks to a simple feedback mechanism from a useful gadget.
The same principle applies to software development and works very well. Using information radiators, big prominent boards with relevant data, is invaluable in driving improvement efforts. It is also possibly the easiest way to initiate a change and is why Kanban proves so popular recently.
So make the invisible – visible.