Good management, Bad management.

What to do.

The current situation.
This application software redevelopment area is divided into two halves. An accounting system and a 'document' processing system that handles incoming (claims etc) and outgoing (payment, notices etc) messages. Each of these is then divided into two halves. One group of teams converting 'service designs' (from a business area) into 'technical designs' of pseudo code. The second group of teams 'builds' the 'technical design' into modifications to a Commercial of the Shelf (COTS) product. The code is passed on to be compiled and tested.

The division between the analyst and programmer is said to be 'Chinese wall' that ensures quality.

In my book both are part of the software design process. Testing of function is the true validation of the design decisions (that both the analysts and programmers make).

The analysts browse the code base and database/massage/file schemas (no access to any usable dev or testing data) and are expected for get the 'technical designs' right first time. The programmers then code and unit test using some unit tests drawn up be the analyst.

This is madness, it breaks the short term (sub daily) feedback loop of an analyst/programmer doing coding and unit tests, and then feeding unexpected corner cases back into the code/unit test rig. It creates a paper/email feed back loop of days. Often the analyst is requested to modify a 'technical design' that he/she have not worked on for days or weeks.

I know one of the analysts. He told a few people there, that he thinks that the analyst and programmer roles should be merged. That the time resources freed up by the improved/shorter communications should be devoted to testing, particularly automated testing.

Now

Well where has been some movement. They are going to pilot a new team structure. The four person team, 2 analysts and 2 programmers, co-located even! One of the analysts will be the team leader too. Good management!

My friend is the second analyst. The team was setup on a Monday. The second analyst and two programmers found out about the new pilot team and their pending move to it, at about 11 am on the previous Friday. They were CCed in on the 'make it so' email.

My friend thinks it's a good idea, that it’s movement in the right direction at least. But he is mifted that he found out about it as a fata compli. Bad management!

Future

My friend thinks that they may want to keep the 'Chinese walls' in place. He wants to grow some 'grape vines' over it. He wants to learn the programmers tool set. He wants to get the programmers updating the 'technical designs' for more than just spelling mistakes.

Any extra ideas on how to improve this pilot team would be welcomed.


Gnoll110

Technorati tags:
agile+software lean+software analyst programmer software+management