Chapter 14

Human Resources and Finance

IN THIS CHAPTER

check Creating a culture to attract excellent scrum team candidates

check Developing talent for scrum

check Morphing into scrum with existing employees and new hires

check Identifying the benefits in incremental funding

check Improving the budgeting process

When the winds of change blow, some people build walls, and others build windmills.

— CHINESE PROVERB

Baby Boomers are retiring at a rapid pace, new generations of employees are taking their places, and human resources (HR) has taken on high-level organizational value. Wasted funds due to failed projects indicate that a smarter way to finance projects must exist. As in so many business functions, old methods of achieving goals are becoming outdated.

Companies that can recognize their core HR and finance issues and then apply the scrum framework to the solutions are staying ahead of the pack. Many opportunities exist to increase human potential and financial effectiveness through scrum.

In this chapter, we guide you through the challenges and solutions in these critical organizational areas.

Human Resources and Scrum

In a survey conducted by the Society for Human Resource Management (SHRM), two core challenges highlight the world of HR today: retaining and rewarding the best employee and developing future leaders. These two concerns are really the same thing. Your best employees often become your future leaders.

When the surveyors asked organizations what their largest investment challenge would be, the number-one response was “obtaining human capital and optimizing human capital investments.”

tip We always encourage the organizations we work with to refer to people as people or talent rather than capital and resources. People aren’t commodities. They have individual skills, experiences, and innovations. The term resources, used to refer to people, is a relic. Start seeing your people as people, and see their creativity and talents as the irreplaceable value they bring to your organization.

That said, the point made by the SHRM survey is still crucial. Different types of leaders are needed. We need leaders to make the hard product owner decisions discussed in portfolio management (see Chapter 13). We need servant leaders who work collaboratively to enable and empower teams, such as scrum masters (see Chapter 2). These people empower and enable self-organizing teams to come up with the best solutions. They value iterative approaches to building products based on rapid and regular customer feedback, and they know how to pivot and respond to that feedback quickly.

Historically, technology companies have rewarded leaders who managed crisis well. In turn, these leaders promoted others who managed crisis with a sense of urgency. Although these firefighters certainly saved the day more than once, we argue that this situation caused an unbalanced shift toward crisis resolution rather than crisis avoidance.

We need leaders in development who excel by learning new skills and mentoring others as they grow. We need collaborative leaders who can work in the dynamic environment of scrum. We need people who value complementary leadership styles. Egomaniacs need not apply. Companies need cross-functional swarming scrum teams to stay competitive. In other words, we need leaders who embrace the value of change.

Reducing risky single points of failure saves money for all the reasons we’ve discussed so far in the book. Teams that collaborate to solve a problem get quality products to market faster than teams that use traditional methods.

Creating the Right Culture

In Chapter 4, we discuss what motivates employees most: not money, but the autonomy and trust needed to do the job, opportunities to grow, and a sense of purpose. People want what they do to mean something, and they want to work with other people who are growing and engaged in what they do.

The fruits of self-organization and self-management are the creation of an organizational culture that attracts and retains the best and the brightest. As we state in Chapter 1, these are Agile Principles 5, 8, 11, and 12.

remember Creating the right culture has many facets. The number-one thing we look for in an effective scrum team member is versatility. Give us someone who is intellectually curious and has what we call a contributor personality, and we’ll have success with that person. We can teach technical skills. Prima donnas who think that this thin slice of development is the only thing worthy of their time will taint the entire team. The most important job on a scrum team is the job that’s necessary to ship the product. Sometimes, that job is coding; sometimes, it’s quality assurance; sometimes, it’s documentation. Whatever that task is, it’s the highest-status, most critical job of the entire project.

Crucial to the creation of an attractive organizational culture is the attitude of executives: what qualities they embrace and how they invest in their people. Like a magnet, leaders attract people who respond to the culture they provide.

Broad organizational culture is important, but so are tactical team skills. Cross-functionality within teams, fostering the ability to swarm, is critical. The keys are aptitude and skills, not titles. A cross-functional, self-organizing team is the perfect environment for skill development. As employees grow, they can become more engaged in the organization’s goal and purpose.

remember Technology changes too fast to get stuck in the single-technology specialist mindset. The standard tech choice of today may be totally different from what’s needed tomorrow. The specialty of tomorrow is the ability to learn and adapt quickly. You need team members who recognize this.

As skills are emphasized over titles, a culture is created in which you don’t have to hire one person for each skill. Expertise (not specialization) is always needed. You don’t need a specialist in every seat.

