I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Thinking in value terms

01.14.2013
| 1958 views |
  • submit to reddit

From technical tasks to user stories, the change is not easy. Here is an experience on how to break down the transition in steps into different models, from waterfall to Agile. Don't stop at the 2nd step.

1st model: Waterfall

The old but ever present waterfall model features a functional separation of the activities made on a project. By "functional" I mean the opposite of the cross-functional term: the team members are strictly organized by departments, so a project passes from the development department (full of programmers) to the QA department (full of testers) to the operations department (full of sysadmins).

This separation is carried out in multiple senses:

  • the team separation described above: you hire developers or testers, but not a person capable of performing in the two roles as he would be wasted.
  • Maybe due to Conway's law, the logical separation of tasks: testing and development cannot be interconnected in this model as they are forced to be separated by the shape of the organization.
  • Temporal separation: first development is finished, then testing starts.

The Waterfall model has many problems, and they cannot all be listed here; for example, it's full of waste in the muda sense, due to the handoffs and rework necessary when code is sent back and forth between development and QA. It also creates some antagonist dynamics, which plainly speaking means departments hate each other: development is wary of testing adversarial attitude and of how much time the sysadmins take to put a new line into production, while the sysadmins hate the developers for trying to break they're running application with each new release.

2nd model: cross-functional, task-based

The assumption of cross-functional teams introduced by Scrum and other Agile processes is that communication between the different roles of the project is more intense and important that communication between different projects. So instead of cutting the work to be done in functions (A develops, B tests), it's cut into projects (A develops and tests project 1, B develops and tests project 2). Sorry for using just development and testing as an example: there are many more roles such as analysis, UX, operations.

When you create a cross-functional team, you place all kinds of people in the same room (less than 10 usually, in the magic 7+-2 range), and hand them a description of a feature so that it comes out at the other end on the product. At least the feature comes out already tests and approved by the customer, and maybe even live deployed the the real production server if you include members from operations (DevOps, yay!).

However, just reorganizing people isn't usually going to provide a net gain. For example, you may see the work provided for this team divided in these tasks:

  1. developing the new green widget
  2. writing automated tests for the green widget
  3. integration of the green widget

Cutting work temporally, handing offs different phases to different people inside the team wasting time in learning, incentive only to finish each phase instead of on the value provided (which is feature out of the door and picked up by real users. I don't write money instead of value because value is more general)

3rd model: cross-functional, story-based

So with the task-based model we're still cutting the work "horizontally": read this as the "height" of the small waterfall, or as the division of an application into UI, database, business, integration layers, and even an automated testing layer that is only run outside of production.

The XP/Scrum user story model is famous for cutting the work to be done into vertical unit instead, which loosely correspond to features. Actually, user stories are more akin to use cases for the system, and many of them compose a single feature. This is nothing new, but is striking in the contest of teams accustomed to working in our 2nd model (I'm currently transitioning one).

However, while the 2nd model has only the assumption of getting different kinds of people in a room, to get the benefits of the 3rd you'll have to make some investments. And these investments have to take care that the assumptions of the model are satisfied (here in increasing difficulty):

  • people know the model. You have to explain how work is divided between them.
  • Developers have basic knowledge of the various stages: even with a tester on the team, they must be able and willing to write unit tests.
  • The definition of done (tested? Reviewed? Or released?), or "done done" as Jez Humble says , must be clear.
  • A board should be allocated to be an informative workspace tracking all stories.
  • There has to be an incentive to complete stories, so each person should be made responsible for getting a story out of all the stages (up until release where applicable).

You should try to stop backchanneling where people outside of the team put them to work without passing from the prioritization of stories; a Scrum Master following who doesn't want respect the model... :) and so on.

Conclusions

A very smart thing I've heard in the XP Italian community is that there is this diffuses opinion that Agile processes makes people work better. This is a myth: you need better developers to work in Agile processes, and impose them on fresh graduates or code monkeys isn't going to increase productivity. You have to invest on people, and training...

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)