Services Page - Retrospective

Retrospective you say?

Retrospectives are an important part of the Agile development process because they provide a structured opportunity for the team to reflect on their work and identify areas for improvement. Agile development is an iterative process, where the team is constantly learning and adapting to new information and feedback. Retrospectives are used to capture this learning and help the team make meaningful changes in how they work.

Retrospectives help the team to:

  • Reflect on their work and identify areas where they can improve.
  • Build trust and communication among team members.
  • Encourage continuous improvement and learning.
  • Identify and remove any obstacles that are blocking the team's progress.
  • Identify and implement new practices that will help the team to work more effectively.
  • Maintain an adaptive, flexible and self-organizing team.

with that...

Services are finally live!

Each and every iteration of the Acorn Interactive Inc. website comes with a mixture of improvements, frustrations, and lessons learned. It’s easy for an individual to recall the frustrations and lessons within a given initiative, but it’s extremely important to have a system to capture this on a broader level amongst the stakeholders on the project. 

There are a lot of reasons to ignore doing retrospectives.

Saying uncomfortable, or hard, things isn’t easy. All too often we want to amplify success stories and downplay frustrations or negative experiences. It’s only human after all. With that, it's the how part of explaining negative, or unpleasant, experiences within a sprint that really help to drive the future success of a team and, by extension, the software.

In developing our services pages, we sought to use the exercise to align us with a number of agile best practices while continuing to iterate on our software systems for sales, and developing new customer relationships.

Just an FYI: Retrospectives require time, and details. Saying that, this post is quite long.

Doing the work to serve customers, that's why we're here - right?

Photo by Joshua Rodriguez on Unsplash

To start, let’s get into the weeds on what Acorn set out to do.

Services Pages: Objectives

We have to start somewhere. In the beginning, ideas flow freely and excitement is everywhere for change. Similarly, the invocation of new features and functionality invite opportunities for a fresh start or new approach one can take. Acorn knew that our site had deficiencies that needed to be addressed.

For starters, our About Us page was high level and vague. The page explained what the agency did on a high level, but lacked specificity and granularity. Sharing the page across social networks could, on the one hand, show that we were proficient in web development implementations. On the other, it didn’t say what exactly to expect. Did we do apps? Shopify? Wordpress? Applications?

The About Us page solved the problem - for a time. Yet to improve our business processes and sales analytics, we had to put forward a plan to monitor page traffic, and conversions, for each of our core service offerings. This way, individual services could be shared in targeted channels, and we could garner insights on what our customers needed or preferred from us. From there, we could run advertisements for these services on a per-page basis.

On a high level, we could put our web application to work for our business.

Always, always, start with a pen and paper.

Photo by Jason Goodman on Unsplash 

Sales Engineering

Sales engineering is a field that combines technical knowledge with sales skills. Sales engineers work to understand the technical needs of potential customers and match those needs with the appropriate products or solutions. They may also work to customize products or solutions to meet the specific needs of a customer. Sales engineers may also assist in the implementation and support of the product or solution.

Did you know?

Digital initiatives are often built to support an existing suite of operations, or extend the capabilities of a team. Knowing who is responsible for what, where resources should be deployed on an initiatives, what technologies will be required to build out a project, and how a suite of software protocols is going to function takes a fair amount of planning.

To do sales, we need to understand our customers needs. It sounds obvious, but it's hard. It's deeply rooted in relationship building.

Acorn has been attending a number of events. In events like #vtjtalks| Version One's Boris Wertz on VC's Past, Present, And Future, or Understanding NFT's and Fungible Tokens with Kris Constable, we come across a number of industry professionals or potential clients. Talking is one thing, but our work is more of a show than a tell. Having a way to shake hands, add professionals to LinkedIn (also hey check this out!), and then share our core services offerings 1x1 is really important for our business. 

Mitch at Boris Wertz on VC's Past, Present, And Future

To support this, and being able to bring customers into our company fold, we needed a way to share information with potential customers, and track them in our Customer Relationship Management Software (CRM). In our case, it’s Capsule.

Designs For the Services Pages

With our sales engineering plan setup, we could build application designs, user flows, pages, and forms to support the outcomes we want - generating leads.

Public Facing Requirements

As with any component, feature, page, or application, it all starts with an idea. Ideas need to become blueprints and sketches, cursory work here needs to translate into more formal deliverables, and these need to evolve at somepoint into comprehensive mockups. As well, system interactions by visitors or administrators need to be catalogued into what are known as flow charts, so software professionals have clear guidelines, and can manage expectations, on their contributions to an initiative.

For us, we needed to have a way to list all of our services on a single page. We needed to have all of our services broken down on separate pages, and then hyperlinked back to the index page of the services.

Administrative Requirements

As we have built our own application for content management to train team, the goal here is to ensure people think deliverable sets through to their logical conclusions. In many instances, we notice that designers tend to prioritize high quality visuals. This is obviously important because people want online and mobile experiences to be impressive, smart, and clean. What gets neglected, however, is the types of small details that help an individual navigate through these experiences, be provided adequate feedback, and understand how these work for publishing contents themselves, and interacting with the database.

We start with flow charts and wireframes

Nick, our design lead, wants to make sure he is building out designs that work within our system.

Interface Design

An interface designer is responsible for designing the visual and interactive elements of a software or website, such as buttons, menus, and layouts. They work to make sure that the interface is user-friendly, efficient and easy to navigate. They are also responsible for testing the interface with users and making adjustments as necessary. Their role is to bridge the gap between the technical functionality of a product and the user's needs and preferences.

Having understood the touch points of our new "services" system from the user flows, and having constructed wireframes for all of the pages associated with it, we could then add some colour, polish, and lipstick to spruce it up!

Did you know?

Translating ideas is hard! Working with personable teams to get the ideas out and on paper is really fun and can identify bottlenecks before the become problems. Need a hand?

Back End Development

A back-end developer is responsible for building and maintaining the server-side of web applications. They work with the server-side logic and the database, and create APIs that the front-end developers can use to interact with the back-end. Back-end developers are responsible for the functionality of the web application, and they ensure that the web application can handle a large amount of traffic and data. They also work to optimize the performance of the web application and troubleshoot any issues that arise. In summary, a back-end developer focuses on the server-side of web development, and is responsible for creating and maintaining the core functionality of a web application.

In our case, we made a really good decision to build out the data model and the api before we started with the front end development. By doing this, we solved numerous problems about creating, reading, updating, or deleting (CRUD) data from our pages.

If we don't take the steps in this way, what can happen is that disproportionate amounts of:

  • time
  • effort
  • budget

go into front end development to port the design into code. The problem is that design caveats can rack up a ton of back-end time and expense with the problem being database integrations are overlooked in the first place. This only adds expense and frustration.

As priorities shift with new information or new learnings, making visual changes is easier to do with a stable database/back-end foundation than to make adjustments to databases with complex front end implementations. This isn't a tried and true "rule" per se, it's just an approach that worked for the problem we were solving. Context is everything...

our model for the services collection, derived from viewing the wireframes and mockups

Why build back end data models first:

Building data models is important for several reasons:

  • Organization: Data models provide a way to organize and structure data in a logical and meaningful way. This makes it easier to understand, manage, and query the data.
  • Data Integrity: Data models help ensure data integrity by defining relationships between different data entities and enforcing constraints on the data. This helps prevent data inconsistencies and errors.
  • Performance: Data models can be optimized for performance by carefully choosing the data types, indexes and other database design elements. This can greatly improve the performance of queries and reduce the load on the database.
  • Scalability: Data models can be designed to be scalable, which means they can handle an increasing amount of data over time. This is important for applications that are expected to grow in popularity or usage.
  • Data Security: Data models can be used to implement data security by applying access controls and encryption to specific data and preventing unauthorized access.
  • Communication: Data models can also be used as a tool for communication between team members, and with stakeholders, as it provide a clear and shared understanding of the data and how it should be used.

Front End Development

Front-end development, also known as client-side development, is the process of creating the user-facing part of a website or application. This includes the design and layout of the interface, as well as the functionality that allows users to interact with the website or application. Front-end developers use languages such as HTML, CSS and JavaScript to create the visual elements and design the layout of the website or application. They also use JavaScript frameworks and libraries such as React, Angular and Vue.js to build interactive and dynamic user interfaces. The goal of front-end development is to create an interface that is visually appealing, easy to use and responsive to different devices. Front-end developers work closely with designers and back-end developers to ensure that the interface is functional, efficient, and meets the needs of the users.

Thankfully we don't need to show visual examples of the work anymore - you can just go check out the page for itself!

