archive-nl.com » NL » I » IMPROVEMENT-SERVICES.NL

Total: 128

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Scrum Practices | ImprovemenT | Page 2
    given time period than can be done They schedule aggressively in an attempt to squeeze blood from stones under the pretext under pressure everything will become fluid this is a literal translation of a Dutch proverb mostly used by old school managers The underlying idea is that everybody will be kept busy but the actual result is that the target completion date cannot be met there s simply too much work to do There are serious negative repercussions from this short sighted interpretation of Parkinson s Law When a team is under heavy pressure to over deliver you can be sure that they will cut corners The first thing that will suffer the consequences is the quality of the work leading to massive technical debt Unfortunately the immense cost of non quality is still the best kept secret in our profession but that s another topic Moreover team members will react by padding their task estimates which only masks the problem and damages the team s ability to meet business needs The cure lies in following agile principles I believe that Parkinson s Law is related to certain psychological factors in the working environment especially lack of trust and respect Given the right circumstances the vast majority of people will create many opportunities to succeed and many situations to collaborate in order to get the job done Trust openness respect and courage are the core values of scrum leading to greater productivity and stakeholder satisfaction than blatant pressure As listed below scrum has many build in mechanisms which not only ignore Parkinson s Law but actually reverse it 1 Focus on tangible features In general Parkinson s Law is lurking when planning is based on stand alone tasks rather than features In scrum the driver for project planning is not a collection of tasks but a backlog with user stories prioritized by the business representative A focus on complete functions to be demoed by the team at the end of the sprint will discourage working on tasks that not contribute to the immediate business value of the deliverables 2 Time boxing with variable scope Within scrum the overall schedule is subdivided into a number of separate time boxes with each part having its own deliverables deadline and budget This approach provides frequent checkpoints and opportunities for corrective action you don t have to wait months for something to be completed only to find out that it s deficient or even obsolete With timeboxing the deadline is fixed but the scope may be reduced This focuses work on the most important tangible deliverables and inhibits the proliferation of less relevant tasks There is no time for extras or unnecessary complexity 3 Teams decides about the workload In Scrum the development team determines how much work can be accomplished in the upcoming sprint Even for unplanned absence it would be legitimate for the team to reduce its original commitment Persisting with the original amount of work despite reduced resources starts a vicious downward spiral of poor quality technical debt and team burn out Bottom line is that you don t force the team to accept more work than can be done The team will ensure that sustainable pace is tuned to available resources and capabilities Some managers see above may suspect that this is an opportunity for Parkinson s Law to kick in and that the team deliberately reserves more time than needed In all the years I m working with Scrum teams in a large variety of domains I have never seen this happen On the contrary especially beginning Scrum teams have the tendency to over commit 4 Teams can re estimate tasks to be done Once the tasks for a sprint are estimated Parkinson s Law may catch up You may argue that the work on the sprint backlog then expands to fill the time available However this is not the case due to the sometimes forgotten opportunity for the team to re estimate tasks yet to be done based on growing insight obtained by working on related tasks during the sprint Every stand up meeting provides the possibility to re adjust the remaining workload resulting in a faithful estimation of the effort needed to complete the current sprint In other words a realistic up to date burndown chart is the antidote to Parkinson s Law Posted in Scrum Practices Scrum under Siege Posted on August 23 2013 by erikphilippus More than 6 years ago I received my first assignment as a scrum coach Later on I have helped many organizations with the deployment of scrum For the most part the adoption of the agile mindset was quite successful but there were also less fortunate cases And of course I had to learn a few things myself too Common pitfalls Successful and lasting deployment of scrum is not easy However over the years I have identified a number of common pitfalls Most of these threats can be prevented with adequate preparation and sharp monitoring during the first sprints Based on my own experience I keep a close watch on the following issues during implementation of scrum Insufficient Elaborated User Stories Incomplete or sloppy user stories will knock off the success of scrum It cannot be stressed enough that the presence of a qualified and dedicated product owner is absolutely crucial I have learned this the hard way and nowadays I will ensure upfront that a qualified and motivated product owner is available at least for the current product life cycle The development team should never start with the sprint when the user stories are not clear However even with high quality user stories the ongoing feedback between de product owner and the development team remains essential to deliver the desired business value Scope Changes An essential element of scrum is focus on the agreed upon sprint goal to be realized by a self organizing team In order to prevent scope creep during a sprint everybody involved must respect the bi

    Original URL path: http://www.improvement-services.nl/blog/?cat=9&paged=2 (2015-12-05)
    Open archived version from archive


  • Architecture Spikes | ImprovemenT
    many spikes you throw into the fray uncertainty will remain a fact of life Reference Architecture The concept of the spike is often used in conjunction with an architectural issue Sometimes the architecture spike is referred to as Sprint 0 since the goal is to map out enough future bones to get going and to start working on creating the product backlog This corresponds with the exploration phase in an XP project encompassing the tentative user stories and initial architectural modeling To a certain extend this activity refers to a painter making preliminary studies of parts of the final picture Along the same line the architecture spike could be described as part of a reference architecture The idea of the first architecture spike is that whilst setting the initial skeleton and creating a single vision of how it might hang together not much is set in stone The goal of this architecture spike is to rough out subsystem boundaries transition points between software layers physical constraints etc Subsystems and other details are typically faked with stubs although is sometimes desirable to have enough of the software be real in order to actually do some preliminary performance and capacity planning assessment The architecture spike will often demonstrate that some parts of the architecture are not going to work illogical partitioning state held in the wrong place unbalanced data transfer wrong footprint etc This type of architecture spike has been compared with sight reading in music Agile Modeling I can t get away from the impression that this approach corresponds with a Small Design Up Front validated with experimental code The problem I have is that it seems to ignore modeling as a means to validate the architecture In my view it is a mistake to assume you always need working code for a proof of concept Of course models have their restrictions and pitfalls but I think it is nonsense to put modeling aside as being non agile As Scott Ambler illustrates with his concept of Agile Modeling there is no need to turn back the clock Quality Driven Architecting But what I think is a much more serious drawback of this type of architecture spike is the absence of an overall vision on crucial product qualities such as extendability and maintainability As I hope we have learned by now these quality requirements must be build into the system right from the start moreover they must be enforced by the architecture Especially when the software we re going to deliver is part of a portfolio of products it is vital to translate the product roadmap into a sound architectural foundation to guarantee the required product quality attributes for all members of the product family It is of course a laudable goal to focus on working software delivering value adding features to end users But we tend to forget that in general the majority of the total cost of software projects comes after initial fielding the system In most cases these costs

    Original URL path: http://www.improvement-services.nl/blog/?p=196 (2015-12-05)
    Open archived version from archive

  • Awakening the Agile Mindset | ImprovemenT
    could mean changing the hours for services renovating the building choosing new choir robes etc First order change involves any kind of change that changes an existing process from one form to another form but leaves the original purpose and standard in tact It is a change that is consistent with prevailing values and norms meets with general agreement and can be implemented using people s existing knowledge and skills Second order change Second order change is a disruptive change which challenges the existing culture and organizational paradigm including current expertise and competencies A change becomes second order when it requires people to learn new approaches or it conflicts with prevailing values and norms Second order changes require leaders to work far more deeply with people in the organization The eventual outcome of such a paradigm change is a transformed or renewed organization Nothing endures but change Heraclitis 535 BC 475 BC I believe that the migration to an agile way of working involves a paradigm shift It challenges the traditional belief that a project will be successful only when you re able to predict its progress and outcome right from the start Hence the agile mindset acknowledges change as a fact of life and provides skills that allow for adaptation rather than prediction So second order change is what we should mean when we talk about transformational change from a fixed mindset toward an agile mindset As discussed in a previous post an agile mind is not something you acquire I think it is best described as a rediscovery I might be addressing different ways to evoke the agile mind in future posts please find below two invitations to leave the beaten path by means of an appetizer Re evaluate critical feedback The litmus test of a changing mindset

    Original URL path: http://www.improvement-services.nl/blog/?p=171 (2015-12-05)
    Open archived version from archive

  • Agile & Architecting: Friends or Foes? | ImprovemenT
    software development project from sand to glass by using a serial lifecycle starting from a BDUF Big Design Up Front The siren song of the predictive approach is that it is based on a logical linear model and thus makes sense Instead of questioning the paradigm the methodology has been gradually expanded into a complicated long winded and sometimes even bureaucratic practice We ve been trying to create predictive requirements and communicate them perfectly up and down the hierarchy for over 30 years and failed year after year In most cases the predicted delivery date is the first day of the schedule slip In Hebrew there s a saying Tafasta Merube Lo Tafasta which means if you try to catch everything you will catch nothing In Lao Tzu s Tao Te Ching a similar saying is found Trying to control the future is like trying to take the master carpenter s place When you handle the master carpenter s tools chances are that you ll cut your hand In other words if you try to obtain perfect knowledge up front it will have the reverse effect Agile accepts change uncertainty and therefore unpredictability as the natural state This can be a quite uncomfortable thought for most traditional managers which is probably the reason why many organizations still value perceived predictability more than they value the ability to change direction quickly Ironically the agile approach gives you more predictability than those carefully planned up front project plans can provide The goal of an agile way of working is to promote collaboration the interaction of people on interpersonal cultural and structural levels To refute a common misunderstanding agile is not equivalent with quick Agility means adopting a posture that allows you to respond rapidly to changing market conditions and customer demands In a nutshell agile is adaptive instead of predictive Agile Architecting Many agilists regard agile to be the antithesis of the project manager s favoritism toward plan centric management They sometimes caricature the role of the architect as an inhabitant of an ivory tower surrounded by elaborated models and producing bulky architectural documentation that is subsequently assigned to the development team for realization But in circles of architects many agile methods are perceived as architecturally weak disconnected from the realities of delivering large systems in complex environments Although it is not surprising that the traditional architect is regarded by most agilists as a typical representative of the old paradigm in software engineering we must beware of throwing the child out with the bath water To dispose of architecture as the basis for the realization of sizeable and complicated software intensive systems is short sighted and would certainly move back the hands On the other hand the rise of the agile approach will inevitably force the traditional architecture community to reflect on a new interpretation of architecture To some extend the agilists are right most traditional architecture processes are heavy weight long winded and time consuming Agile architecting is an attempt to

    Original URL path: http://www.improvement-services.nl/blog/?p=161 (2015-12-05)
    Open archived version from archive

  • Can you acquire an Agile Mindset? | ImprovemenT
    reseeding the burned area Why am I telling this story Because I think it s a powerful metaphor for the adoption of an agile mindset Please allow me to explain Unknown Unloved When a person is challenged his or her intuitive response is to trust previous experience and to apply learnt behavior This attitude feels comfortable and is perceived as less dangerous than experimenting with new behavior Especially in insecure situations we have a natural tendency to apply proven technology Of course this is completely understandable from an evolutionary point of view But what happens when we re provoked to adopt the agile mindset Dominant learning style The agile mindset comprises competences that are related to right brain skills such as intuition creativity spontaneity etc In my view the agile mindset requires the two sides of the brain work in tandem to enable the owner to function as a well rounded personality effectively utilizing both verbal and nonverbal forms of intellect However as indicated in my previous post we live in a society that is influenced by the traditional dominance of the left brain modes of thought which includes analysis logic reasoning etc According to Nobel laureate Roger Sperry modern society discriminates against the right hemisphere As a consequence most people have a tendency to lean towards using the left brain while confronted with a new and challenging task Who is afraid of agile I know the lateralization of brain function must be interpreted with a grain of salt Nevertheless it seems to me that using the fixed mindset is for a lot of people the default mode of operation Hence the fixed mindset is often utilized while trying to migrate toward the agile mindset In my humble opinion that is a mission impossible Involving the fixed mindset in embracing

    Original URL path: http://www.improvement-services.nl/blog/?p=88 (2015-12-05)
    Open archived version from archive

  • First there was the Agile Mindset | ImprovemenT
    abilities are predetermined and invariable and that people who put a lot of effort into something are lacking the appropriate talent As a consequence their response to misfortune is helplesness and they will avoid challenges that may reveal their vulnerability or fallability The agile mindset at the other hand acknowledges the fact that people can change learn and grow Effort is the path to mastery and failure provides valuable information Therefore a person with an agile mindset will embrace challenges and will not respond to misfortune with learned helplessness but with resilience Conditioning Of course humans are not one dimensional stereotypes As with all labels the phrases fixed mindset or agile mindset have limited value and can even have a detrimental effect when used thoughtlessly Therefore I will narrow down this labelling just to myself So relax dear reader it has nothing to do with you Contemplating about mindsets I realized that in my life I ve tried to find a place of refuge at a fixed mindset quite often Why I guess I ve been conditioned that the fixed mindset contributes to my safety and that the agile mindset is perceived as dangerous Perhaps a bold statement but as a justification I would like to make a comparison between the two mindsets and the right and left sides of our brain Lateralization of brain functions According to the theory of left brain or right brain dominance each side of the brain controls to some extend different types of thinking For example a person who is left brained is often said to be more logical analytical and objective while a person who is right brained is assumed to be more intuitive thoughtful and subjective It is tempting to assume that a fixed mindset is correlated with functions found in the

    Original URL path: http://www.improvement-services.nl/blog/?p=52 (2015-12-05)
    Open archived version from archive

  • ImprovemenT › Lost Password
    ImprovemenT Please enter your username or email address You will receive a link to create a new password via email Username or E mail Log in Back to ImprovemenT

    Original URL path: http://www.improvement-services.nl/blog/wp-login.php?action=lostpassword (2015-12-05)
    Open archived version from archive

  • erikphilippus | ImprovemenT | Page 3
    of street signs is a classic example of a so called first order change Likewise first order change in a church could mean changing the hours for services renovating the building choosing new choir robes etc First order change involves any kind of change that changes an existing process from one form to another form but leaves the original purpose and standard in tact It is a change that is consistent with prevailing values and norms meets with general agreement and can be implemented using people s existing knowledge and skills Second order change Second order change is a disruptive change which challenges the existing culture and organizational paradigm including current expertise and competencies A change becomes second order when it requires people to learn new approaches or it conflicts with prevailing values and norms Second order changes require leaders to work far more deeply with people in the organization The eventual outcome of such a paradigm change is a transformed or renewed organization Nothing endures but change Heraclitis 535 BC 475 BC I believe that the migration to an agile way of working involves a paradigm shift It challenges the traditional belief that a project will be successful only when you re able to predict its progress and outcome right from the start Hence the agile mindset acknowledges change as a fact of life and provides skills that allow for adaptation rather than prediction So second order change is what we should mean when we talk about transformational change from a fixed mindset toward an agile mindset As discussed in a previous post an agile mind is not something you acquire I think it is best described as a rediscovery I might be addressing different ways to evoke the agile mind in future posts please find below two invitations to leave the beaten path by means of an appetizer Re evaluate critical feedback The litmus test of a changing mindset is the shift of the internal dialogue The fixed mindset creates an internal monologue that is focused on judging This means I m a loser This means I m a better person than they are While the agile mindset is indeed sensitive to positive and negative information it is attuned to the implications for learning and constructive action What can I learn from this How can I improve In other words a person with an agile mindset has fallen in love with feedback You are invited to perceive honest constructive feedback as a rare and precious gift especially when they are critical or painful Co create a place where is is safe to fail The agile mindset promotes learning at every opportunity through both success and failure However to be able to learn from failure we must feel safe enough to fail Hence we need to find ways of creating safety as a platform for the adoption of the agile mindset Within this context safety is multi faceted and shared responsibility Help to create safety for the developers the managers the organization as well as for the customer You are invited to develop a gentle attitude toward failure both by yourself and others Posted in Agile Mindset Agile Architecting Friends or Foes Posted on August 19 2013 by erikphilippus The emergence of agile methods has shaken the foundation of the ivory tower architecture A new breed of architects called Agile Architects is stepping up Architecture has always been controversial in the agile community Should design be done up front how much and when does architecture turn into BDUF the big bad wolf of agile programming The agilists are right to some extend most traditional architecture processes are heavy weight long winded and time consuming In circles of architects however agile methods are perceived as architecturally weak disconnected from the realities of delivering large multidisciplinary software intensive systems in complex environments Agile Architecting is an attempt to combine the best of both worlds The Essence of Agile What does it mean to be agile In general terms the phrase agile refers to a person being very limber and dexterous but also indicates a state of alertness and watchfulness At first sight this advanced interplay between body and mind sounds like a beneficial achievement for a yoga practitioner so what exactly does it mean in the context of software architecture Agile is commonly described by its characteristics such as iterative development frequent inspection and adaptation self organizing and cross functional teams etc Most of the agile methods are based on a set of core principles focussed on software delivery and collaboration The Agile Manifesto sums these up by stating that it values Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan These are merely the externally observable artifacts but this palette of descriptive terms does not really answer the question what is the essence of agile Looking at the inappropriate application of the honorary title agile to a wide range of practices that are in essence non agile there seems to be enough reason to elaborate upon the essence of the agile body of thought First of all it is of vital importance to understand that the agile approach is a reaction to a software development tradition that goes back three decades This tradition is rooted in the stubborn belief that predictability is a vital prerequisite for any industrial software development project This doesn t really come as a surprise given the prevailing post war engineering paradigm of a makable world In view of the high percentage of failed software development projects for many years the holy grail of software development was to gain full command of projects Only when a project was executed according to a predefined masterplan it would deliver what was specified at the start The deeply rooted rational for this line of thinking is the seductive assumption that if you cannot predict a process you cannot control it The connection between predictability and controllability is further intensified by the conviction that high perceived predictability is a protection against the stress of an imminent runaway project As a result we ve seen a long procession of methods and tools which all promise that they would be able to send the escaped ghost of unpredictability back in the bottle Of course some useful engineering practices have surfaced the last decades but the horizon of predictability of software projects has not been stretched significantly In fact the traditional approach has yielded a growing number of troubled or failed projects As demonstrated by the rise and fall of the widespread waterfall approach it is just not possible to fully command and control a sizeable software development project from sand to glass by using a serial lifecycle starting from a BDUF Big Design Up Front The siren song of the predictive approach is that it is based on a logical linear model and thus makes sense Instead of questioning the paradigm the methodology has been gradually expanded into a complicated long winded and sometimes even bureaucratic practice We ve been trying to create predictive requirements and communicate them perfectly up and down the hierarchy for over 30 years and failed year after year In most cases the predicted delivery date is the first day of the schedule slip In Hebrew there s a saying Tafasta Merube Lo Tafasta which means if you try to catch everything you will catch nothing In Lao Tzu s Tao Te Ching a similar saying is found Trying to control the future is like trying to take the master carpenter s place When you handle the master carpenter s tools chances are that you ll cut your hand In other words if you try to obtain perfect knowledge up front it will have the reverse effect Agile accepts change uncertainty and therefore unpredictability as the natural state This can be a quite uncomfortable thought for most traditional managers which is probably the reason why many organizations still value perceived predictability more than they value the ability to change direction quickly Ironically the agile approach gives you more predictability than those carefully planned up front project plans can provide The goal of an agile way of working is to promote collaboration the interaction of people on interpersonal cultural and structural levels To refute a common misunderstanding agile is not equivalent with quick Agility means adopting a posture that allows you to respond rapidly to changing market conditions and customer demands In a nutshell agile is adaptive instead of predictive Agile Architecting Many agilists regard agile to be the antithesis of the project manager s favoritism toward plan centric management They sometimes caricature the role of the architect as an inhabitant of an ivory tower surrounded by elaborated models and producing bulky architectural documentation that is subsequently assigned to the development team for realization But in circles of architects many agile methods are perceived as architecturally weak disconnected from the realities of delivering large systems in complex environments Although it is not surprising that the traditional architect is regarded by most agilists as a typical representative of the old paradigm in software engineering we must beware of throwing the child out with the bath water To dispose of architecture as the basis for the realization of sizeable and complicated software intensive systems is short sighted and would certainly move back the hands On the other hand the rise of the agile approach will inevitably force the traditional architecture community to reflect on a new interpretation of architecture To some extend the agilists are right most traditional architecture processes are heavy weight long winded and time consuming Agile architecting is an attempt to reshape the architecture process according to the new paradigm of system development aiming at an increased level of agility in architects themselves the architecture process the resulting architectures and delivered systems alike A beneficial side effect of agile is that it highlights the inherent conflict of the architect Dealing with perishable system requirements of imperceptible customers Conflicts with the managers who want to see the project delivered yesterday instead of tomorrow Daily struggles with developers who want to code now and think later Politically coloured trade off decisions As every seasoned architect knows there are many such conflicts some subtle that keep the stress up and the spirits low Agile architecting comprises all relevant and interrelated technical and non technical skills that help the architects to respond effectively to these notorious dilemmas Architecting is the art of addressing all relevant cross cutting concerns balancing the needs of the different stakeholders This remains fully applicable for agile architecting The daily practice of an agile architect will still include articulating the architectural vision conceptualizing architectural approaches creating models decompositions and interface specifications and validating the proposed architecture against quality requirements and assumptions The difference is in the level of responsiveness toward new unexpected information that becomes available during system development The agile architect has an adaptive attitude that is opposite to the traditional belief that requirements and design solutions should be frozen as early as possible The agility of the architecture itself is another cornerstone of agile architecting What is the distinguishing characteristic of an agile architecture To remove a source of misunderstanding in advance an agile architecture is not equivalent with a flexible architecture Although flexibility in itself can be a useful feature the pursuit to arrive at an overall flexible architecture is like chasing the pot of gold at the end of the rainbow In many cases demanding flexibility as a generic architectural requirement rather points at indecisiveness An agile architecture is based on a well considered choice with respect to the variability of the different parts of the intended system Some parts are explicitly modelled as members of an invariable and firm foundation while other parts are deliberately designed as being highly flexible or more precisely scalable configurable portable etc The agile architect will make the subdivision guided by a mixture of product technical roadmaps business considerations market trends and fingerspitzengefüll The focus of the agile spectrum of methods is on dealing with uncertainties during development and manufacturing based on the expectation that uncertainties related to ambiguities in customer requirements the viability of new technologies etc can be resolved before the system is shipped As we all know this is an unrealistic proposition in most cases In spite of that the focal point of the agile approach has been on process innovation rather than product innovation However there are good business reasons to enhance agility not only in the development process but also in the resulting system itself Agile systems are characterized by demonstrable reusability reconfigurability portability and scalability These quality attributes give systems the ability to change from one state or operating condition to another rapidly without large switching costs or increase in system complexity This is especially important for products that are long lived and require a significant upfront investment the expense is simply too large for extensive renovation or even building an entirely new system each time the requirements change after initial fielding of the system In conclusion the agile approach represents an exciting opportunity for architects to establish a streamlined and profitable development process for the realization of adaptable products based on an agile architecture Posted in Agile Architecting Dealing with unplanned work using Scrum Kanban Posted on August 19 2013 by erikphilippus Dealing with unplanned work represents a continuous challenge for most teams It is not unusual that during the sprint team members spent a considerable amount of their regular time on solving urgent unplanned problems This has a serious impact on the project planning Not only the sprint goal is under siege but also the overall project planning since the velocity of the team is becoming unstable inconsistent and unpredictable As a side effect during completion of regular tasks engineers may be tempted to take shortcuts in order to meet de deadline for the sprint goal The resulting sacrifice on quality may increase the technical debt which at the end will cause additional and substantial delays and rework Hence the challenge is to deal with urgent requests without jeopardizing the running sprints The way to effectively handle this situation is to organize each team as a scrumban team The scrum approach is applied for the planned incremental development of features while for a fast response to incoming problems a kanban way of working is followed The combination of scrum and kanban will minimize the hindrance of unplanned work thereby promoting a reliable release planning The goal of Scrum Kanban is to accomplish a swift response to urgent problem solving Following this approach it is possible to address incoming requests quickly normally within a single working day Kanban budget The trick is that the sprint backlog includes a buffer task for unplanned work called the Kanban budget When an unplanned urgent task is given to the team the hours spent to complete this task are subtracted from this budget Of course the size of the budget must be estimated in a realistic way taken into account the historic effort spent on unplanned work the phase of the current project expected rework from integration tests urgent defects still in backlog etc At the start of each sprint the actual size of the budget is determined by the scrum master and project leader product owner A single board with two sections The scrumban board is subdivided into two sections on top the scrum board the lower section is the kanban swim lane The tasks on the Sprint backlog column are determined at the sprint preparation and are fixed for the upcoming sprint This is in contrast with the Kanban section which is the portal for unforeseen tasks that must be addressed immediately by the team Filtering urgent requests The first column in the Kanban section represents the Analysis Filter phase which is the container and filter for incoming items A short analysis will provide more information with respect to the urgency priority and completeness of the incoming item This analysis will ensure that truly urgent matters are entering the Kanban pipeline and that during processing of the item the flow will not be hampered by foreseeable impediments Hence analysis may indicate that the item can be placed on the sprint backlog for the next sprint Any time during the sprint analysed tasks can be added to the Kanban backlog Within the team normally during the standup meeting an owner is assigned to a particular task and the corresponding task note the Kanban will traverse from left to right through a number of phases until completion under the supervision of the task owner assigned to the given task Upper limit for the effort spent on urgent items However there is a strict Kanban rule the Work in Progress number This is represented by the figures in the header of each column on the Kanban board The WIP is the upperlimit of the total number of items in a single phase column For example in the above figure the maximum number of tasks in the Kanban backlog is limited to 3 As a consequence when the Kanban backlog is fully occupied it is not allowed to add a new task first another task must be removed or moved to the next phase The same holds true for the other columns The WIP not only promotes a steady rhythm of tasks going from left to right it will also signal bottlenecks in the process very quickly The items on the Kanban backlog are ranked according to priority the most urgent problem is on top At any time the Kanban backlog is filled with the most urgent items This priority can be changed at any time as long as the task is not in progress Once a task is picked up the aim is to solve the problem without interruption as fast as feasible In case a new item arrives while the

    Original URL path: http://www.improvement-services.nl/blog/?author=1&paged=3 (2015-12-05)
    Open archived version from archive



  •