Tag Archives: review

Review Blue Striped Frog – The agile community – Magazine (1st edition)

Last week I received a few copies of a brand new magazine from Vincent Snijder, the editor in chief. A magazine for the Blue Striped Frog community of professionals who are engaged in transformations towards increasing organizational agility. At this moment there aren’t that many physical magazines focussing on project management, agile, or agility anymore.

I am probably old fashioned but I still prefer a physical edition above a digital edition. Looking at the overload of online blogs, articles, complete magazines etc, I often start reading but in many cases not finishing the digital magazine. When it’s a physical edition, it’s on the table, waiting to be read completely. For this magazine both options are possible (see below).

The editors sees the blue stripe frog as a cool name (I agree and I assume it has nothing to do with the poisonous blue stripe frog you can find in the rain forests of South America).

Let’s look at the content.

The editor in chief opens the magazine with some froggy talk about transparency, the theme of this first issue.

Hans van Leeuwen and Henk Venema were privileged to speak with Kate Collins and Andrik de Jager, both Global directors IT at royal BAM Group. In this interview we see how they constructed an agile future. A future where multiple disciplines are working together efficiently towards shared goals. An agile future that enables BAM to quickly adapt to  changes, attracting and retaining talent and facilitates transparency.

Tim Wiegel takes us in the world of the Obeya concept. Obeya is a big room where goals, performance and activities are visualized and physically displayed on walls to make others aware of the context in which they are working. A bit confusing is the fact that the author talks about himself in the third person and makes a little bit too much advertisements for his upcoming book and training. On his website you can download a copy of the Leading with Obeya – Reference Model. https://www.leadingwithobeya.com

Hélène Propsma, Ilse Tacoma and Jos van Oost put leaders of organizational transformations in the spotlights. Leaders often underestimate their own resistance of uncertainties. What does change mean to those leaders and do they know it from themselves? Do they trust the method? How do they handle pressure? Do they dare to let go? How agile are they? How do they react if their teams make mistakes? And can and do they do they want to be responsible for the results that are not completely defined in advance?

Henk Venema talks about the power of aligned autonomous teams. How can you achieve faster time to market, improved, customer experience, higher productivity and a great place to work? What to do if your organization operates in silos, with many managerial layers, where bureaucracy is in the driver seat and staff feel like a cog in the wheel and the focus is on efficiency and costs. Are you take a step-wise transformation (e.g. in line with the SAFe implementation roadmap), an all-in approach (compare ING transforming their entire organization, not only product and IT, with obeys-rooms and QBR’s to align) and the emergent transformation.

Marcel Riemersma makes the analogy between organizations and some animals. Will you be the rabbit or the leopard. Will you stay put and wait for the ‘hype’ to pass by? Or will you act and chase the opportunity to become an agile organization? Are you a rabbit staring in the headlights of organizational agility and thinks, not my cup of tea or do you become the leopard. The predator who openly hunts for the customer and the competition despite the efforts involved.

Henk Venema shows, based on the results of a questionnaire, that agile organizations are better equipped to adapt to a pandemic disruption due to the rhythms and routines, scaled processes, transparency, motivated teams, organizational layers and facilitating leadership.
In the final article, Hans van Leeuwen elaborates how an agile way of working can be of use during a restart of organizations after the lock down due to the COVID-19 pandemic.

On the tip and myth pages, brief explanations of the tips to create remarkable transparency, and communicate frequently and the myths that agile organizations do not need leadership, and by putting sticky notes on the wall things get better.

Conclusion I like this new magazine. It contains a mix of best practices, interviews, real life cases, a little bit of philosophy, some tips and myths and a cartoon at the back. Looking forward to the second edition.

If you want to receive all the upcoming issues of the Blue Striped Frog Magazine for free (physical or digital edition) you can subscribe at https://www.bluestripedfrog.com 

To become part of the Blue Striped Frog community you can join the community on LinkedIn to be inspired, to learn and to share: https://www.linkedin.com/groups/8762445/

Review Agile Conversations

Agile Conversations – Transform Your Conversations, Transform your Culture, written by Douglas Squirrel and Jeffrey Fredrick could be one of the missing pieces to make your agile transition work.

The book starts with some background information regarding the ideas and theories that underpin the conversational tools that will be used in the rest of the book. You get an explanation of the core techniques of the authors’ four R’s method. The four R’s representing the steps to help you learn from your conversations: record, reflect, revise and role play your conversation.

The rest of the book explains five different types of conversations. Conversations to become a high-performing team, conversation to reach more agility. These five conversations cannot be used randomly. You first have to build trust, using the trust conversation before you can start working on removing fear (fear conversation). Next you can start explaining the why by using the why conversation. The following step would be to agree on your commitments (commitment conversation) and finally we must have an accountability conversation.

TRUST conversation: we hold a believe that those we work with, inside and outside the team, share our goals and values.

  • Be vulnerable
  • Be predictable
  • Use TDD for people (the ladder of Inference) to align your story with that of someone else to build trust.

FEAR Conversation: we openly discuss problems in our team and its environment and courageously attack those obstacles.

  • Identify unsafe practices and habits (“how we do it here”): normalization of deviance
  • Overcome the tendency to jump to conclusions by using Coherence Busting (use a more curious, open attitude into the discussion; uncovering fears)
  • Jointly create a fear chart and mitigate these fears.

WHY conversation: we share a common, explicit purpose that inspires us.

  • Distinguish interest from positions
  • Combine advocacy and inquiry
  • Jointly design a solution

