Tag Archives: Agile

Organisation mindset

Many organizations are struggling with the transition to become more agile. I see organizations starting with a number of permanent agile teams and asking themselves after a while why the expected benefits are not there? Did they choose the wrong scaling agile framework? Maybe, maybe not, it probably has to do with the fact that the mindset of the organization is still the mindset of an organization in the traditional world.

I came across a website focussing on this mindset.

Alex Yakyma, SAFe fellow, and founder of ORG mindset created a model to help you with your transition towards more business agility (implementing Lean and Agile at scale) by focussing on the needed mindshift in your organisation. Without this mindshift, more business agility will be very difficult to achieve, adding more agile practices will not help.

ORG mindshift with their corresponding model will help you with tools and addoption paterns that address the mentality first and allow to build a successful Lean-Agile enterprise. Nowadays you need a mindset that embraces complexity (Lean-Agile mentality)  in stead of a mindset to cope with sequencial industrial systems. In the old world we see anti-patterns such as Outputs over Outcomes, obsession with predictability and metrics et cetera (Reductionist mentality).

Schermafdruk 2017-06-24 10.43.25If you go to the website (orgmindset.com) you get the model with icons (and hyperlinks to the details behind the icons, compare the SAFe big picture).

Exploit variability  explore economic opportunities: Variability entails high-payoff opportunities.

Minimize Constraints to collaboration: Change is inevitable, and the more flexible the structures that foster collaboration the easier the task. Avoid management’s compartmentalized thinking.

Build sustainable practices: Don’t over-emphasize early wins but focus on benefit-constraint, feedback loops, practice maps, embedded menthal models and shared cognition.

Align Mental Models: we never directly operate with a phenomenon, but through mental models.  As a change agent you have to identify problems with mental models in their organization and fix them (accuracy, different people, different models, blind spots).

Besides this model the website offers research, presentations and course information to become an Org Mindset Enterprise Coach (OMEC).

Conclusion: When you are starting or in the middle of a transition to become more agile this site is definitely worthwhile to visit and gives you some food for thought.

Nieuw Vakblad Projectmanagement

image001Genietend van de zon toch met je vakgebied bezig zijn, het kan. KWD resultaatmanagement heeft ons vakgenoten verwend met een nieuw tijdschrift Vakblad Projectmanagement. Op papier, en dat in het digitale tijdperk, en dat juich ik van harte toe. Ik blijf het namelijk lastig vinden om op mijn iPad een vakblad te lezen.

KWD Resultaatmanagement als uitgever is niet nieuw. De afgelopen jaren hebben zij al zes, zeer positief ontvangen, boekjes uitgebracht in de KWD reeks van en voor projectmanagers. Zie hiervoor de verschillende recensies op mijn blog.

Dit nieuwe vakblad heeft een vergelijkbare frisse layout en leest vlot weg. Dit nummer omvat een aantal artikelen waarin een agile aspect centraal staat. In het eerste artikel wordt ingezoomd op de vraag of of persoonlijkheidskenmerken van traditionele projectmanagers verschillen van die van agile projectmanagers. Een ander artikel onderzoekt of agile nu echt een succes is of niet? Ook wordt ook de opdrachtgever binnen de agile wereld belicht. Is hij de boosdoener achter niet-succesvolle agile projecten? De agile gerelateerde artikelen worden afgesloten met een inkijkje in het renovatie Velsertunnel project waarin agile gewerkt werd zonder dat ze het agile noemden.

Naast de agile gerichte artikelen een stuk over persoonlijk leiderschap en authenticiteit. Wat mij betreft cruciale eigenschappen voor alle projectmanagers en niet alleen binnen de museumwereld, zoals ook in een volgend artikel over de gemotiveerde projectmanager tot uitdrukking komt.

De artikelen worden afgewisseld met een aantal filosofische columns die je wederom aan het denken zetten!

Verder is in het blad een plek ingeruimd voor een afstudeerder. In dit geval over een literatuuronderzoek naar de invloed van agile werken op de motivatie van softwareontwikkelaars.

Conclusie: lof voor KWD Resultaatmanagement die het aandurft (ik heb begrepen dat ze in ieder geval de komende twee jaar in totaal acht nummers gaan maken) om een nieuw vakblad uit te brengen en dan ook nog een keer zonder reclame. Zoveel vakbladen zijn er niet in Nederland. En door een stevige redactieraad is ook de kwaliteit van de artikelen gewaarborgd zoals we in dit eerste nummer hebben kunnen constateren. Ik kijk uit naar nummer twee!