Situational leadership is important. If Jim has expertise in .NET, you’ll probably defer to him when you’re facing a .NET problem. Carol may have expertise in quality assurance. When discussing quality assurance, you may defer to Carol. Sam may have just come back from a .NET conference, and although Jim may be strong in .NET, Sam may have learned something that Jim doesn’t know.

The following sections describe two ways to examine HR and scrum.

HR and existing organization structures

In this section, we look at ways to organize and manage current employees within a scrum structure.

Incentivizing

Forced ranking and competitive incentive structures promote competition among employees. Scrum is teamcentric. The team receives praise and receives suggestions for improvement. Incentives should be on the team level too. If the team succeeds, the team gets the prize.

When a football team wins the Super Bowl, every person on the team gets a ring whether he played that day or not. If a development team has a good year, everyone on the team might get a 15 percent bonus, not just a few select people. Depending on your seniority, 15 percent could be significant.

For large teams, this practice may not work. But with scrum, development teams are between three and nine members, so it’s difficult for one or two team members to fly under the radar for very long. A self-organizing, self-managing team demands the contribution of every team member so that everyone earns the prize in the end.

Compensation

If a team is cross-functional, and no titles or specialists exist, how do you create status? You create status through knowledge and being the go-to person on a subject. Someone who’s a heavy lifter on the team has a lot of tasks in the Done column of the task board, and other people want to pair with those people and shadow them on tasks.

Seniority and relative compensation are established by a combination of skill depth and breadth. Each member of a development team has at least one skill. If you know how to do one skill, you’re Band 1. You may be junior-level Band 1 or senior-level Band 1, but you’re Band 1.

If you know how to do two skills, you’re Band 2. You may be junior-level Band 2 or senior-level Band 2, but you’re Band 2. If you have three skills, you’re Band 3, and so on.

Each new skill gives the developer another band. As the team matures through shadowing, swarming, team pairing, and knowledge sharing, each team member should be adding skills (becoming cross-functional). As team members achieve higher levels (such as Band 2 and Band 3), their pay scales rise accordingly.

This situation is a true win–win situation because an organization can pay team members more and save money by having teams of cross-functional employees rather than an army of sharpshooters who know how to do only one thing.

tip By incentivizing developers to learn more skills and therefore increase their status, you give them the opportunity to design their own education and career path. Often, the skills they develop are those that they’re most interested in or have the greatest inclination for. They may be introduced to skills that they never would have tried before but find that they have an aptitude for.

Team members have an incentive to gain more skills, and the company benefits by paying fewer people higher rates and developing scrum teams that are more effective and efficient.

Underperforming team members

If anyone on a self-organizing, self-managing team isn’t pulling his weight, scrum exposes this fact quickly so that the team can correct the problem. In Chapter 4, we discuss the Hawthorne effect, which shows that a worker’s performance improves when someone is watching. Visibility and performance are directly proportional. Scrum also uses information radiators such as task boards and burndown charts, which raise visibility and performance.

tip One client had multiple flat-screen TVs in his building’s lobby. The screens were split into quadrants and showed the day’s burndown of four projects at a time, refreshing with new projects every 20 seconds. Every person walking into that lobby (including suppliers and clients) could see the status of every project that the company was working on — a high-visibility situation for each scrum team and each team member.

Lack of transparency in goals and expectations can also play a role in underperformance. If a person doesn’t know exactly where she’s headed, it’s understandable that she can get off course.

Underperformance in scrum can easily be identified in burndown charts, where daily tasks are marked as accomplished or not accomplished. New code is comprehensively and automatically tested every night through automated tests of continuous integration. With this type of visibility, in which the team is accountable as a single unit, any lapses are easily found and solved.

In a traditional model, if a developer wants to hang out on Facebook for three hours each day, he can easily do so. He can tell the project manager that he needs 4 hours to finish a 45-minute task. If the project manager says that he could do the job in less time, his response might be “Really? Show me how.” Because the project manager probably doesn’t have the coding skills necessary to fully understand the task at hand, his only option is to let the developer get on with whatever he wants to do. The rest of the team members figure that as long as they’re doing their jobs, the problem is that developer and the project manager.

Under scrum, however, teams are held accountable as single units. If a developer spends three hours on Facebook, his teammates will hold him accountable for not doing his share.

Here are some other ways that scrum can expose performance issues:

  • In the daily scrum, before any escalation of an issue occurs, team members can suggest that a troubled developer join them in shadowing or pairing on a task. This suggestion is the team’s idea and may be all it takes to solve the problem.
  • Sprint retrospectives are excellent times to identify gaps in skills and possible solutions. Causes of underperformance can be unearthed, such as team dynamics, the environment, and misunderstandings.
  • In sprint reviews, the team can encourage the struggling person to engage in the demo. In preparation for the demo, things may come to light that prompt ideas for the retrospective.
  • If all the developers know that one person isn’t carrying his weight, but they’re uncomfortable bringing up the issue themselves, a good scrum master will facilitate the interactions needed to address the issue.