COMMITMENT conversation: we regularly and reliably announce what we will do and when.

  • Agree on the meaning of key elements.
  • Use a walking skeleton for a series of commitments and show progress
  • Compliance isn’t commitment
  • Define and agree on your commitments (agree on the meaning, agree on the next outcome to commit to, reaffirm the commitment).

ACCOUNTABILITY conversation: we radiate our intent to all interested parties and explain publicly how our results stack up against commitments.

  • Use theory Y to create a culture that fosters healthy accountability
  • Give briefings and back briefings (directed opportunism. Bungay’s 3 gaps: plans – actions – outcomes, alignment gap, effects gap, knowledge gap)
  • Radiate intent.

High-performing teams are characterized by high trust, low fear, clear why, definite commitment and solid accountability.

Conclusion. This book is not a simple read, but it’s a must read. It could be one of the missing piece to make your agile transition work. The book offers a conversational analysis model to record, reflect, revise and role play your conversations. In the book you get five different, but sequential, conversations to become a high performing team and reach more business agility. The trust, fear, why, commitment and accountability conversations are explained extensively with lots of recorded example conversations and reflections. It asks for discipline to read all those recorded conversations and use the reflection and conversation tools to find and understand the weak spots to improve these conversations. If you do, you have mastered the first step towards more agile conversations and ultimately agility. Following steps are practicing and practicing and practicing. Success!

To order: Managementboek.nlbol.comAmazon

Additional reading

Difficult conversations by Bruce Patton, Douglas Stone, and Sheila Heen

To order: Managementboek.nlbol.comamazon

The skilled Facilitator by Roger Schwarz

To order: Managementboek.nlbol.comamazon

Discussing the Undiscussable by Bill Noonan

To order: Managementboek.nlbol.comamazon

The Elephant in the Room by Diana McLain Smith

To order: Managementboek.nlamazon

The Responsibility Virus by Roger Martin

To order: bol.comamazon

’m Right, You’re Wrong, Now What?: Break the Impasse and Get What You need by Dr. Xavier Amador

To order: bol.comamazon

Nonviolent Communication: A language of Life by Marshall B. Rosenberg

To order: Managementboek.nlbol.comamazon

Review Moose heads on the table

If you want to make the transformation to a self-managing organization the book Moose heads on the table – Stories about self-managing organisations from Sweden by Karin Tenelius and Lisa Gill is a good starting point.

This book gives you insights, stories, lessons learnt from six different small Swedish companies who transformed towards self-managing companies.

In the first three stories Karin, one of the authors, was acting as a consultant or interim CEO, the last story is about their own training company and in the other two case studies they bought the companies and gave away the authority.

For those who are not familiar with the Swedish culture a short explanation about the title. A ‘moose head on the table’ is what we call the ‘elephant in the room’. A metaphor for an issue that’s becomes infected in the team (unresolved from the past, relationship dynamics or an individual or individuals’ way of being).

In the first case study we see Freys Hotel and a manager who wants to give the employees a sort of energy injection. Self-management brings the surprise boost. What does it mean to coach the owner to be a more empowering leader and step back, and on the other hand to coach the employees to step into their new authority?

In the second case we follow Komanco. A company in crisis with chronic losses and after the transformation a company with big wins.

In the next case regarding Excosoft we see a spiral of profit and loss. It’s possible to get great results withing a short time span with self-management but also how quickly this way of working can be undone when a new CEO takes over if they aren’t a coaching, empowering leader.

In the case about Elisabethgården we see what it means to create a climate of openness and new-found autonomy.

In the case about Mötesbokarna we follow a very old-fashioned call center making the transition. The big challenges in this case were the working climate and the business model. At the end the business was shut down.

The last case is about the authors’ own company Tuff Leadership Training. This company was created from scratch as a self-managing organization.

Throughout the text you get pop-out boxes giving some theory behind the used approaches.

You get an explanation of the three pillars for developing an effective self-managing team or organization:

  • a coaching mindset and way of being: relating to people’s potential, placing responsibility with the group, clarifying and distinguishing, being able to be with it, and not having your own (active) agenda.
  • a focus on working climate: 1) ask for the mandate, 2) describe the current working climate and identify the desired working climate, 3) distinguish, clarify and listen, 4) coach the group to become constructive.
  • a culture of mandate and involvement. Use cooperation coaching process: 1) clearly state the purpose of the activity, 2) distinguish how it will be and what they’re ‘signing up to’, 3) give the group the opportunity to ask clarifying questions, 4) give them the opportunity to choose.

This means moving from a parent-child to adult-adult dynamic, from a manager or leader being responsible, to the team being responsible and to be able to talk about what’s underneath the surface (feelings, emotions, ways of being, mindsets) and to tackle these things first before addressing surface or operational issues.

Besides the three pillars you get five useful insights you can use:

  • Concordance decision making: in order to reach a concordant decision in a group, you need to create a safe space for people to express their feelings and develop adult to adult communication.
  • The gold in listening: practicing your ability to listen is the most important task for a coaching leader, and a crucial part of being an effective team member in a self-managing organization.
  • Transparency and self-set salaries: an individual without information can’t take responsibility. An individual with information can’t help but take responsibility.
  • Accountability culture – a mindset shift from power over to power with and a skillset upgrade: fostering a culture of both high psychological safety and high motivation and accountability is key to an effective team.
  • Core quality quadrant (quality – pitfall – challenge – allergy). To help people ’turn reactivity into creativity. 

ConclusionThe book is easy to read and shows what it means to coach management and/or coach the team to become a self-managing organization. The three pillars and five insights are definitely helpful in your own journey. The focus is mindset, leadership and culture. Are you looking for practices, structures and processes, you have to look for different sources.