Oh no... now comes the hard part...

What didn't work for Acorn

As promised we plan to seppuku our process to demonstrate why it's effective for results. This is a summary of our blunders along the way.

Team Communication

The phasing of the project encountered a number of hurdles in getting of the ground. The phasing of project missed important considerations between design and fulfillment which only surfaced after designs were produced, and code had been started.

  1. Sales wanted to have just one page setup so they could setup google ads and test the responses and tweak accordingly
  2. Development and design needed to have models and responsive designs built to simulate the suite of interactions
  3. Sales wanted to route one page to launch, and build out the entire suite of pages as a second set of deliverables
  4. Writing page contents was constantly shuffled around, with no key personnel tasked to completing it


  • Involve sales priorities much earlier on in the process
  • Have sales and fulfillment collaborate on MVP requirements for each build version ensuring both teams have illustrated their needs to accomplish a task

Why are communicating priorities important?

  1. Focus: Communicating priorities helps to ensure that everyone on the team is focused on the most important tasks and objectives. This helps to prevent team members from wasting time on less important tasks and ensures that the team is working towards the most important goals.
  2. Alignment: Communicating priorities helps to align the efforts of the team with the overall goals and objectives of the organization. This helps to ensure that everyone is working towards the same goal and that their efforts are not wasted on tasks that do not contribute to the overall success of the project or organization.
  3. Clarity: Communicating priorities helps to provide clarity on what needs to be done and when. This helps to reduce confusion and uncertainty and ensures that everyone knows what is expected of them.
  4. Accountability: Communicating priorities helps to ensure that everyone is held accountable for their work. By clearly communicating what is most important, team members are better able to understand what they are responsible for and how their work contributes to the overall success of the project or organization.
  5. Resources Allocation: Communicating priorities helps to ensure that resources, such as time, budget, and personnel, are allocated to the most important tasks. This helps to ensure that the team is able to make the most of the resources available to them and that they are able to achieve their goals.
  6. Problem Solving: Communicating priorities also helps to identify problems and solutions, as it allows to see which tasks are more critical than others, and help to solve problems quickly and efficiently.
Type type type - writing contents for your services is a real pain.

Content writing

We faced a number of challenges with drafting the written contents. We started off with a google doc outlining the major service categories we wanted to support. ChatGPT wasn't out yet, and nevertheless, it wouldn't have really helped us. We needed to go through our company history and audit the work we have already provided for our clients. We do have our Portfolio Page setup, so we needed to distill that into the verbiage for our core services offerings - in plan english. The dilemma boils down

  1. Who is going to do it
  2. Do we need to write from the designs, or design from the writing?
  3. Does the content work for SEO?

The problem we had is specialists in every area but content strategy, but nobody dedicated to working on it exclusively. This would be a function of money we didn't have at the time, knowing full well that resourcing both a dedicated content strategist, and a dedicated information architect, would have set up our initiative for success.

How do Information Architects and Content Strategists Collaborate?

  • Content strategists and information architects collaborate by working together to plan, design and organize the content of a website or application.
  • Planning: Content strategists and information architects work together to plan the overall structure and organization of the content on a website or application. They identify the key themes, topics, and goals of the content, and determine how the content will be structured and organized to best meet the needs of the users.
  • Design: Content strategists and information architects work together to design the user experience and navigation of the website or application. They determine how the content will be presented and how users will interact with it.
  • Content organization: Information architects work on organizing the content in a logical and meaningful way, creating a structure that makes it easy to find and understand. They create a taxonomy, navigation, and other information organization tools.
  • Content creation: Content strategists work on creating and managing the content, ensuring that it is high-quality, relevant, and useful to the users. They also make sure that the language, tone and style of the content is consistent with the brand and target audience.
  • Testing and Evaluation: Both Content strategists and information architects work together to test the website or application with users and evaluate the performance of the content and structure. They gather feedback and make adjustments as necessary to improve the user experience.
  • By working together, content strategists and information architects can create a cohesive and user-friendly website or application that effectively meets the needs of its users.

By properly implementing this before we moved into any design, development, or SEO we could have built out flow charts and wireframes that consulted the sales team for their MVP requirements. Then, the IA and content strategist could have worked with the product owner, the development team, user experience, and design, to map out our phasing strategy to launch the MVP for ads and targeting first, and then roll out the suite of application features progressively.

