Tag Archives: QRC

A birds eye view on the agile frameworks forest

Some years ago, you could say “Scrum is agile” and ask “is agile Scrum?” Now we know there is more flesh on the bones. At this moment there are more than fifty known and less known agile frameworks available. To get a first impression of the different frameworks, I try to bring some structure in the jungle to methods and frameworks. In Figure 1, I position the best-known agile frameworks in a structure. The frameworks are positioned within the ‘One-time programs / projects’ sections or within ‘Business as usual’ / indefinite, or both.

Grasp session (Scaling Agile T-Mobile, 2019 Q1) v0.1Fig. 1 Overview agile framework[1]

On the other side the frameworks are clustered around team, product or programme and portfolio level. In the dark blue boxes in Figure 1 we see agile frameworks that are only applicable in IT-focused organizations. All other frameworks can be used within IT and non-IT-oriented organizations (light blue coloured). I haven’t mapped all the known frameworks 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 frameworks.

The team level, including Scrum and Kanban, is applicable in both IT-oriented and non-IT-oriented products and services development and operations. The engineering level focuses specifically on IT-oriented product development. The one-time, temporary projects and programme frameworks are suitable for both IT and non-IT. The permanent umbrella frameworks (both product-targeted and team-targeted) focus specifically on IT and product development and the business-targeted frameworks help organisations to increase their agility.

Teamlevel

If we start at the team level in Figure 1, then we see of course Scrum as described by Ken Schwaber and Jeff Sutherland in their Scrum Guide. In addition, you will see frameworks such as Kanban (as described in the Kanban Guide for Scrum Teams), Scrumban and DevOps or BusDevOps. The team level can be used both within the IT environment and the non-IT environment. At this team level we can position the following IT frameworks too: Crystal family (developed by Alistair Cockburn with Crystal Clear and Crystal Yellow, Orange, Orange Web, Red, Maroon, Diamond, and Sapphire), Rapid Application Development (RAD developed by James Martin), Adaptive Software Development (ASD by Jim Highsmith, Sam Bayer), Agile Unified Process (AUP) as a simplified version of Rational Unified Process (RUP) which was superseded by Disciplined Agile Development (DAD) which was superseded by Disciplined Agile (DA). If you want to deliver quality as a team within the IT world, only following these frameworks is not enough. To improve quality and minimize technical debt (e.g., inefficient code due to many iterative adjustments), you could make use of eXtreme Programming (XP, developed by Kent Beck, Ward Cunningham, and Rom Jeffries) with Pair Programming, Acceptance Test Driven Development (ATDD), Test Driven Development (TDD), Behaviour Driven Development (BDD), Feature Driven Development (FDD), Example Driven development (EDD), User Experience (UX) Design, Continuous Integration and Continuous Deployment. AgileBA delivers the techniques to perform business analysis.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles, that can be applied on an (agile) software development project. There are several core practices: documentation, document continuously, document late, executable specifications, single-source information, active stakeholder participation, architecture envisioning, inclusive tools, iteration modeling, just barely good enough (JBGE), look-ahead modeling, model storming, multiple models, prioritized requirements, requirements envisioning.

 Scrum or Kanban?

When teams start working with Agile, Scrum is often chosen. An obvious choice, but the question is whether this is always the right choice. In a Roman Pichler[2] blog the link was made with the life phase of a product. During the first phase of a commercial product lifecycle, in which the commercial product is finally put on the market for the first time, the uncertainty is high, and the focus is on on-time delivery of the first market-ready product. A deadline has been set and that date must be met. During this phase, the focus of the entire team is on delivering a commercially marketable product. This development is perfect for Scrum with its iterative approach, being able to deal with uncertainty and working together on the result (the commercial product). Optionally, a second launch can take place with a next set of important functionalities, so that eventually a mature product is put on the market. During the further course of the product lifecycle, we see the amount of uncertainty and requested changes decrease. At this moment you can make good use of Kanban. In a continuous flow, User Stories can be picked up, developed and deployed one by one by individual team members.

