Pragmatic Agile Weblog

Agile software development in real life

Shouldn’t engineers just be engineers?

During release planning we do two things: estimate user stories and write and refine user stories…

One of the question I asked myself when I knew for the first time about USs and how an agile team works with the product owner to get and refine user stories was… developers are developers, they are trained and paid to find and implement solutions. Why should we ask them to be a bit of business analyst too and define the user stories?

The other day, one of my best engineer came with the same doubt. Do not get me wrong, it was not a critique or a way to quit what we were doing, but a perfectly legal doubt in the back of his mind.

The answer I gave myself at first was that not necessarily developers will have to write user stories. In a perfect scrum world, the product owner(s) has(have) the bandwidth to fully write and refine the user stories. Engineers should just focus on making sure they discuss the stories with the product owner(s) so that they understand them fully and then estimate and implement the stories. In many real cases, where the customer is not an internal product manager, this can be much more difficult, because as anyone, the customer will have many other priorities than writing stories. But in this case, an agile team can just incorporate a business analyst that proxies the customer and acts as the product owner toward the development team.

There are however some good reasons (i.e. reasons I consider good) to have engineers more involved in writing the stories. First, if the project is of any not trivial size, the number of user stories grows easily big, so big that you would need to add many business analysts or product owners (in addition to big walls on to which stick the cards 🙂 ). In such case, you probably go back to involve the development team in helping out. The other reason, which is the most important, is that writing the user stories engineers are forced to see things with the eyes of the users, more than with the eyes of a technician. To make fun of ourselfs we coined the following acronym: MFMU… Maximu Flexibility Minimum Usability. It was because as engineers, we tend to thinks about how a feature should be done and how the code can be changed easily. This usually despite the usability of the final solution (users will do what we tell them to do…). This is particularly unpleasant in software product development, because when you develop a software product, you can achieve the best result when developers think like users. This fits well with the agile principle of releasing workable software. Most users can live with few features but working, much less with the promise that they will have one day a perfect feature set (which we know already will take a couple of releases to get stable 🙂 ).

Writing user stories helps engineers to switch for a moment from the how to the what and this brings the benefit of understanding much better the requirements, the why things should be done in a certain way, what is really important for the user and what less, what the user will do to accept a story and so on.

This is why I am more than happy we need to help our POs in writing and refining the USs. We are not super good yet, but we will get there!

Some additional comments. Interestingly, another engineer came few days after the first with almost the same argument. Easily the discussion slipped to asking ourself if the focus of a software engineer should not be more on producing quality code than writing user stories. Or, in a way, if we should not focus on making sure we can change our code easily before trying to develop with an iterative (possibly incrementally) development process.

First of all let me say that of course it is fundamental that developers write quality code. This is a good part of a developer professionality and it must be  a field of constant improvement. Still, I like my developers put their hands in the user stories because I believe it is equally important they streer their ability to write code toward the final and ultimate goal of software development, which is delivering value for the users. As a manager I am in the middle between the development team and the product team and in many cases I feel the two teams think about value of software development in two very different ways. Developers tend to see value in writing good quality code, the product owner tends to see the value in features delivered to the user. Scrum gives the great opportunity to get these two views closer and see a common goal: deliver value to the user in the most efficient way. As this sentence shows, there is a sequence that makes sense: first deliver value to the user, then constantly improve your efficiency.


February 22, 2009 - Posted by | Agile, SCRUM, Software development, Software engineering, Uncategorized

No comments yet.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: