What Kids Taught Me About Being Agile

While agile initiatives now spread beyond IT within the corporate world, one may wonder why we tend to brand these changes as “transformations” or “transitions.” After all, we are merely going back to a state of being which we have in fact experienced for years, not as adults but as children. 

For several years, I ran my own small education business. I taught children from the ages of 6 to 10 about science and technology, specifically space and robotics, my favorite topics, with the help of LEGO® bricks, my favorite toy.

As I was busy with this endeavor alongside my daily job as a software development manager, I got plenty of opportunities to compare first-hand the difference between kids being agile and adults doing agile. This was a topic that surfaced in many agile coaches’ narratives, but it was only then that I truly understood it.

Make a Plan, Then Change It

One of the most striking things I noticed during my students’ activities is that when children are taking on a task, whether self-initiated or not, they always seem to have a plan. The plan is clear only to them and continually changes, but it eventually leads somewhere. Even if that means starting again, they reach the finish line quickly and iterate successfully.

It’s no wonder the Marshmallow Challenge, your typical team building exercise in a corporate offsite event, is often said to be better accomplished by children than MBA grads.

Ask Why (And Truly Mean It)

When children ask “why?” they are truly curious and will likely dig further and further until there are no more answers to be had. They have neither a fear of asking nor a sense of shame, a quality which increases their learning and creative capabilities.

By contrast, adults tend to think twice before asking questions, and we feed ourselves on guesses instead.  We tend to be paralyzed by our culture, our pride or fear of judgment from our peers. Either way, we miss opportunities to enrich ourselves, while children have already moved on to their next learning experience.

Flag It as It Is

Learning how to give feedback to each other can be a daunting task for agile team members, and we often associate criticism with its destructive meaning. In contrast, I would safely bet we have all experienced a very direct, sometimes crushing and often tactless (but always honest and “fairly” constructive) feedback from a child. We can all learn something from them.

Collaborate Rather Than Cooperate 

I often tried to divide work and responsibilities among children in my workshops so that they could cooperate in building a larger LEGO® assembly. In most cases, my efforts initially failed, or at least felt like a failure. In fact, these little builders were often inclined to drop their own task to go and help a playmate realize his or hers.

By trying and iterating on the task together while sharing a goal, true collaboration was born and the children’s learning experience was greatly enhanced. The opposite tends to be true in a professional environment, where a culture of individual goals and target-setting has traditionally reigned supreme.

While agile coaches can certainly help guide and scale your organization in the right direction, asking yourself what has happened with your inner child (minus the therapy…), or simply observing your own children, should help you open your mind to the changes to come.

Have you observed any other ways in which children excel at agile principles? Let me know in the comments section below.

Happy 20th Birthday to “Managing the Design Factory”

“Managing the Design Factory” by Donald G. Reinertsen was first published 20 years ago, and its tools, techniques and message are still relevant today.

In software delivery, Scrum and agile are not mandatory. I find it useful to remember this, since I often find myself in conversations with people who are interested in the successes and risk mitigations that Scrum enables. As a Scrum Master, understanding when and how Scrum can be successful helps me make responsible and informed recommendations. Yes, it’s true, I don’t always recommend Scrum, but I do always recommend that people learn more about it, try it and then decide for themselves.

So, I’d like to recommend a book to you, which was itself recommended to me by Mike Cohn when I attended his product owner training in London last year. If you have not read it, then I hope the following brief review will encourage you to do so.

First published in 1997, in the early days of Scrum and before the Manifesto for Agile Software Development was created, “Managing the Design Factory” takes a ground up, economic value-driven view of software development. It will be of interest to senior IT and business managers, product owners, Scrum Masters and anyone else with an interest in the history of software.

It contains no explicit references to agile or Scrum, but it does contain clear expositions of process design that can be seen in the Scrum Guide. I have found the beautifully concise Scrum Guide to be enriched by the detailed and soundly reasoned explanations in “Managing the Design Factory.”

Each chapter is clearly and methodically written, and simple but effective planning and estimation tools are provided. This allows the reader to systematically acquire the knowledge and techniques that will enable them to make the best decisions possible when designing the process best suited to their own particular business requirement for software.

Some of the key messages I have taken, and which we hold in our minds when we enact Scrum, are:

The purpose of the design process is to make money. In addition, we need to understand where in the process value is being added or taken away. This is manifested in Scrum’s product backlog, where there is constant review of value and priorities. Manufacturing process design and software development process design require different approaches. In fact, applying manufacturing quality standards to software not only removes the potential value of the software, it reduces software quality. It is worth remembering that there are still national and global enterprises whose software delivery processes are based on manufacturing process rules. In the software delivery process, where there is risk, there is also potential value. Development of small increments of software product release business value more quickly. As I am sure we all know, the delivery of regular, valuable software is a core agile principle.

“Managing the Design Factory” addresses manufacturing process design, firmware process design and software process design. This breadth provides excellent context for the reader to understand what is different about the design of the processes as well as the management of the people involved in software development. This knowledge will help managers decide if Scrum and agile could work for them.

For those of us who are already convinced of the benefits and value of Scrum, this book may help you understand why Scrum works and thus may also help you explain it to others – something I find myself doing almost daily.

Reading this book has made me a more informed, more confident and more effective Scrum Master. So, thank you, “Managing the Design Factory,” and Happy 20th Birthday!

Have you read “Managing the Design Factory,” or any of Donald G. Reinertsen’s other books? What did you think? Let me know in the comments section below.

Don’t Skip Your Recommended Daily Dose of Scrum

Can you remember what you ate a few days ago? How about a week or a month ago? We only tend to remember the extraordinarily delicious (or extraordinarily un-delicious) meals.

But all of them were important, even if we don’t remember them. How do we know that? Because if we hadn’t eaten any of them, we would not be alive right now. Similarly, missing a meal every now and then won’t do you terrible harm, but if you do it frequently enough, you will start to lose weight and become weaker.

In this way, daily scrums are like food: they play a vital role in keeping your team’s development process healthy. But, for some people, the daily scrum is an acquired taste. Sometimes it can feel burdensome, unnecessary or un-delicious, and you would rather skip it altogether. Resist the temptation.

Here are some objections you might hear from developers, product owners or even management regarding the daily Scrum. Perhaps you have even felt this way yourself.

“It’s boring. The code they are working on has nothing to do with me.”

The daily Scrum is a way to keep everyone informed about what everyone else is working on. This is important for cultivating a cross-functional team. Team members also learn how the code they are working on fits in with other code that someone else is working on, which is especially important if not everyone in the team is working on the same project.

And, even if they are working on entirely different applications, the types of issues different team members face can have common traits. If Alice hears that Bob, a junior team member, is wrestling with a memory leak that she knows how to fix, she can take that opportunity to coach Bob.

“Developers already talk to one another throughout the day. We don’t need a daily meeting for that.”

The spontaneous conversations that take place during the day tend to be operational in nature: Alice has a compiler error; Bob needs some information from Carol before he can define an interface; Dave can’t figure out why a file is missing and so on. They are focused on fixing immediate problems, whereas the daily Scrum is more of a tactical planning meeting.

It is not a problem-solving meeting, but rather a problem-surfacing meeting. You find out who is blocked and who can help, or who can find out who can help.

“This is a status meeting.”

Yes, developers share their status. But that’s like complaining that you must inhale in order to breathe. If the daily scrum consists solely of answering the three questions of what did I do/what will I do/what is holding me back and nothing else, then it is indeed just a status meeting.

But, just like you can’t breathe by only inhaling and never exhaling, your daily Scrum will not be effective if all of the communication is pointing away from the developer and there is none in return. As mentioned above, the daily Scrum is a problem-surfacing meeting, and problems can go unnoticed if no one comments or asks any follow-up questions. The Scrum Master might need to take the lead in digging a little deeper while the rest of the team develops the confidence or interest to do so themselves.

“It is ineffective or rude if you don’t let anyone except developers participate.”

Would you need people from outside the team to participate in a technical coding discussion? Would they even want to? The daily Scrum is a higher-level meeting than that, but only by a hair. If people can see it that way, they might be less inclined to insist on participating. And, with a 15-minute timebox, there isn’t much time for other people to participate effectively anyway.

Having daily Scrums is like maintaining a healthy eating regimen. You might not always want to do it, and some of the meals might be bland or occasionally downright yucky, but you can’t skip them. You might not see an immediate negative impact from doing so, and people might even be happy about it (yum, junk food!).

However, it can erode your team’s agility and cohesiveness over time. Similarly, positive effects may take time to manifest, but they will help your team bond and achieve an elevated level of performance.

Have you heard any other objections to the daily Scrum, from team members or otherwise? I'd love to read your experiences in the comments below.

Scrum Does Not Need Heroes

We all know one: the person who rushed in to save the day or rescue the project. We know the people who work late into the night to finish the presentation or fix a problem with the website. Or, perhaps we have been the “heroes” ourselves. I myself was one for a while. At least, until I understood.

