Sometimes, we let problems go on for so long that we stop seeing them as problems we can solve. Instead of hoping we cn fix the problem, we joke about it. The problem becomes an inside joke, repeated or heckled frequently until the joke itself becomes ingrained in the culture.

A few years ago, my wife and I moved from a condo to a larger house. Some house chores take much longer in a larger house, like vacuuming. Whenever my wife would get ready to vacuum, she whould joke “Get a bigger house he said. It’ll be fun he said.” Vacuuming had transitioned from a problem into a joke.

Jokes get old though. And finally tiring of the joke, I resolved to fix it by buying a Roomba. Now I have other problems, like getting someone other than me to run Roomba, but my wife and I don’t repeat the old joke.

Taking this lesson, I crafted a retrospective exercise. This is designed to surface those large, systemic problems by asking the team to consider what they joke about. I ran this retro recently and the team seemed to enjoy it. Try it out and let me know how it goes.

Joys, Problems, and Jokes

Supplies Needed

• Post-Its
• Markers
• Dry Earase board or Poster sized Post-It
• Dry Erase Markers

Setup

Distribute Post-Its and Markers and write on the Dry Erase Board or Giant Poster the 3 words Joys, Problems, and Jokes as a header to 3 different columns. Reserve some space on the board for Action Items

Introduce the 3 sections to the team by describing the joys as the positive things that happened in the last timebox (sprint, iteration, PI, etc.), the problems as those struggles that arose in the same timebox, and the jokes as the problems that are so long running that we now joke about them. Feel free to use my example or use one from your life or work to make it personal.

Running the Retro

Give the team members about 5 minutes to jot down 1 idea per Post-It. When done, ask them to post their items on the board in the appropriate section.

You can use dot-voting if you have more Post-Its than time allows you to discuss.

Then invite the team to discuss each of the items and bring the conversation back to look for actionable improvements when the conversation strays.

Don’t forget to capture the action items as the team discusses them. Ensure the team agrees to the action items and ensure each item has an owner before concluding the retro.

While tackling the Jokes, solutions may be harder to come by. There’s a reason the team and the organization jokes about these problems - they are likely hard to solve and others may have tried in the past. Ask what we’ve done before so we can consider lessons learned. If the team gets stuck on solutions, ask how they can make things just a little bit better, so things aren’t nearly as painful.

I have a confession to make. For many years, I worked with teams where we never set a sprint goal. This was just not part of my initial Scrum training (from my Scrum Master/QA Engineer who had been a part-time Scrum Master for 4 months). While my teams didn’t define a sprint goal, they still delivered value. But still, something was missing. We were missing a connection to a larger purpose. We were missing a singular focus. We were missing the raison d’etre for the sprint.

With a well-crafted sprint goal, the team has a singular focus. While crafting the goal, the team takes a moment away from the tactical, day-to-day development and delivery of software and have an opportunity to connect the tactical items defined in the user stories back to the overall vision and direction for the product being built.

A sprint goal is one, singular statement that defines what the team will work towards during the sprint. It is one logical thing, and one thing only. The sprint goal becomes the most important thing to accomplish. It is outcome driven - stating the outcome we hope to achieve in the sprint, not the tasks that we hope to complete. If the team is faced with prioritization questions during the execution of the sprint, they should first ask which item is necessary for the sprint goal.

As with most things in life, it’s as much about the journey as it is the destination. Crafting a sprint goal to set a team’s singular focus might be hard. Good! It should be hard, because by choosing our focus, we must discuss trade-offs. By focusing on one thing, that means we may not achieve this other thing over on the side. As the team discusses what the focus is and isn’t, they practice the hard decisions they may need to make later in the sprint when the sprint goal begins to slip out of their reach.

I’ve seen some teams treat sprint goals as a list of outcomes the team hopes to achieve. They treat the sprint goal as ‘sprinkles’, an after thought garnish to the team’s planning process that scatters the team’s focus. Take a moment and say the phrase ‘sprint goal’ as fast as you can 10 times. What did you hear? I hear the word ‘sprinkle’, and that’s exactly what you get when you rush through the creation of a sprint goal.

Example

Let’s dive into an example of what a decent sprint goal looks like, a good sprint goal, and a ‘sprinkle’.

For our example, let’s say we are building an online bookstore. The site is functional, but we are overhauling some elements of the site, including the search functionality so that we serve up more accurate results. The team chooses the following stories for their sprint, in priority order:

• Search on Book Title
• Search on Author
• Search on Description
• Bug Fix: Correct Book Review display issue when reviewe leaves 0 stars
• Allow user to report offensive Book Review
• Allow user to view list of all of their reviews
• Allow user to edit a review

A Decent Sprint Goal

Complete Book Search Feature

This is ok, but it is output focus (complete the task), and not outcome focused (what value we are delivering). This Sprint Goal is better than a ‘sprinkle’, and does tell the team where their focus is, but it doesn’t connect back to the vision of the product.

A Good Sprint Goal

Enable shoppers to search for a book so that they find a book to click on on the first page of results 80% of the time

This goal does not call out specific stories, but it is specific about our aim - we want accurate results delivered and have included our measure for success.

A ‘Sprinkle’

Complete the following items in the sprint

• Search functionality delivered
• Fix Book review display issue
• Begin Book review enhancements

What is wrong with this sprint goal? First, it avoids any hard decisions. In fact, were there any decisions made when the team crafted this sprint goal?

Second, there are 3 focuses here, not 1. This team will find itself split on 3 different areas throughout the sprint. They will likely start all 3 sprint goals on day 1 of the sprint and keep a scattered focus throughout.

Finally, this sprint goal is essentially a copy of the sprint backlog, only summarizing a few stories into a couple of bullet points. If most ofthe information is already captured in the sprint backlog, what value does the sprint goal have?

Conclusion

Sprint Goals, when used well, are a powerful tool to bring a team together. It forces tough conversations. It reminds us of our overall purpose and direction. It gives us a target beyond ‘complete this story, move on to the next’. Sprint goals should not be sprinkled onto a team’s process as an afterthought or written such that a team’s focus is sprinkled around the backlog. It should be a singular, well crated goal that drives the team forward.

In Agile Software Development, there’s a general fear of talking of costs. Costs are something that leads to budgets, which leads to planning, which leads to big, up-front planning, which leads us to waterfalls. But costs don’t have to follow this pattern, if we truly talk of recording costs after they have incurred and take a lean/agile approach to projects.

Tracking costs lets us know how much we spent on an effort. By pairing this with the lift in revenue or cost savings the effort lead to, we have an idea on what our return on investment (ROI) is. Teams may also fear calculating an ROI, thinking that if an effort did not have a positive ROI, then they did a poor job. This is a symptom of a lack of psychological safety, which is a much bigger problem. But that’s a topic for another time.

Tracking cost is can be tracked 1 of 2 ways: by calculating a team’s cost per story point and extrapolating costs from there, or by tracking the team’s time and account for the team’s individual costs. The first approach is unobtrusive, but requires careful calculations and makes many assumptions. One assumption is that team members are 100% dedicated to their team and 100% of their effort goes to the work the team is doing. This approach will give you a number that is ‘roughly right’, but will not be very precise. The second approach is obtrusive, as it requires team members to record the time spent on various tasks (depending on how granular you go), but will give you a more prescise cost.

Besides calculating a Return on Investment, the biggest reason to track cost is to determine a team’s capitalizable expenses. In accounting, a capitalized expense is the expense invested to build or acquire an asset. If I start a business and build a storefront, that store is an asset. The materials that went into building the store would be capitalizable, as well as the labor costs to construct it. However, once built, the electricity and other utility costs would be operational expenses and would be realized as expenses on the budget as they occur. A capitalized expense, on the other hand, is recognized over a period of time - a time span equal to the usefullness of the asset. For a storefront, that may be 10 years or more, where as fixtures or software will have a shorter span of usefullness, somewhere between 2 and 5 years. As the asset ‘depreciates’ or loses value, an expense is realized.

My father, who’s a banker and an accountant, described capitalizable expenses this way: in accounting, you want to recognize expenses such that they align with the revenue those expenses generate. Having a store front allows me to operate a business and earn revenue, but I must spend money in order to earn revenue from a store front. This includes the operational expenses that are on-going and the up-front costs of building the store.

Capitalizing assets and depreciating their value allows me to recognize large, asset-building expenses as I occur revenue. This provides a picture of how much it truly cost you to earn that reveue. Some expenses, like utilities, are operational expenses. But when you have an asset like a building or software you built, its usefullness decreases over time. The building needs repairs. The software becomes dated. That’s another reason these assets are depreciated over their useful life span: at some point, additional expense will need to be made to update the asset. The software will need to be upgraded, or the store front remodeled to fix wear-and-tear and to stay up-to-date with modern trends.

