Side Stepping Landmines: Managing Risk With Sprint Futurespectives

Risks Are Landmines

Risk and project issues are one of the roots of poor project performance. There are three areas that we measure regarding the success or failure of a project; these three areas are what we call in project management, the triple constraint. The triple constraint consists of scope, budget, and time.

The interactions of these three areas are a lot like Newton’s third law of motion. For every action, there is an equal and opposite reaction. Was there a decision to increase the scope? You’ll likely need more time and money. Has there been a cut to the project’s budget? There most likely needs to be a cut to the scope. Has the schedule been crashed and we need to get to market in two months instead of the planned six? Better give me more money and be prepared to cut some of that scope down to a “minimal viable product.” I think you get the idea.

The triple constraint consists of scope, budget, and time. The interaction of these three areas are a lot like Newton’s third law of motion. For every action, there is an equal and opposite reaction.

This is why scrum is so effective. It allows for business agility via quick decision making from the Product Owner and iterative delivery of working software from the team. Scrum deals with actions effecting the triple constraint rather well. Project issues concerning the budget or schedule can quickly be addressed by everyone and the Product Owner can assess the business impact to make a decision that usually concerns scope.

However, when a team starts off on a new project that has a medium to high amount of risk and uncertainty, I recommend allowing teams the time to mull over possible risks and to perform some pre-planning. Otherwise, the project can blow up in their face or decisions will be made for them by the changed environment. We address this with risk planning — we don’t send our soldiers into a battlefield knowing land mines exist. So how can scrum teams plan for risk?

Risks are landmines. Some we know about. Some we don’t. Creating a plan to navigate and manage the consequences of a triggered mine is the only way to help us navigate a minefield responsibly.

Conduct A Futurespective

Thinking ahead and talking can help, but writing down potential risks and plans to address them is even better. This is the point of the “Futurespective;” To conduct risk planning at the start of a project or product enhancement and to give the team some time to do some planning before stepping on a potential minefield. It’s an activity outside of the typical scrum events and because of that, it should not be done before each iteration. Instead, it should be done provided select circumstances:

  • Just before beginning a new effort (i.e. Sprint Zero);
  • Just before a critical milestone (i.e. a new feature release to Production);
  • A significant change to a project constraint is anticipated (i.e. change to schedule, scope, budget, or quality). 

Just Before A New Effort – The Sprint Zero As A Futurespective

The Sprint Zero is an activity I’ve seen successful teams use when they conclude one effort and move to another. There is no such thing as multi-tasking and that is why we should frown upon teams who work on multiple projects at once. What they’re really doing is engaging in “task-switching” or inefficient “serial-tasking.” Instead, we encourage the team to wrap up a product feature and release it to production for general use before moving onto another product.

The Sprint Zero is the time between efforts that allows teams to assess what the new project or product enhancement is. If they’re cracking open the code for an existing product to add a new feature set, they should be allowed up to two weeks depending on the complexity of the code. For older, more monolithic applications, carrying large amounts of technical debt, I’d recommend no time-box on this activity. Let the team take their time getting familiar with the product, the code, and documentation (if it exists or is up to date). If there is no documentation, stress the importance to managers that they should not be rushed into starting the project until they are ready. Let the team decide when they’re ready to begin and use common sense.

If the team is about to spin up a new project and create a new product from the ground up, there should already be a product backlog and roadmap ready for them to review. The Sprint Zero is a great opportunity for the team to familiarize themselves with the backlog, Product Owner, Subject Matter Experts (SMEs), and stakeholders of the new product. The team should be conducting working sessions to create better acceptance criteria for user stories, sketching wireframes, and getting a better understanding of what they are going to build. Encourage them to seek continual feedback on their wireframes and designs. Make it an iterative activity. Teams may also take some time to engage in training if they will be developing in a newer development framework. Again, exercise common sense and decide on a reasonable time-box before kicking off the project.

Just Before A Critical Milestone – Release Planning As A Futurespective

