Payback Period

Payback period is pretty much what is sounds like—it answers the question of how fast the organization will get back the money spent on the project and begin generating a profit. Certainly, the faster the payback period, the better off the organization will be.

Think about it this way, if you lent your best friend money, would you rather they pay you back sooner or later? If you say later, you are a very good friend! Most of us would want that transaction to go as quickly as possible before things get awkward. Organizations are no different, and there is a reason for that. First, profit is generated faster if the payback period is shorter and, second, because today’s money will more than likely not be worth the same tomorrow. The longer it takes to recoup initial investments, the less the return on the investment.

Payback period is always represented in time, and if you have a choice, you would charter a project that pays you back the fastest. Unfortunately, that isn’t the only variable to consider. Organizations still have that pesky problem of determining the allocation of funds across your project and others in the organization, plus spending money means it isn’t being invested in expansion, new equipment, and other projects. Here is where the crystal ball comes into play. You can forecast out when you will be paid back, but it is also necessary to look at the market and see what it is going on at this point in time in order to determine an accurate and effective forecast. That is where things like internal rate of return (IRR) and net present value (NPV) come into play.

Internal Rate of Return

If you were given a choice of whether to invest your money with an annual return percentage of 3.5 percent versus a 10.5 percent, which one would you choose? Those of you who play the market might say things like “it depends on the market, I could lose more with risky investments,” or “I like to play the long game and invest wisely.” That makes sense. What if the market or any other external factors weren’t there? Would that change your answer? Probably! You would most likely choose the highest percentage of return and get the biggest bang for your invested buck. That’s a very simple example of the concept of internal rate of return (IRR): internal (meaning no external influences), rate (what percentage), and return (ROI).

If I’m an organization, I’m going to compare my proposed investment in a project to my projected rate of return and determine if it is the right way to go. Just as you would choose the highest return if no external risk were present, an organization will choose the highest return as well—especially if they are trying to decide between chartering similar projects. The highest return wins.

There is a lot more that goes into all of this, of course (remember big scary formulas and business analysts with crystal balls), but the bottom line is that the higher the IRR the better, and this will be a contributing factor in financial decisions. Once the payback period and the IRR are determined, it’s time to take a look at the time value of money.

Net Present Value

What is today’s money worth tomorrow? My grandmother used to be very specific in her disgust at rising prices for things like movies and travel. In fact, I’m pretty sure that I heard this on a regular basis: “When I was your age, movies cost a nickel and we took a train rather than hurtling through the sky in a tin can to the tune of a year’s salary.” The point is that yesterday’s money isn’t worth the same today. There is inflation and an ever-present market that is constantly unpredictable.

What are big organizations to do? They run big scary formulas that let them know as of right now—today—the present value of net return. Therefore, payback period and internal rate of return are important inputs because they will help drive the resulting net present value (NPV).

All organizations have incoming cash flow and outgoing cash flow, and both hold their own values. Outgoing cash flow is a negative value, and incoming is a positive value. If the organization compares the value of an outgoing cash flow to a project (including what they spent initially) and the incoming cash flow over the payback period, they can start to see the benefits versus the costs. If you spend a million dollars one month and only receive $500,000 back over the course of the next six months and have to wait another six months for the other $500,000, it won’t be worth as much. Your million-dollar investment is now worth less.

Granted that financial worth rarely fluctuates that quickly with those numbers, but you catch my drift. As an organization, I would want the highest NPV possible to drive my decision to charter a project. If a company is forecasting that they will break even on the venture, they may determine that it isn’t fiscally healthy to charter that project. Although, I’ve seen organizations charter a break-even project based on an opportunity that may provide more ROI somewhere down the road, or one that has a chance of landing a big customer, or even one for future growth. Some organizations and industries are considered risk takers, and in technology a lot of projects are cutting edge and risky. Sometimes, however, the opportunity is worth the risk.

Most of you would probably agree that if you knew in advance that you were going to lose money on something, you probably wouldn’t do it. Organizations and the market are sometimes favorable in the odds, and so, like playing craps in a casino, an organization will roll the dice and cross their fingers. You see this a lot in the movies, which now cost an arm and a leg to make and frankly to take your family to these days. This is due to the massive amounts of expense invested in the project and the need to make it back quickly. Think of those huge budget movies with high-paid talent and crazy special effects that tank in the theaters. A studio may have taken a quarter of a billion-dollar gamble and only made $30 million back. Ouch! Why would an organization take on a loser project like that? Because they don’t expect to lose.

Most organizations wouldn’t ever consider taking on a loser project if they knew in advance that it would provide zero profit and run way over budget. The problem is that projections can be optimistic, and sometimes the crystal ball is cloudy and not reliable.

There are only a few reasons an organization would take on a financial loser. First, because they flat out have to. Regulation or compliance demands it, and money that will never be seen again must be spent to be compliant. Nonetheless, because they spent the money, the organization continues on its merry way as compliant. Second, organizations may do this because they hope the market will reset or adapt before they lose money in profits. Usually, you see a lot of this before elections. It’s still a gamble, though and any financial advisor with whom you speak will tell you the same: It’s a risk. So how much are you willing to risk? This is where you leave it to the business analysts to determine that amount.

As Agile project managers, you will wait until you get the green light to begin, and then you will go forward with the stakeholder interactions and determine aspects of the project scope. That is where you begin to determine who, what, where, why, and how.

Elevator Statements

If you were riding on an elevator with someone, could you in a short ride explain what it is that your customer wants from a finished product? This sounds easier said than done. The process of compartmentalizing and being concise is a profound way to express the needs of the project and describe what a successful result would look like.

Elevator statements provide a tangible vision of what the work will produce and what the ultimate goal is as the result. I find it is best to articulate a vision statement or elevator statement in the present tense instead of some far-off increment to be developed in the future. Many times, the terms vision statement and elevator statement are used interchangeably, but the product owner is the one who needs to make sure that the ROI is met. Thus, the product owner will often ask for the vision and/or elevator statement to determine the end goal(s). Provided the product owner and the team understand the direction in which they are headed, how they get to that point is less stringently enforced in many frameworks. Whatever term or process is used, the goal is to keep the team focused on the here and now. This allows for conversations and better direction toward the jumping-off point prior to the iteration beginning.

One thing that you’ll notice about Agile frameworks like Scrum, XP, DSDM, FDD, and others is the concept of transparent communication. In a Waterfall mentality, the team is very dependent on the project manager in the very beginning to set the requirements and describe what the project will entail. In Agile projects, the team and product owner are working with the customer to determine the potential results while trying to fully understand them as they are discussed. Even though the product owner/customer will determine what is valuable to them as the iterations progress, it is the team who needs to describe and understand the vision in the beginning. This will be done with input from stakeholders and customers and from discussions, of course, but ultimately if someone asked you to describe your current project in an elevator, you would have to understand it first yourself.

I think it’s safe to say that everyone starting the elevator statement with the customer and ending with the team is a good sandwich approach. It allows us to focus on both sides of the project equation and provides the team with the ability to buy in to their role in the result. This gives the team a good idea of who they are dealing with and why they are the best people to take it on. This builds the beginnings of motivation, better team dynamics, and the ability to reach consensus right out of the gate, or right out of the elevator as it were. The format for the elevator statement is graphically represented in Figure 4.1.

Tweeting

#tweetinghelpspromoteunderstanding

Tweeting takes the elevator statement and trims it way down to about 140 characters or less. This is a very difficult thing to do, and if you hang out on Twitter you know sometimes it takes a few tweets to get your point across. The good thing about Twitter or other social media is that people are used to tweeting now and, therefore, it isn’t outside of the realm of possibility to tweet an overview of your product.

I find it is very helpful when the customer does this for the team. It causes the customer to really think about what the most important aspects of the result are and really narrow it down to its most concise description.

Remember, I use the term customer loosely and as a blanket statement for both internal and external customers. This may represent an internal customer in XP or a product owner in Scrum or an actual customer. To keep things generic across best practices, it’s important to separate from specific frameworks and methodologies.

I know what you are thinking—I mean how could you possibly collect requirements this way? I totally understand! Let me put it to you a bit differently. Have you ever had a laundry list of requirements thrown at you by a customer who seems not even to be sure what it is that they want? If you have, you know that it can be a bit frustrating.

This exercise is for the customer to dig deep and find the most important things and describe the result they are seeking in 140 characters or less. The best part about this exercise is that it forces both the customer and other stakeholders to be very concise in their descriptions, and they really have to think about it in order to do this effectively.