To know if I am TRULY running a profitable business, I need to consider if I am making more money than both my operational expenses AND my capitalizable expenses. If I spend $1 million to build a store front, have monthly operational expenses of $1,000, and make $2,000 a month, it might appear that I am making a profit. But in reality, it will take me 83 years at that pace to make back the initial investment into the store front - and I will need to repair it frequently over those 83 years! By capturing the capitalizable expenses, I can get a better picture of the businesses profitablity.

It’s for this reason that so much effort goes into tracking capitalized software costs. If I spend $3 million this year on 2 different software projects each, and one is an operational expense and the other capitalized, I will incur a $3 million expense this year for the operational expense. For the capitalized project, I may not occur ANY expense this year if the software hasn’t been released yet. But, once it has been released, I will incur a $1 million expense each year, capturing the depreciation of the value of the software (assuming a usefulness of 3 years for the software).

This is an over-simplified example - with software, there are some activities, like planning, that won’t be capitalized. But by understanding how the accounting works for software, we can see why capturing our costs is important.

Scrum introduced the concept of Spring Goals - an outcome the team aims to accomplish by the end of the sprint. Rally, aka CA Agile utilizies ‘Milestones’ as the key deliverables or decision points in a project and is a term familiar to Project planners. Scaled Agile introduced the idea of Objectives for a team’s Program Increment, or a series of sprints.

Whether you prefer or use goals, milestones, or objectives, these GMOs play a critical role in a team’s success. A goal, milestone, or objective (GMO) gives a team focus, a rallying cry, an item to circle around as the team develops a solution and writes code. When crafted by the team, a GMO provides an additional connection to the work. It also helps leadership gauge if the team understands the work and the value it provides.

A GMO benefits stakeholders too. When crafted in language both stakeholders and teams understand, it brings both groups together. Using language that only 1 group understands builds walls, not bridges. It also gives stakeholders an idea of when work will be delivered, so that they can make plans based on when a deliverable is met. This might include training, marketing material, or the launch of a business initiative. Whatever the activity, having an idea of when the GMO will be delivered aids in business planning.

In crafting a GMO, there are 3 important things to keep in mind. First, the GMO should be SMART. That is, the GMO should be Specific - providing enough details as necessary. It should be Measurable - we could measure the GMO to guage success (and a yes/no answer is measurable). A is Achievable - it’s something that the team has the skills and everything necessary to accomplish it. R is Relevant - that is it is something desirable that the business and stakeholders want. Finally, T is Time-bound (or time-based). That is, the goal is achievable within a certain timebox and it has a rough date for accomplishment in mind.

Second, a GMO should be written so that all parties can understand what it is. It should be written so that business stakeholders understand the value the GMO will provide. It should avoid all jargon, including business jargon. Everyone who interacts with the GMO should understand it - including the development team. This will require the technical team to understand the domain their software operates in. That is, they must understand the business well so they know the terminology in use, the concepts behind it, how they connect, and the processes behind the concepts.

Finally, and most importantly, a GMO should not be so constrictive that there is only 1 way to achieve it. If there is only 1 way to accomplish the GMO, how agile can the team be when it receives feedback that the direction they are going won’t work or won’t be suitable for for the customer in its current configuration? A GMO so specific that the team is boxed in ceases to be an agile goal, objective, or milestone.

Regardless of what framework you use to develop software, a Goal, Objective, or Milestone plays an important role in developing software. It benefits the development team, leaders, stakeholders, and customers. It provides a focal point for efforts. It ensures groups are aligned on deliverables and purpose. It brings people together through a common language to a common purpose. And when crafted well, it aids in a team’s maturity; crafted poorly, and it will detract from their ability to respond to change.

So unlike GMOs found in food, we should all make certain we include these GMOs in our agile practice.

Great teams don’t form by accident. They take work to form, pulling individuals together so that the team truly is greater than the sum of its parts. The best teams I worked with had 3 things in common: a unifying vision of who the team is, trust, and a big, hairy, audacious goal.

Unifying Vision

Before a team can form, there must be some reason for the team to exist in the first place. For a sports team, such as a baseball team, the game itself can bring the team together; 18 individuals can’t play baseball by themselves. A good coach will provide a more detailed vision: we’re going to be a team focussed on great fielding, or all-start pitching, or powerhouse offense. This focus gives charecter to the team and gives it an identity that it can rally around.

Trust

Trust is essential among team members. Patrick Lencioni labels lack of trust as the first dysfunction of a team. Trust is essential for a team to accomplish amazing results. How can a team accomplish greatness if team members don’t trust that another teammate will do what they say they will do? If there is a lack of trust, team members will question eachother’s motives and time is wasted on infighting instead of getting results.