It’s easy enough to see how the opportunity arises for a hero to rush in and save the day. Judging from the expectations some of my clients have had, Scrum is (supposedly) about filling up a sprint with stories and then having the team literally sprint to the finish. For various reasons, when this does not work out and the project is in peril, they cry out for a hero to save the day. Who will answer the call?

A Culture of Hero Worship

In fiction, the hero has a lot to live up to. It is as if fiction writers with a conventional concept of a hero know that their heroes ultimately cannot keep up with the idealistic image that people project on them. They do not grow beyond their own sacrifice, leading to many stories ending with the heroic act itself or the death of the hero.

Think of Frodo from the book series “Lord of the Rings” by J. R. R. Tolkien. After his long and heroic journey to destroy evil once and for all, he does not return happily to his life. Instead, the story ends, with a vague reference of him sailing away to an unnamed country to spend the rest of his life there.

While this can make for intriguing cinema, should we not be allowed to question this cultural concept of a hero when it comes to real life?

In reality, the real work only begins after the “heroic act” has been performed. We must ask ourselves, “How did things go so wrong in the first place? How can we prevent a similar disaster in the future?”

Standing in the Way

Put yourself into the shoes of the lead developer. You are the one who knows the ins and outs of the entire system. If you are working on the issue, it gets done twice as quickly. You are that good.

You fear how the team would perform if you were not available or on vacation, so you tell them you are always available and that they should call you whenever there is a problem, no matter the time. Essentially, you think they are not ready for the world.

But, after a while, it slowly dawns you that your team cannot meet the challenges because you never actually let them try to do so. You are the reason they are standing still.

Men have to have heroes, but no man can ever be as big as the need, and so a legend grows around a grain of truth, like a pearl.

-Peter S. Beagle, “The Last Unicorn”

As a manager, you need to understand why it is crucial not to cry out for a hero. The heroic act does not change the person doing it, and the accolade of those around him or her will eventually end. After the situation has been resolved, the hero usually returns back to ordinary work---disenchanted, since he or she cannot keep working at the same pace on his or her own outside the team.

What these heroes are left with is either pride--which can turn on its head by causing them to become more defensive, less transparent and less of a part of the team--or a sense of abandonment, if they feel their contribution is no longer valued when it’s not urgent.

If you praise heroes by their sacrifice in the face of emergencies, you no longer differentiate tasks by their value, but by their praiseworthiness and visibility. Important but less visible half-finished tasks will be dragged along through several sprints until they cause a fire---with the hero again coming to the rescue, and the vicious cycle repeating itself.

Aim for 100% Completion, Not 100% Exhaustion Rather than demanding heroism and sacrifice by adding more stories to a sprint than the team has pulled from the backlog (or would have, if you had let them!), I recommend setting a goal of sustainability. This helps the team to become more confident in their abilities by removing the need for the “hero” of the team. It might even make the “hero” more productive by having her abilities focused not on putting out fires, but on his or her own strengths. Instead of looking at the hero as a self-sacrificial super-human, I recommend learning to get comfortable with the real hero as someone who can break conventions and who speaks openly instead of purposefully running the project into the ground just to prove a point.

There is no need, in a productive team, for one person to carry the weight of the world on his or her shoulders. We do not have to feel responsible for everything that is happening, only to then complain that we cannot manage it on our own. If the actual result is more important to us than social recognition, we have a simpler option to improve the world without having to sacrifice ourselves: We can focus on our strengths and help others in the team to reach their full potential.

Are Scrum Masters the True Heroes?

Even if you do not have a hero in your team, management might think you do, or that you should. Some clients even see Scrum Masters as a type of “team motivator” whose main task is to whoop the team into shape and reach new levels of productivity. If you do have a “hero” on your team, you might be better off either moving the person into a technical support role outside the Scrum team, or developing that person into a Scrum Master.

But, keep in mind that even the Scrum Master does not fit the image of a traditional hero. His or her main task is to oppose false heroes or paradigms within the company. Sure, the responsibilities of a Scrum Master also include identifying, analyzing and removing impediments, but that does not mean that the Scrum Master takes over tasks the rest of the team could just as easily work on themselves.


The traditional image of heroism does not fit into the Scrum team. A Scrum Master needs to be aware both of a culture of hero worship within a company and individual team members who are engaging in self-sacrificial behavior at the cost of long-term sustainability. 

The real heroes are the ones who break conventions and stand up against false heroes. They will be the ones who contribute to the success of your project and your team.

