Creating an extra high productivity & extra high quality SW development team


We have actually known for a long time much of the concepts and theory of good software development. The journey of 50 year of computing has gradually led us into the point where we understand.

The result of this is model driven process that ends up to a 3-tier application implementation. The layers are: Application layer, Domain layer and Persistence layer. The key element in this approach is the unidirectional association between the application and the domain layer. Here the application layer is strongly associated with domain layer but the domain layer has no references out of it at all! The development process should start with abstract domain modeling. This phase won’t take more than 10 working days in average of a team to build. The development starts from just implementing this model. Then it continues incrementally with design and implementation of the application GUI and workflows. As the work proceeds the details are also added to domain layer that started with skeleton model. The experience from several projects is that the number of classes increases very little but addition of attributes and behavior is of course substantial.

Great opportunity for a top high quality & high productivity team

Currently most of the development of operational software for companies is done based on very old and proven bad paradigms. In practice majority of development is done with a waterfall approach. This is bound from different directions like, wrong idea of the nature of the work, planning and working tradition, buying, selling and agreement traditions. This all lead to situation were a carefully selected team of skilful professionals would have an outstanding advantage in competing on the arena.

The structure and the working process have been proposed and even used many time in the past. I will assembly here ideas from Frederick Brooks: Mythical Man-Mont, Grady Booch: Object Solution, Ken Schwaber & Mike Beedle:  Agile Software Development with Scrum and Kent Beck: XP.

The good principles and best practices for such team could be added up as follows:

  • Small team with member each high professional skills
  • A Scrum-like working team yet somewhat different duties and responsibilities between team members. One could call it “surgical team” like Brooks did. In software the “surgeon” would be call chief programmer & architect.
  • There could be two teams. One for domain & total architecture and another for GUI & work flow control details. The interests of these teams are clearly more loosely connect than inside these teams.
  • The working process should start with clearly separated time boxed abstract domain modeling. Then the implementation process should start with generating the implementing code from this abstract model as starting point and guide lines for the incremental and iterative development work.
  • Professional skills tend to be badly underestimated. Somehow in IT-field the dominating assumption has been (as perhaps is still) that most of software development is routine work, which one can do with short introduction to work. The truth is complete opposite of this! The software implementation is difficult design work from modeling until the last line of coding. It is mostly problem solving and successful people have both good skill and enough routine work behind them to be good at it.The ideal small team could consist of following roles:
    • Chief domain developer. This fellow is the “surgeon”. He has the main responsibility of the overall success.
    • Domain co-developers (1 – 3). These as the assistants of the chief developer. The domain developers discuss and make the key design decision together. One of these is the deputy chief developer.
    • Application developer who designs and implements the work flow control
    • GUI designer
    • Case dependent additional roles
  • The team is really functional after a few ramp-up projects as each member learns to fit and function in this particularly team. To replays any team member requires a fully professional candidate and a learning period with assistance of the leaving member or the rest of the team.
  • One open question (that I cannot provide an answer now) is whether such teams should practice their performance  in advance outside any customer projects.

Really good customer is a must

All this things doesn’t work without the final link in the chain. This is the buyer, the one that the whole thing is done for and the one that should be the most interested in the result.

Participating in such a process require real interest and committing to the process. This means that the organization appoints the most knowledgeable key people in the project and at least some of those fulltime and that the management of the company is actively participating in the process.

In an agile development process very important decisions must be made all along the process. Actually the development of an operation management system is always at the same time a huge opportunity and a steep learning process for the whole organization.

Choosing the customer (at least at early state of working this way) is actually more crucial than creating the best possible team.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: