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".
  • Uncategorized | ImprovemenT
    how things are done around here Virtual Cattlegrids Metaphor for Agile Adoption Scrum of Scrums toward Agility on Strategic Level Agility and Resilience two sides of the same coin Predictability The Forbidden Fruit of Agile Technical Leads and Self Organization Friends or Foes V Scrum Two Religions on One Pillow Recent Comments erikphilippus on Self Empowerment of Scrum Teams using Socratic Questioning Scrum under Siege Revisited ImprovemenT on Scrum under

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


  • Virtual Cattlegrids: Metaphor for Agile Adoption | ImprovemenT
    for granted Well I ve found one or two after some deep see diving The Fixed Mindset versus the Agile Mindset This personal story is now part of my Agile Scrum Foundation training because I think it s a playful yet powerful way to challenge individuals with a fixed mindset A person with a strong fixed mindset believes that we are put on this earth with a toolbox of certain talents skills and abilities and that the content of this toolbox is more or less fixed Their favorite proverb is He who is born for a dime will never be worth a quarter This unfortunate belief has a far reaching impact An individual with a strong fixed mindset will hesitate to leave the well worn paths perhaps the unknown territory will appeal to a skill I don t possess And the default response to failure is learned helplessness I told you I cannot do this At the other side of the spectrum there is of course the agile mindset with a complete opposite attitude toward challenges and failure In contrast with someone with a fixed mindset a person with an agile mindset embrace challenges as a possibility to learn and to grow to explore and to discover a hidden talent a latent skill They show resilience by accepting the agile adagio Fail early Fail often Of course these mindsets is also are metaphoric we will have aspects of both and probably it also depend on the situation which mindset will dominate Nevertheless I believe that many of the obstacles on the path to an agile way of working in an organization are rooted in a prevailing fixed mindset of the employees involved At the same time I have my doubts whether they have ever seriously investigated the underlying conviction that they are indeed missing certain proficiencies Would it be possible that this fundamental belief is just a delusion like the virtual cattle grid and you can just walk over it to the other side Are the impediments to implement the agile principles just stripes painted on the road Anyway the company wide adoption of a truly agile mindset is a formidable challenge for many organizations Especially in a more traditional environment there are of course many complex and interwoven factors involved in the attempt to migrate to an agile way of working But perhaps the metaphor of the imaginary cattle grid will help us again to get a glimpse of a possible cause Can Habits be Inherited The obvious explanation for the effect of the virtual cattlegrid is that cattle acquire a disposition to avoid cattle grids through painful exposure to real grids or else they somehow pick it up from more experienced members of the herd Strangely enough this does not seem to be the case The response of several hundred head of cattle to painted grids has been investigated and it appears that naïve animals avoid them just as much as those previously exposed to real grids In

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

  • Scrum of Scrums: toward Agility on Strategic Level | ImprovemenT
    Scrums meeting has not a united positive image in Agile circles Some argue that teams push problems up a hierarchy for someone else to remove if that s how it s supposed to be in an Agile working environment fostering self empowerment To a certain degree I can agree with this point of view especially since in my opinion the meta Scrum meeting has much more to offer There is more to come According to my own experience the Scrum of Scrums meeting can be more than just a synchronization and alignment meeting on the operational level In addition to the resolution of inter team impediments this meeting offers a perfect opportunity to discuss and decide upon more strategic issues In the scheme depicted below the Scrum of Scrums teams is extended at will with for instance a marketing sales manager portfolio manager system integrator service deployment manager etc Their Product Backlog typically represents the more strategic stuff such as the technical commercial roadmap product portfolio system release plan etc In a large scale organization with many products it is to be expected that the Lead Product Owner joins the club guiding the aggregate view across the various product backlogs Important information radiators for this Scrum of Scrums team are the project burndown burnup charts and the overall release plan based on estimated epics and remaining work In most of the time it is overkill for this meta Scrum team to have a standup meeting every day bi weekly meetings are normally enough Bridging the team level product level and portfolio level I ve found that organizations that align their existing organizational structures with this extended version of the Scrum of Scrums team do a better job of release planning and delivery of business value Connecting the team level with

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

  • Agility and Resilience: two sides of the same coin | ImprovemenT
    their business models and strategies to meet the demands of ever changing business environments and to capitalize on market trends Resilience Engineering As illustrated by the above brief history it is about the absence of resilience increasing the possibility of adverse outcomes as well as materials or systems where resilient was present and where adverse outcomes could be avoided The discussion about resilience versus robustness gave rise to the introduction of the phrase Resilience Engineering in the early 2000s as an alternative or a complement to the conventional view of safety of situations systems and materials This has marked a principal deviation from traditional risk management approaches based on hindsight error tabulation and calculation of failure probabilities The Resilience Engineering Association was established to help organizations to create processes that are robust yet flexible to revise risk models and to use resources proactively in the face of disruptions and economic pressures Failure is the flip side of success Especially in the relationship with agility the view on failure in resilience engineering is noteworthy Failures do not stand for a breakdown or malfunctioning of normal system functions but rather point at the adaptations necessary to cope with the real world complexity Success has been ascribed to the ability of groups individuals and organisations to anticipate the changing shape of risk before damage occurs failure is simply the absence of that It follows that resilience is the system s ability to absorb disturbances before it changes the variables and processes that control behavior Resilient Performance in Adversity and Prosperity The focus of resilience engineering is thus resilient performance rather resilience as a property or quality A system is resilient if it can adjust its functioning prior to during or following events changes disturbances and opportunities and thereby sustain required operations under both expected and unexpected conditions It is important to note that in this definition of a resilient system the focus is on the ability to perform as needed under a variety of conditions rather than just the ability to recover from threats and stresses In other words a resilient system is able to respond appropriately to both disturbances and opportunities The emphasis on opportunities is a clear indication that resilience is more than just protective safety Resilience is about how systems perform while resisting absorbing and responding even reinventing if required in response to fast and or disruptive change that cannot be avoided not just about how they remain safe When a system cannot take advantage of opportunities it is not in a much better position than a system that is unable to respond to turbulences and threats certainly not in the long run As we have witnessed the last decade several traditional organizations have demonstrated resiliency by experiencing a severe life threatening set back but then redefine their business models and reinventing itself around its core values Adaptive Capacity where the twain shall meet Agility and resiliency are two sides of a single coin called adaptive capacity They are highly

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

  • Agility | ImprovemenT
    the early 2000s as an alternative or a complement to the conventional view of safety of situations systems and materials This has marked a principal deviation from traditional risk management approaches based on hindsight error tabulation and calculation of failure probabilities The Resilience Engineering Association was established to help organizations to create processes that are robust yet flexible to revise risk models and to use resources proactively in the face of disruptions and economic pressures Failure is the flip side of success Especially in the relationship with agility the view on failure in resilience engineering is noteworthy Failures do not stand for a breakdown or malfunctioning of normal system functions but rather point at the adaptations necessary to cope with the real world complexity Success has been ascribed to the ability of groups individuals and organisations to anticipate the changing shape of risk before damage occurs failure is simply the absence of that It follows that resilience is the system s ability to absorb disturbances before it changes the variables and processes that control behavior Resilient Performance in Adversity and Prosperity The focus of resilience engineering is thus resilient performance rather resilience as a property or quality A system is resilient if it can adjust its functioning prior to during or following events changes disturbances and opportunities and thereby sustain required operations under both expected and unexpected conditions It is important to note that in this definition of a resilient system the focus is on the ability to perform as needed under a variety of conditions rather than just the ability to recover from threats and stresses In other words a resilient system is able to respond appropriately to both disturbances and opportunities The emphasis on opportunities is a clear indication that resilience is more than just protective safety Resilience is about how systems perform while resisting absorbing and responding even reinventing if required in response to fast and or disruptive change that cannot be avoided not just about how they remain safe When a system cannot take advantage of opportunities it is not in a much better position than a system that is unable to respond to turbulences and threats certainly not in the long run As we have witnessed the last decade several traditional organizations have demonstrated resiliency by experiencing a severe life threatening set back but then redefine their business models and reinventing itself around its core values Adaptive Capacity where the twain shall meet Agility and resiliency are two sides of a single coin called adaptive capacity They are highly correlated concepts and both crucial for adapting to challenges and disturbances for individuals as well as for teams organizations or even industries In line with the agile body of thought individual and group resiliency is based on a strong sense of a valued identity common purpose and shared beliefs Like agility resiliency is also associated with creative prompt responses to minimize the impact of surprises and jolts that are not avoided When we define agility as

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

  • Resilience | ImprovemenT
    the early 2000s as an alternative or a complement to the conventional view of safety of situations systems and materials This has marked a principal deviation from traditional risk management approaches based on hindsight error tabulation and calculation of failure probabilities The Resilience Engineering Association was established to help organizations to create processes that are robust yet flexible to revise risk models and to use resources proactively in the face of disruptions and economic pressures Failure is the flip side of success Especially in the relationship with agility the view on failure in resilience engineering is noteworthy Failures do not stand for a breakdown or malfunctioning of normal system functions but rather point at the adaptations necessary to cope with the real world complexity Success has been ascribed to the ability of groups individuals and organisations to anticipate the changing shape of risk before damage occurs failure is simply the absence of that It follows that resilience is the system s ability to absorb disturbances before it changes the variables and processes that control behavior Resilient Performance in Adversity and Prosperity The focus of resilience engineering is thus resilient performance rather resilience as a property or quality A system is resilient if it can adjust its functioning prior to during or following events changes disturbances and opportunities and thereby sustain required operations under both expected and unexpected conditions It is important to note that in this definition of a resilient system the focus is on the ability to perform as needed under a variety of conditions rather than just the ability to recover from threats and stresses In other words a resilient system is able to respond appropriately to both disturbances and opportunities The emphasis on opportunities is a clear indication that resilience is more than just protective safety Resilience is about how systems perform while resisting absorbing and responding even reinventing if required in response to fast and or disruptive change that cannot be avoided not just about how they remain safe When a system cannot take advantage of opportunities it is not in a much better position than a system that is unable to respond to turbulences and threats certainly not in the long run As we have witnessed the last decade several traditional organizations have demonstrated resiliency by experiencing a severe life threatening set back but then redefine their business models and reinventing itself around its core values Adaptive Capacity where the twain shall meet Agility and resiliency are two sides of a single coin called adaptive capacity They are highly correlated concepts and both crucial for adapting to challenges and disturbances for individuals as well as for teams organizations or even industries In line with the agile body of thought individual and group resiliency is based on a strong sense of a valued identity common purpose and shared beliefs Like agility resiliency is also associated with creative prompt responses to minimize the impact of surprises and jolts that are not avoided When we define agility as

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

  • Predictability: The Forbidden Fruit of Agile? | ImprovemenT
    into smaller user stories when the Product Owner decides the time has come for implementation To facilitate the estimation of epics it is recommended to introduce a formal epic description containing additional information about the epic for better understanding of the business rationale and the scope of the epic I always encourage the use of visual aids such as concept maps high level collaboration diagrams or use cases to explain the epic at the correct level of abstraction It should be clear that estimation of epics is not for newbies it requires experienced and skilled engineers with a prolonged hands on experience with relative estimation When multiple Scrum teams are working on the same project release epics will be estimated by an estimation team with technical leads from all Scrum teams as described in previous post using a single project wide estimation scale Stable Velocity and the Cone of Uncertainty Another prerequisite for reliable release planning is a stable velocity of all the teams involved For at least 10 consecutive sprints the observed velocity should have been in the same order of magnitude The variation in velocity has a direct relationship with the reliability of the release planning so it doesn t make sense to do release planning when the velocity shows a large deviation Consequently the average velocity must be stable which in turn requires a stable mature and well balanced Scrum teams working closely together in regular iterations The core of any Scrum team must remain constant over a prolonged period of time frequently changing the team composition is not only detrimental for team spirit cross functionality and self organization but also killing for realistic release planning Project Burn down Chart So we have mature teams with a stable velocity and a product backlog filled with clearly defined and roughly estimated epics The following simplified example taken from my Scrum training material illustrates how to apply these achievements in release planning Suppose we have two Scrum teams lined up do to a project The initial version of the product backlog contains only themes and epics a set of features described at a high level of abstraction The teams have discussed and investigated these epics and they have estimated the relative size of all epics sums up to roughly 500 storypoins During the estimation session both teams are using the same scale also applied to determine their historic velocity The total capacity of both teams is 50 storypoints indicating that for the realization of 500 storypoints a total of 10 sprints is needed Since the velocity is measured for sprints of 2 weeks the forecasted duration of the project is 20 weeks Based on these parameters the following project burndown chart can be constructed Of course this exercise provides only a rough indication of the project s scope deliverable and lead time The uncertainty is determined heavily by the quality and volatility of the initial product backlog the availability of relevant reference points for the estimation of the epics

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

  • Team Estimation or Estimation Team? | ImprovemenT
    the estimations across Scrum teams anymore Obviously team A and team B would probably give different story point estimations for the same user story This is really a drawback for release planning in a multi team environment especially when more Scrum teams are working on the same Product Backlog Release planning would in that case benefit when there is one universal scale for the estimations otherwise the Product Owner will compare apples and oranges A Product Owner must have the flexibility to assign user stories to Scrum teams at random e g if collaboration of teams or re allocation of work is needed to meet the next deadline In other words when more teams work together to deliver functionality for the same release there is a need for a project wide estimation scale This would make the velocity of the individual Scrum teams the only parameter for release planning not the scale each Scrum team is using for the estimation of user stories Therefore I always advise to install a separate estimation team comprising representatives of each Scrum team plus a few experts to arrive at a realistic estimations of user stories requiring specific expertise or knowledge This estimation team will do all the estimation of user stories using a single relative scale during each estimation session Product Owners are able to convene an estimation meeting at any time when new user stories need to be estimated by the estimation team As a result the Scrum teams will never do estimations of user stories anymore During the Sprint Planning meeting the only thing a Scrum team will have do is to identify the tasks needed to realize the user story possibly providing an hour based estimation of the identified tasks In that case it is even beneficial that they don

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



  •