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.
Monday, May 17, 2010
Wednesday, May 12, 2010
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.
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.
Tuesday, May 11, 2010
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.
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.
Sunday, November 22, 2009
Agile Intelligence: On "Enterprise Scrum"
In his book Ken Schwaber described how an enterprise can adopt and implement scrum across all IT work. Size-wise, the 176 pages long book is divided into two parts: the general text, and appendixes. The appendixes describe some of the key concepts and nomenclature of the scrum, while the general text covers the key topics. The general text also illustrates some of the cases, where scrum implemented, and the kind of results / benefits accrued.
The good part of this book is it talks about some good theories of the classical project management and behaviors. As example, it talks about four stages for team performance: form, storm, norm, and perform. This one is nothing to do with Agile, it was a separate concept altogether. The good part of the book is that it adopted it.
The not so good part is some of the key messages. A few of those are highlighted below:
Scrum cannot be tailored for an organization, Organization needs to change itself: This illustrates the inflexibility of the case studies. If an organization needs to change itself for adopting scrum, while scrum stays unchanged, it practically makes the organization inflexible after scrum adoption. An inflexible organization is certainly going to take a downward dive on every aspect of the business.
The team needs to be self managed, self organized: This practically puts an end to the possibility of inducting junior team members. In every team there needs to be somebody who should be taking the lead role or coordinator role. The person needs to be somebody who can be looked up, and needs to be a role model for the junior developers while they are growing up. The book stays silent on this point.
Fire thy sales guy attitude: In a case study, the book found the solution in firing the sales guy who made some aggressive commitments to the client, and pushed developers harder for completion. A different case study of aggressive but successful sales guy would bring more relevance into it.
Developers should not be pressed: Throughout the book, the author emphasized not to press developers for producing more. It talks about giving the liberty of committing their own release dates, but not much have been mentioned on accountability, and aligning the dates with business reality. The book scares the readers on compromising on quality while speeding up the development, but surprisingly silent on measuring quality of the work product.
Derogating Offshore Work: The book does not support offshoring of work. Instead if asks for improving productivity at onshore. True, that productivity needs to be improved, but it’s yet to be proven that offshore work is less productive. In today’s world, when majority of the software development work is being done from offshore locations, it’s a bit surprising to see the author has missed out the success stories and data.
Overall, the book is not a recommended buy. But if you are an avid reader, go read it with open mind.
The original review comments was posted at Amazon.com.
The good part of this book is it talks about some good theories of the classical project management and behaviors. As example, it talks about four stages for team performance: form, storm, norm, and perform. This one is nothing to do with Agile, it was a separate concept altogether. The good part of the book is that it adopted it.
The not so good part is some of the key messages. A few of those are highlighted below:
Scrum cannot be tailored for an organization, Organization needs to change itself: This illustrates the inflexibility of the case studies. If an organization needs to change itself for adopting scrum, while scrum stays unchanged, it practically makes the organization inflexible after scrum adoption. An inflexible organization is certainly going to take a downward dive on every aspect of the business.
The team needs to be self managed, self organized: This practically puts an end to the possibility of inducting junior team members. In every team there needs to be somebody who should be taking the lead role or coordinator role. The person needs to be somebody who can be looked up, and needs to be a role model for the junior developers while they are growing up. The book stays silent on this point.
Fire thy sales guy attitude: In a case study, the book found the solution in firing the sales guy who made some aggressive commitments to the client, and pushed developers harder for completion. A different case study of aggressive but successful sales guy would bring more relevance into it.
Developers should not be pressed: Throughout the book, the author emphasized not to press developers for producing more. It talks about giving the liberty of committing their own release dates, but not much have been mentioned on accountability, and aligning the dates with business reality. The book scares the readers on compromising on quality while speeding up the development, but surprisingly silent on measuring quality of the work product.
Derogating Offshore Work: The book does not support offshoring of work. Instead if asks for improving productivity at onshore. True, that productivity needs to be improved, but it’s yet to be proven that offshore work is less productive. In today’s world, when majority of the software development work is being done from offshore locations, it’s a bit surprising to see the author has missed out the success stories and data.
Overall, the book is not a recommended buy. But if you are an avid reader, go read it with open mind.
The original review comments was posted at Amazon.com.
Saturday, July 11, 2009
Agile Intelligence: The Story of a Miserable Project
In one of my recent posts, I tried to tell a story of a successful project following Agile methods. Now it's time to flip the coin: let me try to tell a story of a miserable project. This was not a failed project though. The project eventually completed, with near 100% schedule variance and comparable effort variance, but with acceptable quality and conformance to all norms of closure. To give credit to myself (or to Agile), I don't have any story of failed project to tell.
It was a Sunday afternoon, when I was trying my eyes to believe what are being painted in front of me. It was a cozy meeting room, a room where I prefer to talk while standing, a room cozy enough to prevent me pacing bi-ways out of nervousness. With me, there sitting my boss, and two other developers. My boss summoned me to be there, he got a salvo or two from a senior executive of the client. The developers were trying to put forward the project situation, as-is. The first version was a little less than hunky-dory, and I learned that the team conducts a Scrum daily. An attempt to align the client's frustration with the project situation created the second version of the project situation, which was not only far away from being hunky-dory, but a lot scary as well. A critical phase in the software development life cycle got skipped: Testing. The developers were unfazed. The project called for 2 developers, so 2 developers started working. Developers never realized that they need to handover the codes on time to the testers. No body followed up with them either. As a result, the project directly moved to UAT after construction, that too when the construction was not complete. On the day one of UAT, client realized there was nothing for him to see, verify, and accept. He got furious.
Despite of having daily interactions with the client and developers, the project still went into red. It went into red, because there was a lack of appreciation for the SDLC phases. People loved Agile, tried to do some Agile stuff, without realizing that the fundamentals didn't change. Agile methodology does not cover SDLC, in certain aspects, it negates it. That prompts the team practising Agile, and bend for programming to miss out the big picture: the need of testing before releasing the product.
The story did not end here. Follow on meetings with the developers revealed none of them know how much to code and implement. There was no requirements document either. So developers were doing coding based on their understanding of the functionality which were not only inadequate, but also carried the risk of being misinterpreted. As a result, on the day two of UAT, the problem in hand was not just incompleteness of codes, but a total unawareness of the size of the remaining work.
The rest of the story was a familiar tale, an approach that have been followed from the stone age of software engineering. Some of the reputed fire fighters were deployed on the scene. They started working 20 hours a day everyday: coding, understanding requirements, testing, communicating with the client like a PM, and generating intense push-pull force between the buyer and supplier. After 2 weeks of a grueling endeavour, the project started becoming back on track. Client started seeing the work products getting delivered, client started seeing less errors in the delivered work products. The fire fighters started disbanding in search of another fire.
In short, just Agile does not work always. It requires a good understanding of the SDLC. In fact, all successful Agile practitioners today have got their foundations built through the classical SDLC process. Inherently, they practice the good stuff out of classical SDLC. An attempt to bring methods in the madness has always turned out to be effective in Agile projects, provided the teams carry an openness to accept good things from outside.
It was a Sunday afternoon, when I was trying my eyes to believe what are being painted in front of me. It was a cozy meeting room, a room where I prefer to talk while standing, a room cozy enough to prevent me pacing bi-ways out of nervousness. With me, there sitting my boss, and two other developers. My boss summoned me to be there, he got a salvo or two from a senior executive of the client. The developers were trying to put forward the project situation, as-is. The first version was a little less than hunky-dory, and I learned that the team conducts a Scrum daily. An attempt to align the client's frustration with the project situation created the second version of the project situation, which was not only far away from being hunky-dory, but a lot scary as well. A critical phase in the software development life cycle got skipped: Testing. The developers were unfazed. The project called for 2 developers, so 2 developers started working. Developers never realized that they need to handover the codes on time to the testers. No body followed up with them either. As a result, the project directly moved to UAT after construction, that too when the construction was not complete. On the day one of UAT, client realized there was nothing for him to see, verify, and accept. He got furious.
Despite of having daily interactions with the client and developers, the project still went into red. It went into red, because there was a lack of appreciation for the SDLC phases. People loved Agile, tried to do some Agile stuff, without realizing that the fundamentals didn't change. Agile methodology does not cover SDLC, in certain aspects, it negates it. That prompts the team practising Agile, and bend for programming to miss out the big picture: the need of testing before releasing the product.
The story did not end here. Follow on meetings with the developers revealed none of them know how much to code and implement. There was no requirements document either. So developers were doing coding based on their understanding of the functionality which were not only inadequate, but also carried the risk of being misinterpreted. As a result, on the day two of UAT, the problem in hand was not just incompleteness of codes, but a total unawareness of the size of the remaining work.
The rest of the story was a familiar tale, an approach that have been followed from the stone age of software engineering. Some of the reputed fire fighters were deployed on the scene. They started working 20 hours a day everyday: coding, understanding requirements, testing, communicating with the client like a PM, and generating intense push-pull force between the buyer and supplier. After 2 weeks of a grueling endeavour, the project started becoming back on track. Client started seeing the work products getting delivered, client started seeing less errors in the delivered work products. The fire fighters started disbanding in search of another fire.
In short, just Agile does not work always. It requires a good understanding of the SDLC. In fact, all successful Agile practitioners today have got their foundations built through the classical SDLC process. Inherently, they practice the good stuff out of classical SDLC. An attempt to bring methods in the madness has always turned out to be effective in Agile projects, provided the teams carry an openness to accept good things from outside.
Subscribe to:
Posts (Atom)