If one looks at the often difficult transfer to production environments, the time-to-market can be shortened by properly arranging the transfer and reducing the number of transfer errors when development and production teams are merged, and the integration testing and deployment are automated (Continuous Integration and Continuous Deployment CI/CD). In this way a DevOps team is created.

Scrumban is the combination of Scrum and Kanban. In the first instance it was intended as a transitional model to switch from Scrum to Kanban and let the team experience Lean- and Kanban concepts. Nowadays it is an approach in which the team has chosen to work according to Scrum with Sprints, but to use the Kanban system to continually view and improve its working method to optimize the flow of units of work (e.g. User Stories).

Scaling up towards product- or program level

In order to be able to use an agile way of working in an organization of some size, just having individual agile teams is not enough. The agile way of working needs to be scaled up and where possible the overarching alignment needs to be institutionalized.

To institutionalize coordination, management of dependencies and integration between the different permanent agile teams within ‘the run-the-business’ / ‘business-as-usual’ side there are various frameworks available, including:

  • Nexus, as described in The Nexus Guide, is a framework for developing product or software development initiatives with three to nine Scrum Teams, in Sprints of up to thirty days. Nexus is the answer of Ken Schwaber, one of the founding fathers of Scrum, to the scalability of Scrum. It requires more than just the will and the agile behaviour of the different Scrum Teams to work together to deliver an integrated product. Nexus is based and builds on Scrum and the rules and roles formulated in The Scrum Guide. We can position Nexus over the team and program levels of SAFe, but it does not offer provisions on portfolio level.
  • Scrum at Scale (S@S, developed by Jeff Sutherland and Alex Brown) is a modular framework. The starting point at S@S is that an all-encompassing one-size-fits-all framework is not possible, but that every time we have to look at scaling of the underlying Scrum principles. The framework can be tailored for your own organization by adding the needed S@S modules. S@S builds on the well-known Scrum framework. By analogy with Nexus you could therefore say that S@S is the answer from Jeff Sutherland, next to Ken Schwaber, the other founding father of Scrum, on the scalability of Scrum.
  • Large-Scale Scrum (LeSS, developed by Craig Larman and Bas Vodde) is an agile framework with rules, based on principles and doing experiments. The LeSS Company offers a freely accessible knowledge base (less.works) containing the integrated approach, principles, process descriptions, definitions, roles, examples, et cetera, for large-scale, mainly IT-related, product development. Transparency is also a key concept within LeSS. The first version dates from 2005 and since then, work is constantly being done on the use and further development of LeSS.
  • Scaled Agile Framework (SAFe, developed by Dean Leaffingwell) is a framework to enable scaling up of agile teams in order to create better systems, create higher employee engagement and make use of correct cost considerations. This is the mission of the scaled agile organization and of the founder of SAFe, Dean Leffingwell. The scaled agile organization offers a knowledge base that is freely accessible to everyone (www.scaledagileframework.com) with an integrated approach in the form of process descriptions, definitions, roles, examples, etc. for Lean / Agile product development. SAFe is based on five core competences: Lean-Agile Leadership, Team and Technical Agility, DevOps and Release on Demands, Business Solutions and Lean Systems and Lean Portfolio management.

Figure 1 (see the ‘Business as usual’ / indefinite block), makes use of a division between product and team targets, namely on the basis of cooperation, if necessary, of teams or not. Or with other words, can the individual teams work autonomous (team focus) or do they have to work together to deliver a new or modified product (product focus). The fore mentioned frameworks all relate to examples where multiple teams work on a single complex product or value stream (product targeted frameworks). Not visual in the figure several frameworks make a distinction between products where you are working together in with a maximum of nine teams (in total the team of teams must not exceed the Dunbar number of 125-150 people) and a team of teams of teams (e.g. SAFe large solutions, Nexus+, LeSS Huge).

