Business Transformation Digest: November 13, 2015

The BBC this week explores what having a manager like Steve Jobs can do to the workforce. This is important to think about if you want an empowered engaged organization.   Could your behaviors as a leader be preventing the very culture you are trying to achieve?

“So does being rude, ruthless and self-absorbed give you an advantage when it comes to getting ahead in business? Quite the reverse, according to Professor Christine Porath, at the McDonough School of Business, Georgetown University. She says uncivil behaviour from bosses and colleagues affects sickness rate and mental health, stifles creativity and above all affects staff retention. None of which reflects well on those in charge.”

http://www.bbc.com/news/business-34604387

The Economist explores the break up of HP. They point out that HP in the past was the original startup, but now is seen as stodgy and uninteresting to young engineers. And they point out that breaking the company in half does not change that image problem.

http://www.economist.com/news/business/21677635-hps-break-up-will-not-solve-all-its-problems-growing-old-not-together

Does your company or organization have an image problem? What kind of transformation could help change that? Renaming or reorganizing your group is not sufficient.

Harvard Business Review gave us three thoughtful articles this week in the areas of leading transformation, building culture, and being a high performing leader – all important parts of a business transformation.

First they explore Marissa Mayer’s recent actions at Yahoo. Ms. Mayer is leading a turnaround at Yahoo and asked for her leadership team to pledge to stay at Yahoo for 3-5 years to effect that transformation.  Some of her leadership team quit. But that is actually a good thing because now she has a leadership team committed to change.

In any transformation it is important for the leadership team to work together. While a pledge is not always needed, it was an effective means in this case for Ms.  Mayer to assure she had a committed team.

https://hbr.org/2015/11/marissa-mayer-was-right-to-ask-executives-to-commit-to-staying-at-yahoo

Employee engagement is a clear competitive advantage for a corporation, but how do you create an engaged workforce? One key component is to have a clear, compelling mission that people can rally around. This is especially important as companies grow.

This article has some practical examples of practices companies have used to engage the people who work there in the mission and vision of the company.

https://hbr.org/2015/11/how-upworthy-gets-its-staff-to-bond

“Leadership is messy, it is relational, and it happens in millions of interactions every day around real work. … You have to understand the social system you’re working in first.”

Not only do you have to understand the context you are working in, but high performing leaders also have regular ceremonies or routines. Identifying a few key ceremonies (such as one-on-ones or team meetings) and doing them well is a foundational skill for a high performing leader. The article has practical suggestions for how to do this.

https://hbr.org/2015/11/what-separates-high-performing-leaders-from-average-ones

My own offering this week encourages us to really look at the people we work with as individual people. If Steve Job’s management style tends to stifle creativity and engagement, what is a different way to work. This article explores some practical approaches to engaging people at work.

http://www.tomandgeriscrum.com/2015/11/03/people-are-people-not-objects/

Business Transformation Digest: November 6, 2015

Malcolm Turnbull, the new Prime Minister of Australia is calling for corporate Australia to develop a more open and flexible culture that embraces change:

“That means organisations need to be much less hierarchical, they cannot be blame-based,” he said. “You have to, as chief executives or senior executives; you’ve got to encourage the people that work for you to challenge you.”

http://www.theguardian.com/australia-news/2015/nov/06/malcolm-turnbull-woos-business-call-embrace-rapid-change

Though not a new post, this one makes an important distinction between a discrete change and a business transformation and argues we need to treat them differently.

https://hbr.org/2015/01/we-still-dont-know-the-difference-between-change-and-transformation

While it starts off suggesting that firing the leader when a transformation fails is a really bad idea, the post closes with 17 action items to minimize the risk that the transformation will fail. Some good advice in here.

http://www.huffingtonpost.com/terri-wallin/if-something-goes-wrong-f_b_7999166.html

Finally my own offering this week which reminds us that if we want to change people’s mindset and approach to work, we have to also change the environment they work in.

http://www.tomandgeriscrum.com/2015/11/02/to-change-a-mindset-change-the-environment/

People are People, Not Objects

I was recently reading “Leadership and Self-Deception” by the Arbinger Institute. Fundamentally, this about the two mindsets we have when interacting with others. We either see the other person as a unique individual or we see them as an object (problem, hinderance, annoyance, etc.). We go back and forth between these two mindsets all day every day, even during the same conversation, and they color the effectiveness of our communications.

I got a personal taste of this when returning home from the business trip where I was reading “Leadership and Self-Deception”. Since I live a 4 hour drive from the San Francisco airport, I had left my car at the airport parking garage for the return trip. When I got to my car, I discovered the battery was dead. I was a little annoyed by the delay, but someone from airport parking authority came right away, jump started my car, and I was on my way.

I got on Highway 280 and headed north to San Francisco. Just after exiting on Highway 1, the heavy traffic slowed to a brief stop and my car died. I was in the middle lane with no power in the car. No flashers, no lights, no starter. I was on a flat spot of the road and could not get the car rolling. There I was completely stuck with heavy traffic all around me.

I called 911 and a kind woman in dispatch took my information and forwarded it to the San Francisco police department. Meanwhile, people all around me were shouting at me and honking, but there was nothing I could do. I was feeling pretty miserable and I was afraid I might be hit by a car trying to go around.

Then a nice gentleman in a car on my left asked if I wanted help pushing the car. I replied that I thought it was probably too dangerous with the traffic. His companion pulled off the road and the gentleman carefully got out, paused traffic, and came to my car. He talked me gently through what to do as he held out his right hand to pause traffic to the right. People actually stopped and let us in!!

The next lane over was an exit to another road, and again a polite hand gesture stopped traffic to let us through. He pushed me past the exit to the right shoulder and said:

“A while back my car died on the Sacramento Bridge in heavy traffic. There was nothing I could do but wait for help. For 2.5 hours I was the most hated man on the bridge. So I had to stop to help you.”

People who were angry with me were treating me as an object, and it was a pretty miserable experience. I was upset and not thinking very well about what to do. The gentleman who stopped to help saw me as a human being in need and it changed my whole day. I still had a problem with the car, but I was able to resolve the issue (and get home) quickly, easily, and in a positive state of mind.

It does feel different to the receiver of your message when you view them as an object or an individual person. When you view them in any way as an object, no matter how kindly, they will tend to resist you and your message. When you view them as a person, unique and special, they will tend to be positive and receptive.

In business, we have to work hard to get over the people are objects mindset. How often do you hear people referred to as resources (you mean like paperclips?) or they are the “offshore group” or the “contractors”, but certainly not people like the employees right here in the room. How often do you refer to the people working for you as “my directs”?  Of course sometimes we need a shorthand way to describe a whole group of people, but if we get into the habit of doing it all the time, we stop seeing the individuals and just think of the group, and the group is usually “them” not “us” or “me”.

Language is a huge indicator of our mindset toward others. Being aware of and changing the language we use when thinking, writing, and speaking is a big step toward seeing others as people.

While reading “Leadership and Self-Deception”, it hit me hard that one of the business situations where we most often treat people as objects is when giving a presentation. The other people are “students”, “employees”, “delegates”, “congregation”, etc., but we are not thinking of each person as a person. They are not people “like us” because we are the “teacher”, “boss”, “expert”, “minister”, and so are in some way “better”. This us-versus-them mindset is treating others as objects. We are less effective at communicating our message when other people feel we are treating them as objects.

Interesting, in 2009 I took a workshop with Edward Tufte on data visualization. During the workshop he mentioned that he hates using PowerPoint. He says the word power describes precisely what happens – the speaker is in a position of power over the others in the room. He does not use presentation software in his workshops; he makes use of posters and other objects to illustrate his points, and he spends a lot of time walking among the people attending the workshop.

Over the past few years, I have worked with a small group of consultants on creating professional training that does not involve someone presenting at the front of the room.  Making the training more interactive is another way to get past the “I am an expert, you are not” mindset that creeps into typical training.

I have been doing something similar with progress reports. Instead of creating a typical report, I create some kind of interactive tool to help people get engaged with the information and make it their own. For example, after interviewing a lot of people on a particular topic, I created a poster that looked like a bunch of sticky notes with statements gleaned from the interviews. Then I invited the leadership team to not only review the suggestions, but cross off the ones they disagreed with and create their own stickies for things they thought were missing. This provided far superior feedback because the leaders were engaged with the information in a way they had never been when reading a report or seeing a PowerPoint presentation.

If you are paying attention, you will see that this article itself is not very personal. As an example, I will rewrite the previous paragraph using names of people instead of referring to them generically.  See how this changes the feel of the information for you.

“I have been doing something similar with progress reports. Instead of creating a typical report, I worked with George to create an interactive tool to help Helen, Mike, Sarah, Jason, and Henry get engaged with the information. After interviewing Mike, Sarah, Jason, Henry, Bob, Joe, Liz, Mary, Susan, and Paul, George and I created a poster with sticky notes that had statements from the interviews. Then I invited Helen, Mike, Sarah, Jason, and Henry to review the suggestions, crossing off those they disagreed with and creating new stickies for information they thought was missing.”

Now instead of a generic “leadership team” reviewing the information, we have Helen, Mike, Sarah, Jason, and Henry reviewing the information. It is easier to see them as people when they have names instead of a generic description.

