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.