We have embarked on a programme to more formally introduce Scrum into BBD. Scrum is one of the cornerstones of Agile Software Development.
This year ATC have formally run the Scrum Master and Product Owner Certification Training Courses and attendance has been good. Numerous BBD staff members have their Scrum qualifications now and well done to those. The feedback we have received is positive, but there are some questions about the adoption of Scrum within BBD such as:
Is BBD now saying that we should do Scrum; how will Scrum work for my project? Is BBD Agile when we don’t use Scrum?
This article aims to answer some of these questions, but let’s start with a couple of statements:
BBD as a business, and its teams, is generally very Agile and we have been using various agile principles to a greater or lesser extent since BBD started, even before the term was coined. Your team does not automatically become Agile just because you use Scrum.
In order to explain we need to first understand what Agile actually is. In contrast to popular belief, Agile is not a methodology, framework or even toolset. In fact, Agility is defined as the ability to change direction whilst moving at speed. Agile is a mind-set entrenched in a set of values motivated by people, communication, quality and change. There is value in periodically revisiting the Agile Manifesto (https://www.agilemanifesto.org/) to re-affirm these values. Understanding that the values and associated principles are not rules, but really good guidelines based on practical experiences that are proven to work, and should be treated as such.
There have been many frameworks invented that define a set of processes that teams can follow, that fall under the agile umbrella. These include frameworks such as eXtreme Programming (XP), Kanban, the Dynamic Systems Development Method (DSDM), Disciplined Agile Delivery (DAD), and the list goes on…
But it’s the essence of Agile that’s more important than the frameworks or processes being followed.
At BBD we pride ourselves on getting complex software development projects done, and have a great track record of doing this. However, we don’t enforce a single software development method. There are a few frameworks we use, but these are not enforced, we don’t use specific processes, and each unit runs autonomously with very little central control or standardisation.
Given that there is no template for success how do we continue to deliver complex software projects?
Popular belief is that the magic ingredient is the people who work at BBD, and this is very true, but what do we look for in our people and what do they value in software development projects? If we dig a little deeper into the Agile Principles, we start to see an alignment with the BBD principles and behaviours. Agile Manifesto has 12 Principles (www.agilemanifesto.org/principles.html) and we have commented on them from a BBD perspective:
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. At BBD, we are not just coders, we are software engineers that understand the business value of the software we develop, and strive to get it into the client’s production environment as quickly as possible.
Principle 2: We welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. At BBD, we are not slaves to the requirements, but we also understand that requirements should not be ignored. As we understand the solution and the business, we can often change direction quickly and suggest improvements.
Principle 3: We deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. At BBD, working software is what drives us, we aim to demo working software as early as possible to our clients and get feedback.
Principle 4: Business people and developers must work together daily throughout the project. At BBD, we would like the business person on the project, or even better the actual client. Often we are based on our clients’ site or them on ours. If you are not in touch with the business you’re in trouble!
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. At BBD we start with the people as being the best, then add in the hardware and software needed, and a great environment. We give our teams the autonomy to get the job done, how they see fit, there is no one BBD way.
Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. At BBD, we encourage whiteboard sessions and design meetings, we have an open plan office, and encourage teams to talk shop over great coffee!
Principle 7: Working software is the primary measure of progress. At BBD, this is what we do best, we deliver… but this does not mean you can skip documentation, status reports and even timesheets…:)
Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. At BBD, we work hard, and play harder and look after our staff. Maintaining a sustainable pace is difficult, especially when you near the deadline!
Principle 9: Continuous attention to technical excellence and good design enhances agility. At BBD, you need to keep yourself updated on technology changes, and keep your skills honed, but this doesn’t mean you need to change languages/IDEs every two weeks to be a good developer, or to prove that you are on the cutting edge of technology.
Principle 10: Simplicity – the art of maximizing the amount of work not done, is essential. At BBD, this means write less code, write less specifications and focus on producing what is needed (the essence). It doesn’t mean import every framework you have ever heard of into your project.
Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams. At BBD, we give units the space to self-organise, it’s the way the company is designed (look up holonic organisational structure).
Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. At BBD, your team should continuously strive to improve the way they work. Everyone is expected to understand and question the status quo within units.
Teams at BBD relate to these principles, thus the answer to the question “Is BBD Agile?” is YES – right to the core. Does BBD follow specific agile methodologies like Scrum? Sometimes, but it depends on the particular team and client requirements, and when the team thinks and agrees that it will make sense.
So, after checking how we align with the Agile Manifesto, it is clear that we don’t have to be a slave to process and practices like Scrum to be Agile, but learning these practices is likely to be helpful, and is another tool in our ever-expanding toolbox of ways to build great software.
