There are out there tons of articles and studies around DevOps ways of working, working frameworks, Agile Gurus, how to work in a team, shift left, no Silos, and so on, and so on… but, is hard to find any evidence about DevOps basics and the big pillar of DevOps transformation which is, in my opinion, Communication.

Usually one of the misconceptions I find a lot is the fact that people usually tend to focus on tools and automation, forgetting the Agile manifesto where it states Individuals and interactions over processes and tools, customer collaboration over contract negotiation. Forgetting that no amount of tools can be a substitute for good communication and empathy.

Isn’t DevOps a way to bring different Teams together? If so, how can you put a bunch of different people working together for the same objective or goal without Communication? Remember this: collaboration and Communication are strictly connected and dependent on each other.

DevOps is all about teamwork, all together and no Silos, but in order to achieve that we need to take into account that cultural background has a massive role on it and Communication is where sits the key or “secret” of making a difference for the success or (if that is the case) unsuccess of any team.

What my experience across the years and especially managing teams so dispersed on the planet has taught me is to level up the way I communicate to them. I am not talking about only words but gestures (even if virtual), we don’t only communicate through sounds or writing, there are many other ways of communicating and passing a message (Verbal and non-Verbal communication).

Be aware of the different cultural backgrounds and what it means for the different forms of communication, beware of the emotion around the moment and how it is affecting communication.

Invest time with your team, to learn a bit of their main language (in the case your main languages are different), discuss with them about their cultural roots and background and, along the process share yours as well. This exercise not only helped me but helped the team as well, it’s a boost to trust and Communication quality, which are pivotal when you aim for having a high performant team.

Another relevant misconception, or what I usually call a ‘classical pitfall’, is about how Teams must be able to communicate between them without a proxy/middleman! Yes, no me, no Scrum Master, no Project Manager, no Director, no CEO, no to any form of Middle Management. Unless they have the know-how for the solution they are not needed there, it will be just a waste of time for them and a waste of money for the company having them on a call monopolizing, controlling the flow of information, or even making the same a “political arena”.

Remember, tech people don’t need a middle man, they speak the same language between them and they have the delivery mindset on their DNA, they don’t need a monitor/moderator in their calls, all they need to do is to present a solution and people that are willing to contribute for the solution. They need more communication support than anything else, which means they need to communicate between them without interference from authority or other external factors.

Probably you are thinking what about when there is some friction between the teams? The classical confrontation that in human relations is often (too much for what we would like) present but by all means avoidable.

Always be the defuse element, never forget that a story always has two sides, and many times even more than two, which means when dealing with so many different teams in a proper DevOps environment, everyone needs to be heard, and the decision making is with the team union rather than one man choice without any support to that decision.

A message when conveyed less appropriately will definitely bring disunion, unneeded stress, and even sometimes it’s a call out for a toxic environment which is something that no one wants.

This doesn’t mean you need to be the Mr. Nice or the next winner of a sympathy contest. All you need is to agree sometimes that you just will disagree with different points of view without never losing empathy as at the end of the day your goal is a success like everyone else, I hope.

Many times when the discussion is more heated, or you are under stress and just received an email that pressed the “wrong” pressure button, rather than replying straight away it’s better to switch off and even sometimes to wait until the following morning before replying. Never but never reply with emotion, especially if the channel of choice is email. Always prefer “cold head” over emotions and then you will realize that actually you are part of the solution and not the problem. Contribute to defusing a potential conflict between several parts, avoid if possible endless and pointless threads of emails, which in the end are a complete waste of time (yours), resources (colleagues), and money (corporate).

Another classic pitfall, in my view, is the very long emails (even threads) usually with the wrong focus, who never had one (or several…) please raise your hand. Emails should be short, with a pragmatic approach when providing context, focus on a solution and not on the problem, the focus should always lay on Solutions or the search for the same and never about guilt.

My personal mantras for good communication:

