A 6 Month Cultural Transformation with Scrum

1.     INTRODUCTION

An agile journey is not only for the teams building the products. This change is for the whole organization, but it started first with my mindset and the mindset of the leadership team. Because letting go of control and trusting others is not what got me and my peers into a leadership position.

Through the process it often felt counterintuitive, even unproductive, to allow space for the problems and the resolutions to come out of the work. Our natural tendency to step in and solve the problems for our people robs the organization of learning and adapting, which makes them very fragile to change and worse overly dependent on leadership.

As COO of Penta Technologies, I, Laura, needed to realize that my place was no longer solving problems but to create and protect the environment that allows others to thrive in solving problems. If l didn’t own up to the habits and behaviors that needed to change within, we would never reap the real benefits of an Agile transformation.

2.     Background

Penta Technologies, founded in 1991, is a family-owned construction software company located in Milwaukee, Wisconsin. They support construction back-office services with an accounting and finance ERP system, a labor productivity suite, and payroll tools customized for the construction industry.

Penta Technologies has, for years, run like a construction company that operates in the Cynefin simple space, rather than a progressive software company that runs in the Cynefin complex space. The software platform was built to meet the unique needs of its customers, and the customers would often pay for features. Because of this model, customers controlled the functionality, and the product became more and more complex and challenging to scale. Over time, this led to a mammoth, dispirited product that was difficult to enhance, implement, and support.

Contract negotiation and fighting customer emergencies ruled the day. Employees were distracted with constant context switching from one effort to another. The frequency of delivery was slow and inconsistent. Silos of specialty were only getting more in-depth, which led to a complete disconnect between creating value and doing work. A change was needed.

3.     Our Story

3.1        How It Began

Laura’s Perspective: I felt like I was looking at the business through a pair of binoculars; the more we were able to eliminate waste and get focused on the real problem, the more transparently the picture came into focus. I had been a technology executive for over 20 years, had previously held roles leading sales, product management, channel development, marketing, customer service and consulting, but had never seen people work so hard for so little progress. When I realized the entire product development organization needed a redesign, I was eager to take on this new challenge as COO. While I understood the theoretical difference between waterfall and agile, I didn’t realize how powerful this transformation would be or how quickly it would change everything.

The leadership team didn’t start by implementing Agile processes, but instead initiated by focusing on identifying the core problems and the most significant sources of waste. In June 2019, at an all-employee company meeting, I (Laura) announced that they were going to partner with everyone in the organization to figure out the best structure for the business. During this offsite, the employees identified the issues they wanted to see fixed in the new organization:

• Remove functional silos
• More ownership in the work
• Remove unnecessary and complex processes
• Stop micromanagement and improve trust
• More focus on value

Over the next 30 days, several employees researched different organizational structures and collectively decided on a team-based, servant-leadership organizational structure through a move to the Scrum framework. With a deeper level of buy-in, it was time to start their agile journey.

While this the decision to move to Scrum may sound very linear and clean, it’s important to note we started the Scrum journey in a trial and error manner. A number of internal projects and teams focused around components of products just started using Scrum, with the interpretation they had from self-learning. While it was messy (sloppy use of terminology, ad hoc training, follow only parts of the framework, and people were split across multiple teams) we recognized the benefits (increased employee motivation, better cross functional communication, better project results). It was apparent that a more intentional, organizational-wide effort would reap significant benefits.

3.2        Getting Started with Help

After careful evaluation of the product strategy, the customers, codebases, and marketplace the team determined there were three products Penta Technologies had that would yield a return of investment.

The first was their core construction ERP system, the second was a construction labor productivity suite, and a third was a new construction payroll system. The leadership team reached out to a few different coaches and trainers to find someone to help them. During our initial call with Jeff Bubolz and Jeff Maleski, both consultants with Humane Consulting and Scrum.org Professional Scrum Trainers, they provided direct constructive feedback around the approach and helped set a different direction on how to restart Penta’s agile journey. Major changes included:

• Everyone in the organization needed to understand the impact of moving to Scrum and how it would change how they worked. This included putting the entire team through the 2-day Scrum.org Professional Scrum Foundations (PSF) training;
• Fully committing to Professional Scrum for the first 90 days with no deviations;
• Alignment around the goal for everyone to be able to speak the same “Scrum language” to be validated by everyone in the organization passing the Scrum.org Professional Scrum Master I (PSM I) certification assessment;
• Performing an exercise with everyone to self-select in the formation of new teams;
• Alignment on changes to the organizational structure; and
• Alignment on the measurement of success.

