Agile Intelligence: Test Driven Development

My previous post on Test Driven Development described its usefulness in a software development project. In this post, we will try to explore its utility beyond that - more specifically to projects relevant for services, and the service delivery itself. Our context of discussion will be limited to an instance, where a particular service delivery process is being setup, i.e. a project, and subsequently the service delivery. Before getting there, let's recap the principle of Test Driven Development once more: TDD is an approach that emphasizes the development to be done in a way so that the developed work product becomes just fit enough to pass through the test devised for it.

Now, let's think of setting up a process or a set of processes for a specific service delivery. Normally, we try to take a look at the existing set of processes that deliver identical or similar service(s) and then we try to replicate those processes. After replicating the processes, or establishing those with some modifications, we try to produce the work product using that setup. During this trial, we review each process block and verify whether the work products coming out it are matching up to the spec. Once we see the output of the new processes conforming to the specification, we put those outputs to tests. If the tests pass, voila! If not, let's go back to our own drawing board and try to find out the point of defect injections.

Test Driven Development approach would not challenge this method of setting up processes, though would offer a different variant. Instead of trying to match each output of each process block, it would emphasise the need to test the outputs first. In essence, the specification would be superseded by the test cases. The objective of the project manager responsible to setting up such a service delivery process would then focus on obtaining the test cases instead of the specifications.

In reality, this would make the job simpler too. Quite often, specifications go missing, even if they exist they are found to be dated, no similarity with the processes and steps running on ground. Re-writing the updated processes may become a tedious task. Moreover, the people possessing the latest knowledge may not be treating this as a priority work. They may not be willing too. Test cases, on the other hand, are easy to find in its updated form. Even if it is not updated as a documentation, involving the relevant people to perform the tests would ensure that the outputs are tested using recent updates. Moreover, an observer during testing can document all the quality checks and tests performed on the output and subsequently produce an updated test case documentation.

The problem would not end there though. This approach would bring out the test cases for the final work product, not necessarily for the interim. For the interim test cases, separate effort needs to be commissioned, and the present process owners may not be able to help here. So the approach would be to involve all the team members to understand the end work product, irrespective of the processes they are assigned, and to go through the final test cases even if their work product would not be subjected to that, so that they can apply their minds while doing their bit of the processes to strive for passing the final test. Once the test defects are identified, all the team members need to go through that defect through a common session/meeting, and do a causal analysis together. This would ensure that everybody understands the injection points for each of such defects. The collective learning would be harnessed at a later point of time to document the test cases corresponding to all interim work products.

Once the final work product passes through the final test cases, the service delivery process(s) is ready to roll. At this point of time, the team members would continue to follow the same set of steps they had done to pass the test. Simultaneously, the test cases for all the interim work products should be documented. Once that documentation is complete, the focus should shift towards passing through the interim test cases instead of trying to clear the final set of test cases. Passing through all the interim test cases would improve the probability of passing through the final test cases significantly. At the same time, the process specialist must work to establish a good degree of traceability or linkages between the test cases; between final and interim as well as between interim and interim.

As the service delivery progresses, there comes the changes. Broadly, the changes would come in two types: change in the product specification, or the change in the internal processes due to some improvement and optimization. A change in the product specification would call for a change in the final set of test cases. New test cases would get inserted, existing test cases would get deleted or altered. Using the traceability matrix, the impacted interim test cases should be identified and modified. Similarly, for the change in internal processes due to some improvement and optimization would also require change on the test cases relevant for those set of the processes. It would also require to verify and update the linked test cases as appropriate. Once done, the new set of test cases should be used for testing the final and interim work products. This change activities are to be performed by the team members only, so that maximum buy-in can be ensured, and the team members would also get an opportunity to prepare themselves to produce the new work products for passing through the new test cases.

In summary, there is room for reaping benefits by implementing a test driven development approach for a non-IT service work. However, TDD should not be taken as a replacement of classical way of setting up processes. There is no substitute of process design, setting up processes by thorough documentation of steps, determine and optimize the critical path and critical chain, encouraging the team members to perform work through the documented steps, and performing the self review through a checklist. A Test Driven Approach would help the entire service delivery to excel in quality, and to encourage the team to make the processes leaner by identifying the unwanted steps. Finally, even if it is part of Agile practices, it requires tailoring based on where it is to be applied.

Agile Intelligence: Leveraging Scrum for non-IT Services

