Tag Archives: QRC

Bimodal Portfolio Management

Introduction

1*ORjFcvHHbyWBTA1WIijXYwAt the moment, many organizations are in the middle, or on the brink of, a radical change to more business agility. I receive quite often the question how to cope with both an agile portfolio as well as a more traditional portfolio with temporary projects and programs. Existing frameworks supports either an agile IT portfolio or a more traditional portfolio, but I haven’t seen frameworks which supports both.

If I look at existing traditional and agile IT portfolio management frameworks, I asked myself if combining these frameworks can bring an answer for those organizations who need to manage an agile as well as a more traditional portfolio?

In this article I will start with a brief explanation of the existing portfolio management frameworks by explaining the principles and the process (Management of Portfolios, Standard for Portfolio Management, Disciplined Agile Portfolio Management, Agile Portfolio Management, Evidence-Based Portfolio Management, and SAFe Lean Portfolio Management).

MoP P3O SAFe Hybrid (190621) v0.1In the second part of this article I focus on Bimodal Portfolio Management where I combine the best of these worlds and offer a solution for both worlds in the form of a Bimodal Portfolio Kanban (see figure), Bimodal Portfolio Management Principles and Bimodal Portfolio Roadmaps.

To download the article: Bimodal Portfolio Management (article, 190626) v1.0

 

Advertisements

Recensie: Design denken & doen

9789462762718-480x600Patrick van der Pijl en Erik Prins hebben in samenwerking met Justin Lokitz en Lisa Kay Solomon het boek Design denken & doen – nieuwe mindset, vaardigheden en tools voor het ontwerpen van de toekomst geschreven.  Daar bij dit boek de ‘smoel’ of te wel de layout sterk bijdraagt aan het overbrengen van de boodschap mogen ook de designers Maarten van Lieshout en Erik van der Pluijm, van dit boek niet onvermeld blijven.

Het boek begint met een introductie over design en de designer waarbij voor de designer (rebel with a cause) zeven kernwaarden van toepassing zijn:

  • Alles begint met de gebruiker
  • Denk en werk visueel!
  • Vlieg niet solo. Je bent niet slimmer dan de rest
  • Vertel verhalenen deel ervaringen
  • Hou het simpel
  • Zet kleine experimenten op en leer ervan
  • Omarm onzekerheid. Het is voeding voor de hersenen.

Daarnaast wordt het designproces als double loop gevisualiseerd met daarin de volgende stappen:

  • Voorbereiden: Bereid je team voor, je omgeving en hoe je werkt
  • Point of view: Wees een rebel, ontwikkel je visie, ontwerp je verhaal, creëer designcriteria
  • Begrijpen: Begrijp je (eind)gebruiker, je contacten, en je organisatie
  • Ideeën vormen: Leer ideeën te vormen, borduur erop voort en selecteer ideeën
  • Prototypes maken: Breng ideeën tot leven, schets en maak prototypes
  • Valideren: Vind de riskantste aanname, experimenteer en pas ‘pivots’ toe
  • Toepassen: Wanneer en hoe je design toepast in een onderzoeksproces

Middels deze stappen ben je instaat om innovaties vanuit een menselijk perspectief te ontwerpen.QRC Designdenkendownloaden: QRC Design denken