• Transparency
• Always choose head over emotion when replying to anything
• On Virtual Meetings, give the example and always have your video on and invite (not impose) others to do the same
• On in-person meetings, close or keep away any electronic device and use just pen and paper
• Always listen to others, which means you allow everyone to finish their idea, don’t interrupt them
• In case of conflict, be the defuse agent don’t be aggressive, passive-aggressive, or even try to be a joker
• Being the one that is defusing, doesn’t mean you need to agree on something, you can always agree that you disagree
• Be pragmatic and solution-oriented when communicating with others – to point out problems or to play the blame game, anyone from any skills level or age group can do that
• Avoid “Ph.D. dissertation or thesis” for both verbal and non-verbal communication – “Working software over comprehensive documentation”
• Prefer Wiki and Instant messaging over emails

By any means I am not an authority around communication, these are my learnings through my past and continuous experience with DevOps Teams under my management and from my work career with DevOps Transformation. In my point of view, the reason behind so many DevOps / Agile Transformation failures is the lack of a culture of quality communication between teams and peers. If the communication flows freely, without any type of control or censorship, you will get a great foundation for a High Performant DevOps Team.

Good link to remember the Agile Manifesto (key values and principles behind the Agile philosophy): https://agilemanifesto.org

Written by Ricardo Moreira, DevOps Manager at Vodafone Business

The post DevOps Pillar: Communication appeared first on DevOps Online North America.

The IDC illustrates that ICT is dependent on new technology, with traditional business technology revenues in decline as cloud-based computing solutions rise.

The study shows that new technologies known as ‘Innovation Accelerators’ will provide up to US$7.4trillion in the aggregate industry revenue by 2020, with US$1.8trillion annual sales being added to the overall size of the industry by the end of its forecasted period.

The annual revenue of IoT is forecasted to reach US$1.3trillion by 2020, although security, virtual reality, cognitive systems and 3D printing will also add to the growth of the ICT market.

‘Big data is at the heart of the fastest-growing opportunities’

Vice President at IDC, Stephen Minton, said to Cloud Tech: “The traditional ICT market of data centre infrastructure, client devices, software, services, and telecommunications is now growing at a rate not much faster than real gross domestic products (GDP), and increasingly resembles a mature sector of the overall economy.

“Device sales are now dominated by mobile devices and cloud service providers represent a growing proportion of all infrastructure hardware and software sales, while big data and analytics are at the heart of the fastest growing opportunities. Meanwhile, growth in the telecom market is already entirely dependent on mobile.”

Asia-Pacific is forecasted to reach over US$600 billion by 2020, representing the largest market for Innovation Accelerators, followed by the United States, Latin America, Central and Eastern Europe, the Middle East and Africa.

Written by Leah Alger

Read more from DevOps Online | Follow us on Twitter

The post IDC: Emerging tech will rise to US$5.5trillion by 2020 appeared first on DevOps Online North America.

The arrival of artificial intelligence (AI) will lead to fewer job, said 76% of young people who are worried that robots skills will stand out more because of lack of work experience at a young age.

Supporting young people, the Young Enterprise Charity and Financial Education polled 200 young business-minded individuals for its report ‘Robot revolution: The impact of artificial intelligence on entrepreneurs and job prospects.’

Robots forcing students to learn new skills

The report findings found that 59% of participants are worried about not finding a job that a robot could do; with 33% believing that robots with problem solving and team working skills will force students to learn new skills before leaving education.

“The rise of the robots will have a devastating impact on job prospects for young people who have not been equipped with basic work skills,” said Michael Mercieca, CEO at Young Enterprise.

“Its time to wake up and recognise education must extend beyond academia and properly prepare the next generation for the world of work with skills like communication, teamwork and creativity,” he added.

Another survey that differently consisted of 111,362 participants and was created by www.gov.uk similarly showed that more than 10% of workers believe that 20% of daily tasks could be taken over by robots.

Written by Leah Alger

Read more from DevOps Online | Follow us on Twitter

The post Robot revolution to take jobs, say students appeared first on DevOps Online North America.

Even with a helping hand from developers, testers, deploys, monitors, log, configuration management and collaboration platforms, the online gaming company’s road to DevOps wasn’t straightforward. “Our road to DevOps consisted of monthly releases, downtime during release, costly meetings between teams, communication issues and late integration issues,” said Sztupak.