One thing to consider while you are reading this is that you will eventually fill out your application for the PMI-ACP exam. Part of the application piece is describing your project work in about 1,000 characters or less. It takes time to put it all together in a concise manner, but you are describing your project and Agile experience in a very long tweet so that the Project Management Institute (PMI) understands your experience and can validate that your experience aligns with their requirements.

There are a variety of ways to collect requirements, and occasionally I like to revert to my Waterfall experience to design best practices that will work in an Agile environment. This is called project tailoring, and that ability is on deck to be the next important thing in project management best practices, especially with the updates to A Guide to the Project Management Body of Knowledge (PMBOK^® Guide), Sixth Edition, which focus on tailoring best practices for the benefit of your project, not for your process framework.

I see the value in a lot of best practices in both arenas, one of which is a Waterfall practice of surveys and checklists. I like to use surveys with customers as well as specific interview questions and checklists when explaining process or framework implementation. These are excellent ways to keep me organized personally and not digress into a rabbit hole topic (as you may have noticed I tend to do). At the same time, it keeps the focus on the matter at hand by collecting the right information in real time.

Surveys are helpful when trying to get to the bottom of what the result could be and what the customer sees as a successful completion. These questions can reflect anything from what they see as a successful completion to what the end user is looking for in the increment that you are building. I don’t have a set list of survey questions because each project is unique, but I do have some go-to questions I always ask. I use them as a way to keep the focus on the same issues and information and to reduce my tangent potential.

Prototyping is also an effective way to determine what success looks like. Prototyping usually brings up thoughts of creating an entire result, showing it, and then mass-producing it—like in the old days of automobile mass production. A prototype of a new model of a car would be created, shown, and then mass-produced.

This is simply not fiscally responsible anymore. Not to say that organizations don’t create prototypes—they certainly do, and for some engineering organizations it is worth it to build something correctly once before mass-producing it. In technology, however, we are more focused on finding out what the build should be rather than telling the customer here it is—just what you want! Now that is prototyping type casting! These days, due to 3D printers and computer-developed models, as well as low-tech ways to work through to the solution, it’s easier in an Iteration Zero or through pre-project engagement to collect the right requirements, or at least to begin to do so. Obviously, whether you prototype or not is dependent on the types of products or services that you create.

Wireframes

Wireframes are a super easy and cool way to work with stakeholders to define their needs and to help create a mock-up of what will be built before you get into the business of building. I use movies and television shows when I explain wireframes to my customers. I give them an idea of how each scene in the movie is plotted out in advance on paper and, in many cases, is hand-drawn. It is a visual representation of the scene before it is shot. I’m sure that when you look at big blockbuster movie budgets, you can imagine how important it is to plot out the scene in advance. Having a script is great, but that is mostly for the actors to see their lines and when they enter and leave a scene. The storyboards are there for the director so that they can see what they will create on film and use that to plot out the visuals and stunts and to correlate with the actor’s lines. If you consider yourselves the director of the project, then it’s important to see what it is that you are about to create.

A lot of tools used in Agile are surprisingly low tech, and wireframes are considered low-fidelity prototypes or mock-ups of the scene. This allows for a better definition of done because it’s visual, it doesn’t cost anything except for time, and you can work with stakeholders to show what it might look like when it’s finished. Just as in the movies, scenes may be cut or re-created until they are just right.

In Figure 4.2, you’ll see a very basic wireframe. The question you have to ask yourselves is do you understand it? Do you get the gist of how you would mock up the app? At this point, you wouldn’t have all of the information, and the wireframe can be used as a tool to see what the customer wants. If there is open real estate, you can ask what the customer wants in that space and begin building out the vision.

I find that not being able to draw very well, by making it a bit messy I allow the customer to feel more empowered to grab a pen and show me what they want. Or, they think I draw like a two-year-old. Either way, it gets the conversation flowing. There are several wireframe apps out there now to help, and you can always revert to PowerPoint as needed as a quick and easy way to draw or mock up a wireframe. It’s also much less formal than a kick-off meeting. Wireframes are a way to show what you are thinking visually you are going to build. If not, then certainly crumple it up and throw it away. I call it the Pictionary of Agile.

The description is the tweet, and the wireframe is the picture of the tweet. Now we are getting somewhere!

User Stories

User stories were originally created in the XP framework as a way to determine the definition of done and are now used in just about every single Agile framework.

