Dilworth has more than 25 years’ of experience in the IT field, holding roles onshore and offshore within software, systems and network engineering. In 2012, when he returned back to the UK, he began to head up infrastructure and operations for Thomas Cook’s E-commerce Centre of Excellence.

“Here, as part of data centre consolidation, rationalisation and cloud strategy, I began to implement key technologies and ways of working that today form the mainstream of DevOps,” Dilworth explains.

“Following this, I perfected my work within DevOps at Sainsbury’s where I had the opportunity to deliver DevOps at scale and implement an AWS cloud first strategy as part of a major digital transformation programme.”

DevOps culture

Now working for Capgemini, he continues to evangelise DevOps within large-scale cloud migration and transformation programmes for the UK public sector. He has been engaged with the Home Office’s Immigration portfolio project and contributed to delivering a double award-winning large-scale AWS migration. Nevertheless, for him, DevOps is the catchall.

“DevOps is not a software development methodology. It is not a role or a job title, nor is it a team or a group name. Instead, DevOps is a culture which the whole organisation should be doing for it to succeed,” says Dilworth.

“Very often you see agile development working in isolation. Unfortunately, water – scrum – fall are very prevalent. Yet, with DevOps, it is all or nothing. However, you can implement aspects of DevOps to achieve pragmatic improvements in value streams and thereby demonstrate the worth of pursuing further improvements and rolling such initiatives out to the wider community.”

According to Dilworth, if an organisation is “really doing DevOps”, then all software testing is tightly integrated into the value stream.

Creating secure software

“We shift things left and we don’t wait until the product or service is ready for launch before starting security tests. From a delivery perspective, we build security testing into the continuous integration (CI) pipeline so that we can detect and fix issues early. It is much easier, faster and cheaper to fix problems at integration rather than in production,” he continues.

Furthermore, Dilworth advises to follow the following principles to create secure software:

• apply security measures per story
• encrypt at rest and in transit
• use SSO for offshore and onshore users’
• have a way of providing auditable information
• have authentication/authorisation between services
• enforce protected branches
• enforce reviews via pull requests
• require signed commits
• have a well defined, understood and enforced code review process
• ensure you have fast, repeatable deploys with automated testing
• monitor security advisories and patches.

To evangelise DevOps, as well as create and implement strategies to achieve DevOps at scale within the public sector, Dilworth believes it’s important to engage with leadership to describe and show, using key business metrics, for the art of the possible.

DevOps transformation

Dilworth adds: “Whole scale transformation to DevOps is not possible unless you can issue “Jeff Bezos style” mandates! Cultural change is very difficult, especially as many do not understand what DevOps or lean is.

“What we do in the public sector is to educate at the higher levels, and then attempt to scale by providing either shared services or centres of enablement which have been created by successful localised initiatives.

“In this way, you can make smaller incremental improvements in more manageable and controllable environments.  These can then be rolled out to larger communities. We aim to create self-service, commodity services that are easily and cheaply consumed and thereby demonstrate that doing the “right thing” has wider benefits.”

Dilworth also adds that, when creating key advisory relationships with senior clients and internal stakeholders don’t tell them you dislike their product or service; look for and communicate the positives of what the client is doing; always have a constructive message, or offering, to partner any criticism; help the client succeed; accept that sometimes you are wrong and respect clients’ delivery pressures!

Written by Leah Alger

The post Implementing strategies to achieve DevOps at scale appeared first on DevOps Online North America.

Prover of visual management platform for agile teams and organisations, Targetprocess, and software developing training firm, Net Objectives, announced its strategic partnership to enable both companies to provide integrated solutions uniquely tailored to mid-sized enterprises.

The post Targetprocess and Net Objectives announce strategic partnership appeared first on DevOps Online North America.

Since specialising in project management for more than ten years’ successfully using PRINCE2 waterfall methodology, in 2010 Jay transformed himself into a Cloud SME. He has held numerous cloud leadership roles at Vodafone, The Foreign Office, Rackspace and Three mobile. However, his passion is to blend cloud, data-based insights and automation using lean and agile to transform today’s enterprises into digital, continually innovating and disruptive, customer-driven organisations.