These projects are always iterative.

O0o0oh look, it's Nel again...

Nel Pontejos - Seasoned QA and DevSecOps

We brought Nel on with a league of experience at EA and Nokia, to name a few, to look at how we were doing things and improve our approaches to agile. We can leverage his experience, coaching, and skills to make ourselves better organized for project management, agile methodologies, role definitions, and team communication. Nel was able to capture his observations on our process and recommend a number of improvments.

Areas Nel targeted for improvement :

Perform Retrospective Exercises:

This works internally, to work externally. We need to have structure in place to review what's happened, what's going on, and what's coming up. We need to have metrics to measure client satifcation and identify pitfalls from experience. We need to use this time to become better communicators.

Team buy in:

As in, gaining the support and commitment of team members for a project, plan or idea. It is important because it helps to ensure that everyone on the team is working towards the same goal and that their efforts are not wasted on tasks that do not contribute to the overall success of the project or organization.

Build out a scrum master role:

The Agile Scrum Master facilitates the Scrum events, such as daily stand-ups, sprint planning, sprint reviews, and retrospectives. They ensure that the events are run efficiently and effectively, and that the team stays focused on the goals of the sprint. They're also responsible for leading and managing the Scrum team. They ensure that the team is working together effectively, and that team members are communicating and collaborating effectively.

We would have various people leading the charge to get deliverables built. Having a single person assigned to being "the octopus", as in the one integrating the various tasks assigned to team members would be a role to build out.

this is also a function of money...

Proceed with 2 weeks sample sprint

It's easy to throw around agile jargon but the whole idea is to practice and get good at it. Saying things smart doesn't really matter if you're not disciplined about it. Nel created a framework to whip us into shape here from his observations, and continually schedules check ins to make sure items are being accounted for in our sprints, and things are not cluttered.

Evaluate the gap, situation, challenges, limitations and make predictions

All of this work to delegate tasks and have time to check in on how things are going (not too much now, Shopify) allows us to channel inputs from our customers to limitations, and blockers, from our team. The more we can have good correspondence between what needs to be done, what can't be done, what can be shelved, and so on the better working relationships we can have internally and externally.

Nel has created a new role called FEDS is born, Fun and Engagement Designer Strategist. It's not like a ping pong tournament by contract. It's about employee satisfaction from a mixture of clarity of purpose, agency in role, clear direction from team members, and well established milestones for project fulfillment.

This role is designed to push the boundaries of what can happen within a two week sprint. More on this to come.

Role based paradigms for task and ticketing:

Nel interviewed the team to get a better understanding of the day to days of their role. He isolated those roles into ticket categories with clearly defined task categories. He wanted to build this out as a way to make remote work sane, and practical. He wanted to find ways to ease the cognitive burden of distributed workflows using Jira.

Role based ticketing, go!
If you're assigned to do a ticket for a category, here is what the role is expected to do.


And that's it! We were able to

  • get the features live,
  • capture and log process notes along the way
  • breakdown the major pain points, bottlenecks, and miscommunications that occurred and interfered with our delivery
  • create a plan to fix these in future iterations and client work
  • setup tasks and deliverables to keep on keepin' on

The chronology part of "what did we do", "where are we at", and "what do we need to do" is exactly why we do retrospectives with ourselves, and with our customers.

If we skip this part, we miss out on the important details that can inform service line agreements, or at their worst, accumulate into system defects that don't get tracked and affect what is happening on the systems and applications we design/build.

It takes a team to do this. People who phone it in, or think they're better than focusing the vision of their team are both farming out responsibility and ultimately being a pain in the ass.

Taking the time to do these exercises to collect and action feedback matter, and the teams that do this well have the results to support.

Onwards and upwards.


On Wednesday February 1st, Nel hosted another retrospective from Acorn's time building sales and outreach related features, along with attending the Qubits conference virtually.

Nel was able to draw an awesome comparison from his own research on quantum annealing to talk about the energy, or effort, we put into the work that we do and the way we pull together. He was able to visualize this principle with the video below:

You can see the full article in the link below for the Qubits event. What's fascinating is the touch points we can bring into our retrospectives from consistently fine tuning our collaboration, checking in with the status and progress of our own initiatives, and leveraging the field notes we take to improve ourselves and our core services offerings as an agency.