Udostępnij za pośrednictwem

Trait of an agile environment: planning-oriented developers

  • Artykuł

When agile development still was not called agile development, there were planning-oriented technicians —professional software design practitioners, that is— in a development project team all the way from the very beginning of the project to the actual retirement or replacement of the system.

A popular style for the division of labor in a development project groups tasks by category and assigns task categories to roles, e.g., all the planning tasks go to management roles which —in the very best cases— have actual development experience (arguably, this experience in most cases is by now obsolete and its relevance has expired); all the development technical tasks to development technicians, all the testing tasks to testing technicians, and so on and so forth. There could be projects where doing so could actually be a wise thing; in my experience, I have found none of those (but that is just me).

Another style for division of labor is in fact a division of scope where the basic unit of scope is a short-time-boxed, implementable, end-to-end usage flow (also known as use case instance, user’s story, scenario, user-valuable feature, etc.) then these scope units are grouped and selected for delivery as releasable, production-graded, functionally accumulative clusters known as sequential versions; the selection criteria is contextual, e.g., business priority, technical risk, etc.; the development progress of each unit of scope in time follows the growth of a feature, this is essential iterative and incremental development where planning, architecture, testing, detailed design (also known as coding) are activities —not stages— occurring all the time and performed on-demand by the team of professional software design practitioners themselves. Who does what? There is a litmus test for knowing if this approach is going to work with a particular team: if an external leader has to come and tells them the answer to the previous question then this is not the way to work for that team; if the team —on the other hand— knows their craft, knows each other, and are eager to take complete control of their own work and project fate, then you know they are going to succeed with this work style.

This kind of project team is made of schedule-oriented professionals who carry out the very act of planning continuously as new information is confirmed about the actual course of the project. There are —of course— other considerations for the team structure based on their broad objective, e.g., problem resolution, breakthrough invention or tactical execution where trust, autonomy or clarity respectively could be a dominant trait.

One of the most curious things about this work style is that it is not new, outstanding software professionals have worked this way since long ago and many have documented the conceptualization of what they do, e.g., the macro-process and micro-process in the Booch Method for object-oriented development.

Comments