It is real work to change a mindset from viewing people as people instead of objects. No one is perfect at it. But when we really try to think of the actual people, then not only do we communicate better, we also create a work environment that is a much more pleasant place to be. I think you will find that when you really focus on thinking of the individual people working for you, instead of thinking of them as “my directs” or “my resources”, you will become the kind of leader that everyone wants to work for.

To Change a Mindset, Change the Environment

An important thing in any kind of business transformation is to keep people as people in the front of your mind. We have a tendency during business transformation to think of people as “resources” rather than individual human beings. But people are not machines, they are individual humans with motivation and free will.

Real business transformation comes when we change people’s mindset. That means changing what is going on inside someone’s mind. You do not do that by telling them, exhorting them, or yelling at them. People change their mindset because it is in their own best interest to do so.

Look around your organization. You probably see some behaviors that do not make sense to you. Since people act in their own best interest, you can be sure there is a rational reason for how they are behaving. You just need to discover it.

Let me share a typical story about a Program Manager named Susan (this is a composite from many, many companies where I have worked over the years). Susan works for a very large company and is responsible for 50 people. She is typically overseeing 7 projects at a time. Susan regularly assigns each of her people to work on 3-5 projects at the same time.

Susan’s company is in the midst of “process improvement to be more efficient”, and so I met with Susan to work out together how her teams could be more efficient. I know that well-respected studies show that having a person on that many projects at once is very inefficient, so I was puzzled by how Susan was assigning people to projects.

As we chatted, Susan told me she is rewarded for filling up her people’s time 100%, she is rewarded for spending 100% of the budget, but she is not rewarded in any way for being more efficient. No matter what the executives said about efficiency, it was clear to Susan that they did not mean it because they continued to reward for inefficient behavior.

When what you say is opposite of how you reward, people will behave according to how you reward them. Your words mean nothing if the culture and environment do not support them.

If you want to change how people behave you have to change the environment they work in so that the desired behavior is something they see as in their own best interest. This may mean making change to any or all of the physical environment, business processes, metrics, rewards of all kinds including social, and practices. But how do you know what that change needs to be?

You start by identifying the behaviors that you want to change. Let us assume that the executives at Susan’s company are really serious about being more efficient and they select one behavior to change: we want the Program Managers to assign people to 1 or at most 2 projects at the same time.

Now we have to find out all the things that drive Susan to assign people to 3-5 projects. We know a couple of the reasons – fill up their time 100% and spend 100% of the budget. But what else? Why is Susan managing so many projects at the same time? Susan is rewarded by her boss for having a lot of projects in flight. The more she can prove she can handle at once, the more likely she will be promoted. George, the executive in charge of Susan’s division, says she shows she is a good person to promote by taking on every project requested and getting started working on it at once. Hard work, and even heroic efforts, are the things that are rewarded.

On the customer side, Susan’s peer Jeff is also rewarded for spending money as fast as he can. If he spends all his budget, he can ask for more, and so he is incentivized to start a lot of projects at once. He is also pressured by his boss to show he is “doing something” which is interpreted as running a lot of projects at once.

In this kind of environment there is no reason for Susan to change her behavior. Just asking her to do so will not help. Getting her training or a coach will not help. Putting up posters will not help.  Changing the environment is the only thing that will allow Susan to make the change that the executives want.

So what needs to change? One change is to stop rewarding people for spending 100% of their budget. In many companies this is very hard to do because the rewards (and punishments) are coming out of the corporate portfolio and funding process. If George’s division saves money he will find his budget cut the following year because “you obviously don’t need all that money”.  Or perhaps if George’s division saves money it will be taken away and given to another division that is running over budget.

In George’s company, people running the divisions with the biggest budgets are the most likely to be promoted to the C-suite and so having less money in his division is not in George’s best interests. He works hard to be sure all the money his division is allocated is spent every year, and even tries to ask for a little more at the end of the year to justify a larger budget the following year.

So even a “simple change” such as stop rewarding people for spending 100% of their budget is very hard to do. It requires strong support from the C-level executives and possibly the Board of Directors. This change has to start all the way at the top of the company with an overhaul of the corporate portfolio and funding process, and very likely with changes to how executives are rewarded (remember the bigger the budget the more likely someone is to be promoted).

Maybe a simpler change is to stop rewarding people for filling up 100% of their employee’s time. This practice came from a mistaken idea that busy is the same thing as productive. Instead of using hours worked as a measure of productivity, perhaps we could change to measuring cycle time – how long does it take from request to delivery of solution?

This change also has to go all the way to the top. The Board of Directors has decades of productivity numbers based on hours worked and if the metric changes, then they cannot compare the previous years to work going forward. They will have to work this out with the accountants and the legal department. Various US corporate laws make some kinds of changes very difficult to make due to having tax implications and possibly legal implications.

That was just two things that need to change before Susan will be motivated to assign people to only 1 or at most 2 projects at a time. Both of these “simple” changes require support from the top of the company as well as significant changes to how the company is run. And we still have not addressed all of the things impacting that one behavior!

Changing the environment also means the executives all have to model the desired behavior from the top down. Just as children imitate their parents (whether we like it or not), so employees take their cues from those in positions above them. After all, if you were successful behaving the way you do, then obviously the way for someone else to be successful is to model your behavior. The higher you are in the organization, the greater your impact on everyone in the company.

Back to Susan’s example. If Susan works for me and I want her to assign people to one or two projects at a time, then I have to assign Susan to one or two projects at a time, and I myself have to work on one or two projects at a time.

What does that mean assign Susan to one project at a time? Does that mean she has only one project for all her teams? No. Susan is a Program Manager, so she is not working in the projects. The Project Managers directly manage the projects. Her “project” is to oversee the set of projects her teams are implementing (which should be a number that is small enough she can actually oversee all of them). At the same time, I do not want to ask Susan to take on planning the organizational fall fest, and run the company’s Toastmaster’s club, and do that research project and special report I need for the CTO, and, and, and.

I also have to work on my own time management, focusing on one or two things at a time and getting them done before moving on. My personal example will demonstrate to Susan that this really is important to do. It will be far more effective than talking about it.

In addition to the other changes, one of the most powerful things you can do is regularly measure the behavioral change and publicly track progress. This provides a social motivator where people start to compete to do the right behavior.

Determining what to measure can be tricky because numbers are easy to game. For example, if we check the time tracking system to verify that each person is working on no more than two projects, we may very well find that line workers are being directed to only record their hours to two projects when they are actually working on several.

To overcome this problem, you may need to measure two or three different things and cross check them. In Susan’s case, the average project needs a team of 15 -20 people. Since 50 people work for her, if everyone is on one project at a time, she should be running 3 projects at a time. We can verify in the time tracking system that only 3 projects are being reported for her group. We can also estimate how much work 15-20 people can do in a month full-time on one project, then check with each project to see if it has progressed that far in a month.

These are not perfect measures either. At some point we have to spend time on the floor with Susan and her teams to know what is really happening. We cannot rely on metrics and statistics to know what real people are doing day-in and day-out.

To summarize: When doing a business transformation of any size, keep in mind that your people are human beings who will act in their own best interest. To change behavior, you have to find out what in the environment is encouraging the current behavior, and then change the environment to support the new behavior. Sometimes seemingly simple changes have to be made at the very top of the company. One powerful motivator is for executives to model the behavior in their own work that they want others to follow. Another is to use appropriate frequent measures of behavior change and post the information publicly.

If you have enjoyed this article, please share it with others.

Design Thinking for Rolling Out Change

A recent issue of the Harvard Business Review spotlighted “Design Thinking” with 5 articles on that topic. It appears that many executives are noticing that the practices of designers are being applied to business practices as well.

One use of design thinking they mentioned was the use of design thinking to plan for change.

A number of years ago I got to see this working at a large company that was using design thinking to create the change management plan for the roll out of a significant new software system that would impact a large percentage of the company. Not only was there a lot of new software, many business processes would need to change as well.

We started with observations and interviews of people who would be impacted by the changes to the software and the business processes. From that information, we created detailed avatars. Posters of each of the avatars were put around the building for everyone to become familiar with the people who would be affected.

Then for each avatar, we created a plan for how the roll out would work specifically for that person. We answered questions such as:

  • How would this person be notified when the change was released?
  • How would this person be able to get their questions answered about the impact on them of the change?
  • What training would be available for this person?
  • Did this person just need an informational meeting? Who was the best person to lead that meeting?
  • What if this person would be changing jobs or retiring within a few months of the roll out? How would that change that person’s participation in the roll out?
  • What is the best method to communicate with this person?

With answers to those questions, we could create a detailed change plan that addressed all the needs we discovered during the interviews and the creation of the avatars.

Like other good design thinkers, we did not assume we got it right! And so for any particular group of people, we tested the roll out plan on a few people and made adjustments based on what we learned. Our process was to do a little, test a little, get feedback, adjust, and try again.

By involving the users throughout the process, we had a very smooth roll out of the changes to the system and business processes, and it was accomplished with very little stress or anxiety.  While the new software and business processes were not perfect, the users were invested in making it work and they helped to find solutions. That is the benefit of applying design thinking to business transformation.

Business Transformation Digest: October 31, 2015