The other group concerns frameworks to support IT departments that have to maintain dozens or hundreds of applications or services, whereby the dependencies between the teams are minimal (multiple team targeted frameworks). Here the Spotify model (developed by Henrik Kniberg, Anders Ivarsson and Joakim Sundén) can be positioned, but also Scaled Agile Lean Development (ScALeD, developed by Peter Beck, Markus Gartner, Christoph Mathis, Stefan Roock and Andreas Schliep). For both groups, there are essential interfaces between the teams in areas such as data integrity, security and architecture that may not or sometimes will ask for coordination when implementing changes.

In addition, there are many, less known, frameworks that can offer support at the product level, including Agile Integration Framework (AIF), Agile Team Portfolio Management (AgileTPM), AgilePath, Continuous Agile, Disciplined Agile (DA), Enterprise Scrum, Enterprise Agility, FAST Agile, RAGE, Surge, XSCALE, Industrial XP, and AgileDS.

On the left side of figure 1 we see the one-time projects and programs as part of ‘change the business’. Here a distinction is made between projects and programs. Within the project block we see three frameworks and/or methods, all three of which are a further development of the more traditional project management frameworks:

  • Agile Project Management (AgilePM, which is derived from DSDM);
  • PRINCE2 Agile (derived from PRINCE2 from AXELOS)
  • PMI-ACP (in addition to the PMBoK Guide of PMI)
  • Project Half Double (Project Half Double is run by a community of dedicated project management practitioners who are passionate about what they do)
  • Agile Project Management (APM), not mentioned in the figure, can be positioned here too.

On the program side we see:

  • Managing Successful Programs (MSP from AXELOS) that is very agile in itself with the step-by-step growth (via tranches) towards the intended goal (and connects to PRINCE2 (Agile)) and
  • AgilePgM (Agile Program Management of Agile Business Consortium) that connects with AgilePM on the one hand and is comparable with MSP on the other hand.

Praxis covered the portfolio, programme and team levels. Praxis is a free framework for the management of projects, programmes and portfolios (based on PRINCE2, MSP, MoP, AgilePM and other frameworks). It includes a body of knowledge, methodology, competency framework and capability maturity model. The framework is supported by a knowledgebase of resources and an encyclopaedia.

Disciplined Agile (DA) covers both one-time projects and programs as well as business as usual product development. The DA toolkit is a process decision toolkit that describes how agile software development, DevOps, IT, and business teams work in enterprise-class settings.

Portfolio management level

Traditional portfolio management focuses on ‘change the business’. In the previous chapters it has become clear that more and more changes are being handled by the line organization, that is to say: by the permanent agile teams. This means that portfolio management must now also provide an overview of what takes place in ‘run the business’ / ‘business as usual’ for to be implemented change initiatives. Existing portfolio frameworks such as Management or Portfolios (MoP from AXELOS) and Standard for Portfolio Management (SfPfM from PMI) only cover the change-the-business part. Agile Portfolio Management (AgilePfM from ABC) covers ‘run the business’ / ‘business as usual’ as well as ‘change the business’.

In addition, there are a number of agile frameworks that also include a portfolio management component:

  • SAFe offers a portfolio management layer to control ‘run the business’ / ‘business as usual’ permanent team(s) of teams.
  • Disciplined Agile (DA) offers a portfolio process in which, in addition to projects, a number of ‘run-the-business’ / ‘business-as-usual’ aspects are taken into account, such as the permanent teams and the operational management of existing IT solutions.
  • Scrum @ Scale contains modules Strategic vision and Organizational development to which portfolio management can be related.
  • Spotify also provides its own portfolio management approach with its strategic planning.
  • AgilePfM use some basic concepts of an innovation hub, an agile portfolio process, maturity of the initiatives within the portfolio as well as horizons for an agile portfolio.

At the moment (Jan’ 2019) there are no mature portfolio management frameworks that include ‘change the business’ as well as ‘run the business’ / ‘business as usual’. AgilePfM was launched by the Agile Business Consortium (previously DSDM Consortium) as part of their Agile Business Change Framework. However, it is becoming increasingly clear that the overarching agile portfolio management principles are based on frameworks like SAFe, Agile PfM and Disciplined Agile.

