Tag Archives: Agile

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

Book review: The DevOps Handbook

9781942788003-200x300Gene Kim, Jez Humble, Patrick Debois and John Willis are the authors of the book The DevOps Handbook. how to create world-class agility, reliability, & security in technology organizations. If you look at the cover you see some similarities with The Phoenix Project. A novel about IT, DevOps, and helping your business win. And that is not a coincidence because Gene Kim is one of the co-authors of this book too.

Where The Phoenix Project is a business novel explaining the journey to set up a DevOps team, this book gives you the theoretical background, and the tools to build and use the DevOps philosophy by integrating product management, development, QA, IT operations, and information security to elevate your company.

The book is divided into four blocks: The first block (part I) introduces the three ways: The principles of flow, feedback and continual learning and experimentation. The second block (part II) explains where to start a DevOps movement in your organization. The third block (parts III-V) describes the technical practices of the three ways. The last block (part VI) discusses the technological practices of integrating information security, change management, and compliance.

In part II we see what it means to select the value streams with the most sympathetic and innovative groups to start with the DevOps transformation, analyse those value streams by creating a value stream map, and design the organization (functional, matrix or market oriented), fund services and products and not projects and create loosely-coupled architecture to dramatically improve the outcomes.

The first way describes the architecture and principles that enable the fast flow of work from left to right, from Dev to Ops to deliver quickly and safely, value to customers. Start with a single repository of truth for the entire system, make infrastructure easier to rebuild than to repair, enable fast and reliable continuous integration and automated testing and start with low-risk releases. Include running in production-like environments in your DoD.

The second way addresses the reciprocal fast and constant feedback from right to left by implementing feedback loops and use shared goals spanning Dev and Ops to improve the health of the entire value stream. The authors provide insights in telemetry from processes, behaviour and production issues, audit issues and security breaches that enables seeing and solving problems. Next we see, how we can integrate user research and feedback, peer reviews and pair programming and what it means when integrating hypothesis-driven development and A/B testing into our daily work?

The third way helps to create a culture of learning and experimentation. What can you learn from incidents, and how others can learn from your own learning by creating repositories and sharing learnings. How can you enable and inject learning into daily work by establishing a learning culture, have post-mortem meetings after accidents occur and communicate them, decreasing incident tolerances and organize game days to rehearse failures? And make sure you capture organizational knowledge by using e.g. chat rooms and chat bots.

In the last part, the three ways are extended by using them to achieve information security goals by making security a part of everyone’s job, by integrating preventive controls into a repository, by integrating security with the deployment pipeline, and integrating deployment activities with the change approval processes and reducing reliance on separating of duty.

Conclusion

If you want to start a DevOps movement, start with The Phoenix Project to make yourself enthusiastic about DevOps and continue with this book to get the real technical practices to make your DevOps a success. When buying this book, you will get a unique one-time access code to the DevOps X-ray individual assessment to benchmark your own performance against industry-wide data.

To buy: The DevOps Handbook

Agile Antipattern card deck

2016-10-29-11-16-27I received a deck of Agile Antipattern cards. An agile antipattern looks innocent but the can have a big impact on the agile initiative or even on the whole agile transformation. These cards can help you to spur conversation and fight dysfunction. You can use these cards as a retrospective tool. The team can select the antipatterns they ran into this sprint. After discussion the team can select the top antipattern to address in the next sprint. The cards can also be used to accommodate the debate during agile transformations.

The deck contains 24 Agile Antipattern cards.

At this moment the development of a new book is in progress: ‘Agile Antipatterns: The Scrum Master’s Guide to Traps, Tripwires, and Treachery’ By Adam Weisbart. You can download a first chapter on agileantipatterns.com.

This chapter, ‘The invisible gun’, elaborates on the the agile antipattern “My boss is on my team”.

Agile Portfolio Management Framework

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

In that article I created a list of aspects to take into account when designing an agile portfolio management framework. In this article I expanded and re-ordered the list and I summarized it in a picture. I updated the original article too.

dia1Agile Portfolio Management Framework:

Strategy assessment

  • Internal and external environment assessment (SWAT)
  • Portfolio management must facilitate sustainable business change (People, Planet, Prosperity, Processes, and Products)
  • Strategic objectives setting
  • Develop strategic themes.

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
  • 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 PfM Framework.

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

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:

dia1

Agile Portfolio Management Framework:

  • Strategy assessment
    • Internal and external environment assessment (SWAT)
    • Portfolio management must facilitate sustainable business change (People, Planet, Prosperity, Processes, and Products)
    • Strategic Objectives setting
    • Develop Strategic themes
  • 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
    • 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 additions
    • 02-10 Picture Agile PfM Framework

 

Book review: Agile Project Management and Scrum v2

front-cover-webIn two of my previous posts I wrote about DSDM and UX Design and Agile Project Management and Scrum v2. This is another little book in the same style. And this booklet too can be read as an addendum to DSDM’s Agile Project Management Framework.

Andrew Craddock is the author of the book ‘Agile Project Management and Scrum v2‘.

The booklet starts with a comprehensive overview of Scrum based on the Scrum guide 2013 and an explanation of the Agile manifesto.

Next we get an overview the combined AgilePM / Scrum process framework. The project delivery context is based on AgilePM and the evolutionary development context is pure Scrum.

In this combined framework we see the following changes / additions in comparison with the original AgilePM framework:

 

AgilePM AgilePM/Scrum
Process Evolutionary Development Scrum Development
Product Prioritized Requirements List Product Product Backlog

 

Timebox Plan and Timebox Review Record Sprint Goal, Sprint Backlog and Sprint Review Record
Roles adding the PO, SM roles

An enhanced Scrum two-week Sprint contains some minor embellishments to the standard Sprint:

  • In comparison with a standard Sprint we now see a split in two parts: Refinement (7 days) and Consolidation (2 days).
  • Within the Consolidation part we see a Consolidation Scrum to confirm progress to date and to explain what will be ‘Done’ by the end of the Sprint.

A new event, the Project Planning Event, is added. This event takes place at the boundary of timeboxes and can be used, by project stakeholders, to influence the the work of the Scrum Team without compromising the way Scrum is used.

Dia1

All roles are explained within this combined framework with special attention for the Product Owner role including relationships and interactions with the Technical Coordinator, PM, Business Visionary, Technical and Business Advisors and the Development Team.

Final paragraphs explain the usage of multiple Scrum Teams, Regulatory, and financial governance, the usage of Barry Boehm’s Cone of Uncertainty and some optional techniques (MoSCoW prioritisation, Facilitated Workshops and Modelling).

Conclusion: For those who are using AgilePM in combination with Scrum this is a must read. It gives a nice overview of the changes and a good explanation of the PO role including all relationships and interactions.

To order: Agile Project Management and Scrum v2

This is the last post in a series of three. DSDM and UX design was the first and Agile risk management and DSDM the second.