Usually a sprint or two before releasing a larger feature, the team should have a handle on the stability of their product. Testers have been giving Developers feedback on the quality of their code via Integration & Performance Testing and of course, Bugs. The Product Owner is busy preparing, coordinating, or wrapping up User Acceptance Testing (UAT).  The Scrum Master is busy assisting everyone with Impediments and UAT. It can be chaotic or running smoothly… sometimes too smoothly…but, maybe I’m just naturally pessimistic?

I find this is a great opportunity to use the time normally allocated for a Retrospective as a way to plan for risk and get everyone together for the release plan. Of course, the need for this will eventually disappear as practices become better and code is pushed into production more rapidly via continual integration and continual deployment, however, I recognize that it can take a while to get to this point.

The need for this will eventually disappear as practices become better and code is pushed into production more rapidly via continual integration and continual deployment.

There are multiple ways to conduct a Futurespective and each one could use their own article. However, it’s a good idea to invite the Product Owner and SMEs to this event. To be concise, I’ll give you the meat and potatoes of what makes a good Futurespective.

  1. Identification of plausible risks regarding the release
  2. Statement of assumptions about the release
  3. Statement of the issues currently occurring (problems & challenges the team is experiencing).
  4. Identification of dependencies effecting the release (technical or cross-team dependencies the team or organization has). 
  5. Written mitigation plans that is developed by the team and Product Owner.
  6. Assignments/Owners for each plan (“if risk 2 is realized, who is the person responsible for leading the plan?”). 

A Significant Change To A Project Constraint

When a business priority changes and the project’s budget, schedule, or scope, is effected, the Product Owner may decide to stop the iteration and cancel the sprint. The Product Owner should call the team together and appraise them of the situation and call on the team for advice. Ultimately, the Product Owner will likely make some tough decision about cuts to the product scope. The Product Owner should use her Subject Matter Experts, stakeholders, and Delivery Team to make the most informed decision possible. It’s a great opportunity for everyone to brainstorm with the Product Owner about the best way to continue moving forward and exercise business agility.

Prioritizing the Product Backlog and refining user stories that were in the “freezer” takes a lot of effort and planning. Schedule as many backlog grooming sessions as needed and run a Futurespective before proceeding.

Thanks for taking the time to read and I hope you found it useful. I’d love to hear your thoughts on risk management or any experience you’ve had with Futurespectives. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Photo Credit: Pixabay

Related Posts

The Scrum Product Owner Chooses Business Value

The Product Owner Steers The Ship

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, And Jaded Sage

The People And Process Balancing Act

The Agile Manifesto Teaches Individuals and Interactions Over Processes and Tools

There’s a common misconception, especially among those new to Agile, that the relationship between people and processes is one of friction — that it’s a dichotomy. The subtlety of the language used, “individuals and interactions over processes and tools” implies that both need to exist. The framers of the Agile Manifesto even state, “while there is value in the items on the right (Processes and Tools), we value the items on the left more (Individuals and Interactions).” I agree with this and would also argue that processes and tools are an input to productive interactions among individuals. We know what is more valuable according to the Agile manifesto but, which one is most important? People or Processes? Maybe we’re thinking about it all wrong?

Chinks In The Armor

Asking, “what’s more important, people or processes?” is a fair question to ask when you’re new to Agile. Especially since most organizations looking to “go Agile” start with Scrum (by the way, practicing Scrum does not mean you are Agile. It’s a great start as long as the leadership team continues to stay open minded and doesn’t limit the organization to just Scrum). Usually, a handful of developers, project managers, business analysts and line of business managers are sent to a two-day class scrum class; they receive a certificate dubbing them newly minted “Certified Scrum Masters/Product Owners/Developers” and are given a small project to show a “proof of concept” with the

storm trooper
Scrum Reveals The Chinks in the Armor

