Tag Archives: review

Review: A Guide to Assurance of Agile Delivery

agile-coverThis guide (2017) is a result of the working group of the Association for Project Management’s Assurance Special Interest group (APM’s Assurance SIG).

The guide addresses assurance in relation to the areas that are considered the fundamental aspects (and key differences form traditional waterfall approach) of agile project management and assurance.

Like the other book I reviewed (Agile Governance and Audit), this book too focusses on temporary project organizations using an agile way of delivery (compare PRINCE2 Agile, AgilePM, DAD, PMI Agile where we have agile teams using e.g. Scrum) and not on organizations using e.g. SAFe, LeSS or Nexus. The four areas described, are (each in a separate chapter):

  • Approaching reviews in an agile way provides guidance on how to plan and conduct reviews. It starts with early engagement to obtain an understanding how the organization applies agile project management, what methodologies, (reporting) tools and approaches it employs. A Terms of Reference (ToR) focusing on the specifics of an agile way of working, the planning of the review and the the output.
  • Environments focus on the agile ways of working and the physical working environment. You get ten general health indicators to assess an agile team. Furthermore, you should take the time to familiarize yourself with the whitboards/walls the, preferably co-located, teams are using to understand their Kanbans.
  • Governance starts with an overview of generic governance topics that are applicable too for agile projects. On top of this you get some additional characteristics of agile projects that you, as an assessor, should keep in mind. E.g. the agile approach and terminology, the way the backlog is managed, the agile specific roles like an agile team, a product owner and a scrum master and their behaviors.
  • Risk management mechanisms are probably leaner than for traditional projects. Incremental and iterative delivery with regular client feedback reduces the chance to deliver the wrong product. An overview of specific risks for agile projects and how to cope with them is provided.

At the end of the book you get checklists for the four areas (approaching review, environments, governance and risk checklists) and references to further reading including links to National audit Office and HM Government documents and several agile related sites.

Conclusion: This easy to read book focusses, as stated, on temporary projects with an agile delivery team. I would say it’s a good starting point, and it helps to get an understanding how to perform an assessment on agile projects.

To order: A Guide to Assurance of Agile Delivery

 

Review Agile Governance and Audit

9200000030027431Christopher Wright wrote the book Agile Governance and Audit – An overview for auditors and agile teams. Auditing of an agile way of working looks like an unexplored corner. There is not that much written about this topic.

Agile Governance and Audit gives a short introduction to agile, compares agile with waterfall and looks at audit and agile cultures. The author follows a project life cycle from idea towards a usable product including governance and control.

Based on an audit objective related to the position in the life cycle, you get the main risks to consider, the audit approach including a set of questions and a conclusion. The following audit objectives are explored:

  • Auditing agile versus waterfall: To ensure management has adequate controls for decisions regarding the choice of approach for projects (agile/waterfall/hybrid approach) and has established the governance and infrastructure to support these approaches
  • Auditing project initiation: To ensure management has adequate procedural controls and evidence for decisions regarding inception and choice of approach, business benefits, risk/compliance implication, phasing and level of governance required. A case study is included
  • Auditing requirements gathering: To ensure management has adequate controls and evidence for decisions for the consistent gathering, assessment, prioritization and approval of high-level business requirements. A case study is included
  • Auditing build and testingphases: To ensure management has adequate controls and evidence for decisions regarding testing performed, and that that testing will ensure management requirements will be met
  • Auditing business handover: To ensure management has adequate controls and evidence so that functionality, processes and controls can be operated effectively and maintained by the business post Go Life
  • Auditing agile governance: To ensure management has established an effective and efficient framework for governance off the project, with appropriate evidence being retained.

The final chapter gives some top tips for auditors as a take-away.

Conclusion: This easy to read book focusses on projects with an agile delivery team using Scrum, Unified Process or XP. This means, in this book, a temporary organization using an agile way of working that is close to more traditional project management. This is where we now see PRINCE2 Agile, AgilePM, DAD or PMI Agile. I would say it’s a good starting point, and it helps to get an understanding what kind of controls you need to put in place. On the other hand, I hoped to find some audit practices regarding organizations with permanent agile teams using SAFe or LeSS or other agile scaling frameworks. In these situations, the focus will probably be on requirements/user stories/backlog items, roles, governance, decentralized decision making, DevOps, automated testing, continuous integration, continuous deployment and transition. And these areas are not covered in this book (understandable because the book was written in 2014).