To order Moose heads on the tablebol.com, Amazon

Additional reading

Ricardo Semler, Maverick! The Success Story Behind the World’s Most Unusual Workshop, 1993 to order: bol.comAmazon

Frederic Laloux, Reinventing organizations, 2014 To order: bol.comAmazon

Review Introduction to Blockchain Technology

Quite often you hear the words blockchain, bitcoin or cryptocurrency, but do you really know what is meant with those words? Tiana Laurence wrote the book Introduction to Blockchain Technology – The many faces of blockchain technology in the 21st century to demystify these words.

The book is divided into 10 chapters. In the first three chapters you get an introduction to blockchain technology by explaining a blockchain, nodes, cryptocurrency, tokens, the meaning of distributed, and key parts of blockchain technology like cryptography, hash, ledgers, public witness and different consensus algorithms and structures of the network.

It all started with Satoshi Nakamoto. Satoshi is the pseudonym of the person or people who developed the bitcoin white paper (2008) and implemented the first blockchain database including the bitcoin. At this moment it is still not known who is behind this Satoshi. Satoshi left the blockchain scene in December 2010. A blockchain is a peer-to-peer distributed timestamp server that holds a record of all transactions that have ever occurred on that network. Blockchain technology may be applied in areas where a middleman is needed to facilitate trust. Trust is essential for things such as the transfer of money, voting, land records, IP rights, and identity. Blockchain software can be programmed to take the place of the middleman by becoming the trusted record keeping system.

Some used terminology within the blockchain technology:

  • node is a computer that is connected to a blockchain network. It runs the software for the network and keeps the network healthy by transferring information across the network to other nodes.
  • hash function is used to secure all the data in a block of transactions. A hash is the output of this mathematical process that creates a string of numbers and letters of a fixed size; for bitcoin it is 32 bytes.
  • Public blockchains are open to anyone in the world to participate in the functions of the network, only limited by their access to the internet, hardware and electricity.
  • Privat blockchains only allow trusted parties to operate their blockchain.
  • Hybrid blockchains control who can participate and at what level of participation each node is allowed to operate.
  • A common way to connect to a blockchain network is to mine. A miner is a type of node that is adding transactions to new blocks. Miners compete to win the right to create a new complete block by solving a complex mathematical problem. Each miner will write their answer in the block header and if they are correct, they are then rewarded with cryptocurrency. Mining does three things: creating new cryptocurrency, confirming transactions and securing the blockchain history.
  • cryptocurrency is a type of digital cash and is a bearer instrument.
  • Not all blockchain networks have cryptocurrency, but all networks allow for the issuance of some kind of token. Tokens are flexible and may not be bearer instrument. Tokens are self-authenticating data packets and represent a rare digital bit of information.
  • Ledger is a general term for describing records used to account for something and ‘distributed’ means that the record is kept in more than one location.
  • Blockchain technology is an extension of public witness concept (A public witness is a person that is attesting to a fact or event) in that it spreads knowledge, encourages persistence of information, and allows each individual node to make a choice with the information that they are given. Primary use cases of blockchain technology are tokenization, digital identity, transfer of value and decentralized applications.
  • Cryptography is the encryption of data so that it is only known by the intended parties. Blockchains use asymmetric encryption (public-key cryptography), to secure the transfer of cryptocurrency from one address (public-key) to another. A private key lets you decode messages sent to you over public channels. A public key allows anyone to send you a private message over a public channel.

consensus algorithm is a code that governs how a blockchain operates. It sets the rules that all participants must follow to proceed transactions. Consensus algorithms create a network structure and process that allows a group of independent systems to agree on a single version of the truth. Different types of consensus algorithms are:

  • Proof of Work
  • Proof of Stake
  • Delegated Proof of Stake
  • Proof of Authority
  • Proof of Elapsed Time
  • Proof of Capacity and Proof of Space
  • Proof of Burn
  • Hyperledger Fabric

The chapters 4 to 9 explains the many faces of blockchain. First you get insights into the key blockchain networks and technologies like Bitcoin, Hyperledger and Ethereum. Next you get different second-generation applications of blockchain technology like Smart contracts, tokens and decentralized autonomous Organizations (DAO). In the following chapters the author shows what can happen next if you combine these applications with online or protected identity, IoT, AI or marketplaces. How can blockchain influence the world economy by looking at supply chain, cross-border money transfer and financial change agents. In line with the previous chapter you get an overview of new frontiers in blockchain and business e.g. digital fiat currency, disrupters in banking, blockchain and insurance and an explanation of intellectual property rights and providence. The last chapter focusses on blockchain and people by looking at Estonia’s e-Residency and (smart city) projects in China and the financial capitals of the world.

  • Distributed ledger technology (DLT) is categorized within the blockchain technology but has three fundamentally distinct differences. There is no cryptocurrency, the nodes are known (private network) and the development is directed.
  • smart contract acts as an online contract between two or more parties. A smart contract is created by developers and enforced with Boolean logic, mathematics, and encryption. Smart contracts have automated performance and verification. The code in the contract would execute once a pre-specified action or event occurred.
  • Decentralized applications (DApps) are applications that run on a peer-to-peer network instead of a single system. DApps can be tools, programs, games, and more that connect users and provide directly. DApps expand smart contracts beyond simple A-to-B value transfers.
  • Decentralized Autonomous Organizations (DAOs) are sophisticated smart contracts that have things like voting rights of members.
  • A decentralized marketplace is a peer-to-peer platform that allows buyers and sellers to interact directly without involving a third party. A centralized marketplace is a platform with central authority.
  • Digital fiat currencies are a digital representation of the country’s fiat currency, which will be backed by financial reserves of the country such as forex and gold.