Business level

The culture targeted block provides frameworks to increase business agility by changing the mindset of all staff in the organisation. What does it mean to work in an agile way? How can we make sure that the Agile Manifesto values and principles are understand and applied, and the Scrum values (courage, focus, commitment, respect and openness) are part of what we are doing? If the right mindset is in place it makes it much easier to implement an agile framework. In figure 1 the following frameworks are mentioned:

  • Open Space Agility (OSA) is a safe, pragmatic and repeatable technique for getting a rapid and lasting Agile adoption. It works with the framework you are currently using, and OSA can be added at any time. OSA is used to actively engage as many employees as possible in your Agile program.
  • AgileSHIFT (developed byAXELOS) is a framework that prepares people for transformational change by creating a culture of enterprise agility. The AgileSHIFT framework helps organizations to undergo a transformational change, to adopt a ‘survive, compete and thrive’ mindset. It will help to bridge the gap between the current and the target state (the Delta in AgileSHIFT) by embracing a range of agile, structured and hybrid approaches across the organization. The existing severe split between ‘run the business’ and ‘change the business’ will vanish.
  • Agility scales (developed by Jurgen Appelo) helps organizations achieve agility at scale from the bottom up – with measurable evidence of organizational transformation.
  • Lean Startup (developed by Eric Ries) is a methodology for developing businesses and products, which aims to shorten product development cycles and rapidly discover if a proposed business model is viable; this is achieved by adopting a combination of business-hypothesis-driven experimentation, by using a minimum viable product (MVP), iterative product releases, and validated learning.
  • Holacracy (developed by Ternary founder Brian Robertson) is a method of decentralized management and organizational governance, in which authority and decision-making are distributed throughout a holarchy of self-organizing teams rather than being vested in a management hierarchy.

Not mentioned in the figure:

  • Goal Driven Agile (GDA) rests on three main pillars: autonomy, alignment and structured improvement. It’s a very simple framework and consists of only one base structure, the diamond, five roles and ten building blocks.

Already more than 50 agile frameworks and it’s still growing. The figure can help you in your agile framework selection process, but it cannot be said often enough, do not act dogmatically, see a framework not as a panacea that can be implemented out of the box. Common sense helps too to achieve more agility and probably the best route to become more agile is dividing your products and services into smaller autonomous parts and have them supported by an individual team.

To download this article: A birds eye view on the agile frameworks forest v1.3

[1] This picture is based on a simpler version in the book Scaling Agile in organizaties (Portman, 2017)
[2] Pichler, Roman, ‘Is Scrum right for your product?’, 19 september 2016, see: www.romanpichler.com
Advertisements

Quick Reference Cards in 2018

As a result of my book reviews I created several Quick Reference Cards to summarize what I have read.QRC 2018

A new kid on the agile block: Agile Digital Services (AgileDS)

Last week I followed an APMG ATO / trainer briefing regarding Agile digital Services.

This agile framework, developed by Agile Business Consortium, focusses on building and delivery of digital services. The AgileDS framework will help organizations to develop a consistent agile approach, a common language and a skilled workforce regarding digital services. It uses the same terminology as other agile frameworks. It is based on the GDS lifecycle (Government Digital Service, UK), themes and responsibilities have evolved from the roles and responsibilities in AgilePM and its agile practices come from other existing frameworks (e.g. WSJF from SAFe).

AgileDS (QRC, 180718) v1.0To create this quick reference Card I used the handbook that is available for feedback (beta phase). To download the QRC: AgileDS (QRC, 180718) v1.0

Generic and governance principles

The ten generic principles are:

  1. Start with needs
  2. Do less
  3. Design with data
  4. Do the hard work to make it simple
  5. Then iterate again
  6. This is for everyone
  7. Understand context
  8. Build digital services, not websites
  9. Be consistent, not uniform
  10. Make things open: it makes things better