In a next post I will review another book in this area: A guide to Assurance of Agile Delivery. Please let me know if you are aware of other books in this area.

To order (Bol.com): Agile Governance and Audit

 

Review Make Disruption Work

9789082838206-480x600Alexandra Jankovich and Tom Voskes wrote the book Make Disruption Work – a CEO handbook for digital transformation. Everybody is talking about digital disruption. It will continue impacting every sector and industry and creating new ways for companies to serve customers better, faster and cheaper. Those companies that adapt and make disruption work for them, win big; those that don’t get boiled like frogs.

The book is built around the 5D model. Each step has its own chapter with explanations of the key points in that step and related examples of existing companies. The final part of the book is dedicated to three case studies. The chocolate world (de-decentralizing: autonomous-owners to everyone-wants-in), Dealcraze.com (back from the brink: data saves) and Prospect & Micawber (safety through risk). The case studies are detailed and risk, covering not only the sunny side, but also the gritty problems and misconceptions faced, as well as key case data.

The 5D model:

  1. Discover the new world. CEOs ask: ‘How is my industry going to be disrupted?’ Start by looking up
  2. Define how to act. The game has changed. There are six new rules, and seven strategies to match
  3. Determine what you need. Organize to deliver speed and disruption, and approach tech right
  4. Drive the change. Get your capabilities, get your team, go!
  5. Delight in the new world. Lead, act, and tell the story.

QRC (make disruption work, 190821) v1.0To download: QRC (make disruption work, 190821) v1.0

Conclusion: The book is easy to read, easy to digest, and visually attractive. By following the 5D model you get a lot of useful advice for senior leaders how to cope with disruption and how to make disruption work for you.

To order (Managementboek.nl): Make Disruption Work – a CEO handboek for digital transformation

Nederlandse versie: Make disruption Work – Een CEO-handboek voor digitale transformatie

 

Review Official PRINCE2 Foundation App

1200x630waA companion learning tool to pass the PRINCE2 Foundation exam. It’s based on a simple 3-step approach: study, practise and mock exams. You can do a quick test by topic or a full mock exam. You can review answers provided with explanations and results will be tracked by topic.

It can be used as a reference tool with a comprehensive glossary with search function across the whole App. The App contains a case study to bring PRINCE2 to life and offers links to continue your PRINCE2 journey.

On the main menu you have to choose between study or practice. In the study part you will be able to read a case study (Axle Car Hire) about project management and study for your exam with Study Cards (in total 240 questions). The case study contains 5 topics:

  • Introduction to PRINCE2: introducing the company, it’s vision, the project and the key employees
  • Principles: remarks from the key stakeholders in line with the principles
  • Themes: purpose and remarks from the key stakeholders in line with the themes business case, organization, quality and plans
  • Themes 2: purpose and remarks from the key stakeholders in line with the themes risk, change and progress
  • Processes: purpose and remarks from the key stakeholders in line with the processes starting up a project, directing a project (3 parts), initiating a project, managing a stage boundary, controlling a stage, managing product delivery and closing a project.

The study cards are in line with the five topics. When you give the right answer, you get an explanation why that’s the correct answer. If you give an incorrect answer you get an explanation why it’s incorrect.

In the practice part you can select a quick test or mock exam. The length of the quick test (min 10, max 30 minutes) and the number of questions (between 20 and 40) can be adjusted. The Mock exams are 60 questions in 60 minutes. The questions are the same as the study cards. 

Conclusion: In total 240 questions, which more than enough to prepare yourself for the foundation exam. The App could be of more value if the study cards are based on the case itself.

Some potential improvement points:

  • Navigation: if you mark a topic as read you imediatly get the next topic and before you know you mark that one as read too.
  • Navigation. Replace < on the top with HOME. If you use this as previous screen/previous question you have to start all over with the study cards. Or add a message in line with the mock exam.
  • In the case there is a reference to PRINCE2 role: Sponsor (incorrect, see glossary).
  • Some questions refer to the Commissioning organization (not in the glossary).

