So we’ve started delving a little deeper into Agile Development today at TWU. Today we discussed the balance of quality and timebound delivery, as well as iterative software development and adaptive planning. Below I’d like to discuss an issue that is near and dear to my heart, an issue that really worries me about Agile methods, or really any kind of development that advocates the writing of code at an early stage.
In an Agile project, it is likely that a development team begins to write computer code nearly immediately when starting a project, or at least that’s my perception. By immediately, I mean to say that code is created within the first week of the project, if not the first or second day. Meanwhile, a team of Analysts goes and studies the work processes to help the customer figure out exactly what kind of software will be needed. I’m going to assume that at an early stage of a project, the development team makes some assumptions about what will be needed, and commits some ideas to code before they are sure that it will be needed.
This, for me, is where the problem begins. Whenever computer code is created for its own sake, or without proper research, there is potential for the developer to become married to their code. Here’s a scenario:
The team comes to a work site and meets with the client, who has asked that an internal system be created that helps employees communicate with each other, despite the fact that they are distributed around the world. One of the developers immediately thinks of a *great* feature: real-time chat. In the next few hours, he creates a web-based chat tool that can easily be plugged in to a system. He is really excited. This is something he has wanted to try to do for a long time, and finally has had the opportunity to do.
Meanwhile, one of the analysts has been chatting with some of the employees and realizes that all of the collocated employees in each office have no problem keeping in contact with each other simply through face to face communication. The problem, however, is that employees who work in different locations also work in different time zones, and are rarely ever working at the same time. Logically, this means that real-time chat is not a feature that will improve the communication system.
Now we have a real problem. Our developer has fallen in love with an idea, has created it, and will likely be reluctant to let it go. The analyst has evidence that the feature is not needed, and requests that the tool be removed. Now what? Is it an interpersonal problem? Will the developer take this personally? What about his precious time that was spent creating the tool?
Since the feature was created before the development and analysis teams really understood the nature of the design question at hand, it ran the risk of being unneeded. In this case, the tool turned out to be unneeded. The developer may take this event as a war story about “that time the analyst stole the glory and made him remove the best feature.”
But what about the users? The users don’t need it…so why code it? This is just one of the things that bugs me about Agile…code is created so early. Maybe I’m exaggerating the story a bit, but still, nobody likes to throw out work, right?
Maybe some of you agile experts out there can shine some light on the subject and help your soon-to-be peer clear some things up… 🙂
15 responses to “My Agile Worry, Part 1: Marrying Code”
I don’t think you have much of a realistic scenario here. Firstly agile teams have iteration plan which is as you know the set of stories that are prioritized. I aggree that finding stories to first iteration might be hard since the collaboration between customer and the team is not in place. And this is why there is “Iteration 0” which you set continuos integration, some basic technical infrastructure etc.
If the team needs to implement a business strody in the first iteration , the prioritization should be correct so that the stories that are selected have high probability to make their way into production.
Hope this helps
Murat Uysal
A few counterpoints from my perspective:
I would argue that there’s just as much danger of designers getting married to early design sketches they come up with.
If you’re doing faster iterations in your design process, I don’t think it takes very long before you realize that it’s not really all that big of a deal to toss aside what you’ve been working on if new information comes along that would indicate you need something different.
Another aspect of shortened development cycles is that (if short enough), there’s barely enough time with an idea for a brief courtship, let alone marriage.
Also, even though you may seem like you’re “throwing away” code, you may wind up using that same code later for another project, just like you might reuse a design concept that you come up with that seems like a good idea but just doesn’t work well for what you’re doing.
Further, if everyone is working in short cycles, then it would seem like they all need to be working on something. Hence, what are the coders to do other than code while the analysts research the problem?
And finally, on the note of taking things personally, you mention “What about [the developer’s] precious time that was spent creating the tool?” In most situations, the “precious time” isn’t so much the developer’s as the employer’s (i.e.: the whole “giving people money in exchange for time spent working” thing).
In XP at least, this is dealt with through pair programming. In addition, XP and Agile both state not that there should be no design or analysis, but more that it should not be all done up front. At least that what some Agile experts have either told me or posted on other websites.
One of the ideas behind pair programming, as I understand it, is to break the code ownership that results from a single developer working on a piece of code alone. If two people work on it, and then a different two people work the code, then that code is shared by the entire group. In addition, the code that is worked on tends to be driven by the user stories and not by one developer’s solitary idea.
At least this is how I understand the ideas.
That doesn’t quite sound right to me. What ought to happen in an agile project is that the team – including developers, not just BAs – starts by speaking to the customer/users, to begin understanding what they want. This will probably involve capturing the first user stories, as well as maybe doing some paper/whiteboard prototyping of the first parts of the application.
Once the first (ie highest priority) stories have been agreed, the team begins implementing them, while continuing to discuss them with the customer. They shouldn’t be rushing off to develop random features that no-one’s asked for.
To me, creating features that no-one really wants is a problem with non-agile development, not the other way round.
I think you’ll find that’s an incorrect assumption 🙂 However it does appear to be one of the common myths.
All the agile methodologies try very, very hard not to make assumptions of this kind by breaking down the project into thin vertical slices of functionality with the customer – trying to give them the minimum they need to get useful functionality out.
The scenario you describe is what can happen when code is written in the absence of a business requirement (usually expressed as a user-story). Agile/lean development is about building a system that fulfills a business need. If a developer has gone off and implemented some functionality in the absence of an identified business need for it, they’ve departed from the process (and the point) of agile. While an agile process does start delivering features sooner, those features are still driven by analysis, planning and design.
No feature written that doesn’t have a User Story and the associated tests. Otherwise known as You Aint Gonna Need It (YAGNI). This is really more of a an XP than a universal Agile thing but it’s close enough.
To sum up, someone has to ask for the feature before you build it.
Now this doesn’t mean that you can’t build a quick prototype to demonstrate a potential feature. A recent example is just showing people what script.aculo.us makes possible. However, developers don’t prioritise features.
I do find that a sense of detachment is useful though. Creating useful things tends to be more about removing things than adding things.
Hey Josh,
Good point and a valid concern. However, in my experience the scenario that you have described has never happened. I think that there are many reasons for this, but I’ll highlight just a few.
1) In most cases, a high level story list will already have been created, so the developers will have a general idea about what is needed and what is not. This is also a time where you need to trust your BAs, they have a pretty good idea of what the business wants and needs. By all means ask questions about the specifics of the implementation do they need real time chat or will email do? But if there is a requirement for communciation of some sort your efforts are not going to be wasted.
2 & 3) This scenario is where the other Agile practices come in to play. Having collective code ownership means that no one developer is going to own a piece of code so it’s not going to be such a wrench to lose it. Having an iterative approach to development means that if the customer changes their mind, or a new requirement is discovered, the amount of work you are going to lose will be one, perhaps two weeks, but at least the customer has been able to tailor the solution to their needs.
Now is the time that I make the mandatory reference to Kent Beck’s Extreme Programming and set you a challenge – have a look through and see where any of the other practices help to mitigate the problem you have described.
Cheers,
Tom
Firstly, welcome to ThoughtWorks!
Secondly, I fear any situation where developer start writing code before the customer figures out what they want. In my opinion, the role of a BA is to help explore this situation with the customer, and co-ordinate the generation of stories.
There shouldn’t be a situation (like the one you describe) where developers just feel what’s write and offer up solutions. In a ‘classic’ XP team where the number of people is small, it’s possible to have everybody sit down with the customer and a white board and sketch out and talk through ideas. During which the devs (at least in my experience) question the customer about what they want – the rule of the 5 whys. Attempting to understand the _actual_ problem at hand, rather than what the customer says they want. They can be subtly different.
As you say, nobody likes to throw out work, but in my experience by having these discussions earlier with _everyone_ people are less likely to make bad assumptions and spot opportunities to deliver value sooner.
At the risk of sounding repetitive, there shouldn’t be a situation where a developer just sits down and starts coding without attempting to deliver some business value – the story. The more often (and quicker) you get feedback, the more likely you’ll be to not spend time writing something that isn’t needed.
A new friend of a friend I will be meeting for the first time in Copenhagen on Sunday is big into Agile. I’m going to to try to have him reconcile this dilemma you describe.
The development model I like best is Rational Unified Process, for a couple reasons. First, one of the primary goals is stability. Every iteration in a development cycle should end up with something very stable to minimize errors and force advance planning. I have found through my own project work since coming to the school that this tends to leave a programmer with the perception things are slow, at least in the beginning, because you can’t show as many beeps and whistles to a client (or boss) as you work on all of the hidden things that go into creating a stable platform.
The second thing I really like about it is its flexibility. It can become a very high ceremony development framework, with lots of documents and sketches, or it can easily adapt to smaller projects by asking only for the documents that support that project. A lot of corporate development seems to put the ceremony ahead of the process, or confuses it outright with process.
Agile seems to be the same kind of framework, except that – as you point out – there is an emphasis on completing small features that may not even be required. I would think the positive spin on that is the experience the programmer gains from the process of doing so much building. But it is a prerequisite for the programmers to view these mini sessions as the equivalent of a designer’s concepts – disposable and part of the process
You raise 2 points: the first, that code might be written before the requirements for it are understood, should not be an issue an agile project. The first step should be to understand the problem – stories can then be written, estimated, prioritised and developed. Ideally, developers would not be placed onto the project unless they had stories to implement (unless they are there to do exploratory work, prototypes etc).
The second point, that developers can get attached to the code they write, is mitigated by promiscuous pairing (changing partners every day) and collective code ownership. It is not my code, it is our code. Furthermore, requirements can change overnight, and features get cut or added regularly, so get used to it 🙂
Jim
Developers practising agile ala XP don’t do any development without stories, which come from the client. If developers are assigned to a project when the project begins they will set up environments (i.e. CI box) for the first week while the analysts create stories with the client. Or, almost as often, the analysts will work with the client before the developers are even assigned to the project.
In agile especially, no code is written that the customer didn’t ask for.
I suggest doing a bit more research before criticising a methodology that your company advocates.
I think the bottom line for me is that I do not marry my code. This is not to say I don’t take great pride in the code I produce. But just as with people in an organization, nothing is irreplaceable or beyond improvement.
Myself and my code included.
[…] About « My Agile Worry, Part 1: Marrying Code […]
[…] As noted in my first agile worry, I am often scared that features of a given piece of software will be built based on reasons other than user needs. Yesterday I learned that story cards are, indeed, quite user centered. […]