Agility - Looking Beyond Software Development

17 December 2013


Overview

The Agile software development community has created such noise and visibility over the last few years that the very notion of being Agile, and using Scrum as an instrument for enabling agility, is often associated with projects or initiatives that involve some aspect of software development. This isn't anything that wasn't expected; after all, Agile did come into existence with the motto of "uncovering better ways of developing software," as mentioned in the Agile manifesto.

Anecdotally speaking, though, Scrum and Agile borrow from the principles of Lean manufacturing, thus providing credence to the school of thought that it might be possible to use some of the practices and strategies we use in Agile software development in fields that aren't related to software at all.

One of my close acquaintances has a reasonably successful consulting practice that he, along with two partners, manages from their office in Gurgaon, India. Let's call them KNM. KNM provides accounting, legal advisory, and strategic consulting services to international clients working primarily in the Japanese segment. During some of our conversations over the last few months, the challenges of being an entrepreneur often came up. One oft-repeated grouse related to their increasing inability to track tasks that their employees, mostly lawyers and certified accountants, were working on. It appeared that my friend and his partners were spending an inordinate amount of time trying to manage work allocation, monitoring, and eventually quality control for the artifacts that they were creating for various clients.

This immediately rang a bell. Their problem was probably a result of their failure at creating the right amount of visibility into the progress being made by the team, as well as an absence of quality control checks designed to augment the self-learning process of the team. It was also obvious that instead of focusing their efforts on trying to generate more business, interact with clients, and act like entrepreneurs, they were caught in a familiar downward spiral of being stuck in their roles as managers. In the absence of a strong history with their team, which led to some lack of trust, they had to vet almost everything before delivering to clients, since neither the legal nor accounting worlds are very forgiving when it comes to defects.

I am pretty sure that the problem sounds familiar to most of us who come from the software world, and I believe that a potential solution would also be apparent to those of us who are Agile enthusiasts. In our world, projects are mostly short-lived, and thus we need to continually adapt to working with new clients, new teams, and fresh sets of expectations. Given the similarities in my friend's predicament, I decided that it was time to adapt Agile practices to try and address this common problem in a niche industry, and that this might well be a perfect case study to investigate and analyze the degree of success with which agility could be implemented in the world beyond software development.

The road to Agile -- Scrum or Kanban

Given my biased mind-set molded by experience in the Agile world over last five years, the solution that I initially considered was obviously built around leveraging Scrum. Scrum, as we know, more or less adopts an iterative process for creating business value.

However, the work that KNM was executing for its clients mostly involved tasks that were repetitive in nature, for example:
  • Legal compliance checks that are standard
  • Incorporation activities for new companies that would always need the same set of forms to be completed
  • Auditing that would, again, need the same set of procedures to be followed and the same set of documents to be vetted
  • Strategic consulting
The place where they had to think outside the box was strategic consulting. Since this was only beginning to take off and involved mostly senior people on their team, at this point in time it wasn't their primary pain point. As we have discussed, mainly they had the following challenges that they wanted to address to create a more Agile organization:
  • What does their work pipeline look like?
  • Creating visibility about who's working on what
  • The current status of tasks being worked upon
  • Any impediments that need to be addressed
  • Quality control by using a checklist of tasks that have to be completed for a standard regulatory compliance or audit activity
As I pondered potential Agile implementations within this context, it became evident that iterations were probably not going to add value for the kind of work that my friend's firm was doing; and if it was not going to be iterative, I was fairly certain that using Scrum might not be the right thing to do.

The feature that I certainly wanted to borrow from Scrum was that of the daily Scrum meeting. The intent was to offer an opportunity for various KNM teams to meet every day and share their progress, obstacles, and any specific lessons learned. This way, they could all stay in sync without having to attend multiple meetings throughout the day. Respective team leads could then go on to attend a Scrum of Scrums with management so as to make sure that the organization as a whole was on the same page.