‘The digital way of life’

According to Gandhi, digital has completely revolutionised the way we live our lives, and this is the start of a journey that will undoubtedly increase in importance, impact and velocity as we further embrace the digital way of life.

“The range of products and services which can be ordered literally from the tips of our fingers is already staggering. From everyday items on Amazon, to food from Just Eat, to cleaners on HouseKeep.com – most of us already believe there are very few problems that cannot be solved by an app,” says Gandhi.

“Delivery times for many of these products and services has reduced significantly – not by a percentage improvement – but by a magnitude. For example, not so long ago Amazon Prime was game-changing by offering same-day delivery, but already, we have Amazon Prime Now, HomeRun and McDelivery all offering a within-the-hour service. It won’t be long before we have real-time delivery options.”

Innovation culture

Gandhi believes that, with almost zero effort required to exercise your freedom of choice, this is the final nail in the coffin for brand loyalty. Consumers may continue to do business with you for the long term but, only if your organisation continually meets the needs and exceeds expectations. For example, many of us regard Amazon.com as the default, go-to app for all consumer goods (perhaps as we believe scale implies the lowest prices) but the moment you perceive it to fail, you will without hesitation find an alternative.

So, how has so much progress been made in such a relatively short amount of time and why are we just at the start of this digital revolution?

“Many born-in-the-cloud organisations started life knowing they must delight their customers and the only way to achieve this was by continually innovating in order to meet the ever changing needs and expectations.

“This mindset has now been adopted by many traditional enterprise organisations – albeit with mixed success rates,” continues Gandhi.

Data insights

“Creating a culture of continuous innovation is super complex as it requires wholesale change across an organisation from leadership, governance, skills, expertise, creativity and autonomy to reward structure – but for now – we should focus on some of the key technical delivery ingredients such as methodology, insights, cloud, automation and how they complement one another.”

In order to continually meet the needs and expectations of customers (and even prospects), Gandhi advises businesses receive insights via data.

Gandhi adds: “We know insight is a hot topic but at a high level, it is not the volume, velocity or variety that you should obsess over. Instead, it is the relevancy of your data. Relevant data will allow your organisation to glean vital insights such as: what are key issues with your existing products? What improvements do customers want to see to existing products and services? And what new products and services would your customers (and prospects) like you to develop?

“If you have a healthy digital relationship with your customers and prospects, your business decisions will be guided based on evidence – this will help your organisation to become customer driven.”

Delivery methodology

There’s no doubt many of today’s organisations have successfully delivered projects/programmes using traditional waterfall methodologies e.g., PRINCE2 but as Gandhi described earlier, the needs and expectations of consumers today is all about choice, quickness, and low costs.

“In my previous life when I was a Project Manager for 10 years, I utilised waterfall to successfully delivering many complex projects, so I fully appreciate its merits. However, knowing the velocity of consumer demand, I can also see that a traditional waterfall model is simply not fit-for-purpose in terms of timescales, frequency, approach, techniques and quality,” comments Gandhi.

“It is analogous to using the old paper-based, London street map. Sure you can still use it today to navigate the streets but many people prefer a digital format which is, compact, kept up-to-date and through crowd-power can highlight the best route based on real-time traffic information.”

If waterfall is adopted to successfully deliver a new application/functionality but takes 3 months, then is it a failure? Gandhi believes consumers in an on-demand world expect things now, and if not, expect early sight (such as a beta release).

Adopting a lean approach

Gandhi continues: “Delivery times in the order of months is simply no longer feasible. Furthermore, in those 3 months, there is every chance the original needs to have either branched off, advanced or discontinued.

“Consumers nowadays would rather have an early release within days/weeks so they can ‘get a feel’ and provide early feedback rather than wait for the [perceived to be] finished product many weeks later. This implies a more lean approach is necessary where the bare minimum is implemented to prove a simple or part of the overall concept (aka Minimum Viable Product (MVP)).

