‣ In Push Organisations:
‣ Decision making in isolation
‣ Lack of visibility and transparency
‣ Unclear expectations and goals
‣ Lack of economic prioritisation of projects and
misalignment with strategic goals
‣ Lack of Empowerment and Enablement of
Employees to meet Expectations
‣ In Pull Organisations:
‣ Teams self-organise based on Capacity and Capability
‣ Equal contributors to the Problem-Solving process
‣ Maintain their Commitment
‣ Create engaging environment w/ passion and
‣ Probabilistic Planning & Forecasting
‣ Smooth journey from concept to cash
Pre-Project Feasibility Foundation Post-ProjectDelivery Deploy
Pre-Project Feasibility Foundation Post-ProjectDelivery Deploy
‣ Merits in managing your Portfolio:
‣ Identify which projects are blocked
‣ Raise awareness of the bottlenecks
‣ Align projects with teams
‣ Highlight the current workload
‣ Resolve interdependencies
‣ Prioritise projects based on economic drivers
‣ Visualise the stage of each project in the portfolio
‣ Classify projects by their nature using colour aids
‣ Set WIP Limits:
‣ Balance the demand for more work with the
capacity to deliver quality products
‣ WIP Limits create a coordination mechanism
‣ Enable a pull-based system
‣ Sustainable teams working in a productive and
‣ WIP Limits signal availability & expose issues
‣ Focus on ﬂow and not on utilisation
“Avoid futility of endless busyness, make time to
renew, find time gaps to reflect, take advantage
of slack to respond to change.
– Stephen Covey
“Economies of scale is a myth.
Economies are in flow.
– John Seddon
‣ Prioritisation made on economic value (e.g.
Cost of Delay, Cost of Carry, Real Options)
‣ Identify and manage different types of projects
(e.g. S/M/L or Internal/External)
‣ Understand your system (Cumulative Flow
Diagrams, Lead Time Distributions)
‣ Manage your portfolio with valuable data
‣ Accurate Probabilistic Forecasting of Project
‣ Detailed work at team-level board
‣ Interfaces well with Scrum Teams:
‣ Tickets in this board form the Sprint Goals or
the Sprint Backlog Stories
‣ PSI from Scrum Teams contribute towards
‣ Regularly prioritised backlog based on business value
‣ Deﬁnition of Done for each stage aligned to the products
‣ Eg.: a policy for moving between Feasibility and
Foundations would be to have completed the
‣ Outline Business Case
‣ Risk Assessment
‣ Outline Solution
‣ Feasibility Prototype (opt.)
‣ Outline Plan
‣ Project Approach Questionnaire
We keep seeing a set of challenges in the PMO, which could be addressed by some Kanban principles and techniques. The majority of techniques and practices that we see in Agile Project Management tend to be visible at the Team / Delivery level. However, at the PMO level, even if we consider ourselves Agile orgs, we see a lack of robust and solid Agile practices (instead we see spreadsheets, internal memos, gantt charts, poorly-defined KPIs). We are introducing some Kanban ideas to help the PMO. Let's start with some provocative questions to set the scene.
Can we deliver true business value faster, with more transparency, more visibility and far more commitment in our organisation? Do we need a magic wand to achieve this? Faster means focus on value-add and quality. It’s not just about doing work, it’s about doing valuable work that benefits the end user.
Why do maturing companies face issues with Productivity, Quality, Morale and Time-To-Market? Is work fun? Can we really create a creative and collaborative environment without fear?
Why do Product Development Projects miss their Economic Objectives? Have we miscalculated ROI, or NPV, or disregarded our important data from within or outside our team, front-line employees? Do we suffer from output myopia?
We are drowning in waste. Can we decrease wasteful activities 98% across our portfolio? How many meetings that you attend are not adding value? Do you spend time dealing with your inbox trying to get a project update rather than actually doing work?
Can we offer any key takeaways for the office tomorrow, so you start thinking different ways to improve your PMO?
We have identified the issues based on how organisations operate. Have they implemented systems with pull or push strategies? Most of us work in a 'push' environment. Usually, the choice of 'push strategies' is not even conscious. You will be surprised that many people, even the majority of you sitting here, think this is the norm and -somewhat- the only option they know. Lucky those who work in an 'orange' beaker. In a push environment, we can feed the organisation with so many projects that the organisation constipated (#organisational constipation) In a pull environment, we value completing work and only start new work when we have the capacity; 95 projects in organisations w/ less than 20 developers; False focus on the delivery throughput of developers, remedy: ‘make’ them agile, whereas the root cause of the issue was too many projects in progress.
Scope is defined in the background; 3-year old project green / last-minute: red; Team members are pushed to directions most likely to benefit the organisation, not the individual; Delivery expectations are set in disconnect to real-time input / data; While driving organisational results, tend to experience most employee dissatisfaction, lack of true engagement, shrinking talent recruitment pools [Glassdoor]; 'Outcome Myopia': discretionary effort and levels of engagement; Org. Division: us vs them; Self-perpetuating cycles: employee resistance, management pushes harder, more resistance, more 'push'; How many of us believe that our colleagues can do more than their current positions?
One key aspect we can see in pull organisation is a hybrid of flow/velocity; Probabilistic (non-velocity driven); where the journey of from the ideation stage to deploy and post-project analysis is explicit and visible;
In our example, let’s have a look at DSDM as project lifecycle; We combine the best attributes of DSDM Lifecycle Process with the distinctive approach of the Kanban Method, introducing Transparency, Visibility, Predictability and Visualisation in the PMO. We harness the best of the two worlds, combining an enterprise-level framework with a lightweight knowledge work management system. New DSDM Lifecycle Process. Release: May, 2014.
The DSDM Framework could be visualised in the form of a workflow.
Caveat: Tickets do not change through the flow. We just liked how they appear visually. This is just for presentation purposes to highlight the state! Kanban Myth: We do not really need the board. We need to dissociate that kanban is just a board. In the initial inceptions of Kanban, there wasn’t a board (refer to DJAA Case Study); This org, it shows projects in motion. Crammed with work
Every stage: instead of a spreadsheet, information radiator Projects Blocked: Internal agreement on when the project is flagged red Bottlenecks: reconcile demand and supply / hire more talent; Teams: Shared-resource model
In order to avoid system overcrowding and stalling, we introduce a range of WIP Limits (min / max); PIP Limit; NOTE: show broken limits (red)
Sustainable Teams = Productive (and Predictable) Environment, suitable for Knowledge Work and Innovation;
- How infrequent is it to stop, reflect and introduce change in the PMO?
- Let's investigate the merits of Flow.
Manage your portfolio with valuable data Prioritisation made on economic value (e.g. Cost of Delay, Cost of Carry, Real Options) Identify and manage different types of projects (e.g. S/M/L or Internal/External) Understand your system (Cumulative Flow Diagrams, Lead Time Distributions) Accurate Probabilistic Forecasting of Project Completion
Expedite Projects cause Business Critical Impact Expediting provides a means to respond Swarming on the project ACT!
Visualise and Manage Team Workloads Focus on completing projects Avoid project multi-tasking Coordinate multi-project deployments
Detailed work at team level board Regularly prioritised backlog based on business value Interfaces well with Scrum Teams. Tickets in this board form the Sprint Goals or the Sprint Backlog Stories PSI from Scrum Teams contribute towards Deploy phase
Sources of Dissatisfaction: rough idea of the problem/scope? stakeholders in the presumed system + customers? wider organisation? Demand & Capability: “what to whom, and why”, do we have idea about how work flows from one boundary to the other? Model Workflow: DSDM. questions to challenge this workflow? Discover Classes of Services: an internal tool for organising and scheduling work, OR an approach to explore customer expectations? Design KBN Systems: how to scale success? big bag implementation OR start small and expand to the rest of the Portfolio? Physical VS Electronic.