new framework. It’s chaotic and exciting at the same time; however, the organization’s weaknesses begin to show up (Scrum has a way of shedding the spot light on the problems that have existed in the organization for a long time). I call these the “chinks in the armor.”

The biggest chink I’ve seen most teams discuss in their retrospectives are the People vs Process Dependencies. Invariably, team members and managers dig in their heels about which one is better. This is because people default to what they know best. They use what has worked for them in the past. Change is hard, even when there’s clear evidence that what they’ve been doing will not work anymore because of changes in the business environment.

As a coach, it’s important to understand the pros and cons of the people and process dependencies. It should be explained clearly with not only your teams but, with the management team too. The organization will have to move past striking a balance and figuring out which areas need the most improvement. Instead, they should assess the parts of each dependency and figure out what works best for them today. Below are some extreme examples of each dependency to illustrate the pros and cons of both.

People Dependency

Pros

  1. It gives workers satisfaction – employees feel satisfied when they know they are valued
  2. Flexible – employees are empowered to perform work in the way they feel is best
  3. Adaptable – the ability to pivot and make changes is the hallmark of business agility
  4. Efficient – unnecessary steps in a process are avoided
  5. Helps to retain high-achieving, confident, people – people stick around because they know they are important and are good at their job

Cons

  1. Less repeatability – changing processes are not repeatable and leads to waste
  2. Makes customers nervous – customers feel comfortable when there’s visibility on the process
  3. Can provide a “false sense” of a high degree of control – processes are measurable. What get’s measured gets done. When managers rely solely on the self-reporting, certain messages may get filtered and there is no data to verify.
  4. Turnover impacts are much greater – institutional knowledge can walk out the door or get hit by a bus
  5. Higher risks – for the reasons listed above

Process Dependecy

Pros

  1. Repeatability – repeatability helps with predictability
  2. Easier to improve – a documented process is easier to improve with less risk to the organization
  3. Less people dependent – automation of easily repeatable tasks frees up resources for more value added activities
  4. Predictability – it can be measured objectively and relied on as a lever for control in the organization
  5. Brings new personnel up to speed faster and with less risk of poor performance

Cons

  1. Paperwork can overshadow the task – processes that are overly complex distract from value added work
  2. Resources must be spent enforcing or ensuring compliance – managerial debt is incurred. Managers spend less time removing impediments and more time micromanaging processes.
  3. Someone must own and manage the process
  4. Less “thinking” is needed – employees and managers can become complacent if there’s no impetus for process improvement. This leads to waste. 

Processes Come First But They Should Not Be Valued

I know I’m going to rub a few people in the Scrum community the wrong way (and probably piss of a few of the business process analysts too) But, processes should come first but they should not be valued in the same way we value our people and interactions. It’s easy for managers to regard processes as instruments for control. Some managers finely craft their business processes. They labor over them and build complex systems for the organization. But only effective processes facilitate people. Not complex ones. If you require a practical rule of me, I recommend you murder your darlings.

“Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it — whole-heartedly — and delete it before sending your manuscript to press. Murder your darlings”

— Arthur Quiller-Couch,

On the Art of Writing

vintage scale.jpg
People and Processes Are Not Equal

I argue that people and processes should not balance each other. Many representations of this balancing act builds a false dichotomy. It implies that they are of equal value. Like the framers of the Agile Manifesto, I do not value them the same way.

Processes should support our people and facilitate their interactions. Processes are either operational, supporting, or management oriented. If they do not provide value. Murder them. It’s up to the teams to decide which processes they need most and which ones can be forgotten. Each organization is different. Each darling should be judged accordingly — but retain the ones that still add value. Don’t throw the baby out with the bath water. Don’t assume that just because you’re “doing Agile” that processes no longer needed to exist. No, processes are still important. They unlock your people’s ability to work at a higher level. But it’s time to end the love affair with processes and value your people.

Share your thoughts in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum

Improving Agile Retrospectives With SMART Goals

Six Elements of An Effective Strategy

 

 

 

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, and Jaded Sage

