Tag Archives: Agile

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

Recensie: Agile HR – De (on)misbare rol van HR in wendbare organisaties

9789492790026-480x600Willemijn Boskma, Minke Buizer, Nienke van der Hoef, Gidion Peters en Willy Zelen hebben het boek Agile HR – De (on)misbare rol van HR in wendbare organisaties Geschreven.

Een vlot geschreven boek, gelardeerd met vele voorbeelden, dat je makkelijk in een keer uitleest. Het boek bestaat uit vier delen waarbij twee invalshoeken zijn gekozen. Enerzijds krijg je voorgeschoteld welke rol HR kan spelen in organisaties die een agile transitie door (willen gaan) maken zoals HR als aanjager van de verandering en HR in een organisatie met wendbare teams. Anderzijds wordt beschreven wat het betekent als je HR-afdeling zelf meer wendbaar wilt zijn. Dit deel is ook prima te gebruiken als je behoort tot een andere afdeling zoals bijvoorbeeld Juridische zaken of inkoop et cetera en je wilt de slag naar meer agile zijn, maken. Verder vind je een deel over de toolkit (o.a. apps) voor Agile HR. De delen sluiten af met een opsomming van experimenten die je kunt starten.

In het eerste deel staat het perspectief van de organisatie centraal. Welke nieuwe rol en plek van de HR-competentie en HR-professionals kan/moet ingenomen worden als de organisatie meer wendbaar gaat werken? De volgende rollen worden besproken:

  • Employee experience (EX) ontwerper
  • Purpose-ontwikkelaar
  • Werkgeluk-ontwikkelaar
  • Agile coach
  • Trendvertaler

Het tweede deel zet de HR afdeling zelf centraal. Wat betekent het als de HR afdeling zelf meer agile en flexibel gaat werken? Welke stappen kan je zetten naar meer wendbaar werken? Hoe kan je je dagelijkse werk organiseren onder gebruikmaking van Scrum of Kanban? Wanneer gebruik je Scrum, wanneer Kanban? Hoe kan je overzicht en sturing creëren over alle lopende projecten voor niet-IT-teams onder gebruikmaking van agile portfolio management (AgileTPM)? Wat betekent het als je met duidelijke rollen en verantwoordelijkheden in lijn met Holacracy, gaat werken? En tenslotte krijg je uitgelegd hoe je meer wendbaar kunt vergaderen (doelgericht, wendbaar en flexibel, gezamenlijke verantwoordelijkheid en transparant).

Deel drie beschouwt de impact op HR als er in de organisatie gewerkt wordt in agile teams. Zelf organiserende teams die steeds autonomer worden en daardoor ook verschillende HR-competenties zelf gaan invullen. Welke taken en verantwoordelijkheden blijven centraal belegd, welke kunnen de teams zelf op zich nemen? Wat is eigenlijk een zelf-organiserend team, welke vormen van zelf-organisatie zijn er? Wat zijn de mogelijkheden van zelfbeloning? Hoe promoot en faciliteer je agile leiderschap (coachen vanuit vertrouwen, voorbeeldgedrag en transparantie, heldere kaders en opdrachten, stimuleren van experimenten en beschermen van teams en medewerkers). Alle onderwerpen worden voorzien van vele tips.

Het laatste deel biedt inzicht in trends en ontwikkelingen gezien vanuit een agile HR. Je krijgt een scala van tools die de HR-professional ter beschikking staan (inclusief verwijzingen naar websites waar meer informatie over specifieke tools is te vinden). De toolkit is onderverdeeld in tools en tips (mee starten, loslaten of stoppen) verdeeld over de aandachtsgebieden recruitment, leren en ontwikkelen, functioneren en beoordelen en HR-analitics.

In het boek vindt je verder verwijzingen naar een tweetal tests: Agile HR volwassenheidtest en de team scan (zie www.agilehrtest.nl)

Over de team scan is geen gedetailleerde informatie te vinden op de site. De volwassenheid test biedt je inzicht in vijf dimensies: bewustzijn van klant en leverancier, ontwikkeling van zelf-organiserende teams, ontwikkeling van HR instrumenten, HR als groep en de rol in agile transities.

Conclusie: Een aan te bevelen boek als je aan de vooravond of middenin een agile transitie zit. Door vanuit de HR bril naar de transitie te kijken krijg je inzicht wat er allemaal nog meer komt kijken naast het kiezen van een agile framework en het benoemen van een aantal agile teams. Ik ben ervan overtuigd dat deze nieuwe inzichten de kans op een succesvolle agile transformatie vergroten.

Bestellen: Agile HR – De (on)misbare rol van HR in wendbare organisaties

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

Goal Driven Agile