On the call, I (Laura) had a well thought out and constructed plan; however, because I was open to constructive feedback, I felt a sense of relief that I could turn the process over to someone else who had done it before.

I, along with President Bill Wagner and Jeff (Bubolz) all knew from the openness and transparency of the discussion; this would be a great partnership.

Jeff’s Perspective: During my initial discussion with Bill and Laura for this engagement, I saw a company that was hungry for organizational change. Often organizations think of team self-selection as a radical change. Still, after hearing the problems with engagement and the culture of micro-management that had taken place in the past, I knew that self-selection would be a very impactful activity that would show the Development Teams that leadership was serious about organizational change.

When I met with the executives, directors, Product Owners, and Scrum Masters, I found that many of them had seen me speak multiple times before. Very quickly, I had built up a lot of rapport. I was quickly able to jump into a coaching and advisory role. I wanted them to know what they were getting if they decided to move forward with me, helping them on their agile journey. If they were looking for someone who was only going to work at the team level or someone who would not address the broader systematic issues, I was not their person.

3.3        Kicking off the Journey

Immediately after training, we tackled team formation. Everyone on the different Development Teams was brought together for a whole day team self-selection event. In this event, leadership set guiderails for all the teams; they included items, such as team size, skills needed, and being able to deliver customer value from concept to cash.

Development Team members then self-selected into teams aligned around the three product areas. 80% of the self-selection was easy; the remaining 20% had several conflicts where individual Development Team members had every opportunity to solve the conflict on their own. When an impasse was found, I (Jeff Bubolz) along with my partner, Jeff Maleski, facilitated conflict resolution.

There were several passionate debates on who should be on which team, but by the end of the time-box, the Development Team had self-selected into teams within the leadership teams guiderails. Interestingly, both the development manager and Laura were out during this week, allowing freedom and space for this effort to happen on its own.

After team self-selection the three products looked like the figure below. Each product had a unique Product Owner. The Core product had one Scrum Master that served on both teams, and the Payroll and Labor Productivity products shared a Scrum Master. Each of the Development Teams was dedicated to their products.

Figure 1. The Structure of the Penta Teams

The next week, the new teams started working with me to create their definition of “Done”, working agreements and start building and refining Product Backlogs for the three Products, and then they were off Sprinting. Like many teams that start using Scrum, they had Product Backlog Items broken down into waterfall phases (Analysis, Design, Develop, Test, Deploy) and they needed to split work by value and outcomes.

After the first Sprint, all three products had a “Done,” potentially releasable increment that could be released to production. Some Product Owners did release their Increment to production, and other Product Owners decided not to ship the Increments that had been created as of yet. During the first couple of Sprints, Product Owners created outcome-based roadmaps to tell the stories of the Product Backlogs. The amount of transparency in the organization was at a level that people had never seen from the product organization.

Jeff’s perspective: Over the course of two weeks, we:

• Ran two, two-day Professional Scrum Foundations (PSF) courses;
• Did team self-selection to align around three products, with a Product Owner for each product;
• Refined three different Product Backlogs with enough work to get started working in a value focused way;
• Aligned each product around a Definition of “Done;” and
• Established a working agreement for how we were now going to work together.

This was a lot of change really fast for an organization that had been working in a waterfall fashion for decades and despite all of this change each Scrum Team was able to create a “Done” working product Increment that shipped or could have been shipped to production.

In my experience, having all products get to “Done” this quickly is not the norm. The only way this happened is with having everyone in the organization bought in 100% to the change.

I worked with many leaders teaching them on how not to define best practices for the teams, but rather to give them space to experiment with different complementary practices. The Development Teams were looking for Product Owners, Scrum Masters, and Leaders to make decisions for them.

I coached the Product Owners, Scrum Masters, and Leaders to create space, align on the vision or outcomes they desire, and set guiderails for self-organization. There were many times when this was going on that I needed to coach myself with the same advice and remind myself not to solve the problem. It is difficult for everyone to leave space for self-organizations.

I would ask the Development Team how they want to do something regarding the process, and no one would say anything. I needed to count in my head for 8 to 10 seconds or more at times before someone would speak up. I think there was some disbelief that they were going to be able to own the process for how they deliver working products.