Not only are user stories an effective way to determine what done looks like, but they are also used to determine how much work could be accomplished in any given sprint or iteration. You’ll see in Domain V : Adaptive Planning how you can estimate amounts of work by utilizing user stories. In this chapter, you’ll see them as a way to engage stakeholders, and as task 6 on the exam content outline for this domain clearly states, “You will need to establish a shared vision of the various project increments (products, deliverables, releases, iterations) by developing a high-level vision and supporting objectives in order to align stakeholders’ expectations and build trust.” User stories help you accomplish that.

Most user stories follow a similar format of: As ____________ I need/want ____________ so that I can ________________________.

This keeps things very simple, and as the title suggests, allows the key stakeholders and customer to work through the why as well as gives the team a better idea of who they are and where they are coming from.

It’s a powerful thing for a customer to say any one of the following:

• “As a customer and key stakeholder, I need to be able to log in from anywhere in the world so that I get better at client relations and service.”
• “As an end user, I need an app to keep track of my teenager so that I get updates on her whereabouts and can keep her safe.”
• “As a decision maker in my organization, I need an app that can access my salespeople’s daily results, regardless of where they are in the world, so that I get the sales updates in a timely manner.”

Even though the above examples could be viewed as vague and nonspecific, they can be better vetted as the user story creation progresses. Remember right now that you are trying to engage your stakeholders—you are attempting to understand their needs and why they want the product, service, or result.

The goal of any user story is to make sure that you can break it down to a specific, individual amount of work (about 1 to 3 days of work) and test it for completion. It’s okay in my book to allow them to start big and work their way down to more specifics. It’s our job as a development team, product owners, and Agile project managers to get the customer to the point where we understand their vision enough to define the specifics to the point where we can execute them.

User stories give us some insight and a way to see stakeholders and end users as people needing something from us rather than some random customer. This will create buy-in on the team side of things, and the client will feel heard and understood.

Ron Jefferies is one of the founders of eXtreme Programming as well as one of the 17 contributors who created the Agile Manifesto. Jeffries also contributed to the idea of a user story by providing Agile with the Three C’s:

• Card
• Conversation
• Confirmation

Jeffries felt that all user stories should be written on a card. This makes a user story tangible and singular, and it also limits the amount of space you have to write it. There can be many user stories in one iteration/project, and each can be as important as the other. It’s up to the product owner to determine which of the cards or user stories are most valuable today. Just like the Kanban card approach or Scrum boards that use Post-it notes to describe user stories or tasks, the first C is used in the same way. The story is written on a card.

The second C is conversation, and it is perhaps the most important. I could write user stories all day long about what I think my customer wants, but unless I have a conversation with them, I’ll never know for sure. I also have a self-directed and self-managed cross-functional team who frankly knows more than I do—people who do the work, know the work, and therefore, are the best people to be creating user stories with the customer and other stakeholders. The communication, engagement, and conversation aspect is the crux of Agile. Without it, you would never build the right thing or build the thing right.

The third C is confirmation. Have we done it correctly? Have we built the right thing? Is it fit for use? Have we tested it to make sure? Can we test it to make sure?

Confirmation is a bit like the validate scope process in Waterfall project management, meaning that the customer needs to sign off on the result and validate its correct completion. You’ll have to have some kind of formal thumbs-up to call it done, and much of that comes from testing early and often to make sure everything is working correctly and meeting the needs of the customer’s definition of valuable.

Reviews with the customer will also provide the opportunity to demo the increment at the end of a sprint or iteration. This allows the customer to confirm that it’s correct or not by utilizing acceptance testing.

User Story Workshops

User story workshops are an excellent way to get everyone working together and communicating. Some of the best explanations I’ve ever gotten from my clients resulted from asking them to tell me a story. The workshops are a collaborative way of gaining valuable insight into what the end user needs and what the requirements are, and it also engages stakeholders by including them in the design process. Much like wireframes, it’s a way to get everyone on the same page. I like the workshop aspect of user story creation because I believe that to truly reach consensus and design a vision, everyone needs to have input and it’s worth spending the time to get it.

You can certainly timebox these workshops from one to two hours as needed, and you can provide facilitation or structure to the event as well. Otherwise, you have a free-for-all that’s free for all. I like to keep it to just one free-for-all and facilitate the rest.

The key to most planning in Agile environments, other than engagement and communication, is determining your workflow and improving it as you go. By collaborating on the needs of the end user with the end user and the team, everyone can begin to see a path to the workflow necessary to achieve it.

Epic and Personas