The big story this week comes out of Microsoft, specifically the Visual Studio Online group in the Developer Division. The Visual Studio Online group has 35 teams of about 12-15 people each, about 450 people total and they are Agile. Not only that, the whole Developer Division, about 4,000 people, is being Agile. “There is a pervasive Agile mindset in which respecting, valuing and engaging those doing the work in response to customers’ needs is at the core.”

Particularly notice that they really focused on Agile 5 years ago, they took a test and learn approach, and that the key to the whole transformation was not learning Scrum (relatively easy) but “the shift in mindsets for all involved” which has taken a very long time.

Microsoft is Agile Part 1

In part 2 where they get into details, I loved this description of the new Microsoft “Microsoft is not a giant warship, but more like a flotilla of speedboats operating in sync.”  This is a really important concept when thinking Agile in the large.

I also note this gem of a paragraph:

“The question addressed at Microsoft is: “How do we make the whole organization agile?” not “How do we scale Agile or Scrum?” In answering this question, the methodologies of Scrum and Agile in software development have a huge potential contribution, but they are only part of the story.”

Microsoft is Agile Part 2

In a related post, the author discusses when you should consider Scrum/Agile coaches. He argues that you may never need them if you work with the executives to create the right environment for Scrum.

I find myself in agreement with this approach. Change the environment to change the mindset and doing Scrum is as natural as breathing.

Coaching Agile from the Top Down

How Your Waterfall Project Can Be More Agile

5 Practices to Make Any Project More Agile

A core foundational concept in Agile is to get feedback from real users early enough to be able to address any issues that arise.  In traditional Waterfall, we assume we can do enough work up front that there will be no issues at the end, but reality shows that this almost never happens. Instead, at the very end of the project, we do User Acceptance Testing and discover issues that we either rush to patch or we plan a follow up project to address them.

Even if your project cannot adopt an Agile methodology, there is a better way to do Waterfall that still lets you take advantage of all the experience you have doing Waterfall projects and requires very little change within your organization.

There are 5 practices we strongly recommend because they can be done by any project following any kind of methodology. We have in practice with real projects seen them dramatically improve the results of Waterfall projects, and in fact have found historical evidence that some of these practices were recommended in the past for Waterfall efforts. These 5 practices are:

  • Divide the work into increments
  • Plan, estimate, and prioritize each increment
  • Synchronize work including vendors
  • Demo each increment
  • Retrospective each increment

This is what as known as Incremental Waterfall with the addition of the Agile practices of work synchronization, demonstrations of progress, and multiple retrospectives. For Waterfall projects, these practices should not require much change to current processes. Some of the phase gates may need to be passed each increment, such as detailed requirements or design each increment, so some additional time should be allowed for in the schedule. The time is made up later when better quality leads to shorter test cycles and involvement of users means much less (if any) late rework. Big picture work such as overall planning, high level requirements, architecture, and solution selection can be done at the beginning because they are common across all increments and typically do not change much throughout the project lifetime.

In general the approach for a Waterfall project will be a relatively short up front planning, requirements, and architecture phase followed by a set of increments for implementation. Each increment will include the work of detailed planning, requirements, design, implementation, and testing. The complete release process may take place at each increment if desired, or may be delayed until the end of the project.

Each practice is described in more detail below.

Divide the work into increments

An increment is a working subset of the overall solution. This practice would mean examining a project to determine the best way to divide it into 2 or more incremental deliveries of working solution. Note that these deliveries do not have to be general availability, but rather could be collected in a holding area until the whole solution is complete. But each increment will go through a full test cycle including especially user acceptance testing.

The criteria for determining what goes into each increment should include business value (the most valuable work should be done earliest), risk (we should use feedback from real users to drive out risk as early as possible), and the ability to deliver a working subset of the overall solution (minimum viable product). This practice by itself has dramatically improved traditional Waterfall projects by providing feedback well before the end of the project.

In fact, this practice was proposed for Waterfall projects in 1970 by Dr. Winston W. Royce based on his previous long time experience with large Waterfall projects (Managing the Development of Large Software Systems, Proceedings IEEE Wescon August 1970, pages 1-9). His experience and research showed that there would almost always need to be at least a second increment of a Waterfall project to refine the solution based on lessons learned, and so teams should just plan for it. We see the same realization at most of our large customers, where large Waterfall projects have typically been followed by another improvement or fix-it project. We are suggesting to formalize this practice with multiple planned increments of any software project.

Plan, estimate, and prioritize each increment

No matter the length of the increment, the detailed work planning, refining of estimates, and prioritizing of work should happen not long before the start of the increment, instead of doing all of it up front for the whole project. This allows the flexibility to take advantage of lessons learned in one increment to apply to the planning for subsequent increments. It is also a good time to review project metrics to verify the work is going according to plan, and allows a planned time to make adjustments as needed rather than waiting for the end of the project to discover there are issues.

