Agilists always advocate for incrementally developing a thin slice of the application, in the form of a user story, that implements end-to-end changes that are required to deliver business value to the customer. This will normally entail changes to the UI, front-end logic, back-end components, databases, service interfaces, etc. This process results in the end user receiving value for every story delivered. The customer gets this value early, while developers have to manage only one small change at a time, and significantly reducing code integration overhead.
But what about efficiency?
Some will argue that working on different layers requires different skills, and that there is a waste incurred in task switching, e.g., switching from working on the UI to working on the back end. It can be demonstrated that working width-first, as in developing 10 UI components (A1, A2, A3, ...), , then 10 back end components (B1, B2, B3, ...), etc., will require less time than working depth-first (A1, B1, ...), then (A2, B2, ...).
But then, who's right?
In fact, both are. It is indeed more efficient to work on the same task type, since there is less task switching, and there are mass production techniques that could be employed. However, the customer gets value much later, process feedback is delayed, and there are more integration work and problems that are only discovered late in the process.
It so happens that in software development, the Agile method is far more superior. The benefits of an Agile process increase in line with the rate of change in the process.
But what about efficiency?
To the non-agilists, it should be noted that efficiency isn't the point. Thinking mainly about efficiency distracts from the goal of delivering more value to the customer, at a faster pace. To concentrate on efficiently producing UI components, for example, increases waste by delivering more than the customer needs, by increasing the rework required to adapt to changing/better understood customer needs, by delaying feedback, and by increasing work in progress. This is a form of local optimization that negatively impacts the overall goal.
But also, to the agilists, the efficiency argument should be understood. There will be opportunities during development to queue up similar tasks, and leverage specialized skills, and mass production techniques, to gain immediate task efficiency.
The idea, then, is to never let efficiency distract you from your gaol, and to only pursue it if it doesn't increase work-in-process, and doesn't delay feedback or customer value.
Wednesday, September 9, 2009
Subscribe to:
Post Comments (Atom)
2 comments:
You have a point here. But there are different ways you can mitigate the efficiency and specialist’s dilemma.
If you think about it in a sequential way (layer approach for example), you will have the dilemma. But instead you should consider that your development is happening concurrently. This is the Agile way! Similarly to BAs, Dev, and QAs working concurrently, you should have the “specialists” working concurrently. This should take care of the efficiency and specialist’s dilemma.
Ideally, you'd have poly-skill people capable of working on multiple layers.
But, even if you have specialized talent, the idea is to deliver (A1, B1, C1) first, then work on delivering (A2, B2, C2). If efficiency is the goal, you might be tempted to optimized every talent's queue by queuing up (A1, A2, A3, ...), for example, thus falling in the efficiency trap.
So, everyone could be working concurrently, but not independently. And the target is delivering complete stories, not consuming a work queue.
Post a Comment