Tag Archives: review

Review: Manage your project portfolio

9781680501759-480x600Johanna Rothman wrote the book Manage your portfolio Second edition – Increase your capacity – Finish more projects. A book for the more professional portfolio manager or as mentioned on the back of the book: Expert skill level.

If you are facing too many projects, if firefighting and multitasking are keeping you from finishing any of them, this book will help you to manage your portfolio. It makes use of agile and lean ways of working and brings the biggest benefits when you are running your projects in an agile way too. Projects become to be delivered features and evaluation means prioritizing feature sets. In the quick reference card, I highlighted the way the author promotes the usage of Kanban boards to manage your portfolio and it visualizes some of the decisions to be taken.

Manage your portfolio (QRC, 171017) v1.0

To download: Manage your portfolio (QRC, 171017) v1.0

The author divided the book in fourteen chapters and these chapters gives you a step by step approach to build your portfolio. All chapters end with several situations and possible responses to try.

  1. Meet your project portfolio: It’s not your customer who cares about your portfolio. If you are facing issues to finish projects, if you want to deliver faster, more often and qualitative good products to your customer, you need a portfolio
  2. See your future: by managing your portfolio you make the organization’s choices transparent. It becomes clear what to work on first, second, third. It will help to avoid multitasking. What does it mean if you apply lean approaches to your project portfolio? You must think in terms of value, let teams work in small chunks that they can handle and complete
  3. Create the first draft of your portfolio: start collecting all the work before you attempt to evaluate and determine whether you need to do it now. When needed organize sets of projects into programs. Divide your projects in feature sets or Minimum Marketable Features. Not all feature sets are equally important.
  4. Evaluate your projects: the very first decision is about whether you want to commit to this project, kill the project, or transform the project in some way before continuing. If you don’t want to commit but you can’t kill it either put the project on a project parking lot (name, data, value discussion and notes) so you don’t lose track of it.
  5. Rank the portfolio: You can use many methods to rank. The author discusses the rank with Cost of Delay, business value points (divide a total number of points across your projects), by risk, organization’s context, by tour product’s position in the marketplace or by using pairwise comparison, single or double elimination.
  6. Collaborate on the portfolio: Making portfolio decisions is never a single person’s decision. Facilitate portfolio evaluation meetings.
  7. Iterate on the portfolio: Set an iteration length for your review cycles. This cycle length is affected by your project life cycle (agile delivery gives you the opportunity to have shorter review cycles), your product roadmap, and budgeting cycle.
  8. Make portfolio decisions: Conduct portfolio evaluation meetings at least quarterly to start with, decide how often to review the project parking lot. How are you going to cope with advanced R&D projects? Build a project portfolio Kanban (create backlog, evaluate, project work, assess/validate and maintain) to manage your portfolio.
  9. Visualize your project portfolio: Create a calendar view of your projects with predicted dates. Show not only your staffed projects but your unstaffed work too.
  10. Scaling portfolio management to an enterprise: What are the consequences of resource efficiency thinking (100% resource utilization is 0% flow)? How can you scale by starting bottom up or top down? You need both but scale with care. Do you know your enterprise’s mission or strategy otherwise it will be very difficult, if not impossible to make large decisions? Set up a corporate project portfolio meeting to answer the questions which projects help to implement our strategy and which project distract us from our strategy.
  11. Evolve your portfolio: Using lean can help you to evolve your portfolio approach. What does it mean if you stabilize the time-box or the number of work items in progress (see Naked planning video too).
  12. Measure the essentials: for a lean or agile approach consider the following measures: team’s velocity (current and historical), amount of work in progress (cycle and lead time, cumulative flow), obstacles preventing the team to move faster (how long in progress), product backlog burn-up chart, run rate. Never measure individual productivity.
  13. Define your mission: Brainstorm the essentials of a mission, refine the mission (specify strong verbs, eliminate adverbs, avoid jargon), iterate until you feel comfortable, test your mission, make the mission real for everyone.
  14. Start somewhere…but start!