How do your team members share work among themselves? Do you have specialists, like a “super-programmer”? Have you seen evidence of hero worship in your company’s culture? Please let me know in the comments section below.  

Culture Wars: The Battle for Hearts and Minds

Recently, VersionOne released their 11th annual State of Agile report detailing the current state of agile across multiple organizations spanning the globe. 

In the report, VersionOne listed the top challenges respondents reported having experienced in adopting and scaling agile. Their number one response (with 63 percent of respondents citing it as an issue) was that company philosophy or culture was at odds with core agile values.

This issue jumped out to me as getting to the heart of the problem that many who adopt agile experience: the great culture war, or the battle for the hearts and minds of your organization. When adopting agile, we must recognize that extensive knowledge of the framework is not enough and that changing the culture of a company is the more necessary and arduous task.

Why are so many seeing this as a challenge to their agile adoptions? What is it about company philosophies or cultures that conflict with core agile values? More importantly, what could we do better as an agile community to address this issue and provide solutions to this widespread concern? 

Agile values are best represented by the four main statements put forward in the Agile Manifesto. These statements are not buried deep within the training material and should be well known by any company looking to implement an agile transformation.

In fact, I would imagine that if there is one thing executives or other sponsors for an agile transformation certainly know about agile before they pull the trigger on an adoption, it is the Agile Manifesto. Why, then, do we find our companies at odds with the most fundamental concepts associated with agile?

What I have heard multiple times from various organizations is that there exists a very real disconnect within their companies between some layer of the management structure and the teams who are implementing agile.

In other words, parts of the organization are implementing agile while other parts continue to use waterfall methodologies. The team level will practice iterative, incremental development while reporting up to layers of management that still operate on what David Hawks calls “a requirements delivery model rather than a requirements discovery one.” 

What this creates is a mushy translation layer within organizations where some poor souls are asked to translate agile concepts into traditional waterfall-speak. That group is given the impossible task of translating iterations and story points into a Gantt chart with hard deadlines for delivery. They are asked to take overly complicated requirements documents and translate them into user stories. 

These are insurmountable challenges which will only produce frustration in both those trying to translate and those expecting the translation. There is no Rosetta Stone to accomplish this translation because the concepts simply don’t translate. Any translation that a company might settle on must compromise on one side or the other, and it is usually the agile side that takes the hit.

If an organization wants to change its culture and realize the full benefits of an agile transformation, a more holistic approach is needed. Both management and team layers need to understand not only the “how” but the “why” behind each change that is being made.  

Two suggestions for organizations that are seeking a more holistic approach:

Consider arranging training not only for your teams but also for your directors, vice president and C-level leaders as well. Within the past few years, The Scrum Alliance has created the Certified Agile Leader (CAL) certification course that many of those in management and leadership positions would be wise to consider investing in. This course will help organizational leaders understand what to expect and learn how they can encourage and fan the flames of their organization’s agile transformation. Consider “seeding” your transformation by contracting outside coaching to help teach not just one-time concepts but overall culture on a day-to-day basis.

Now, you might be thinking to yourself, “Of course you would say that! You’re an agile coach and consultant!” And you’d be partially correct. One of the main reasons I decided to do what I do is because I wanted to focus on an area where I felt I could make the greatest impact. However, there are many great coaches and consultants out there and most of them would tell you the same things. 

Culture isn’t something you can transfer in a one- or two-day course. Culture takes time and is learned through osmosis and by example. When a team member suggests that a sprint be extended so that the team can finish all the work, a coach is needed to explain not only that Scrum is timeboxed by rule but also that we do this to establish a definitive point that we can review the work to see what adjustments we need to make to move forward.

This leads a team to think of the steps of the process as more of what they were intended to be – a framework. When that shift occurs, a team begins absorbing the cultural concept rather than simply parroting back answers from a book. That leap, in both organizational leaders and in teams, is what will transform the culture of an organization and it is the best way to combat any disconnect between a company’s culture and core agile values. 

Hearts and minds will always be more difficult to change than procedures and processes. However, in order to change the culture of an organization, that is exactly the target we should be attempting to hit. Our job as agile leaders is to draw this clear distinction and point our teams in the right direction. Only then can we begin to address the number one issue organizations face in their path towards a successful agile transformation.

What do you think is the hardest part about transitioning to agile? Are there any culture clashes you’ve observed in your own organization? Let me know in the comments section below.


Myths and Misconceptions About Trust

