Practicing Agility in Human Resources

The Human Resources organization at Principal Financial Group understands Agile can help a team focus on the most valuable work and deliver meaningful results more frequently. The HRIT teams were already using Agile delivery techniques on a few projects. The HR Business teams were ready to identify practices that could help them focus on prioritizing value and delivering more quickly. As the team learned first hand, an Agile Transformation is not an event, it is a journey that would require more time, energy and change than anticipated and will continue to challenge how the team thinks about value and possibly even how the organization is structured to deliver their services.

What began as a discussion to scale Agile across an IT organization supporting Human Resources at Principal Financial Group illuminated the need for active participation from the HR Business unit to ensure a coordinated focus on value and prioritization. To better manage the portfolio of demand across the IT team, to improve budgeting processes by creating a fixed and shared IT resource pool, and to ensure the work being requested aligned to the HR organization’s desire to close specific capability gaps and implement certain strategic objectives, the group understood their participation in prioritizing and planning work would be critical. The initial goals of an Agile Transformation began to take shape and focused primarily on Human Resources IT.

As the HR organization assessed their readiness and discussed potential systems of delivery that would suit their needs, the business leadership team began to see where the same concepts of Agile could help them better manage the demand on HR’s business operations, not just IT. Teams handling recruiting, training/development, communications, and compliance operating with small teams but large demands could benefit through Lean/Agile concepts of prioritizing for value and maximizing flow. Larger teams such as those handling compensation, payroll, and benefits managed dozens of “business only” projects every year and identified that rolling-wave planning, mapping work back to strategic goals, and bringing visibility to their work could help them better manage the expectations of their stakeholders. Across all of HR, many of the Principles of Agile closely aligned to an emerging initiative to revamp the culture of the team that included more empowered decision-making and improved collaboration to meet the needs of stakeholders more quickly and with less bureaucracy.

The adoption of Agile by Technology teams supporting HR seemed a straightforward endeavor. But how would it work to transform the flow and coordination of work amongst a diverse community of HR Specialists?

As an Agile Coach, focused on leading large-scale Agile Transformation engagements, I have had several opportunities to work with teams outside of technology in digital marketing, video production, and light manufacturing to build delivery systems around principles and practices of Agile and Lean. This opportunity to lead an integrated Business/Technology transformation excited me. And, eventually, challenged me to rethink some of my own biases.

The effort started with a goal to scale Agile across dedicated, cross-functional IT teams. Through discussion and education about Agile, the Business understood their involvement in prioritizing work, calling out Goals and Objectives for the teams, and in managing dependencies between IT and the Business (such as setting policies that became business rules in the software, planning to participate in UAT and training efforts, communicating availability of systems to the company’s Employees for enrolling in benefits, etc.). The leaders of the HR Organization also understood that using a tool, like Jira, would help orchestrate the dependencies between IT and the Business better than their traditional approach using email and spreadsheets.

As the discussions and education progressed, the HR Organization started to see how Agile could help them better manage the definition and coordination beyond just IT to better manage their own work and make headway toward accomplishing several key business objectives.

Business Drivers for Agile Adoption in Human Resources

• Improve Predictability and Cohesiveness
  • Collaborate and deliver on promises with “no surprises” in timing or quality
  • Deliver a cohesive set of products and services across a global employment landscape
• Improve Capabilities and Responsiveness
  • Prioritize work to yield the most benefit to stakeholders
  • Respond quickly to high priorities
• Act as “One HR”
  • Align across departments to manage expectations, priorities, decision-making and success
  • Model collaboration and empowered decision-making to the rest of the organization

With these goals in mind, we agreed to embark on a journey to bring Agile practices and tools into the HR Business teams to better manage their products and services. We started by assessing their readiness as an organization to adopt a new set of principles and behaviors in support of Agile. With a clear set of objectives and reasons to experiment with Agile in the business operations, the team made a commitment to undertake an Agile Transformation initiative across both the Business and IT organizations. With goals established, commitment made, and a transformation roadmap in hand, we were ready. Over 250 HR and HRIT staff members in roles from technology to recruiting to performance management to benefits administration were now part of this transformative journey. Not only would the 6 supporting IT teams continue their transformation, the entire HR organization would set off on this expedition together.

Before jumping right to training and coaching, I’ve learned the importance of conducting a “readiness assessment” with the organization to understand the environment, the culture and the history behind the organization’s consideration of installing Agile methods and techniques. At a high level, I spent about 6 weeks with this HR Organization, and a few interested parties from outside of HR, to understand:

• Business Drivers – in this day and age, it is not difficult to understand why Technology teams would want to adopt Agile; I wanted to understand what was driving HR to consider Agile
• Boundaries – to understand what “sacred cows” or other constraints the organization may have; to identify my guardrails and possible obstacles to address early in the process
• Culture – not because I believe a consultant working on a 6-month initiative can completely shift the culture, but to understand what cultural norms are already in place to build on in support of adopting Agile, what initial standards in the culture are ripe for change, and where the culture will be affected only through long-term adherence to and deeper adoption of Agile principles

In HR, we identified one of the key Business Drivers was to improve predictability. In the current state of the organization, the teams were taking requests for work through many avenues (operational mandates, business unit specific needs, regulatory requirements, executive direction, etc.) with little formality in prioritizing the work or rationalizing the demand against available capacity. As a matter of habit, the teams would commit to nearly all of this work from all of the many stakeholder groups and find ways to “just get it done.” As a result, capacity constraints and poorly planned dependencies would ultimately make themselves apparent when a deadline would come and go with an expected deliverable not completed (or completed, but only through heroic efforts, stress and overtime).

In terms of Boundaries in HR, there were few identified in the beginning as the team was genuinely interested in doing whatever it would take to improve how they managed work and the flow from idea to valuable deliverables.

From a Culture perspective, it was important for me to align with internal initiatives to improve employee engagement and move toward decentralized, empowered decision-making. The goal here was to encourage these HR professionals to feel confident in their choices rather than relying on managers to tell them what to do or give them permission to do what made sense.

The Human Resources organization at Principal is supported by a robust Business Architecture discipline with a well-defined capability map that also includes understanding around how each capability is performing, where there are gaps, and a scoring algorithm to help identify which capability gaps are most in need of attention for various reasons such as size of gap, risk associated with the gap, value to consumers, etc. This advanced view of HR from a Capability perspective made it easy to identify a governing structure to align with coordinating and managing the work across all the HR departments and supporting IT platforms.

In Figure 1 in the attachment, you can see that we placed an emphasis on bringing together departments that aligned around:

• Talent: The People of the company (finding, hiring, training, developing, coaching)
• Rewards: The Products of HR offered to the People of the company (compensation packages, benefits, pay, leave)
• OneHR: The Services of HR that allowed the People to interact with HR (communications, data management, research, etc.)

For several reasons, we chose to start with a pilot involving only a handful of teams that would test the new structure and governance approach. First, I didn’t want to disrupt projects that were already in flight with expectations around resource allocations and delivery dates that could be affected by changing teams mid-stream. Second, the HR organization consists of nearly 250 people in a dozen or more departments; I am one consultant – as ego-confident as I may be, even I realize managing communication, change and coaching for that many people at one time is not realistic.

The Pilot began with 3 AppDev Teams and parts of 3 HR Business Teams (parts of Recruiting, all of Talent & Organizational Development, and Workforce Planning – thus, components of the Talent and OneHR Programs). The AppDev Teams had already been practicing a form of “kinda, mostly” Scrum, so my involvement with these teams was focused on integrating them with the new Program Portfolio Structure and managing intake of work for the pilot HR Business Teams rather than on perfecting technical practices.

3.3.1       Prior Agile exposure and the right team structure can facilitate Agile adoption in a Business Team

For example, the Workforce Planning Team in HR was already familiar with Scrum and had been closely partnered with a dedicated team of developers and testers for over a year. The need for training and coaching was minimal with this group thanks to their established relationship to the AppDev Team and understanding of Agile practices. We focused on building a Jira board for the Workforce Planning team to use for managing work they were doing outside of technology (which was already on the IT team’s Jira board). Examples of this work included: preparing for an upcoming presentation to the Board of Directors, consulting with leaders in the Sales organization to conduct labor market analysis, and creating predictive analytics to help understand attrition rates for future years as part of an overall staffing initiative. The Workforce Planning team quickly adopted basic Kanban behaviors and began managing their work in Jira to better coordinate work among team members in Iowa and India. Because the team had prior experience working with an Agile AppDev Team, the adoption process and use of visual management tools was far simpler than it would be for some other HR Business Teams.

3.3.2       Most HR Business Teams are really a collection of specialists, not a cross-functional team

