PLM & OCM Ch.9: Running an Agile Project via Collective Learning

Prev: PLM & OCM Ch. 8: Decomposition Creates Dysfunction | LinkedIn

“Hi Prof.”

“Hi Sarah, how are things?”

“Good, and thanks for the deep dive into Mass, Quality, Lean, and Agile. I compressed what you discussed into just a couple of slides, but I got buy-in from the Acme PLM Leaders. They are all concerned about quality, and Agile is gaining enough buzz in the industry that they want to be part of it.”

“Good! I remember that I first taught a unit on Agile in my 2016 PLM course, and it went over the heads of everyone. But by 2018, some students were using Agile in their work, and now I have students who are Certified Scrum Masters. But there is an aphorism that I like, ‘the future is here, but is unequally distributed’. Not every organization is familiar with Agile.”

“How did you get interested in it?”

“First, like you I was originally a software developer and adopted a spiral approach to my own projects. It was easier to develop pieces and get recurring buy-in, rather than to do lots of work up front only to be surprised at the end. Two projects come to mind:

• The first was in 2008, so not many people had even heard of Agile. I played an occasional role in bringing new PLM technology to an important customer with decades-old engineering processes. Nine months after implementation began, we started to train users and brought in a trainer to give a week-long class. In hindsight, it was a funny story – but probably not so funny at the time. In a Q&A at the end of the first week of class, he was asked ‘how do we do ‘X’? and I forget what X was, but it was important to the users. The trainer said, correctly, ‘Sorry, what you are asking about is not in the scope of what we’ve developed’. There was silence, but no real drama, and the trainer flew home. When the plane landed, on the Friday afternoon of a long weekend, he had a dozen voicemails from executives on down, asking what had happened. He and the executives worked through that weekend, and in the end, the company scrapped nine months of work and started over. They lost a bunch of money on that project. There is some sort of ‘flight to a fight’ joke there, but it’s not coming to me.
• A few years later, I led a team implementing engineering change on an already running project which used what they called ‘Scrum’ but is better termed ‘Scrummerfall’. It sounds a little like a James Bond movie, but it’s a predictive project that tries to use Sprints as milestones, or phase-gates. In any event, just our piece of that project had 1500 requirements spread across 11 documents. Many of the requirements were redundant, and some were in conflict, but since they were in different documents, the conflicts were hard to recognize. That misguided project went on for nearly a year before we scrapped it and started fresh.

Prof continued, “The two projects occurred three or four years apart, and the results cemented my frustration with requirements-based approaches. Especially in the second project… in fact, the reason that there were 11 documents was because the client used 11 separate databases to manage their product development process. Cogswell was there to organize the client’s business processes into a single PLM system, but the client’s vision was limited to repeating what they currently do. This would be a good project to discuss sometime.”

Prof pivoted, “Ok… as the Lead Architect at Acme, what is your vision for their future business processes?”

“My vision?”

“Yes. In your arrow diagram, you are working with three groups, right? Simulation, Design, and Supply Chain? In just a few sentences, how will their lives be better after your first release seven months from now?”

Form, Fit and Function

“Within those three, project work begins with Simulation, and it would be valuable to Acme if Processing could procure long-lead items much sooner. Robot risers are a case in point, they are heavy steel tubes which hold the robots off the floor so that they can reach over things… maybe they need to reach over a side panel to put a bead of sealant on the car’s floor. Risers are heavy pieces of rolled steel, and take a long time from order to delivery, but they’re also one of the first things to be figured out in simulation. The simulation team can release orders to the Supply Chain group as soon as they figure this out, and Designers don’t need to be involved. But it may be eight to twelve weeks before risers arrive, and they’re often painted the wrong color.”

“Oops.”

“Yes. And related to this are recurring battles between the Designers and Engineering Services, mostly regarding how parts are numbered."