The six governance principles are:

  1. Don’t slow down delivery
  2. Decisions when they’re needed, at the right level
  3. Do it with the right people
  4. Go see for yourself (GEMBA)
  5. Only do it if it adds value
  6. Trust and verify

Service Lifecycle

There are five phases discovery, alpha, beta (privat and public), life and service retirement which can be tailored to meet the needs of different organizations. The aim is to deliver  incrementally within each phase with a significant delivery at the end of a phase.

Products

The following products are described (purpose, when created, updated, needed): Terms of Reference, Business Case, Backlog, Roadmap, Service Architecture Definition, Development Approach Definition, Management Approach Definition, Delivery Plan, Service Lifecycle Transition Report.

Themes and responsibilities

AgileDS defines a set of responsibilities that are collected into simple themes. All responsibilities must be covered and it’s vital that the team acts as a collaborative and effective whole, with clarity about individual responsibilities. Within the Service Delivery Team the following responsibilities must be covered: service ownership, delivery management, product management, business analysis, service development, user research, technical design, service assurance, service design and service deployment.

When needed specialist guidance should be available: assisted digital guidance, accessibility guidance, performance analysis and agile coaching.

Within Steering and Leadership we encounter the following responsibilities: business sponsorship, service ownership, technical leadership and change coordination (in case of multiple service delivery teams).

Techniques

Several techniques are explained: Kano method, relative prioritization, stack ranking, MoSCow prioritization, WSJF, iterative development and incremental delivery, MVP and MMP, requirements and user stories, user research and personas, timeboxes and sprints.

Conclusion

Where AgilePM is there for the delivery of a product or service (temporary agile project, using a project lifcycle), AgileDS is there for the delivery and the continuous operations, support and maintenance of that service (permanent agile delivery team, using the product/service lifecycle). There will be a foundation and a practitioner certification in line with other APMG certifications.

In the next picture I have positioned AgileDS.Grasp session (Scaling Agile, 180526) v1.1

Review: The Agile Enterprise

9781484223901-480x600Mario E. Moreira wrote the book The Agile Enterprise – Building and Running Agile Organizations. A book that can help you to understand what is needed to achieve the full benefits of mature agile. Individuals at all levels in the organization must be committed to the agile mindset and focusing on delivering value to the customer. On top of this all employees must be empowered to take ownership.

The author uses a metaphor of the Agile galaxy: a landscape for your agile culture to view where agile is being applied in your organization and a customer value driven engine.

The book contains 22 chapters, where the first four chapters (I would say the first five) explains the conceptual groundwork for an effective customer-value-driven enterprise and all other chapters provides in-depth knowledge of concepts, mindsets, practices, and techniques to build this customer-value-driven enterprise.

Several chapters ends with references with more material and on many places you get an ‘Agile Pit Stop’ to illuminate ideas or highlight important points.

The landscape of the agile galaxy has three axes. The horizontal view, the delivery axis, following the recording of an idea towards the release of that idea. A vertical view, the hierarchical axis, from top (exec level) to bottom (team level). And the third dimension is the culture: from a negative agile, or more traditional hierarchical and command and control, culture towards a positive agile culture, aligned with engaging customers and employees and aligned with agile values and principles.

Dia1To download: The Agile Enterprise (Agile Galaxy QRC, 180507) v1.0

To highlight the different chapters I will follow the author’s clustering of several themes and summarize some key points.

Agile as it relates to the customer:

The key is narrowing the gap between employees and customers (two-degrees-of separation rule). Customer input and feedback are the two primary guides towards customer value. And understand that often customers don’t know what they want until they see it. To understand customer ideas the author describes how you can record them by using a lean or customer-value canvas and customer personas.

Agile as it relates to the employee:

If you believe employees matter, you must embrace the COMETS values (Collaboration, Ownership, Motivation, Empowerment, Enthusiasm, Trust and Safety). If your organization is following the agile transformation journey and your role has not adapted you may not be part of the transformation. Topics like bounded authority and holocracy are discussed and what is needed to build a learning enterprise. Focus early on the readying the mind for agile with agile mindset education and not with education on an agile process or agile role (the mechanics). A culture with a discovery mindset, infused with incremental thinking, experimental thinking, divergent and convergent thinking, feedback thinking and design thinking is key. HR can play an important role to promote education and agile and hiring agile-minded employees.

Agile culture and mindset:

In the previous clusters already several topics were highlighted, e.g. embracing customers and employees, building a learning enterprise, applying a discovery mindset as well as the role of HR. To understand your own culture an Agile cultural assessment survey based on desired agile behaviors is included in the book.

Running an agile enterprise:

The delivery axis in the agile galaxy can be seen as the enterprise idea pipeline or portfolio backlog or enterprise Kanban board. The 5R model is explained as a path to deliver customer value (Record, Reveal, Refine, Realize and Release and the 6R model added the Reflect step at the end) and how this pipeline can be connected to the backlogs. Prioritization techniques like the Cost of Delay (CoD or CoD3) are explained and what it means if you move away from traditional budgeting towards agile budgeting and make use of lightning-bolt-shaped teams (with primary and at least two additional skills to be able to handle a broader range of work). Agile success measures are discussed and it ends with an explanation of an incremental approach toward an agile adoption (learn, grow, accelerate, transform and sustain).

Establishing your requirements relationships and decomposing requirements from idea to task:

To show the relative hierarchy among various requirements the author uses the requirements tree (corporate strategy, division strategy, ideas, idea increment, epic, user story, and task) and story mapping points you at options that help validate customer value including collaboration on user stories.

Conclusion. A good book when you are at the beginning or in the middle of an agile transformation. I like the idea of the agile galaxy with the three axes. The author gives a lot of in-depth information, mindsets, principles, tools and practices to increase the chance of success of your journey. To read the book from front to back is not easy. I miss a sort of red thread throughout the book, I sometimes had the idea that some chapters could be combined, e.g. 16 and 18 or could be moved to the first part of the book.

To order: The Agile Enterprise

Recensie: De 5 frustraties van teamwork

9789047001966-480x600In het boek De 5 frustraties van teamwork – Hoe zorg je ervoor dat samenwerken leuk blijft legt Patrick Lencioni de essentie van samenwerking binnen een team uit. Het boek is alweer een aantal jaren beschikbaar maar ik kwam het tegen op vele lijstjes, bijvoorbeeld als een van de aanbevolen boeken binnen SAFe, zodat mijn nieuwsgierigheid getriggerd werd en een recensie op zijn plaats is.

Het boek bestaat uit twee delen, waarbij het eerste, omvangrijkste, deel een parabel vertelt waarin we een niet functionerend managementteam zien worstelen in haar soms moeizame weg naar een echt samenwerkend team en het tweede deel ingaat op het begrijpen en tegengaan van de vijf frustraties.

In de parabel volgen we de net aangestelde CEO Catherine die van het bestuur de opdracht had gekregen om van het managementteam een echt samenwerkend team van te maken die resultaten kunnen neerzetten. In een aantal off-sites gaat zij met het managementteam aan de gang waarbij zij de driehoek met de vijf frustraties van teamwork stap voor stap met iedereen doorleeft. Als eerste stap bespreekt ze wat ‘afwezigheid van vertrouwen’ betekent. Middels een aantal oefeningen werkt ze aan het verbeteren van het onderlinge vertrouwen. Vervolgens pakt ze de vijfde frustratie ‘te weinig aandacht voor resultaten’ beet en stelt met de groep het doel voor de komende periode vast. Middels een scala aan oefeningen komen ook de andere drie frustraties ‘angst voor conflicten’, ‘gebrek aan betrokkenheid’ en ‘verantwoordelijkheid mijden’ aan bod. Het is zoals te verwachten, echt vallen en opstaan, drie stappen vooruit en twee stappen terug maar uiteindelijk ontstaat een echt team.