In a bid for Gamesys to change its path another route needed to be found. “We needed to find a way to prevent the following issues: we needed to split up monolith, create a platform that allows people to create microservices easily, deploy those microservices, automate processes and automate what’s on the Dev’ side,” he added.

Before the change, backend and frontend teams were separated, teams were effectively going at different speeds and frontend and backend teams were merged into verticals.

“A platform team needed to be built up from members of different teams. We set up to drive the move to microservices, gave ourselves more leeway in assessing new technologies, created Dropwizard (a common platform) and found a way of specifying our APIs,” revealed Sztupak.

After 5 months and 3 weeks they finally found solutions. Legacy-in-a-box removed the convoluted build and deployment process, and made it easy to make changes to the legacy monolith.

“To ensure that the following was achieved, teams started to create microservices even though there was no way of deploying them, containers were introduced, GoCD was used as a framework, and everything was built automatically in git,” he added, concluding that Ansible, Docker and GoCD are the backbone of DevOps technologies.

Written by Leah Alger

The post Gamesys road to DevOps appeared first on DevOps Online North America.

In a bid to streamline the content development process, they addressed team challenges, such as being asked to support new projects, competing priorities and bottlenecks and silos, but in an agile fashion.

According to Milcetich, working in agile allows resources to be shifted, whatever the users need. “If it’s tax season and we need to make major updates to our tax content, we can now more easily pull anyone from the team to support that effort. We’re able to balance resources to match priorities and work in a more proactive, rather than reactive, manner,” she added.

Culture change

In this case, switching to agile implies grooming backlog requests, holding bi-weekly sprint planning meetings and retrospectives and using a board to track work in progress.

“It was a big change in the way we work. Our previous model had been based on a newsroom-style operation where people were clustered together around specific areas of content to use the journalism terminology,” admitted Milcetich.

“The newsroom model works really well for media outlets with bigger teams of people, but for a small government content team, it wasn’t the best fit because it didn’t easily allow people to support projects or user needs not on their beat.”

In order to keep things moving, employees regularly communicate about the status of work and roadblocks.

“While our process isn’t perfect, and we’re certainly still learning as we go, operating in a more agile manner has helped us focus our priorities and deliver content that will help our users accomplish their tasks,” said Milcetich.

Written from blog post by Leah Alger

The post Agile influences the USAGov appeared first on DevOps Online North America.

The glittering awards ceremony will take place in October, Central London.

Meet Richard Hilsley – our judge from Aviva

Richard Hilsley, Director of Platforms and Engineering at Aviva, will be one of this year’s judges at the upcoming award ceremony.

When discussing his own DevOps journey, Hilsley said, “I’ve tended to be a big advocate and sponsor for DevOps adoption, to inspire change in teams and IT organisations as a whole”.

He went on to say, “I think that’s not always easy, because companies tend to not understand it. Organisation structures and operating models can make implementing DevOps difficult, and I’ve had to face these problems previously.”

When asked what he will be looking for in entrants, Hilsley said, “new ideas and ways of working that have broken with convention in some way, particularly where teams have had to demonstrate determination and resiliency.”

12 exciting categories to enter

You will be able to enter 12 different categories at The DevOps Industry Awards 2017, ranging from Best DevOps Automation Project to the DevOps Team of the Year.

If you work in a specific sector, then there are also categories reflecting the Best Overall DevOps Project in Finance, Retail, Gaming, Public Sector or Communication.

The DevOps Industry Awards are here to stay

Being launched this year, entries for the DevOps Industry Awards, which celebrates companies, individuals and teams who have accomplished significant achievements in the DevOps space, open on 1 March 2017.

As a judge at this year’s DevOps Industry Awards, Hilsley believes that awards ceremonies such as this one “raise awareness of the topic in a positive way, and it’ll inspire teams to not give up on something, that generally, is a very good thing. It also allows the industry to connect and share ideas – you need every bit of help you can get in IT nowadays, it’s a complicated industry.”

Entries need to be submitted by the 14^th of July 2017, and the winners will be announced at the Gala Dinner in October 2017.

Written by Jordan Platt.

The post Entries for the DevOps Industry Awards are now open! appeared first on DevOps Online North America.

