I recently had the opportunity to act as an observer during a Phoenix Project Game at the Headquarters of The Royal Society for the Protection of Birds (RSPB) in Sandy. I've wanted to observe a Phoenix Project Game (TPP) for a while now and this was a the perfect opportunity to do so. On top of that, I got to see Sandy's beautiful surroundings.Read More
Ranger4 DevOps Blog
Most of you with a passing interest in football will have heard of Lincoln City FC in recent weeks, we are the media darlings right now, well more specifically two former school teacher’s Danny Cowley and his Brother Nicky our Managers are. I’ll come back to Danny and Nicky in a moment.Read More
Last week, there was a pleasant change in my day as I had an opportunity to participate in a Ranger4 Public Schedule DevOps Foundation Course along with a bunch of customers and one of our new trainers from Portugal.
I don't have an IT background but just over three months ago I joined Ranger4 and have responsibility for marketing, so it's my job to communicate everything that's good, bad and sometimes a bit ugly about DevOps to the world - so I'm on a steep learning curve and loving it! My understanding of DevOps so far has developed from reading, following DevOps related news and watching DevOps related videos. What I really wanted to do is to sit in a room with IT developers and operations professionals, and get an understand of what their view on DevOps is, the kind of daily problems they face and how DevOps could provide them the solutions they are looking for. So I relished this opportunity to attend some real-life training!
In short, DevOps is a cultural and professional movement that stresses communication, collaboration and integration between software developers and operations departments. Its core values are Culture, Automation, Lean, Measurement and Sharing (CALMS).Read More
Big news for one of our key partners this week, as Atlassian announced their aquisition of project management service Trello. The deal is expected to close before March 31, 2017 subject to all that legal stuff. Of the $425 million price tag, $360 million is cash with the remainder in Atlassian restricted shares.Read More
Welcome back! We hope everyone's had a wonderful festive break and is fired up to make the most of 2017 whatever excitement and craziness the year ahead is going to throw at us. We're looking forward to helping our customers new and old continue to tread the DevOps path to make our lives (and software!) better, faster and safer. Here are 7 things we're expecting to be working on to that end in the coming year:Read More
It's the Ranger4's #DevOpsFriday5 series and this week's answers are courtesy of Chris Prowse. He's DevOpstastic!
1) How would you describe the relationship between DevOps, Agile and ITIL?
DevOps and Agile, despite common misunderstandings, are not inextricably linked; I’ve worked on more traditional projects that have still seen significant benefits from adopting DevOps thinking. However, they’re incredibly complimentary in the way that they work.
Traditionally, we saw the Business, Development and Operations all working in silos. This meant that requirements were sent from the Business into the Development teams, where they were interpreted (often incorrectly), but didn’t reappear again until the end of the project when they were given back to the Business as a product that may or may not satisfy the Business’ needs. It was often at this point that the Operations team got sight for the first time of the product too; meaning they had a battle to deploy and support something new.
Agile thinking brings the Development and Business teams closer together, using regular feedback and engagement to keep the product in-line with the Business’ expectations, and ultimately delivers something that is useful to the Business. Throughput is therefore faster; but the Operations team are often still the last to see the product, and face similar challenges.Read More
Last month Gartner released their 2016 Magic Quadrant for Application Performance Management and for the 7th consecutive year running, Dynatrace were listed as a leader with the highest ability to execute.Read More
Processes and People
This is the last blog of a 3 part series on Agile Service Management (ASM).
Processes are ways of working that allow someone or thing to let someone or thing get what they want. A supplier gets a request, some steps are performed and an outcome is achieved. It could be to fulfil a request or to pass data from one application to another, it all involves a process (es). Simple! Then why is it that many of our processes are so hard to complete, or are changed without consideration of the effects or are just simply ignored for the way someone thinks it should be done?
Maybe it is because our processes are not people centric. By people I am talking about the people that do them, create them and receive the outcome. Processes are not created by automation. Automation enables a process. So let’s get the people that want something and the people that need to provide that outcome together!
In my recent blog on Agile Service Management we discussed how blending the concepts of faster (Agile) with safer (ITSM) could lead to processes that enable an organisation to use technology to remove obstacles or enable goals. This is the second of a 3 part series on Agile Service Management (ASM).
It is a mindset that stops us from thinking in this way though. Agile is always thought of creating or innovating and ITSM is thought about in terms of inflexible processes or tools that no one else can use.
So I want to say straight off: THIS IS NOT TRUE!
This is the first of a 3 part series on Agile Service Management (ASM).
IT Service Management (ITSM) has been around for almost 27 years: the capability of taking a process, creating a high-level view by collaborating with others and then iteratively introducing each step until fully introduced. For me, a process is a way of work: buying something, onboarding a new employee, resolving an incident are all examples. What we missed was someone to then continue the process as part of their job; an accountable person. Yes, I know that we had many roles defined but, in my experience, once a process was defined, the review and improvement of that process in short, iterative timeframes rarely occurred.
Therein we missed a trick. We should have treated the creation of a process with the same mindset that we use to create products based on various agile techniques. We should have created a way of ensuring these questions were always being addressed:Read More