The last chapter of the book is dedicated to vulnerabilities, community fractures and feuds, attacks, hacks, and fraud and scams. Both private and public blockchains can be manipulated and trusting blindly may well lead to disaster.

ConclusionThe book gives a good overview of the blockchain technology, but it is difficult to read. The concepts discussed in the first chapters are key and could use some more explanation. In line with the title – The many faces of … there are many examples of different blockchain systems and applications. A little bit too much I would say. The book is also mandatory reading for the EXIN Blockchain Foundation certification. At the end of each chapter you get some sample exam questions to test your own knowledge. I missed a glossary at the end and that could be beneficial to candidates too.

To order Introduction to Blockchain Technology: managementboek.nlbol.comAmazon

Review Blockchain Foundation Courseware

The Blockchain Foundation courseware book is created by Expo Luppes. It contains a copy of the complete Blockchain foundation slide deck, one EXIN sample exam including the rationale and the Preparation Guide EXIN Blockchain Foundation. If I look at the slide deck, I would expect the same figures as been used in the book but that’s not the case. Could be an advantage but for those who want to get the certification it could be confusing too. The set-up of the deck is more or less in line with the chapters of the book. In the slide deck you will get an extensive list of addition reading (mostly web pages).

To order Blockchain Foundation Courseware: Van Haren Publishing

Additional reading

Satoshi Nakamoto, A peer-to-peer electronic cash system, retrieved from  https://bitcoin.org/bitcoin.pdf

Klaus Schwab, The fourth Industrial Revolution 

To order: managementboek.nlbol.comAmazon

Don Tapscott and Alex Tapscott, Blockchain revolution: How the technology behind Bitcoin is changing money, business, and the world: 

To order: managementboek.nlbol.comAmazon

Don Tapscott and David Ticol, The naked corporation: how the age of transparency will revolutionize business

To order:  bol.comAmazon

Review People Over Process

51Y04ZWZE5L._SX331_BO1,204,203,200_Michael K. Levine wrote with People Over Process – Leadership for Agility a very pragmatic and down to earth book about leadership and agile projects.

The classic formulation of agile in the Agile Manifesto has no role for leadership. In fact, it is explicitly anti-leadership, encouraging self-managed teams, reliance on motivated individuals, leaving them alone and trusting them to get the job done. Furthermore, neither agile or scrum contemplates how the agile team should be connected to a larger organization and to external partners who will likely have differing development processes and cadences.

The book is divided into four sections. The first section introduces facilitative leadership for agility and introduces the facilitative leadership triangle rigor, efficiency and alignment (REA). Next we get an explanation of the three major frameworks (architecture, plan and team structure) and the meetings to create them. In the third section we get an overview of some routine meetings like the daily scrum, demos, governance meetings and teleconferences. The final section focusses on project retrospectives.

You could also say that the book contains a theoretical explanation of the facilitative leadership model and a business novel where we follow a consultant Mary to help Pacifica Bank with their agile project. By following Mary, we see the facilitative leadership model in a ‘real life’ case to make it really easy to understand the theory. Theory and the Pacifica case alternate.

As stated, the facilitative leadership model contains the triangle rigor, efficiency and alignment (REA). And in the middle, we see the three major frameworks (architecture, plan and team structure) and meetings to create them. See the Quick Reference Card leadership for agilty.

Rigor: Clearly define each decision to be made, gathering and considering facts, thoroughly considering options, and making clear decisions. Making good decisions: right talent, experience, skills, and roles, team composition, options considered and evidence for decisions.

Efficiency: Respecting the time of all team members as a valuable commodity not to be wasted. Respect for people’s time: balance “Agile” and “Planful” management, frameworks to provide context, extensive preparation for meetings and tools and techniques.

Alignment: Teams must work in a way that gets the best input from all members, and gains understanding and commitment around common goals, schedules, methods, and decisions/directions of all kinds. Heads in game and moving together: right involvement, information available, input enables, value consensus and someone to decide.

Extraordinarily well-prepared and conducted meetings use the following pattern:

  • Preparing for a meeting: set a simple and achievable objective, lay out a path to achieve the objective (agenda, activities), roles and responsibilities, the physical setting, the paraphernalia, and ensure alignment on the way in.
  • Conducting a meeting: make the path visible and start down it and control the dialogue.
  • Concluding a meeting: checking for alignment, agree on communication of results, and set immediate next steps.

Architecture simulation meeting (event). The architecture simulation event is a proven mechanism to discover and build alignment around architecture. It can be used in many situations and at various stages of a project. It puts the focus on the software and the related business processes in a powerful way by using different scenarios. It’s a participative learning event.

Project Planning meeting. The project planning meeting is a proven mechanism to develop an effective project plan. Several subgroups are brought together around a timeline from the planning meeting through productive use to plan forward and backward.

Team configuration meeting. The team configuration meeting helps teams to adopt existing mechanisms in their organization (silos). Next, team members, their managers, and stakeholders work together to define specifics for each varying initiative (connectors, bridges between the silos) and finally, the team members (extended) retrospect and adjust.

QRC (Leadership for agility, 200725) v1.0To download: QRC (Leadership for agility, 200725) v1.0

