01/30/06
Filed under:
Musings,
Technology
Posted by:
Peter @ 8:03 pm
So you want to bring Agile into your software development process. And you are wondering where to start. That’s a tough question for each team does different things well. I always like to start anything new with teams by getting a baseline, that way we can show improvement and we can celebrate. We can also more easily identify the low hanging fruit. Just the process of getting the baseline creates some interesting dialogue amongst the team. Anyhow, I like to keep it simple, so I took the 27 rules and practices of extreme programming, put them in a spreadsheet and made a wag of the percentage of time I actually saw the rule or practice being implemented. For one of the companies I worked with they implemented three of the rules and practices over 90% of the time. These three were; they measured project velocity (in their own way, but they measured it), their unit testing was awesome and they had really good collective code ownership. The other rules and practices implementation varied from less than 90% all the way to non-existent. That’s ok, gives room for improvement
February 8th, 2006 at 11:04 pm Peter, this is an article I wrote about drafting a Corrective And Preventive Action System for Agile. Presently this area is not covered so I thought I would give it a try. __________________________________ This post is for the benefit of those who would like to obtain the benefits of a Corrective and Preventive Action (CAPA) system, but do not have the time or resources to dedicate to the initiative. This is particularly true with companies involved in “Agile Product Development”, where there must be a minimum of administration and all of the work must be performed by those actually responsible for the design and implementation, rather than a layer of quality assurance specialists. “Picking up the Slack” is a term that is often used in team management to describe the practice where the productive members compensate for the shortcomings of their peers. This provides a short-term improvement, but may lead to long-term problems. As an alternative, rather than concealing the shortcomings and missing opportunities for improvement, this approach embraces such opportunities. In this concept, SLACK is an acronym denoting: S-Summary, L-Lessons Learned, A-Actions, C-Commitments, K-Knowledge Base. After an event or process, it is important to capture the information. A Summary should be recorded within 48 hours of the event so that key details are not forgotten. Unlike a formal CAPA system, this Summary need not follow any structured format, but can be flexible to suit the needs and priorities of the organization. This is critical as we do not want to create a clutter of trivial details that may obscure the vital facts. From the Summary, the team can derive Lessons Learned. The Lessons will be those items most relevant to the people directly affected. In contrast, a CAPA system uses people separate from the process to allocate and determine the priorities of the situation. Also, while issues from a CAPA system are generally perceived as negative shortcomings, the Lessons Learned can be either negative or positive, allowing the team to not only fix its problems but rapidly adopt successful innovations as permanent practices. Each Lesson should engender an Action. As a result of a Lesson, something must be done. This bias for action over analysis is consistent with the Agile methodology, and ensures that there is always progress. However in order to deliver the desired Action, Commitments are necessary. By assigning the Action to an individual and setting a specific deadline, the Action and Commitment are powerful change drivers. The risk of any team is that the departure of key members will mean a reduction in collective knowledge. To mitigate that risk, the final step is to apply the improvement into the Knowledge Base. While a conventional CAPA system mandates the specific method and approach, this method applies flexibility and common sense. In an unstructured environment, Standard Procedures are infrequently updated or referenced, and make a poor repository for current knowledge. Different prompts or reminders (i.e. content of readme files in the directory, comments within software applications, updates to Intranet pages) that apply technology can be used to communicate and entrench the knowledge so that it remains within the team, no matter who stays or goes. SLACK (Summary-Lessons Learned-Actions-Commitments-Knowledge Base) is a linear model that can be formatted into a simple table or matrix. Below is an example of this application. Summary Lesson Learned Action Commitment Knowledge Base The product demonstration revealed software deficiencies. The customer was unimpressed and did not purchase. Demo software should be tested prior to demonstrations. Programmers and testers must test software prior to demo, and indicate usable release. Testers must create Demo Test Plan within 14 days. Demo Test Plan to be added to Test Library. Customer expectations should be known before presentations. Product Manager should perform needs analysis as requirements for demo. Product Manager should create a Needs Analysis prior to next trade show. Needs Analysis for Demo to be added to Sales Binder. An additional benefit of this approach (besides the logical workflow and simplicity), is the ability to monitor progress continually. Successive processes that have applied the correction, or implemented the innovation, can be tracked and confirmed (or refuted as the case may be) to obtain a longer-term benefit. As new Lessons are learned, the criticality of those lessons can be inserted into the existing S-L-A-C-K matrix (SLACK-tracking). To summarize, this is a method that is consistent with nimble project management approaches like Agile. It is simple enough to be applied by anyone on the team without the intervention or facilitation by a dedicated quality practitioner. It also provides coverage of this important area which is necessary for Continual Improvement.