It felt like the Development Teams were just waiting for someone to pull the rug out from under them and say we were just joking you don’t get to decide how you work. It took time for the teams to trust that this change was happening, and no one was going to make these types of decisions for them anymore.

During the first few Sprints, all of the teams did a lot of experimenting with different tactical practices. They often tried something for a Sprint or two and then refactored the practices they were using until they found some norms that worked well for the teams. It took some change of mindset that this was not wasteful, but it was adapting based on what they learned about how they worked together.

Each of the teams embraced different practices that worked well for them in their context. The teams shared what was working well and what didn’t work well. What they found is that many things that didn’t work for one team worked well for a different team because their context was different. This ownership of the practices on the teams led to higher engagement and ownership of the work.

Laura’s perspective: I had very little involvement during the kickoff phase, just following the training and passing my Professional Scrum Master I certification. I went to Italy to stand up at my brother’s wedding. We were going through the most significant organizational change I had ever implemented. It took courage to simply show my commitment and then turn the work over to the teams to execute without my involvement. Doing this was a genuine endorsement of my level of trust to them.

When I returned, we did allow every team to redesign their workspace. We purged truckloads of waste, and each team created an environment that reflected their team.

3.4        Merging Teams

After Sprint one, the two ERP Core Scrum Teams found that there was a lot of overlap because of the deep silos that people had. They found that they ended up having a Daily Scrum for each team and then had to have another full team Daily Scrum and then there was another support meeting to talk about unplanned work as it happened. These three events were taking around an hour each day.

Refinement was happening in one big group; then when the group split out and did Refinement with each team, there was always a person missing on the team, and the team felt they needed more people in the room. The Development Teams struggled with their deep silos of knowledge and not having all the business and technical expertise required on each team. The Development Teams suggested that they merge into one big team of 16 people. We both had concerns about the team size, and shared the concerns with the team. We brainstormed together to find ways to mitigate those concerns. Jeff worked with the teams to come up with some complementary practices to alleviate these concerns.

By the end of the third Sprint, the Development Team was able to do Daily Scrums in around 10 minutes with a 16-person Development Team and come out of the event inspecting their progress toward the Sprint Goal and adapting their plan for next 24 hours.

The Development Team moved into one big area, created a physical Sprint Backlog, and walked the board most days. They used the complementary practice of the 16th minute to sync on more in-depth items right after the Daily Scrum. Refinement became more of an activity that smaller groups would self-organize around and bring back to the larger group to get a greater understanding.

While the Development Team was working this out, there was talk about leadership interceding and splitting the teams in two. Leadership learned about the importance of leaving space for self-organization to happen from the past few Sprints, and stayed the course and let the Development Team figure it out. During this time, there were a lot of questions in the Sprint Reviews about how the Development Team would handle their size. As the Development Team found more and more ways to mitigate the concerns, leadership became more and more comfortable with the team’s decision to combine into one team as they continued to deliver value and provide transparency to the organization.

3.5        Financial Pressures

Everything seemed positive after the first three Sprints, and then the honeymoon period wore off. As the teams focused more holistically on the products, the revenue from paid customer work slowed to a trickle. The two greenfield products were not ready for the market even though they were making good progress on getting done functional pieces of software. The business pressure put pressure on Laura and the leadership team to share the finances with more people in the organization than they ever had. Now the Product Owners, Scrum Masters, managers, and executives all had the same pieces of financial information. Laura and Jeff (Bubolz) lobbied with the executive team to give financial transparency to the Development Teams, but the level of that transparency was under debate. They are working toward budgets aligned around products. Once product budgets are in place, they anticipated having financial transparency with the Development Teams.

Laura’s Perspective: While I was amazed at the progress we had made in just a few months, I had concerns that there was too little communication about what was happening in the work with the executive teams. I had full appreciation we were asking for two conflicting things from the most senior leaders, let go and trust while still being ultimately accountable.

Through conversations, I recognized that there was not a frequent cadence for the leadership team to meet and strategize on how they were going to handle different problems. I worked with Jeff (Bubolz) to set up a cadence for the leadership team to review their approach and get alignment on how to move forward. During this time, we had some passionate debates about financial transparency, urgency, accountability, and what should be shared and not shared and with whom.

In these meetings, spirited debate was the norm as we gained alignment on where we are going as an organization. I often had to remind leaders to fight the urge to jump in and save everyone, which would ultimately hurt all the momentum we had gained thus far.

