Being Agile @ Work

I manage a team that works on different flavors of IT projects, such as development, maintenance and enhancement of the existing applications, implementation of strategic technical and functional initiatives at an organization and group level, and working on BAU ad-hoc and priority issues.

The team is expected to handle and work on multiple things at a time in such scenarios. This is the 2nd such team I am managing in as many organizations in my last 5 years of career. And, the organizations I have worked for (Thomson Reuters and British telecom) are 2 biggies in their respective areas. So, the expectations from any such team across any such companies across the world cannot be any different from mine, is what I conclude.

The only difference would be that certain companies have got the grasp of how to handle such teams with ease, and some are struggling.

I had my struggles too, and have been able to find a way out by adopting agile practices in “managing the team”, though the execution of the projects that the team has been working on are following a waterfall model. Some of the struggles:

1. Highly fluctuating WIP items of each team member
2. Surfacing of issues when it is too late
3. Non optimal turnaround time of items on hand
4. Non optimal productivity of the team

I am going to take an example of completion of a technical design which is one of the artefacts that is delivered as part of waterfall project execution and how by giving an agile touch to it, I have been able to tackle the above problems.

Earlier, the design documentation would be estimated with an overall effort comprising of conceptualisation of design, completion of documentation, review and roll out. This meant that the design was available for review once the documentation is complete. Now, by using WBS, we have been able to break down this story of design into specific , reviewable tasks and accommodate review of each reviewable chunk as soon as it is done, thus ensuring quality is reviewed and ensured adhered to  even before the whole exercise is completed in entirety.

The participatory nature of this exercise (both in estimation and execution) ensures that accountability does not just lie with manager or the lead of the project, but gets percolated into the last member of the team, thus giving them enough visibility on what they are contributing into.

There is a progressive evolution at a team member level with respect to estimation and prioritization and improved sense of involvement/inclusion.

Daily stand up meetings have resulted in a visibility on the progress of tasks on hand and adaptive accommodation of the items in backlog. For instance, our organization has strict regulations on mandatory trainings that each employee of the company has to take on a regular basis. Such important but not “a priority” tasks now are gotten into the daily work stream when a band width is seen on a daily basis (which comes out at the stand up meeting), thus freeing up the management and employees from last minute rush into completion when the end data approaches.

Iteration review and planning gives scope to learn iteratively from each sprint/iteration and get learnings into practice in the subsequent iterations in terms of better planning, better breaking down, and optimized estimations.

As you might have noticed, what I have adopted is the agile mind set to execute the operations of a team that works on projects in a waterfall model, and I am able to reap the benefits by improving the engagement level and turnaround time for each team member.

Extrapolating it to an application level or product level delivery of a group or organization, I can draw parallels of benefits that can be achieved with respect to

1. Iterative, incremental and evolutionary execution over big bang release
2. Test driven development
3. Short feedback look and adaptation cycle over phased implementation

Distribution of resources across the globe, team sizes can pose challenges to adopt Agile methodology at an organization level, but there are collaborative tools that I have used such a Asana and VersionOne which I have witnessed not only eases out the functioning, but also makes it very interactive and fun filled.

Also, the bottom-up approach of practitioners (of agile) spreading the awareness of the benefits up the organizational ladder, I feel would cement the adoption into the methodology than it coming top-down as an organization policy.

Scrum and Kan-ban are two populate that companies have started adapting to at a very fast rate. I have witnessed the transition from waterfall to scrum methodology at Thomson Reuters and have witnessed the improvement in speed of delivery, the team engagement and quality and currently am trying to replicate the same with British Telecom too.