With the promise to help companies deliver software much faster, with higher quality and less risk, the concept and practice of continuous delivery are taking IT organisations by storm. But easier said than done – indeed, it’s normal for companies to wrestle with how to make fundamental changes to their work structures and processes, as well how to kick-start new technology into their organisations. For a company evolving toward continuous delivery, this author wishes to share 3 tips for a successful transition.

1. Treat continuous delivery as a strategy not a technical solution

Continuous delivery offers enormous business benefits by radically removing waste from your software delivery process. But continuous delivery is much more than a set of technologies. It’s a strategy that reverberates across the company, transforming the way you deliver software to your customers. As such continuous delivery requires executive support, buy-in across the organisation and hands-on participation from all stakeholders in the release process, from developers and QA, to operations, release management, IT management, and business people. This is equally, if not more, essential than technology for successful implementation.

It’s not uncommon for organisations adopting continuous delivery to adapt or completely scrap some old organisational-wide practices, rooting out manual work, replacing it with automation and embracing principles and practices (such as agile) that promote the frequent, reliable execution of repetitive tasks.

2. Replace silos with cross-functional teams

Continuous delivery requires a high degree of collaboration that’s not possible when using traditional siloed approaches to software delivery. This is because communication between business, development, QA and operations takes place on many different levels, which often leads to confusion and long wait times due to handoffs between different people and groups. All of this increases the potential for hesitation and disruption.

Slow, error-prone, manual processes, delays and lengthy fix cycles inevitably lead to infrequent releases and unnecessary stress at release time, often followed by days or weeks of post-release emergency patches. How can a business ever release features quickly and reliably under these circumstances?

Savvy companies know this and concentrate on being highly customer-focused, getting management to support that focus with a set of practices and goals that improve standardisation, reduce variability, and speed time to market.

These practices typically include facets of lean software development such as Agile, which maximises speed, efficiency and high-quality throughput, while slashing wait times and inefficiency. Many companies also have embraced some degree of automation into their software development and release pipelines. Smart organisations allow their development teams to blend automation into their product releases cycles. By doing this, their time is better spent on cross-team communications and resolving dependencies more effectively.

3. Break down the wall

One of the biggest pain points when transitioning to continuous delivery is breaking down cultural stereotypes between development and operations (e.g., developers hastily push things into production while operations people move slowly and block suggestions from developers). Take a positive approach. Try laying out the many benefits of continuous delivery that naturally make it easier for the two groups to work together.

First, with continuous delivery, deployment of new software versions across all target environments is fully automated. Self-service allows developers to provision new environments on the fly, avoiding lengthy handoffs to operations – a major time sink and source of tension.

Second, continuous delivery provides greater control and reduces risk. By breaking the software delivery process down into multiple stages, it enables IT teams to verify new features every step of the way, preventing errors from being pushed down the pipeline. Plus, operations can automatically enforce the controls they need to ensure compliance, capture audit trails, reduce production failures and security vulnerabilities, and mitigate risk across the pipeline.

Third, by automating the pipeline, continuous delivery severely reduces or eliminates miscommunication. It does so by creating a single source of updated release information, providing visibility into the flow of changes, and establishing a means to provide feedback throughout the process.

Finally, continuous delivery frees developers and operations people to focus on their most important tasks. Instead of maintaining outdated code or manually provisioning environments, both teams can spend more time doing creative work, possibly reducing technical-debt in the process.

All of these things help bridge the gap between development and operations and build end-to-end delivery teams. Less tension. No red tape. More time for creativity. What’s not to like?

Change that’s worth the results

Introducing continuous delivery into your enterprise will likely involve many changes, notably abandoning single-function jobs, and creating cross-functional teams focused on the needs of the customer. It will also involve a paradigm shift, especially among Dev and Ops people. But, done properly, your changes will result in better software delivered faster to the customer.

Edited for web by Cecilia Rehn.

The post Overcoming obstacles to continuous delivery appeared first on DevOps Online North America.

