Skip to main content

Posts

Showing posts from 2020

Finding orientation in a chaotic world

The 6th question of Personal Agility is "Who can help?" and now I know why.

A few weeks ago, Maria Matarelli (my partner in the Personal Agility Institute and on the book) observed to me, "Peter, it's obvious you haven't been doing Personal Agility for a while. Maybe you would be better at mastering your current challenges if you did."

Man! I had to chew on that one for awhile. She was right of course. This is what a good coach does. A good coach helps you see the reality of your situation so you can act effectively. A good coach brings the truth of the matter to the surface.

Today, I came back to my Priorities Map. I decided to start with a clean slate. What is the first question to ask, even before you start with the 6 questions? Why?

Why am I doing Personal Agility? What is the change in me that I am trying to achieve that I am not able to do now? In my case, I feel like I have potential that I am not realizing. I want to realize my potential.

This over…

How are we responding to the Corona Virus for our upcoming Scrum classes

Scrum for Hardware Expert and WIKISPEED founder Joe Justice has confirmed that he is coming to Switzerland next week to teach the XM Extreme Manufacturing workshop. I am looking forward to a great workshop that opens your eyes to new possibilities. The COVID Virus is indeed making a big mess of everyone's plans. Why are we holding the class anyway? (Scroll past the graphic for the answer).
To make the March workshops more attractive, we are offering a special discount. Use the coupon code WhatsSpecialinMarch for an additional 20% discount an all our courses in Zurich in March (XM, CSM, CSPO). For course listing and registration, click here.
Based on what we have learned about how the virus spreads, who it affects, what the impact is, we believe it is still reasonable to be holding the classes. We are watching the situation, and if that changes, we will react appropriately. 
Here is the statement we sent to our students to explain why we believe this and what we will do to mitigat…

Top Project Risk Number 1: Delivery Risk

Will I get anything usable at all? Ninety percent of the time and money allocated for your project have been used up. Yesterday your project leadership said, “We're 90% done.” Today the project leader comes to you and says, “We need more time and money.” “How much more?” you ask. “Oh, about what we have spent up till now.” “What can we deliver now?” “Nothing.”

This was a common scenario back when large ‘waterfall’ projects only attempted to integrate and demonstrate the solution late in the development process. According to the Standish Group's Chaos Reports, 31% of IT Projects in 1992 failed outright, and another 53% were challenged. By 2012, the percentage that failed had dropped to 18%, largely due to doing smaller projects.
Delivery risk mitigation in Scrum Scrum mitigates delivery risk by taking a big project and splitting it into many small projects. Each mini-project lasts less than one month and creates a potentially shippable version of the product, regardless of whe…

Top Project Risk Number 2: Time and Budget Risk

“Will it be ready for Christmas?”  Just about every client I ever met has wanted to know the answer to this question. Will it be delivered in the time frame and budget that were promised?

Time and budget are very closely related. While there are other factors, cost usually depends mostly on the number of people involved and on the length of the project.
Time and budget risk mitigation in Scrum You can deliver to a deadline with Scrum or other agile frameworks. A fixed price is easy to achieve if you limit the time on the project but leave the scope open and definable in the project.

Scrum mitigates time and budget risks by breaking down functionality into small pieces, implementing must-have features before nice-to-haves, and having a shippable version available at least once per sprint.

In Scrum, the Product Owner has the option at the end of every sprint to deliver, to continue funding and developing, to deliver and continue developing, or even to abandon the project.

Phased develo…

Top Project Risk Number 3: Scope Risk

Will I get everything I asked for? Imagine it is Saturday, your spouse is about to go out somewhere with the car, and you need groceries. You ask him or her to stop at the grocery store on the way home. “Of course, send me the list!” You text the list of groceries for the week and then add, “For our guests tonight we need meat, wine, and cheese.” Your spouse returns at six that evening with everything but the meat, wine, and cheese. “How could you not bring tonight's dinner!?” “Oh, that was at the bottom of the list and I was running late, so I didn't get to it.” Obviously, getting everything would have been the best solution, but if you had to choose between ‘things for next week’ and ‘things for tonight’, which is more important? Which alternative gives you better options?

