Many of us use Windows in our daily (development) work, either by choice or forced by external factors, such as the client IT-environment or application restrictions. For years, I’ve used git bash to get around the Windows command line’s shortcomings. However, I soon discovered the awesome Cmder that was almost a Unix-like terminal replacement. But then again, why resort to a replacement, when you can have the best of both worlds? In this tutorial, you’ll learn how to install a Linux subsystem on your Windows machine (if you have never heard of that, I know, it sounds weird and potentially frightening) and after that, we’ll continue by installing Hyper.js AND zsh to have a terminal just like on any UNIX-system. Probably the best invention since the cheese slicer.
Before installing any Linux distros for WSL, ensure that the Windows Subsystem for Linux (WSL for short) optional feature is enabled. Enabling this is straightforward, just open PowerShell as Administrator (a handy shortcut: right-click on Start menu) and run:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Restart your computer when prompted.
After you’re back on desktop, the easiest way to download your preferred Linux distribution is from the Windows Store. Search for e.g. ‘linux’ and choose your favourite. If you don’t have any preference, Ubuntu is a safe bet. The download might take a few moments, so grab a coffee here. If you have enough bandwidth for another download, this might be a good point to download Hyper from https://hyper.is.
After the installation is complete, search for your newly installed Linux distro in the start menu to finish the process. On first boot, some initial installation steps are completed, so be ready to wait for a while once again.
With enough patience, you’ll be prompted to create your UNIX-account.
Installing a better terminal
If you didn’t do so already, download Hyper.js from https://hyper.is/. Hyper is an extendable terminal replacement based on Electron, and runs on any platform, so you might want to try it out on other operating systems as well. Not to forget that it’s beautiful and fully themeable. Unless you’re scared of everything that runs on Electron, of course.
Booting up Hyper.js for the first time brings you to the default Windows command prompt.
Ctrl + ,
to open the preferences in a text editor, and scroll down to ‘shell’.
We want Hyper to log in to bash instead, so change this line to
While you’re at it, you might want to change some other settings to match your preferences as well, e.g. specify your favourite colours or add a predefined theme or other plugin
All set and done! To see that bash works, open a new tab from the menu or by pressing
Ctrl + Shift + T
Now you’re halfway through. Leave the terminal open, we need it later.
Installing zsh and Oh-My-Zsh
For those not familiar with the Linux lingo, zsh is a customizable alternative shell for UNIX systems. Oh-My-Zsh builds on top of that to help you manage the preferred configuration, consisting of community-developed plugins and themes to make one’s life easier (it really does). So if you left the tab open in the previous step, call
sudo apt-get update
sudo apt-get install zsh
to install zsh just like any other Unix system.
Now we need to make zsh our default shell. This needs to be set at login because as far as I know, the default login shell on WSL cannot be changed.
For that, open .bashrc in your favourite text editor
bash -c zsh
as the first line in order to tell bash to switch to zsh at login.
Save and close the file.
Finally, we’re ready to install Oh-My-Zsh from
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
And you’re good to go! Just remember to review your settings in .zshrc.
Finally, in a proper terminal
One of the first things you might notice is that npm does not work. Now that we’re living inside Linux,
the easiest option is to install Node (or nvm, if you need that) again on Linux by running
sudo apt-get install nodejs
Additionally, in case you run into issues, you might have to make your path point to
Bonus round – usage in VS Code
Open settings in JSON (Ctrl + Shift + P, type settings), and add
That pretty much sums things up. Now you have made your terminal great again – on Windows!
Some useful guides to continue diving deeper
My oh-my-zsh wiki https://github.com/robbyrussell/oh-my-zsh/wiki
Installing Powerline fonts required by some themes – https://medium.com/@slmeng/how-to-install-powerline-fonts-in-windows-b2eedecace58
Making Windows native Docker work on WSL – https://medium.freecodecamp.org/how-to-set-up-docker-and-windows-subsystem-for-linux-a-love-story-35c856968991
Quite often I hear the claim “on-premise is more secure than cloud”
Having worked in both the on-premise and cloud worlds for several years, this is an informed opportunity to dissect such claims into smaller subsets and do some comparisons.
Regarding cloud environments, I’ll stick with Amazon Web Services (AWS) which I am the most familiar with.
Let’s start with physical security.
A properly configured server room must have the following topics covered:
- Deny unauthorised access
- Ways to prevent and detect tampering
- Although not directly related to intrusion or unauthorised use, a fire alarm and fire suppression system must be present
- All rack cases must be locked so that, for example, thumb drives cannot be inserted
- Backups must reside in a remote location and must comply with the same security policy as the on-premise source
In cloud environments, the above-mentioned best practices are the responsibility of the service provider – if not, please change your provider – quickly!
With such best practices in place, a cloud customer doesn’t need to be concerned with the hardware aspects when designing a cloud-based system.
Regarding software security, the following topics must be covered:
- Keep software up to date
- Scan for vulnerabilities
- Scan for misconfigurations
- Security is layered
<shameless plug>If you missed my previous post, some of these topics were covered in greater detail here: https://gofore.com/computer-security-principles/ </shameless plug>
Another often heard claim is “Data is so sensitive that it cannot reside in the cloud”
Right, so why is that computer connected to the Internet?
Everything is crackable and the firewall in front of the computer is just a teaser in the game. If the data is that sensitive, then it must be in an encrypted format. You’ve got this covered, right? I hope so!
For these kinds of best practices, AWS offers great tools:
- Encrypted S3 storage (object storage)
- A Systems Manager Parameter Store to encrypt all values going into a database
- Key Management Service to automate key handling, including key rotation and audit trail
(to name just a few examples)
If a virtual machine is being run, one should be aware that Spectre and similar hardware vulnerabilities will pose a danger to some extent; at least in the cloud where resources are shared.
An evil-minded attacker’s virtual machine instance will need to be located in the same host machine in which the victim’s instance is running.
These kinds of vulnerabilities are patched very swiftly as soon as the fix is available. Especially since it poses a danger to the core business. Therefore these attacks are short-lived – unless a new zero-day exploit is found. And even then, the zero-day exploit must be applicable and:
- Moderately quick to exploit to have benefit
- Success rate must be fairly high and it must give enough permissions to control the needed resources
An improvement would be to use cloud-native components to handle load balancing, container orchestration, message brokering and so on.
Why? Because those are constantly audited by the cloud provider, therefore resulting in a smaller attack surface compared to handling the whole operating system and its software components (and their updates).
Copying an insecure application into the cloud doesn’t make it magically safer.
Regarding security standards, AWS complies with the following letter and number bingos:
- SOC 1/ISAE 3402, SOC 2, SOC 3
- FISMA, DIACAP, and FedRAMP
- PCI DSS Level 1
- ISO 9001, ISO 13485, ISO 27001, ISO 27017, ISO 27018,
These standards fulfil the requirements for Nasdaq, the US Department of Defence, and Philips Healthcare, just to mention a few high profile customers. These organisations take security seriously and have a huge budget for their security teams.
In the AWS Aurora database is a Maria/PostgreSQL-compatible relational database service (RDS) that offers automatic scaling and updates.
Major version updates can be done this way too, though it’s against best practices to upgrade without testing. You have been warned! That diminishes the burden of updates drastically.
The biggest cloud providers, namely Amazon, Google and Microsoft, have some of the most talented people in the field working on their products to keep their customers’ data secure. Compare this to on-premise scenarios where, in the worst cases, it’s a one-man show. If (s)he is not really interested in security, then it’s a security nightmare waiting to be unleashed.
Nothing protects faulty configuration choices in the cloud either, though some things are harder to make globally reachable by default.
In conclusion, cloud is not a new kid on the block anymore.
Learn your environment and implement with best practices.
Correctly configured cloud is secure and might save the administrator/DevOps/whatever from nightless nights.
You can learn more about gaining cloud certifications in our blog series starting here: https://gofore.com/en/getting-certified-on-all-cloud-platforms-part-1-introduction/
“80’s rule man, best time ever! Then that Cobain had to come around and ruin it all.” is a funny quote from the movie Wrestler. Today’s software experts might also yearn for former times. In the waterfall model, the role of architecture was clear – it was designed up front, after requirement analysis and before the implementation phase. In the current Agile era, architecture is often evolving without clear goals and objectives.
Yin and Yang
According to “Clean Architecture”, the purpose of architecture is to support the lifecycle of the system. The ultimate goal is to minimise the lifetime cost of the system and to maximise programmer productivity. Traditionally, dedicated experts have been accountable for this function. In this blog, these experts are called software architects, but technical leads and stack leads are also commonly used titles. Typically, software architects have a strong technical background and good leadership skills.
One of the Agile core values is the development teams’ autonomy. Teams design, implement, test and deploy independently. Traditional Agile methodologies, such as XP (Extreme programming) and Scrum, do not mention how architecture design should be led in practice. XP advises, for example, that architecture design just emerges alongside other design.
The larger the project (i.e. multiple teams), the more complex is the product’s software itself. This means that architectural decisions will have a bigger impact. The question then arises how architecture design is led and what responsibilities software architects versus teams have?
Make your system visible
Systems thinker and the father of the quality evolution, W. Edwards Deming has said that 96% of organisational performance is a function of the organisation’s structure. Only about 4% of an organisation’s performance is attributable to the people. Part of the structure is to understand how collaboration works in the system.
The following table makes collaboration between architects and teams visible. Every row of the table represents a potential point of leverage. The columns represent different options as to how collaboration can be implemented. Left columns represent a more distributed and emerging architecture mindset (i.e. Agile) and the right columns a more centralised and formalised approach. Organisations are different, and therefore leverage points and options vary as well. Rows are also independent, so for example “Architects are part of the teams” and “Architects are dedicated mostly to architecture topics” can be used on the same project.
<– more distributed more centralised →
Point of leverage
|Hierarchy levels||One level – no special roles, just team members||Two levels. Developers and architects||Three levels+. Team members, architects, chief architect|
|Scope of software architects||None||Architecture principles (e.g. standards, concerns, styles)||Architecture principles and infrastructure & operations||As option 3 plus enterprise architecture|
|Alignment||No architects. Team member is the only role||Architects are part of the teams.||Architects work as free agents||Architects form a team or department|
|Decision making||No architects. Teams make architectural decisions||Teams and architects make architectural decisions together||Architects make most of the architectural decisions|
|Division of Work||No architects. Teams share responsibilities dynamically||Architects and teams share their responsibilities dynamically||Architects have predefined responsibilities|
|Capacity||No reserved capacity. Teams use their time on architectural topics if needed||Architects/teams have reserved capacity for architecture topics||Architects are dedicated mostly to architecture topics|
No “one-fit for all” solution
After the current collaboration model is defined, the next step is to decide the future direction. Organisational systems are determined by their context, so “one-fit for all” solutions aren’t appropriate. Nevertheless, some conclusions can be drawn.
Typically, the long-term goal should be to move to the more distributed and self-organising collaboration model. When people understand the collaboration strategy, it is much easier to take actions toward it. Unfortunately, organisations underestimate the amount of work that the transformation requires. People have different skills and expectation levels and unlearning at both the organisational and individual level is required.
Agile is also a highly disciplined method. Business people and team members must work together daily; the cross-functional team structure is mandatory and software delivery must be frequent, to name just a few principles. If the organisation won’t bend to these demands, a more centralised collaboration model might be the valid option.
Sub-optimising is also a risk in bigger organisations. A team might violate architecture principles thoughtlessly, just to finish their sprint backlog faster. The other team might implement a similar service that has been already created by another. Architects see more easily the whole and are able to make holistic decisions.
Many organisations’ technical debt is huge as well. Products suffer wrong technologies or bad programming practices and an enormous amount of refactoring work is needed. Painful architectural decisions are often made more efficiently by a more centralised collaboration model.
A hero is required
Software architecture is not the hottest topic in the software development field. In addition to this, it is very abstract and hard to lead. However, all software has an architecture regardless of if the architecture is managed or not. Smart organisations understand that the organisation structure should be optimised for the most crucial paths of collaboration – and collaboration between teams and architects is part of it.
The Clean architecture – Robert C. Martin
Technical leadership and the balance with agility – Simon Brown
Have you ever been really into your work but didn’t have anybody who shared your enthusiasm when you started gushing about it? Do you work as a specialist in a multi-functional team and don’t seem to have direct support for challenges related to your specific domain? At Gofore there might be a guild that could help, or maybe you need to start one?
About a year and a half ago the project I was working on restructured which lead to our scrum master leaving and me transitioning to the role of scrum master. Our product owner was also replaced by a team of three product owners. Simultaneously the project goal changed from a proof of concept to get a release of the product out in three months so the number of developers was also ramped up. Because our team was made up of experienced developers already familiar with the product I found myself in a situation where most of my time was focused on getting the product owners on track with their roles. After a couple of sprints I realized that I hadn’t had a chance to even assign myself a ticket, I had transitioned to a full-time scrum master position. While I have several years of experience as working as scrum master and developer I quickly realized that being a dedicated scrum master was a very different role.
My perspective drifted away from the product I had been building in the proof of concept phase and I started focusing on how the team was working not what it was working on. I wasn’t as interested in what decisions the product owners were making but on how to get them to make any decisions at all. And then I realized I was the only person on the team focusing on these issues. I started wondering how similar issues were handled in other projects at Gofore and how I could ask our more experienced scrum masters, product owners or project managers about these issues, so I invited them to lunch.
Since I had been working in project management roles earlier I had a company credit card and reserved a table at a nearby restaurant for lunch and invited everybody working at the Helsinki office who I knew had worked or was working in a scrum master role. I think the offer a company-sponsored lunch combined with curiosity led to around seven people coming and we shared news and thoughts about our project work. Since everybody didn’t have a chance to talk about their project I decided to have another lunch or breakfast the following month and I promised to organize a doodle for the date. This quickly became a monthly thing.
I didn’t ask anybody’s permission to organize these lunches, I just used my own judgement that they were needed. Being true to the Gofore spirit of transparency I was as open about the costs and the time I spent organising the guild lunches as I could be. From the beginning, our lunches were a bit fancier than your regular working lunch, because I thought that it is important to communicate that we as a company value learning from each other. Also having the meetings outside the office gave a sense of detachment that you don’t get in a familiar meeting room.
I happened to mention about these lunches we were having to our Lead Coach Heini while I was visiting our Tampere office and she informed me that I had started a guild.
On the train, on the way back from meeting Heini in Tampere I changed the name of the page recording our lunches in our confluence to the Agile Leadership Helsinki Guild. There are some other guilds in our company but their role hasn’t been strictly defined. Each guild is a bit different in how they work, but they all relate to professional development. Ever since the beginning, sharing and sparring project-related challenges have been a staple of our lunch meetings. At some point, I stopped doodling and we agreed that our lunch date would be on the last Thursday of each month. It was easier that way, and knowing the lunch dates several months earlier makes it easier to reserve the time needed to be away from the client.
We started having short introductions to agile related subjects at the beginning of the lunches. This was a great way to share experiences when somebody attended a conference or external training. At some point, Anu joined me as the champion for the guild and having a dedicated person with whom to share guild related ideas with made guild work a lot more fun. We started organizing training sessions outside of lunches that were directed to guild members as well as open for others at Gofore. The latest thing our guild has done has become a platform for helping members go to conferences and on external training courses.
I gave up the position as guild champion at the beginning of the year and the current champions are taking the guild forward and doing stuff I didn’t have time for. I am still actively involved and enjoying having a community to reflect my project work, Agile Finland work and Agile Transformation and Lean capability work.
Lessons learned from starting a guild at Gofore
While I had a useful experience from working with volunteers in the scouts and in university organizations, this was the first time I had started a completely new organization or community. This gave me the chance to reflect on my previous experience in volunteer leadership, combined with formal academic knowledge from Knowledge Management studies at university and professional project management experience. At Gofore we have many social clubs (or Glubs as we call them) where like-minded colleagues come together to discuss everything from investment opportunities to the latest beer to be launched. Guilds help unite people over professional interests compared to glubs leisure focus. If you have an interest, professional or extracurricular, starting a community around it at Gofore is a good way to network with your colleagues. There are now many guilds covering a wide variety of software solutions and related fields like design. Below are my experiences of setting up a guild for Agile leadership, but they apply for setting up glubs as well.
- Having a personal need to fulfil when starting a new project helps when you need motivation or need to pivot.
- A guild is a community so starting one is really hard.
- Starting a community is basically a culture change or creation project.
- When starting aim for consistency with minimal effort.
- You can never over-communicate or over promote guild related events or issues.
- Culture change projects need a champion so don’t worry about things being personified to you.
- Because it’s voluntary don’t be afraid to make choices and do the work even when you don’t get feedback.
- It is great to have a community for sparring your project work and personal development.
- The strength of the guild comes from the fact that even though participation is work time it still voluntary so people participate from their intrinsic motivation.
- The biggest obstacle for people participating in professional self-development work like guilds is loyalty to the customer and interesting customer projects.
I believe it is important to keep up to date with developments in your professional area of interest. Gofore guilds are a great way to, not only keep up to date with professional developments but also to network with like-minded colleagues. It’s great that Gofore actively support and encourage guilds and glubs. Connecting with your co-workers over shared interests is a great way to contribute to the collaborative and supportive working environment.
In the first part of the blog series, we described the challenge of combining service design and secure design with agile methods. In this blog post, we will describe a process model for tackling this issue. This model combines the envisioning phase with the agile development phase and ensures that secure design and service design are deployed with the development.
Start with the problem, not with the solution!
At Gofore, we use the service design approach to understand the service or products core purpose. An example of a core purpose can be, for example, Instagram stating that their product is meant to “Capture and Share the World’s Moments”.
The objective of service design is to design a holistic, user-friendly service experience by answering the needs of customers and the competencies and capabilities of service providers. By using design thinking methods and tools it defines the optimal customer experience for the service to be designed. Service design aims to make the service creating actions visible to all parties involved and find empathy and understanding of the users of the service.
The objective of secure design is to ensure that the security and privacy aspects of the service or product delivered, and the associated user experience, have been investigated together with the business and stakeholders from the inception of the project. The challenge is how to ensure secure design, like service design, gets built in?
Utilising a design-thinking mindset, we conceive the core purpose with a “Double Diamond” method. This diamond model of creativity combines divergent thinking and convergent thinking phases to discover as many ideas as possible, and then distil them down to the best solution. Using the Double Diamond, this process is repeated, once to confirm the problem setting (to find out “Why” we’re doing something), and once to ideate the solution (to find out “What” we’re doing). The user environment, user tasks and associated user behaviours are explored, elucidated, visualised and synced with the service provider’s business and strategic goals. This is done using various service design processes and tools, for example by applying participatory user- and stakeholder-oriented design methods from the very inception of the project.
Service design yields the design drivers for the service to be implemented. At the same time, the security- and privacy-relevance of these design drivers should be scrutinised; for example, what is contained within the user data? Does the service ingest personal data? What data regulation must be complied with? What are the business and user assets requiring protection, and how? Thus, service design and secure design should be done simultaneously.
Continuing with service design envisioning, the user epics are ideated, and corresponding requirements are extrapolated. Concurrently, the security and privacy aspects of epics should be identified and documented. When the corresponding service features are concepted and their stories are derived, the corresponding security and privacy user stories should be derived and linked. For example, if the concept is a web application, then the web application’s feature stories should be linked to the associated security and privacy stories where relevant.
Why should you envision first?
By finding the core purpose of the service to be designed, the envisioning phase delivers not only the customer value being aimed for but also the guidance for prioritising the backlog and validating the design (metrics and test cases). It also acts as a valuable resource for defining the service roadmap and business strategy by answering the question: what user features are most important to implement first?
As mentioned earlier, service design and secure design are mutually beneficial and complementary activities. Requirements arising out of service design are likely to have associated secure design and privacy requirements that can be further deduced by assessing the threats and risks to the design. By ensuring that both service and secure design perspectives are purposefully envisioned, a more user-centric and a more robust foundation will be ideated and architectured into the implementation phase of the project. This mitigates the risk of service design and secure design deficiencies that cause further expense, wasted effort and rework arising during the production phase. Notably, this complementary design characteristic also fosters the sharing of design, security and privacy awareness across these historically siloed disciplines.
From envisioning to production
When the backlog of service concept epics, feature stories and linked corresponding security and privacy stories are considered primed for agile implementation, then the initial sprint grooming and planning can commence.
How to ensure continuous design in agile processes?
To ensure a complementary user-centred and security- and privacy-oriented approach throughout the development phase we require both the secure design and service design advocates to participate throughout the implementation. We also require team members and a product owner who understand the benefits of building service design and secure design into the implementation. This is crucial because there is a natural tendency for developers to focus on visible deliverable features; after all, that’s what the customers and business stakeholders want to see; visible signs of progress.
For these reasons, a continuous service and secure design concepting flow should run alongside the actual sprint process ensuring their aligned iteration according to the agile iteration model whereby you plan, develop, evaluate and iterate the design continuously based on user studies and usability testing.
Figure 2. Development
As depicted in Figure 2, the service design and secure design activities continue throughout the development phase to keep the process agile and iterative. The deliverables from the concepting and prototyping work are continuously designed just one or two sprints ahead of implementation. The implemented design is then, in turn, evaluated by usability testing and acceptance testing according to the metrics established in the envisioning phase. If according to the testing, there is a need to change the design, it goes back to the drawing board as design iterations. This ensures a continuous evolution of the service design and secure design epics and features while keeping the service’s core purpose linked to the iterative development and evaluation of the service.
In this way the objective and purpose of the service being developed are nurtured along; prioritising the backlog is easier when the guiding requirements for it have been properly established and are maintained alongside the daily implementation work. Also, by using this model, the concepts delivered using service design and secure design can be re-evaluated at any time. For example, if while doing usability testing, we discover that users’ needs have changed from what the initial envisioning phase suggested, service design will scrutinise and update the core purpose and help steer development into a more user-oriented service experience. Or if some feature or component changes, secure design will scrutinise potential security and privacy impacts and protect accordingly.
Recap: to be truly agile, plan (a bit) first!
Figure 3. Holistic envisioning and development of service design and secure design
At Gofore we encourage our customers to ask for a pre-planning or study/envisioning phase before the actual agile production of the service starts. This delivers preliminary requirements for the service experience, its security and privacy considerations, and guidelines for metrics and evaluation. Envisioning also simplifies the estimation of the scale and scope of the project to be done. With our Envision/Develop process model, we can tackle the service design and secure design requirements while maintaining an agile process wherein the design concept can be iterated at any point during its production.
Service Design Network: What is Service Design?
Design Council UK: The Design Process: What is the Double Diamond? https://www.designcouncil.org.uk/news-opinion/design-process-what-double-diamond
Minna Puisto: People don´t want service design, they want their problems solved!
Craig Bachman: The Agile Experience Strategist
Valerie Carr: LEAN and Service Design | Understanding the differences.
Gofore blog, Niall O’Donoghue: Secure design is a mindset and way of working
Gofore blog, Jyrki Anttila:Hands-onn UX-Design in Lean Projects with Limited Resources
Gofore blog: Combining Service Design and Secure Design in Agile Software Projects: Part,1 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.
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.
Jari Hietaniemi: The Best Ways to Screw Up An Agile Project: