The Watershed Week

This was a week of some rapid progress.

The CEO of the organization who has been traditionally hand holding every effort from HR hiring to process implementation to resource scheduling to client satisfaction was on a leave and it was left to the employees to manage the organization all by itself.

Three of the developers [1 of whom was participating in the session] caught hold of a project manager, process analyst and CTO in the conference room to discuss their problems and issues. It was a landmark moment for all of us. The group discussed issues ranging from not enough learning, not enough guidance, not enough leadership and not enough clarity. The CTO and Process Analyst explained the what steps are being taken to overcome these precise issues. They also sought their help in taking initiative and coming up with something very innovative. We promised to meet in another month’s time to discuss if we have made any progress at discussing these issues.

In the same week. one of the new teams was also formed. The new project lead has already undergone the SCRUM process training and this helped her understand issues. Most importantly, she had a place to turn to to help her in the transition to Agile. One of the projects which had gone really bad was turned around by her team using project and sprint backlogs to guide their development process. There are some issues with her team which she needs to still tackle. However, we are on good footing because the team is talking, discussing and ready to take more work and action.

In the same week, we also had a discussion with one more project team through CTO to define the project backlogs for all new projects. We almost made it compulsory to start all new projects with a project backlog. In fact for one of the projects we are doing a full “story writing workshop”. I had some time from doing the normal quoting/ writing proposals to help teams discuss and define their backlogs and user profiles.

In the same week, we reviewed number of software’s like Rally, SCRUM team Add-on, Planning Poker, Excel, SCRUMWorks, SCRUM Wiki and XPlanner. We have zeroed in on XPlanner and we will be customizing this for our own organization. All this coming without any push from my side was the most heartening aspect of all.

In the same week, teams found out innovative ways to put their backlogs online - Google spreadsheets, simple interfaces, excel sheets, scanned sheets et al. Creativity, willingness to experiment, willingness to learn and importantly, willingness to share were the critical aspects here. However, this is still limited to only some sections of the organization and not the complete organization. Our challenge is to make this fire spread far and wide.

And last of all, this was the week where we discussed story points with a customer and decided to pick up work only for given story points in a week. It was a watershed moment in our history.

Sometimes I feel, are we going too fast

Next Group - SCRUM Session II

This week we conducted the second session for the second batch. The organizational disfunction was illustrated at its best in the arrangement for the sessions. Three developers turned up 15 minutes late and worse of all we had to conduct the session without a projector. It seems that the department projector was in the cabin of an employee who was on leave. Hence, we had to make use of white board. However, this seemed to a blessing in disguise. We turned the session into a conversational one. We picked up a project which two participants were working on and constructed the project and sprint backlogs for that. We used the session to get the participants to work like a team and come up with something useful. We ended the session with the team promising to get the backlogs going for their teams and projects. We seem to be making some progress.

Another heartening aspect of the session was that the group has started to take interest and participate. We hope that the sessions also empower the participants to think and articulate regarding the obstacles and innovative solutions to overcome these.

Next Group Session I Feedback - Part B

We were able to get 3 out of 7 participants to give feedback for the last session. The session feedback was as follows:

We would need to devise better way to get feedback. As always, technology might not be the best solution - at least not in itself. We would need to talk to participants and get their feedback. Lets see what we can do about this and if we can get people to participate more next week.

Random Thoughts - III

SCRUM empowers people.
SCRUM provides visibility.
SCRUM exposes people.

How do you handle all this?

We have already had problems where we identified one project manager as being the bottleneck in getting the team to an optimum level. We are staring at another project manager who has his ideas and thinking in old style management - control and direct. Two-three developers who work in his team are feeling a little restless because of the expectations that the sessions bring on them and the expectations of their reporting authority. The typical knee jerk reaction is to fire or move and shuffle teams. However, what is delaying this is probably because finding experienced project managers is very difficult. And finding experienced project managers who want to turn Agile is even more difficult. We are trying to convert project managers through trainings and hand holding. However, the jury is still out on this. Any process change does provide for lot of churning - however, we would try and keep this churning to churning of mindsets and not people.