Instantaneous face to face teamwork isn’t always possible. Tightening travel budgets, awareness of the environmental impact of air miles and the increase of IT teams operating in globally dispersed markets mean that more companies are turning to video conferencing as an alternative to time-consuming and costly travel. Innovations in video conferencing now provide easy, simple group video chat – meaning proper group collaboration amongst IT teams. In an IT environment, collaboration can mean the difference between spotting a missing line of code, developing a patch together or creating an easier way to complete a process. The opportunities for team members to learn from each other are increased if people can see their colleagues and what they’re doing.

While it is the answer for many dispersed environments, the traditional video conference, cumbersome and difficult to scale in a work context, is in decline. There is an increase in research which shows its slow death: The dedicated system segment, the backbone of the video conferencing market, declined 6% in Q1 2016, and the global enterprise video market was down 4% in 2015 from 2014, dragged by PBX-based and dedicated systems.

Boosting productivity

The very technology which is meant to help boost productivity is what is slowing down collaboration. Clunky systems – which require time and effort to install downloads, fix errors and update software – are causing frustration among IT teams and users alike.

But the difficulties lie in the methods used, not the concept of video collaboration itself. In fact, Wainhouse Research found that 94% of employees say that group video conferencing results in higher efficiency and productivity, compared to other forms of communication. A Harvard Business Review study that looked at people’s habits on non-video conference calls highlights why productive teams are turning to video to collaborate. When teams collaborate over the phone, as opposed to the screen, 65% of respondents admitted multi-tasking, 44% sent text messages, and 43% checked social media sites. More shockingly, over a quarter (27%) of respondents have fallen asleep on a conference call! In contrast to this, video calls resulted in only 4% of respondents multitasking, according to another study referenced here.

Not only does video chat boost productivity, it also disseminates company culture across borders. If the culture is one of collaboration and inclusion, employees often embrace it with open arms. Video is one more way to break down the barriers that separate teammates geographically and bridge the gaps in communication that slow work down. Teamwork and collaboration, be it in person or over group video, allow for better brainstorming and problem-solving, contextual learning, and the bolstering of skill sets.

Supporting global teams

The modern methods for instant group video chat allow teams to make decisions faster, with less friction. It’s the virtual version of spinning your chair around to brainstorm an idea – but with colleagues who work across the room or across the globe. IT teams are in prime position to implement video chat in order to boost collaboration. This, in turn, should lead to more productive staff who can collectively solve problems quickly and are motivated in their jobs.

Clearly, the business case for modern, simple video chat is strong: managers will like to know calls are efficient and leading to optimised collaboration. Wasting time working through issues with old technology should be a thing of the past.

Edited for web by Cecilia Rehn.

The post Modern IT collaboration and the benefits of face to face time appeared first on DevOps Online North America.

Agile methodology is part of the mainstream in software development now. The business value is clear and the community, knowledge and tools have matured. More than 95% of respondents to VersionOne’s 10^th Annual State of Agile Report said their organisations practice agile and highlighted benefits such as faster product delivery, flexibility, and increased productivity.

Global outsourcing and the use of offshore teams is widespread. We’re talking about a market that was worth around US$90 billion in 2015, according to Accelerance. The ability to scale quickly, find the right expertise, and keep costs under control ensures that outsourcing is essential for many companies.

Both the agile and offshore trends have their obvious attractions, but bringing the two together can present a unique set of problems. Communication is such a key aspect of agile that distance between teams can be a tangible barrier. There are cultural differences and trust issues to deal with. However, it is possible to combine agile and offshore, if you adopt the right approach.

Open lines of communication

Agile enables faster development partly because it cuts out unnecessary bureaucracy and encourages daily conversations about the best way to proceed. The distributed nature of many modern development teams poses some definite problems. If your offshore team is on the other side of the world it may be difficult to promote effective communication.

There are a few ways to combat this issue, starting with some basic planning and consideration. Regular meetings are essential for agile development, but you must make sure that you schedule meetings for a time that works for both teams. If it’s the middle of the night for your offshore team, then that’s going to have a detrimental impact on their contribution.

Make sure that everyone uses a common Wiki, a forum, or another shared repository of collective wisdom. This enables team members internally and offshore to share knowledge, review the plans for the next sprint, and discuss issues or thoughts. You should also provide instant messaging and video conferencing tools. Audio calls are better than written communication, but there is still room for misinterpretation.