Throughout the Pacifica case we get 25 leadership and 15 meeting tips. To mention a few:

  • By failing to prepare for a meeting, you are preparing to fail – Ben Franklin (Agile is not an excuse not to plan!)
  • Be sure the meeting participants at all times understand the meeting path, and where they are on that path
  • Bring vendor partners into your agile projects as soon as you know they will be an important part of the solution
  • the “self-governed team” agile principle is a valuable but incomplete concept. Applying hard-earned expertise to team configuration and process and exercising the power to mobilize an organization matter
  • Use the RAE test when deciding on an idea. Would it have impact on the rigor, is it needed for alignment, is it efficient. If the answer is no, don’t do it
  • Integrating events give much greater routine focus to ensure completion, and take the place of demo prep in many scrum projects
  • If you plan on sharing an important decision with the team for rigor and alignment, don’t be satisfied with a half-hearted attempt
  • When the going gets tough, double down on in-person relationships
  • Write the major elements of the meeting objectives and the agenda up on the wall so participants have a visual shared guide
  • Get people away from the protection/separation of a big table
  • Have the right time of party
  • The earlier in project planning that you can set specific dates for integrating events the better
  • When a topic is raised in a meeting that doesn’t quite fit, take it offline
  • it is very difficult to both participate in and facilitate a complex exercise as a project retrospective.

And as stated many, many more.

The book ends with tips to use tools like the Kaizen A3 – one page problem solving tool, agenda, alignment checking tools (fist of five, thermometer), dot voting, evaluation matrix, failure mode and effect analysis (FMEA), five whys, more of/less of, nominal group technique, tool advertisement and two by two matrix.

On the corresponding website www.TheTalesofAgility.com  you can find some information about the author’s Lean and Agile Software trilogy. People over Process is the third book. The two other books are: A Tale of Two Systems: Lean and Agile Software Development for Business Leaders and A Tale of Two Transformations: Bringing Lean and Agile Software Development to Life.

 Conclusion. A pragmatic, down to earth book when using agile ways of working and the case makes clear that scrum is not the magic bean or silver bullet for all projects. The book offers the facilitative leadership model for agility based on rigor, alignment and efficiency around major meetings or events like architecture simulation, project planning and team configuration to support you in having more successful projects.

 In my opinion the author mixed up the concept of minimum viable product (MVP) and minimum marketable product (MMP). See my blog for a short explanation on MVP and MMP. And, if I am correct there is not such a thing as a Scrum release planning. Also, Scrum doesn’t talk about User Stories but backlog items and that will solve some issues in the book too. But these are minor things. I would say this book is definitely worth reading!

To order: People over Process

To order: A Tale of Two Systems

To order: A Tale of Two Transformations

Review True lean

9789082365245-480x600With the book True lean – Your guide to the fundamentals connecting purpose, process and people written by Rudy Gort you get a concise but complete and clear overview of and insight into lean. What is it, what can you do with it and how did it come about?

The book is divided into three parts. The first part examines the origin of lean in order to understand the philosophy behind lean. We get a brief overview of a number of approaches (including agile, BPR, co-creation, kaizen, supply chain cooperation, operational excellence, Scrum, Six Sigma, TQM) and how these approaches relate to the lean philosophy. In the second part, the main elements of lean are explained using the house-of-lean and larded with many practical examples and literature references. The last part elaborates on the power of lean.

Much of lean originates in Japan and more specifically at the factories of the Toyoda family. In chronological order:

  • Yōzan (harunori) Uesugi (1751-1822) used the philosophy of tell them, show them, let them do it, and praise them
  • Sakichi Toyoda (1867-1930) puts jidoka in the front. Quality must be an integral part of the process, the process must automatically stop in case of errors (andon), and the system must be mistake proof (poka-yoke). In addition, Sakichi Toyoda believed that his company should contribute to society (purpose).
  • Kiichiro Toyoda (1894-1952): was of the opinion that one should think beyond personal interests and should think in the organization’s long-term interests and take personal responsibility for problems.
  • Eiji Toyoda (1913-2013): build the new car factory based on just-in-time concept (JIT) and a kanban system.
  • Taiichi Ohno (1912-1990): was the man behind the Toyota Production System (TPS); one-piece flow and pull, management by sight, and 100% operable rate.
  • Ass sources of inspiration they used Henri Ford’s flow principle and operational excellence and Edwards Deming’s improvement cycle PDCA, extended by Toyota with “Go and See” resulting in an incremental continuous improvement process (kaizen).
  • Fujio Cho, a student of Taiichi Ohno, develops the house metaphor.
  • John Krafcik (1988) introduces the word ‘lean’.

Lean is the label that researchers have put on the way of thinking and acting that Toyota encountered. The underlying culture is called the Toyota Way and is based on continuous improvement (challenge, kaizen, Genchi Gembutsu) and respect for people (respect, teamwork), the heart and soul of the lean management system.

To position the principles or main elements of lean, the house of lean is used as a metaphor, in which the firm base to build on stands for purpose, the roof stands for value, the foundation for stability, the two pillars for built-in quality and timeliness and the residents of the house for behavior (see also the quick reference card QRC Lean). QRC (True Lean, 200717) v1.0To downloaden: QRC (True Lean, 200717) v1.0

Purpose (firm base) or long-term mission gives people a sense of importance, direction, opportunity and performance and creates solidarity within the organization and, therefore, has a strong, binding function.

The goal is to create value for the customer, or in a broader sense, the general satisfaction of all stakeholders. To achieve this, an organization must have an inspiring vision of the future. It is the customers who determine how well the organization is doing. They determine the organization’s viability.

Stability (foundations) stands for predictability and reliability and stable and standardized processes. By means of visual management by using scoreboards and feedback mechanisms to stay on course and to make deviations visible, helps to create an evened-out workload. Through the five steps of workplace organization with 5S: sort (seiri), set in order (seiton), shine (seiso), standardize (seiketsu) and sustain (sitsuke) the workplace can be organized logically and create ownership of it. In addition, uniformity can be created by leveling out the volume and the product mix (heijunka). Mura stands for unevenness, fluctuation, variability, muri for overload or overburden and muda for overcapacity or waste.