Next Group - SCRUM Session I

This week we started SCRUM sessions for another group of 8 employees. The group comprised two project managers [one of whom was the CTO of the organization] and one project lead, 3 were senior developers and 2 others were considered highly for their experience and skills. However, the exercise got to a wrong start with the project lead opting out of the sessions at the last minute. However, we had seen lots of hiccups in the past and understood that its take time to get a group going. We went ahead with the training session. Unlike the last group, this group presented lots of contrast. The last group was comprised of employees of excited individuals on one hand and on the other hand there were those who either not interested or did not understand the purpose of the exercise. This group had only two-three eager participants while the others were quite obviously bored or could not care less.

The session content was almost the same as the one we had used in the first group. However, I did add couple of other interesting facts like communication channels, failure of formal requirements gathering phases and critique of control and direct method of management. After a brief introduction to Agile - the group was a bit more responsive. I had also cut down some slides which I found were show stoppers last time around. This allowed the session to go along a crisp pattern. I introduced to the team key principles, values and practices of SCRUM. We also did a small exercise to construct a backlog for a “Blog Website”. The group asked me that can we do an exercise to start the next session? This was encouraging. Although this means that the original session would need to revised a bit - this does mean that we have a bit more responsive a group and we can perhaps the session to another level. However, despite all the excitement in the session - the group did not seem to participate so well in the feedback ratings. There seem to be mixed signals. Overall, it does seem that the session went well. However, we might need to extend the number of sessions for the group so that the group has the necessary time to debate, discuss and understand the SCRUM framework.

For some reason [could be inhibition on our part or just the vibe we got from the group], I did not insist on assignments for the group. Now we think that it was wrong. We did not stretch the SCRUM axiom of “art of possible” far. The group might not understand doing session assignments which are not directly related to their work but we could have thought of something that allows the group to mould their assigments around their current projects. Lets try and see what can be done in the next session regarding this. We also need to gather the session feedback/ rating from the group.

Progress Update - I

The last week was an exciting one. Not only were we able to wrap the sessions on SCRUM for the first batch but an assessment at the end of the coaching [comprising of objective type questions and a group exercise] made us understand that everyone has grasped the fundamentals well. Now is the chance to build on this.

Two projects have already started using SCRUM. However, we see them facing problems like customer interaction, communication, backlog construction, allocating work tasks and people who took the training taking it on themselves to implement SCRUM [and in the process becoming like project managers of the yore]. Hence, the skills training is very important for the group. This will inculcate the right approach to issues like client interaction, team communication and positivity. After these sessions are over, the group also needs to understand the agile estimating and planning approaches. However, we would allow them to experiment for a while so that when they come to the next sessions - they understand the context of the discussion.

However, there are also cases where we have not been able to implement SCRUM and this is primarily within the two teams. We need to check what we can do about these cases in the next process group meeting.

Apart from this, we have also institutionalized the HTML training for the developers. The worrying part is that this request did not come from the developers themselves and was identified by the management. The good part is that at least a mechanism for training has been institutionalized and a vision for the process includes advanced XHTML training as well. The very fact that we need to tackle the issue of synchronizing team training times - means we are suddenly seeing trainings and exchange emerge as an item with high frequency and we need to now organize this.

And finally this was also the week when we first discussed the idea of Process Audits. More on this later.

Next Level for SCRUM Masters

I have been thinking over the past few weeks that does a SCRUM Master really need to be only a Management Guru? Does all that she need to do is to keep the SCRUM process in check? What is the career graph for a SCRUM Master? Why is this question circulating in my head is because I am myself battling demons that I am being left behind in the technology race. How long can you just enable people to make the really cool and snazzy interfaces/ scripts/ APIs without yourself wanting to be part of the action? However, one of the SCRUM rules is “only one role”. You can not take on another role in the project. However, if you continue doing only one role again and again - would you not feel stifled?