Time, budget and scope are the classic measures of success of a project. Is it on time and on budget? Did it deliver all the features? Of these three, scope is probably the least important. Being on time …

Top Project Risk Number 4: Market Risk

If we build it, will people use it or buy it?
Building a product that no-one wants is a great way to lose your entire investment.
“For our guests tonight we need meat, wine, and cheese.” Your spouse goes to the grocery store and gets all the ingredients for dinner. That evening... you have prepared a wonderful meal. Your guests arrive and see that the menu consists of meat and cheese: “We're vegetarians, and I have a milk allergy.” 
This is known as ‘technical success’. The developers did a great job, but the ‘business guys’ screwed up by not figuring out what the customer really needed.

How do you avoid creating “a solution looking for a problem?”
Market risk mitigation in Scrum  Scrum reduces market risk by encouraging collaboration between the stakeholders and the Scrum Team. Scrum requires a demonstration to stakeholders every sprint and makes the Product Owner responsible not just for staying within the budget, but also for ensuring that the sponsor's money is well spent…

Top Project Risk Number 5: Technical Risk

Can it really be done? I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth. When American President John F. Kennedy made this speech in 1961, did anyone know if it was possible to get a man to the moon? If you are going to build rockets you need a certain tolerance for explosions – and you will learn the importance of testing and when to be careful!
Technical risk mitigation in Scrum In Scrum, the Whole Team collaborates to identify the best step forward each sprint. This includes identifying and handling risks. The Team advises the Product Owner, who has the final say about deciding which backlog items come to the top of the backlog and into the sprint. Business value usually trumps technical issues, but the Product Owner should be an educated client and listen to the Team.

An insidious form of technical risk is the ‘Technical Debt’. Technical Debt is the consequence of po…

Top Project Risk Number 6: Social Risk

Can the people building the product collaborate effectively? Most projects are not rocket science. When I talk to people about the reasons for their most successful projects (or their biggest failures), they don’t usually talk about technical issues. Instead, they explain the importance of openness, trust, collaboration, and communication, effective decision making and clear leadership.

Social risk does not appear to be on the radar screen of many organizations as they shuffle ‘resources’ from one project to the next. This is surely a contributing factor to the relatively low performance, engagement and morale that are common in large organizations.
Social risk mitigation in Scrum  A Scrum Team is a small group of people, less than ten, who work together over a longer period of time. While team changes are possible, they happen infrequently. The group becomes and remains a team that knows, supports and trusts each other. Scrum Teams value courage, focus, commitment, respect, and open…

Top Project Risk Number 7: Dependencies, or Resource Risk

Will the people who are needed be available when they are needed?
Many organizations are structured around skillsets or technology platforms, e.g. analyst, developer, tester or front-end, middleware, back-end, database. Since the back-end folks can't do anything without a database upgrade, and the middleware folks can't do anything without the necessary back-end functionality, etc. you end up with a lot of dependencies, which need to be managed.

Let's say Mary (remember Mary? We met her yesterday), a middleware developer, is scheduled to work on Project A until the end of the month, and then move on to project B. What happens if her work on Project A takes longer than expected? Either she is not available for Project B, so that project gets delayed. Or she gets put on Project B anyway, in which case Project A suffers an even longer delay.

Component teams create dependencies because they are not capable of creating finished functionality by themselves. Delays in one projec…

Top Project Risk Number 8: Stakeholder Risk

Will the stakeholders change, or even just change their minds? Just before my team was scheduled to release the first version of the product, the client’s pilot customer changed their digital marketing manager, who was responsible for the product. We made the release, and he was shocked: “You have created a web-based media tool but don’t support the basic tags required to track readership! How could you?!”   What happens if new people assume the role of key stakeholders in the project? Are they aware of and bound by the decisions about purpose, priority, scope or funding level made by their predecessors?

Even without personnel changes, decisions about prioritization can change any time and have an impact on many projects.

