Comments on: Division of Labor in Lean Software Development Workflows

By: Not all activities are best handled by generalists | Lean Software Engineering

Tue, 19 Feb 2008 22:51:55 +0000

[...] When we can get the benefits of both generalization and specialization. We do this by hiring generalists, but having them rotate into specialized roles (like test, project management, architecture, etc.) for the duration of a project or two. This is an excellent strategy to gain the benefits of focus through specialization, while retaining a flexible, low-overhead organization. TSP is a well-known adopter of this strategy. This is also a variation of the recommendation here of division of labor in lean software development workflows. [...]

By: Brad Appleton ACME Blog

Brad Appleton ACME Blog — Wed, 13 Feb 2008 10:21:45 +0000

Katch the KanBan Kraze!…

For those who haven't been keeping up with "Agile 2.0" or "Post-Agile", one of…

By: Corey Ladas

Corey Ladas — Wed, 13 Feb 2008 08:41:23 +0000

I certainly agree that it is a good idea to cross-train and develop generalist skills. However, just because you have a broad set of skills, doesn’t mean you should always use all of them. Or, perhaps a good way to think of that is that training in a skill improves your ability to consume the product of that skill as well as produce it. That is especially important in a pull system. Also, it’s important to recognize that the division of labor I gave in the examples is situational. If there were other people on the team with different aptitudes, you might end up with different task assignments. Teams don’t last forever either, so if you’re the designated tester on one team, you might end up as a coder on the next one.

To that end, a brand new team might start in more of a generalist mode until you learn your comparative strengths and begin to develop cooperative strategies. I’ll have more to say about that in the near future.

By: Steve Campbell

Steve Campbell — Wed, 13 Feb 2008 04:19:23 +0000

Of course, there are other unspoken benefits to the team of generalists (morale, spreading of technical knowledge, avoiding development silos).

Still, I’m mostly convinced.

By: Synesthesia » Links roundup for 2008-02-11

Synesthesia » Links roundup for 2008-02-11 — Tue, 12 Feb 2008 00:36:38 +0000

[...] Division of Labor in Lean Software Development WorkflowsCorey Ladas prods the assumption about all members of a team needing to be generalists… agile lean development [...]

By: Corey Ladas

Corey Ladas — Mon, 11 Feb 2008 19:00:58 +0000

It could be broad processes like design, development, test. It could also be more detailed than that. It depends on the size of the team, and the steps in the workflow. The states in the workflow represent known intermediate states of work in process, that you expect to see done in a certain order, with certain quality criteria.

Different software teams will have different detailed workflows, because the kind of software you produce is different. Game developers produce different artifacts than web application developers, or industrial control system developers. If you have some specialized workers on your team like interaction designers or database developers, then it makes sense to allocate space for them in the workflow, because they a may be scarce resource that will need regulation.

So, you could have a workflow state like “user interaction design”. You might have a UI designer available to the team as a resource. By focusing on the product, rather than the person, then somebody else can step in and produce a “user interaction design” if the UI designer isn’t available. Most of the time, you let the UI designer do it because she is better and faster. Most of the time, she wants to do it because that’s her role and she likes it.

Workflows will also differ according to what kind of process you use. XP has one kind of workflow, TSP has a different workflow. Maybe your workflow includes producing unit tests, maybe it doesn’t because you write formal specifications instead. Code review might appear in different places depending on process. Maybe you do security reviews for user-accessible features. There might be a few steps to deploying to a big server farm, or updating firmware on a consumer electronics production line.

also: http://leansoftwareengineering.....-examples/

By: Jiri Ludvik

Jiri Ludvik — Mon, 11 Feb 2008 17:47:47 +0000

“we don’t organize our workflow by role. We organize it by task or process, and let team members apply themselves to the workflow in the most efficient manner”

Corey, I think I get what you mean but a a practical example would be useful. What do you mean by tasks/process? Design, development, test? or something more specific? Thanks