Skip to main content

cross-functional

“RJ,” said Willy, the CEO, putting his arm around RJ’s shoulders, “we made you CTO because you said you could deliver. Foofle have launched a cloud product and it looks like we’ll lose our market share to them. We can’t wait a year, what’s the earliest we can launch Project Synergy? Change the team if they can’t deliver!”

Richard Jones (known as RJ to everyone except his mum) went back to his office to think about the situation. Willy was right; he was promoted because he promised to deliver Project Synergy within a year. Unfortunately, things weren’t going well. He had skilled engineers and he’d planned everything thoroughly but things weren’t working out. His DBA, Donald, had broken his leg snowboarding and couldn’t produce Synergy’s schemas, tables and queries. The middle-tier team were working on defects while waiting for Donald to recover. The UI team were finished with Synergy and had moved on but their team lead was worried about rework. He wouldn’t stay CTO for long at this rate. At his wit’s end, RJ picked up the phone and called Value Driven Software.

In their first meeting, Colin talked to him about incremental delivery explaining that, rather than working on different layers of the system, each team should work on a feature. This meant the product could be released incrementally, a feature at a time. Instead of waiting a year for the completion of every layer before releasing, they might release the first feature within weeks. RJ also learned that features needed cross-functional teams to deliver them.

When discussing it with the team Mike, the team lead, told him why they work the way they do, “We’ve considered working in cross-functional teams before but dismissed it because we don’t have enough DBAs and UI experts to have one of each in every team.” He paced in front of them, “We need to make sure that all DB and UI work complies with standards.” Colin relaxed back in his chair, “Don’t you have the tools and knowledge to do the work yourselves?” he asked. Mike stopped pacing and stared at him, “Of course we do but I’ve just told you SQL and UI work must be done by qualified people. Imagine if an engineer made a mistake and deleted a database table in production. It could bring the whole system down!” Colin held his gaze, “But what if you do the SQL and UI work yourselves but have Donald and Emelie validate it?” Emelie was head of UI. Mike and Donald were still dubious but RJ suggested they give it a try anyway.

Colin explained that a cross-functional team isn’t a bunch of specialist sub teams. “That’s no different from having separate teams. You’ll still have problems when someone’s overloaded or not available. You’ll also have people sitting idle when there’s not enough work for them.” Rising from his chair he continued, “What we need is a team of generalists that can turn their hands to anything. That way we can maintain the flow of work through the system.” Raising his voice slightly he went on “That doesn’t mean people can’t be experts. Of course they can! Think about it though, Donald. What percentage of the DB work requires all of your expertise?” a murmur went through the team but they didn’t respond, “Is it fifty? Is it ninety? Or is it more like five? Or maybe only one percent?” eventually, Mike spoke up again, “You’re right,” he said, “we do need Donald and Emelie but we don’t need them every minute of the day. We just need them to validate what we’re doing.”

Colin helped them re-organise so they could deliver incrementally. After some horse-trading between the stakeholders and developers, a plan emerged. It wouldn’t have everything they wanted but the first release would satisfy the market and the developers were confident they could deliver it. RJ thought the session was brilliant. Seeing all the work planned out, with commitment from the team put a bounce in his step. Now he was really looking forward to seeing Synergy delivered

“I don’t get it RJ,” said Willy, “six weeks ago we were a year from delivery but now you say you can deliver in six weeks.” He leaned forward with both hands on the edge of the boardroom table, “You haven’t changed the team as I suggested, what’s different? How did you do it?”

RJ smiled to himself, Willy might not think he’d changed the team but actually he had completely changed the team.

Popular posts from this blog

The Business Value of Telemetry

Dynamic technologies and infrastructure allow server failures and network issues to be quickly addressed, easily mitigated and, in many cases, reliably predicted. As a result, there’s a new venue opening for IT: end-user telemetry, which enables IT to determine how its internal users are consuming business resources, what type of application issues they are experiencing and how it impacts business performance. Gartner suggests that infrastructure and operations (I&O) leaders must change their approach and prioritize top-down business-oriented metrics. The research firm predicts that “60% of IT monitoring investments will include a focus on business-relevant metrics” by 2021, up from just 20% this year. Changing The Game Of course, it’s one thing to recognize the value of business-driven metrics and another to implement effective monitoring processes company-wide to overcome key barriers to effective digital transformation. The first step is understanding the fundamental shift requi

The Customer Paradox

We all have customers. Some of them are real live customers, people we deliver a tangible product to in return for financial reward and others are merely the next link in our production chain. Testers, for example, are customers to developers. The one thing all customers have in common is they are happiest when they are given exactly what they want. When I think back to the times I′ve been a customer, be it in a shop or maybe a restaurant, I remember how annoyed I was when given something I didn′t ask for and didn′t want. Even more annoying though, were the times when what I was given wasn′t what I wanted and it was what I asked for. This brings me to the customer paradox, which can be stated as, "the harder you try to define your customer′s requirements, the less likely you are to deliver what he wants." This is especially true about software development and, in my opinion, it′s largely to do with the way we approach project management. Yes, you′ve guessed it, I′m having a d

The Death Knoll for the Agile Trainer

The winds of change blow fiercely, propelled by AI-driven virtual trainers, and I can't imagine for a minute that certification organisations have not already recognised the potential for a revolution in training. They may even already be preparing to embrace technology to reshape the Agile learning experience. Traditional face-to-face training and training organisations are on the verge of becoming obsolete as virtual tutors take the lead in guiding aspiring Agile practitioners through immersive digital experiences. The future of training and coaching lies in AI-driven virtual trainers and coaches. Trainers, powered by artificial intelligence engines such as ChatGPT, are set to revolutionise the learning experience. With AI-powered virtual trainers, learners can engage in immersive virtual environments, actively participate in simulations, collaborate with virtual team members, and tackle real-world scenarios. These trainers automatically analyse progress, provide instant feedback