My previous post on Scrum jotted down some of the key elements and thoughts for using this into the software development projects. While looking back and reflecting the same for non-IT services, the basics remain same at large. The simplicity of Scrum makes it extensible to a different area of work keeping its core same, and making necessary changes to it implementation the way new service would require. Again, I must emphasize that the service team or group considering to adopt Scrum should not be asked to change themselves nor their way of working. The implementation of Scrum needs tailoring instead, if so needed.

The core three questions of Scrum would stay same while implementing it for non-IT services as well:
1. What have you accomplished since the last scrum?
2. What are you going to accomplish till the next scrum?
3. What are the issues are you having on your way?

However, the response to these questions will vary here. As it is evident, that we are talking about the service, not really a project. So the spicy details of what's getting cooked should not be expected here. On a normal day, a team member is expected to respond something like this -
1. I have completed 140 transactions, all that were assigned to me.
2. I will complete all assigned transactions, upto 160 transactions in a given day.
3. Nothing to be mentioned.

In a room of 20, this set may be repeated multiple times, by multiple individuals, in a way that would question the relevance of the questions. However, the participation of all is a necessity here, inclusivity is the key to the excellence. So, the same answers should be allowed to get repeated. While the repeatation is underway, the scrum master should train his/her ears to pickup the relatively proactive responses, something like this one -
1. I have completed 140 transactions, all that were assigned to me. I had some free time, about an hour, and spent that in updating the review checklist.
2. I will complete all assigned transactions, upto 160 transactions in a given day, and will use my free time to complete the checklist updates.
3. The checklist updates are infrequent these days, can it be regularized?

Once such responses come out, the role of the scrum master needs to go beyond the point of asking three questions. The scrum master needs to encourage such activities as stated in #1, needs to push the work target stated in #2, if appropriate, and take cues of innovation ideas as mentioned in #3. A little more risky bet would be to ask for innovation ideas at the end of the scrum. All through, the scrum master should be patient and careful about not doling out any unrealistic plan, specifically, for #2 and #3. In a service oriented structure, the number of transactions per day cannot grow everyday, it would saturate to a level and any further upward push without planning and enablement would impair the overall service delivery structure. Similarly, all innovation ideas should not be converted to an improvement, it would not be feasible either. Each ideas need to be evaluated with a structured review, and upon qualification, should be implemented through a plan.

Finally, how much time should be devoted for scrum? For a mature process, it should not be more than 15 minutes per day. It's important to have it everyday with varying duration. For a stable situation, it should not be more than 15 minutes, but during any change implementation, more time needs to be allocated for sufficient discussion.

Agile Intelligence: Leveraging Agile Methods in non-IT Services

Traditionally, Agile methods were developed and applied for software development only. The foundation processes for a successful project following Agile methods were largely focusing on the interactions among programmers and managers grown out of programming environments. Nevertheless, the promise of changing specification during the course of SDLC (production period) and flexibility to demonstrate work-in-progress had its own influence, even within the community of stakeholders who were not generally related to software development work. Also, over the period of time, the IT managers started assuming the role of the BPO/KPO service delivery managers as their companies started taking such work offshore. As a result, many of the IT practices has started finding their relevance within IT Enabled Services as well.

The concept of agility was not new in the non-IT space though. In fact, Agile Manufacturing is a not-so-new terminology used to express a manufacturing process or setup that can react to the fast changing product specification in the fast changing competition landscape. Agile Manufacturing setup also allows the product marketers, product designers, and production personnel to share a common goal and a common set of information all through the product life cycle to efficiently handle the upstream and downstream activities.

In the area of IT Enabled Service delivery, Agile Programming methods are certainly not going to be applicable as-is. However, there are certain good practices, that can be adopted and applied to realize benefits. The practices that would be useful quickly and without tailoring are Scrum, Test Driven Development, Continuous Integration, and Backlog Management. As a caveat, I must submit, none of these are usable by its original names, nor by its original terms as dictated by the Agile proponents. Each of these practices are to be called with a relevant name and to be brought under relevant set of activities & steps. Moreover, it must be understood that these set of practitioners are not going to be programmers, techies, nerds, or of that sort. These practitioners will be come from a diverse set of backgrounds: by academic background, by experience, and by mindset. So, each of these four practices will require comparable level of revisions and modifications to fit the respective needs, their implementation risks are to be assessed with due care, and only after that should be brought in practice. We will look through each of these practices keeping this context in mind, in the following posts.