Trust is not an easy thing to develop. “Trust falls” and other team building activities may build a small amount of trust, but there is no cure for lack of trust other than time. “Time heals all wounds”, but if used intentionally, it also builds trust as small committments are accomplished each day to build trust up slowly.

Big, Hairy, Audacious Goal (BHAG)

In “Built to Last”, Jim Collins and Jerry Porras coined the term “Big Hairy, Audacious Goal”, or BHAG for short, as a goal that is a mid to long-term goal that is worthwhile, yet lies just out of reach. For a team, a BHAG is only achievable when everyone is working together. It’s such a large goal that no one person could accomplish it on their own. Only through team work and hard efforts can the goal be achieved.

In sports, this may look like a coach rallying his team of underdogs to a championship, taking on impossible odds, and still ending up on top. I’m reminded of my Cincinnati Reds and the 1990 season where they went wire to wire, advanced to the National League pennant, then were faced with the Oakland A’s and their ‘Dynasty’ in the World Series. The Reds werethe underdogs in the series, but the crappy team with ‘Da Nasty’ boys in the bullpen swept the Oakland A’s 4 games to 0.

A BHAG may sound ridiculous, like the underdogs sweeping the opposing team. It may seem impossible. But in my career, the best teams I’ve coached were forged in the fire of battling a BHAG. By overcoming adversity and accomplishing the seemingly impossible, anything else thrown at the team felt like a walk in the park. In such a battle, trust will be required, but if the team consists of the right people, they will deliver and build trust at a phenomonal rate. And it’s teams like these that we look back on and marvel at all that we were able to accomplish together.

On Friday, July 26th, I had the privilege of speaking at the 10th CincyDeliver Conference, formerly known as the Day of Agile. It’s my favorite conference because many of the talks are given by practioners like myself who are leading and working with agile software development teams on a daily basis.

You can find the presentation for this talk here: .

Some of the talks for this year, plus the past two years can be found on github here.

During my final year in High School, I took a programming course in which I learned/relearned QBasic and Visual Basic. Both languages introduced me to numerous elements of programming. While I learned a lot of elements, I would learn some underlying principles later. For instance, my final project was a turn based role playing game. To turn the code in, the teacher asked that we print out the program. At 80 pages, my project was by far the largest. I was not blessed with super-speed typing, but I did possess the ability to copy/paste the common elements where ever I needed them.

In these early years, I had not learned the DRY Principle. There are many elements of good software that developers learn throughout their career. One that quickly becomes ingrained is the DRY principle, which is an acronymn for “Don’t Repeat Yourself”.

DRY reminds developers that the best, easiest code to maintain is the code you write once, and not the code that you write or copy/paste repeatedly. It challenges developers to reuse code and castises them for when they copy and paste code.

This principle works well with code, but it doesn’t hold up when working with people. Try as we might, we can’t just tell someone something just once. It often takes several times for a message to be heard, understood, and engrained. Old marketing guidelines state that a person needs to see or hear your content 7 times before a consumer truly hears the message. Those that we serve also need to hear a message several times. A new process, a new business direction, a new vision, stated only once, will never come to fruition. It takes frequent reminders, frequent statements, for anything a leader shares to be heard by all.

Leaders have to operate by different principles than Engineers. Instead of DRY, think of RYE - Repeat Yourself Everyday. Only through repitition of the same message over and over can a leader ensure that a message is heard.

Very shortly, my old blog site, kevin.generalizingspecialists.com will be shut down. A lot of my older posts here, like The Coach part of Agile Coaching was taken from this site. A colleague and I had envisioned launching an agile podcast 3 years ago, recorded one episode, and concluded we did not have the time to pursue the project further. The most fun from project has been bringing it up in conversations around the concept of Generalizing Specialists.

The concept of Generalizing Specialists is near and dear to the heart of a Jack of All Trades like myself. I’ve held every role on a typical Scrum team, I’ve spent 6 months on a DevOps team, and am currently a Release Train Engineer. From this eclectic background, I have numerous skills that I bring with me. A Jack of All Trades like me is the ultimate Generalist, capable of filling any role, wherever the need arises. It’s characterized by the ability to plug in the gaps, when they are found, and ensuring things continue to move forward.

Jack of All Trades get a bad rap though, as they are often derided as being Masters of None. Some argue that they are over generalized to the point that they have no single area of mastery.