“Adopting a lean approach focuses the stakeholders on proving the intended concept which reduces complexity and thus delivery timescales. The most important thing is to prove the concept as quickly as possible and obtain invaluable learnings as they help you determine whether you should progress or ‘pivot’ direction.”

Gandhi recommends that building in manageable chunks/iterations/cycles and using the learnings each time to steer you towards the target outcome is representative of today’s consumer habits and this delivery approach is called agile. Because lean and agile allow you to continuously deliver, your delivery teams can build momentum and confidence. Furthermore, not only can you close the gap in meeting consumer needs today, but also in the future as expectations change.

Cloud & automation

As Michael Dell once quoted “ideas are a commodity, delivery is not”. Delivery is a complex business comprising controlled cycles of build, measure and learn. The more the cycles the more you build momentum and learn.

“If lean and agile methodology enables continual innovation, then cloud infrastructure and automation, in turn, support the methodology. We all appreciate public IaaS clouds i.e., Amazon Web Services and Microsoft Azure are platforms comprising some very powerful tools but in this context, the key attributes required for developing in a Lean and Agile manner are choice, freedom and fairness,” Gandhi adds.

“Choice in terms of the countless programming languages, operating systems, database flavours and server a and storage specifications. Freedom to move between these tools at any time without lock-in and fairness, because public clouds only charge you for the resources you consume. Furthermore, build-measure-learn cycles can significantly improve in speed and quality if automation tools are used to support continuous integration, testing, configuration and deployment.”

Gandhi concludes that the success of your business rests in meeting the ever-changing and increasing needs of your customers. “Organisations which transform into digital, continually innovating, customer-driven businesses will positively disrupt (take market share away from their competitors) and thrive,” according to Gandhi.

He also notes that transforming an enterprise organisation will require a strong vision of the future supported by delivery methodologies and technology strategies.

Written by Leah Alger

The post Creating a culture of continuous innovation! appeared first on DevOps Online North America.

Many testing teams have managed to meet the demand for accelerated testing, but how many can claim that they’d be able to keep up high-quality standards in testing if the rate of development accelerated even further?

Accelerate with AI

Given the veracity and the pace of change, new technologies, advanced capabilities and more innovative methods, many QA teams are looking to AI in order to capitalise on the efficiencies it offers by way of speed, innovation, and accuracy.

In testing, the ability to blend human expertise with AI-powered insights has never been more important: it’s about using the best person or bot for the job in order to keep pace with testing and ensure quality. For example, QA teams can indicate the prioritised user journeys to test first before switching to an AI-powered test mode in order to test other journeys that they might not have even considered. These could be focusing on modules that have changed or exploring areas that have not received adequate test coverage. Teams can now also automate the capture and analysis of runtime performance data and enable the testing process to “learn” where potential bottlenecks are in order to eradicate them.

AI is also enhancing application discovery capabilities. This means testing can now automatically build a GUI interaction model by routinely learning about the elements that compose an application screen. Companies can then use this information to automatically populate the automation logic in an application model.

Simplifying performance testing and device labs

In the past few years, we’ve seen subtle but critical improvements in load and performance testing products that teams should look to take on in order to keep pace as DevOps influences development, product and service delivery.

Performance testing is often a black art that requires specialist skills to set up. However, now techniques have evolved that allows test teams to scale up the load from the functional tests they have developed. Intelligent frameworks that can multiply the load from functional tests to create realistic load tests, put performance testing capabilities into the mainstream.

Similarly, testing the breadth and scale across a matrix of different devices, operating systems and browsers can now be simplified. Testers now have the ability to create a scalable ‘device lab’ that virtualises and manages thousands of devices, each with different OS and software combinations that can be run against different test cases and user types. The idea is that a test can be developed once and then run against a matrix of different real scenarios. And multiple tests can be cued up and multiplexed intelligently against this device lab.

Maximising the Team