De vijf frustraties van teamwerk (QRC, 180121) v1.0Downloaden: De vijf frustraties van teamwerk (QRC, 180121) v1.0

In het tweede deel zoemt de auteur in op de in de parabel gehanteerde driehoek met de vijf frustraties. We krijgen een samenvatting van het model en een teamonderzoek vragenlijst met daarin vijftien vragen om vast te stellen welke frustraties wel/niet een probleem vormen voor het team.

Vervolgens krijgen we per frustratie karakteristieken van teams waar de frustratie aanwezig is en karakteristieken van teams die de frustratie onder de knie hebben. Daarnaast krijgen we per frustratie een aantal suggesties hoe de frustratie is tegen te gaan en welke rol de leider hierbij moet spelen.

Tenslotte wordt de relatie tussen de verschillende frustraties toegelicht. De eerste stap is vertrouwen. Als er vertrouwen is durft men conflicten aan te gaan waardoor betrokkenheid wordt gecreëerd. Door betrokken te zijn voelt men zich verantwoordelijk en hiermee kunnen de gewenste resultaten geboekt worden.

Conclusie: een vlot leesbaar boek dat de essentie van teamwork helder naar voren brengt. De vijf frustraties bieden een mooi handvat om te laten zien of een team wel of niet goed functioneert. Een must voor agile teams. Middels de teamonderzoek vragenlijst wordt een eenvoudig instrument aangeboden om middels vijftien vragen vast te stellen welke frustraties wel/niet een probleem vormen voor het team. Kijk je verder naar de aangeboden suggesties om de frustraties te lijf te gaan dan krijg je een gereedschapskist om van een groep mensen een echt team te maken. Alleen jammer dat de geboden suggesties niet wat concreter uitgewerkt zijn.

Bestellen: De 5 frustraties van teamwork

Overview of my year 2017 book reviews and QRCs

2017 was a fruitful book year. I wrote many book reviews including corresponding quick reference cards and several personal insights, and views on specific topics in the field of project, program and portfolio management and I wrote two books Scaling agile in organisaties, and Agile with a smile.

overview 2017 (reviews, 171222) v1.0

Agile portfolio management

Agile

Project management and PMO

Organization

overview 2017 (reviews + QRCs, 171222) v1.0

Quick Reference Cards:

  • QRC AgilePfM
  • QRC P3M3
  • QRC Best Value Project Management
  • QRC How to do projects – A Nordic flavour to managing projects
  • QRC Manage your project portfolio
  • QRC Goal Driven Agile
  • QRC De Team-ontwikkeling-schijf
  • QRC Overtuigen
  • QRC The agility shift
  • QRC The Relational Web
  • QRC Lean UX

Recensie: ICT-leverancier: van vijand naar vriend

Afbeelding1Dinsdag 14 november 2017 was ik als gast van KWD Resultaatmanagement aanwezig op de KWD Projectmanagement Vakdag. Deze dag stond in het teken van ICT Leverancier: van vijand naar vriend. Naast de keynote -sprekers Jitske Kramer en Jan Lammers was er een programma met een zestal parallelsessies. Mijn keuze was gevallen op de sessie van een praktijkcase van Best Value Projectmanagement bij Transavia. Een inspirerende en informatieve sessie over een onderwerp waar ik nog niet veel van wist.

Aan het eind van de vakdag was daar de lancering van alweer het zevende boekje in de KWD-reeks. Het boek met dezelfde titel als de Vakdag “ICT-leverancier: van vijand naar vriend – Sourcing op basis van Best Value Projectmanagement” geschreven door Fred Bons, Fred Heemstra, Arjan Jonker, Luuk Ketel en Gerard Meijer.

En dan valt alles op zijn plaats. De bijgewoonde praktijkcase is ook als case in het boek opgenomen en Best Value Management en Best Value Projectmanagement staan centraal in het boek zodat ik nu na lezing een beter begrip heb gekregen van Best Value Projectmanagement.