Schermafbeelding 2016-12-15 om 11.09.35In my latest book Scaling agile in organisaties (in Dutch) I described around 30 (scaling) agile frameworks. All these frameworks are there to scale the product delivery by organizing the way how more and more agile teams can work together.

I came across a whitepaper from Xebia describing a new framework: Goal Driven Agile. This approach is not about scaling delivery but about scaling Business Agility.

Goal Driven Agile 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.

Goal Driven Agile (QRC, 170902) v1.0To download the QRC: Goal Driven Agile (QRC, 170902) v1.0

Roles

  • Department lead: Maximize goal value & achievement per department
  • Value stream lead: Maximize goal value & achievement per value stream
  • HR lead: Maximize goal achievement potential
  • Team: Maximize effectiveness towards achieving goals
  • Coach: Internalize the framework

Building blocks

  1. Department ambition
  2. Department change portfolio meeting
  3. Value stream ambition
  4. Value stream portfolio meeting
  5. Value stream performance meeting
  6. Team goals
  7. Team performance meeting
  8. Role performance meeting
  9. Impediment cascade
  10. Goal driven culture

Structure

The diamond showing the five roles and the relations.

In one diamond, you can have four value streams. Every value stream can have max four teams. One team consists max 9 people (Scrum team) you can have 144 team members, 1 Department lead, 4 Value stream leads and 4 HR leads. In total 153 people (compare with the ‘Dunbar’ number of 150).

The diamond shape can be multiplied to scale-up by using the Department lead as the central point to add more diamonds, but only in case when there are shared goals. Such a super diamond structure contains 600 people and these can be scaled-up too.

Conclusion

I am looking forward to case studies using this set-up. I am curious to know how autonomy works out in a situation with both the Value stream lead as well as the HR lead facilitating the team. But reading the whitepaper it looks promising to think about setting up the organization in this ‘diamond’ structure to achieve more business agility, something agile frameworks are lacking.

You can download the whitepaper on: pages.xebia.com/whitepaper-goal-driven-agile

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

Agile with a smile

9789463425803-480x600Samen met Dion Kotteman en Bert Hedeman heb ik het boekje Agile with a smile geschreven.

Overal, in IT land en daarbuiten, hoor je “agile, agile!’ Deze methode heeft stad en land veroverd. En dat is verklaarbaar: met agile gaat je project beter en je levert eerder op wat wordt gevraagd. Niets mis mee toch?

Of toch? Heb je het idee dat die methode soms niet goed werkt, dat er dingen vergeten lijken te worden. Heb je gemerkt dat je soms de grenzen van agile in zicht hebt?

Het kan zijn dat je bent opgegroeid met waterval methodes, dan is dit wel even wat anders.

En weet je precies hoe agile werkt of ben je sterk afhankelijk van de deskundigen om je heen?

Als je in de praktijk hebt gemerkt dat agile werken ook zijn keerzijden heeft, dan is dit een handig boek voor je. Het laat zien hoe je agile kunt aanvullen met bestaande werkwijzen. Dan neemt de succesrate van je projecten toe.

Als je het als manager beter wilt snappen, ook dan is het een handig boek. Het geeft op een speelse manier weer waar je met agile werken tegen aanloopt en hoe je het handiger kunt toepassen.

Bob, de hoofdpersoon van dit boek, heeft dat idee ook: hij werkt op een agile manier, heeft Scrum teams ingericht, een Product Owner aangewezen, maar toch loopt het niet goed. Hij wist niet altijd waar  hij was met zijn projecten. Hij had het overzicht niet. En hij kon de omgeving niet goed uitleggen hoe de puzzelstukken in elkaar moesten passen. Toen hij ook nog op zijn kop kreeg van de compliance mensen, was hij goed ongerust.

Hij wint advies in en ziet dat met een paar redelijk eenvoudige aanpassingen het agile werken veel succesvoller kan zijn. En wat grappig is: de meeste van die aanpassingen kent hij al wel, want die komen uit de methoden die hij overboord had gezet toen ze agile gingen werken.

Dat is de kern van dit boek: agile werken is prima, het is breed toepasbaar, maar zorg dan wel voor meer overzicht, meer samenhang en zicht op de voortgang en de architectuur. Dat is goed te doen en er zijn nauwelijks nieuwe technieken voor nodig. Dit boek laat zien hoe je dat doet.

Dat gebeurt op een chronologische manier: we volgen de weg die je aflegt als je start met agile werken. De problemen die dan naar boven komen zijn achter elkaar gezet. En niet alleen de problemen! We zetten er per probleem ook een heldere oplossing bij. Korte overzichtelijke pagina’s die kort aangeven hoe je het aanpakt.

Dus: agile kan met een smile, maar let even op een paar voorwaarden om het een groot succes te laten zijn!

Bestellen: Agile with a smile

Artikel computable: Agile is meer dan een hype

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.