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:
with that...
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.
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.
Photo by Joshua Rodriguez on Unsplash
To start, let’s get into the weeds on what Acorn set out to do.
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.
Photo by Jason Goodman on Unsplash
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.
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.
With our sales engineering plan setup, we could build application designs, user flows, pages, and forms to support the outcomes we want - generating leads.
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.
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.
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?
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:
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...
Building data models is important for several reasons:
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!
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.
Resolution:
Why are communicating priorities important?
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
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?
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.
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.
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.
And that's it! We were able to
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.