When I was a teenager, I was bitten by a German Shephard out of the blue, or so it seemed to me at the time. I never trusted that dog again, mostly because we never met again. I'm sure that if we had, we might have become friends and I would have become much better at reading him. The incident certainly hasn't stopped me from loving dogs.

The romantic in me would like to say that this incident is what sparked my interest in trust. It didn't, but it's a nice story, and it illustrates a couple myths and misconceptions about trust.

Myth: Trust Is All or Nothing

For a long time, I believed that if I trusted someone not to bash my head in, it meant that I completely trusted them. You either trust someone or you don't, right?

Not exactly.

I like to drive convertibles at high speeds up and down mountain roads. Roads like the one in the above picture. When that picture was taken, I was not at the wheel. Does that take trust? You bet. Would I trust the driver with anything? No way.

Would you trust the driver of a getaway car with your wallet? Can you trust a very competent rally driver to look out for you in difficult personal circumstances? Can you trust a co-worker that would drive you up or down this mountain safely not to go behind your back to reap the fruits of your labor?

Trusting someone for one thing does not necessarily mean that you trust them for everything. It's quite possible to trust a co-worker not to gossip about you, yet have no trust for them at all about the way they handle their own or your mistakes.

Myth: Trust Is a Matter of Life and Death

It certainly can be, and in many professions it is, whether between teammates or between the person performing a service and the person undergoing it. However, most of us don't work in the fire department or have medical jobs. Most us have office jobs, where life and death situations are few and far between.

In those circumstances, trust revolves more around emotional safety. Can you make a promise because you can trust someone to deliver so you won't have to face another's wrath? Can you trust someone not to judge you? Can you trust someone to walk their talk?

Myth: Trust Is About Competence

According to some, competence inspires trust. While I don't disagree, I don't entirely agree, either. Competence, or being good at something, is more about inspiring confidence. Specifically, confidence that someone is the right person to get a job done. On the other hand, trust is more about being able to rely on them using that ability to do the job right and get the best result possible.

Take the co-pilot of Germanwings flight 9525, trained to the T and perfectly competent to fly an aircraft to its destination. His ability also made him perfectly competent to fly it into the ground. Which, unfortunately, is exactly what he did on 24 March 2015. Despite his competence, he should not have been trusted to fly on that fateful day.

This next example hits a bit closer to home for me. The people I wouldn't want behind the wheel on that mountain road fall into two categories. One group simply lacks the ability to safely get me to the top and down again. I have zero confidence in their competence.

Another group consists of the people that can complete the trip safely, but I am uncertain if they will. Not because they may have a death-wish like the German co-pilot, but maybe because they tend to drink a little too much in the evenings, or because they are easily distracted and tend not to be focused on the job at hand.

Myth: Trust Arrives on Foot and Leaves on Horseback

Google “trust quotes” and this comes up a lot. It's a widespread belief.

However, trust isn't slow to arrive. Yes, some people will not trust anyone unless and until they have "proven" their trustworthiness. Most people, however, function the other way around. They will trust until they are proven wrong.

Further, being proven wrong once isn't enough to warrant a complete lack of trust. Yes, it will make you more cautious, but your trust for them doesn't simply fly out the window. People are quite capable of distinguishing between intention and effect, and are generally willing to give someone the benefit of the doubt.

Even when proven wrong a couple of times, that doesn't mean that all trust is gone, because trust is not all or nothing. Oh sure, after banging your head against the wall several times, you will not trust X to deliver on time anymore, but you can still rely on X to deliver high-quality work. And what if X were to deliver quality goods on time several times in a row?

Regardless of the initial level of trust for others that you operate from, that level of trust is in constant flux. Brené Brown uses a marble jar analogy to illustrate this.

Your marble jar for Peter starts with an initial number of marbles in it. Every action by Peter either adds a marble or takes one away. For example, Peter remembering your mother's name, inquiring about your recent exam, delivering quality work on time or being discrete about something you told him in confidence will add marbles. On the other hand, delivering something late or of inferior quality, being harsh to you or someone else or always saying yes but doing no will remove marbles from his jar.

So, where does the popular belief that trust leaves on horseback come from?

I have no idea. My guess is that we are often unaware of the effects of other people's words and actions on our level of trust for them, perhaps because questioning your trust for someone feels like a betrayal in itself. When you've finally had enough of someone's failures to act trustworthy, it feels like emptying the jar in one fell swoop, when in reality it has been running on fumes for some time already.

Myth: Trust Happens Automagically

Everything I've read about agile and high-performance teams stresses the importance of trust. Trust between team members, trust between teams and trust between teams and their stakeholders. And yet, none of the agile frameworks or methodologies I’ve seen go any further than that. We are all apparently expected to "get" it and get on with it. "Trust is important. Now go forth and trust each other."