HR and scrum in hiring

When you make organizational changes and adopt scrum practices, you’ll search for and hire new employees using different criteria than you did before. Following are some things you need to consider when you’re hiring for each scrum role:

  • Developers
    • Remove titles from the job descriptions and base your searches on skills. You’ll not only filter your search results based on skill keywords that candidates include in their profiles, but also filter out candidates who are more interested in touting their titles than their skills.
    • Search for candidates who have curiosity and a desire to cross-train — those who have demonstrated an ability to work outside their comfort zones.
    • Search for generalists who have broad skill sets and experience in moving among skills.
    • Find people who seek chances to work with a team. Even the most introverted soul enjoys working with respectful teammates.
  • Product owners
    • Look for the key characteristic of decisiveness.
    • Find people who have worked collaboratively with developers and stakeholders.
    • Seek the soft skills of communication and proactivity. Providing effective, timely clarification is critical to a scrum team’s success.
  • Scrum masters
    • You want soft skills such as facilitation of conflicts and demonstrated effect on previous teams’ performances.
    • Look for someone who can protect the team, display empathy, and mentor as a servant leader.
    • Don’t advertise for a project manager hoping to convert that person to a scrum master. The project manager role doesn’t exist in scrum, and it may not be the right fit.

Regardless of the position you’re trying to fill, search for people who have positive scrum and/or agile experience. Regularly review job descriptions and update them with appropriate scrum role terminology and Agile Principles to attract candidates who prefer working with scrum.

Performance reviews

After you have your new scrum-focused hires, performance reviews can be team-based. Reward people based on their contribution to the team, shifting the emphasis from the individual to the team.

Team-level performance reviews are a natural for scrum. Given the high visibility inherent to this framework, daily assessment is given through peers, and team output is consistent and tangible.

Formal annual reviews of individual employees are for the most part artifacts of traditional project management frameworks. They’ve proved to be ineffective for several reasons:

  • People need and want regular feedback, not just a review at the end of each year. Regular coaching is the key.
  • It’s difficult to assess an entire year’s performance, with all its nuances and situational factors, in one review. By its nature, the review will be incomplete.
  • Poor performers should be coached and mentored early, not after a year has passed.
  • Positive, constructive feedback is much more effective than the appraisal format of an annual review.

The most logical, straightforward way to provide feedback that helps team members improve is to have each person’s peers provide a 360-degree review (see Figure 14-1). On scrum teams, these peers are team members, stakeholders, and customers. Instead of being a formal performance review, a 360-degree review is a feedback tool. Each member of the team can understand the effect of her work on every other person involved. This holistic view shows how an employee is performing within the entire work environment.

image

FIGURE 14-1: The 360-degree performance review.

Use 360-degree performance reviews for determining compensation and (more important) for helping team members inspect, adapt, and improve. When you use them only to satisfy HR requirements or determine merit increases, you miss the full power of 360-degree reviews.

Some benefits of a 360-degree review are

  • Viewing an employee’s performance from different angles allows for greater understanding of which skills need improving and which are outstanding.
  • Growth depends on frequent, high-quality feedback.
  • Starting points for improving skills can be identified.
  • A baseline can be set for measuring improvement.
  • Personal blind spots in an employee’s behavior can be identified.

Finance

The goal of business is to make money to provide and improve products or services. Therefore, finance lies at the heart of any successful project. Increasing competition and tightened budgets require making tough, wise funding decisions.

Billions of dollars are wasted every year on projects that failed or died somewhere along their protracted and painful development. Here are just a few examples:

These are only a few examples of preventable financial waste.

A survey conducted by KPMG on global IT project management unearthed some startling findings. When respondents were asked about their experiences in delivering value in projects after receiving funding, this is what they found:

Most of this was likely preventable.

Incremental funding

Not surprisingly, companies want to fund an initial deliverable before they decide whether to keep funding a project. In scrum, product increments are produced every sprint and packaged for release every release cycle, so incremental funding is easily incorporated.

technicalstuff Incremental funding is a financially driven method of funding projects. It focuses on maximizing returns by delivering sequenced, portioned customer-valued functionality to maximize a project’s net present value — the present value of future incoming cash flows minus the purchase price and any future outgoing cash flows.

What used to happen in corporations is that the business team would go before a funding committee with a proposal and return on investment (ROI) numbers that team members believed were necessary to get their project funded. If they were successful, the team spent every nickel of that funding and then delivered results or asked for more funding. Few people looked at the ROI numbers from months or years earlier because the company wasn’t going to get that money back anyway. Sunk costs meant that companies had to move forward at all costs.

