Articles
How to get the most from (SCRUM, etc.) Agile
Scroll down for more...
Scrum development is an excellent discipline for funded project initiatives: the customer is provided with frequent progress updates and allowed to modify the course of their initiative. But, what is the best method for handling defects and the many smaller enhancements being managed by your lights-on teams? Scrum may be too rigid and inflexible for a mature team that is just working down the fast-moving Backlog of minor requests and urgent issues of a platform. This is where Kanban may provide a better fit - keeping our development teams more fully engaged, empowered and self-regulating. Kanban, (which means, essentially, 'the sign you can see' - a plackard, sign or billboard) started as a scheduling system for lean and just-in-time (JIT) manufacturing that has been adapted for IT. There is no ScrumMaster on a Kanban team (but you still do Scrum!). There is no planning poker or Sprint retrospective. In fact, there is no "Sprint". Each member of the team pulls as much work as he/she can handle in a continuous flow. Development is self-regulating. Cycle time and Cumulative Flow analysis allow the team to identify bottlenecks to their efficiency and make adjustments to continuously improve. Ideally, Kanban encourages maximum through-put and offers the most efficient use of IT development resources who are not working on just one project. How does Kanban work?The basic parts of a Kanban workflow are familiar to those who know Scrum, but some of the steps and roles of Scrum are modified or removed. You need an active, prioritized Backlog of pending Stories and Defects. You need a Product Owner or business analyst who is responsible for defining the criteria for "done". The balance of the Kanban team are developers and testers, who work closely together - ideally dedicated resources - to pull as much work through the cycle as possible. Velocity, though, is changed entirely. In Kanban, the Stories can be estimated, but that is optional, and less important to team success. Each Story or defect is taken as a single unit of work - regardless of size. THIS is the concept often most difficult for Scrum teams to accept. Kanban challenges the team to maximize through-put over time regardless of Story size. Since the resource pool is assumed to be fixed, the rate of work is assumed to be fixed, as well. So, the goal is not simply to push more Stories, but rather to maximize the effectiveness of team skills and roles. Kanban asks the team, "Do we have the right people in the right roles for the type of work we do?" Each member of a Kanban team should be working at full capacity, over time, and if they need, say, another tester to achieve that efficiency, the Kanban team has the documentation to support that request. In Kanban, you are looking for the bottlenecks to your code development processes that cause your team to wait on a regular basis. Pull Kanban uses a pull model for work management. Each major phase of development - Analyze, Code, Test - pulls work when it has capacity. In other words, when a developer has more capacity, they look to the queue of Stories/defects that have been analyzed, and pull their work from the top of the prioritized queue. Over time, the team discovers and refines the Work-In-Progress (WIP) Limit for that phase of the cycle. When the WIP Limit is exceeded, an electronic Kanban board, such as in VersionOne will change color, notifying the team that there may be a problem. Visual cues are central to Kanban. In Kanban we "Visualize, Learn, Improve" as a repeatable cycle. The Kanban board is used by the team to see both status and flow and recognize and discuss issues. Like Scrum, Kanban will not work without communication. The Kanban board is a visual tool, but only works when it stimulates discussion. Where is UAT? The Kanban board is focused on the development phases that you can control (the Cycle). What is missing from a typical Kanban board are the steps around UAT and releasing to Production. Those phases still occur and must be tracked, but since they can be batched and may not affect the flow of individual Stories and defects, it is assumed that they are handled outside the Kanban cycle. Kanban for IT does not necessarily address every stage of your software life cycle, and assumes that you already have processes in place for creation of the Backlog and for promoting completed Stories to the production environments. Kanban is designed to focus every effort of your development team on pulling more work through the cycle, and any phase that by definition requires a wait-time is not part of the Kanban cycle. NOTE: if you use a tool like VersionOne, create a status for your Kanban work that shows it has passed QA testing, but can be used as input to a deployment queue, including UAT, build testing, etc. Add the expected release date to your Story card and manage the release process separately from your Kanban process. Just let your Kanban process feed the queue of enhancements and bug fixes that are candidates for UAT/Production, but handle the Promote-to-production process separately. Story quality Stories in a Kanban process do not go through quite the same rigor as is required for Scrum Stories. The more clarity is in the Story, the more efficient the process will be, but the law of diminishing returns is in effect here. Keep the machine flowing by asking your Product Owner (or BA) more questions and delivering a solution quickly, then watch the cycle time to see if your process bogs down in the QA phase. Stories should still be as small as possible, so that does not change. And, if your Stories are poorly written, and Dev and QA cannot determine what the Product Owner intended, you may want to push for more Story clarity. But, Kanban assumes that Story effort is a balancing act and that communication always works better than documentation. So whenever you have a question, just ask. Cycle-time Maximizing efficiency also translates to maximum through-put. In other words, as we work more efficiently and effectively, the time it takes to move a Story through from Analysis to Development to Acceptance Testing should decrease to a stable point. Once we know what that "cycle time" benchmark is, we can more easily spot when problems arise. Bottlenecks and poor communication should become more obvious as they lead to increased cycle times. This concept is so important to the principles of Kanban, that we only track improvements that affect every Story/defect. That is why the cycle is measured from start of Analysis to completion of the QA Story for most IT BAU teams. Only these steps apply to every item and are subject to the scrutiny that cycle time analysis can address. QA testing Once QA has begun there is a need to be able to return Stories to early stages when they fail testing, but this is not as simple as it might appear at first. If a fix can be completed in less than one day, simply leave the Story in QA and retest it as soon as it is fixed. If the Story defect is too large, then send it back to the appropriate Kanban step so it is obvious that development has more work to do. If the Story fails because there is a problem with the acceptance criteria, consider sending it back to the Analysis step. This will show that the Product Owner or BA must complete further refinements before the developer can resume coding. Emergencies Handling priority Stories, such as Production hot fixes is essential for a BAU / Lights On team. These can be handled by means of a separate swim lane on the Kanban board. The statuses are the same, but the "emergency" Story will indirectly affect the WIP limit of your regular prioritized Backlog. The Story moves through its own lane making it easier to track ahead of your other work - while work in your "normal" swim lanes is postponed until the Emergency is resolved. So, Do I Scrum?? Yes (in a sense)! The daily Scrum meeting is still an essential part of team coordination and morale in a Kanban environment. Use the same approach to Scrum that you use in the Project daily stand-up meeting: Ask everyone what they did since last meeting, what they are doing next, and what impediments they are facing. Keep the meeting short, but since you do NOT have a ScrumMaster, use this time to decide how to tackle your impediments. Also you should have a regularly scheduled (every 2 weeks?) Retrospective meeting to confirm what is going well and areas where you want to improve. Article SummaryKanban for IT is a concept of development where the team is trusted to work at their highest capacity by removing barriers to efficiency including unnecessary meetings, phase-gate oriented product grooming, and by using visual tools and aids to "see" the Story or defect flow - adjusting the team composition and roles as needed. There is a Scrum meeting, but no ScrumMaster, and all team members are equals. There is also a role for the Delivery/Project Manager in watching cycle time and cumulative flow for bottlenecks and blockages to support team reorganization and additions with metrics gathered over time. Work comes in continuously, and priorities can change by the hour, so everyone works together to keep impediments out of the backlog. Kanban efficiency is not gained overnight, but with the tools available and a committed team, this methodology can drive up customer satisfaction and make the best use of your development resources.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorPaul Berryman is a passionate application development leader who has earned the title of champion of Agile and DevOps methods and tools for enterprise development teams Archives
September 2014
Categories
All
(c) 2016 - Agile Down-to-Earth All rights reserved |