There was a Yahoo Group Discussion on this topic some times back. It seems that SCRUM Masters should then become coaches who help SCRUM Masters hone their skills. But what next? There does not seem to be any answer from what I have been reading.

However, I think we need to understand that the key idea of SCRUM is that everything is not a designation but a role and a responsibility. Every individual in the team can take turns to play the SCRUM Master. I would think that is the ideal situation and scenario. However, that means that coaching/ mentoring/ understanding is something that the whole team needs to get involved with rather than having someone coordinate this for the team. However, is that not what SCRUM is all about?

Skills Session - Communication

Last week was quite eventful. One of our main concerns in Agile Implementation is that is a ground up and gradual process. Our belief is that this not only involves exposure to Agile values and thinking but also to best engineering and management practices. All the team needs to be aware of the technical challenges which the projects face [rather than just the team leads/ architects] and the whole team must participate in the design sessions and decisions. Hence, we were thinking of organizing the next few sessions through one of our most experienced Project Managers which would expose developers/ senior developers to what “done” actually means from management/ customer perspective. This was an important hindrance which almost every layer of the organization had identified - the definition of “done” was very weak and the understanding of “done” across the team was very different. Last week we were not able to organize the session http://agilediary.blogspot.com/2006/12/scrum-session-v-feedback.html [the Project Manager was not able to take out time]. This story repeated again this week and the Project Manager again was not able to take out time. I am not sure if the belief is that these sessions are not important or according to the priorities, they are not as important. However, we were determined to ensure that the sessions should not have any break. We were able to contact another of our senior project managers to tackle another aspect which we were keen to get started with - exposure to different skills, whose requirement is even more pronounced in an Agile framework - Communication, Team Building and Relationships. And luckily for us, not only was the Project Manager more than adjusting but seemed very excited about the idea.

As per the feedback available with us, the session was very well received. There were some observations that the session was all theory rather than some games/ discussion - but we are sure that the first session is always the one which lays the foundation. We are confident that the next sessions would be more interesting. The next session is on “Team Building” and I would myself like to be a part of this session.

Explaining SCRUM Basics to Customers - Part I

This week I explained to a customer - what is SCRUM and how to we plan to use it to manage the project [that was currently in progress]. It was the first time someone did this in our organization. However, it was smoother than what I imagined. The customer was more than forth coming and wanted to start with the process right away.

All references to the project and client name have been changed.

