There are three key areas of work activities needed to deliver a product:
- Discover something.
- Flexibly build it.
- Study what was built.
Here is an approach that I am using and adapting:
I would encourage you to experiment with it.
In this concept, all of these are important factors in building a quality product. Namely, right the first time, at the right price, and the right thing that our customers truly need.
There are certain mindsets and principles that support these, which are in the cloud shape in the middle to denote that they underpin everything. Activities to complete are in a circle to try to convey that they are not sequential, although some are more likely to be completed for certain key areas.
For example, shared coding style would likely be carried out when flexibly building your product. However, when you study what we built, there may be a need to change or update your shared code style.
This is not supposed to be an exhaustive list. Given your context, there could be others that you would want to include, or some that you would exclude. I am continuously refining this Agile Continuum as I learn more, experiment and adapt.
It is always important to iterate back over processes, practices, and concepts like this to understand if they are still working for you. If they are, then keep doing them. If there are improvements that you can make in order to optimise, then add them to your backlog for visibility and ownership to ensure they get implemented.
Retrospectives, even when not doing Scrum, are mandatory for me. They serve as a good way for the team to continuously inspect their processes, celebrate success, and adapt those that are not working to make them better.
Let’s explore what is contained within the Agile Continuum:
Cloud
To reflect the concepts of build, study, and discover, we need to have fast feedback loops. We can only do this if we are delivering incrementation pieces of product frequently.
The team cannot be expected to collectively complete on their iteration goals if code (the product) is not delivered until the second week of a two-week iteration. This does imply that more technical skills are needed to be able to test pieces of functionality without the whole being available.
The use of test harnesses, stubs, drivers, and service virtualisation becomes more important. This extends to testing APIs rather than waiting for the whole system to be ready.
The team as a whole is responsible for quality, so this needs to be reflected in the iteration planning to maintain a sustainable pace. After all, everyone has a role to play in quality delivery. From the business analyst creating testable requirements and the developer doing the unit testing, to the tester using the right coverage of tests based on product risk profiles.
Let’s look in more depth into some activities contained within the circle.
Circular activities
I am keen on pairing techniques which expand on XP’s pair programming. There are now collaborative tools available to support mob programming, which can be expanded to cover pair automation to automate repetitive checks and provide greater return on investment.
Others in the team, such as the busines analyst, can also become involved in automation by becoming the observer or navigator, reviewing each line of code as it is typed in. This may need some adaption of the process as the developer, the driver, may need to talk through what they have just coded as they write it, rather than the observer understanding the code directly.
Equally, testers could do this too. In pair programming, the two programmers switch roles frequently, but this could be achieved by others in the team that assume the observer role.
An early way to get feedback is by modelling the proposed solution(s), leaving the decision to the last possible moment. The use of mock-ups and prototypes can be trialled with a variety of different users to get fast feedback from real customers, even before requirements have been written.
This is the most cost effective way to firm up idea concepts and reject those that are not going to be commercially viable. Observing how customers interact with, learn to use your product, and how efficiently they complete their customer journey, all give valuable insights into your UX, accessibility, and solution design.
Tailoring your Agile implementation
We have explored a couple of examples from the diagram, but what does that mean for our implementation of Agile?
The power of business agility is that you can adapt it and make it your own. The challenge is that same flexibility means you can also get it very wrong as well.
Agile’s simplicity, referenced in four manifesto statements and twelve principles, is also its complexity.
If your team stays true to these values, the implementation of your process, practice, and frameworks can fit your organisation, environment, and even provide autonomy for your teams within certain scalable company constraints. Several of the methodologies have similar practices for this very reason.
The key is to focus on delivering value to your customers – the right product, right quality, right time, and right cost. If you chose to use a particular framework, such as Scrum, then I recommend that you should implement it, at least in the first instance, as stated.
Do several Sprints before you decide to make changes so the processes/practices become a habit. However, how you conduct the testing should be up to the team.
I would advise that you pick one item at a time to experiment with and do that long enough to understand whether it works for your team or not.
There are some testing fundamentals that apply, regardless of your methodology:
- Build quality in, not test it out.
- Use testing techniques to identify coverage.
- Focus on testing product risk to reduce residual risk.
- Use lightweight test planning that updates as you learn more.
- Make the whole team responsible for quality and not just the testers.
- Start test execution on day two. This should be discussed with the developers at iteration planning to ensure they are releasing at least daily.
- Automate as much as possible, where there is return on investment, and as early as you can (test first approaches), particularly unit testing, APIs, and services.
Different frameworks have differing benefits, so it is important that the team talks about which will be best suited to the way they want to work with each other, and within the wider organisational teams.
Accelerate your quality
Today’s world is more connected and reliant on technology than ever before. This means product quality is of critical importance so that your customers get the experience that they want and need.
Get the quality right and they will come but get it wrong and they will quickly leave. However, this is not easy or something that can be achieved overnight.
Guided by good Agile practices, it is possible to speed up delivery while enhancing quality. Find out how you too can unlock the benefits of business agility for accelerated quality.