We expect high level planning at the start of the project for all except the most innovative and fast-changing work (which by nature cannot be planned much in advance). This practice is to wait to do detailed planning until just before you need it so that the plans are the most accurate based on the information you have to date. This practice avoids spending time doing detailed work that is likely to be changed later in the project. The less well-understood the work is, the more important this practice becomes.

Synchronize work including vendors

Everyone involved with the project should regularly synchronize their work, including a representative from each vendor. This synchronization can take the form of a daily standup. In some cases, that may be more frequent than needed, but this synchronization should take place at least weekly. Synchronization should be often enough to remove the risk of unnecessary delays due to unknown work blockages.

Note that this is not meant to be a long status meeting, but is rather a 15 minute or less structured ceremony where each person just states what he or she has recently completed, what work he or she is working on now, and anything preventing (blocking) the person from completing his or her work. The most important information to come from this meeting is typically the blockages. The work blockages can be addressed after the synchronization meeting.

It is very important that the vendor representatives be included. A big problem when working with vendors is lack of visibility into what they are working on. Communication can be difficult already when working with another company, so anything we can do to promote regular, meaningful communication will improve (sometimes greatly) the work we do with vendors. Our customers who have worked this way with vendor representatives report a uniformly better experience than just handing work “over the wall” and expecting everything to be fine.

Demo each increment

At least once per increment, the working solution is demonstrated to at least the project sponsor and stakeholders. By far the better choice is to have real end users also attend the demonstration. This demonstration has two purposes: it provides a real deadline when work has to be finished so that it can be demonstrated, and it provides an early opportunity for users to provide feedback on whether or not the solution meets their needs.

Note that this does not replace formal user acceptance testing, but rather is a demonstration of progress and an opportunity for feedback well before the end of a project. Instead of providing status through reports showing perhaps 85% of requirements are completed (for example), we demonstrate working solutions as a measure of progress. If the solution is not complete enough to be demonstrated, we count it as zero percent complete.

We treat solutions as zero complete or 100% percent complete and do not try to determine an increment in between. This is because with any kind of knowledge work, it is not actually possible to truly determine how much is left to do. We can only know how much has been done. We all know of cases where the solution was 90% complete but that last 10% took 90% of the resources. We prevent that in this practice by only counting a 100% solution as complete and anything else as zero.

The demonstration provides a good opportunity to review the progress of the project to get an idea of whether it is on schedule, ahead, or behind. The outcome of the demonstration is that either the work to date is acceptable as is, or defects or change requests are created to fix problems that are detected at the demonstration. The work to fix the defects or change requests can be planned into subsequent increments of the project so that these problems do not exist in the released version of the product.

Retrospective each increment

Most companies have some kind of retrospective or lessons learned at the end of a project. Unfortunately, that is too late to do any kind of good for that team. Instead, at the end of each increment, the team will review the past increment, and in a non-judgmental way discuss what went really well, what did not go so well, and what they will do in the next increment to improve as a team.

We suggest the team start the retrospective by reciting a statement such as “We acknowledge that everyone has done the best job they were able to do in the circumstances that existed during this increment” and suggest the team end the retrospective with expressions of gratitude and thanks to other members of the team or even people outside the team who helped in some special way (it is nice to let those people know in person that they did a great job if they do not happen to be at the retrospective). This helps set a non-judgmental tone to the ceremony. The most important thing is to avoid blaming and finger pointing, to make the ceremony constructive.

The outcome of the retrospective is a small set of specific action items the team will take to improve the coming increment. We recommend starting with just 1 or 2 action items so as to not overwhelm the team with improvement work while they are focused on delivering a product. Often the outcome of the retrospective are suggestions that become habits over time, as the team incorporates better and more efficient ways of working together.

Setting up Your Programs for Success

With all the conversations about SAFe, you would think programs were a new idea. Actually, they have been used for many decades to manage very large efforts. This article discusses lessons learned from the past about how to set up a program at the beginning so it will run more smoothly throughout.

A program is one kind of construct to organize and coordinate the work of a large number of people on the same deliverable. Other constructs include value streams, products, product families/lines, and the open source model (community ownership of software with rules and governance). I have heard of programs as small as 40 people contained within one company and I have been personally involved with programs involving hundreds of people, sometimes across several companies or countries. Programs are used to manage big efforts.

Programs were developed in the defense industry to manage efforts such as putting a man on the moon, creating a new submarine, or creating an overall battlefield management system. Programs were adopted in commercial enterprises to manage efforts such as SAP implementations or creating a new tractor. Creating a mobile app does not require a program.