EB8DnayWwAIyOqc

 

Review AGILE NXT – New Insights for Agile Performance Management

Schermafbeelding 2019-06-18 om 13.27.07This is XEBIA’s second edition of AGILE NXT (see AGILE NXT for the first edition). This time you get approximately twenty articles to bring you up to speed with new insights for agile performance management.

  • Measuring the Value of Business Agility (by Daria Nozhkina) shows that business agility generally adds value in three ways: it impacts the top line or the costs (or both); drives profitability; and contributes soft value which ensures that the profitability achieved is sustainable over the long term.
  • Data Science and Coaching: The Yin/Yang of Better Interventions (by Pieter Rijken) gives insights in team behavioral change by looking at goodness for fit for the delivery rate (items per iteration) data.
  • The Efficiency Addiction: Just Say No (by Roel trienekens). If you focus on efficiency … you get better at being increasingly less effective. Efficiency is about doing the same for less, effectiveness is about achieving more with the same input.
  • Four Steps to Effective Performance Meetings (by Daniel Burm) discusses four fundamental principles to keep in mind for people leading performance meetings: it’s not about you, close the loop, achievable next steps, and ask open questions.
  • The Quantifiable Added Value of Scrum is an interview with Jeff Sutherland about result-oriented organizations operating on clear and simple performance indicators (by Serge Beaumont).
  • Diamond Agile: Measuring What’s Meaningful (by Frank Verbruggen). Diamond Agile is a way of looking at organizational health from 5 different perspectives. Associated with each perspective are metrics. These metrics have been selected from hundreds of metrics as the best fit. 
  • The Power of Play in a Safe (But Not Too Safe) Environment (by Jasper Lamers) shows that a safe environment in which people can experiment, learn and fail without ruining the company, boost creativity.
  • Measuring Success, Measuring Value: Performance Management in a Scrum World (by Gunther Verheyen) highlights that team engagement is the most ignored aspect of value, yet one where huge gain can be made to increase the ability to deliver value.
  • The Gentle Way of Change (by Chris Lukassen) talks about six levers or sources of influence from the path to Judo black belt that could make you a better leader in business: personal motivation, personal ability, social motivation, social ability, structural motivation, and structural ability.
  • Changing Behavior—Measure First, Change Next (by Just Meddens) emphasizes what it does take to actually change behavior in the long term, and why it is so important in business. To change behavior the ABC change model can be of help (Antecedent: what triggers the behavior? Behavior: what’s being displayed? Consequence: what happens after the behavior is displayed? Is it being reinforced?).
  • It Takes Two to Do the Agile Tango: Invite Security to the Dancefloor (by Dave van Stein). Security and development need to dance together, so it’s best if they both learn the steps together, right from the beginning of your agile transition. Otherwise, once the development teams gain velocity, security and incident management becomes an impediment, and there is likely to be a few stumbles on the dancefloor.
  • Micro-Interventions from a Position of Leadership (by Rik de Groot). Management is responsible for 33% of transition failures. Micro-interventions that can help to achieve a positive outcome are provide purpose, speak out and build trust, lead by example, think big, act small, and shared leadership.
  • Doing: Diagnosis and Intervention Guide (by Paul Immerzeel and Maarten Uppelschoten) gives insights in the Doing model. Why people do things, how intervention triggers the behavior that creates the desired outcome and with it, organizational change. Forces that influence doing are understanding, willing, able and being enabled.
  • The Secret Key to Performance: Inner Agility (by Mirjam Diependaal). When in transition, organizations often forget that the essential factor in change is people. And people are often afraid to change. That’s why organizations should explicitly focus on helping people develop inner agility, because, without it, lasting change won’t occur.
  • Reducing Waste in the Race for Innovation (by Wilco Nap) outlines strategies designed to prevent product waste, time waste, and talent waste.
  • EventStorming: Increasing Performance Through Continuous Discovery, Learning, and Sharing (by Kenny Baas-Schwegler) explains EventStorming. It’s a workshop-based method for facilitating collaboration between the different IT disciplines and silos to empower knowledge-sharing.
  • Metrics: WiFi, Hamburgers, and the Successful Improvement Rate (by Jarl Meijer) emphasizes that there are two metrics that matter most in measuring the success of an agile transformation: the “level of agility” and the” successful improvement rate”.
  • How DevOps Helps You Accelerate Your Execution Power and Why it Matters (by Hans-Jürgen Jacobs and Pavel Goultiaev). DevOps allows a company to respond faster and rapidly test assumptions in any response to opportunities or threats. By creating more customer value, a company can achieve superior performance.