3.6        Customer Validation

With the rising pressure of the financials came more and more pressure to reduce risk by proving the riskiest assumptions on the greenfield products with real customers. The teams requested someone to be added to the team to help from a user experience perspective. Doing this proved to take longer than the teams felt comfortable with, so they started creating paper prototypes and doing the UX work themselves. There was a need to get in front of real customers and the Development Team didn’t think this was something they could do on their own. They reached out in the organization to find help and what they ended up doing was spinning up a separate cross-functional team of sales, marketing, Scrum Masters, and Product Owners to find customers to validate the initial designs.

After a few weeks, this company cross-functional team was not moving fast enough for the Scrum Team, so they took this impediment back and asked for someone with deep user experience skills to be added to the team to build up the skill sets in this area. The Development Team decided that the simplest thing that could work was to start with other employees in the company to get user feedback. The second thing they did was ask the whole company if they had any close relationships with people that fit specific personas in the construction industry and get time setup with these people to get feedback.

They then found out that the list of things they wanted to validate with customers was getting huge, and they needed to prioritize this list just like typical Product Backlog Items (PBIs). The Development Team worked with the Product Owner to come up with a prioritization technique to prioritize these items with minimal effort. These user experience PBIs were then added to the Product Backlog and prioritized alongside all other features. With this new prioritization technique in place, they now had a strategic approach to mitigating usability concerns with their new product.

Jeff’s Perspective: There were so many great things that were going on at this point, but the one thing that kept me up at night when I thought about Penta was customer validation. There was not enough of it happening. I was lightly nudging in the first Sprint about this, but several Sprints later as the nudges became more insistent, little was done to address this issue.

I kept bringing it up to pretty much anyone who would listen. There were a few times when I almost just started doing some of it, but I resisted the urge to do this for the team. I ended up setting up a few different meetings, aligning some conversations with consultants that could help, and just generally got the ball rolling. It was great to see the team take ownership of the user experience and jump into the unknown with both feet.

3.7        Technical Excellence

Many of the people on the Development Team had only worked at Penta, and there was a concern on the Development Team that they didn’t know what they didn’t understand from an architectural standpoint. Leadership was made aware of this issue, and they worked with the Development Team to find a couple of outside consultants to help validate their technical assumptions and come up with modern approaches to great products with technical excellence.

The Development Teams drove the agendas with the consultants, and they tackled the riskiest areas first. One consultant that the team selected had a day job working for an industry leading software company, but was willing to do some consulting on the side, so the Development Team setup a pizza and beer mob programming session that started late afternoon and went into the evening. The plan for these sessions was driven by the Development Teams to help them solve the most urgent problems. In these mob programming sessions, there were developers from many different products, all working on a single product problem. Doing this led to shared knowledge and cross-team collaboration.

3.8        A Lesson on Transparency

During the 7th Sprint, one of the teams changed their Definition of “Done” because it was unclear what they were doing and what they were not doing. In the Sprint Review with the stakeholders, this topic was quickly covered, and because it was the holidays, several people were missing.

After the Sprint Review, it became clear that automated testing was no longer on the definition of “Done” and had not been completed on any of the previous Increments. Most of the stakeholders were surprised about this realization and this eroded trust with them.

The Development Team shared a plan to take an incremental approach to get back on track with automated testing with the stakeholders. During the next Sprint Review, after the holidays, trust was eroded, but the Development Team took ownership of the mistake and came up with a plan to mitigate the gap that was left. It took a while to gain the stakeholders’ trust back, but the key was delivering done working software every Sprint and increasing transparency.

Jeff’s Perspective: When this subject came up with the leadership team, I was pleasantly surprised at how serious they took the definition of “Done” and what it meant to them. The leadership team didn’t see the definition of “Done” as something just for the Development Team.

The Development Team didn’t understand why the leadership team was so upset at first. What the leadership team thought was happening and what was actually happening were two different things. I tried to help the Development Team take accountability for that misalignment, but from the time when we talked about this to when the conversation happened in the first Sprint Review, the message was lost. This led me to work on speaking more in terms of business value with the Development Team and helping them to have empathy for what the leadership team has on their plate.

3.9        The Results

The positive energy in the company is at an all-time high. Before the change, over 67% of people thought there was a lot of negativity at Penta; 3 months after the change, only 12% of people said that there was a lot of negativity. People are excited to come to work and see how what they are doing is making a difference at Penta.

