Archive for the Coaching at Net Solutions Category

Inertia Rules

Posted in Coaching at Net Solutions with tags , , on June 30, 2007 by vikramadhiman

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?



Posted in Coaching at Net Solutions with tags , on June 18, 2007 by vikramadhiman

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

Posted in Coaching at Net Solutions, People Management with tags , , on June 10, 2007 by vikramadhiman

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?

Posted in Coaching at Net Solutions with tags , on June 4, 2007 by vikramadhiman

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

Posted in Coaching at Net Solutions with tags , on June 4, 2007 by vikramadhiman

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

Posted in Coaching at Net Solutions, Project Management System with tags , , on April 28, 2007 by vikramadhiman

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

Posted in Coaching at Net Solutions with tags , on February 25, 2007 by vikramadhiman

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.