Curious to read the magazine? Download or request a printed copy at: AGILE NXT

 

Review Flawless consulting

flawless consulting 9780470620748-480x600Peter Block is the author of Flawless consulting – A guide to getting your expertise used. Starting point are the following three consulting goals. Establish a collaborative relationship. Solve problems so they stay solved and ensure attention is given to both the technical/ business problem and the relationships. To achieve this, you have to follow four phases and you must make sure you complete the requirements for each phase before you move into the next phase.

The four phases and their requirements are:

  • Negotiate the client and your own wants, cope with mixed motivation, surface concerns about exposure and loss of control, and understand triangular and rectangular contracts.
  • Discovery and inquiry. Layers of inquiry, political climate, resistance to sharing information, and the interview as a joint learning event.
  • Feedback and decision to act. Funneling data, presenting personal and organizational data, managing the meeting for action, focusing on the here and now, and don’t take it personally.
  • Engagement and implementation. Bet on engagement over mandate and persuasion, design more participation than presentation, encourage difficult public exchanges, put real choice on the table, change the conversation to change the culture, and pay attention to place.

Result By definition, being a consultant – and not a manager – means you have direct control and responsibility only for your own time and your own support resources. The line manager is paid to take responsibility for what the line organization implements or doesn’t implement!

Accountability If I – know my area of expertise (a given), behave authentically with the client, tend to and complete the business of each consulting phase, and act to build capacity for the client to solve the next problem on their own, I can legitimately say I have consulted flawlessly.

QRC (Flawless consulting, 190628) v1.0To download: QRC (Flawless consulting, 190628) v1.0

The book explains what to do during the different phases, what kind of meetings can be or must be held (including checklists). You get practical guidance on how to ask better questions, gives suggestions for dealing with difficult clients, and contains expanded guidelines on more engaging forms of implementation. It describes the important differences between internal and external consultants. What kind of resistance can you face, what does it mean and how to deal with resistance? Several examples are given including two outside the consultancy world. One taken from the health care and one from educational reform efforts.

In the book you can find several handy checklists:

  • Assessing the balance of responsibility: Rate who is taking responsibility in a project you are engaged in.
  • Analyzing one of Your contracts: Practice writing up elements of your contract.
  • Planning a contracting meeting: Answer these questions when you are planning a contracting meeting.
  • Reviewing the contracting meeting: Questions to answer after the meeting.
  • Planning a discovery meeting: Planning guidelines to aid in data collection and prepare for resistance.
  • Reviewing the discovery meeting: Questions to answer after the meeting.
  • Planning a meeting for action: Guidelines to help you prepare for the meeting.
  • Reviewing the meeting for action: Questions to answer after the meeting.
  • Preparing for implementation: Reminders on working the elements of engagement into the implementation phase.
  • Reviewing an implementation event: Questions to answer after the Implementation phase.

To download these checklists, visit www.flawlessconsulting.com where you can find much more resources too.

Conclusion. A must read for consultants. If you just start or if you are already a very experienced consultant, this book gives a lot a very useful insights, practices, checklists, examples, and a way of thinking and working to build the right relationship with your client and to avoid disappointments on the client’s or your own side.

To order (Managementboek): Flawless Consulting

To order (Bol.com): Flawless consulting

Review User Story Mapping

User story mappingJeff Patton wrote the book User Story Mapping. Story mapping it’s a tool to enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why.