“Knowledge increases by sharing but not by saving.” – Kamari aka Lyrikal

Op de site van KWD Resultaatmanagement kan je je abonneren op dit blad.

Boek launch: Scaling agile in organisaties – Wegwijzer voor projectmanagers en agile leads

Tijdens het 20ste BPUG seminar vond ook de launch van mijn nieuwe boek plaats. Altijd leuk zo’n mijlpaal en ondertussen al vele enthousiaste reacties ontvangen. Ook hebben wij, Bert Hedeman, Hajati Wieferink en ik van de gelegenheid gebruik gemaakt om de nieuwe naam van onze organisatie wereldkundig te maken. Het is geen Hedeman Consulting meer maar HWP Consulting om daarmee de complementaire kennis en ervaringen van ons drieën te benadrukken.

20170613_133950

Boek preview

Scaling agile in organisaties gaat over organisaties die stappen willen zetten om teams meer autonomie te geven door besluitvorming decentraal neer te leggen en managementlagen en managers weg te halen om de teams zelforganiserend te laten optreden.

OMS_SCALING_AGILE_v6Business agility (oftewel de vraag: hoe wendbaar is je organisatie) is meer en meer onlosmakelijk verbonden met het bestaansrecht van organisaties. Het snel en accuraat kunnen inspelen op consument- of klantbehoeftes is van levensbelang. Iteratief en incrementeel ontwikkelen biedt betere oplossingen en waarborgen om producten fit-for-purpose te laten aansluiten bij de eisen van klanten; beter dan een watervalaanpak waarbij alle eisen al aan de start gedefinieerd worden en gedurende het ontwikkelproces in principe bevroren blijven.

Vele organisaties hebben stappen gezet om teams meer autonomie te geven door besluitvorming te decentraliseren. Ze hebben managementlagen en managers weggehaald om de teams zelforganiserend te laten optreden. In dit eerste deel komen enkele agile aanpakken van het eerste uur aan bod. Dit betreft agile aanpakken op teamniveau. Daarnaast beschrijf ik wat het betekent als er meerdere teams met elkaar moeten samenwerken.

Kijkend naar zo’n agile team, werkend met Scrum (met voorgeschreven rollen) of Kanban (zonder voorgeschreven rollen), komen de vragen op of er in zo’n constructie met een ontwikkelteam en Product Owner (typische Scrum-rol) nog wel sprake is van een project en of er dus nog wel plaats is voor een projectmanager. Een project is een tijdelijke multifunctionele organisatie, werkend met een start- en einddatum, opgezet om een uniek product of unieke dienst of release van een product of dienst op te leveren, rekening houdend met onzekerheid en onderbouwd door een businesscase, waarbij de juiste mensen voor het projectteam worden gezocht. Er zijn ondertussen verschillende cases bekend van organisaties die alle project- en programmamanagers hebben laten afvloeien en hiervoor in de plaats zijn gaan werken met Product Owners en Scrum Masters.

Zelf ben ik van mening dat het compleet afbouwen van alle project- en programmamanagers een brug te ver is. Wel geloof ik dat het aantal project- en programmamanagers bij veel organisaties sterk kan afnemen, maar er zullen situaties zijn waar toch een beroep op project- en/of programmamanagers gedaan moet worden. Wellicht worden ze dan anders genoemd, maar de rolinvulling zal veel gelijkenis vertonen met die van de project- of programmamanager. Ondertussen word ik gesterkt in dit idee door het feit dat ik organisaties in Nederland toch weer project- en/of programmamanagers zie aantrekken. Hierbij moet ik wel de kanttekening maken dat de opnieuw aangetrokken of overgebleven project- en programmamanagers veel vaker op de relatie zitten (stakeholdermanagement) en dat ze om zaken voor elkaar te krijgen invloed moeten uitoefenen zonder macht te kunnen hanteren.