Conclusion. Johanna Rothman wrote a must read for portfolio managers who are struggling with their role when their organization is moving towards more business agility, with more and more permanent agile teams in place but also for the traditional portfolio manager, facing too many projects and almost no delivery to get hands-on practical advice to start organizing their portfolios.

To order: Manage your portfolio Second edition – Increase your capacity – Finish more projects.

Naked Planning Overview by Arlo Belshee

Arlo was one of the first to lay-out the inspiration for Kanban systems for software development.
Advertisements

Review: The Scrum Culture

9783319118260-480x600The Scrum Culture – Introducing Agile Methods in Organizations by Dominik Maximini is a book that starts were most of the agile or Scrum books stop. You can send people to Scrum training classes but what does it mean if you want to use Scrum in your organization? The official Scrum guide is only sixteen pages, thus how difficult can it be? Is it that simple or are we talking about a transition of several years?

Probably the biggest root cause for failed agile transitions is the fact of misalignment between the needed agile mindset and the organizational culture.

The book is split in four parts. In the first, more theoretical, part the author evaluates different organizational culture models, explains his research and ends with a definition of the Scrum culture.

The following organization culture models are explained:

  • Harrison’s culture model (high/low formalization versus high/low centralization: role orientation, task/achievement orientation, person/support orientation, power orientation)
  • Deal and Kennedy’s culture model (fast/slow feedback versus high/low risk: work hard/play hard, tough guy/macho/stars, bet-your-company, process)
  • Schneider’s culture model (Actuality/possibility versus personal/impersonal: collaboration, control competence, cultivation)
  • Cameron and Quinn culture model (flexibility and discretion / stability and control versus internal focus and integration / external focus and differentiation: Clan (collaborate, adhocracy (create), market (compete), hierarchy (control))

The author compared traditional organizations and agile organizations (based on Gloger and Häusling) to highlight the cultural differences:

Traditional organization Agile organization
Position Role
Expert Generalist
Team lead Scrum Master (agile coach)
Product / Project Manager Product Manager / Product Owner
Responsibility of line management: Team, daily operation Responsibility of line management: Individual (focus intrinsic motivation), strategy
Passiveness Activeness
Planning of uncertainty over a long time horizon Planning for a short and clear time horizon
In-transparency Transparency
Presence Accomplishment
Customer as an alien Involvement of customers
Delegation of responsibility Adoption of responsibility
Control Self-responsibility – positive idea of man

A transition to a more agile organization will have an impact on the following categories: management and leadership, decision making, cadence and speed, planning, focus on productivity, soft factors, hierarchy and organization structure.

The second part is about the theory of introducing Scrum. The author discussed several shapes of Scrum, their advantages and disadvantages: Scrum PRN (pro re nata: take as much as needed), virtual Scrum software studio, Scrum software studio, façade Scrum, profound Scrum, and sustainable profound scrum.

Part III structures the way to introduce (your chosen shape of) Scrum. Will you use a bottom-up, a top-down or submarine approach?

The author uses Kotter’s eight steps for organizational change to explain what you must do to introduce and embed Scrum in your organization. In part IV we get a case study following the same eight steps.

Every step is explained in a separate chapter and you get explanations, pitfalls, do’s and don’ts. At the end of each chapter you get an overview with things you must remember for that specific step.

  • Creating a sense of urgency
  • The guiding coalition
  • Vision and strategy
  • Communicating the change vision
  • Empower your employees on a broad basis
  • Generate quick wins
  • Consolidate gains and initiate further change
  • Anchor new approaches into the corporate culture

Conclusion: If you are responsible to lead a transition to become more agile this book is a must read.

To order: The Scrum Culture – Introducing Agile Methods in Organizations

Review and summary Lean UX

9781491953600-480x600Lean UX, as described by Jeff Gothelf and Josh Seiden (Lean UX – Designing Great Products with Agile Teams, 2nd edition, 2016) is the evolution of product design and team collaboration. It takes the best parts of the designer’s toolkit, combines that with Agile software development and Lean Startup thinking, and makes all of this available to the entire product team.

Lean UX contains principles, a process and many tools and techniques (see the QRC Lean UX too).

The Lean UX principles

The foundational principles for Lean UX are the core attributes that any Lean UX team should strive to embody. Lean UX principles can be organized into three groups: principles to guide team organization, process and culture.

Principles to guide team organization are:

  • Cross-functional teams
  • Small, dedicated, co-located
  • Self-sufficient and empowered
  • Problem-focused team

Principles to guide culture:

  • Moving from doubt to certainty
  • Outcomes, not output
  • Removing waste
  • Shared understanding
  • No rock stars, gurus, or ninjas
  • Permission to fail (see YouTube video)

Principles to guide process are:

  • Work in small batches to mitigate risk
  • Continuous discovery
  • GOOB (getting out of the building): the new user-centricity
  • Externalizing your work
  • Making over analysis
  • Getting out of the deliverables business

The Lean UX Process

The lean UX process is a iterative cycle with four steps:

  1. Outcome, assumptions, hypotheses
  2. Design it
  3. Create an MVP
  4. Research & Learning

The first step Outcome, assumptions, hypotheses is about driving vision with outcome by defining the Project’s problem statement. Declare assumptions (4 types: Business outcomes, Users, User outcomes and Features) and transform assumptions into hypotheses (tactical and testable).

During step two Design it, you build a shared understanding, generate and converge ideas by using:

  • Design Studio: problem definition and constraints, individual idea generation (diverge), presentation and critique, iterate and refine in pairs (emerge), team idea generation (converge)
  • Design systems, style guides, collaborative design sessions, and simple conversations

In step three create an MVP you build the smallest thing you can make to learn whether your hypothesis is valid.

  • Creating an MVP to understand value: get to the point, use a clear call to action, prioritize ruthlessly, stay agile, don’t reinvent the wheel, measure behavior
  • Create an MVP to understand implementation: be functional, integrate with existing analytics, be consistent with the rest of the application
  • Final guidelines for creating MVPs: it’s not easy to be pure, be clear about your learning goals, go small, you don’t necessarily need code, the truth curve
  • Examples of MVPs: landing page test, feature fake (aka button to nowhere), Wizard of Oz
  • Prototyping: paper, low-fidelity on-screen mockups, middle- and high-fidelity on-screen prototypes, coded and live-data prototypes.

In the final step, Research & learning the team is looking for feedback and performing research.

  • Collaborative discovery: as a team review, decide who to speak, create interview guide, break your team into research pairs, arm each pair with a version of the MVP, meet the customer, interview and take notes, begin with questions, conversations, and observations, demonstrate the MVP, collect notes and customer feedback, switch roles
  • Continuous learning: three users every Thursday, simplify your test environment, making sense of the research
  • Monitoring techniques: customer service, on-site feedback surveys

Lean UX (QRC, 170812) v1.0

Download QRC Lean UX: Lean UX (QRC, 170812) v1.0

The book is divided in three parts. The first part introduces Lean UX and explains the principles. The second part explains the process. The last part focusses on Lean UX in your organization. How can you integrate Lean UX and agile (staggered sprints, design sprint, dual-track Agile), what organizational shifts are needed to comply with the principles and to integrate Lean UX. The book ends with several case studies.

The reason I read this book is related to a next Leading SAFe 4.5 training class I will give. The new version SAFe 4.5 moved from UX to Lean UX and expanded on user experience development. SAFe 4.5 uses a slightly adjusted Lean UX process:

  1. Outcome hypothesis
  2. Collaborative design
  3. Build MMF (Minimum Marketable Feature, SAFe uses the MVP in the Lean Startup Cycle)
  4. Evaluate

As a SAFe Certified Consultant, I would say a must read and not only for trainers. The book is easy to read and contains a lot of explanation and examples.

To order: Lean UX – Designing Great Products with Agile Teams

Why do you need to fail – by Derek Sivers

Organisation mindset

Many organizations are struggling with the transition to become more agile. I see organizations starting with a number of permanent agile teams and asking themselves after a while why the expected benefits are not there? Did they choose the wrong scaling agile framework? Maybe, maybe not, it probably has to do with the fact that the mindset of the organization is still the mindset of an organization in the traditional world.

I came across a website focussing on this mindset.

Alex Yakyma, founder of ORG mindset, created a model to help you with your transition towards more business agility (implementing Lean and Agile at scale) by focussing on the needed mindshift in your organisation. Without this mindshift, more business agility will be very difficult to achieve, adding more agile practices will not help.

ORG mindshift with their corresponding model will help you with tools and addoption paterns that address the mentality first and allow to build a successful Lean-Agile enterprise. Nowadays you need a mindset that embraces complexity (Lean-Agile mentality)  in stead of a mindset to cope with sequencial industrial systems. In the old world we see anti-patterns such as Outputs over Outcomes, obsession with predictability and metrics et cetera (Reductionist mentality).

Schermafdruk 2017-06-24 10.43.25If you go to the website (orgmindset.com) you get the model with icons (and hyperlinks to the details behind the icons).

Exploit variability  explore economic opportunities: Variability entails high-payoff opportunities.

Minimize Constraints to collaboration: Change is inevitable, and the more flexible the structures that foster collaboration the easier the task. Avoid management’s compartmentalized thinking.

Build sustainable practices: Don’t over-emphasize early wins but focus on benefit-constraint, feedback loops, practice maps, embedded menthal models and shared cognition.

Align Mental Models: we never directly operate with a phenomenon, but through mental models.  As a change agent you have to identify problems with mental models in their organization and fix them (accuracy, different people, different models, blind spots).

Besides this model the website offers research, presentations and course information to become an Org Mindset Enterprise Coach (OMEC).

Conclusion: When you are starting or in the middle of a transition to become more agile this site is definitely worthwhile to visit and gives you some food for thought.

Scaled Agile just released SAFe 4.5 (SAFe for Lean Enterprises)

SAFe 4.5 can be configured for four development environments (Essential SAFe (simplest), Portfolio SAFe, Large solution SAFe and Full SAFe (most advanced) and SAFe 4.5 is backwards compatible with SAFe 4.0 (available through June, 2018).

PRINT-4.5-BP-FULL-Configuration-8.5x11The big picture is a little bit more user friendly (some details / icons are taken out) and you can select the environment you want to use (and as a result the picture will only show the corresponding parts). I think some more icons on the big picture can be removed too if Scaled Agile creates a specific big picture on their homepage for their online knowledge wiki which contains hyperlinks to all topics. A big picture to explain SAFe can work without icons for SPC, Lean-Agile Leaders, the implementation Roadmap and topics like the Continuous Delivery Pipeline.

Most important changes:

  • Faster innovation with Lean Startup and Lean UX
  • Epic Value Statement and Light weighted Business Case are replaced by Epic Hypothesis Statement and Lean Business Case
  • Feature delivery with Scalable DevOps and Continuous Delivery Pipeline
  • SAFe implementation Roadmap
  • Value Stream has been changed to Solution (Value Stream Backlog > Solution Backlog, Value Stream Engineer > Solution Train Engineer, …) and a Solution Train has been added (several ARTs and Supplier forms one Solution Train)
  • Compliance has been added to the Solution Intent
  • Program Portfolio Management (PPM) has been replaced by Lean Portfolio Management
  • Increased alignment with the Scrum Guide

Impact on my book Scaling Agile in organisaties is minor. For the coming year, SAFe 4.0 is still valid. In the next print of my book I can make adjustments regarding the name changes (Value Stream, PPM). The SAFe Implementation Roadmap was already incorporated and topics like faster innovation with Lean Startup can be added.

More information on SAFe 4.5 can be found on www.scaledagileframework.com. At the homepage you can with to SAFe 4.0 too.

Book review: The Principles of Product Development Flow

51PdVCFcp3L._AC_US436_QL65_Don Reinertsen wrote the book The Principles of Product Development Flow – Second Generation Lean Product Development.

A very complete book that describes the underlying principles that create flow in product development processes. After reading this book I now understand why in the SAFe methodology and corresponding training material there are so many references to this book. The eight major areas focus on practical methods to:

  • improve economic decisions
  • Manage queues
  • Reduce Batch size
  • Apply WIP constraints
  • Accelerate feedback
  • Manage flows in the presence of variability
  • Decentralize control.

I find many concepts and methods that are present in the SAFe framework too. E.g. economic objectives, cost of delay, economic batch size based on transaction and holding costs, queues, CFD, little’s law, variability, batch size, synchronization, Weighted Shortest Job First (WSJF) and many, many more.

The book follows the already mentioned eight major areas and you get for each area a set of principles explaining that specific area. Each principle is explained in detail including examples. In total, you get 175 principles explained.

Conclusion: this book is definitely a must read. If you want to improve or create the flow in your product development process start with this book. If you are using SAFe this book gives you a lot of background and explanation behind specific methods and principles that are included in SAFe.

An introduction to Lean Product Development Flow given by Don Reinertsen at Adventures with Agile in London, September 2015.

To order: The Principles of Product Development Flow

Book review: The Agility Shift

9781629560700-480x600Pamela Meyer is the author of the book ‘The Agility Shift. Create Agile and Effective Leaders, Teams, and Organizations’. Not a book about an agile framework but a guide to help organisations and their leaders and employees to make a shift to the right in terms of Bob Marshall’s right shifting model to become more effective, to become more agile!

The book is divided in three parts. Part one covers the understanding and dynamics of the agility shift by explaining what and why, by weaving the relation web for agility and discovering the five dynamics of the agility shift. Part two explains what it means to make the agility shift at all levels of the system. Talking about the agile leader, the agile team and the agile organisation. Part three focusses on putting agility into work. How can you shift to agile learning and development and recruiting, reinforcing, recognizing and retaining your agile talent?

Agility shift can be summarized by the three C’s: Agility Competence, Agility Capacity and Agility Confidence and is first and foremost a shift in mind-set. A shift from the false comfort of “a plan” to achieving a state of readiness to find the opportunity in the unexpected. To build this readiness you can make use of your own Relational Web.

Dia3

To download the QRC The Relational Web: The agility shift web

Becoming an agile leader asks for a leadership mind-set for agility, whole-person agility and learning agility. To build a team make use of lessons from improvement, high-stake and development teams: work with the same understanding of the givens, agree to the givens, practice gift giving, practice finding the game, provide opportunities for interaction, make communication and coordination expectations explicit, expect role elasticity and learning agility, develop resource awareness, practice rapid prototyping: fail faster, learn quicker, work at a sustainable pace and capacity, create an agile manifesto for your team.

When agile leadership and the first teams are in place you can start co-creating the agile organisation by weaving the organisational relational web (create groups that foster employee camaraderie, maximize your relational web potential, and improve the proximity between members of your relational web), Structuring for the agility shift (create opportunities to identify the bare spots, get input on barriers and enablers, and resist the urge to formalize) and las but not least expand engagement to build capacity for decision making (empowerment) and converge planning and action to maximize your organizational agility.

The last part explains what the shift means for agile learning and development and recruiting, reinforcing, recognizing, and retaining your agile talent. You get an overview of competencies, skills and practices and performance indicators as well as a helping aid for recruiting for agility with sample conversation topics/scenarios and questions and tips to listen and look for specific performance indicators.

Conclusion: No matter what agile framework you are using, this book will bring you above the level of framework techniques and gives you helpful insights to become more agile. A must read for agile leads!

To buy: The Agility Shift