Iedere stap wordt vervolgens in een hoofdstuk uitgebreid beschreven waarbij een stukje introductie en de theorie achter die stap aan bod komt. Verder worden de voor de betreffende stap noodzakelijke vaardigheden beschreven en worden de bijbehorende tools, in de vorm van canvassen toegelicht. In totaal worden 19 canvassen beschreven. Denk hierbij aan bekende canvassen zoals het Business model Canvas en het Value proposition Canvas maar ook aan, speciaal voor de in dit boek beschreven aanpak, ontwikkelde canvassen zoals bijvoorbeeld het 5 bold Steps Vision Canvas en het Riskiest Assumption Canvas. Alle canvassen zijn op designabetterbusiness.com te downloaden (ondertussen is de site al uitgebreid met een aantal extra canvassen). Ook worden in de verschillende hoofdstukken in totaal 48 casestudies of praktijkvoorbeelden behandeld die je laten zien hoe anderen de theorie in de praktijk hebben gebracht. Zo komt bijvoorbeeld in de Audi-case de toepassing van het storytelling canvas aan bod of de case hoe ING Bank de designcriteria canvas heeft toegepast. Ook lezen we hoe Wavin haar echte klanten, de loodgieters, ontdekt en wat het betekent als ze voor deze loodgieters Wavin Academies opzet. Er komen verder 30 designers en thought leaders met persoonlijke inzichten en ervaringen aan het woord en krijg je 36 korte maar krachtige insidertips. Middels 150 visuals is het een een prettig leesbaar boek geworden.

Conclusie: Een visueel krachtig en prachtig boek om de wereld achter het design denken tot je te nemen en zelf met design denken aan de gang te kunnen gaan.

Bestellen: Design denken & doen

Review User Story Mapping

User story mappingJeff Patton wrote the book User Story Mapping. Story mapping it’s a tool to enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why.

The book offers 18 chapters:

  1. The big picture. This chapter will help to get a basic understanding of a story map and what it means to tell stories.
  2. Plan to build less. Now you have a basis understanding of a map some more details are added. What’s the backbone of the map, what type of users are playing a role, which big activities are the performing, how can those activities be divided into smaller steps, how can we split a single step into more details.
  3. Plan to learn faster. Are we going to deliver everything in one big release, or can we have multiple releases? How are we going to set up the individual releases? How can we learn from the users using the release (validated learning, build – measure – learn)?
  4. Plan to finish on time. Don’t release each slice. Divide your release in an opening game (see it work), mid game (make it better) and an end game (make it releasable). Include risk stories to make risk visible.
  5. You already know how. Based on the previous chapters you now have a pretty good understanding of a story map. In this chapter you can prove you really understand it by creating a story map of all the things you have done this morning when you woke up until you’ve gotten ready for work. Will be fun, definitely when you do this with some more people and start to discuss differences. QRC (story mapping, 190606) v1.0To download: QRC (story mapping, 190606) v1.0
  6. The real story about stories. The founding father of the idea of stories was Kent Beck (eXtreme Programming). His idea was to stop working so hard on writing the perfect document, and to get to tell stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. Ron Jeffries describe the story process as 3 C’s: Card, Conversation and Conformation.
  7. Telling better stories. Stay away from template zombies. Start talking about the who, what, why, what goes wrong, what happens outside the software, questions and assumptions, better solutions, how and how long.
  8. It’s not all on the card. You could scribble everything you like on a card. E.g. short title, description, story number, estimate, size or budget, value, metrics, dependencies, status, dates. You could even flip the chart to the back and write additional notes or bulleted acceptance criteria.
  9. The card is just the beginning. The 3 C’s are just the beginning. Two more C’s complete it: Construction and Consequences (evaluate with team first, then with business stakeholders and in tests with customers and users).
  10. Bake stories like cake. Ask lots of who, what, and why questions. Ask about the context (where, when, how many). Talk long enough to build shared understanding. If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal. If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.
  11. Rock breaking. A right-sized story from a user’s perspective is one that fulfills a need. A right-sized story from a development team’s perspective is one that takes just a few days to build and test. A right-sized story from a business perspective is one that helps a business achieve a business outcome. Conversations are one of the best tools for breaking down big stories.
  12. Rock breakers. A small, cross-functional team led by a product owner orchestrates product discovery work. The ideal size for a product discovery team is two to four people – dinner-conversation-sized so the members can quickly build shared understanding. The solution we want is valuable, feasible and usable (the three concerns; triad).
  13. Start with opportunities. Have conversations about opportunities and decide whether to move forward with them or trash them. If you agree to take on everything you are not helping anyone. Aggressively trash opportunities that don’t offer much hope of creating the outcomes you hope for.
  14. Using discovery to build shared understanding. Discovery work isn’t about building shippable software, it’s about learning. What problems are we really solving? What solutions could be valuable? What does a usable solution look like? What’s feasible to build given the time and tools that we have? Use four essential steps to discovery: frame the idea, understand customers and users, envision your solution and minimize and plan.
  15. Using discovery for validated learning. During discovery and validated learning, you may be telling stories constantly, breaking ideas and work down into small buildable pieces and agreeing on exactly what to build. You’ll be doing it so fast that it won’t be clear you’re using stories. But you are.
  16. Refine, define, and build. Play the Good-Better-Best game for splitting stories (What’s good enough to get things working, what would make it better, what’s the best version we can imagine?).
  17. Stories are actually like asteroids. Break stories down progressively, and just in time. To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those tittles with a single title on your new card and you’ve got one big story. In this way you can clean-up your backlog.
  18. Learn from everything you build. There are many opportunities to learn: review as a team, review with others in your organization, learn from users, learn from release to users, and use a map to evaluate release readiness.

