Posts Tagged ‘development’
This is the second part in a 2-part series. Read part 1.
In my last post I gave an overview of how we started the process of changing the way we do agile development at LeaseWeb by setting goals, engaging our engineering teams, and developing a maturity model to get everyone working to the same standard. In this post I’m going to talk about how we set up our scrum teams, how we get all levels of the business involved in the development process, and how we calculate the cost to provide the most value for the company.
Our current Scrum teams are set up as follows:
- Product Owner – defines the priorities of the team; responsible for the order in which features are built.
- Scrum Master – in charge of the scrum process (coach): making sure the team does retrospectives, sprint planning, refinement, coordinating meetings.
- DevOps – Development and Operations in one team of about 5-8 people.
Last year, we merged our existing operations and development departments into one Product Engineering department. Since then we have been focusing a lot on coaching all 13 teams and improving their effectiveness
In october last year, we attended an excellent talk by Bol.com at Velocity Amsterdam. In this talk they explained their ongoing transition towards DevOps. One of the concepts they introduced, was a maturity model to measure and incentivise continuous improvements within a team.
Inspired by the Bol.com talk, we have since developed and implemented a maturity model within our Product Engineering organization which consists of a matrix of four levels in four categories.
In this 2-part mini-series, Joshua Hoffman examines some of the common issues companies face when designing for scalability. Read part 1 here.
In my previous blog I looked at what I call the first three sins of web scale – pride (the refusal to use tools not invented here), envy (the desire for a more exciting project) and gluttony (ignoring scope and capacity). Today I’ll discuss the other four sins you need to be aware of when building and deploying your app or product. So without further ado, let’s check them out.
Throughout my career I’ve had the opportunity to work at a variety of different companies both large and small. They each had their own set of unique challenges regarding growth but one thing I noticed with time and experience was that the solutions to the problems they faced were not specific to the company itself. The approaches that were taken and the lessons that were learned could be extrapolated and applied to many of the situations facing a company looking to expand and grow technically.
There is a concept in some religions that before you save a sinner you have to tell them how they have sinned. In other words, if someone doesn’t know what the problem is they won’t be able to change. For a company just starting out, there are no wrong ways to build and deploy your app or product. Once you begin to grow however, you realize there are things you didn’t know and that some or all of the decisions that you made at the beginning were mistakes. This is the point where you need to decide how to address these issues. New companies are started all the time so I decided to draw from my experience to put together what I call the Seven Deadly Sins of Web Scale using seven real world examples from my career.
It’s no secret that LeaseWeb heavily relies on automation to manage the large network of services that we offer. Over the last five years, we have been investing a lot in our internal systems and our strategy has been to have them communicate via APIs (specifically web services).