Scrum or Kanban

In one of my previous blogs I wrote about ‘Agility by delivering changes as ‘business as usual’

In that article I showed a picture with different agile methods and frameworks. On the team level I mentioned Scrum, Kanban and DevOps. I came across a blog post from Roman Pichler titled ‘Is Scrum right for your product?’. A nice article explaining when to use Scrum and when to use Kanban, by following a product life cycle from launch via product market fit till the end of life. I added DevOps to his approach in the same product life cycle and will use this to expand my own article. See the animated PowerPoint too.

During the first part of a product life cycle the uncertainty is high and the focus is on goal driven iterations for the first product launch and market fit product. During this part of the life cycle Scrum is a great fit to cope with uncertainty and product iterations developed by the whole team. During the rest of the product life cycle the amount of uncertainty and change gradually declines. Here Kanban is a good fit. User Stories will be realized in a continuous flow by one or more of the individual team members.

When a major product upgrade has to be delivered by the whole team Scrum could be a better choice for that goal oriented iteration, otherwise Kanban stays a good fit.

To avoid the error prone handover and to shorten the time to market the Development and Operations teams can be integrated. Kanban is a good fit for the DevOps team. When to start with DevOps varies.

See: Is Scrum right for your product?

Review: Scrum Magic. Ultimate training guide to the agile framework.

51xkemdtrllDoug Purcell wrote the book ‘Scrum Magic. Ultimate training guide to the agile framework‘ that will help you to pass one of the basic Scrum Master exams.

I would say that with this book you will get a lot of flesh on the scrum bones (as offered by the official Scrum Guide).

To set the scenery the author begins with the explanation of waterfall, agile and kanban and discusses the pros and cons and compares waterfall and kanban with scrum. 

After getting an eagle eye view of scrum including the roles product owner, scrum master, development team and stakeholders we follow the sprint lifecycle planning phase, execution phase, and closing phase.

  • Planning phase: sprint planning and estimation strategies including story points and the comparison with man-hours, planning poker, fist of five and user story best practices
  • Execution phase: daily scrum meeting with dos and don’ts and monitoring progress
  • Closing phase: sprint review with dos and don’ts and group roles, sprint retrospective best practices.

