Businesses are made from the hard-earned money of shareholders and the easily-spent time of the people that work in them. Both are too valuable to waste by repeating the mistakes of the past, accepting inefficiencies, or holding back from changing things for the better.
The world is changing at an ever-faster rate. The technologies and businesses that are changing the world now do not look like those of five years ago, and the only way to avoid obsolescence is to take every opportunity to learn.
Failures are an opportunity to learn; more on that later. We hold weekly retrospectives to learn from the team’s activities and tweak our processes. We encourage engineers to read the latest tech news whilst they’re waiting for tests to complete. The whole team owns their team process, and is equally responsible for improving it. Pair-programming provides immediate feedback to engineers, and helps spread expertise amongst the team.
The only true failure is a failure to learn. If failures are swept under the carpet then vital information that could inform improvements is lost; and so it is critical that members of the team are not afraid to admit when something has gone wrong.
When a technical problem occurs, we get to the bottom of it and make sure it doesn’t happen again through engineering and automation. When there is a problem with a team or a process, we discuss it in one of our regular retrospectives, and make an action to try and improve it.
A problem can only be fixed if it is acknowledged. We do not keep quiet when we see something that is not right, be that a technical problem, an issue with process, personal conduct, or anything else.
Do we do our best work after working for eight hours already? No. We don’t do anything other than our best work, all day. Overtime and ‘crunch’ before deadlines are symptoms of poor planning or poor resourcing, and as such that information should be exposed to those responsible for those functions and acted upon.
Each team is responsible for its own decisions as its members are the ones with the most contextual knowledge of the issues at hand. We do not enforce standards, and instead imbue values, foster communication and facilitate cross-pollination of ideas. This divergence allows each team to progress unimpeded, creates more opportunities for learning, and allows the best ideas to be harvested and shared.
We pair in-person every day. We have stand-ups in person. We co-locate, and when that isn’t possible we use remote-pairing technology and video links.
Humans have evolved a host of responses based on the immediacy of contact with other humans, which ensure that antisocial behaviour is inhibited. The breadth of human body language communicates intent much more richly than electronic media, reducing the likelihood of misunderstanding or building resentment. Lone workers behind the facade of email invite a culture of passive-aggressive mistrust.
Diverse teams have diverse strengths. Team members are respected for their attitude, their effort, and their technical ability. We learn from the baggage and past mistakes of the IT industry: we do not inherit it.
We work from a linear backlog that is regularly prioritised by the Product Owner with feedback from the engineering team. Engineers only ever pick stories from the top of backlog, ensuring that they are always working on the most valuable deliverable.
Engineers always “develop in the now” and do the simplest thing that works given the current constraints. We don’t engineer for requirements that might be important in the future - if they’re important, we’ll get to them soon enough and tackle them while they’re in the present.
Because we’re always working on the most important thing, and achieving it in the simplest way that works, you can have confidence that we’re not wasting your time. This is the basis of a key contract of trust between the engineering team and the Product Owner.
We practice behaviour-driven development and test-first development so that we have utmost confidence that we are delivering working software that satisfies customers’ needs. We do not take any shortcuts which would mean that we have reduced confidence in the efficacy of our solutions. It either gets done properly, or not at all.
We will use our experience to give an indication if a goal is achievable within a timeframe, and work with 100% commitment to make that happen. Given that we will always be taking the simplest route to the most important features, production solutions will be delivered as soon as possible.
As we do not compromise on quality, the remaining factors that affect how long a task takes are the complexity of the desired solution and the number of resources committed. The calendar has an impact on neither. We cannot predict the future, and it would be dishonest to pretend that we could.
We estimate stories based on their complexity, and over a period of weeks and months gain data on how much complexity a team has processed. This gives an indication as to how much complexity the team can process in future.
If an engineer has repeated a task often enough to be able to accurately estimate the amount of time required to do it again, then the task should already have been automated or a re-usable solution delivered.
We use the term test-first development to highlight the belief that purely test-driven development in a large distributed system can lead to emergent architecture which can be costly to move away from. We do enough up-front design to avoid ‘coding ourselves into a corner’, but not at the cost of delivering features.
The technical solutions at the beginning of a product’s life are unlikely to stay the most suitable forever. Engineers keep a track of ‘pain points’ in the code, and have the authority and responsibility to address these in order to maintain the team’s velocity. The scheduling of tasks to address technical debt is a result of a relationship of trust and communication between the engineers and the Product Owner.
If it can be automated, it will be. There is no time for a manual procedure when production systems have gone down during peak hours.
All the engineers own all the code, and all the team own their tools and process. With this ownership comes a greater sense of investment and job satisfaction, and reduces the risk of human single-points-of-failure.
We specialise in making Cloud Foundry operable in your organisation. Our aim is to get you from code to user feedback as fast as possible.
Our process is driven by a clear set of principles and practices, built from complementary elements of eXtreme Programming, Kanban and Lean.