The Talent & Organizational Development Delivery Team (Talent), on the other hand, had little experience with anything “Agile” outside of a few subject matter experts who would be allocated to IT-related projects when needed to answer questions or define requirements. This team is responsible for the Learning & Development, Performance Management and Organizational Effectiveness capabilities.

The concept of minimizing WIP was, and still is, a struggle for many of the teams in HR; Talent was no exception. First, the culture and history of HR was such that the teams would always do their best to “just get it done” – regardless of the quantity of work or the sanity of the requests. Even after several months of practice, the WIP count for the Talent team has not decreased significantly and the team still has a fair number of work items that sit “In Progress” for long periods of time.

The team is aware of their need to focus on finishing and prioritizing for value, but 

the team struggles because external stakeholders have not change their expectations

that HR will “just get it done” and has not been part of the Agile Journey.

We needed to demonstrate there is more value to Focus on Finishing, not Starting!

The second concept that was a struggle for Talent was that of “Swarming” on work together. As they all reside in one “department” of HR, I initially treated them as one delivery team, with one Kanban board, and one approach. As I was to learn, this “team” of Learning & Development specialists was a loose assembly of individuals with similar job titles, similar roles, but very specific duties and different customers. The daily activities and business relationships each of these “specialists” have is generally unique with little crossover or backup. For example, one Learning & Development specialist may support the internal training and learning environment, but no one else on the team did the same work or even knew how to do the work if needed. Another Learning & Development specialist may support one specific business unit, but never interact with other business units. This team, like many other HR Business Teams, was “one bus accident” away from possible disaster.

Many HR Teams are a work group of Specialists, not well suited for cross-functional swarming

It would be difficult for Julie, for example, if she supported the Insurance division, to suddenly show up with the Retirement division to coach an entirely new set of people with whom she had no prior relationship, knowledge or understanding of the needs. Likewise, it would be awkward for the specialist whose primary goal was onboarding new interns and employees through orientation to show up at an Executive Breakfast and try to lead them through an Executive Coaching session that was typically led by another specialist with many more years experience and had a long-standing relationship with executives.

Needless to say, “one team, one board, one approach” was not going to work as I had anticipated. For me, it was awkward to come to this realization during our first day of Kanban training. Pressured by a short engagement timeframe, I had not spent sufficient time breaking the organizational capabilities down further at an individual contributor level to understand how I might better create a visual management system that more closely aligned with their reality. After this first day of Kanban training, the team had stuck through it with me to at least learn about the basics and feel comfortable with basic Jira functionality. But, I went home that evening frustrated.

I was surprised by the next coaching session with the Talent team. We reconvened the next day, where I expected the team to push back on this “Agile” stuff and the approach to managing work visually, swarming, prioritizing for value, etc. What surprised me, though, was that the team started the discussion with the Agile Principles at the forefront. With attention placed on the needs to “trust motivated individuals,” “satisfy the customer,” “focus on meaningful deliverables,” and other concepts we had talked about from the Agile Principles, the team started to define how they would personalize Agile, Kanban and the use of Jira for themselves. The team recognized that they all had very specialized and focused jobs, with little overlap, but that there were several team projects that they could share responsibility for regarding key activities and deliverables. Further, the team identified that the concept of swarming actually fit nicely with some of their internal succession planning and the need to balance workloads during specific seasons where one individual could potentially be overloaded (and demonstrated a working knowledge of how the team understands “sustainable pace” and a need for backup).

As a coach, I found myself in an interesting position. Typically, I am the one barking out orders and directions as to how the team should behave and operate in order to be “Agile.” Here, I found myself listening to a team take the things they had learned, apply them to their own situations, and personalize the initial application of those concepts. Was it perfect? No. Was it a wonderful attempt at the first step? Absolutely.

As a result of the Talent team taking ownership of their Agile journey and starting to behave in different ways around the handling of work, including regular opportunities to inspect and adapt their own practice, the team has shown they can manage a steady flow of work through the system and is comfortable with both Agile Principles and Visual Management. In spite of several sizable work requests coming into the team unexpectedly, the team has maintained a steady pace at prioritizing work together, minimizing wait-times by revisiting items in their “waiting” column on the board before beginning new work items, and is starting to incorporate “team & process improvements” into their backlog to be addressed in each Sprint. As an early step toward building a more cross-functional team environment, the team is even taking opportunities to pair together as part of cross-training and skill-building for team members.

Through this process of Agile Transformation in Human Resources, the usual suspects in Technology made themselves apparent:

• Improved time-to-value for high-priority work
• Improved response time to operational work and small enhancements
• Reduction of overhead in planning and scheduling resources