Built-in quality and timeliness (the pilars) represent jidoka and just-in-time. Jidoka or built-in quality ensures that problems are not passed on further in the process, is much more effective and less expensive than inspections and repairing quality problems at the end of the line (zone control). It is not a technique but a principle. Prevention is better (poka-yoke). Just-in-time (JIT) means that every process only produces what is needed by the next process and does so in a continuous flow. JIT includes three elements: takt time (the rhythm at which a consumer consumes something), continuous flow (making and moving one item at a time to match the takt time) and a pull system (to guide an uninterrupted flow and avoid overproduction). Frequent use is made of techniques such as the spaghetti diagram, Value Stream Mapping (VSM), kanban, status board, and obeya.

Behavior (the residents of the house) can be characterized by five aspects. Everyone must set ambitious goals (improvement kata, coaching kata). Kaizen, to improve business operations continuously, and always driving for innovation and evolution. “What I do today, I can do better tomorrow”. Genchi genbutsu: going back to the source to find the facts to make correct decisions, build consensus and achieve goals at our best speed. (facts over data, analysis, 5x why). Respect by learning to understand each other and finally self-organization needs to be stimulated (teamwork).

The last part describes the power of lean. How it can be done faster, better and cheaper without a trade-off between quality and productivity and with unsurpassed flexibility. By reducing lead time and focusing on flexible production lines, quality, customer relationships, productivity and resource and space utilization are all improved. Only the employees themselves can continuously improve their work through commitment and remain motivated as a result. In addition, lean increases the innovation ability of the organization through effective, organization-transcending way of sharing knowledge with the various suppliers and partners and by creating designs and processes that support both high quality and easy production (design for assembly). Finally, the true power of competitiveness and lean is a learning organization. Lean is based on emergent learning in the most efficient way possible. A learning organization does not only learn. Above all, it learns how to learn using short-cyclic learning, knowledge management (explicit, tangible or written knowledge, but more about implicit knowledge gained through experience) and mentor-apprentice relationships.

The book concludes with a quote from the author himself “Lean is not a destination, but a way of traveling.”

Conclusion. A very readable and freshly designed book with many references to articles, videos (using QR codes) and other, sometimes groundbreaking books about lean or lean concepts. To get a concise but complete picture about lean – what is it, what can you do with it and how did it come about? – this is a great starting point and I highly recommend it.

Youtube: How Toyota changed the way we make things

To order (managementbook.nl): True lean – Your guide to the fundamentals connecting purpose, process and people

To order (bol.com): True lean – Your guide to the fundamentals connecting purpose, process and people

Review Leading the transformation

81UHq59ZetLThe book Leading the transformation – Applying agile and DevOps principles at scale written by Gary Gruver and Tommy Mouser gives a refreshing look how to start your agility transformation.

While most Agile implementations start with a focus on applying Agile principles at the team level, the approach presented in this book focuses on applying the basic principles of Agile and DevOps across the organization. How teams come together to deliver value in large organizations is the first-order effect, while how individual teams work is a second-order effect. Therefore, this book primarily focusses on how to transform the way the teams come together to provide value to the business by integrating all their changes early and often in an operation-like environment.

Transforming development and delivery processes in a large, traditional organization requires a lot of technical changes that will require some work, but by far the biggest challenges are with changing the culture and how people work on a day-to-day basis.

The approach to rolling out an enterprise-level Agile transition should focus on the business breakthroughs the Agile principles are intended to achieve while taking into consideration the capacity of an organization to change.

In several chapters we follow the steps you have to take when transforming the organization.

  • Business objectives and crucial first steps. Once you have a clear set of business objectives in place, the next step is determining where to start the transformation. You can’t do everything at once and this is going to be a multiyear effort, so it is important to start where you will get the biggest benefits.
  • A culture of continuous improvement at the enterprise level is important for any large successful transformation (mini-milestone objectives, cascading objectives to track progress, conversations, learnings and agile adjustments).
  • Agile enterprise planning. Organizations need to decide whether their primary objective is to deliver long-term accurate plans to its executives or if it is to deliver business value to its customers. Break the planning process down into different planning horizons, don’t eliminate flexibility, don’t lock in all of your capacity to long-range commitments, just-in-time creation of requirements details.
  • Business objectives specific to scaling DevOps. Applying DevOps and Agile principles at scale in the enterprise requires developing processes that will enable the organization to economically release smaller batches of code on a more frequent basis. There are five main objectives: improve the quality and speed of feedback for developers, reduce the time and resources required to go from functionality complete or release branching to production, improve the repeatability of the build, deploy, and test process, develop an automated deployment process that will enable you to quickly and efficiently find any deployment or environment issues, and remove the duplication of work that comes from supporting multiple branches of similar code.
  • Creating a culture of trunk development. One of the most important cultural changes for aligning the work across the organization is having all the teams continually integrating and testing their code in a production-like environment. From a technical perspective the team will have to learn development practices like versioning services, rearchitecture through abstraction, feature flags, and evolutionary database design techniques.
  • ensuring a solid foundation. The first fundamental is clean architectures that enable smaller teams to work independently in an enterprise and make it possible to find defects with fast running unit or subsystem tests. The second is build and the ability to manage different artifacts as independent components. The third is test automation.
  • Continuous Delivery is a fundamentally different approach to development and operations that automates as much of the configuration, deployment, and testing processes as possible and puts it all under a revision control. The core pieces of Continuous Delivery you need to know are continuous integration, scripted environments, scripted deployments, evolutionary database design, test automation, deployment pipeline, and orchestrator.
  • Designing the deployment pipeline. You need to design a deployment pipeline that moves as close to that ideal state as possible but accommodates the current realities of your traditional business. Building up a stable enterprise system is a key component of the DevOps or Agile principle of enabling more frequent and smaller releases. Even if your business does not require or support more frequent releases, it helps with developer productivity and takes uncertainty out of the endgame.
  • Improving stability over time by using build acceptance tests and the deployment pipeline.
  • getting started. The key is starting the process of continually improving. The first step is making sure you have a clear set of business objectives that you can use to prioritize your improvements and show progress along the journey. Next is forming the team that will lead the continuous improvement process. The team should include the right leaders across Development, QA, Operations, and the business that will need to help support the priorities and lead the transformation.