Het boek is onderverdeeld in negen hoofdstukken en afgewisseld met de praktijkcasus Transavia.

Het boek begint met het beschrijven van de theorie van sourcing en de concepten van Best Value Procurement en Best Value Projectmanagement. Aansluitend beschrijven de auteurs een drietal probleemgebieden m.b.t. Leverancierskeuze, contract en samenwerking.

Naast de genoemde drie probleemgebieden, problemen rond het sourcingstraject in enge zin, komen ook problemen rondom sourcing in bredere zin aan bod: de integrale besturing van sourcing tijdens selectie en implementatie. Best Value Procurement en Best Value Projectmanagement zijn, volgens de auteurs, de antwoorden om de genoemde problemen te lijf te gaan.

Bij Best Value Procurement is de leverancier in de lead, hij is de expert en levert dominante informatie op basis waarvan de leverancier kan aantonen dat hij een oplossing kan leveren die de doelstelling van de klant kan realiseren, waarbij tijdstip van leverancierselectie en de daadwerkelijke gunning bewust niet samenvallen. En dit alles binnen een veel korter aanbestedingstraject met een contract dat aangeeft welke prestaties door de leverancier geleverd moeten worden en niet een gedetailleerde door de klant opgestelde scope en bijbehorende afbakeningen (zie ook ‘false positive feasibility’ zoals beschreven in The Lean Machine waarin o.a. het omgaan met requirements bij Harley Davidson wordt beschreven).

Best Value Projectmanagement integreert Best Value Procurement met een projectmanagement-aanpak resulterend in kernwaarden, principes, vier processtappen (voorbereiding, beoordeling, concretisering en uitvoering) en stuurknoppen. Zie ook de bijgevoegde QRC.

BVPM (QRC, 171120) v1.0Downloaden: BVPM (QRC, 171120) v1.0

Best Value Projectmanagement is niet altijd toepasbaar. Er moeten wel voldoende aanbieders zijn die de expertrol kunnen invullen. Heb je, als organisatie ervaring met Best Value? Zijn er meerdere oplossingen mogelijk en zijn risico’s eenduidig toe te wijzen? Tenslotte hoe complex is de omgeving? Kijk ik naar Snowden’s Cynefin model dan positioneer ik het toepassen van BVPM in het complexe domein waar we ook de agile aanpak kunnen plaatsen.

Binnenkort wordt de KWD Projectmanagement App uitgebreid met één plot met drie invalshoeken:

  1. Is mijn project geschikt voor Best Value (BV)?
  2. BV readiness Opdrachtgever – hulpmiddel voor een gesprek om inzichtelijk te krijgen in hoeverre de opdrachtgever klaar is voor BV
  3. BV readiness Leverancier – hulpmiddel voor een gesprek om inzichtelijk te krijgen in hoeverre de leverancier klaar is voor BV

Naar verwachting zal de App eind december 2017 beschikbaar zijn.

Het laatste hoofdstuk gaat over de vraag hoe Best Value Projectmanagement in de praktijk werkt en hoe om te gaan bij verschillende vraagstukken zoals bijvoorbeeld vertrouwen of tegenstrijdige belangen.

De praktijkcasus Transavia is onderverdeeld in een viertal blokken:

  • Outsourcing van Housing & Hosting
  • De leverancierselectie
  • Contractering
  • Samenwerking

Conclusie

Wederom een informatief en mooi opgemaakt boekje met fraaie foto’s en het lezen meer dan waard om een eerste beeld van Best Value Procurement en Best Value Projectmanagement te krijgen. We krijgen een scala aan handvatten waarmee je als opdrachtgever, projectmanager, inkoper of leverancier, sourcing succesvol kan laten verlopen. Wat ik nog mis is de uitwerking van de regiefunctie als onderdeel van exploitatie. Een gebied waar ik organisaties nog weleens zie struikelen als bepaalde services of diensten zijn uitbesteed.

Bestellen: ICT-leverancier: van vijand naar vriend