Urban Legends and The Organization

I recently started binge watching a show called Supernatural. For those of you unfamiliar with Supernatural, it’s about two brothers, following in their father’s footsteps, traveling across mid-west America, solving mysteries of the paranormal. They’re a part of a small community of “hunters” who vanquish demons, ghosts, shape-shifters and other urban legends (great show! I highly recommend it!).

While watching S01E05, an episode based on the “bloody mary” urban legend, one of the brothers makes the statement, “all urban legends are based on some version of the truth.” This got me thinking about the urban legends that exist in our organizations and prompted me to reflect on when my own organization first adopted Agile to manage our projects.

“The seed of an urban legend find fertile soil at the corner of tragedy and imagination.”

― Thomm QuackenbushWe Shadows

Bad Advice: Ignore The Nay Sayers…

About a year and a half ago, I was one of the leading change agents in our IT Operations Section. I coached and taught Agile to our Server Group, Network Group, Desktop Support Team, Service Desk Agents, Database Administrators, a GIS team, and a Software Development team. Each team had one or more people labelled by management as the “naysayers.” I was warned to ignore them and push forward. However, I felt this was the wrong approach.

Naysayer or Jaded Sage?

I say embrace the naysayers. They are the organization’s seers. They have been around the block, seen past failures and experienced a variety of initiatives from different management regimes. They’ve lived through the failures of past projects. Over the course of their careers and their tenure, they have accumulated sage like experience. Unfortunately, the naysayers have become a bit jaded and skeptical of “initiatives” they’ve seen fail in the past. One might say they’re not quite ready to start “drinking from the kool-aid.”

Some of these urban legends sound like…

  • “They’ve tried this before…”
  • “Just another management fad…”
  • “Why are they trying to reinvent the wheel…”
  • “They’re asking us to do things outside our work performance standards…”
  • “They can’t throw this in the mix, we’re busy trying to keep the lights on…”
  • “They keep shifting priorities, we can’t keep up…”

Identify Project Risks With Respect and Empathy

Seeing repeated failure is frustrating. It’s only human to become frustrated and fear failure. Sometimes it sounds like the naysayers are full of “doom and gloom” but their urban legends really only spur from a place of fearful imagination. Because of their fear, there’s a certain level of “attitude” and defensiveness we may face we when first initiate a dialog with our jaded sages, however, treating them with respect, dignity, and lots of empathy will go a long way. This attitude will quickly dissipate and they’ll open up and impart some of their wisdom and lessons learned.

Our Goal Is To Identify Project Risks Early

Our goal is to identify project risks quickly and find that grain of truth in their urban legends. Their wisdom should never fall on deaf ears. As a coach, project manager, or product owner, it’s our duty to ensure our organization doesn’t miss out on opportunities to learn from past mistakes and to identify risks as early as possible so they are not realized, or at the very least, so risks can be mitigated and managed.

As a project manager, we can add these items to our risk management plan and start a qualitative analysis with the project team. Product owners and scrum teams can conduct a retrospective focused on the risks. Some of my favorites are:

  • The Sailboat – Use this technique to identify what things are helping the project, what is slowing the project down, and what risks are ahead (I like to draw a pirate ship and jagged rocks below the water line and differentiate between known risks and possible unknown risks for prioritization).
  • The 5 Whys – Use this technique to help identify root causes of known risks and get at the root of problems.
  • SWOT Analysis – Strengths, Weaknesses, Opportunities, and Threats. A classic technique usually used to form organizational strategy can easily be framed for risk identification. I like this one because “opportunities” can include good risk that we should plan for (example: We are planning an event for 200 people, however, what if 1000 people show up? This would be a good thing but jeopardize the success of the event if we don’t have a contingency plan to accommodate the extra 800 guests).

If you’d like to discuss more about managing risk and dealing with naysayers, I’d love to hear from you! Let’s connect and have a conversation.

 

Photo Credit: Flickr