I think it is important to give day-to-day guidance on how to run a user story workshop. It’s easy for someone who has done it to say, “Oh this is super important, and you should do it.” Just as you are about to say, “Yeah, but how?” they have moved on to a new topic. User stories and workshops designed to create them are important, so I want to give you some tips and tricks on the how, not just the why!

There are a couple things that can help you in a user story workshop and throughout the project, and those are epics and personas. Let’s start with epics.

Epics

When I think of the word epic, I think of something that is massive, with many pieces of a whole put together. Sometimes it’s impossible to jump to a small user story about a couple of days’ worth of work just like that. The customer also may have a challenging time narrowing down what they want in a short sentence. In this respect, epics are a good jumping-off point, and then you can begin decomposing down to the user story and finally to the task level. Remember, all of this could adapt and change, but you have to start somewhere and the better that you understand the big picture as the customer sees it, the better you are able to break it down into an actual workflow.

I know that in Waterfall project management, the decomposition of scope is a big deal. If a sponsor says that you are going to be assigned to a year-long technology project to introduce broadband (yes, I’m aging myself) to other areas of the world, that’s a BIG ask! It’s too much information to process in its vastness. I could never in that moment answer the question of how much it will cost, how long it will take, and how many or what resources it would require. It’s too, for lack of a better word, epic. So, we begin to focus on big deliverables and break those down to a level that we can most accurately estimate. We could still be wrong, but it’s easier to zero focus than to determine specifics from a 50-thousand-foot overview.

You’ll find that your customers also start 50 thousand feet up, and they will describe something much larger and with too many moving parts to it. Guess what? That’s okay. I encourage it! The reason I do encourage those thoughts and discussions is that you have to start somewhere and, once everyone has a direction, it’s easier to map it out.

A good epic metaphor or story is useful to help explain the importance of this technique.

Personas

Personas are a great way for the team to understand the end users or customers in a way that keeps the focus on their needs while bringing a personal aspect to the users. The key to personas is to make them realistic and goal oriented. The advice from experts is to use someone who isn’t real but who can be related to in a real way. I agree with that if it is in the very beginning of the project and the team doesn’t really know the customer well yet. After that, I believe in the getting-to-know-you process of customer collaboration and communication. I like to make the personas become more realistic and more specific to the customer. It makes everything more real in our world, and it allows me to empathize or even sympathize with their needs.

Whatever way you use personas, it’s best to keep them front and center on visible cards or flip charts so that everyone can see them and use them in correlation with user stories. Keep things goal oriented but personal to the real or fictitious customer and be creative. The better everyone understands the persona, the closer you will get to creating the thing right.

Knowing your audience is a big part of Agile project management, and therefore personas are useful in a workshop environment and in sprint planning meetings. Even if the customer isn’t part of the discussion, or the team has run a couple of them and is getting better at identifying who is the customer, personas can help you walk in the customer’s shoes for a bit.

You can probably tell that epics, personas, and user stories are a large part of collecting requirements to determine the definition of done. The more times that you produce a workable increment at the end of an iteration, the deeper you can get into what the customer wants and needs. That in and of itself is pretty epic.

Figure 4.3 shows the very simple steps to consider when holding a user story workshop. Whether you incorporate all or just the ones that are relevant to your current project is up to you. One of the major trends in Agile is to keep things simple. The process can be as well.

INVEST for User Stories

Remember back in Chapter 2, “Scum and eXtreme Programming (XP),” you were introduced to the acronym INVEST created by Bill Wake. The INVEST acronym applies to having superior quality in the product backlog, which essentially means that you have effective user stories that can be estimated and produced to spec. INVEST is an effective way to check ourselves and not produce defects or waste in the process flow. Part of our ability to provide that quality is to communicate the needs of the business and the customer effectively.

The INVEST acronym is an excellent way to develop user stories during a workshop to communicate those needs, and even though you were introduced to it before, this is where it really matters—the creation of effective user stories.

It’s also important to balance both what the customer wants and what the organization needs. NPV is present here, and ROI needs to be met. This balancing act is the main reason a workshop or collaboration involves everyone—customer, development team, Agile PM, and other key stakeholders.

The INVEST Acronym

The INVEST acronym stands for the following attributes:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Let’s look at user stories in the context of the INVEST acronym to gain effective insights into what the customer wants and that this is understood by the team.

Testable