Dit boek kan dus ook gebruikt worden door meer traditionele projectmanagers die zich een beeld willen vormen wat business agility gaat betekenen voor hun eigen rol. Blijven er traditionele of hybride projecten bestaan (projecten waarbij gebruikgemaakt wordt van zowel tijdelijke als permanente ontwikkelteams en waarbinnen gebruikgemaakt wordt van zowel agile als meer traditionele aanpakken) waarbinnen zij een projectmanagerrol kunnen blijven vervullen? Of is het zinvol dat zij zich binnen de lijnorganisatie meer gaan ontwikkelen in de richting van portfoliomanager, Agile Leader, Integration Manager, Roadmap Manager of Roadmanager, Release Train Engineer, Scrum Master, Agile Coach of Product Owner?

Ik ga in op verschillende agile frameworks die het op organisatiebrede schaal agile gaan werken ondersteunen. Ik schets eerst een handvat om de verschillende agile aanpakken mee te positioneren en vervolgens ga ik in detail in op een aantal van de meest gebruikte frameworks en geef ik een korte introductie van enkele minder gebruikte en minder bekende frameworks.

Ten slotte vergelijk ik verschillende frameworks en sluit ik af met een aantal, soms aan een specifiek framework gerelateerde, aanpakken om een agile framework te implementeren. Verder krijgt u mogelijke valkuilen waar u bij het implementeren van een agile aanpak rekening mee moet houden en antipatronen waar u tegenaan kunt lopen bij het gebruik van een agile framework.

BestellenScaling agile in organisaties

Book review: The Principles of Product Development Flow

51PdVCFcp3L._AC_US436_QL65_Don Reinertsen wrote the book The Principles of Product Development Flow – Second Generation Lean Product Development.

A very complete book that describes the underlying principles that create flow in product development processes. After reading this book I now understand why in the SAFe methodology and corresponding training material there are so many references to this book. The eight major areas focus on practical methods to:

  • improve economic decisions
  • Manage queues
  • Reduce Batch size
  • Apply WIP constraints
  • Accelerate feedback
  • Manage flows in the presence of variability
  • Decentralize control.

I find many concepts and methods that are present in the SAFe framework too. E.g. economic objectives, cost of delay, economic batch size based on transaction and holding costs, queues, CFD, little’s law, variability, batch size, synchronization, Weighted Shortest Job First (WSJF) and many, many more.

The book follows the already mentioned eight major areas and you get for each area a set of principles explaining that specific area. Each principle is explained in detail including examples. In total, you get 175 principles explained.

Conclusion: this book is definitely a must read. If you want to improve or create the flow in your product development process start with this book. If you are using SAFe this book gives you a lot of background and explanation behind specific methods and principles that are included in SAFe.

An introduction to Lean Product Development Flow given by Don Reinertsen at Adventures with Agile in London, September 2015.

To order: The Principles of Product Development Flow

Book review: The Agility Shift

9781629560700-480x600Pamela Meyer is the author of the book ‘The Agility Shift. Create Agile and Effective Leaders, Teams, and Organizations’. Not a book about an agile framework but a guide to help organisations and their leaders and employees to make a shift to the right in terms of Bob Marshall’s right shifting model to become more effective, to become more agile!

The book is divided in three parts. Part one covers the understanding and dynamics of the agility shift by explaining what and why, by weaving the relation web for agility and discovering the five dynamics of the agility shift. Part two explains what it means to make the agility shift at all levels of the system. Talking about the agile leader, the agile team and the agile organisation. Part three focusses on putting agility into work. How can you shift to agile learning and development and recruiting, reinforcing, recognizing and retaining your agile talent?

Agility shift can be summarized by the three C’s: Agility Competence, Agility Capacity and Agility Confidence and is first and foremost a shift in mind-set. A shift from the false comfort of “a plan” to achieving a state of readiness to find the opportunity in the unexpected. To build this readiness you can make use of your own Relational Web.

Dia3

To download the QRC The Relational Web: The agility shift web

Becoming an agile leader asks for a leadership mind-set for agility, whole-person agility and learning agility. To build a team make use of lessons from improvement, high-stake and development teams: work with the same understanding of the givens, agree to the givens, practice gift giving, practice finding the game, provide opportunities for interaction, make communication and coordination expectations explicit, expect role elasticity and learning agility, develop resource awareness, practice rapid prototyping: fail faster, learn quicker, work at a sustainable pace and capacity, create an agile manifesto for your team.

When agile leadership and the first teams are in place you can start co-creating the agile organisation by weaving the organisational relational web (create groups that foster employee camaraderie, maximize your relational web potential, and improve the proximity between members of your relational web), Structuring for the agility shift (create opportunities to identify the bare spots, get input on barriers and enablers, and resist the urge to formalize) and las but not least expand engagement to build capacity for decision making (empowerment) and converge planning and action to maximize your organizational agility.

