The challenge
Imagine building a house in the following fashion: you start building the house from one room, for example from the bedroom. You start erecting the room walls, decide its dimensions, interior design, and furnishing. Perhaps while building the bedroom you consider other rooms as well; you have preliminary ideas for the kitchen, the lounge, the bathroom, and so on. What’s missing?
What is missing is the fundamental architecture and functionality of the overall house; what type of residence is it intended to be? A loft, a cottage, a mansion, something else? What type of foundation needs to support it? What materials should constitute its roof and exterior walls? Who are the intended residents?
The challenge with agile methods regarding service design and secure design
Building a software product or service using the agile philosophy encourages implementing features quickly, with an expectation and pressure to deliver visible progress to stakeholders. Often, agile projects tend to sprint from the start – and keep sprinting – without enough attention as to what should be the appropriate starting point for the whole project. Jumping straight into the agile process is like building a house without its fundamental blueprint.
In many agile process models, the user-centric approach and service design philosophy are not written explicitly in the model. This omits the whole process of defining the service’s purpose in a user-centric way, or it is too vaguely described to be of actual use for the day-to-day production work. On the other hand, the lean start-up methodology isn’t well suited to large-scale organisations or complex service ecosystems.
Likewise, in many agile process models, secure design is not written explicitly in the model. Secure design involves design considerations for ensuring that the security and privacy aspects of the delivered service or product, and the associated user experience, have been taken into consideration from the beginning. A secure design aims to be self-protective and trustworthy.
Design debt
Still, with even the leanest service creation, some kind of discretion and direction is required to elucidate the preliminary problem statement for the design. We like to call this phase envisioning. The bigger the picture, the more upfront study and understanding is required of users’ needs and their context of use.
If the envisioning phase is not done properly (and keeping the users in mind), the result may be a service creation process that is very agile and productive in letter but not in spirit; a process that actually fails to deliver any real value to the organization or its customers and users, and with security and privacy design deficiencies. If guidelines for prioritising the backlog are unclear, rapid arbitrary changes of focus and, changes to which feature preferences to implement may occur. Managing the service roadmap becomes unwieldy. The aimed for customer value may be hazy or not based on actual user needs with the consequence that the metrics for evaluating the service may deliver less accurate results. User stories may not be based on actual user needs at all, but instead, reflect the organizational perceptions of users and their needs.
This omission or gap from envisioning to production, from the project’s outset, triggers the risk of service design and secure design debt due to envisioning being de-prioritised, delayed, or skipped. As the saying goes; the earlier debts are repaid, the better. Better still, don’t allow debt to build up. It pays to use some time to plan and to avoid this risk before the agile process kicks off!
In the second part of this blog series, we will describe how this envisioning phase is done and its deliverables deployed to the agile development process.
Further reading:
Jari Hietaniemi: The Best Ways to Screw Up An Agile Project:
https://gofore.com/en/the-best-ways-to-screwup-agile/
