Tag Archives: Agile

Recensie: Agile zoals het bedoeld is

9789461263575-480x600Christine Karman laat met haar boek Agile zoals het bedoeld is – slagvaardig werken (zonder de bureaucratische rompslomp) zien dat het klakkeloos volgen van de Scrum guide zoals dat door puristen gepropageerd wordt kan ontaarden in bureaucratisch geneuzel. Aan de hand van haar eigen praktijkvoorbeelden krijgen we een beeld hoe zij agile werken ziet en toepast.

Het boek is onderverdeeld in elf korte hoofdstukjes en een zestal intermezzo’s waarin haar eigen ervaringen met agile werken zijn opgetekend. Verschillende aspecten van agile werken zoals het doel van agile werken, agile werken in de praktijk, haar vier principes van slagvaardig werken (stoppen met vergaderen, werk met een multidisciplinaire team, kies voor continuous delivery en maak het team de baas) en de fasering van een project komen aan bod. Ook de, m.i. belangrijkste, zachte kant van agile werken, lees agile werken is mensenwerk, de samenwerking in een team, communicatie en de taak van de manager passeren de revue.

Interessant is haar blik op niet-functionele eisen. Jammer alleen dat ze dit niet verder uitwerkt hoe je daar als agile team mee om kan gaan. Leg je deze niet-functionele eisen vast als acceptatiecriteria bij de user story, in de definition of done of maak je daar eigen stories van? Ook had ik graag gelezen wat haar ervaringen zijn met het voldoen compliance richtlijnen.

Het boekje leest vlot weg en de beschreven anti-patronen en eigen werkwijzen zoals de project startup hackathon bieden handvatten om het agile werken ook eens anders te proberen. Op een aantal momenten blijft het echter te oppervlakkig of wordt het probleem m.i. wat te makkelijk bij de Scrum werkwijze zelf neergelegd. Het is m.i. niet het Scrum ritueel zelf maar de wijze waarop het scrum ritueel binnen de organisatie door de medewerkers zelf wordt ingevuld waarom het geen toegevoegde waarde heeft. Dat ze een aversie tegen vergaderen heeft begrijp ik volkomen maar om alle vergaderingen uit te bannen en daarvoor de gesprekjes bij de koffieautomaat te gebruiken werkt lang niet altijd.

Haar beeld dat een team na iedere iteratie een minimum viable product (MVP) oplevert vind ik onjuist. Een MVP is een met de kleinst mogelijke inspanning te leveren oplossing om een hypothese te testen, om op basis daarvan te besluiten om wel/niet door te gaan. Wat ze beschrijft is een minimum marketable product (MMP).

Neemt niet weg dat het lezen van dit boekje je toch weer met je voeten op de grond zet en je laat nadenken wat je nu eigenlijk wilt bereiken met agile werken. Een volgens het boekje geïmplementeerde werkwijze of een meer wendbaar team of organisatie?

Bestellen: Agile zoals het bedoeld is

 

 

A Bird’s eye view on the agile forest article published on PM World Journal

The PM World Journal has published the latest version of my Bird’s eye view in the agile forest article. For sure there will updates in the coming months.

Some years ago, you could say “Scrum is agile” and ask “is agile Scrum?” Now we know there is much more flesh on the bones. At this moment there are more than fifty known and less known agile approaches, frameworks or methods available. To get a first impression of the different approaches, I try to bring some structure in the jungle to approaches, methods and frameworks. In Figure 1, I position the best-known agile approaches in a structure. The approaches, frameworks or methods are positioned within the ‘One-time programs / projects’ sections or within ‘Business as usual’ / indefinite, or both.Agile (50 shades of grey Clarity User Society, 191105) v1.0On the other side the approaches, frameworks or methods are clustered around team, product or programme and portfolio level. In the dark blue boxes in Figure 1 we see agile approaches that are only applicable in IT-focused organizations. All other approaches can be used within IT and non-IT-oriented organizations (light blue coloured). I haven’t mapped all the known approaches, frameworks and methods in this figure, and to be honest, I think there is a lot of duplication and probably commercial drivers play a role too to ‘develop’ the next kid on the block without added value in comparison with the existing approaches, frameworks or methods

Have a look for the latest version: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November

 

Heart of Agile: a missing tree in my bird’s eye view on the agile forest

heart of agileOn linkedIn I received a remark that the Heart of Agile was missing in my bird’s eye view (kudos to Milvio D.).

The Heart of Agile is a radically simpler approach to achieve outstanding outcomes. The founder is Dr. Alistair Cockburn, one of the Agile Manifesto co-authors.

Whatever your initiative, it involves changing the world just a little bit. The world, however, is remarkably resistant to interventions. The best ideas fail because of misunderstandings of how the world will react, or because of errors in implementation.

The Heart of Agile simplifies two decades of practice into four critical imperatives that amplify your effectiveness:

  • Collaborate (collaboration, trust): closely with others to generate and develop better starting ideas. Communicate often to smooth transitions.
  • Deliver (learning, income): small probes initially to learn how the world really works. Expand deliveries as you learn to predict and influence outcomes.
  • Improve (experiment, change): the direction of your ideas, their technical implementation, and your internal processes.
  • Reflect (insights, improvements): periodically, along the way. Think about what you’ve learned in your collaboration and from your deliveries.

See https://heartofagile.com for more detailed information.

In my bird’s eye view I positioned the Heart of Agile in the culture-targeted box.

Dia25See my blog for the complete Bird’s eye view on the agile forest article.

 

Agendashift, a new tree in the agile forest

logo_loresI thought I now covered all agile ways of working but I failed (again). I found a new one. This time it’s Agendashift. A 21st century modern engagement model (developed by Mike Burrows) that is needs-based, outcome-oriented, continuous and open to help organizations grow wholeheartedness.

The model Agendashift does:

  • Help the change agent structure their engagement with their client organisation and its staff
  • help the client organization engage its staff meaningfully in change-related work
  • Help the transforming parts of the organization engage constructively with the rest of the organization, so that both will thrive.

overview 16x10

Agendashift is based on five principles:

  1. Start with needs
  2. Agree on outcomes
  3. Keep the agenda for change visible
  4. Manage options, testing assumptions
  5. organize for clarity of intent, speed of decision-making, and alignment of impact (mutual accountability).

in Agendashift we see five activities:

  1. Discovery (where we would like to go: remember the future, 5W, True North, 15-minute FOTO, Clean language)
  2. Exploration (prospecting for opportunities: 15-minute FOTO, Clean language, Cynefin)
  3. Mapping (plans & priorities visualized: (User) Story mapping, reverse STATIK, impact mapping, X-matrix)
  4. Elaborating (framing actions, testing our thinking: hypothesis-based change, Lean Startup, A3, Cynefin)
  5. Operation (change as real work: Lean Startup, Kanban, Scrum).

On the Agendashift website you can find more details, set-ups of workshops, templates, books, et cetera.

In my bird’s eye view in the agile forest I added Agileshift in the Culture-targeted box.

Agile (50 shades of gray Clarity User Society, 191105) v1.0

See my bird’s eye view blog for the complete article.

AgilePM building block approach

logoHappy to see that the Agile Business Consortium copied one of my blogs on their site. In this article I propose a way to reduce the AgilePM documentation by using a building block approach.

Have a look at the Agile Business Consortium for the blog.

Project name (AgilePM building blocks 2019xxxx) v1.0For the complete article see my blog

Agile Performance Management: Measure what matters retrospective

Schermafdruk 2019-08-29 12.59.26Friday September 13, I was one of the 40 participants of the second Agile NXT Future Friday conference organized by Xebia in Hilversum, the Netherlands.

It was, similar as the first AGILE NXT Future Friday, perfectly organized, interesting topics, great food, and enough time to network. Four 1.5-hour lively sessions with 20 participants each to facilitate discussion and the final keynote speaker.

The first session Freedom by Restraint: Improving Autonomous Team Performance with boundaries by Riët Broekhuizen gave interesting insights in the four stages of autonomy (self-organizing – operational, self-developing – tactical/operational, self-directing – tactical/strategic and self-initiating – strategic). We started by defining (per table) autonomy. We followed the five steps to build an individual team framework. 9789462154780-480x600Describe for each team if the can decide on corporate identity, workplace, product and/or technology & methods. Look at the maturity of each team (entrepreneurship, resilience, purpose driven, creative, ownership and transparency) and build the individual team framework. Clear frameworks can dramatically improve autonomous team performance. Further reading: De High Performance Organisatie, deel 1 – Leiderschap, strategie, beleid & cultuur by Jan-Dirk den Breejen.

The second session Leadership agility, it’s time to remove the performance roadblocks by Rik de Groot started with a small table discussion regarding roadblocks. As a next step Rik discussed his top 10 of roadblocks and the rationale behind these roadblocks:

  • Conways law
  • A tenuous link between strategy and day-to-day behaviors
  • The idiosyncratic rater effect
  • Avoiding difficult conversations
  • Lack of hope
  • Lack of regular constructive meaningful feedback
  • No respect for individuals and the job they do
  • Missing human support
  • Lack of praise and acknowledgement
  • Value and behaviors mismatch

Based on a real-life case we discussed roadblocks and which micro interventions could make sense using a table with many micro behaviors (leading, supporting, sounding, change-oriented, collaborative, liberate and evaluate results).

The Responsive Organization

Further reading:

 

The third session Measure the impact of coaching – using methods from data science by Pieter Rijken was a tough one. He started with a view on soccer coaches. How is it possible that after 5 matches the first coaches are already fired and if you look at the results, they are not that different in comparison with the fired coach. If you take an intervention you need to compare against a baseline e.g. no coaching, no intervention and ask if the result is worse, similar or better. Perhaps the results are even worse, and no one notices, or the coaching works and the organization concludes it doesn’t. Rik explained that for scrum teams a simple measurement is the delivery rate (and you probably already have the data). If you plot this data, you find a Poisson distribution (under the assumption that the team is independent, and the delivery rate is constant). By using methods from data science, you can find jumps and, as a coach or scrum master, you could ask what happened, which intervention did I made that could justify the jump et cetera. Rik finished his session with some take a ways (e.g. be patient, beware of time delays in interventions, simple to use measures: delivery rate, support coaches in learning which interventions are effective, and which are not).

Further reading:

 

In the fourth session Agile Performance Management – next level by Theo Gerrits insights and practical knowledge how to optimize efficiency and measuring the value of agile was in the spotlights. What to measure was discussed in groups by using the following general steps:

  • What is value in your organization (value: customer, business, knowledge, risk, laws & regulations, public image)?
  • Understand your value chain (value stream mapping, organize around value streams, avoid “silo’s”
  • Which possibilities to monitor value creation?
  • Choose viable metrics. Keep it simple and seek balance (max 3-4 metrics)
  • Have an opinion and take action always (performance dialogs). If you are satisfied with the measurements: what should you do to maintain them. If you are not satisfied: what could be the (root) cause/reason, what solutions, choose and watch out what happens.9780321579362-480x600

Agile Performance Management is similar with regular meaningful conversations while responding to changes. Further reading: Succeeding With Agile: Software Development Using Scrum by Mike Cohn

9789026337512-480x600During the last session of the day, the Keynote, Maarten van der Weijden gave his personal story about his illness, his relationship with his father, the way towards his golden Olympic medal and the two swim eleven-cities tours to raise money for cancer charities. He spoke with passion about the value of metrics in delivering top performance, personal leadership and innovation. Further reading: Beter Maarten van der Weijden.

On the way out everybody received a tapeline as a token of appreciation for attending this session about Agile performance management: Measure what matters. This second future Friday was again a success with new insights, new thoughts and new contacts. I recommend this event when you want to take the next step in your Agile journey. The content is next level and you can bring it the next day into practice.

I am looking forward to the next AGILE NXT Future Friday, November 22, 2019.

 

Review: A Guide to Assurance of Agile Delivery

agile-coverThis guide (2017) is a result of the working group of the Association for Project Management’s Assurance Special Interest group (APM’s Assurance SIG).

The guide addresses assurance in relation to the areas that are considered the fundamental aspects (and key differences form traditional waterfall approach) of agile project management and assurance.

Like the other book I reviewed (Agile Governance and Audit), this book too focusses on temporary project organizations using an agile way of delivery (compare PRINCE2 Agile, AgilePM, DAD, PMI Agile where we have agile teams using e.g. Scrum) and not on organizations using e.g. SAFe, LeSS or Nexus. The four areas described, are (each in a separate chapter):

  • Approaching reviews in an agile way provides guidance on how to plan and conduct reviews. It starts with early engagement to obtain an understanding how the organization applies agile project management, what methodologies, (reporting) tools and approaches it employs. A Terms of Reference (ToR) focusing on the specifics of an agile way of working, the planning of the review and the the output.
  • Environments focus on the agile ways of working and the physical working environment. You get ten general health indicators to assess an agile team. Furthermore, you should take the time to familiarize yourself with the whitboards/walls the, preferably co-located, teams are using to understand their Kanbans.
  • Governance starts with an overview of generic governance topics that are applicable too for agile projects. On top of this you get some additional characteristics of agile projects that you, as an assessor, should keep in mind. E.g. the agile approach and terminology, the way the backlog is managed, the agile specific roles like an agile team, a product owner and a scrum master and their behaviors.
  • Risk management mechanisms are probably leaner than for traditional projects. Incremental and iterative delivery with regular client feedback reduces the chance to deliver the wrong product. An overview of specific risks for agile projects and how to cope with them is provided.

At the end of the book you get checklists for the four areas (approaching review, environments, governance and risk checklists) and references to further reading including links to National audit Office and HM Government documents and several agile related sites.

Conclusion: This easy to read book focusses, as stated, on temporary projects with an agile delivery team. I would say it’s a good starting point, and it helps to get an understanding how to perform an assessment on agile projects.

To order: A Guide to Assurance of Agile Delivery