In one of my previous posts, Are We There Yet?, I talked about creating visibility for various stakeholders in a software development project by leveraging status boards in JIRA. JIRA as a tool is an altogether foreign concept for folks outside the software world, so I had to fall back on using Excel sheets for creating various boards that were kept on a shared drive so that everyone could access them.

Apart from status boards, we also created a task backlog, akin to the product backlog, and educated KNM decision makers to always keep the list sorted so that people could finish their existing tasks and simply go ahead and pick the next-highest-priority item from the backlog to work on. Thus it was primarily Kanban that I considered to be suitable for addressing this particular problem, albeit with a mix of Scrum to encourage smooth communication and a higher level of awareness across the entire organization.

Kanban -- the solution to creating visibility

True to the spirit of Kanban, we decided to create three different boards:
  • To do -- A master list of items that would be managed and prioritized by senior management within KNM. Respective KNM teams would have their own backlogs that would derive items from the master list.
  • In progress -- The items being worked on currently, assignees, and the status of respective tasks for those items. The tasks to be completed for a particular item would be derived from templates for standard work items created by domain experts in KNM. This ensured that there was standardization and consistency across the organization in terms of exact steps to be followed in order to claim that an item was successfully delivered to a client. The templates would be refined and reviewed periodically.
  • Done -- To specify what has been delivered to the client and when. This board would be similar to the "In progress" board, albeit with all the tasks marked as completed and completion dates specified.
It is important to point out here that both the "In progress" and the "Done" dashboards were created at the team level as well as the individual level. This was to offer a fine-grained view into the current occupancy level of the workforce so that future work could be planned and committed for the clients accordingly.

The implementation

Having completed most of my homework and created a plan for assisting KNM's march into an Agile world, I conducted two full-day trainings for the senior management, team leads, and team members. Later came multiple follow-up sessions wherein specific problems and challenges were addressed as they cropped up during the actual live implementation of the new work strategy.

The sessions were initially conducted separately for all the folks at different levels in the organization so as to encourage questions and solicit candid feedback about the proposed changes. It is worthwhile to highlight here that the entire process was only possible because I found plenty of traction and support from the management team of KNM to begin with. After spending four hours during the first day reviewing and understanding the whole strategy, they were all in agreement that the concept of product backlog, standardized templates, and dashboards for status and progress monitoring were steps in the right direction for their organization. (Please refer to the aforementioned article Are We There Yet? for an idea about the baseline templates that we used for customizing dashboards for KNM.)

We spent the rest of the day finalizing the format of various dashboards and discussing some of the formats that could be considered for the standard task templates.

Conclusion

Agile and Scrum, as we know, are processes of continuous change and improvement. Having implemented most of the changes over the last couple of months, the ride for KNM has not been all smooth sailing.

They've had particular challenges in motivating team members to provide daily progress updates. Initially the challenge of simultaneous changes to the same document also arose -- and was resolved by migrating to Google docs for managing most of their Excel-based dashboards and other documents.

Another challenge was to keep the backlog prioritized, with priority being updated on a regular basis. This was an aspect and expectation that people at various levels of management at KNM are working on and trying to improve as an ongoing process.

However, all the team members at KNM are in agreement that now they have better visibility into where they are as an organization in terms of delivery. Daily Scrum meetings assist everyone in prioritizing their tasks, resolving dependencies, and highlighting any impediments. The management now has informative dashboards and multiple forums wherein they get a realistic sense of work being delivered and planned.

In my opinion, the best thing has been that they've now begun exploring tools like JIRA to help them automate the updating of most of their dashboards. This appears to suggest that the information collected using the Agile/Kanban approach is being put to good use across the decision-making process of the organization.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

ABHISHEK KUMAR SRIVASTAVA, CSM,CSPO, 12/18/2013 10:15:07 AM
Good article Sourabh. Agile can do wonders in non-software dev world too. Your experience here is a perfect example.

You must Login or Signup to comment.