Conclusion. After reading this book it becomes clear that moving towards business agility has nothing to do with the implementation of an agile way of working at team level. It’s the organization’s culture that has to change and this book is a great start to understand what that cultural change means from a developers’ perspective and which steps you need to take.

To order: Leading the transformation


Review 97 Things Every Scrum Practitioner Should Know

9781492073840-480x600The book 97 Things Every Scrum Practitioner Should Know edited by Gunther Verheyen contains the wisdom of 69 practitioners around the world and helps you to improve your understanding of Scrum (nb. Who are we missing on the cover of the book?).

Gunther organized these 97 essays around ten themes. These themes cover all aspects of Scrum and beyond. The events, the different roles, their behavior, the skills, collaboration and the artifacts. The book ends with a simple Scrum glossary. To summarize, some topics that are discussed in the ten themes:

  • Start, adopt, repeat. This first theme gives you insights what it means when you start using Scrum. Use it, as it is or adapt? Why using Scrum? Are multiple Scrum teams the same as Multi-team Scrum? And many more.
  • Products deliver value. What are your products? How is this reflected in your backlog? What do we mean by value? Who’s value? And what does this mean for the product owner?
  • Collaboration is key. Collaboration, communication and interaction between whom? With the customer, within the team? Are you just following your job description or not? Are tools considered harmful?
  • Development is multifaceted work. What are you developing? What’s on your product and sprint backlog? How to size your PBI’s? What do we mean with backlog items, user stories, abuser stories, bugs?
  • Events, not meetings. Here we get several ideas how to make the events work and effective. The impact of sprint goals, who plays which role during the events and what are these events not.
  • Mastery does matter. Here we get the spotlights on the Scrum master. The Scrum master as servant leader, court jester, (technical) coach, or is he just an impediment hunter?
  • People, all too human. Teams are more than collections of technical skills. Are people impediments? Can Scrum masters replace team members?
  • Values drive behavior. Scrum is more about behavior than it is about process. What is self-organization? How to be a more humane Scrum master and an essay on the sixth Scrum value.
  • Organizational design. It’s all about agile leadership, culture, improving the organization, the importance of networks, respect and a save environment.
  • Scrum off script. Probably you think you know the origins of Scrum, but it might not be what you think they are. Here we also get some examples of Scrum outside software development, e.g. at the police, in the classroom, in education.

Conclusion. This book is definitely food for thought for Scrum practitioners. Sometimes you get different views or opinions e.g. on backlog items and user stories but that’s also the beauty. It’s not carved in stone. When using Scrum, you have to think, rethink, discover and adapt. And don’t forget it’s all about people! A must read!

Throughout the book you get many references to articles, et cetera on the web. It would help the reader if small QR codes were added to the text (I often make mistakes by reading/typing a I, i, L or l).

In the book there is a reference to the Flow framework. In a next blog I will dive into this framework to see where it fits in my Bird’s eye view on the agile forest.

To order (managementboek.nl) : 97 Things Every Scrum Practitioner Should Know

To order (Amazon.com): 97 Things Every Scrum Practitioner Should Know

To order (Bol.com): 97 Things Every Scrum Practitioner Should Know

Youtube: Gunther Verheyen answers questions about “97 Things Every Scrum Practitioner Should Know”

Review Rethinking agile

51nTAg-en9LRethinking agile – Why agile teams have nothing to do with business agility written by Klaus Leopold is great book to cope with agile transformations and what you have to do to increase the chance of success. It definitely busted the myth that having agile teams makes you agile.

The book is divided into four parts: the problem, the causes, the first solution, and the result.

The book starts with a case study of an organization that wants to optimize their time-to-market. They want to reorganize their teams. All teams should be cross-functional and organized according to the premise: One team, one product. Teams could choose the agile method they wanted to use, and the following requirements needed to be fulfilled: work should be visually managed, hold daily stand-ups, retrospectives, throughput and cycle time must be measured. All 600 IT employees followed a one-day agile mindset basis training. Management realigned the teams according the product structure and the reorganization took place through self-organization (marketplace). External support in the form of 16 coaches helped the teams to run system design workshops and create Kanban systems to visualize and manage their workflows. As a result, all teams were fully transformed and fulfilled the stipulated agile framework conditions. But the ability of the teams to deliver had not changed much! Projects are not being completed more quickly!

The author describes four causes why their projects were not completed more quickly.

Cause #1: The pitfall of simplistic inference in the change process

    • Implementing agile is a means – not a purpose – for achieving business agility
    • The change process as a project (pull versus push principle)
    • Change is a new organigram – mixing up cause and effect.