In discussing the concept of Generalizing Specialists, the ancillary concept of ‘T’ shaped skills is often mentioned. The idea is that a capitalized ‘T’ represents one’s skill level in a number of skills. It’s not very deep in ost skills, save for one in the middle. A Jack of All Trades, on the other hand, would have a ‘-‘ hyphen shaped skills. The hyphen may be wider than the ‘T’ shaped skills of another, but there is no one area of mastery.

Except, I think there is one area of mastery that Jack of All Trades are masters in - playing in the white space between roles ang groups. By being adept and filling any role, these individuals have learned how to maximize their ability by recongnizing gaps and doing what it takes to get the job done. Those that get a thrill from doing anything and everything will find a way to discover where they are needed and make themselves useful.

In startups and small companies, you see many Jack of All Trades out of necessity - without a large group of people, the need hasn’t risen for granular role specialization. For the business to keep operating, everyone must fill in the gaps wherevery they may be.

Large organizations, with the economies of scale that they operate at, seek out specialists. Look at most job descriptions, especially for those for a developer in a large organization, and you will see very specific languages and tools referenced, as the organization has setup specific roles. But a large organization needs Jack of All Trades too, to play in the white spaces between their specialists. In a software organization, these Jack of All Trades are often the leaders, the managers, Scrum Masters, and Release Train Engineers, who are all adept at identifying those gaps and calling attention to them. The way these gaps get filled will vary from person to person and role to role. But identifying these gaps and where teams are impeded is the speciality of agilists at any level.

The term Jack of All Trades was preceded by a British term, Johnny-do-it-al. It also had a bit of a negative connotation when it was introduced to describe Actor, Playright, Poet, and Businessman William Shakespeare. Just because you do it all doesn’t mean you can’t be wildly successful.

Like any kid who grew up in rural Ohio any time in the last 50 years, I played little league baseball. I never had a knack for it. I played in the outfield often and could not throw far. So, when I fielded the ball, I would run the ball in from deep in the grass until I reached the sand and only then throw it to my teammates, as if I could outrun the base runners. Looking back, I’m amazed anyone put up with me playing on the team, since I clearly couldn’t field and had little success in the batter’s box either.

Our coach worked with us on two things: the fundamentals of baseball, such as hitting, catching, fielding, and throwing, and good sportsmanship.

As the saying goes, “it’s not whether you win or lose, it’s how you play the game”. That was a good mentality to take with me on the team.

As agile coaches, this mentality applies doubly to us. We have many eyes on us. We set the example for how teams should cooperate, collaborate, and function together. It matters less if we are successful or “right”, as long as we deomnstrate the value and behaviors that we coach our teams on. We are all human and we will make mistakes. Our mistakes should be the exception, and not the rule. We should strive to habitually embody that which we stand for.

Returning to our sports analogy, what kind of sportsmanship would you expect to see from a team that is coached by someone who yelled at every mistake, threw their hat when the other team scored, who argued with the umpire when they disagreed with a call, or berated the team when they lost? These players might become decent ball players, but would they be people you would want on your team? (No thanks, I’ll pass.)

Are the actions and behaviors you have at odds with the Agile values and principles? If so, consider where your team currently struggles with in Agile. As the team is in some way a reflection of you, they will likely struggle in the same area as you, because you have not shown them how to be successful with it yet.

While not every player or team member we coach will become a star, they still need to operate well within the team. But, they may one day become a coach in their own right. And if you demonstrated the right values for them, they’ll likely carry it forward for the next generation, teaching others the right way to play the game.

I love finding great coaching lessons in unexpected places. A few years ago, I watched a comedy special by Craig Ferguson where he posed these 3 questions one should ask others before speaking.

Does this need to be said?

As a coach, not everything we think of needs to be addressed. Perhaps the team didn’t discuss a story during the standup. Given the current development of the team, the day of the sprint, and the importance, consider if the omission is important enough to call out.

Does this need to be said by me?

A coach doesn’t have to be the one to point out an omission or problem. The best agile coaches are teaching there team to work together, and this includes holding each other to high standards and ensuring everything gets done.

If a team is far enough along in their growth, it may be detrimental for the coach to call out very basic advice or poiut out obvious problems. But, if the coach waits long enough, someone else may speak up. My best coaching moments have come from when others are applying the lessons I’ve taught them and calling out the problems I’ve taught them to look for.

Does this need to be said by me now?

The final question ponders the timing of coaching intervention. Is now the right time to act? Or, would it be better to save the conversation for another time, such as the sprint retrospective?

Conclusion

Coaching is based on soft skills, which can be learned from anywhere. Keep your eyes and ears open, and you may find some great tips from the unlikeliest of sources.