We had regular scrumming sessions over Solaris talk and telephone conference as well as face to face informal meetings. As agile development adage goes, we made application changes precise, frequent and quick, so that users could enjoy the fruits of our modifications as soon as possible. At every release we had two weeks of beta for willing users who wanted to use the latest and greatest or for users who themselves urgently required a feature they had suggested because a disastrous process misbehaviour had slipped through their fingers which the new statistical analysis features would catch.
The management of the users were very supportive and their mandate was make my engineers, planners and designers happy. That was since twenty years ago. Yes, I have been practising scrumming and agile development for twenty years with my colleagues but we never knew that one day what we were practising would be formalised into terminologies called scrumming, extreme engineering and agile development.
In one of my former place of employment, since I normally reported to the Information Systems department, I had a problem. My administrative management would inform me that the project goals and targets that I had agreed with my manager were seldom satisfied. So, came the annual goal and target setting week.
What are my project goals and targets for this coming year, I would be asked. I would sit quiet, pondering how to transform my tasks into projects and milestones that would be acceptable to my manager. Finally, I would confess, I really don't know. What? My goal is to ensure that the users of my statistical analysis applications are happy with my work. That is not a valid goal, I would be told. OK, I proposed, how about goals like these,
- reduce average turnaround times of tasks from two weeks to ten days
- reduce number of misinterpreted customer requests from five to one.
Those are not project goals.
But, but, but, my clients' goals and targets keep changing. I don't know what they want next. They seldom know what they want next.
You must force your customers to accept the way the Information Department works. We have solid projects not moving targets. We should have customer contracts which we would fulfill and which the client department needs to justify through their department managers why those targets and goals need to change. You are working for the Information Department, remember? Not for Engineering, Planning, Manufacturing or Design. You must force your departmental clients to understand how information management works. If you fail to make your clients understand and comply to that, we are sorry to tell you that you have no skills in managing your customers.
OK.
But my departmental clients are in the business of making their customers happy. Moreover, I together with every employee, have been compelled by the corporate quality compliance authorities to pledge through various fanciful sloganeering that we would work our best to keep our corporation profitable by helping our colleagues ensure our external customers are satisfied.
So, why can't I have a set of stable immutable projects? That is because, I work for a corporation which has processes. Both procedural and chemical processes that need to be managed. New products and processes are constantly developed. My departmental clients cannot wait for a process to stabilise into immutable states because if we do not solve issues as soon as they arise, our external customers would take their contract elsewhere. It's a fast changing business. We have to constantly stabilise those processes by constantly discovering requirements for information that we never expected we needed last week. Therefore, my targets keep changing and therefore I cannot have long term project milestones. My milestones are one week as soon as a new issue crops up and I would need to scrum with Engineering, Manufacturing, Planning and Design to remove bottlenecks and roadblocks towards the goals of making our external customers happy.
Then after a while, my psychotic management would decide - so we need to justify your existence because they have just graduated with MBA degrees where they learnt that we need measurable benefits in what we do. If we cannot measure, we are probably doing the wrong thing.
OK, why don't you get your departmental customers tell you how much money they saved for every microproject they make you perform? We have an activity-based costing framework and we need to distribute the cost of employing you to various product lines and the cost saving differentials. So, I spent two days conjuring numbers with my clients, instead of helping them solve problems. After, just one round of cost justification exercise, my colleagues implied that I should either work on their problems or f*** off.
So, on the whole, sometimes information departments are really out of touch with their fellow colleagues on the nature of the business of the company they work for. They are so attached to their information theories and formalised information management theories that they seem to think that the whole world needs to tune their processes to be in line with computer science.
Then, one day, I started working for a company that prided itself with formalised scrumming practice.
Hey, fellow agile development enthusiasts, the day scrumming became formalised is the day of its demise. When I participate in a daily scrum, this is what I expect to happen. I want to present to my colleagues the roadblocks I am facing. Then I want to find out who has the expertise, authority or personnel connections to remove my roadblocks and I would like to find out if I am roadblock to my colleagues and what I can do about that and also if I am the solution to helping someone's roadblocks. And I expect everyone on the team to bear the same attitude. Then I expect that we humbly acknowledge we need to rearrange our fluid milestones and schedule which is subject to changes. Then I expect the product to be tested and then released to customers or customer interface who are willing to provide feedback to the product.
However, the department that I started to work for did not realise they had quite a few impediments to their successful implementation of agile development. Their daily scrum lasts an hour. People took turns to present an update of their tasks and justify their delays. And the scrum was presided over by the scrum-enthusiastic department head, no less. Alright, after those meetings, I would have to go through the actual scrumming by meeting informally with colleagues which is when I get my real scrum done.
So, the company was experiencing frequent customer returns. These are huge pieces of equipment not little tubes of IC chips. Or the service engineer would have to drive or fly a couple of thousand miles to see what the problem is with the equipment. The idea of agile engineering, I was reminded was to work on an issue, and don't try to solve the bigger picture and refrain from refactoring your code. But that advice works only after a while. With the frequency of customer returns, the only solutions was to clean up the code that I had inherited because patch after patch was making it difficult to trace problems.
The other problem was, customer interface personnel who worked with us refused to participate in scrums. In order to find out what the problem was, we needed to make changes and have her try it out. But she complained to the department head that she was confused by my frequently updating the behaviour of the application. Ok, she complains the customer is not able to use the equipment because of software problems. I am told that the formalised theory of agile development is not to make large changes. And without making large changes I cannot clean up the code. Without cleaning up the code, the patches upon patches made it impossible for me to predict if when released, would the equipment be returned. And to clean up the code I would need our gentle and lovely customer interface to understand that she would need to test them.
It is unfortunate when once useful and practical procedures are formalised into respectable MBA curriculum, they normally become the problem rather than solutions. People don't know when to deviate from the theory.
As for me, I just want to make my customers happy.
No comments:
Post a Comment