Cause#2: Dealing with dependencies between teams and products. They forget to consider:

    • One product, many teams
    • Dependencies between products
    • Peculiarities in knowledge work.

Cause #3: An incomplete value stream

    • What is happening downstream? Integration? testing? release? …?
    • What is happening upstream? Idea pool? Triage? Business case, decision making. …?
    • End-to-end management of the value stream was missing.

Cause#4: WIP limits at the wrong place

    • Reducing WIP: Park the work in front of the system (option pool)
    • Limit the initiatives, the number of projects in the system (strategic portfolio management).

As a solution the author discusses the added value of the flight level model as a communication instrument to identify the effect of specific improvements at operational level (team), coordination (value stream) and at strategic portfolio management (company) and to discover where within the organization it makes sense and/or is possible to leverage improvements (visualizing the work, setting WIP limits, establishing feedbackand determining and implementing improvements). On top of that he sees three areas of improvement: make dependencies visible (product boards), integrating the upstream (be aware of traps: too much, too exact, too unnecessary) and strategic portfolio management (strategy board).

The book ends with a summary to make your business agile:

  • Start at the top (the first agile team)
  • Agility begins with the change process
  • Focus on the goal not on the method
  • Agility is not a team affair
  • Identify the flight levels (operational level, coordination and at strategic portfolio management)
  • Manage and eliminate dependencies
  • Incorporate the drivers for lean business agility at every flight level (visualize, manage WIP, feedback loops, improve).

Conclusion. Great book and nice illustrations (by Matthias Seifert). A must read for those who are starting or in the middle of a business agility transformation to learn what others did wrong and what you can do to increase your chance of success. A next print could benefit when a contents paragraph and chapter and paragraph numbers are added.

To order (Amazon): Rethinking agile

To order (bol.com): Rethinking agile

Review: DevOps for the modern enterprise

devopsDevOps for the modern enterprise – winning practices to transform legacy IT organizations is a practical book based on the experience of the author Mirco Hering.

The book is divided into three parts. The first part explains how to create the right ecosystem for success. The second part puts the people and organizational dimension in the spotlights and the last part emphasizes on technology and architecture aspects. Every part contains four chapters and at the end of each chapter you get some steps to exercise to make it more practical.

The first part – creating the right ecosystem – starts with the usage of value stream maps to visualize your IT delivery process and a jump-start of the transformation with an initial roadmap and governance approach. As a next step you have to analyze your application portfolio (criticality of application, level of investment in application, preferred frequency of change, technology stack). Based on this analysis you should focus on a minimum valuable cluster (MVC) to speed up the complete cluster by uplifting the MVC. The following chapter discusses the added value of guidelines for selecting new applications and the strengthening of your architecture by creating and empowering ecosystem. The following aspects can be used to start the assessment of architecture maturity: auto scaling, self-healing, monitoring and capability for change. When looking at your packages, in case you can’t or don’t want to replace, the following approaches are explained: leverage your system integrator, leverage user groups, strangle the application and/or incentivize the vendor to improve their product. In line with the types of applications (differentiator applications, workhorses and true legacy) you have to find the right partner that fits your ambition and culture.

As stated, the second part put the people central. How can you provide your people with the right context for their decisions, what team structure you should choose to enable autonomy and purpose, how to shift from legacy thinking that has caused many test automations projects to fail, and how to manage your people better? Based on the “burger organizational chart” the author discusses delivery governance (with an agile governance function, DevOps governance function and quality assurance),  the test automation center of excellence, agile teams (maybe clustered in an agile release train, team by location, team by function and team by technology) and the platform team (test automation, automated app release and environment provisioning). A separate chapter is dedicated to testers and the importance of quality. The last part gives more generic people-oriented techniques and ways of working like one-on-ones, feedback, delegation, creating a blameless culture and measuring your organizational culture.

The last part looks at the right way to choose DevOps tooling, what makes a good DevOps architecture, how to evolve your application architecture, how to leverage the relationship between DevOps and cloud computing, what each delivery model looks like, and how these models impact your organization.

The delivery models are:

  • Continuous delivery model deploys applications automatically into persistent environments (either cloud or on premises)
  • Cloud-enabled delivery model deploys applications automatically after provisioning a new environment from the cloud or data center. Main difference compared to continuous delivery model is the maturing of the infrastructure practices – infrastructure as a code.
  • Container-enabled delivery model deploys applications as a set of containers into one or more hosts that are dynamically created. Main difference compared to cloud-enabled delivery model is the maturity of the container practices and the more modular application architecture.
  • Serverless delivery model (potential future model) where you don’t run services as such but rather write a function to perform some business logic. When the function is called, an instance is created just for the duration of the function call (e.g. Amazon Lambda).

To evolve your architecture over time you can use the strategies decoupling (two speed delivery model), going on a diet (paying down the technical debt and making the core more agile), let’s try it on the side (green field setting) and erode the core with microservices (a service that serves one purpose; it is self-contained and independent; it has a clearly defined interface and isolated persistence). The book ends with different aspects of levering cloud-based services. Benefits of the cloud are cost benefits, ease of setting up redundancy for resilience, the scalability of resources, and the strong ecosystem of related services that you would otherwise have to build yourself. on the risk side we see the dependency on a third-party provider, the challenges with data sovereignty, and the risk of being attacked because you are on a popular platform.

Conclusion. Reading this book and execute one or more of the exercises gives you one of the reasons why so many agile transitions fail. It’s not only about creating, sometimes only renaming teams into agile teams but you have to look at the complete ecosystem, your application landscape, the application architecture and your delivery models. A must read for those who are transforming their IT organization towards a more agile organization.

To order: DevOps for the modern enterprise