Tangram Flex is excited to continue the multi-part series about bridging the treacherous gap in...
In this post, Fred Gillenwater, Product Manager at Tangram Flex, writes about our hackathon-style events at Tangram Flex and how we approach engineering discipline, user experience, and product development with curiosity, empathy, and deep understanding. Fred brings a diverse background in education, curriculum development, and business strategy to the Tangram team and uses his keen eye for customer experience to improve our solutions and the ways we build them.
In early 2020 we added a new ceremony to our agile development cycle at Tangram Flex — the Integration Event. Our intent was to create a team-wide event every three weeks to test out newly developed features. As Integration Events evolved throughout the course of the year, what emerged was the most important thing we have done in the past twelve months. We found what Forsgren said to ring especially true:
“Our analysis is clear: in today’s fast-moving and competitive world, the best thing you can do for your products, your company, and your people is institute a culture of experimentation and learning, and invest in the technical and management capabilities that enable it.”― Nicole Forsgren, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
A New Ceremony
So, what is an Integration Event? At Tangram Flex, our Integration Events are calendar driven and product focused. Our engineers working across a range of feature development and customer program teams (and even some of our product team members) are placed into mixed-ability group and given a scenario to work through. Scenarios range from challenge problems that our customers are facing to product and feature use cases — but in all of them, relevance to real-world customer concerns is paramount. Exercising user empathy helps us identify areas of our product that can be improved for users (such as reducing the number clicks to complete a task or finding a way to make someone’s first 30 seconds in the product intuitive). While each scenario frames the job to be done during the Integration Event, it’s actually just a vehicle to achieve shared understanding.
Shared Understanding
If you’ve read The Phoenix Project, you might remember Brent. Brent is the go-to guy for fixing all things IT. His knowledge of the enterprise system is unrivaled. He unclogs server pipelines. He puts out fires. He knows that to “start the car” you have to pump the gas pedal three times and gently press the gear selector toward the “P” so that the relay switch registers that the car is in Park and ready to start. Wow, what a guy! What would we do without Brent?
The problem is that having a “Brent” on your software development team is really just a fix that fails. Why?
Well, someone like Brent blocks shared understanding. He can fix the immediate surface level problem and put the fire out, but Brent is unable to address the systemic patterns that caused the fire in the first place. All the knowledge on “how to start the car,” or fix the server, is in Brent’s brain. Brent is a bottleneck. Brent doesn’t scale. Brent is actually a fix that fails because he is the choking point for shared understanding.
Now consider how quickly the “Brent Method” would dissipate in Integration Events. Integration events distribute the knowledge to the rest of the team and prevent over-reliance on a “Brent”. Integration Events generate shared understanding. This shared understanding provides tremendous benefits: Developers gain greater visibility into the system, or in our case, the product as a whole. When every engineer uses the product every three weeks in the context of a customer relevant scenario or challenge problem, the purpose of their code becomes clearer. No longer is the structure and function of, say, how the frontend queries the backend in the head of just one or two engineers. Instead, there is shared understanding across teams regarding specific capabilities and features.
In other words, Integration Events at Tangram Flex work to avoid creating “Brents”.
Teams of engineers share ownership over the development and deployment of code. They know and understand exactly where the application or feature they are building will live and how the user will experience it… because they have experienced it! More importantly, they are taking ownership of the whole product rather than simply the piece they are developing.
Distributed Learning
It’s not only about the product. It’s about the team.
While Integration Events include carefully constructed scenarios that promote shared understanding of the product, pairing engineers in mixed ability, cooperative settings to promote technical breadth has expanded each individual’s “island of knowledge”.
What does this look like in practice? In a recent Integration Event, we worked together on a DevSecOps challenge. The scenario involved smoothing out the deployment of Tangram Pro™ with the use of a Helm Chart. Helm is effectively a package manager for Kubernetes. The Helm Chart treats collections of Kubernetes resources as a package, can use published packages as dependencies, and may implement hooks for upgrade, deployment, and rollback.
Testing our Helm Chart was an obvious benefit to this Integration Event. Customer benefits were also well known — using a Helm Chart, our customers will be able to independently deploy Tangram Pro™ or bundle Tangram Pro™ in their Infrastructure-as-Code (IaC).
So, why include Tangram Flex engineers that specialize in embedded systems and write C++ code in this Integration Event?
It turns out Helm Charts provide an additional benefit. With k3s and Helm, Tangram Flex engineers can have a locally-running Tangram Pro™ environment against which they can integrate and test! Echoing again the wise words of Nicole Forsgren,
“Developers should be able to run all automated tests on their workstations in order to triage and fix defects. ― Nicole Forsgren, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organization
When every engineer experiences this benefit, every engineer can begin to see the value of DevSecOps for developing and deploying more secure software. Having participated in this Integration Event, our engineering team, even those who don’t have backgrounds in DevSecOps, can shift testing to the left. This is far more powerful than having one “Brent” on the team that knows Helm!
Ritualized Feedback
Have you ever been to a major league baseball game? If you have, you know exactly what happens halfway through the 7th inning. As if reading from a script you stand up on cue and sing the hymn of baseball right alongside the crowd of fans. The words are comforting and familiar to the insider, but unknown to the first timer. What’s great about rituals like the 7th inning stretch is that they are reminders of the culture in which you are participating. Rituals like this provide cultural continuity and shape identity. “I belong to this group of baseball fans and I know that because I am at the game and can sing the song.”
Our Integration Events aren’t complete without structured feedback. Even though the scenarios are always slightly different, our team knows what to expect every third Tuesday when it comes to feedback — just like baseball fans knowing exactly what to expect mid way through the 7th inning.
At the end of Integration Events we block 30 to 60 minutes to allow for engineers to report out their feedback. Comments might be about the Integration Event itself. This is helpful. It improves the timing, pairing, and scenario creation. Most importantly, however, feedback is about the development work that just went into the product. This feedback is more than helpful, it is incredibly powerful.
Because the feedback is relevant, specific, kind, and immediate, teams can process the input and adjust their work accordingly. If the change is small, it can be made quickly and be tested and deployed before the release candidate is cut. If the change is big, it can be explored thoroughly and incorporated into a future sprint. This also accelerates development and delivery. Most recently, the accumulated feedback over multiple Integration Events led to one feature team dedicating time to pay off some technical debt. With teamwide understanding resulting from Integration Event feedback sessions, other members of the team understood how taking the time to pay that technical debt would improve features for our users. Not only did we address a systemic issue in our product, but coordination for that sprint was proven effective by our burndown rate and avoided unplanned work.
Like “buy me some peanuts and Cracker Jacks,” our engineering team now expects to both give and receive feedback that will positively impact the product.
A hard habit to build, but worth it
Keep in mind this did not happen overnight.
Consistency on the part of engineering leadership to plan and execute Integration Events modeled a commitment to their principles. A curiosity and the willingness of the broader engineering team to embrace change while having their work on display in front of the entire company was critical. A culture of learning resulted, but so too did a culture of accountability centered around feedback.
To be sure there have been costs and trade-offs. Planning. Executing. Prioritizing engineering hours. All of these were reasons to not do the hard work of building this company wide habit. But Integration Events have gradually transformed from a “have to” to a “want to” across our growing team.
“Improving by 1 percent isn’t particularly notable — sometimes it isn’t even noticeable — but it can be far more meaningful, especially in the long run. The difference a tiny improvement can make over time is astounding…What starts as a small win or a minor setback accumulates into something much more.” James Clear, Atomic Habits
And while it has taken a little over a year to see the results, Integration Events are the habit that accumulated into that something much more.
Shared understanding, distributed learning, and ritualized feedback are helping us align the work we do with the principles and values we profess, ultimately for the purpose of safely and securely developing and delivering software to systems that matter — because every mission deserves access to innovation.
Tangram Flex simplifies software integration for mission-critical defense systems. Every system is unique, but the mission is clear: the people on the ground need dependable, adaptable equipment to get the job done. At Tangram Flex, we understand the challenges of security, speed, and safety. Our team combines engineering expertise with our Component Software Integration Platform (CSIP), Tangram Pro™, to arm engineers with customized toolkits for meeting mission needs.
Tangram Flex is headquartered in Dayton, Ohio. Our staff has experience from DoD, Fortune 500 companies, and innovative software startups. We are dedicated to walking alongside our customers to keep pace with changes in technology. Get in touch: hello@tangramflex.com.