Face to face time is important

If people can actually see each other when they talk it really helps to develop the relationship and build trust. Set up the conference room for your regular meetings and test the technology ahead of time to avoid any frustrating delays or technical issues. Make sure that the person speaking can be seen by the other team and encourage employees to have face-to-face calls whenever possible.

There’s also no substitute for an actual physical visit. This is particularly important at the beginning of a project. Make sure you plan for site visits in both directions. Start with key team leads and have them spend time with the offshore team and vice versa to see exactly how things operate and establish one-to-one links with each other. Set aside some time during these visits for social activities that encourage long-lasting relationships and break down cultural barriers.

When your internal team and your offshore team understand what the other is doing and recognise them as people with their own personalities, instead of names on a list, they will work much more effectively together.

Learning is a two-way street

If you treat your offshore team like hired help, then you won’t get the benefit of their expertise and experience. Part of your decision to choose a specific offshore team was based on their skillset and the quality of their work on past projects. Remember that, although they’re assisting you with a specific project, they may also be able to offer useful insights and suggestions that could really benefit your company.

It’s also very important to ensure that the offshore team are able to make their voice heard. They should be participants in your regular meetings, not just observers. If they never ask questions, then you should be concerned. Make sure that participation is encouraged and even rewarded where appropriate. They should be properly valued and ideally treated as an extension of the company, rather than as a separate entity.

There are lots of other considerations to keep in mind when you employ agile and offshore strategies together, but these broad concepts should be in the forefront of your mind. For a successful, long-term partnership to work it must be mutually beneficial and laying the groundwork for effective communication is always a necessary prerequisite.

Written by Du Nguyen, Vice President of Delivery for KMS Technology, edited for web by Cecilia Rehn.

The post How to combine agile and offshore appeared first on DevOps Online North America.

Business simulations to aid IT training

GamingWorks designs, develops and deploys professional business simulations or serious games aimed at solving the issues describes above and supporting organisational learning and development. The ‘learning-by-doing’ solutions are used by a worldwide network of professional partners.

“The firm launched 15 years ago, with its business simulation for Apollo 13, allowing companies to get the most out of ITSM/ITIL training,” Schilt says. “We’ve grown, expanded globally and now offer 6 different scenarios from process management to cyber security, ITIL, and most recently DevOps.”

Business simulations are often customised to firms, to meet their learning objectives. Then, typically, 10-12 people join for a full day’s collaborative learning in a workshop, Schilt explains. The tasks start easy and get harder as the day goes on; ensuring team members challenge each other and themselves throughout the day.

Soft skills needed for DevOps professionals

There is a demand and necessity for soft skills amongst firms taking on a DevOps transformation.

“When you look at DevOps and its success/fail factors, it always comes back to people,” Schilt says. “It’s about communication, interaction, and continuous learning.”

These are skills, Schilt argues, that you cannot pick up in foundation classes where 20+ students passively sit and listen and come out with a diploma.

“All the success factors, communication and continuous learning etc. can only be learned through practice,” Schilt says. “Which is why it’s so great to get people together in a room, let them experience DevOps in practice – use communication skills, use Kanban, develop flow, actually do continuous learning. It makes a massive difference.”

Learning from past mistakes

There is a growing interest in simulation-based learning. Schilt believes it to be as a result of learning from past mistakes.

“I think the industry is learning from the days of ITIL implementation. It was a big drama for many organisations, where despite money being invested in traditional training and courses, it was hard to transfer knowledge into day-to-day work,” he says. “Now there’s an increased understanding of the importance of soft skills, and the different ways to develop these skills amongst team members.”

The Phoenix Project

GamingWorks’ DevOps simulation draws upon expertise from a familiar DevOps thought leader.

“Our simulation is based on Gene Kim’s The Phoenix Project, and we put people in the context of the book for a day,” Schilt says. “They get to live the project from start to beginning, and experience first hand the positives that DevOps can bring to a team project.”

Jan will be speaking on The Phoenix Simulation at the DevOps Enterprise Summit.

Written by Cecilia Rehn

The post Teaching the DevOps soft skills appeared first on DevOps Online North America.