What surprised me, pleasantly, with respect to the HR Business Teams was the quick and easy adoption that several of the teams displayed. That example of self-determination and adoption by most of the teams helps soothe the disappointment I feel in the lack of enthusiasm and adoption displayed by others. But, I know it is a journey and that the entire organization is on that journey, even if at different paces on different routes.

When working with a technical team, for whom Scrum, XP, SAFe and other Agile frameworks apply neatly, adherence to “best practices” is fairly straightforward. When working with non-technical teams, and especially when combining techniques from multiple practices (like I did from Scrum and Kanban), it’s crucial to evaluate what is value-add and what is not. For example, I started with a “Daily Stand-up” for each of the teams on a daily basis. But, given the way the teams were structured, getting the entire “department” together daily didn’t make sense. There were natural “sub-groups” or smaller teams in each HR Business Team where a daily huddle did make sense. Even from there, several teams preferred to touch base asynchronously or less frequently due to their schedules, locations or other factors. It’s about helping the team communicate, collaborate and coordinate, not about how perfectly they practice a particular ceremony.

In cases where team structures and agreements allowed for swarming, pairing and working by priority, the shift in how the team works is typically easy – work from the top of the backlog and focus on finishing. But, where teams are structured as a workgroup of specialists – whether the specialty is a work-stream or a set of relationships – the transition to working by priority can be challenging and frustrating. In most cases, those teams find it difficult, even impossible, to work by priority from a holistic HR perspective.

The majority of the work in the backlogs is specific to individuals due to the nature of the product/service they provide or the relationships they maintain. In these teams, really the only “shared priorities” in the backlog revolve around team-initiated process improvements, cross-training opportunities, and other low-value work that anyone on the team can do. The primary benefit to these teams is in the visibility that Visual Management brings, the coordination and collaboration on certain work that the regular planning sessions brings, and in identifying opportunities to improve through regular retrospectives.

I continue to wrestle with how I would approach these teams differently – and am, so far, convinced that the real changes lay in future discussions about team structure, assignments, and areas of focus. Further Agility practices may require the organization to restructure their team’s work assignments, relationships, and specialties. Whether or not to make changes is a decision that will come in time and requires the team to evaluate the practices and outcomes they have now and explore alternatives over time. As long as they continue to retrospect, inspect and adapt, this transformation should continue and opportunities to improve will become apparent.

Always, some of the most satisfying moments in a Coach’s career include observing those moments when an acolyte graduates to an evangelist. Allow me to share some of those moments with you.

In Their Own Words

“Agile is about empowering our employees to work smarter to meet the needs of our clients… it just makes sense.” – Vice President of Human Resources Business Partners

“One of the key things that makes Agile successful is communication… it’s part of how we do work going forward…this impacts everybody!“ – Human Resources Chief Operating Officer

“It helps others see everything I am working on, helps me understand what my teammates are doing… and where they may need assistance… I have a better view of…and feel more connected with…the work.“ – Talent Development Team Member

I can’t close without sharing my personal favorite tagline, expressed by a key leader in Human Resources. I will use this one for years to come…

“You ask me, ‘why Agile? I say, ‘why the heck not!’”

I would like to thank my Agile 2016 experience report shepherd, Christopher Edwards, for the early advice on how to approach this report and for the multiple iterations of review and refinement. The direction and content of thought reflected here is far better than it would have been trying to write alone and without an experienced guide. Thank you!

Sharon Vickery, thank you for your friendship and for finding this gig for me – it was incredibly challenging and rewarding.

Kathy, thank you for lending an eye to reviewing this from a Human Resources team member perspective and helping ensure a coherent, understandable message was present.

At Principal, there are so many to thank for their openness to experimentation, willingness to learn and ability to take ownership of their own futures. Natali, Sheila, Shelley, Kelly, and Ronna, thank you for helping me maintain (or find, some days) my sanity in times of frustration and chaos. Tony, thank you for trusting me, and keeping me between the guardrails of what practices would be acceptable in the long-run as I designed a scaled system of delivery. Tammy, Darcy and Natali, your examples of leadership and commitment to excellence are both inspiring and refreshing. Staci, Kathleen, Mindy, your patience and trust are so greatly appreciated. To all of the team members on the Program Teams, you have my undying respect and gratitude for the hours of commitment you made (and will continue to make). Thank you all for experimenting with me, personalizing the details and taking ownership of your own practice.