Conclusion: A must read for product owners and agile team members. It’s the most complete book on story mapping I have read, and it will answer all (or most of) your questions regarding user story mapping.The book will definitely help you to use story mapping to deliver results that satisfy your customers.

To order: User Story Mapping

 

Review: An Introduction to Evidence-Based Portfolio Management

portfolio 2Scrum.org wrote the whitepaper An Introduction to Evidence-Based Portfolio Management. Evidence-Based Portfolio Management is an approach that applies lean and agile principles to the challenge of deciding where to invest to derive the greatest business benefit.

It enables organizations to quickly test ideas by actually building and validating the smallest solution that will deliver a single outcome to a single set of customers or users.

Evidence-Based Portfolio Management takes a Principles Based Approach:

  1. Separate capacity-for-growth from focus-of-work
  2. Make the best decision you can, based on the best evidence available
  3. Invest in improving business impacts using hypotheses, don’t just fund activity
  4. Continuously (re)evaluate and (re)order opportunities
  5. Minimize avoidable loss
  6. Let teams pull work as they have capacity
  7. Improve status reporting with increased engagement and transparency.

QRC E-B PfMTo download the QRC: QRC E-B PfM

Evidence-Based Portfolio Management focusses on outcomes to produce better results. It states that the organizational mission, vision, outcomes, and strategy must be centralized, and the product vision, strategy, and execution must be decentralized.

The art of portfolio management is deciding what not to work on and the number of teams you have will limit how many ideas you can work on at once.

To download the whitepaper: An Introduction to Evidence-Based Portfolio Management

This framework fits in the Portfolio level block of my bird’s eye view on the agile frameworks forest (see also the complete article).

Grasp session (Scaling Agile, 190603) v1.1

 

 

A bird’s 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, 190603) v1.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’.

Evidence-Based Portfolio Management (E-B PfM) is an approach that applies lean and agile principles to the challenge of deciding where to invest to derive the greatest business benefit. It enables organizations to quickly test ideas by actually building and validating the smallest solution that will deliver a single outcome to a single set of customers or users. Evidence-Based Portfolio Management takes a Principles Based Approach:

  1. Separate capacity-for-growth from focus-of-work
  2. Make the best decision you can, based on the best evidence available
  3. Invest in improving business impacts using hypotheses, don’t just fund activity
  4. Continuously (re)evaluate and (re)order opportunities
  5. Minimize avoidable loss
  6. Let teams pull work as they have capacity
  7. Improve status reporting with increased engagement and transparency.

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.
  • The Agile Fluency model, developed by Diana Larsen and James Shore in 2012 and substantially updated in 2018, is a framework to help teams understand their current position and to help them develop an individual road map. Agile teams pass through four distinct zones of fluency as they learn (Focusing teams, Delivering teams, Optimizing teams and Strengthening teams). Diana Larsen defines fluency as things that you do automatically without thinking. Each zone brings specific benefits.
  • 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.5

[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

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