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.

A common problem I see time and again across development teams, organizations, and industries is difficulty with the Product Owner role or Product Management in general. How is it that team’s struggle in this area so often? Why can we find quality Scrum Masters, Software Engineers, and QA Engineers easily, yet the great product person is as rare as a Straight Flush in a hand of poker?

One can look to the books we have to teach the various roles. Amazon returns over 60,000 results on both Computer Programming and Quality Assurance, yet only around 4,000 books on Product Ownership. While not exactly a scientific method, it is indicitive of the market supply and demand for such topics.

But let’s take this a step further. Software Engineers, when they have a college degree, often have a degree in Computer Science, Mathematics, Software Engineering, or Informatics. Yet what degrees exist in traditional universities for Product Management? Carnegie Melon, University of Wisconsin, and New York University all offer a Masters in Product Management from their business school, but there does not appear to be any bachelor degrees for Product Management. This leads to a disparity in skills. While Software Engineers often have years of training before joining a team to write code, many Product Owners learn on the job, being mentored by those who have cleared a small path before them.

There are certifications available, like those for a Scrum Master, such as the Certified Product Owner, that provides a general introduction to product ownership, including writing stories, prioritize a backlog, and how to plan a sprint with a Scrum team. There are also training courses like Pragmatic Marketing, which provide more advanced training and a framework around discovering needs, crafting a plan, executing, and releasing a product.

And while these trainings can help a Product Owner get up to speed on their role, the simple matter is that the Product role requires heavy reliance of soft skills and influence. Technical skills, such as the steps needed to write an automated test, are simpler to learn in comparision. While one is crafting an automated test, they can refer to notes on the subject until they have mastered the steps, yet a Product Owner might get a sideways glance if they bring notes to a backlog refinement session, a meeting with a stake holder, or a sprint planning.

Your traditional training tries to assuage this by going through “simulations” in order to give Product Owners a feel for the job. And this is a good approach, but it is just once, must be done in a group, and the pace of most clasees allows little time for reflection.

But dedicated practice and exercises are a great way to build product skills and confidence. The first challenge is finding time to practice. I personally find Friday afternoons at the quietest time of the week. A couple hours after lunch are a good time to set aside to learn and practice.

The second dificulty then is how do you practice product ownership? Hear are a few exercises you can try to practice writing stories, defining acceptance criteria, and prioritizing a backlog. There’s more to product ownership than this, but this provides a good foundation for the rest of the skills.

Product Ownership Exercise

First, identify a software product or feature you use everyday, such as the latest Facebook feature, a “Pizza Tracker” for a pizza shop, or your Out-of-Office feature of an electronic calendar.

• what is your vision of what this product or feature will be?
• What stories do you need to implement this product or feature?
• What would you name the feature?
• What description for hte user stories?
• What acceptance criteria would you identify?
• Finally, what order would you want to implement these stories so that you can maximize value delivered?

For the purposes of this exercise, ignore any technical implementation details, technical dependencies, and ignore any technical concerns in terms of priority order. It’s the responsibility of the development team to serfuace these, which you would normally uncover when refining, estimating, and/or planning these stories with the team.

As a bonus exercise, find a peer, each choose the same product and feature, and independently build your product backlogs. When complete, compare your backlogs and discuss how you each choose to write the stories and prioritize them. What simularities did you have? What vision did you have when creating your backlog, and how do your product visions differ and did these differences lead you to different backlogs?

We’ve all found ourselves part of great teams that just ‘click’. These teams are capable of achieving great things. These teams are the teams, years later, you look back and are proud to have been a part of the team and amazed at what was accomplished.

On the other side, there are teams that are a bear to be a part of. THings are just off, and no amount of team building, norm setting, or retrospectives fixes the issue. What gives?

Whether you are in school, sports, work, or in my case, agile software development, teams are an integral part of working, learning, or having fun. But how can we get team formation wrong? What inhibits a team to form?

Patrick Lencioni in his fable 5 Dysfunctions of a Team, lays out a pyramid of dysfunctions that inhibit team formation: Lack of Trust, Fear of Conflict, Lack of Committment, Avoidance of Accountability, and Inattention to Results. Each one builds upon a previous one. I see these as a progression, or a journey in the evolution of a team.

While all of these are critical to a well-functioning team according to Lencioni, Lack of Trust and fear of Conflict will inhibit a team from forming the most. If a team does not trust eachother, they will act as individuals in their own self-interests. Further, if a team is afraid of conflict, they will not challenge each other and you have a team with false harmony - brushing aside their problems just so it seems like they all get along.

In another fable, Patrick Lencioni tells us of the Ideal Team Player, someone who is Humble, Hungry, and Smart. Humble is somewhat self-explanatory. Hungry means a team player will put in extra effort to achieve the group’s goals. Smart refers to Emotional Intelligence, meaning an ideal team player knows how to work well with others. If you have team members who lack these skills, team formation will also struggle.

Personality differences can also inhibit a team from forming. While I’d like to think that anyone can work well with anyone else, in reality, there are some people and personalities that just struggle to get along. SOmetimes, this is seen as polar opposites, someone driven by competition and someone who abhors competition. But sometimes, it’s a combinition of personality traits that cause individuals to struggle on a team together. This is when leaders can step in and re-arrange teams to find an ideal mix of personalities, background, and diversity in an aim to find a better functioning team.

But sometimes, the problem lies with the leaders themselves. If a leader establishes goals that are counter-productive to team formation, such as individualistic goals, or worse, goals that pit team mates against each other, how can a team form in these conditions?

Beyond the leader, the culture must also support and celebrate the team and not the individual. When teams are celebrated and recognized, it makes it clear to individuals that they cannot succeed without their team around them. When team members are given team-driven performance goals and not individual-driven performance goals, it is clear that an individual must work with their team and help it do better in order to personally do better.

There are many ways in which team formation can be stunted, slowed, or prevented. To ensure teams form, hire for people who are humble, hungry, and smart. Establish team level goals and rewards. Consider personality types and seek to find good matches where possible. And finally, ensure leaders walk the walk as well as talk the talk.