The book offers 18 chapters:

  1. The big picture. This chapter will help to get a basic understanding of a story map and what it means to tell stories.
  2. Plan to build less. Now you have a basis understanding of a map some more details are added. What’s the backbone of the map, what type of users are playing a role, which big activities are the performing, how can those activities be divided into smaller steps, how can we split a single step into more details.
  3. Plan to learn faster. Are we going to deliver everything in one big release, or can we have multiple releases? How are we going to set up the individual releases? How can we learn from the users using the release (validated learning, build – measure – learn)?
  4. Plan to finish on time. Don’t release each slice. Divide your release in an opening game (see it work), mid game (make it better) and an end game (make it releasable). Include risk stories to make risk visible.
  5. You already know how. Based on the previous chapters you now have a pretty good understanding of a story map. In this chapter you can prove you really understand it by creating a story map of all the things you have done this morning when you woke up until you’ve gotten ready for work. Will be fun, definitely when you do this with some more people and start to discuss differences. QRC (story mapping, 190606) v1.0To download: QRC (story mapping, 190606) v1.0
  6. The real story about stories. The founding father of the idea of stories was Kent Beck (eXtreme Programming). His idea was to stop working so hard on writing the perfect document, and to get to tell stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. Ron Jeffries describe the story process as 3 C’s: Card, Conversation and Conformation.
  7. Telling better stories. Stay away from template zombies. Start talking about the who, what, why, what goes wrong, what happens outside the software, questions and assumptions, better solutions, how and how long.
  8. It’s not all on the card. You could scribble everything you like on a card. E.g. short title, description, story number, estimate, size or budget, value, metrics, dependencies, status, dates. You could even flip the chart to the back and write additional notes or bulleted acceptance criteria.
  9. The card is just the beginning. The 3 C’s are just the beginning. Two more C’s complete it: Construction and Consequences (evaluate with team first, then with business stakeholders and in tests with customers and users).
  10. Bake stories like cake. Ask lots of who, what, and why questions. Ask about the context (where, when, how many). Talk long enough to build shared understanding. If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal. If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.
  11. Rock breaking. A right-sized story from a user’s perspective is one that fulfills a need. A right-sized story from a development team’s perspective is one that takes just a few days to build and test. A right-sized story from a business perspective is one that helps a business achieve a business outcome. Conversations are one of the best tools for breaking down big stories.
  12. Rock breakers. A small, cross-functional team led by a product owner orchestrates product discovery work. The ideal size for a product discovery team is two to four people – dinner-conversation-sized so the members can quickly build shared understanding. The solution we want is valuable, feasible and usable (the three concerns; triad).
  13. Start with opportunities. Have conversations about opportunities and decide whether to move forward with them or trash them. If you agree to take on everything you are not helping anyone. Aggressively trash opportunities that don’t offer much hope of creating the outcomes you hope for.
  14. Using discovery to build shared understanding. Discovery work isn’t about building shippable software, it’s about learning. What problems are we really solving? What solutions could be valuable? What does a usable solution look like? What’s feasible to build given the time and tools that we have? Use four essential steps to discovery: frame the idea, understand customers and users, envision your solution and minimize and plan.
  15. Using discovery for validated learning. During discovery and validated learning, you may be telling stories constantly, breaking ideas and work down into small buildable pieces and agreeing on exactly what to build. You’ll be doing it so fast that it won’t be clear you’re using stories. But you are.
  16. Refine, define, and build. Play the Good-Better-Best game for splitting stories (What’s good enough to get things working, what would make it better, what’s the best version we can imagine?).
  17. Stories are actually like asteroids. Break stories down progressively, and just in time. To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those tittles with a single title on your new card and you’ve got one big story. In this way you can clean-up your backlog.
  18. Learn from everything you build. There are many opportunities to learn: review as a team, review with others in your organization, learn from users, learn from release to users, and use a map to evaluate release readiness.

Conclusion: A must read for product owners and agile team members. It’s the most complete book on story mapping I have read, and it will answer all (or most of) your questions regarding user story mapping.The book will definitely help you to use story mapping to deliver results that satisfy your customers.

To order (Managementboek): User Story Mapping

 To order (Bol.com): User Story Mapping