Customer says:
what did you have in mind?
Vik says:
We would like to follow SCRUM for Project Management from next week starting with Phase III specifications
Vik says:
you actually have already taken the first step without us asking for it
Vik says:
that is prioritizing the work for us
Customer says:
yes I like the SCRUM model
Vik says:
I think you are familiar with this model – right?
Customer says:
yes
Vik says:
ok – so what we will be doing is giving you a detailed breakdown of list of work to be done for Phase III
Vik says:
please note that this would not cover the work already ongoing on phase II items like labels etc.
Vik says:
which we hope to complete by next weekend
Vik says:
however, we would be starting with work on Monday on Phase III as per priority set by you
Customer says:
ok
Vik says:
we will then track the work on this backlog of work
Vik says:
and visit this once every weekend
Vik says:
or whenever we decide to
Vik says:
and track which items are “done” and which are pending
Vik says:
and then again re-prioritize it on this day
Vik says:
because the priority is not always set and we “might” add more items to the backlog – for instance, the events/ reporting functionality might be higher priority two weeks from now than anything else
Vik says:
does that make sense?
Customer says:
yes it does – I like this model
Vik says:
ok – here are some things which you might be interested to know about”;
Customer says:
ok
Vik says:
1. you can add any item to the backlog at any time
Vik says:
2. however, we will change the priority only when we visit the backlog – this ensures that whatever we take up we complete fully and then move on
Vik says:
3. backlog can have items like “data should be preserved when implementing new functionality”, “the speed should be 1-2 seconds on 56k modem” etc.
Vik says:
4. in rare case if we need to re-prioritize earlier, we can cancel our work and start afresh [however, because we are visiting the backlog once every week – this should not really be the case]
Customer says:
ok
Vik says:
daily status update would be provided to you by team on what they did
Vik says:
also – the detailed task breakdown for the work would be sent to you for each week
Vik says:
I think its important we follow a structured approach because project is now on a critical stage and we need to optimize our growth from scalability, fast turn around times to opportunities and also maintaining a good/ clean code
Customer says:
I totally agree
Customer says:
I think that this is a great approach for V3
Vik says:
Do you have any questions?
Customer says:
not at this time….
Vik says:
ok – if you were to have any questions – please let me know
Vik says:
I am starting a new thread “SCRUM and Project”
Vik says:
in case any one has any questions – you can post them there and I will respond within 24 hours
Customer says:
perfect
Vik says:
however, please note that this calls for a commitment from your side to be available for a weekly chat
Vik says:
this is over and above our other chats we will have
Customer says:
of course – I will definitely make these chats
Vik says:
Thanks Customer. I really enjoyed last 11 months with project and I am sure we would be making a great product in future. At our end, we are committed to help you build a truly world class product.
Customer says:
I am fully aware of that – project is coming along great – we are all very excited about it
Customer says:
Thanks Vik – I look forward to the next level of v3.0 and beyond
Vik says:
Thanks Customer – we are all excited about it as well
Vik says:
Good day ahead
Customer says:
talk to you soon! Thanks Vik

How impressed and excited the customer was evident from the note that he sent us later in the day – “I forgot to ask you guys what day do you think would work the best for us for our weekly meeting?”

What I tried to do was keep this simple and away from jargon. I exposed him to terms like Project Backlog but that was it. There was no mention of Sprints, Sprint Backlog, Burn Down Charts, User Stories, Velocity etc. I think we would need to introduce these terms slowly. It is looking exciting over here.

————————————————————————-
Journey from no-style Project Management to Agile Thinking and Principles
http://agilediary.blogspot.com/

SCRUM Session V Feedback

Some interesting things happened over the past week. One of the senior most project managers could not start her sessions on “Technical Issues: Identification and Handling Bugs/ Enhancement”. She was taking care of bugs/ enhancements created by some other team and hence, could not find time to focus on her session activity. We were taken back momentarily. However, we understood that we had an opportunity available with us. This opportunity was as to streamline and get the people who had been left behind in the last week’s session to catch up. Hence, I spruced up the presentation on “The Team” and presented it again to the batch that had been identified. In hindsight it seems it was a good thing to do.

There were 05 participants this time around. One was absent [injury], another has since resigned from his position in the organization and another was not particularly interested it seems. Anyways, we had 05 participants and we had some interesting discussions on “Engineering and Management practices of SCRUM teams”. The profile of the group was as follows: two dot.Net developers, one Cold Fusion developer and two PHP developers. PHP developers were beginning to use MySQL and had queries regarding use of stored procedures. One of the dot.Net developer was able to clarify aspects of best engineering practices in use of stored procedures. We had a lively discussion on “units”, “code reusability” and “refactoring”. After getting the team to understand the beauty of best engineering practices, we slowly introduced them to the management principles again and this time around the reception was more positive. The team seems to have enjoyed the session. The feedback was as follows:

The team asked me why has a promised meeting between the team and CEO/ CTO not been organized as yet. It was just the spurt that we wanted. The meeting was planned and scheduled for the day after.

What is it that I am carrying forward from the session: Overall we were successful. We wanted to build a solid second foundation for the organziation and we are on the path to do this. We have helped catalyze a movement where this group can help us identify best practices in engineering and management. It would be good to see how do we go from here.