The last part explains what the shift means for agile learning and development and recruiting, reinforcing, recognizing, and retaining your agile talent. You get an overview of competencies, skills and practices and performance indicators as well as a helping aid for recruiting for agility with sample conversation topics/scenarios and questions and tips to listen and look for specific performance indicators.

Conclusion: No matter what agile framework you are using, this book will bring you above the level of framework techniques and gives you helpful insights to become more agile. A must read for agile leads!

To buy: The Agility Shift

Book review: The DevOps Handbook

9781942788003-200x300Gene Kim, Jez Humble, Patrick Debois and John Willis are the authors of the book The DevOps Handbook. how to create world-class agility, reliability, & security in technology organizations. If you look at the cover you see some similarities with The Phoenix Project. A novel about IT, DevOps, and helping your business win. And that is not a coincidence because Gene Kim is one of the co-authors of this book too.

Where The Phoenix Project is a business novel explaining the journey to set up a DevOps team, this book gives you the theoretical background, and the tools to build and use the DevOps philosophy by integrating product management, development, QA, IT operations, and information security to elevate your company.

The book is divided into four blocks: The first block (part I) introduces the three ways: The principles of flow, feedback and continual learning and experimentation. The second block (part II) explains where to start a DevOps movement in your organization. The third block (parts III-V) describes the technical practices of the three ways. The last block (part VI) discusses the technological practices of integrating information security, change management, and compliance.

In part II we see what it means to select the value streams with the most sympathetic and innovative groups to start with the DevOps transformation, analyse those value streams by creating a value stream map, and design the organization (functional, matrix or market oriented), fund services and products and not projects and create loosely-coupled architecture to dramatically improve the outcomes.

The first way describes the architecture and principles that enable the fast flow of work from left to right, from Dev to Ops to deliver quickly and safely, value to customers. Start with a single repository of truth for the entire system, make infrastructure easier to rebuild than to repair, enable fast and reliable continuous integration and automated testing and start with low-risk releases. Include running in production-like environments in your DoD.

The second way addresses the reciprocal fast and constant feedback from right to left by implementing feedback loops and use shared goals spanning Dev and Ops to improve the health of the entire value stream. The authors provide insights in telemetry from processes, behaviour and production issues, audit issues and security breaches that enables seeing and solving problems. Next we see, how we can integrate user research and feedback, peer reviews and pair programming and what it means when integrating hypothesis-driven development and A/B testing into our daily work?

The third way helps to create a culture of learning and experimentation. What can you learn from incidents, and how others can learn from your own learning by creating repositories and sharing learnings. How can you enable and inject learning into daily work by establishing a learning culture, have post-mortem meetings after accidents occur and communicate them, decreasing incident tolerances and organize game days to rehearse failures? And make sure you capture organizational knowledge by using e.g. chat rooms and chat bots.

In the last part, the three ways are extended by using them to achieve information security goals by making security a part of everyone’s job, by integrating preventive controls into a repository, by integrating security with the deployment pipeline, and integrating deployment activities with the change approval processes and reducing reliance on separating of duty.

Conclusion

If you want to start a DevOps movement, start with The Phoenix Project to make yourself enthusiastic about DevOps and continue with this book to get the real technical practices to make your DevOps a success. When buying this book, you will get a unique one-time access code to the DevOps X-ray individual assessment to benchmark your own performance against industry-wide data.

To buy: The DevOps Handbook

Agile Antipattern card deck

2016-10-29-11-16-27I received a deck of Agile Antipattern cards. An agile antipattern looks innocent but the can have a big impact on the agile initiative or even on the whole agile transformation. These cards can help you to spur conversation and fight dysfunction. You can use these cards as a retrospective tool. The team can select the antipatterns they ran into this sprint. After discussion the team can select the top antipattern to address in the next sprint. The cards can also be used to accommodate the debate during agile transformations.

The deck contains 24 Agile Antipattern cards.

At this moment the development of a new book is in progress: ‘Agile Antipatterns: The Scrum Master’s Guide to Traps, Tripwires, and Treachery’ By Adam Weisbart. You can download a first chapter on agileantipatterns.com.

This chapter, ‘The invisible gun’, elaborates on the the agile antipattern “My boss is on my team”.