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".
  • Blog Subscription Page | ImprovemenT
    ImprovemenT Agile Scrum Training and Implementation Search Main menu Skip to primary content Skip to secondary content Home Overview Services Contact Blog Subscription Page Your email Proudly powered by WordPress

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


  • AGILE SCRUM | Unknown Page | ImprovemenT BV
    Trainingen Archief Contact 404 Error HOUSTON WE HAVE A PROBLEM We can t seem to find what you re looking for Help us to find our way on your map Or please take us home Klanten Referenties Contact About Algemene

    Original URL path: http://www.improvement-services.nl/mobile/404.html (2015-12-05)
    Open archived version from archive

  • Professional Scrum Foundations: solide basis voor de Agile werkwijze
    slag wil met Scrum of die de bestaande werkwijze wil optimaliseren Blended learning concept voor drukbezette professionals De Agile Scrum Foundation training van ImprovemenT is een uniek Scrum trainings traject gebaseerd op het blended learning concept Dit betekent dat u na het volgen van een intensieve interactieve Scrum training van twee dagdelen zelf aan de slag gaat onder de supervisie van een ervaren en gekwalificeerde Agile Scrum trainer coach Follow up voor implementatie van de Scrum Methode Gedurende dit follow up traject kunt u bij de trainer terecht met vragen over het toepassen van de Scrum methode in uw eigen werkomgeving De Agile Scrum trainer van ImprovemenT heeft al gedurende vele jaren bij vele bedrijven het Agile gedachtengoed en de Scrum werkwijze ingevoerd dus hij kan terugvallen op een brede hands on ervaring met het implementeren van de Scrum methodiek in allerlei domeinen Zelfstudie traject voor officiële Scrum certificering Daarnaast omvat de follow up een begeleid zelfstudie traject waardoor u zich onder de hoede van de Agile Scrum trainer optimaal kunt voorbereiden op het officiele Professionele Scrum Master examen U ontvangt een zelfstudie gids stappenplan u krijgt toegang tot een gereserveerde pagina op de ImprovemenT website waar u al het

    Original URL path: http://www.improvement-services.nl/mobile/professional-scrum-foundations.html (2015-12-05)
    Open archived version from archive

  • Agile Scrum Foundation Trainingen | Content
    versus Fixed mindset Agile Skills Agile Manifesto Basic Agile Principles Overview Agile Methods Agile Deployment What is Agility Common Agile Practices Visual Management Time Boxed Activities Tangible Deliverables Agile Teams Prioritization Communication Temperature Scrum Basics Pillars of Scrum Transparancy Inspection Adaptation Requirements versus User Stories Attributes of User Stories Product Backlog prioritization grooming Overview Scrum Roles Product Owner Scrum Master Development Team Scrum Meetings Sprint Planning Meeting Scrum Meeting Sprint Review Meeting Retrospective Ideal Sprint Length Sprint Burndown Charts amp Project Burndown Chart Spike Iterations Nul Sprint Release Sprint Scrum Topics INVEST in high quality user stories Multiple product teams Unexpected high priority items Maintenance and Bug fixing Team Dynamics and Team Formation Agile Leadership and Agile Decision Making Prioritization of Requirements Measurement of User Satisfaction Agile Testing Definition of Done and Product Quality Role and Responsibility of higher Management Scrum Under Siege Implementation of multidisciplinary Scrum Scaling Scrum Scrum for non software projects Scrum and Kanban Lean Manufacturing Sources of Waste Difference between Agile and Lean Lean Principles Kanban and Kaizen What is Kanban Work in Progress Kanban Workflow Kanban Board Combination of Scrum and Kanban ScrumBan Dealing with high urgency tasks Dealing with structural unplanned work Agile Project

    Original URL path: http://www.improvement-services.nl/mobile/agile-scrum-foundation-training-content.html (2015-12-05)
    Open archived version from archive

  • In-House Scrum Training, Certificering en Implementatie Nederland
    voor iedereen die snel aan de slag wil met Agile Scrum Door middel van een pragmatische shorttrack training van twee dagdelen follow up zijn deelnemers snel vertrouwd met de Agile principes De nadruk ligt op de overdracht van praktijkervaring met ruime aandacht voor de vragen die leven omtrent de introductie implementatie en optimalisatie van de Agile Scrum werkwijze in uw eigen werkomgeving Uitgekiend blended learning concept voor een hoog rendement De combinatie van een intake gesprek shorttrack training van 2 dagdelen indien gewenst op een middag avond en een follow up traject garandeert een maximale Return on Investment De deelnemers ontvangen alle benodigde zelfstudie materialen en tijdens de voorbereiding voor het optionele Agile Scrum certificerings examen krijgen de teamleden persoonlijke begeleiding van de ervaren Scrum coach per email telefoon of Skype Gedurende de follow up kan het team terecht met vragen over de implementatie en optimalisatie van Agile Scrum Interactieve training van hoge kwaliteit die zich snel terugverdient De In House Scrum training kan worden georganiseerd voor groepen tussen de 6 en 18 personen Afhankelijk van het totaal aantal deelnemers bedragen de totale kosten voor het in company trainingstraject groep van 6 t m 10 personen 2 425 groep van

    Original URL path: http://www.improvement-services.nl/mobile/in-house-training.html (2015-12-05)
    Open archived version from archive

  • ImprovemenT | Agile Scrum Training and Implementation | Page 3
    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 Kanban

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

  • A Scrum Team as Dissipative Structure | ImprovemenT
    origine encountered an apparent contradiction According to the second law of thermodynamics any thermodynamic work process will show an increases in entropy due to dissipation of energy for instance in the form of frictional heat Hence every closed system will show an increasing amount of disorder unless external energy is supplied Escaping the trend toward chaos This would imply that the universe irreversibly moves to a situation of increasing chaos Nevertheless we see numerous processes in our environment leading to an increasing order which seems to contradict the law of increasing entropy Most striking example is the evolution from atoms to molecules amino acids proteins cells micro organisms etc This is undoubtedly a proces of increasing order against the stream of increasing disorder This paradox has puzzled scientists for a long time until Prigogine found the key open systems will not only exchange energy with the environment but are also capable of discharging an excess of entropy to their surrounding It is exactly this characteristic that enables systems to escape the trend of steadily increasing disorder There is an upper limit to the amount of entropy a system can dissipate however Any ordered system can become unstable when brought off balance by external influences When the internal chaos piles up there are two options the system will fall apart or it will reorganize itself in order to cope with the increased level of disorder Or as Prigogine would say the system escapes to a higher order It is important to note that it is chaos that enforces the spontaneous evolutionary step to a new and more stable system not a rational intervention from the outside Order and stability can arise spontaneously from disorder and chaos through coherence Random fluctuations cancel one another out Coherent fluctuations amplify one another into a stable dissipative structure Prigogine s theory of dissipative structures is not only a physical law it can also be applied to the behavior of organizations teams and individuals With this knowledge we are better equipped to understand and to value the self organization in teams On the Edge of Chaos The most important message that we should not be afraid of strong fluctuations or imminent chaos On the contrary these are exactly the circumstances that would flourish a team and put the team on the road to innovating and creative solutions Trying to shield a team in a well intentioned attempt to maintain an externally imposed equilibrium is not only futile but can even have a negative effect According to management professor Ralph Stacey managers must not strive to maintain a stable equilibrium but they better should create a certain amount of disorder in order to challenge teams to what he describes as complex thinking 3 Ken Schwaber one of the inventors of Scrum talks about about the pressure cooker of the deadline as a way to awake collaboration and creativity in a development team 4 Hence when the organization or a team is under great stress or balances on

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

  • Reflective Communication Scrum | ImprovemenT
    company culture one has to keep in mind that the different Scrum artefact are intertwined in a very clever way Removing a single element from Scrum like in RCS the Product Owner and the Product Backlog with User Stories will have desastreus consequences for the application of the method Apart from an underlined critique with respect to missing Scrum essentials the main question in this Dutch article is the rationale

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



  •