Its been a while I blogged, probably i got lazy or too busy with other things after getting married :).
Lately I was involved in a project where the so called scum master/monkey advocated and promoted Agile practices to his bosses overseas probably to get apprised, but wouldn't practice it in his own team. Probably his lack of enthusiasm, insecurity or his ways to get on top of the corporate ladder by pushing others down. God only knows. It did annoy me and can see clearly the team was getting disintegrated and drowned in misery.
There was no tester involved, no business analyst to communicate or document requirements/backlog(we had to produce the backlog and code and test and release and communicate to business and take the risk of getting something wrong as we were doing multiple roles). Just another Dev ops dude Y and me figuring out how to deal with things - digging legacy code/building the new messaging pipeline/ reverse engineer the data model/ liaise with teams and what not. This was not scrum. Just adhoc. The scrum monkey would as well shamelessly admit being a Hippocratic. It was absolute shambles - me and Y (who could spend only some time on this project as he was pulled into another project by the so called scrum monkey). I did mention him several times to get another resource and a tester, but he would simply brush it away. And with his crooked ways would ask for the build result without being involved in the design or build process and would like to take the credit when the boss would make an occasional visit? Also on the other side there was a tech ops/support team trying to coax me into dealing with their stuff applying Social engineering skills/Behavioral science/Jingoism. Well one needs to learn moral science first and do their duty instead of troubling their colleague who is doing his job.
This was so unnatural and demotivating. Obviously good developers would run out of choice and move on at this stage, so am I. I can see others following. One dirty fish seems to spoil the pond.
So as usual i asked Google god (our digital god who answers our prayers with search results), Why?
1. Basically we were ending up doing Cowboy coding with the boss only interested in the results - doesn't matter how you do it. And he would pull the resource to do other tasks than the main goal. An undisciplined scrum master who doesn't care for his team but only the outcome by simply not pulling his weight.
Refer
http://www.agilebuddha.com/agile/agile-is-not-ad-hoc/
2. Happiness Metric is something a scrum team should always consider along with retrospectives followed by its implementation. After all a motivated healthy and happy team will always produce good result. This does seem like the natural way of doing things.
Refer
http://scrummethodology.com/happiness-metrics/
Digression
My miseries and rant apart. Let me think what was going wrong here.
Ongoing maintenance and build over legacy application is a challenging task especially with so many technologies involved built by several different minds over time. The tech ops team struggle to understand whats going inside when something breaks while the dev team struggle to build over legacy apps as there are no regression tests.
Both team need to co-exist to be an ideal Eco-system.
1. The tech stack builds up with many new technologies(Java and its loads of relatives, Mule, ESB, Oracle, Linux) and functionality while the older technologies(C, VB, websphere, messaging, Sybase, Solaris) and functionality haunt the developers. It is like renovating an old house, and the builders waste get expensive to be cleared and affects the new building blocks.
2. The old process and the new process need to match up. The bosses expect the migration to be done somehow.
3. The programming mindset - Stored procedural programming vs Object oriented programming mindset is hard to change IMHO. After years of PL/SQL programming ones brain gets hard wired to its style. As industry moves to OOP technologies like Java there needs a shift of ones thinking which has a hard learning curve involved.
4. As developers move out of team for grazing into greener pastures - there is a huge loss to the team. The new comers are left with no choice but to reverse engineer the code to understand the functionality as the docs might not exist or tend to get obsolete. Moreover the flat documentation can never be as complete as the relational application code. The code is the only source for latest functionality.
5. Working with the existing complex data model can get harder with time if no good process is followed.Also applications cross referencing database tables make them more tightly coupled
But there is no real process for that defined in Agile afaik for a moving target (for porting legacy apps along with ongoing maintenance ). From the bosses point of view Agile might mean getting things done fast with less resource so one can secure a bonus or promotion fast.
Hmmn thats how corporates work isn't it or am I being too pessimistic?
A similar pattern i could see in the past with another media company and could see stressed out developers and tech ops. Someone was not pulling his weight or there was no one to see the big picture and steer/guide the team(perhaps an Architects role) or was there a lack of process for this moving target?
More later...
