Training for Agile Software Development Should Be Flexible, Collaborative

Follow us on LinkedIn for our latest data and tips!


Training for Agile Software Development Should Be Flexible, Collaborative

Using only traditional training does technical engineers and software developers a grave disservice for one very important reason: Things move too fast for traditional training methods to be effective.

Kyle Gabhart, a training and technology consultant for Gabhart Enterprises, said too often, software engineering follows a classical engineering model in how it approaches problems. That works if you’re building a physical bridge over a section of water, for example, because the river won’t get any wider. All of the variables are essentially fixed. The engineer knows up front that it’s a footbridge or for a train, and he or she can do all of the data collection, get things figured out, and then build it.

Software engineering is a different animal. The variables are constantly changing. Gabhart said the analogy would be, you’re half way through building a footbridge and the product owner says “hey, if you wouldn’t mind, can you add one quick little feature, and make it so that a train could go over the bridge as well?” In a normal engineering context that would be absurd. But in a software context it happens all the time.

“They’re like, it’s just a couple more fields, or it’s just a few more pages or entries in the database. Can’t you just make this one little change?” he said. “But the software environment is fundamentally different, and the way that people deal with it is different. We need a methodology and an approach that is sufficiently flexible to embrace the rate of change that has become the norm within the technology sector. Agile is really well suited for absorbing and embracing that type of change.”

Of course, agile technology means more than just flexible software development. It refers to flexibility in expectations around business outcomes as well as flexibility in the business need technologists are aiming to solve. It’s essentially a discovery process because in many environments there are a lot of unknowns and uncertainty. Agile helps to navigate that uncertainty, which is appropriate when the ultimate goal is to continuously innovate.

In order to promote agile or out of the box thinking and behavior in software development Gabhart said experiential training is best. There are some things one can learn in a classic academic setting, but it’s best to learn in a hands-on lab situation where technical talent can apply new concepts, see how they work, adapt and “rinse and repeat” over time.

“One thing that is often overlooked is the importance of having all the different roles involved in the training all the way through,” he said. “There’s a tendency for people to group up in their tribe whether that’s testers, developers, project managers or what have you, and agile more so than other approaches lends itself to having the entire team collaborating together, cross training.”

He said yes, participants will have different perspectives, and some elements of the training will resonate more readily with certain team members, but the value is in the collaboration because agile is not just about technology. It’s a collaboration and a communication activity that uncovers and clarifies a business need as well as the solution for that need. Diverse technical and non-technical perspectives facilitate that process and clarify the vision for the ultimate product or service under construction.

Roles will vary from client to client and situation to situation, but Gabhart said the ideal classroom might contain the product owner, scrum master, a few business analysts, the technical team, developers, a few testers and QA folks. That’s not what usually happens, however.

“Normally, you sit down and do a class with developers, then you sit down and have a class with testers, then you have a workshop with the project management team, and it’s like no no no. Everybody’s working on the same project,” he explained. “Let’s get whoever is going to be involved collaborating together; we want to mimic that in the training.”

In class, the team gets a scenario and with an instructor’s guidance, walks through all the paces. It’s not ‘okay, developers let’s drill into some random set of requirements and figure out how to build software from them.’ It’s ‘lets present a business problem, walk through the paces and have each stakeholder, from business analyst to product owner to tester, do their thing, supplying requirements, sharing stories, and receiving valuable feedback at critical points along the way.’

That’s the ideal classroom setting. Unfortunately, Gabhart said learning leaders aren’t receptive to the idea of a truly collaborative training environment.

“They should be, but their perception is, “it’s a three-day training. I don’t know that I can free up that person’s time, and aren’t ya’ll just going to be talking about a bunch of techy stuff anyway?” It’s a huge challenge,” he said. “I’ve seen it work well, yet time and time again we don’t have time, or they’re not available to do that. Or, I’ll set it up and get the non-technical folks for like half a day on day one. Then they bail and aren’t involved in the rest of the class.”

In the ideal training scenario, Gabhart said there likely will be times when the non-technical people zone out with the cartoon Peanuts teacher’s waa waa waa ringing in their ears as the technical people do their thing. But their presence is still vital to provide feedback at key points on, “did we hit the mark? Are the requirements that we defined consistent with your intent? Now we’ve built a prototype. Is that consistent with what you were expecting?”

Feedback, collaboration, having the non-technologists hear technology terminology in a different way, these things help to ensure the technology solutions developed actually solve business problems. “In the absence of solving a business need, technology literally has zero value,” Gabhart said. “You only have value to the extent that the technology enables the business to somehow be faster, better or cheaper.

“Remember, agile is intended for those contexts where there are a lot of unknowns, a lot of uncertainty, either in the tech, in the requirements, in the outcome, or all three. Because there’s uncertainty we have to iterate multiple times. We need feedback. Otherwise technical talent won’t know if they’re on target or not.”