The days of only looking at “does the code work” are in the rear-view mirror. Now more than ever it is vital businesses are measured by software delivering positive business outcomes and delighting customers. At the same time, the team are under cost pressure to deliver more with less in an ever-shortening time window. They must take advantage of automation while maintaining essential human influence where it makes sense in order to optimise testing.

By using AI, intelligent performance testing and device labs to test the digital experience, testing teams can keep the pace of DevOps, and improve time to market and customer satisfaction. This is without losing sight of the bigger picture, which is helping the business to understand and test the user journey and gain valuable insight into the entire user experience.

Written by John Bates, CEO at Eggplant

The post Keeping pace with DevOps: How testing teams can deliver appeared first on DevOps Online North America.

Flexera advises customers to move towards a more agile, software-driven business model by following these four steps:

1. Package your products for different customer needs using a flexible monetisation and entitlement management technology.
2. Offer different product packages at appropriate price points for different market segments.
3. Provide value-related pricing that enables your customers to start small and scale up as they grow.
4. Create up-sell and cross-sell opportunities for features and add-ons.

Flexera wrote in its Smart Manufacturing White Paper: “Differentiating products by enabling or disabling features through software enables producers to offer product agility so far unknown to the market.

“This can be in the form of producing fewer physical parts (and configuring package features via efficient licensing solutions) and rebalancing features between devices almost instantly.

“Instead of manufacturing dozens of different models of a product at significant manufacturing costs, an IoT company can use secure digital monetisation capabilities to reduce the number of physical product lines, using software to create different versions.

“Software on the SCADA/HMI level is being used to enable and disable features on controllers, managing hardware functionality on a device level.”

These tips can help manufacturers to rebalance features between devices almost instantly, as well as enables business model flexibility as high-value features can be monetised separately.

Written by Leah Alger

The post Flexera: Get lean and offer the right product at the right price point appeared first on DevOps Online North America.

When several offshore software development companies offer the same services at competitive prices, businesses often face a dilemma of choosing the right provider.

3 Factors that need to be considered while negotiating offshore software development rates include:

• Experience: You should consider the outsourcing team’s experience in the desired technologies and platforms that you want them to work on and ask for a portfolio of past projects to understand its complexities. A highly experienced team may require slightly higher development costs but can help reduce development time and offer quality-centric services.
• Team size: Defining your software development requirements accurately helps estimate the required team size for the project, so you should look for an offshore development company that allocates a project manager along with the dedicated resources.
• Development methodology: Agile, lean, DevOps and waterfall are some of the development methodologies used by software development companies – among these, agile and DevOps have gained popularity owing to its flexibility.

Different forms of agile methodology also include scrum, crystal, and feature-driven development methodology.

Written from press release by Leah Alger

The post Report advises 3 factors to consider when negotiating offshore appeared first on DevOps Online North America.

In the last four years, we have seen a fantastic shift in ability for companies to innovate thanks to what has been aptly called “DevOps.” Drastically oversimplifying it, DevOps is the unification of the operations and development groups inside of an organisation; leveraging culture, automation, lean, measurement, and sharing (CALMS) to rapidly accelerate software from development to productionUsing DevOps to develop products

Companies like eRetail startup Etsy have used DevOps to rapidly develop their products and capture huge market share; likewise, DevOps has brought light speed agility to established giants such as Amazon, Apple, Facebook, and Fidelity to be able to deploy thousands of times a day. In the face of such demonstrable results, it is uncertain how companies that aim to compete in the marketplace can do so without embracing DevOps.

“DevOps is a human problem.”

Since software rules the world, we tend to look to software to improve our situation. Software has allowed us to automate, measure, and lean “all the things” to achieve some amazing results.

Yet everyday companies seem to be waking up to the realisation that software alone isn’t enough. Just a simple search of “DevOps failures”, limited to this month’s results, provides several pages of new listings. It seems that these companies are just late to learn what Patrick Debois discovered near the beginning of the DevOps movement: “DevOps is a human problem.”