In scrum, the product owner goes before a funding committee with his vision statement and monetized product roadmap. He might say, “I need $3 million to implement all these features.” The funding committee can respond, “Okay, we’ll allocate $3 million for your project. But first, we’ll give you $500,000. Show us that you can deliver the ROI promised for your initial release, and we’ll give you more money. But if you can’t deliver on a little bit, you can’t deliver on a lot.”

Many companies prefer to use incremental funding for their projects with or without the accompanying scrum practices. Incremental funding is used to do the following:

  • Mitigate risk. Stakeholders and product owners can test the projected ROI at minimal cost to see whether they hit it.
  • Reduce costs. A minimal investment is used at the start.
  • Maximize returns. Earlier monetization leads to higher revenue.

technicalstuff Another way to look at team funding is in terms of MVP (minimum viable product), which we introduce in Chapters 5 and 13. You should be able to monetize the MVP (explicit ROI). If the MVP realizes the projected ROI, fund the next MVP.

Incremental funding creates an opportunity at every release for product owners and stakeholders to examine their ROI. At each release, if problems exist, depending on the size and complexity of those problems, stakeholders can invest in fixes or terminate the project before more money is wasted.

Revenue can be started earlier. The goal is not just less waste but earlier return — and earlier return means higher return. Value is delivered to the customer earlier, and his buy-in increases. Controlling risk and cost is important; so is providing value. If you can identify ways to deliver distinct features for generating revenue in earlier time frames, you should chunk them out and deliver them first so that the customer can realize revenue before the end of the complete project. As revenue comes in, the initial costs are offset earlier, and overall revenue and profit over the life of the product are higher.

Historically, a project’s ROI is projected, and funding is received based on that projection. Projects are rarely canceled because testing and customer feedback are left until the end of the development cycle. Even if problems are discovered, it’s difficult to take money back after it’s been allocated. Not surprisingly, ROI projections are sometimes inflated to get funding.

With incremental funding, the ROI is kept honest because it needs to be proved at each release. If the increment fails to deliver, no more money is invested.

This lower cost of failure allows developers to nurture their creativity and even form an intrapreneurial culture. Fresh ideas can be tested, and if the ROI is met, they can be continued. Company cultures change as trust is built through tangible delivery and the intrapreneurial spirit is nourished.

Failure no longer exists; it’s replaced by consistent learning toward the next success when costs are low, and innovation is encouraged. Self-organizing teams have the freedom and motivation to come up with their own best designs and solutions.

The following sections discuss standard accounting practices that fall in line with this incremental approach to financing.

Statements of position (SOP)

The American Institute of Certified Public Accountants publishes statements of position (SOPs) on accounting issues. SOP 98-1 defines the point in an internal software development at which project costs are expensed (that is, capitalized):

  • Expenses in the preliminary planning stage are expensed in the period in which they occur.
  • Expenses incurred during development can be capitalized or split to be included in the overall price of the software asset and then amortized as costs during the life of the product.

Scrum allows for more costs to be capitalized after planning and throughout the project, because planning and overhead are lower and value-added activities are higher. Most of a sprint is spent on value-added activities, whereas a traditional model spends as much time on planning and analysis as on the development phase.

Scrum allows the cost of doing business to occur in increments, as opposed to expensing the entire project up front. Profit can be realized much sooner when you spread initial expenses across the life of the project. The sooner you deliver value to the customer, the sooner the revenue comes in. This capitalization approach means that profit is realized sooner rather than later.

Scrum and budgets

Traditional budgeting methods, especially in private companies, entail creating a budget for the entire fiscal year. This budget is meant to capture all expenses and revenues for that year.

Management commits, tracks, and rewards based on this estimated budget projection. If a manager or product group exceeds revenue estimates or spends less than the estimated expenses, that person is group rewarded. If the manager or group falls short of revenue goals or exceeds estimated expenses, questions must be answered, but evaluating over- or underperformance is done by reflecting on what has happened in the past; it’s a reactive process.

Organizations should accept a yearlong budget as what it is: an estimate. The next quarter’s estimate should be the actual target and what teams measure their goals against. The team tries to meet or exceed the budget for this one quarter rather than the budget for the whole year.

Subsequent quarters are still considered to be estimates and treated as such. Teams can incorporate what they learn in the current quarter into the next quarter (inspection and adaptation in finance).

This is how Wall Street works with company estimates. Companies publish their current quarter’s estimates and establish those further in the future. However, those estimates further out have less weight than the current estimate.