Let's say Mary, a middleware developer, is scheduled to work on Project A until the end of the month, and then move on to project B.  What happens if Sam, a stakeholder of the middleware team, tells Mary's manager that Project C is now the top priority? “Hav…

Top Project Risk Number 9: Change Management Risk

Will changing requirements delay the project?    “We had been working on a new hardware-based product for six months. One day, the sponsor came in and announced a change in the requirements that invalidated all of our work. The change was so fundamental that we had to start over from scratch. We wasted six months of the team's effort and delayed our entry into the market by at least that long.”


The lost revenue probably had a bigger impact on the company's bottom line than the wasted capacity. This kind of decision can also be very hard on the morale of the Team.
Change management risk mitigation in Scrum  Scrum addresses the change management problem in several ways:
At the end of every sprint, there should be little or no work in progress. This is a low-cost opportunity to change direction if necessary.The Development Team designs the product and their engineering practices to make change as inexpensive as possible, because it can happen every sprint.The Product Owner's …

Top Project Risk Number 10: Bullshit Risk

Are you lying to yourselves about something important?
“I am bidding on a tender. The client has put in requirements that we both know are physically impossible to achieve, but if I don't say I can do it I won't get the contract.”
“We have changed all of our job titles to be Scrum compatible, but we haven't changed how we work. All my colleagues are still working on three projects at once.” Scrum doesn't solve your problems; you solve your problems. If you follow Scrum, it will help you recognize issues quickly so you can deal with them quickly. These are called impediments. If you don't do anything about your impediments they fester, lower morale and performance, and can endanger the project as a whole. Impediments that are rooted in the contract can be extremely difficult to fix.
Bullshit risk mitigation in Scrum  The foundations of Scrum are inspection, adaption, and transparency. It only works if you tell each other the truth.

Respect the sprint contract! If yo…

Five Also Rans - Product Development Risks That Can Kill Your Project!

“These are the only ones
of which the news has come to Harvard.
There may be many others
but they haven’t been discovered.”
 – Tom Lehrer, The Elements While collecting feedback and materials for Ten Contracts, I received plenty of additional thoughts on what could go wrong. Top of the list were:
Too Many Cooks Risk: Are other vendors providing part of the solution? Are they working on an agile or a classical basis? Do you need to collaborate effectively across more than one company border? Who is empowered to address systematic impediments to success? Who gets to make decisions?Worthless Feature Risk: All features contribute to the cost of the product, and some features contribute to the value of the product. The goal is to identify and eliminate worthless features before wasting money on their development.Client Attrition Risk: Will the client discontinue the relationship if the deliverable does not deliver business value?Fake Scrum Risk: as Scrum been imposed on the team? It is sur…

Top Ten Product Development Risks That Can Kill Your Project

Every project has some degree of risk. Every project is a leap of faith. Risk identification and mitigation start long before the contracts are signed. Some of these risks can be mitigated or aggravated through the contract. What are these risks, how does Scrum mitigate them, and how do they play into the contract?


This series of articles will look at the top 10 risks of product development and how you can mitigate those risks in Scrum,

Most risks occur when you have to make a decision based on incomplete information. You make an assumption, take a decision, spend the money and hope for the best. Sometime later the facts will emerge. This is called validation. If your assumptions were correct, then you get the return or other benefits you hoped for. If not, your time has been wasted and your money is lost.

How big is the risk? A securities trader would explain that it depends on how much money is at stake and the duration of your exposure. Exposure is the period of time between maki…

Personal Agility: The Path to Leadership is released to early readers

Fifty some years ago, man from the planet Earth first set foot on the Moon. Two astronauts did the walking, and one person spoke the first words. But the effort was massive. It was probably the largest mobilization of a country’s resources for a peaceful purpose. Between NASA, the military, other government agencies and civilian contractors, over 400,000 people were involved in the Apollo program.

How do you organize so many people to achieve such a seemingly impossible goal in less than a decade?

Maria Matarelli and I have finished Chapter 5 of our book on Personal Agility! We look at Clarity of Purpose, Achieving Autonomy and Alignment, Connecting with People, How to be an Agile Leader and Achieving Results! Download it here! (registration required)