Fittingly, the IT Revolution Press bookends the DevOps acronym of core principles with two people-centric items: culture and sharing. But, even some of those models that put people first are among those who have failed. So then, what is the missing ingredient that hinders IBM’s success with DevOps and enables the Etsy’s? It seems to all revert back to a company’s leadership style.

Servent leadership

In reading numerous interviews of some of the most widely acknowledged DevOps experts, there’s a recurring pattern: servant leadership. Ken Blanchard breaks down servant leadership into the roles of servant, steward, and shepherd:

• The servant seeks to meet the needs of others
• The steward takes great care and consideration of what has been entrusted to them
• The shepherd protects, guides, and nurtures those under their sphere of influence

In the preface of The DevOps Handbook, Jez Humble, Gene Kim, Patrick Debois, and John Willis give brief interviews as to how they got involved with DevOps. The common theme among their interviews was that they saw their peers struggling and felt compelled to find a better way to help their community.

This required many years of swimming upstream against a long-established IT culture of anti-patterns rewarding fiefdoms, silos, and lone wolves. For those of us who have been in the industry any real length of time, we have either been participants or victims of this culture – or perhaps both.

The idea of servant leadership necessarily precedes culture. While culture is the result of group action and thinking, and each of the aforementioned pioneers had to initially go it alone. Such was their isolation, that in their brief interviews, each of them noted the moment when they encountered like-minded individuals.

This is a common missing component across the technology-sphere, whether DevOps is your priority or not.

One cannot simply list “Servant Leadership” as a core value in the employee handbook and reap the rewards in a few quarters. To truly get your organisations to go against the current, begin to openly collaborate and share, and work to a common business objective; you are going to have to rely on individuals that are driven by interest in a greater purpose. Even if this requires a transplant.

But, it is not enough just to have servant leaders in the lower ranks.  With top-level servant leaders in place, your front-line servant leaders will have the support they need to continue to face cultural adversity for the sake of everyone under their watch.

Fortunately, this is a priority that can be taught, but it must be taught by example. When company leadership at the top prioritises on serving others, they can help focus mid-managers’ efforts in that direction as well. This creates a culture of “none of us is greater than all of us”, which is the ideal climate for generating servant leaders.

In building upon “the shoulders of giants”, DevOps teams can iterate faster, toward better results than they could have if any one expert had been working on it individually. Building a culture of shared successes then attracts other servant leaders, and the potential for explosive innovation is limitless.

Edited for web by Jordan Platt.

The post DevOps programmes require servant leaders appeared first on DevOps Online North America.

Agile, DevOps and testing skills

The programme begins with 14 weeks of fast-track training, followed by placements within all the major technology teams. Four learning streams will cover software engineering, software engineer in test, DevOps and test engineer, as well as covering a variety of topics in agile, lean, business skills, databases, scalability and software testing.

Graduates will also learn to code Ruby and JavaScript.

Matt Hughan, Head of Recruitment at Sky Betting & Gaming, said; “We’re committed to the North and have been able to recruit at record rates here. By offering such high quality placements, we’ve not only been able to hold on to home grown graduates from our local universities, but also to attract those from further afield.”

The programme will last for 12 months and graduates will learn about Sky Betting & Gaming’s lean and agile methodologies and improve their general business skills.

Promoting tech talent in Yorkshire

A significant 17 – or just under 70% – of the graduates came from universities in Yorkshire, including Hull University, Leeds Beckett University, Leeds University, Sheffield University, Sheffield Hallam University and Bradford University.

Andy Burton, Sky Betting & Gaming’s CTO said:  “I’m delighted that our software academy has now launched. Like many other tech companies in the region we are finding recruiting the right people increasingly difficult. By investing in graduates now we hope to play our part in ensuring there’s a pipeline of tech talent in Yorkshire. I look forward to welcoming the first grads in the summer.”

Edited from press release by Cecilia Rehn.

The post Sky Betting & Gaming launches new Software Academy appeared first on DevOps Online North America.