Progress Update - 02/24/2007

Its been a quiet 2 weeks on the Processes Front. We did not conduct the weekly training class and we also did not have any major discussion/ breakthrough. We have however had some disheartening developments - four of our key people have resigned and two have left - apparently attributing the reasons to lack of processes and defined roles. The worst part of this has been that these resignations have happened in the high performing teams. None of these resignations is directly related to the SCRUM process implementation as such. In fact none of the people who resigned have been involved in SCRUM trainings so far.

Apart from that one of our flag ship SCRUM projects is going to Beta this week. This is 15 days late than originally planned - however, compared to the other projects which have usually been months late, its still some achievement. We are also looking to complete another of our projects by March end. We are having difficulty introducing all the SCRUM related aspects in the project so far. That is primarily because I am not being able to spend devoted time with the teams on the projects. Next week we will try and adhere to Agile values and principles and framework strictly. We have had a new Project Lead who is probably not trained much in Agile project management. We now need to factor in how we would be able to bring him up to speed as well.

There are some good signs as well. There have been projects where very good backlogs have been created without my involvement. The projects have been put into practice/ development life cycle as soon as they have got approved. Also, the general happiness quotient in the people involved in SCRUM projects has sustained so far.

Why is SCRUM difficult?

***Draft Version of article

SCRUM seems to be the most light weight method of project management ever. Let’s see what it says:

1. Maintain a prioritized list of things
2. Pick some items and put them in a sprint/ iteration
3. Deliver the items at the end of the sprint/ iteration
4. Revise the list of things to do

Whats it about this that is so difficult to do? Over the last months, we have had difficulty doing this in each and every project.

Difficulty 1 : Drafting a Project Backlog

Project Backlog is not just a prioritized list of things but needs to be prioritized, estimated and also useful/ relevant. Its time and thinking consuming to arrive at a consensus on prioritized list of things or project backlog. It is generally considered a client’s duty to provide the project backlog and keep it useful. The very nature of Agile ensures that he is not the *only participant* in this exercise, nor is this a dump down exercise where product owner just has a field day choosing things. It requires the product owner to answer questions on usefulness and address technical dependencies in the project. It requires the client to be in toes all the time - evaluating usefuless of the items in the backlog and advising the team of business priorities. And importantly it requires the teams to understand this business perspective of the project backlog. For most developers, transition to a business thinking in software development is rare. Software development has generally been considered a technical job, far removed from business and developers/ in most cases even project managers have been shielded from the business side. Hence, arriving at a project backlog that is useful and reflects a common understanding is indeed a difficult exercise.

2. Difficulty 2 : Drafting a Sprint Backlog

Most developers are pretty poor in dividing required tasks for a requirement. It is primarily because they have been fed on a diet of breakdown of tasks already done and specialized people doing specialized work. There is little or no incentive to think about the big picture or overall scenario. Most developers also want to shy away from committments. They would rather have someone else estimate how long it would take and how it should be done. And importantly, most teams are afraid to fail or allowed to fail. SCRUM’s allowance of just enough thinking and ability to add tasks later allows most developers to only think of two-three days at time, giving project managers little by ways of vision of tasks for the sprint. A sprint backlog generally becomes a dead duck document which is passed around in morning email. One day the team is doing 30 hours of work and another only 5 hours.

3. Difficulty 3 : No restrospectives

Most of the problems highlighted above also occur because there is no learning. There is just not enough of committment from the teams side to grow in managing their projects better - not as much as learning a new technology for instance. What is the incentive to estimate better? What is the incentive to divide tasks better? What is the incentive to try an unchartered path, fail and provide a learning of how not to about things? Another problem why teams avoid retrospectives is because most of them do not know how to do retrospectives - what is problem identification and problem solving.

If we do a root cause analysis of each of the above difficulty scenarios - we would reach to one common cause : not enough committment and no focussing on right things. Most of us have difficulty asking questions the right way, analyzing the right way and answering the right way. Most of us are caught up in our day to day working so much that we incorporate only fire fighting element of SCRUM in our project management, leaving the more beneficial - learning and adapting out of window. SCRUM is like driving and swimming - lots of little things to take care of but once you know it, you can do it easily. Unfortunately learning it first time around require : committment and focussing on right things.

Next Group 2 - Session I

This was a group we were waiting to conduct SCRUM sessions for. It was truly a wide represetation of the organizations culture and work force - graphics designers, quality people, developers, analysts - freshers, experienced, mid-career.

We started the session discussing participants expectations from the session. We then introduced them to the ideas of agile principles, empirical process control - visibility, inspection, adaptation and then introduced the SCRUM framework - SCRUM roles, ceremonies and artifacts. We made a few changes in conducting the session this time around. Each session there is a check list that all participants identify for themselves that they would go back and try and implement. The over-riding theme of the session was the participants would like to become more organized. Most of the participants opted that making a list of things that they need to focus on would be their first initiative along with trying to understand the why behind the client feedback/ participation.

These sessions are challenging from another perspective as well. Most of the participants are not terribly convinced about SCRUM and Agile. The feedback of the first session was “focussed on basics”, “we felt energized after the session”, “we have to feel more responsible”. It would be interesting exploring how do we go further.

Next Group - Session VI

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.

Random Thoughts IV

The Journey from No Style Project Management to Agile Thinking and Principles is now in gear two if not three.

We are out of gentle introduction to Agile and debating real team issues. From clients who don’t yet get it [ones who don't respond for weeks at a stretch, to ones who are prioritizing things left, right, center], to team members who are not willing to walk the extra mile to other teams who are feeling left behind. There are teams who have a grin when they say - “we told you so”. There are teams who are being exposed for their lack of effort, initiative in using software to solve the customer’s problems.

However, there are some successes as well. Every project has a plan defined upfront and the teams are trying to keep this process dynamic. There is a team which allows the team members every Saturday to experiment for half day. The team outings, fun quotient and making people count have become buzz words. From having no second string to take control, we have quite a few contenders for the next responsibilities in the organization. Teams are meeting and discussing ways to improve. Project visibility has increased and activities like monthly managers SCRUM to discuss issues like new organization wide processes are increasingly regular.

We are in exciting times. The problem though, is that the SCRUM initiative is still one persons belief. I myself find it hard to take the crap and attitude form some people. Motivation to concentrate on only the cooperating teams and people is high. Let’s see how this journey unfolds.