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".
  • Technical Leads and Self-Organization: Friends or Foes? | ImprovemenT
    I have witnessed several Scrum teams myself in which design issues and quality related matters were not really understood and subsequently ignored ultimately resulting in unmaintainable software Self organization cannot hide the fact that inexperienced team members may have an appalling lack of knowledge of basic design patterns and software engineering principles They don t know what they don t know The dispute is partly caused by a misunderstanding of the concept of self organization Let s take a look at the formal description Self organization is the ability of a disordered system to spontaneously arrange its components in a purposeful non random manner not necessarily directed or controlled by any agent or subsystem inside or outside of the system It is as if the system knows how to do its own thing Apart from many physical systems animal and human communities too display self organization Typical element of self organization in these systems is that in every group a member emerges as the leader who establishes order and rules that are followed by the other members of the group usually willingly The resulting organization is wholly decentralized over all the components of the system As such it is typically very robust and able to survive and self repair substantial perturbations In other words it is completely normal and also in line with the concept of self organization to have a leader in a group In every Scrum team a not appointed leader will emerge Hence the two viewpoints on the presence of a technical lead in a Scrum team are actually not so far from each other The pressing question is rather how should a technical leader fulfill his her role in the team The ideal candidate for such a natural leader is a person with senior knowledge and

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


  • V-Scrum: Two Religions on One Pillow | ImprovemenT
    things in the V model as well In general it is a good advise to look before you leap And if you have manufactured the same model doghouses for years please follow the good old waterfall approach Agile would not have a real benefit in that working environment I guess Agility and Feedback are two hands on a belly But if you are in a complex innovative environment with by a short time to market and rapidly changing market demands you may not survive without a more Agile approach One of the pillars of Agile is early and continuous feedback from real users In the V model the validation of the user requirements is the last step in the process As a consequence wrong interpretations or assumptions about requirements or design are to be discovered late or too late The enticements of the V model I assume that it is a no brainer that in an innovative environment many of the system s details only become known to us as we progress in the system s implementation Some of the things that we learn on the way simply invalidate our original design and we must be able to backtrack So why is it still so difficult to let go of the V model I guess the model is appealing for management because of the apparent predictability and clarity promised by the phased approach leading step by step to the agreed upon goal Neuroscience offers a plausible explanation for this stubborn preference Contrary to what we like to believe the neocortex plays a minor role in the determination of our behavior when we are encountered with unpredictability and risk It is the reptilian complex or crocodile brain that will validate a situation as safe or unsafe The instinctive reaction to unpredictability

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

  • Scrum under Siege | ImprovemenT
    to prevent scope creep during a sprint everybody involved must respect the bi directional agreement between the product owner and the development team at the start of a new sprint There is a strict procedure in scrum to handle inevitable scope changes which allow for swapping user stories but this is reserved for emergency situations only Interference Unplanned Work In many organizations it is more or less accepted that persons outside the development team are entitled to instruct individual engineers to stop with their current work in order to deal with an urgent task Especially sales and service are famous for throwing new items over the wall the last one even more urgent than the previous one This pattern of continuous interference has to stop otherwise scrum will never work In a previous post I have shared an approach to effectively deal with unplanned work in scrum Since it is an enormous source of waste there is no valid excuse to ignore the root cause of interference and unplanned work Change of Team Composition Especially in a smaller organization or in a junior scrum team only a few senior engineers will have essential domain knowledge at their disposal Hence it is inevitable that these engineers are often needed to solve urgent problems in the field Of course it is crucial for an organization to help customers and end users but the down side is that the depleted scrum team is unable to complete the sprint goal It is strongly advised to keep the core of the team intact as much as possible to allow for a stable velocity and reliable release planning Stretching the Definition of Done Sometimes teams over commit e g due to organizational pressure The only way to seemingly adhere to the sprint goal is to stretch the definition of done which in most cases means giving up on quality But even without this pressure the phrase potentially shippable product may give the undesirable side effect that the focus is on functional requirements only To be accepted the demonstration of a feature during sprint review is not always enough Especially when certain quality demands are crucial e g to prevent technical debt delivered features should be checked against these requirements as well The cost of non quality must always outweigh the temptation to earn of the maximum number of story points Therefore the definition of done must include all essential acceptance criteria including the relevant quality requirements Management support is a prerequisite Before accepting an assignment as a scrum coach I will always have an honest and straightforward conversation with senior management preferably the CEO With the above pitfalls in mind I need to make sure that managers understand the threats and their role and responsibility in neutralizing them After I have explained the rationale of scrum and the possibility for a win win situation when the agile mindset is adopted company wide there is commitment and support in most cases If not I will kindly decline

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

  • Dealing with unplanned work using Scrum + Kanban | ImprovemenT
    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 Kanban budget is depleted the scrum master and project leader product owner will make a tradeoff which tasks will have the highest priority On the other hand when there are no incoming urgent tasks the Kanban budget can be spent on completion of a new user story added to the Scrum backlog Promoting

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

  • May | 2015 | ImprovemenT
    Samurai this requires a considerable amount of perseverance courage and trust Starting small and taking it from there is in most cases not a problem soon the Scrum team will start to customize their way of working But for whatever reason the last step appears to be the most difficult and often the original set of rules is just replaced by a new set of rules To be honest I ve witnessed only a few teams or team members arriving at the last stage which has no ending by the way Perhaps a better description of Ri would be the awakening and realization of the Agile mindset as a transcendence of the fixed mindset The following dialogue in Alice in Wonderland perfectly expresses the whole idea Alice From the moment I fell down that rabbit hole I ve been told what I must do and who I must be I ve been shrunk stretched scratched and stuffed into a teapot I ve been accused of being Alice and of not being Alice but this is my dream I ll decide where it goes from here Bayard If you diverge from the path Alice I make the path It is an open secret that transformation impediments such as the growth of the team toward self empowerment and self organization are in most cases management level related Team level impediments if any will dominate in the short run and management level impediments dominate in the long run The organizational culture plays a crucial role and servant leadership is in my view a prerequisite to promote and facilitate the journey toward truly becoming Agile References 1 Martin Fowler The New Methodology www martinfowler com 2005 2 Alistair Cockburn Shu Ha Ri http alistair cockburn us Shu Ha Ri 2001 Posted in Agile Mindset Scrum Practices Tagged Scrum Practices Self Empowerment of Scrum Teams using Socratic Questioning Posted on May 2 2015 by erikphilippus Socratic questioning is a problem solving technique where a team is requested to think collectively about a case presented by one of the team members The participants in such an intervision workshop are not requested to bring solutions to the table but to ask relevant questions about the context fundamental concepts principles and theories with respect to the problem challenge or impediment Socratic questioning is a practical technique that can be adopted by Scrum teams in order to enhance the cohesion and collective problem solving capability and to make a next step toward becoming a highly effective self empowered team Socrates 470 399 BC was an enigmatic Greek philosopher who despite being considered one of the founders of Western philosophy left no writings at all Most of what we know about his life and work comes from the writings of his disciples Xenophon and Plato He lived during a period of transition in the Greek empire and after the Peloponnesian War he was tried convicted and executed for corrupting the young Socrates engaged in questioning his students in an unending search for truth He sought to get to the foundations of his students and colleagues views by asking a series of questions not only to draw individual answers but merely to encourage fundamental insight into the issue at hand The Socratic questioning is a useful tool to engage a team in a discussion while using probing questions to get at the heart of the subject matter thereby fostering critical thinking skills in the participants The downside of well meant but unsolicited advice While discussing a problem at work it is not uncommon that an advice or solution is given even before the essence of the problem is fully understood by the team members Especially when the problem relates to a listener s passion the discussion might be obscured by a hobby horse As a result confusion is looming This often well meant routine can block creativity and innovation and thus impede the discovery of unconventional solutions Especially in complex environments the specialists involved must have the intention and the strength to really understand mutual issues and to help each other to find the optimum sometimes interdisciplinary solution The Art of Asking Questions The Art of Asking Questions is thus an important skill which will enhance the thinking power within teams and organizations The Socratic questioning method is mostly based on self reflection exchange of well underlined arguments and a common investigation of the problem at hand It will make room for new and original ways of thinking thereby preventing fixation on unsatisfactory or suboptimal solutions A well conducted Socratic dialogue will connect people by building mutual understanding by promoting open communication The point of departure of the Socratic questioning is an open dialogue which doesn t include informal brainstorm rhetoric or convincing the other person It requires that participants are prepared to let go of their personal beliefs and participate in a group process to sincerely evaluate the prevailing opinions experiences values and standards The method assumes that everybody has hidden pragmatic knowledge with respect to the issue under investigation During Socratic intervision the mediator has the role of a midwife helping to give birth to what is already present within the group Socratic questioning what is it not Finding a valuable solution to a problem is of of course a bonus but not the prime objective of a Socratic questioning workshop Important goal is to foster mutual understanding by enhancing the communication temperature Traditionally our thinking is instrumental targeted at solving problems A Socratic dialogue tries to touch upon a more fundamental level in order to uncover the underlying reasoning values and drives It is an investigation based on emphatic listening not a debate The phrase yes but is replaced by yes and It is merely a free space activity judgements are suspended arguments and opinions are freely exchanged according to the principle Try to understand before you want to be understood Socratic intervision how does it work One participant is the protagonist and introduces a case This case

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

  • April | 2015 | ImprovemenT
    Agile and Scrum How can we ensure effective collaboration between our Scrum teams How can we make our retrospectives a lot more valuable How can we effectively deal with unplanned work and disruptions How can we make a realistic project and release planning How can we use cross functionality to the fullest How can we effectively apply self empowerment How can we answer your questions and challenges What is the essence of this training Real synergy is gained mainly by hands on experience together with your team mates The Advanced Scrum Training is a very practical training Each new approach will be connected to new behavior How After presenting some theory we will practice what has been learnt using relevant and startling work forms on the rugby field Every exercise is concluded with a retrospective humorous profound and always respectful Who are the trainers Erik Philippus of ImprovemenT and Wessel Hofman of Scrumit have joined forces and developed a challenging Scrum masterclass They form a unified team combining their experience and creativity They have bundled their broad experience craftsmanship and enthusiasm into a professional training with a tangible result Erik and Wessel are ready to provide you with an unforgettable training Follow up program After completion of the training both trainers will keep in touch with the participants At any time participants can discuss difficult practical questions with one of the trainers to ensure the maximum benefit of the training In addition every participant will be granted access to a private archive with useful background information on Agile Scrum and a subscription on a monthly newsletter with relevant information and useful tips Location The Advanced Scrum Training will be offered at a rugby club near you using the clubhouse and the rugby field The two day training 9u00 17u00 includes

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

  • February | 2015 | ImprovemenT
    Posted in Agile Mindset Scrum of Scrums toward Agility on Strategic Level Posted on February 14 2015 by erikphilippus An important technique for scaling Scrum to large project teams is the Scrum of Scrums meeting Each Scrum team designates one member as ambassador to participate in these meta level meetings with representatives from the other teams to create a shared plan to discover and resolve inter team dependencies overlaps and impediments This article extends this traditional view on the Scrum of Scrums meeting lifting it from the operational context to a more strategic level involving stakeholders and relevant adjacent disciplines within the organization The scheme depicted below represents the common view of the Scrum of Scrums meeting the Scrum teams presumably working on the same project get together at their standups and then send their their delegees to another standup where they get together and discuss the cross program risks on a daily basis They then have to get back together with their teams This type of Scrum of 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 the project and portfolio level this Scrum of Scrums team is able to make underlined trade off decisions which help to prioritize the items on the individual backlogs In addition members of the Scrum of Scrums team may discuss high level valuation ROI project level costing tracking metrics etc So the Scrum of Scrums meetings can incorporate part of the regular PMO activities Long before the dispute about scaling agile started I have experimented with the extended version of Scrum of Scrums For me it is self evident to install this Scrum of Scrums team in every medium size organization with let s say 4 to 8 Scrum teams working in parallel on a product portfolio So for me there was no need to immerse myself in comprehensive Agile scaling models such as SAFe or LeSS introduction of Scrum of Scrums extending the basic Agile Scrum principles and using common sense was enough More than once I have witnessed a fruitful organization transformation after installation of a strategic Scrum of Scrums team Posted in Agile Mindset Scrum Practices Agility and Resilience two sides of the same coin Posted on February 11 2015 by erikphilippus Survival of the fittest is sometimes confused with the right of the strongest But it is not the strongest of the species nor the most intelligent that survives It is the one that is most adaptable to change In the struggle for survival the agile win out at the expense of their rivals because they succeed in adapting themselves best to their ever changing environment This lifesaving property of agility is based on resilience Robust systems can resist short term change but they are incapable of adapting to a change that persists whereas resilient systems can recover form a perturbation and still retain their basic structure and behavior These systems thrive when other systems fail Hence agile systems are survival worthy because they are able to perform in a resilient manner So what exactly is resiliency What is Resilience Resilience is a term that has been used for a long time and in several different ways The term was introduced into the English language in the early 17th Century from the Latin verb resilire meaning to rebound or recoil It was first used in to describe a property of timber and to explain why some types of wood were able to accommodate sudden and severe loads without breaking Almost four decades later a measure called the modulus of resilience was developed as a means of assessing the ability of materials to withstand severe conditions used to compare the strength of materials utilized in the construction of the Royal Navy s fighting ships Many years later resilience was used to describe the ability of an ecosystem to absorb changes and still exist Resilience was contrasted with stability defined as the ability of a system to return to its equilibrium state after a temporary disturbance But it was also argued that resilience and stability were two important properties of ecological systems In the early 1970s resilience began to be used as a synonym for stress resistance in psychological studies of children It soon became a frequently used term in

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

  • January | 2015 | ImprovemenT
    initial product backlog the availability of relevant reference points for the estimation of the epics the familiarity of the team with the content of the project the presence of applicable expertise and experience etc Nevertheless according to the Scrum teams 500 storypoints is still a good guess Hence it is to be expected that unexpected stuff will pop up as in any project So after 4 sprints it doesn t come as a surprise that the status of our sample project is not all rosy As indicated by the project burndown chart sprint 3 has put a spanner in the works After 4 sprints there are still 350 storypoints to go and with an average velocity of 50 that would require another 7 sprints one more than anticipated Growing Insight Apart from the usual impediments such as technical setback sickness absence interference etc another plausible more positive explanation for the hiccup could be progressive insight During the course of the project the product backlog is continually refined so it is quite likely that team members come to the conclusion that some initial estimations are too optimistic For instance two epics that were initially estimated at 100 points are now re estimated at 150 points and that explains the bending of the curve In other words the scope of the overall project appears not to be 500 but 550 storypoints Whatever the cause the important thing here is that the project burn down provides an early signal that the project is perhaps in jeopardy So there is enough time to take appropriate measures such as negotiating with the customer to deliver 2 weeks later or to reduce the scope of the first release If a team struggles with a new unfamiliar technology perhaps the velocity can be increased by adding a specialist to the team for one or two sprints Rolling Wave Planning Using the instruments provided by the Scrum teams to maintain a project burndown chart will increase the transparency and the ability to effectively monitor and cope with unforeseeable factors early in the project This is an example of Rolling Wave Planning work to be done in the near term is based on high level assumptions while high level milestones are set As the project progresses the risks assumptions and milestones originally identified become more defined and reliable Especially in combination with a Variable Scope Contract the approach outlined in this article will prevent an unacceptable negative schedule variance Posted in Agile Mindset Scrum Practices Technical Leads and Self Organization Friends or Foes Posted on January 5 2015 by erikphilippus A popular phrase in Agile circles is that the best architectures requirements and designs emerge from self organizing teams Based on my own experience however I have some reservations about this statement How can we be so sure that self organization is the road leading to the most appropriate technical solution What is self organization anyway In general a self organizing team is defined as a team having full

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



  •