Coaches and facilitators do get a bit more training and can find a lot more resources on trust building exercises. Unfortunately, most trust building exercises I have had the pleasure of reading or being subjected to are not about building trust. They are about building a connection. Connectedness is a lubricant that makes trust easier: you are far more likely to trust someone with whom you have broken bread, played or exchanged personal information. But a connection is not trust itself.

What everybody also seems to forget is that trust or team building exercises and activities can just as easily destroy trust when the person you previously thought was pretty nice turns out to be an utterly unreliable partner in the exercise.

What's more, just like training a dog doesn't just happen during obedience classes, trust doesn't just grow or erode during exercises and events intended to build it. Trust levels wax and wane with every observed word and action. If you want trust levels to improve, you will have to work at it all the time. This doesn't mean you can't slip up, just that when you do, you have to acknowledge it and make amends.

Myth: Trust Must Be Earned

This myth is one of my pet peeves. I am firmly in the "trust until proven wrong" camp, even though it may sometimes be with a lot of trepidation.

That doesn't mean I trust everyone for anything in every situation. For example, I am very much in favor of assessments and tests during the hiring process. I could say that is because of cognitive biases that make people believe they are better than they actually are. While that plays a part, the true reason is that hiring is a process with a lot of conflicting interests, and assessments may add some much-needed objectivity.

But, don't put people through a wringer just to gauge their trustworthiness as a human being. Doing so is a clear signal of distrust that is clearly heard by the person on the receiving end. Distrust begets distrust. They may tolerate it if it's the way to gain a prize they want, but, if anything, it will lower their trust (and respect) for their "testers."

Hearing an agile coach utter this myth really got me on my high horse.

Besides, it is futile. If you are not willing to trust me, there is nothing I can do or that I can give you that will make you trust me. Because, as we’re about to discuss, trust can't be built.

Myth: Trust Can Be Built

Now there's a bummer. Bet you didn't expect that one, especially with all the trust building exercises, ice breakers, team building activities and what have you that all intend to build trust levels in teams.

Unfortunately, it is true. There is nothing I or anyone else can do to make you trust us.

It's not like I can stack packets of trust on you and that will increase your trust for me. All anyone can do is speak and act in ways that will facilitate your trust for them to grow. However, whether it has the desired effect or not depends entirely on whether you allow it and are willing to trust.

Trust can't be built or earned, it is given and it grows.

So, are all those exercises, ice breakers and games in vain?

Absolutely not.

They are essential for trust to have a chance. They create conditions and get people to interact in ways that are conducive for trust to grow. You need to take people out of their "normal" work -- the transactions of day to day business -- and put them in situations where they can interact as people.

Interacting as human beings, with as little interference from formal hierarchies as possible, is what makes people more comfortable with each other and what will allow them to interact more easily and with less trepidation in their "transactional" work. It allows trust to grow and to be given.

Myth: Trust Is Optional for the Bottom Line

Just like "leaving your emotions at the door" is wishful thinking, hoping that you can make do without trust is daydreaming at best. Sure, companies where distrust reigns supreme can be successful and make a profit. I just wonder how much more profitable they could be if they worked on increasing trust and happiness levels. Read Patrick Lencioni's "The Five Dysfunctions of a Team" to see where an organization can leak money left, right and center when trust issues run rampant.

And, if you want the people in your company to innovate, to be creative and to be open to change, then you need them to be willing to make themselves vulnerable to the words and actions of their co-workers. That takes trust. Loads and loads of trust.

So, What Is Trust?

Trust is multi-faceted.

Trust is feeling emotionally safe.

Trust is knowing that someone will use their abilities appropriately.

Trust is resilient.

Trust is a two-way street.

Trust is essential for smooth collaboration so innovation, creativity and change can flourish.

Trust is in constant flux, it waxes and wanes with every interaction.

Trust is a verb. It needs to be worked on and you need to be aware of the effect of words and actions on trust levels.

Trust is not built or earned. It grows and is given.

If you have any additional thoughts on trust that I haven’t addressed here, please share them in the comments section below.

How to Implement COTS in an Agile Fashion

Most organizations do not develop 100 percent of the software that they use, nor should they.

A vast majority of the jobs they have to do can be satisfied with readily available Commercial Off the Shelf (COTS) software, or its more modern successor, Software as a Service (SaaS).

Why go through the pain of building something to address the same need that thousands of others have and that many developers have put in the effort to figure out already?

