Inertia Rules

No progress over the last month. Thats three months of inertia in a row now. We even had to postpone the session for the 3rd group once again. It did not make for very happy faces but things were beyond our control or at least we let it be. Some things which make our efforts to overcome interia futile:

1. Fellow team member on leave [getting married], so personally neck deep in work
2. Agile Collaboration System stalled for lack of energy and quality time expenditure on it
3. Long stuck project requires attention to be completed at the earliest
4. Finally, Agile Implementation as Number 1 priority of the organization takes a back seat

The future is currently looking bleak and something will need to be done at the earliest. The big question is how to get rid of interia that has set in?

Advertisement

Slack

If you have been following our recent posts, Taking everyone along in Agile Implementation, Is our Agile Implementation on its way to Failure? and Resuming Sessions after Break then you would know that we have been trying to get the third group sessions organized for over 3 weeks now. And for 3 weeks all we have done is talk internally. This does not like a very Agile shop. I also discussed in Taking everyone along in Agile Implementation that I have not been pushing hard. One of the reasons for the same is lot more workload due to some team changes and the second is because I have not been able to motivate myself internally. Somehow, I do not seem to have the energy any longer. I cant argue my case with passion and earnestness. I give up far too easily and just let the things drift.

An Agile evangelist and sponsor who cant keep himself/ herself motivated continuously over a pretty longer period of time is not a very good sign for our Agile Implementation. Does it strengthen my original question: Is our Agile Implementation on its way to Failure? What is it that we and I can do to get over the slack and get things in momentum like before? It has to happen sooner than later for sure.

Taking everyone along in Agile Implementation

One of the thoughts which strikes me everytime I think about Agile Implementation is our CTOs comment “Project Managers need to be on top of things all the time.” And yet, as a project manager of Agile Implementation myself, I have not been the most Agile Project Manager over the last few months. I have not adhered to the Agile principle of carrying everyone forward. I have allowed people who do not quite understand Agile to dictate how we should structure our Agile Implementation. For instance, one of the junior most designers who was earlier a part of our truncated sessions for 3rd group is no longer considered to be worthy enough to take the sessions. This is because the current thinking is that Agile sessions are for employees with certain “IQ” and “who can take us forward“. The argument put forward is that we need to explain to employees why someone is allowed to take these sessions while others are not allowed/ considered. Hence, only the very best [or at least the very best in our eyes] should be allowed to take the sessions.

The other side of the story comes from the usual office politics. Some project managers will not allow anyone from their team to take part in the sessions. This is because they either do not like what we are doing or they have problems with people in the Agile Implementation group.

In both the situations above, it indicates that the reason why we are not able to take everyone along is because we cant get people in top management to be carried along as well. The implementing group has been thinking of it as some kind of agenda that we will implement Agile without the support of top management. This is obviously not going to happen. Also, this alienates them to the extent that before Agile is going to become a total reality we have already create a group that does not want to hear anything to do with it. In the first case [where a designer was barred from attending 3rd session] it indicated failure of communication internally in the group and in the second case [where office politics was at play], we were at failure in getting along everyone in top management.

We know its hard to work with people whom you have passionately hated all your stay in the office but we need to decide what is more important for us, Agile Implementation or Our own Comfort Zone. The answer is not that simple. But one thing is for sure, we need to find a way to get everyone along.

Is our Agile Implementation on its way to Failure?

One of the central tenants of Agile is to keep it simple yet effective. Most of the literature and blog content available online generally keeps the first part in mind alright, but does not always have a point to make [like the many posts in this blog]. One of the best posts [in parts] that I read recently was a blog/ article by Jean Tabaka. The article was “11 ways Agile Adoptions Fail” and is available here Keeping these 11 points in mind, an evaluation of an Agile implementation in our organization is attempted [disclaimer – one persons viewpoint only]:

1. Retrospectives – How often do you do retrospectives? Do you do these often enough? When was the last time you did it? This is a very interesting question. We can probably measure it with some sort of a process metric very easily too. However, the more important question was what followed this. What did you do with recommendations of retropsective? This is very important. Unfortunately, but for one team where a one-to-one meeting with the immediate lead is the norm, the other teams seem to be doing very badly on this score. Score: 3/10
2. Everyone or select coterie – Do select few senior people dictate the project schedule, deliveries, estimates and milestones? It seems like we do pretty badly on this front. What it tells us is that either we do not trust the junior members in the team enough or we do not know of way to involve them in decision making. Does the team have committment from each of its member? This seems like a KRA of SCRUM Master, getting everyone motivated and charged every single day of the iteration. It does not seem like we are doing this well either. Score: 5/10
3. Infrastructure – Has the team removed the obstacles every single iteration to come to a steady flow output of functionality every single iteration? This seems like something which flows from [1]. Has the team learnt skills like refactoring, unit testing, continuous code check in, pair programming, osmosis and build control? It seems like we have done this well enough, but probably not through the means that it should have been done. A group of highly motivated employees has brought these terms and ideas to attention and coaching has been done on these. The results are not totally satisfactory but we are doing well enough and consistently enough. Score: 6/10
4. Bad SCRUM Masters – Is the team leader more oriented towards servant leadership or command and control? Unfortunately, we do not score that well on this parameter. We need more to be done to move away from this. The [2] and partly [3] highlight the symptoms/ causes of this behavior. Score: 2/10
5. Product Owners – Are product owners not available or there are too many that do not agree with each other often? Although our product owners are generally available but the decision hierarchy is too big: a client working with our client [who has project managers managing working] who works with our project manager. The tree of information flow is big and the projects are stuck with varying expectations, feedback taking long to arrive and lots of change requests after projects are done. And because we do not have a lot of [1] and [2], we are stuck with same cycle over and over again. Score: 5/10
6. Revert to form – Reverting back to old habits. Dictating from top which code to use rather than telling teams to analyze and consider using a particular piece of code is a recent example of command and control. The team which seemed pretty charged up to write a great piece of software is now just doing the mundane and needed. Similarly, not answering developers questions and simply saying “Do it, because I say it.” or “Believe me, this is the way it is most efficient.” Not investing consistently and heavily in trainings and refactoring means that not enough learning is being done at all levels in the organization. Wow! it seems we have a lot to do here. Score: 2/10
7. Top Management Support – Does management provide rich resources and rich committment to support Agile? If the organization is not effectively going Agile, the case is probably not being pushed strongly enough by the management. However, we seem to be lucky here. The management supports and makes an effort to understand Agile. What is could probably do more is to wake people up from slumber that is [6] above. Score: 7/10
8. Decision Making – Who makes the decisions? Are decisions handed over to the teams by the CEO/ CTO and to developers by the managers? In this scenario, motivation and committment and to an extend employee performance suffers. This is different from [7] above where the management support for initiatives is required. Management does not need to dictate but lead a path to discovery, understanding and appreciation of larger organization concerns. Score: 5/10
9. Onsite Evangelist – Not having a full time coach and evangelist. We do not have one and it does seem like lot of [1] – [8] above would be taken care of if someone’s KRA was just to see that these do not occur. However, we do have two or three senior employees who play this role as part of their other roles but seems like it is not sufficient. Score: 2/10
10. Learning – Not supporting learning, means not supporting agile. [1], [2], [8], [9] above would mean that we need to do a lot more to truly institutionalize learning. It is something we need to passionately believe in, measure and amplify at all levels. We have done well primarily because of efforts of few people in senior management but the results would be even better, if its done by efforts of even more people. Score: 5/10
11. Honesty – Does management support brutal honesty and transparency and encourage teams to achieve the same? What would we say to a manager who comes and says that this was a mistake and the project would be done in twice the estimates if everyone filled time sheets? Would the developers be willing to come and say, we lack these skills, we need trainings for these? Would senior management be willing to say, yes we violated terms of agile and are sorry for the same? It seems like we will get a positive response to some and not so positive to others. Hence, some work to be done here. Score: 5/10

The total score is 4.3/10 which does not seem like something flattering.

What should be the next steps that make this score go up?

Resuming Sessions after Break

We are resuming the sessions for the third group after a break of over 4 months. The sessions were stopped in between because of number of reasons. Some of the reasons are:
a. Our focus and attention shifted to development of an Agile Project Management System for use internally
b. The key people got involved in other projects because of the exigencies at organization level
c. Some of the people were shuffled along

The teams are now settled. Our PMS project is also coming along well. Some members of the group have now begun to ask us to schedule the sessions again. It seems like a right time to schedule the sessions. There is just one slight issue that we are facing. Do we continue with the same group or mix and match to get a better combo which reflects the current realities of the organization better? If we do not do so, we would be holding ourselves hostage to niceties and safer option and if we do so, we might just demotivate people who are left out. Currently, it seems like the former option would be the way to go.

Update from the Break Period

Its been a temporary break since writing the chronicles of the application and also implementing. We have been busy reading and discussing lots of activities internally. Further, I have been having some trouble on the personal front. Hence, the activities on the Agile Project Management front have been lying low. However, it has allowed us time to step back, observe, gather opinions, hopefully understand and come back with renewed vigor over the next few months.

One of the activities is an Agile Project Management System. We have been reviewing a lot of SCRUM and XP based Project Management Systems. While some have some features which work very good, there are many which appear to be a drag. We are still undecided on a make vs. buy decision. This is possibly the biggest challenge in making a technology decision for a process. We should not forget that technology does not solve the problems – it can be an enabler and a very effective enabler, however, it will not solve most of the deep rooted process and improvement issues. Hence, while we are discussing the project management system, we should not loose sight of project management.

I read somewhere that effective change takes about 02 years to percolate down. It is heartening when the teams talk sprints/ iterations and daily SCRUMs. There was a time when development used to start without a clear idea of what the client wants. The wireframing and prototyping phase [which precedes the sprint immediately] has allowed us to confront the fact that We now need to think about the next level. I think the teams now to understand the importance of updating a project backlog, estimating the stories upfront and deciding how many stories would they want. Once this is done, we should then start at defining the steps for a project. Hence, “Stories and Tasks” should be the next from our motto of activities.

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.