There is a technique, initially introduced by the Extreme Programming movement, which consists in adding an element to the product backlog that we call a “spike.” The team agrees on a limit of time to be invested in this item. The goal is to acquire the knowledge necessary to reduce the risk, understand a requirement, or improve accuracy when estimating another backlog item.
There are two types of spikes: technical and functional. Functional spikes mainly help to better understand a required behaviour of the application in order to be able to break it down more efficiently or simply to acquire the tools necessary to make better implementation decisions. Technical spikes help to better understand the technology in order to determine the feasibility and impact of certain implementations that need to be done.
Spikes are used in different situations:
- To analyze the affected behaviour to better break down the tasks and make estimates more easily;
- To analyze the feasibility and determine the viability of the backlog’s bigger items (Epics);
- To conduct basic research to be more familiar with a new technology or a new line of business;
- To acquire confidence in an approach (technical or functional) to reduce the risk or uncertainty.
It is important to note that a spike needs to concern itself only with the problem in question and must ignore any other point of uncertainty. That is why the resulting code is rarely kept in the final sources of the software; you must keep in mind that it is an ephemeral code that will probably end up in the garbage.
Design in columns, not in layers
Focusing only on the minimum required for each feature to be implemented does not necessarily mean that the application’s design will remain minimal.
However, it is necessary to change the way the infrastructure is built. The traditional developer’s reflex is to design in layers, with one layer for the database, one to access the data, one for the business logic, and one to show this data.
With Emergent Design, the architecture needs to be built little by little with each sprint. We will thus be able to test a link from the database layer all the way to the presentation layer with the first sprint. This way, the team can test all levels of the infrastructure very early on and implement full features without having to wait for all involved parties to complete their parts.
Therefore, it is essential to have a structure that includes all the layers from the beginning, but it needs to be constantly defined and modified throughout the development process that is conducted one small step at a time. Each of these steps is a chance to remain at the leading edge of technology (both in terms of the infrastructure and of user experience) without suffering great repercussions in the event that the choice agreed upon was not the right one.
The role of the Agile Designer (Architect)
Seeing how the design can be built vertically, we understand that the designer’s role is different in an Agile mode. Instead of managing technical decisions, he needs to act as an expert or a mentor that accompanies the team in a development that will meet the requirements.
The designer does not only have the role of a coach; he also remains responsible for defining and maintaining the solution’s structure. His role can be split into five parts:
Understanding the requirements
Since he is generally more experienced, the designer must master analysis of the requirements to be able to take part in the product development strategy, while making sure to remove all the elements that can impact the design’s definition.
Formulating the design
His expertise also allows him to have a global vision of the solution to ensure that the defined structure will not unnecessarily increase complexity. Working collaboratively with the Product Owner, he can then maintain a balance between the solution’s objectives and constraints.
Communicating the design
He also has to make sure that everyone understands the structure correctly, regardless of the level of experience and knowledge. Everyone can have a different point of view. Therefore the designer has to make sure to present several facets of the system to adapt the information according to the type of public of the different teams.
Supporting the developers
It is important to have a well-defined structure, but it must also be achievable. So the designer must act as a mentor and be directly involved in the development so as to be quickly informed of the obstacles and assist members of the team in overcoming them.
Verifying implementation
As soon as the first version of the software is delivered, the designer monitors the technology of what has been programmed. He has to verify that the delivered code is coherent with the communicated design and that it respects the requirements supported by the added features.
These roles need to be changed as the project advances. In fact, it is the designer’s focus that needs to change according to the maturity level of each part of the system design. The designer can therefore assume several roles and his workload can often be shared between different members of the team to avoid having only one source of information.
Everyone changes with time. When sharing the different tasks, preferences and skills evolve and certain people can then be more motivated by the possibility of taking care of certain parts of the system’s evolution. For example, someone that has more ease communicating concepts to business people can take part in the strategy, while someone else with deep technological knowledge can get more involved in creating and communicating the design to the team.
Accepting change
In an Agile mode, the designer is the main person responsible for changes and for managing the complexity they bring, whereas other developers focus more on the next version.
Naturally, in a complex system we can’t let anyone make changes at any time. Similarly, it would be illogical to let any family member destroy any wall of the house.
There are three main dangers when we have too much ease accepting change:
- Scrapping and wasting features because requirement changes are too frequent and unstable;
- Loss of global system stability, as if the whole building was collapsing;
- Increase in complexity, since changes are made without abstracting any level of the concept. We then loose the ease that allows us to reuse or to conduct a quicker refactoring of the existing code.
By maintaining a balance in the management of changes that impact the team, the designer acts as the champion of the solution and has the responsibility to maintain this role. He needs to properly sell his vision to all people, whether they are internal or external to the project, so that everyone understands how everything that is in place satisfies each one of the requirements and why changes are undertaken in that direction.
A few tips
For an efficient Emergent Design:
- Use practises, design patterns, and principles that are common to all team members;
- Use refactoring to make sure that complexity and quality stay at acceptable levels;
- Test early, often, and automatically;
- Implement Application Lifecycle Management (if you are using Team Foundation Server, Done Techo offers an interesting advantage for Agile management of the work to be done);
- Make frequent deployments.
Don’t forget! It is the first steps that require adaptation. Afterwards, the walk becomes easier and easier, to the point where you can eventually start running.
Enjoy your development!
Make an appointment with our team to discuss it!
Look at our other divisions Pyxis