Yet, the organizations that primarily use software developed by someone else are the same ones that are now trying to become more agile, at least in their IT departments. Those folks look at the various frameworks for agile software development (primarily Scrum and SAFe) and say: “That’s great that you’re building software, but what if you primarily purchase and implement it instead?”

Here are some ways I’ve found to implement COTS and SaaS in an agile fashion.

The Goal Is to Get a Job Done, Not To “Be Agile”

I thought I’d get this one out of the way early on.

Being agile should not be your ultimate goal. Rather, your ultimate goal should be to deliver the right outcomes, which you can think of as satisfying your customer’s needs. Agile values provide a great mindset to have in place to accomplish this, but they are simply a means to an end.

Agile frameworks (such as Scrum) provide a starting point for your team to figure out how you’re going to approach work in a way that embodies the agile values and principles which will most likely increase your effectiveness in delivering the right outcome.

In the case of COTS and SaaS, you have a job that you want to get done that is similar to a job that many organizations have, and there are existing products that will help you get that job done more effectively than building something yourself.

Instead of asking how you can implement a COTS software in sprints, ask how you can implement this package in a way that delivers the most value for your organization and allows you to address the uncertainties you run into along the way.

Fall in Love With the Problem, Not the Solution

All too often, organizations implement COTS or SaaS products because someone with a great deal of influence or authority came across a “must-have tool” and began hunting for a reason to introduce it to the organization.

A better way to approach this is the from the opposite direction: start with the problem in mind and describe that problem in the terms of what value it has for the organization. I find that collaborating with impacted stakeholders to create a problem statement can help you build a shared understanding of the problem.

When you understand the issue at hand and want to identify possible solutions (some of which may not actually require software), you may find a technique such as Impact Mapping helpful.

Once you’ve identified desirable characteristics of your solution (hint: do not just look at the feature list of someone’s pet product and crib off of that), describe those characteristics in the form of user stories or job stories so that you can focus on the problems you are trying to solve. 

Pick the Right Solution

Now that you understand the problem and know what you’d like in a solution, you can decide whether it makes more sense to build or to buy. Using purpose based alignment can help you determine the right path. If your solution will differentiate you in your market, it probably needs to be unique, so building the solution is most likely the better choice.

If the solution is parity for your market, you may find that you can buy an existing solution.  Should you go this route, resist the urge to customize whatever it is that you buy. That is a sure way to blow your budget and timeline and probably fail at achieving your desired outcome. 

Instead, find the solution that is the most closely aligned with your desired characteristics, and revise processes or expectations in the small cases where you don’t have alignment. This is a parity activity. There is no value for you to do it more uniquely than anyone else.

Iterate and Increment to Learn

When most people think of applying agile to COTS or SaaS, they are trying to figure out how to fit the work of implementing the solution into sprints. There is certainly validity into figuring that out, but it’s essential to understand why.

You don’t iterate and increment for the sake of doing things in sprints. Rather, you iterate and increment in order to learn.

Most COTS and SaaS solutions require some amount of configuration, integration with existing systems and the transformation and loading of data from a current system. These activities provide great opportunities for an iterative and incremental approach. The two primary ways you can approach it are:

Gradually roll out functionality. Start using the new solution for limited purposes. Perform the configuration and integration to support just that functionality, deploy it and observe the results. Determine what you can learn from that rollout to apply to, configure and deploy subsequent functionality. Gradually roll out to new users. Have a small subset of the total planned user base start using the solution and closely watch the challenges they run into and the feedback they have. Use that feedback to alter your configuration and approach to roll out to the next set of users. When you pick you first users, make sure you select people who are comfortable with change and adept at using products so that they can provide meaningful feedback.

You may find that in some situations you can combine both approaches, especially when different groups of users use different functionality. The key to picking the right approach for you is to select the one that will allow you to learn the most with the least amount of impact to ongoing operations as you make your transition.

And, if you must transition data or content from your existing solution to a new solution, do not wait until the last minute to transition that data over. Determine how you can transition it as soon as possible. If the data changes rapidly, you may have to wait until just before go-live time to transition that data over. If it rarely changes, move it over immediately so you can test your new solution in as realistic a setting as possible.

Agile COTS/SaaS Is About Value and Learning

When you implement a COTS or SaaS solution, figure out the problem you’re trying to solve, have a clear understanding of how the solution will help you solve that problem and implement it in a way that will help you learn along the way. Doing so will help you deliver the right outcome to your organization.