“Every PLM project has a part number battle. (See Oleg Shilovitsky discussion on this in How Not to Kill the Engineering Process with Intelligent Part Numbers."

Prof continued. "But tell me, do the blue robot risers have a different part number than the red risers?”

“No! And that’s a near-term problem to solve. The simulation team really doesn’t care about riser color, they only care if the risers are sufficiently high off the floor so that the robots don’t hit anything. But colors do have meaning to people in the plant, and if the physical risers are the wrong color, they’re not acceptable, no matter how well they worked in the simulation.”

“Why do colors matter?”

“Any number of things, but a GM plant may have a different color scheme than a Ford plant. And parts that move back and forth need to be painted yellow so that people in the plant are aware of potential safety issues due to moving parts. And at GM the moving color might be yellow, and at Ford it may be orange, etc.”

“Yes, for someone in the plant where Acme delivers a system, color denotes the function of the part. The general rule is that every part number refers to a unique combination of Form, Fit and Function, so when part colors differ, the function differs, and the part numbers should be different. If you’re ordering clothing from an online retailer, black socks have a different function than blue socks, even if the form and the fit are the same.”

“But the issue here is that the people in simulation who order the risers don’t need to know the color to do their jobs, and they have the next simulation to get to, so it’s easy for paint color to fall through the cracks.”

“And such is the need for collective learning. So, you want to go live with your first system in a few months, do you have thoughts for later go-lives?”

“I added Manufacturing and Service to the Arrow diagram. I think Acme is missing future revenue by not servicing systems after they are delivered to their customers. Acme can drive additional revenue in the Service phase, but they are not thinking of this. I think that they could also offer their customers ‘Simulation as a Service’, to help the in-plant manufacturing engineers understand what they might do better.”

“Are you thinking of Digital Twins? The idea that any information which can be found in the physical system can also be found in a virtual instance?”

“Yes, definitely. The attention of these three groups is focused on buying the right parts and getting the system out the door. I think there is additional revenue if I can get them to think a little bigger.”

“Sarah, what you said is awesome! In a few paragraphs you laid out a near-term vision on how to make three groups more efficient, and then you have a longer-term vision which sees things that Acme doesn’t yet see. You are providing insight! But if I asked you to predict and schedule when you would have all this accomplished, could you tell me?”

“Oh gosh, no. I’ll be happy to still have a job three weeks from now.”

“Right. So, while your vision is valid and should remain mostly consistent, the mechanisms of how to achieve that vision will change as progress moves on. I am such a fan of adaptive approaches like Agile and Scrum. There is not a realistic way to predict all the steps you need to complete your long-term vision, and even if you could predict the technical content of every step, you still need Acme to adopt new business processes. But by creating an Agile learning process you will build momentum towards your future vision.”

Imposter Syndrome

Sarah paused, “To be honest, I’m a little terrified. I am the lead architect on this multi-million-dollar project, and I don’t know enough to make all these decisions. I need to recommend new technologies to Acme, that I don’t know how to use myself. Fortunately, I have a deep bench of Spacely experts, and they all know more than I do, but I’m afraid that they expect me to be smarter than I am.”

Prof laughed, “Yep! Welcome to leadership! In fact, there is a term for what you are feeling, called ‘imposter syndrome’. 70% of leaders feel like imposters, and the other 30% are liars. Oh, my goodness! I remember when I first started teaching that I was terrified! I panicked on the first day of every semester that I would have stage fright. My means of dealing with it was to over-prepare my slides. I wanted to make sure I had a script I could fall back on if I froze. Over time, I’ve become more confident, but what really helps is when former students stay engaged with me after the semester is over, like you are doing now. I’m mentoring the CEO of a small company in Lagos, Nigeria, though he mentors me as much as I do him. As I was talking about my own imposter syndrome, he told me that it hits him too. Again, 70% admit to feeling like an imposter, and the other 30% are imposters.”

Prof continued, “But the term was first coined through research of women entering male-dominated fields, like engineering. What’s the make-up of your team?”

“At the moment it’s all guys.”

“And not just guys, but guy engineers. One year, when I was teaching in-person, I had only 6 students in class, and 5 were women. The class after mine was Statics or Dynamics or some heavy mechanical engineering course, full of macho guys, but as they were entering, and my class was leaving, I would think, ‘you are going to work for the women in my class’. And to be honest, I was just that sort of engineering jerk until I started teaching. After decades spent trying to prove that I was the smartest person in the room, I learned that helping others to learn is more fulfilling. Do you watch the TV show Ted Lasso?”

“I’ve heard good things, but we haven’t watched it.”

“The premise is that Ted is the coach of an American collegiate football team and becomes the coach of a European professional football team -- in the US we would call it soccer. The point is that Lasso knows less about European football than anyone on his team, so he doesn’t try to tell them how to play football. He instead helps individuals find the best version of themselves, while simultaneously getting those individuals to be motivated by team success. So, despite all the technical skills that you learned in preparation for getting this role as Lead Architect, now you need to be good at something else – you need to enable your team to perform.”

“I want to build an atmosphere of collective learning…”

“Good! What are your plans?”

Sarah’s Scrum Process

“First, predictive projects are stressful at the start, and a nightmare at the end. So, we gave the team a deadline and an overall goal, but not a list of requirements. We’ll maintain a steady level of moderate pressure, and we won’t stop our sprint cycles until the next loop costs more than the value that it brings.

We are using an online scrum management tool, which helps us with the following:

• Backlog Items: An Acme Leader creates a backlog item in the tool, by saying: ‘As <<a type of user>>> I need to <<do something>> to <<accomplish some goal>>.’ They add a couple of paragraphs on what they are looking for, and why they need it, and by creating the BLI they become responsible for driving its progress until they sign-off and say that it is done.
• Weekly Meetings: Every Friday, we host a voluntary meeting, open to all, and serve a free lunch. Every Acme Leader who puts a new BLI into the backlog will get the opportunity to discuss it and describe why they think it is important. Attendance was sparse at first, but now we get 40 people in the room, and another dozen online every week. This conversation gives attendees the opportunity to understand what will be coming soon, and they can decide if they are impacted. It may be that the BLI isn’t needed, because that task is being handled by some other group. One purpose is for people across Acme to realize that they have overlapping goals. What I really enjoy is when two people are discussing something, and suddenly a third person will realize that she is impacted and will want to be included in that BLI team.
• A ‘Minimum Viable Product’: The BLI owner makes their case to Acme peers on why they think it is important, which helps us prioritize it. Our first release, at the seven-month point, is targeting a single project, but that project will represent about 40% of Acme’s annual revenue. If the new BLI isn’t relevant to our first project, it will be kept in the Backlog list for future implementation and on any Friday, we can re-prioritize it. So, we’re not doing a ‘Big Bang’, where we try to implement everything, everywhere all at once. We’re rolling out a minimal set of important functionalities which will be viable on the first representative project. (MVP is a Scrum term.)
• BLI Teams: For high-priority BLI’s, I’ll assign Spacely technical experts to work with the Acme owner. At this point the BLI becomes a living document, and others are organically pulled into the online conversation. In the scrum tool the conversation looks like an email thread, but it’s all contained under one BLI, which is focused on what a User will need to do.
• Collective Learning (Acme): The conversation history shows who was involved and what they expect as the BLI moves forward. In the more active BLIs, four or five people will contribute 15-20 comments. Sometimes I’ll see two Acme people negotiating with each other over the best approach, and the tech expert will just follow the conversation and interject when needed. But oftentimes the Acme people didn’t realize that the new software will solve their issues in a different way, and the expert can help them with an out-of-the-box solution. Of the dozen Spacely experts on my team, only two are doing deeply technical things, mostly setting up data models; the purpose of the rest of my team is to help the Acme Leaders to learn what Spacely’s product can already do.?
• Collective Learning (Spacely): Initially, I asked my team to meet every day for the traditional 15-minute stand-up meeting, where we discuss ‘what did you do yesterday, what will you do today, and what’s in the way?’, but once the Spacely team hit a dozen people, they asked that we meet three days per week for an hour. I was very happy that they took the initiative to create a process that works best for them. After a few tries we developed social norms, and the meeting kinda runs itself. But the weekly Acme meeting goes much better because of these thrice-weekly meetings. Spacely collaborates amongst ourselves to figure out how to guide Acme.
• Sprint Cycle: We run two-week sprints, because sometimes there are database changes that need to happen over a weekend and need to be tested the following week. But the real pace of progress is driven by the Friday meetings. For every BLI assigned to the current sprint, the owner – and remember that this is an Acme employee – demonstrates what they have developed to their Acme colleagues. And this is very much on purpose – Friday meetings are about Acme people presenting new business ideas to other Acme people, not about Spacely experts demonstrating that ‘our software works’. From Monday to Thursday the Spacely team gives Acme Leaders all the support and learning that they can handle, but in the Friday meetings, and in front of 50 of their peers, Acme people show other Acme people what they have accomplished. We will help Acme learn, but every Friday they need to show their peers that they have done so."

?Sarah continued, "Finally, it is up to the Acme Leader, the BLI owner, to drive progress. I think that most feel quite good that we are helping them learn and giving them the opportunity to lead. But if they lose interest in the BLI, or are unwilling to learn, we’ll put it back on the long-term backlog and prioritize another BLI ahead of it in the next Sprint. Spacely does not force change onto Acme; we enable their Leaders to create their own change."

“Interesting, Sarah. How is it working?”

“In a lot of ways, very well. The Simulation and Design leaders are really excited about what the new tools can do for them, and like showing off what they’ve done. I think they’re informally competing to show who has done the most. But we’re not having as much luck with the Supply Chain team. I’m not sure why that is. I’d like to discuss it soon.”

“Sure. But I’m curious… Often the bugaboo in PLM implementations is managing the customizations. How do you handle those?”

Sally smiled, “I was a little devious on this:

• Customizations: Corporate Execs wish to develop company-wide processes, and do not want customizations unless they are necessary. I’ve told Acme’s Business Leaders ‘We can do customizations for you, but only if the COO’s of both the US and HQ approve it’. That is a high bar, and when Leaders realize this, they say ‘I give up. Is there some out-of-the-box way to do this?’ And then I bring in an expert to help them develop a new BLI, and the result is a change in business processes which aligns with Spacely’s out-of-the-box product.”

Sarah continued, “There was a great example of this a couple weeks ago. Charlie, an Acme design leader came to me on Wednesday saying that he needed a customization based on how Acme handles line-item costs on a project. They do this through a shared network drive, where the project manager could lock access to files after items are procured, so that they’re not purchased again. I asked Sam from my team to show Charlie a technique called a ‘phased release’ process because many other companies have this issue. And two days later in the Friday meeting, Charlie from Acme demonstrated phased releases to his colleagues, who quickly adopted it. If Sam from my team had given the same presentation, it would not have been as effective. This is why Spacely doesn’t present in the Friday meetings; we prepare Acme so that they can present to each other.”

“Cool! Anything else?”

“It’s funny, I built my career at Acme by writing customizations, but now I’m working hard to eliminate them. Also, my solutions team has started selling new software… I want a commission!”

Prof laughed, “how so?”

“If you think of the flow of information:

• Add-on Sales: my team of a dozen interacts daily with 20 Acme business leaders, and my team brings what they have learned into our Spacely meetings. In those conversations I may realize that there are other Spacely tools which would be useful to Acme. I’ll set up a one-hour Zoom meeting with a Spacely pre-sales engineer who will demo the new tool, and open the meeting by saying ‘I think this tool might solve that problem we discussed last week.’”

Sarah continues, “selling is so much easier when we can help Acme solve specific problems. I don’t sell for the sake of selling, and I make a point to leverage as much as we can of what is already available, but if we can sell $100K in software to solve a $1 million problem, everyone is happy.”

“Sarah, you are no imposter. This is great! You are bringing your insights into Acme at the moment when they have the greatest impact.”

Prof continued, “but now I need to prep for class. Talk again?”

“Yep! I’ll set up a meeting.”

Author’s note:

This is a fictional story, based on real events, and 'Sarah’s' method proved quite successful in reality:

• The initial go-live occurred on time, just 7 months after the team adopted an Agile Learning approach. In comparison, Acme’s project manager, ‘Gary’, spoke at an invite-only event a year later, and ‘Acme’ was the only project to go live in less than 36 months.
• The first customer project (the minimum viable product) was a month late in starting due to issues unrelated to the PLM implementation, and one of the greater challenges was to keep the team engaged when they were ready a month early.
• By the time of go-live, ‘Sarah’ had little to do and was even sleeping regular hours. This is very unusual, as they are often tension-filled and require late-night heroics.
• That said, ‘Charlie’ from Acme was passionate about moving Acme users onto the new system, and in the few weeks surrounding go-live he and ‘Sam’ spent their days training users, and late nights fixing problems found in training. User training is an important source of information about what is and isn’t working.
• The arrow diagram I developed missed a critical step which occurs prior to Simulation, and I was completely unaware of the existence of an important group. But with about two months remaining on the schedule, I called for a dry-run sprint which introduced no new functions and only looked for gaps. The missing group was recognized, and we were able to fit their needs on time. (My own imposter syndrome proved useful in calling for this dry run. I was NOT confident that I knew what I was doing. ??)
• At about the 6-month point, two top execs from Acme HQ, the corporate CFO who was world-wide lead on both the PLM and ERP projects, and the member of the Board of Directors responsible for Industry 4.0 adoption, came to the US to check on progress. As in the Friday meetings, Acme Leaders presented to the top execs, while Spacely’s team sat on the back wall and provided help only if needed. It was important that Acme present to Acme, and the meeting was quite successful.
• At about the two-year point, Sarah’s team, which by that point included 30 people, won an ‘Excellence in Project Execution’ award from Spacely.

?However, as successful changes were implemented at Acme, they generated cultural tensions, which will be discussed in future chapters.

Learning Goals

• It’s common, when elevated into a new role, to feel like an imposter. There is a link to a Harvard Business Review article here, and from there you can find more. The Hidden Brain podcast also covers it.
• The weekly Scrum process described here is ‘Scrum-lite’ and doesn’t leverage concepts like ‘points’ and ‘technical debt’. The real-life project made enough progress without introducing these concepts that she didn’t want to add potential confusion. But this is not to say that these deeper Scrum topics are unnecessary in any project. But what she finds most useful from Agile methods are their ability to enable continuous collective learning.
• Managing part numbers is a recurring issue in every PLM project and tends to be deeply embedded in cultural norms. Many LinkedIn bloggers discuss this, including Martijn Dullaart and Oleg Shilovitsky . (Apologies to any I’ve missed.)