Self-managed teams

    Recently, project manager in our team has been changed. My new boss is quite diligent in applying strict software development process. It's wanted and needed indeed: it's a really good thing when you know that some certain functionality will be delivered before certain date. At least management can sleep well in this case. But what chance of the dreams to become true in the team that steadily delivers many unexpected things, both good and bad. In complex projects work of developers are pretty much research work: everything brings piece of chaos to the complex system.     So all costs should be put under consideration not only in aspects of men-hours, but also in some very human-based and subjective opinion about increasing entropy. To be simple: each time you add new functionality you should think about chaos you make to your application. I will probably talk more about this effect later. So if we know that men-hours are not scalable (special thanks to Frederick P. Brooks), entropy increment is something even unmeasurable. In environment when nobody knows system, each development task means investigation, design, coding, testing, testing and testing ...
    Ideal developer for this is good motivated specialist that can "keep himself busy": he commits whole cycle from task specification to integration and he does not disdain to use any technologies due to solve any tasks. Although division of labour market still has people like that:

    I don't know exact reason for that. Probably IT are still very attractive not for just welfare, but also for self development.
    Such developer can be not so keen in each of his things he does, but he is much better for developing some kind of software than team from several people engaged in separated things:

• he consumes less management resource than team of specialists of many sorts. It is really cool - the management resource is is inclement deficit.


• he tends to self development and quickly embraces knowledge of applied system


• he and people like that provides good base to create self-managed teams

    If you have more than 40% percent of people like that in your team, team becomes more or less self-managed: they able to distribute tasks themself, coach people who are not skilled enough. Broad specialists can also maintain whole development cycle protecting software from ambitions of others.
    There are also some disadvantages:

• There are might be lack of people that likes formal management (with burndown charts, timelogin, issue tracking, road mapping and so on)


• They like too engage themselfs with tasks they want. Remember that common developer designs only that things that he can and wants to create


• They start fighting windmills when face challenging problems

    This means that team still need force that leads the development. This not always can be done by customer or head of developer. Customer and head masters can be so distant from development team that team doesn't feel leadership from that side. As it was recently discovered manage IT people is similar to herding cats (Last year I'd got this amazing book).
    Usually good developer asks somebody if he needs extra information about what to do and also he asks if he needs to make decision how to do. Many developers that are still with strong technical background doesn't like others to asks. So on one hand we need two roles:


    1. Somebody who knows what to do and prevent to do things developers supposed to not do.

    2. Somebody who knows how to do and prevent to do things in incorrect way.


    So on the following scheme I establish two more roles - architect and analyst:

    Analyst is pretty close to the meaning of analyst in all other models of development cycle. But destinctive features of architect that he is not just IT specialist that creates architecture or (even worse) designs software, but man who can reply on question how to make software. This not obligotary means that he should no everything, in fact this would be insecure for enterprise, and doesn't mean that he should create development document accordingly to standards himself, but he gains role of the knowledge base moderator. His artifacts is every document that helps to define how development team suppose to resolve their tasks, including guidelines, solutions, designs of crucial units in system, description of used technologies, that are not necessarily created by him, but in the good environment carefully selected by him from sketches created by team, external sources and self experience.
    Architect doesn't response for design anymore: it should be responsibility of people that creates software (the team). But he should be very responsive on questions that helps team to make decision. And the most important thing is that architecture not more process that bound to specific time or stage in project: architecture as development document should be steadily updated as new experience is incomming to the people that make software. This is very distinctive, because this means that we are not able to say "Oh, men! Congratulation - you have successfully passed the architecture stage, let's come for planning!". Because there is no more stage of architecture, it's continuous activity.
    What impact has aforementioned approach on analyst?
    Quite similar to one that has on architect: in complex project we can expect surprises of inconsistency of requirements or infeasibility of them analyst at any time within period of development. So architect is one who not only creates documents, but also use them to explain others what things are expected from software. Like architecture, requirement analysis is not more determined stage, but more or less continuous process. Analyst comparatively with architect should have probably longer gap between his start and start of the development itself, but boundaries between pure requirement analysis and support requirements are anyway obfuscated ...