What experiences have you had implementing COTS and SaaS solutions? Did I miss anything? Share your thoughts in the comments section below.

Creating Your Agile Business Analyst Role

This is the first in a three-part series of blog posts addressing the biggest challenges faced by business analysts on agile teams.

As a business analysis consultant, trainer and coach, there is a single question that wins the prize for being most commonly asked:

“What is my role as a business analyst on an agile team?”

And I universally have bad news for them, and perhaps for you, dear reader.

There is no business analyst (BA) role on agile teams.

At least, not straight out of the box. Let’s look at the basic role-set in agile.

Roles in Agile

An agile environment consists, at minimum, of two participants: the customer and the developer. The customer has the need, and the developer has the means to fulfill it. It’s a match made in heaven.

But, since development is a lot of work, it usually takes a team of developers to build the product that the customer wants.

This is because most development teams have many times more customers than developers. Since each of these customers has diverse needs, characteristics and preferences, we end up needing a person (the product owner, or PO) to understand and coalesce this aggregate demand into a single product that the team can build. Cool.

And, since development teams will run into plenty of problems, many teams hire someone (the Scrum Master) to overcome obstacles, make sure that everyone knows what’s going on and interface with management.

So, let’s recap: customers, developers, product owners and Scrum Masters. While the last two are Scrum terms, even non-Scrum teams will have something similar.

And here we have the basic agile team, although it is sometimes expanded to include non-development roles as needed by our enterprises, such as testers, architects and even business analysts.

The Problem for Business Analysts

The problem is that, in agile, we business analysts are not responsible for our usual bread and butter, requirements. Instead, the implicit requirements of the customers are managed by the product owner, who is also responsible for creating written requirements, in the form of user stories, and conveying the understanding of the requirements to the development team.

This leaves business analysts to flounder. We end up helping the PO, development team and testers, but we have no direct responsibilities of our own.

This problem, as we’ve seen, is baked into the fundamentals of agile development in at least two ways.

First, the product owner role absorbs all responsibility for the business analysis work typically performed by BAs. However, this is not a business analysis role. Historically, product owners have come out of the product management function, and they have only performed analysis incidental to their positions. Product management professionals are focused on:

Developing products that appeal to customers  Monetizing that appeal. Certainly, business analysis will play a role in achieving these goals, but it takes a backseat.

Second, and more fundamentally, agile deprivileges team roles in general. In calling the team the “development team,” I’ve been fudging. It’s really a cross-functional team of professionals working together to build the product. The team includes developers, certainly, but also any other miscellaneous professionals needed to most effectively deliver a high-quality product.

Given the ad hoc nature of the situations that business analysts find themselves in, combined with the fact that we’re not completing backlog items ourselves, we find ourselves craving some understanding of our role on the team. Are we helping the PO to better understand his or her customer base? Are we floating from desk to desk helping the developers understand what needs to be built? What exactly are we supposed to be doing?

The Solution is Not to Find Your Role

The solution is not to try to figure out what our role is, but rather to create a role customized to the needs of our team, product owner and customers.

In working with numerous coaching clients, I’ve found a straightforward three-step process to most effectively help create a Business Analyst role that will make the biggest impact.

Step 1: Understand the (probably significant) Conflict Between the Values of Your Company and the Values of Agile

You probably didn't see this one coming. The fact is, no company is perfectly agile, not even the ones run by the people who invented agile. Every company has a culture, and every company is comprised of individuals with competing personal values, goals, beliefs, perspectives and egos, and these can all get in the way of collaboration.

The first step is to realistically and non-judgmentally understand what your company’s culture is. Until you understand that your company is not a perfect agile wonderland, you won't be in a position to design your role.

Step 2: Determine What Your Company Needs of You

Establish what not just your company, but also your team, your management, your product owner, your stakeholders and your customers need of you. Sure, what you yourself want to do is important, but it won't be sustainable or effective if you're not also meeting the needs of everyone else. We Business Analysts fortunately tend to be good at figuring out what our stakeholders need, but it's often harder to turn our analytical eye inwards.

Step 3: Design and Implement Your Role

For people like us, this is the fun part. In this step, you'll essentially put the techniques we use to create products to use in creating your role. No, you are not a product yourself; you're a human being. But there is a lot to learn (and leverage) by going through the same process.

By determining what specific features, values and benefits your role will possess, validating that role within your company, and implementing that role with an eye to regular fine-tuning and improvement, the BA role problem can be successfully overcome.

How about you? What role problems have you been facing either as a BA yourself or as someone working with them? Feel free to share your thoughts and experiences in the comments section below.