The author starts every time with a bullet list coming from the Scrum Guide and elaborates on the different topics using more detailed theory and own best practices, dos and don’ts and FAQs. You also get for each chapter the used sources (books, websites), and a quiz to help you study the material (in total you get 130 sample questions and a rationale for the answers.

In the appendices you find an overview of different agile certifications as well as project management certifications (the last is unnecessary). The explanation and reference of several agile related websites/blogs is valuable and will trigger you to have a look.

Conclusion

If you want to go for a scrum master certification this book is definitely worth to read and practice the questions and using the rationale to really understand and prepare yourself for the examination. If there is no need for certification this book will still be useful to get a practical understanding of using Scrum.

To order: Scrum Magic

Recensie: Benefits realization management

img_14721-kopieIn het boekje (white paper) ‘Benefits realization management’ neemt de auteur Ruud Kramer je mee in de wereld van benefits management. Met dit boekje wil hij aantonen dat het zinvol is om meer aandacht te geven aan batenmanagement. Daarnaast neemt hij je mee in zijn aanpak van Benefits Realization Management dat een nadere invulling is van het onderdeel Benefits Management van MSP.

Ik kom programmamanagers tegen die sterk focussen op de projecten in hun programma maar te weinig aandacht hebben voor het realiseren van de baten. Gebruik van methoden zoals MSP met het benoemen van Business Change Managers en deze BCM’ers verantwoordelijk maken voor het verzilveren van de baten helpt hierbij maar wordt lang niet altijd gevolgd.

Dit boekje kan prima gebruikt worden om het belang van batenmanagement aan te tonen en ideeën op te doen voor het invullen van batenmanagement, ongeacht de methode die je gebruikt. Het biedt handvatten voor het in kaart brengen en meetbaar maken van te realiseren baten, het optimaliseren van mogelijke baten en het gebruik bij het optimaliseren van een projectenportfolio. Ter ondersteuning wordt gebruik gemaakt van schermafdrukken van een batenmanagementtool (Wovex BRM-software).

Het boekje is onderverdeeld in drie hoofdstukken.

In het eerste hoofdstuk staat de Benefits Dependency Map centraal. Hoe breng je de oorzaak-gevolg relaties tussen doelen, uitkomsten, veranderinitiatieven en de lange termijnambities in kaart. De Benefits Dependency Map wordt stap voor stap opgebouwd aan de hand van een voorbeeld van een Integraal Werkplek Ontwikkelingsprogramma. Uitgaande van strategische ambitie (“start with the end in mind”) kan terug geredeneerd worden naar uiteindelijk de mogelijke veranderinitiatieven. Vervolgens maak je samen met gebruikers inschattingen van realistisch haalbare baten (KPI’s) en deze voeg je toe aan de Benefits Dependency Map. In overleg met de belangrijkste stakeholders kan de Map wellicht nog worden uitgebreid met additionele afgeleide doelen. Door de voor hen belangrijke baten te benoemen en te visualiseren en daar ook over te gaan rapporteren heb je een prima instrument om deze stakeholders betrokken te houden. Tenslotte kunnen in overleg met deze stakeholders randvoorwaarden benoemd worden en aan de Benefits Dependency Map worden toegevoegd.

Het tweede hoofdstuk geeft aan hoe je kan optimaliseren door het juiste scenario te kiezen. Niet alle baten zijn even belangrijk. In overleg met de stakeholders kunnen aan de verschillende baten wegingsfactoren worden gehangen zodat subjectieve meningen worden geobjectiveerd. Voegt men vervolgens bij de verschillende initiatieven de mate van ontwikkeling toe (niets doen, brons, zilver, goud) dan kan men verschillende scenario’s creëren door te variëren met de mate van ontwikkeling en wat dat betekent voor de te realiseren baten (What-if dashboard). Op basis hiervan kan vervolgens de stap gezet worden naar de hiervoor noodzakelijke producten of processen (lees output van projecten) en de daarbij behorende projecten en lijnactiviteiten.

Het laatste hoofdstuk gaat over de opvolging. Waar staan we met de batenrealisatie, moeten we corrigerende maatregelen nemen? Meten van zowel tussen- als eindresultaten moet het benodigde inzicht leveren. Door in een dashboard de performance indicatoren zichtbaar te maken en te laten zien hoe deze indicatoren zich ontwikkelen in de tijd gezien krijgt met een krachtig instrument om te volgen of we de gewenste baten gaan halen en of er eventuele acties genomen moeten worden.

Conclusie

Een leuk boekje om batenmanagement over het voetlicht te brengen. Middels het stappenplan en de vele plaatjes wordt de kracht van batenmanagement en de Benefits Dependency Map helder neergezet en krijgt men een goed beeld dat voor het bereiken van succes er meer nodig is dan alleen het afronden van projecten.

Zie ook http://www.bizfits.nl

Recensie: Project Canvas. Samen naar de kern van je project

9789462761117-480x600In lijn met het boek Program Canvas (zie mijn recensie) hebben Rudy Kor, Jo Bos en Theo van der Tak het boek ‘Project Canvas. Samen naar de kern van je project’ geschreven. Ook hier een A3 (of A4) one-pager, de Project Canvas, waarin de essentie van een project wordt vastgelegd en waarmee de dialoog kan worden aangegaan met stakeholders rond het project.

De Project Canvas kan het projectvoorstel (project brief) in PRINCE2 / PRINCE2 Agile termen of de project charter in PMBoK termen vervangen.

Het boek is onderverdeeld in vijf hoofdstukken.

Het eerste hoofdstuk positioneert de Project Canvas in de levenscyclus van een project. Het project wordt afgezet tegen andere vormen van samenwerking zoals routine, programma, proces en improvisatie. Daarnaast krijg je inzicht in de mate van voorspelbaarheid van de verschillende samenwerkingsvormen.

Hoofdstuk twee beschrijft de opbouw van het Project Canvas.img_1471

 

 

 

Het Project Canvas bestaat uit vijftien elementen die in vijf blokken zijn onder te verdelen:

  • Wat? (Achtergrond, Probleem/Uitdaging, Doelen, Resultaat, Afbakening)
  • Wie? (Opdrachtgever, Belanghebbenden, Projectteam)
  • Hoe? (Aanpak, Risico’s, Afhankelijkheden)
  • Waarbinnen? (Randvoorwaarden, Kwaliteit)
  • Waarmee? (Tijd, Geld).

Per element krijgen we een beschrijving en vier hulpvragen om de gedachten te ordenen.

Hoofdstuk drie beschrijft het creatieproces om te komen tot een ingevulde Project Canvas. Zowel een ontwerp- als een ontwikkelbenadering worden toegelicht alsmede werkvormen en het faciliteren van een Project Canvas workshop.

In hoofdstuk vier staan Projectmatig Werken en Projectmatig Creëren centraal. Met alleen een Project Canvas ben je er nog niet. Projectmanagement vergt aandacht voor de vier thema’s inhoud, organiseren, aanpak en beheersing. Het hoofdstuk wordt afgesloten met twee ingevulde Project Canvassen van de projecten opstellen programmacontract duurzaamheid en Maken Project Canvas boek.

Het laatste hoofdstuk laat zien hoe de Project Canvas aansluit op PRINCE2 van Axelos, de PMBoK van PMI en AgilePM van DSDM.

Conclusie

Is het uniek? Nee. Is het praktisch toepasbaar? Zeer zeker. Het boek leest vlot weg en is voorzien van overzichtelijke tekeningen en biedt een heldere toelichting op het invullen.

In 2009 schreef ik het boek De praktische PRINCE2 en daarin zit een aanpak om alle PRINCE2 managementproducten samen te stellen met behulp van PowerPoint bouwstenen. De basisbouwsteen hierin is de Mandate one-pager. In deze Mandate one-pager komen de volgende blokjes voor: Achtergrond/Rationale, Projectmanagementteamstructuur, Doelen, Producten, In scope, Out of scope, Start/Einddata, Kosten, Risico’s, Beperkingen en Afhankelijkheden.

De Project Canvas lijkt op een verder doorontwikkelde versie van de one-pager die ik toen beschreven had. De auteurs gaan echter verder. Naast een logische opzet bieden ze ook allerlei handvatten en hulpvragen om tot invulling te komen als ook een klustering van de verschillende blokken en mogelijke volgorden van invulling. Ik zie de Project Canvas dan ook als een prima instrument om zonder dikke pakken papier de dialoog met de belangrijkste stakeholders aan te gaan.

Bij het downloaden van de Project Canvas template kreeg ik nog een paar verrassende resultaten van door anderen ontwikkelde Project Canvas modellen:

  • http://www.projectcanvas.dk biedt naast een template voor de Project Canvas ook een boekje met toelichting op de Project Canvas. Op deze Project Canvas vinden we de volgende elementen: Purpose, Scope, Success Criteria, Actions, Milestones, Team, Stakeholders, Users, Resources, Constraints, Risks.
  • Ook vond ik verschillende verwijzingen naar een Project Canvas inclusief tools om de canvas in te vullen. Op deze canvas vinden we de volgende elementen: Users, User Benefits, Goals, Participants, Activities, Deliverables, Risks, Milestones, Constraints, Scope.

Ook op basis hiervan kunnen we dus stellen de in dit boek beschreven Project Canvas het meest uitgewerkt is.

Bestellen: Project Canvas. Samen naar de kern van je project

Book review: The Lean Machine

1001004008192950The lean machine. How Harley-Davidson drove top-line growth and profitability with revolutionary lean product development by Dantar P. Oosterwal. In SAFe you can find several references to this book. For me a reason to review this book.

The book is divided in three parts. The first part, the first chapter, explains the current state of product development and shows how many organizations have structured their product development. The second part, the chapters two through seven, gives insights how Harley-Davidson’s learning environment looks like. The last part, chapters eight through sixteen focusses on the learning and discovery journey in the application of lean principles, which resulted in knowledge-based product development which helps to increase new product throughput, to reduce time to market and to improve quality.

In the first chapter we get insights in a traditional command and control product development organization using very detailed standards for product development, controlled by stage gates and where problems only show up at the end of the development cycle during testing.

In the second part we focus on Harley-Davidson’s learning environment.

Chapter two describes the history of Harley-Davidson and how Harley-Davidson made a transformation towards lean manufacturing. As a result, the organization was divided into three business areas (circles) focussing on manufacturing customers, manufacturing products, and providing the required support. At the intersection of these three circles was the Leadership and Strategy Council. This circle organization structure requires trust and unpredicted levels of collaboration, a lot of coaching and investments in personnel. The traditional command-and-control was transformed in a consensus-driven organization with decision taking by individuals, shared or group and mechanisms for managing conflicts.

To complement this circle organization a formal business process was created to empower the entire organization and fully harness the energy of the workforce. This business process is anchored with three overarching “umbrella” constants: values, issues and stakeholders. The process can be visualised with the following flow: Constants – Vision – Mission and Operating Philosophies – Objectives – Strategies – Work Unit Plans – Work Group Goals.

Chapters three and four put the Product Development Leadership Learning Team (PDL2T) central. This team embraces Peter Senge’s book The Fifth Discipline to build and maintain a learning organization (Systems thinking, Personal mastery, Mental models, Building shared vision and Collective team learning).

We get insights in the set-up of the meeting room and agenda, a code-of-conduct to enable dialogue and establishing learning conversations so the attendees will balance between advocacy and inquiry and know where they are on the ladder of inference in conversation. Based on the conversations we see the creation of a system model example.

Chapter five is all about firefighting and the tipping point. The tipping point refers to that point at which a minor change ‘tips’ the system into a new and irreversible condition. Think about a delay in one of the projects or a new project that will put the whole portfolio at risk. To solve (firefight) the problem we will use some of the resources of another project resulting in an issue for that project too and before you know you are only firefighting issues in many projects in your portfolio without delivering as was promised. Consequences of this are analysed by using a system model the PDL2T created. Based on analysis of the system model and the data two critical elements were identified. cadence and flow are necessary to establish effective and efficient multi-project product development.

Chapter 6 goes into the details of having a cadence and flow. Many organizations use a phase and gate development model. Will this bring execution certainty? Probably not, it will maintain financial control, brings discipline but on the other hand it will throttle development and flow and instil bureaucracy. Having a cadence, the rhythm and the heartbeat that drives effective product development, to pace the work is much more beneficiary to deliver more or with other words to increase the flow of delivered products (or projects). Within Harley Davidson this cadence and flow was translated in standardized pieces of work called bins representing small, medium and large projects. For every bin the scope, schedule and resources was clear. This resulted in a standard portfolio were the sequence of large, small and medium size projects was clear as well as what could be managed in parallel. In the portfolio it became clear for everybody how much could be delivered (flow) and when (cadence).

Chapter 7 goes into supply and demand. Based on data analysis it became clear that improvement of throughput of new products will result in increased customer demand.

Part III: knowledge-based product development

Chapter 8 looks into possibilities to apply lean principles in product development. Is it possible to use lean principles to create cadence and flow? You get an explanation how the Wright brothers took a systems approach to their study of flight focussing first on solving the three primary obstacles preventing successful flight (wings, power and craft dynamics).

Chapter 9 gives you a first understanding of the product development learning curve. Chapter 6 already gave some cons of a phased or stage gate development process. Here you will get some more insights. Every phase builds on the previous one and each phase has specific criteria that need to be met to continue with the next phase. This life cycle is A linear ‘design and validate’ process which promotes ‘point-based’ solutions. Key is the phenomenon that is termed “false positive feasibility”. Based on this we pass tollgates and use redesign loops to fix design problems during testing with delays as a result. See the animation.

In chapter 10 we get an explanation of product development design loops. Every design loop ends/starts with an integration point. At those integration points you control product development. And chapter 11 emphasized on learning cycles. A traditional phase gate methodology promotes progression of product development linearly through stages of development. These decision gates are intended to control risk by stopping the flow of work. As a result, this methodology encourages a linear, point-based development mind-set. Only in the last phase we have the possibility to learn and find out whether the design is truly feasible. This point-based mind-set results in false positive feasibility. Examples of learning cycles are Plan Do Check Act (PDCA) or Look Ask Model Dialogue Act (LAMDA). In linear point-based development, the learning cycles occur as unplanned rework loops to fix the problems. To avoid this, we have to follow a set-based product development.

Chapter 12 gives more insights in set-based development by explaining the usage of the limit curve. Set-based design doesn’t mean that you have to develop in parallel several options but in your design you work with bandwidths (see the limit curve) and use the data to turn it into visible knowledge. Based on this knowledge you will reduce your options to move forward in the right direction. Combining set-based development with cadence and flow through experimental learning cycles results in a knowledge-based development system.

In chapter 13 the leadership learning and pull events are highlighted. The objective of a pull event is to focus the development organization on a tangible event to force completion of a learning cycle to physically demonstrate it.

Chapter 14 gives some best practices to quickening product development. We get an explanation of combat planning. Combat planning is suited to turbulent and ever-changing conditions and relies on sound aggregate objectives where alternatives are developed by individuals in order to ensure achieving shared goals. We get insights in the usage of help chains and visual management as well as After Action Reviews (AARs) as learning tools.

In chapter 15 Oobea stands in the spotlights. The Oobea process and room is explained. This Oobea is all about collaboration and sharing. Oobea is the Japanese word for “big, open office”.

The last chapter shows that Harley Davidson made an enormous step forward by developing and using this knowledge-based product development cycle.

Conclusion.

After reading this book I can now see why there are several references to this book in SAFe. Also the usage of set-based development is now much clearer to me as well as the negative side of stage gate development cycles and the “false positive feasibility”. A must read when you want to apply lean in product development!

For more information, see: www.theleanmachine.org

 

Agility by delivering changes as ‘business as usual’ (extensive version)

Organizational agility developments

Many frameworks use the model ‘run the business’ (permanent teams doing the work) versus ‘change the business’ (work will be done by temporary groups of people). Projects and programs are managed via ‘change the business’. We see project and programme managers bringing people together for a definite period of time to make this happen. But in many cases we are confronted with budget overruns, delays and unhappy customers because what is delivered is not what they really need. As a reaction on these unsuccessful projects a group of people created the agile manifesto, and based on that several agile delivery frameworks were designed to help to deliver more successful projects.

This agile manifesto is embraced by many organizations and these organizations started to keep the people together who delivered e.g. a new system. These teams are able to deliver changes much faster by using Scrum, Kanban etc. These small focussed agile teams are self-organizing and are continuously learning to deliver more with the same people and within the same time-boxes. Collaboration is the norm. What these teams are delivering is managed by a product owner. It is the product owner who prioritizes the work to be done by maintaining a backlog with potential features and user stories. For these teams we don’t need a project manager to bring people together and structure and control the work. The members are already together, are self-organizing and can be seen as part of the ‘run the business’ side of the organization.

So for those changes that can be managed by a single agile team there is no need for a project manager. But in many occasions you need more than one agile team to implement the requested change. We need to scale up from a single agile team to many agile teams. The Scrum guide (developed by Ken Schwaber and Jeff Sutherland) gives some directions to use the scrum of scrums to align the teams and to make integration into one solution possible. In practice this works well for just a few teams, but what do you need if you have to make use of several component and feature teams to deliver one integrated solution? Scrum of scrums is not enough, you need a project manager to manage all stakeholders, all dependencies, the complexity and to deliver one integrated solution. Several organizations are on this level. They still run projects and project managers will make use of these permanent agile delivery teams.

Probable you could ask yourself, why do I want to make use of a temporary project manager? Is it not possible to have a permanent, maybe virtual, structure to take care of stakeholder management, dependency management and integration and have as a result a more or less continuous flow or at least short delivery cycles of changes bringing into production without ramping up and down project governance structures and teams.

You now see that several frameworks to support this level are being developed and used by many different organizations. To mention a few: Nexus developed by Ken Schwaber, Scrum at Scale developed by Jeff Sutherland, SAFe developed by Dean Leffingwell, the Spotify model copied by several organizations, Less developed by Craig Larman and Bas Vodde and there are many more. If you have implemented one of these frameworks the need for a project or programme manager will decline but on the other hand they can take new roles like roadmap manager, integration manager, release train engineer, value stream engineer.

Does this mean we don’t need any more project or programme managers? I think for the coming years we definitely need project and programme managers. In those cases, where we need more than the already existing permanent teams we have to build these non-existing teams. And these teams can of course make use of agile ways of working or just choose the for them most appropriate delivery method. If there is a need for a piece of specialist work we must select the right people and bring them together to deliver. This is typically a task for a project or programme manager. If you want to transform your organization, open new product/market combinations, integrate departments, or merge different organizations I expect that most of the organizations will not have permanent teams in place to handle this.

To support this way of working we see frameworks on project level (PRINCE2 Agile, DSDM AgilePM and PMI APM) and at programme level (MSP and DSDM AgilePgM). The competences of these project and programme managers have to change. where in the traditional way of working the focus was on project results using a formal mandate we now see a shift to business results realized by using influence without power. Stakeholder management becomes even more important with a focus on empathy, negotiations and persuasiveness. Servant leadership becomes key.

Here too, I see developments to reduce this type of project management work. Where we first saw integration of development and operations people into DevOps teams we now see the first BusDevOps multi-skilled teams where product management, marketing, development and ops people are in the same team and as a consequence again less projects and project managers.

dia1

Scrum or Kanban?

During the first part of a product life cycle the uncertainty is high and the focus is on goal driven iterations for the first product launch and market fit product. During this part of the life cycle Scrum is a great fit to cope with uncertainty and product iterations developed by the whole team. During the rest of the product life cycle the amount of uncertainty and change gradually declines. Here Kanban is a good fit. User Stories will be realized in a continuous flow by one or more of the individual team members.

When a major product upgrade has to be delivered by the whole team Scrum could be a better choice for that goal oriented iteration, otherwise Kanban stays a good fit.

To avoid the error prone handover and to shorten the time to market the Development and Operations teams can be integrated. Kanban is a good fit for the DevOps team. When to start with DevOps varies.

Agile portfolio management

Does this have consequences for portfolio management too? At this moment I have not seen any mature agile portfolio frameworks. The first framework that includes the portfolio level is the SAFe framework and DSDM included an agile portfolio management paragraph in their little book The Agile PMO.

In one of my previous posts I already proposed a change in the MoP framework to include the ‘run the business’ permanent agile teams in the portfolio view. If we want to reach more business agility, I strongly believe that we have to decentralize decision making. If we don’t and still want to make decisions at a higher more central level Standish ‘Cheetah’s Law’ is applicable and the speed of decision making could obstruct delivery success.

So for me the following aspects need to be taken into account to design an agile portfolio management framework:

Agile Portfolio Management Framework:

  • Strategy assessment
    • Internal and external environment assessment (SWAT)
  • Direction setting
    • Portfolio vision, goals and objectives
    • Portfolio management facilitates innovation as part of the roadmap
    • Portfolio management must move away from the iron triangle and focus on delivering value, capacity and time-to-market
    • Portfolio management must facilitate sustainable business change (People, Planet, Prosperity, Processes, and Products)
    • Close cooperation between enterprise architecture and portfolio management (addressing enabler epics (NFRs, technology drivers, innovations) to be part of the roadmap) to invest in (digital) technology to win, serve and retain customers
    • Portfolio management will have large impact on strategic decisions (achievability, technology trends)
  • Selection
    • Funding at value streams or permanent agile teams level and not at project or programme level
    • Funding must be aligned with the strategy or strategic themes. Enlarge or lower the number of agile teams must take place to align with the strategic themes
    • A short simple business case justification must be used to put epics on a portfolio backlog
    • The portfolio backlog epics must be prioritized based on attractiveness, risk or opportunity costs, time criticality and the duration. The weighted shortest jobs first (WSJF) from SAFe is a good example. Standish ‘Law of the eatable elephant’ is in line with this.
    • Epics can be business related as well as non-functional
    • Epics must be head and heart-driven, not just head-driven
    • Keep epics as small as possible but it must contain more than one feature
    • Number of epics in the roadmap must be WIP limited
  • Planning
    • Portfolio plans will be replaced by a portfolio backlog with epics and a rolling-wave portfolio roadmap (Roadmaps include six key elements: time frame, prioritized and identifiable outcomes, strategic themes, context-specific content, dependencies, investment outlay)
    • Starting point for a portfolio roadmap must be a portfolio vision
    • Rolling-wave portfolio roadmap must be a living document. Only the first part must be committed to make sure changes can be embraced
    • Portfolio roadmaps must have a cadence or heartbeat to increase throughput and integration moments/milestones to create learning loops
    • Portfolio roadmaps must show retrospective events
    • Portfolio roadmap achievability must be based on (group of) team(s) velocity and not on optimized resource utilization. 100% resource utilization will lead to a lot of busy persons but no delivery!
    • Portfolio roadmap must be approved by senior management and communicated to the organization
    • Must be a continuous integrated portfolio planning process with regular strategic reviews (included fact-based feedback loops) and pivot when needed
    • Portfolio roadmap development includes strategic option analysis / scenario planning
  •  Delivery
    • Portfolio dashboards must show the funding of value streams (and permanent agile teams) and the alignment with and budget allocation across the strategic themes
    • Portfolio dashboards must show progress on epic level. Details of epic break downs in features and user stories are not for the portfolio level (respect the decentralized decision making)
    • Focus must be on delivering value / benefits and not on OTOBOS (On Time, On Budget, On Scope)
    • Possible portfolio dashboards Key performance indicators and metrics (not limitative): productivity (feature lead time), agility (predictability, number of releases), quality (satisfaction, #defects), metrics for self-improvement, time to market, NPS
    • Use timely, accurate, and relevant information based on real time (automated) performance data, avoid manual aggregation
    • Portfolio dashboards must show data-driven recommendations for decisions
    • Portfolio dashboard reporting at anytime
    • Dependency management on epic level (inter and intra dependencies)
    • Doing the right things (metrics on effectiveness), Doing it right (metrics on process efficiency). Compare over more than one period
    • Customer feedback to evaluate the effectiveness of the roadmap
    • Portfolio dashboard reporting creates transparency and will motivate stakeholders
    • Integrated tooling (EA and PPM) must give real time insights (rich information) about the health of initiatives, capacity and what-if scenario analysis corresponding with the requester’s role

Behaviour

  • Senior management commitment (much more leadership, less management)
  • Decentralized decision making
  • End-to-end transparency
  • Inspect regularly and adapt where needed
  • Feedback is crucial
  • Empowered employees
  • Culture of collaboration (remove silo’s)

Looking forward to your comments and adjustments so we can co-create a new agile portfolio management framework.

  • Updates:
    • 30-09: added Scrum or KanBan paragraph
    • 30-09 Agile Portfolio Management Framework

 

Boekrecensie: Het projectassistentboek

9789462154438-480x600Boeken voor projectondersteuners, projectassistenten, PMO’ers zijn er niet veel. Het PMO als pop-up shop zou je daaronder kunnen rangschikken. Het boek ‘Het projectassistentboek. Jouw rol en positie in projecten’ geschreven door Pieter Hoekstra, Peter Vos en Jakob Zwinderman past prima in dit rijtje.

Het boek is onderverdeeld in negen hoofdstukken waarin de positie van de projectassistent wordt belicht, een introductie projectmanagement wordt gegeven en vooral wordt ingegaan op de noodzakelijke kerncompetenties van een projectassistent zoals samenwerken en beïnvloeden, communiceren, feedback geven en ontvangen, omgaan met conflicten en het slim gebruiken van tools. Het boek wordt afgesloten met een aantal bijlagen waarin naast eenvoudige templates, een aantal handige vragenlijsten worden aangeboden, waaronder het opstellen van je eigen invloedprofiel aan de hand van een veertigtal uitspraken.

In het eerste hoofdstuk (Dans met de projectleider) wordt je eigen positie als projectassistent duidelijk en wat dat betekent voor de samenwerking met de projectleider. Het belang van een samenwerkingscontract wordt toegelicht (template in de bijlage).

Het tweede hoofdstuk geeft enige basiskennis van projectmanagement zoals fasering en de GOTIK-factoren en de vier, volgens de auteurs, leidende projectdocumenten: projectopdracht, projectplan, voortgangsrapportage en projectevaluatie.

Hoofdstuk 3 stelt het situationeel kunnen toepassen van verschillende beïnvloedingsstijlen centraal en gaat in op communiceren, luisteren, samenvatten en doorvragen. Wanneer moet je overtuigen, aansporen, onderzoeken of juist inspireren? Het hoofdstuk wordt afgesloten met een vijf stappenplan om een andere invloedstijl uit te proberen. Aansluitend gaat hoofdstuk 4 in op de verschillende niveaus van communicatie en krijg je inzicht hoe je De roos van Leary kan gebruiken om gedrag van anderen te koppelen aan je eigen gedrag.

Hoofdstuk 5 gaat in op je eigen timemanagement inclusief plannen en prioriteiten stellen en hoe dit beïnvloed wordt door je eigen voorkeursmanier(en) van werken. De auteurs gebruiken hiervoor het acroniem SCHOP (Solist, Creatieveling, Helper, Optimist en Perfectionist).

Hoofdstuk 6 helpt je bij het realiseren van een ideaal projectteam. Welke stappen moet je met elkaar zetten om meer uit het team te halen en welke teamrollen kent het ideale team (organiseren, creëren, stimuleren, produceren en controleren). Om het ideale team te bereiken ontkom je niet aan feedback. Hoofdstuk 7 geeft een aantal handvatten voor het geven en ontvangen van feedback.

In hoofdstuk 8 geven de auteurs een toelichting op het ontstaan van conflicten, de mogelijke positieve of negatieve gevolgen van een conflict en hoe je met een conflict moet omgaan. De vijf conflictstijlen (wedijveren, vermijden, aanpassen, compromis zoeken en samenwerken) worden besproken.

Het laatste hoofdstuk zoomt in op de tools. Tools die je helpen om het project te structureren en beheersbaar te maken zoals een actielijst, documentenbeheer (vaak onderbelicht), communicatie en planning.

Conclusie: een helder geschreven boek waarin de theorie verduidelijkt wordt aan de hand van een case, verluchtigd met plaatjes van schilderijen en cartoons, en voorzien van vele tips, overzichtelijke werkbladen en handige tools voor de projectassistent. Ook een prima boek voor de startende projectleider die gaat samenwerken met een projectassistent.

Wel een boek wat het traditionele projectmanagement, lees een watervalaanpak, centraal stelt. Ik had graag gezien dat de auteurs ook een specifiek hoofdstuk hadden gewijd aan de rol van projectassistent bij een agile traject.

Bestellen: Het projectassistentboek