How will you know that a user story has been accomplished? Test it and test it again! Think about it this way: To graduate high school or college, you had to take tests that proved that you knew the information well enough to pass. When you take your PMI-ACP exam, you will be tested on your knowledge of Agile environments. Testing is the proof that something is correct and that it works and meets requirements.

Much of the testing piece in Agile environments is currently or eventually will be automated. In fact, many tests are written in advance knowing that the increment will fail right out of the gate. It is expected.

When the test is passed, it meets requirements. To create the right tests to prove that something is working or completed, it is important to understand what it is that you are trying to develop. Therefore, user story workshops are an integral part of Agile frameworks. What you produce in the workshop will go into the backlog, be groomed by value, and be used by the development team to estimate what they can accomplish in each sprint or iteration.

If you rolled all selected and developed user stories together across iterations, all stories combined should align with the definition of done and the definition of done-done or deployed.

The INVEST acronym is an important one to remember. Not just for your PMI-ACP exam but when you are holding your user story workshops. Figure 4.4 is a simplified version that you can keep close by the next time you host a user story workshop if you are not already familiar with it and/or using it currently.

The concept of communication and knowledge sharing in a user story workshop environment, as well as other communication opportunities, provides many keys to a successful result. Stories allow us to put ourselves into the shoes of the user or the customer, and it allows the development team to practice empirical process control by utilizing observation, conversation, and experimentation as ways to make decisions.

Originally rooted in the Scrum framework, but applicable in many frameworks, empirical process control keeps things transparent in the communication, allows for ways to inspect or test the increments being developed, and can be adapted as needed. Regardless of how you run your workshops and how you go about getting to the point where you can build out the increment, user stories are one of the key aspects of communication and knowledge sharing.

Most of the time your team and organization will be working directly with a customer who may want you to develop a website, get it up and running, and then fix any bugs with updates later. That’s realistic because you want to produce something workable and usable, or what’s called a minimal marketable feature (MMF). It’s not unusual to have tech debt from past projects to work on throughout your current iterations as well.

You know going into a project that some tech debt may occur in the future, but you can’t depend on a future update to get it right. So you focus on the here and now using communication, collaboration, and knowledge transfer to keep everything above board. You work with the customer to understand exactly who the users are and how to build the thing right and how to build the right thing. Finally, you produce a usable increment that has a minimal (the smallest amount of what is needed and valuable) marketable (you can push it out to the market as is and fix the bugs later) feature (one feature of many until done-done).

Communication and Knowledge Sharing Basics

The concept of communication is a large one to tackle because there are so many ways that humans communicate with others. We have so many ways to communicate these days, and the options aren’t fading—rather they are increasing. We have social media and colocated versus remote/virtual people that need to communicate differently as well as texts, mobile phones, and the Internet. Soon holograms and virtual reality will be a part of organizational day-to-day communication. In Agile, though, a lot of communication is low-tech, high-touch as well including visual communication via information radiators. Body language can influence the final message, and it is a large part of overall communication in a colocated environment.

Albert Mehrabian, professor of psychology at UCLA, performed a study in the 1970s on communication. This study suggests that body language makes up 55 percent overall of a face-to-face message, even if we aren’t fully aware of it. Tone of voice makes up 38 percent of the message, and only 7 percent comprises the words spoken. That’s a pretty powerful reminder that our brains are receiving more visual communication than the words themselves. The brain is said to process visual images 60,000 times faster than spoken words. That is a good part of the reason Agile teams use so many types of information radiators. They are front and center and easy to understand because they are so visual.

What happens when the communication isn’t face-to-face? Tone takes over. If you have ever read and reread your emails before sending them out to someone, that is why you are doing it. What is the message and, more importantly, what is the tone? Perception is 100 percent reality to the person decoding the message. If you don’t really like someone, and you get a message that you perceive to be a bit salty or cranky, you’ll take more offense to it. If your best friend wrote the same exact message, you’d think that they were just having a difficult day and didn’t mean to come off that way.

Communication is considered an aspirational skill, meaning that we all aspire to be better communicators. Some people pursue this more than others. In an Agile environment, the entire framework you use (regardless of method) is dependent on effective, transparent communication. The act of knowledge sharing on an Agile project can be specifically targeted communication with your team or your customer, or it can be very passive like osmotic communication. Because humans use a variety of methods to communicate, and each method is affected by many things, it seems better to address some of the influences on and challenges of effective communication and knowledge sharing one by one.