Programs are used to manage large complex efforts. A key technique to managing complexity is to structure the work in such a way as to get rid of as much complexity as possible. Simplify as much as possible, then manage the rest.

When planning your program, assign work to individual teams in such a way as to reduce or remove dependencies between teams. Each team should work as independently as possible. There should be little or no dependencies based on time, code, functionality or any other factor.

You can achieve this independence by assigning complete independent work packages (for example use case, user story, subsystem, component, or task) to each team. If the work packages are truly independent, you should not have very many cases where multiple teams need to work in the same code base, nor should you care much about what order the work is completed.

Any points where the teams need to cooperate should be well defined using tools such as contracts, interfaces, services, or API’s. Test harnesses and stubs can be effectively used to keep the work of the various teams as independent as possible, allowing each team to test their own code even if code they need to use from another team does not yet exist.

Teams should NOT be set up around the SDLC, i.e. a requirements team, design team, coding team, and testing team. This creates unnecessary dependencies between teams such as the coding team is waiting on designs, the testing team is waiting for code, etc. Each team should be responsible for the complete life-cycle for the work package they are assigned.

You do have to plan coordination points for releases. Teams cannot work on whatever they please. Each team has to make a commitment to deliver certain functionality at a certain time with specified quality. This is a commitment to their co-workers on the other teams. There may be other work a team does as well, but there has to be a minimum set of code they complete by a specific scheduled date in order for everything to fit together. You have to carefully manage the teams so they deliver what they promised the other teams at the time they promised to deliver it. If you do a good job defining the integration points between teams and managing their work to complete on time, then integration of the work of the various teams should be fairly straight forward.

There has to be a program level management team whose job it is to create the appropriate work packages, set up the release schedule, assign the work to the teams, define the minimum each team is required to deliver to make the release, coordinate the work of the teams, remove obstacles between teams, and be the final arbiter in situations of disagreement. People managing the program may include architects (software, system, network, data, UI, business) as well as those in more traditional management roles. You may need people at the program level to create (or help create) code that coordinates the work between teams such as test harnesses, stubs, interfaces, services, or API’s.

While you can do a whole program with one release at the end, this is very high risk. Programs tend to be lengthy and much can change from beginning to end. It is much better to plan a series of releases with time scheduled to make any needed adjustments due to change or lessons learned.

In a well structured program, you do not have to care about how each team does their work. As long as the team delivers according to their contract, it does not matter if they are onshore, offshore, or vendor, or whether they use an Agile or Waterfall type of SDLC.

Finally, the key to a well-run program is monitoring the teams and their progress with appropriate metrics, regular meetings with a representative from each team to coordinate efforts, management by walking around when you can, and quick resolution of problems when they arise.

Lean Startup Ideas for Mitigating Business Risk

All businesses exist to deliver the right product or service to market, at the right time, for the right cost. All business risk fundamentally puts one of these items in jeopardy, and so our fundamental business risks are:

  1. Failure to deliver the right product or service

  2. Failure to deliver the product or service at the right time

  3. Failure to deliver the product or service for the right return on investment (ROI)

  4. For companies in regulated industries we also have failure to comply with all laws and regulations

These risks are fundamental to business, and do not change based on the processes or procedures used to create or deliver the products or services. All risks we identify that are specific to processes or procedures must address one of these fundamental business risks.

For example, business continuity procedures help some companies, such as those that deliver SaaS or hot line support, ensure that they deliver the product or service at the right time. In this case, business continuity procedures are extremely important for staying in business because delivering the service at the right time means the service is available all the time.

In addition, we should consider the cost of controlling that risk versus the effect it has on the business risk. Controls that have a small impact on the fundamental business risks should either not be used or should be very inexpensive to implement.

As one example, many companies say they have a risk of project failure, which they define as going over schedule, over budget, or both. I have worked for a number of companies who delivered every project on time and on budget, and their products failed on some or all of the fundamental business risks. I have worked for a number of other companies who did not always deliver their projects on time or budget, but did in fact deliver the right product to market at the right time for a very nice return on investment. In these cases I observed, the risk of project failure did not have a strong correlation to a fundamental business risk. Controlling for project risk only weakly controlled for business risk.

What that tells me is instead of assuming that the project lifecycle is the problem, we should do a root cause analysis to determine the actual problem. Maybe we are running projects poorly. Or maybe we are failing in marketing and sales. We should find the real problem and invest in controls that have a strong correlation with product success.

What is a control? By definition a control is a process that reduces risk. Typically a control is a mitigation strategy that is formalized. Documents are not controls. Documents are also not evidence that a process was followed. We all know of delivery teams who did not follow a specified process but created the document that “proved” they did at the end of the project. I have seen many documents that were supposed to prove that a process was followed, that were merely copies from another effort. Many times, the project name was not changed throughout the document, nor the dates when the work was supposed to have been done.

A control is a process. Therefore, if you want to audit for the control, you have to audit the process. Most of the time, that will mean observing the process as it is being done. If all the auditors do is look for a document that says the process was done, then you have incurred cost with zero benefit. If your company is typical, your people never have enough time to do everything, so they will cut processes that are only audited by document and do the fastest job possible to produce the required documents. Since the process is most likely not being done, either the process is not necessary to control for risk or you have been lucky.

Given all that, what are associated risks and mitigations for the fundamental business risks? Below are some examples of possible risks and mitigations for the fundamental business risks listed above. The mitigations are heavily influenced by Agile and Lean Startup thinking, so may or may not be appropriate for your business.

Business risk: Failure to deliver the right product or service

Associated Risk Mitigation
Your market is not well-defined Leadership in the company should go through an exercise of defining the market for each product and service. They might be the same, they might be different. It is not good enough to say “Our market is men.” Or “Our market is middle-aged people.” It is almost certainly true that those markets are too big. Get specific.
You do not understand your market Company leadership should ideally be from your target market or have a close relationship with your target market. You can also use focus groups, advisory boards, and other techniques to get a better understanding, but there is no substitute for personal knowledge.
The product or service is poorly defined This is common early in product development, but must be mitigated before the product or service goes to market. The best mitigation is to do a little, test it with users, based on feedback do a little more, test again, and continue this until you have a viable product. Whatever prototyping you do, find the least expensive, fastest way to do it.
The users do not want the product or service The best mitigation is to get real users involved in developing the product or service. Not just one group of users (you end up developing something just for them), but bring in many different groups of users over time who represent the breadth of your market.

Business risk: Failure to deliver the product or service at the right time

Associated Risk Mitigation
You deliver too early Find real users who are connectors and recommenders. Get them involved in the development process. Encourage them to help prepare the market for the coming product.
You deliver too late Identify a minimum viable product. Develop that first, and keep it always ready to go. You can release that at any time if you have to quickly go to market and follow up with additional features later.
You deliver too often Solicit feedback from real users all the time – forums, blogs, Facebook page, etc. They will tell you if they are getting overwhelmed. When possible, track the use of the different product features. If you are delivering new features and no one is using them, you are probably delivering too often.
You deliver too infrequently The same as delivering too late, always have something new ready to go. Solicit feedback from real users all the time. They will tell you if they are tired of waiting for new features.

Business risk: Failure to deliver the product or service for the right return on investment (ROI)

Associated Risk Mitigation
The size of your market is smaller than you thought Discover if there is a broader market who can also make use of your product or service. Cut back on your product plans to match the size of your market.
Your market is not finding out about your product or does not see the value in it Assuming you have identified the right market and product, then along with traditional marketing, find connectors and recommenders, get them involved in developing your product, encourage them to recommend your product to others. Also, look for related products where you can piggyback your marketing efforts. Joint marketing with another company could be quite effective.
The cost of development was too high when compared to sales or other benefit received (low ROI) Identify the root cause. Were you overly ambitious compared to market demand? Then you need to cut back on your development efforts. Was the development process inefficient (heavy process, too many people, too many metrics, too many meetings, not enough experience in the development team)? Bring in someone to help improve your process. Was the failure in the sales team – not enough sales to recover the cost of development? Maybe you need more experienced sales people, or they need better training on the product and benefits, or they need coaching on sales techniques.

Business risk: Failure to comply with all laws and regulations

Associated Risk Mitigation
Discovery of non-compliance and the consequences of it (product removed from market, product reworked, fines, prosecution, restitution) Educate your workforce on the laws and regulations. Review product and service offerings with lawyers, regulators, and other experts as appropriate. Keep records of all recommendations by lawyers, regulators, and experts. Be aware when there are changes and have your product and service offerings reviewed for compliance with new laws and regulations. Be sure all product and service offerings are updated within the time frame allowed.

I hope this article has you thinking more about how to control for risk. Doing the same thing “everyone else” is doing may not be the right thing for your company. Go back to the fundamental risks and discover the best way for your company to reduce them.

Tips for Job Searches

While not specifically Scrum or Agile related, I know at any particular time many of you are likely looking for a job.  If that is you, read on.

I recently put together a workbook that steps you through using the Strengths Finder quiz to find keywords to use in your resume, LinkedIn profile, and cover letters. These keywords are your strengths, as well as being the search terms that recruiters use to find people for jobs.

Right click on the link to download the PDF.

Using Strengths Finder to Get the Job You Love

I hope you find this useful.

Geri