Before the change, 38% of the Development Team felt empowered to make decisions, just three months after the change, 98% of people said that they felt empowered to make decisions. Teams are consistently creating “Done” potentially releasable Increments every Sprint. Transparency on where the products are going and where the products currently are has never been higher.

Sprint Reviews have become events where stakeholders from C-suite to developers on other products to adjacent departments sync on the progress made and adapt their plan for the next two weeks. Transparency, alignment, and delivery of working products have been at the foundation of creating a trusting atmosphere and new culture.

No longer are functionality requests commanded down from the executive team or mandated by an angry customer. The teams are analyzing the request, looking for the root business problem, and the whole Scrum Team is determining how to solve the problem for the customer. The teams are introducing analytics in their applications so they can validate their hypothesized solutions to the challenge and validate that they are solving the root problem. Using data to inform decision-making is becoming more and more common, with a hope to make this a core competency in the future.

Today the budgeting process is being refactored to be aligned around P&Ls by product line. Product Owners are empowered to be mini CEOs of their products. The organization is preparing to have a high level of financial transparency aligned around products.

Teams now use empirical data to forecast with Monte Carlo simulations when the new greenfield products will be ready to go to market. Marketing, account management, leadership, and the Scrum Teams are aligned around a shared vision to release what they believe to be game-changing products to the construction market. There are still many conflicts and problems to overcome, but the transparency and frequent inspection and adaptation cycles put in place have put a framework that allows the whole organization to move away from an analysis mindset and into a feedback mindset based on empiricism.

4.     What We Learned

Laura’s perspective: There were three powerful things I learned that will forever change how I lead:

1. I had a very well thought out plan on how to roll out and execute the changes that needed to happen in the development organization. And after meeting with Jeff (Bubolz), who had done it before, I needed to be able to abandon the plan and simply trust the process. Checking my ego and surrendering control was the best way to lead this change.
2. Changing the way people work—the first phase is hard, but it’s much easier than changing the way people think. I realized that the first part of this change is about executing a lot of tasks, creating a Product Backlog, getting teams established, visualizing the work in the Sprints, and creating a physical environment for collaboration to thrive. The second part is all about people and the complexity that comes with the element of change. Most leaders surrender at this stage and never realize the full potential of self-organizing, self-lead empowered teams.
3. An agile journey is not only for the teams building the products. This change is for the whole organization, but it started first with my mindset and the mindset of the leadership team. Because letting go of control and trusting others is not what got me and my peers into a leadership position. Through the process it often felt counterintuitive, even unproductive, to allow space for the problems and the resolutions to come out of the work. Our natural tendency to step in and solve the problems for our people robs the organization of learning and adapting, which makes them very fragile to change and worse overly dependent on leadership. I needed to realize that my place was no longer solving problems but to create and protect the environment that allows others to thrive in solving problems. If l didn’t own up to the habits and behaviors that needed to change within, we would never reap the real benefits of an Agile transformation.

Jeff’s perspective: Changing how people work is the easy part, changing how they think about the work is the hard part. Teaching people Scrum and different agile practices are easy. The practices are not what is important it is the principles behind the practices and knowing the whys and how to adjust practices to lead to better outcomes. Teaching this to a group of people is different every single time. I always learn a lot from everyone I work with and I hope they learn a lot from me. When pressure hits, we will naturally want to go back to our traditional ways of working. It takes consistent inspection and adaption to catch these deviations from the larger goal. It is important to embrace the unknown and frequently inspect and adapt your approach.

Working with these teams exemplified the first line in the Agile Manifesto, “We are uncovering better ways of developing software by doing it and helping other do it.” The journey and learning along the way are what got us to this point. It was not a specific practice or individual thing that we did. You will never be done uncovering better ways.

When you can get everyone in an organization aligned towards a common goal, magic is possible. Having the executive team in the same training as the developers, having regular inspection points with stakeholders throughout the organization, and being transparent with working software is a game changer.

5.     Acknowledgements

We would like to thank every single person at Penta Technologies, as with them this change would not have been possible, including: Penta’s executive leadership team for accepting the risk involved with such a large process change, along with the Product Owners, Scrum Masters, Leaders and Development Teams who made this transformation a success. We would also like to thank Rebecca Wirfs-Brock for working with us to create this experience report.