The adoption of agile methodologies and working practices is a process enterprise CIOs are increasingly keen for their digital teams to undergo, as part of their wider IT transformation efforts.

Download this free guide

The human side of DevOps

DevOps practitioners often claim taking care of the technology side of the continuous delivery equation is nothing compared to getting the people part of it right, as agile-inspired processes often require IT teams to adapt to very different ways of working. Download this guide to read best practice and real-world examples of organisations who have successfully addressed the human side of DevOps.

This is based on the feedback of 300 UK and US-based CIOs, with the former and latter group reporting an agile IT project failure rate of 12% and 21%, respectively.

“The truth is that, despite the hype, agile development doesn’t always work in practice,” the accompanying report concludes.

There are good reasons for that, according to Nick Street, associate director at agile software development company, Pivotal.

In their rush to get going, a lot of organisations fall into the trap of getting too prescriptive with what their agile strategy should look like, Street tells Computer Weekly.

“They’ll say, ‘We’re going to use a particular agile methodology, say Scrum or whatever, and this is how it is going to work’,” he says.

“But agile is about being able to iterate and change and respond to the needs of your teams: there is no cookie-cutter version that can be imposed that will be ultimately long-term successful for their team. They need to find their own way for their industry and domain.”

And Street should know. Pivotal, whose UK headquarters are based near Old Street in London, provides organisations with guidance on how to make their agile ambitions a reality.

Its customer list features more than a third of the Fortune 100, and includes the likes of Allianz, Ford, BMW, GE, and Liberty Mutual, to name a few.

The process invariably begins with an exploration of the client’s current approach to software development, and at look at how (or how not) these square with addressing the organisation’s wider business goals.

“It is about ensuring we understand the problems at stake for the product we’re trying to [help them] build, so we know we’re starting in the right place and not wasting any work when we start engineering,” says Street.

This typically leads on to a 12-week period, termed the delivery phase, where Pivotal and the client expand their work to delve a little deeper into what it is users want from the product, while experimenting with how best to meet these requirements.

“Alongside it we will also be doing engineering work, giving us a decent level of time to build a simple version of a product that adds value to somebody but, at the same time, enables us to enable our clients,” says Street.

A paired approach

During the “secondment”, the client’s software developers follow the paired programming approach to software development and delivery, whereby two engineers sit side-by-side at the same computer and work on the same piece of code together.

“To make it more ergonomic, we equip them with two keyboards, two mice and two monitors, but if they try and type at the same time, they’re going to end up with gobbledegook,” says Street.

To prevent this, the paired engineers are encouraged to talk about the software problem they are trying to solve, and decide the best way to address it.

“The process will force you to communicate and collaborate while working, meaning you can decide together the highest priority thing you should be working on, and you can bring each your expertise to the problem you’re trying to solve,” says Street.

For example, pairing up engineers with backgrounds in different parts of the technology stack can be hugely beneficial, he says.

“Bringing together a front-end engineer with a back-end engineer means you can solve the full stack of the problems involved, so you don’t have to break down work according to the technology strata,” he adds.

The psychological aspect of having someone, essentially, peering over your shoulder as you work means paired programmers are more inclined to stay focused on the work at hand, says Street.

“Pair programming ensures every line of code is known and understood by at least two people. So that brings in a sense of shared responsibility, shared ownership and it brings a lot of team spirit because you are working incredibly closely in a collaborative way,” he says.

“It can also reduce the cycle time it takes to go from getting one of these ideas through to production, and ensure you don’t go down rabbit holes or things that aren’t good solutions. You maintain focused too because you’re not distracted by things such as Facebook.”

Figuring out what these pairs need to work on and prioritise is influenced by user feedback, which is passed on by the product design and product management teams, says Street.

“While we might be building good quality software, we might not have solved the real nub of the problem that a company has, so product designers represent the user and advocate for them,” he says.

The product designer’s input is essential to ensure the changes the paired programmers are introducing to the software creates features users want, while the product managers are focused on ensuring the result is in keeping with the needs of the business.

“That’s something in traditional waterfall [software development] processes that often happens right at the beginning if you’re lucky, or right at the end when you give it to people,” says Street.

“By [building it] this way, that gives us opportunities to build software that really matches the needs of the people we’re building it for at every stage.”

Pooling resources

Each pair of engineers works together for a day before being swapped around to ensure their knowledge gets shared throughout the team.

“We pair Pivots [Pivotal employees] with the client at lot at the beginning so we can show them this way of working and we can make sure everything is test-driven at the code base,” says Street.

“We can also help curate and make sure [clients] have the right people on their team to build their capacity, and the right capacity to do this on their own.”

This knowledge-sharing and pairing up means the client’s digital teams should have everything they need to keep agile software products afloat and thriving when they return to their own place of work.

“We provide the scaffolding at the start of a project [because] we have the environment, the people with the know-how, and we can bring you in and show you how to work this way. So, in time, they will be enabled to lead this process themselves,” says Street.

There is often a subtle shift in the way clients behave that tells Street and his team that the time to withdraw from the engagement is nearing. Instead of looking to Pivots for guidance and support, they are figuring things out on their own and sharing their knowledge with the rest of the team.

“Once we get to that point, we tell them to start thinking about going back into their own workplace and building this community in their own environment,” says Street.

“We’ll have our team work with them in their workspace for a few weeks after that to work through any unexpected issues, so we’re not just throwing them into a new environment where they might just panic when they’re not quite sure how to get things done.”

There are also a number of elements pertaining to the workplace culture that pervades Pivotal, which Street and his team hope clients take with them once their time at the company draws to a close.

For instance, organisations need a culture where empathy, respect, communication and collaboration thrive for paired programming to work.

Street points to the organisation’s commitment to staging a brief, stand-up meeting each day at 9.06am as integral to this process, which everyone (including clients) is invited to attend.

“We use it to welcome new people in, which helps others identify people, perhaps from other parts of the business, they might not necessarily work with on the day-to-day but would be useful for them to have an ad hoc conversation with,” he says.

“We also raise ‘interestings’, and these can vary from sharing details about security alerts our engineering teams might need to address to a joke or something else that helps build rapport within the teams.

“These are things we do for ourselves anyway, and we see these ideas spinning out to our parents and clients, but it’s also part of helping the technology companies that come and work here think the different tools, practices and working styles they could be using.”

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy