This session was not about Agile practices but an understanding of what makes Agile work. It was suitably titled “Agile Thinking”. Agile Thinking focussed on retorspectives/ root cause analysis, energized environment and informative workplace. We focussed on how having the right information at the right time for the right people is key to being Agile. Another focus was on understanding how motivation, energy and intrinsic desire to innovate is the key to people delivering good quality output. We also discussed how having fun in the workplace was one of the key requirements for an energized workplace. Finally we focussed on how retrospectives can enable people to focus on the right things. The root cause analysis was discussed with two live examples as a technique to unearth the causes of problems/ obstacles.
Ours has traditionally been an organization which focusses on people sitting late as a sign of their hardwork. Focussing on energizing workplace allowed participants to come up with their suggestions on how to organize their lifestyles. One more important part of the session was a live use of root cause analysis.
One of our projects had been run under a lot of on the fly requirements, aggressive deadlines, unpredictable customer behavior and as you would know – lot of stress. As soon as the beta went live, customers registered on the website right, left and center. The website had too many bugs, feature requests, support emails and more importantly a harried/ stressed out staff.
1. We started with some symptoms first. The main one was “It was difficult client to manage”.
2. So we asked the first Why?
3. He was difficult because he was an intermediate client who was serving an external client and was communicating deadlines to them which we were not aware of. Also, he was unreasonable most of the time.
4. We asked the second why for the second part of above cause
5. He was unreasonable because he had an unstable mind and thinks of ideas all the time making our efforts unstable.
6. We asked the third why
7. We had coded in hurry so our architecture was not such that we could support rapid UI changes without affecting the underlying logic. And we were ourselves just following the client instructions.
8. We asked the fourth why
9. This was amongst our first dot.Net projects and the project was also domain specific.
At this point we thought we would do some SSC [Start/ Stop/ Continue] and came up with the following list:
1. Start to do:
a. Have better understanding of the end client deadlines
b. Refactor mercilessely and adhere to coding standards come what may
c. Start thinking about UI designs
2. Stop to do:
a. Stop coding in hurry and not obeying business layer logic
b. Refine the code in Data Access Layer
3. Continue to do:
a. Code fast and be as responsive as we have been
b. Follow the wireframing process
We intend to continue such exercises in future sessions as well.