Have you ever had a moment when you find yourself wondering if you’re doing the right thing for your business? Likely, you have. We all do. As experts in the technology world, we are pressured daily to evaluate every business decision we make – and it can be difficult to know the right direction to pursue. If we ask this question of the Magento eCommerce community, it usually starts to trigger questions like, “Should I upgrade to Magento 2?” or “Should I write this integration from scratch?” or most often as an agency, “Is this the best use of time and effort for my client?” And finally, “Are we being Agile enough?”
Additionally, we might discover while navigating through this new territory that we ask ourselves what the best decision for all of our clients will be. Are these integrations going to be sustainable and reusable?
At Human Element, it was at this point that we began considering a change to benefit both our internal team and our clients. We looked at a number of options similar agencies employ including Agile, Kanban, Waterfall, and a simple revision of our existing structure, all in an effort to answer the ultimate question: What is the best way to build software and deliver to satisfied clients from a service-oriented perspective?
After significant discussion and consideration, our team decided that the best approach would be in utilizing a rather “customized” variation of Agile’s Scrum. These are the highlights:
What is Agility?
Before we answer this question and look at the Human Element solution, let’s back up just a little bit and talk about what Agile is. There are four main tenants of an Agile Technology process from the Agile Manifesto perspective.
1. People and Interactions over processes and tools
2. Working Software over comprehensive documentation
3. Customer Collaboration over contract negotiation
4. Responding to change over following a plan
When thinking about how these values intertwined with our own company Core Values, we came up with a list of intermingled values that connected with our team.
- Individuals and interactions over processes and tools
- Always do the right thing
- Respect for people and ideas
- Encourage work/life balance
- Always look for a better way (internal focus)
- Working software over comprehensive documentation
- Always do the right thing
- Keep the bottom line in mind
- Always look for a better way (internal focus)
- Customer collaboration over contract negotiation
- Always do the right thing
- Take ownership, recognize ownership
- Take responsibility
- Responding to change over following a plan.
- Take ownership, recognize ownership
- Take responsibility
- Keep the bottom line in mind
- Always look for a better way (internal focus)
Understanding this at a fundamental level gives us the cultural foundation for applying an Agile structure that we can then build processes around. That doesn’t mean that these problems do not have a high degree of complexity, but we can agree that everyone is looking for the best way to deliver on the promise of functional technology. In the end, these answers should be separated from the business decisions and budgets around each individual project. No one has the definitive answer to the question “What is the best way?” But being able to create something that works for your organization is the key, and in my opinion, that is what being Agile is all about.
What does this Agility mean at Human Element?
The bottom line is that everyone wanted to do the right thing for our clients. And everyone wants to do this while working with people that they like. They also want to keep growing, learning, and making our culture thrive. The only kicker that we had to keep in mind was the bottom line and the happiness of our customers.
While talking with Pete Behrens, about leading the organization through this shift at his CAL Training, hosted through Michigan Technology Services, we looked at a couple case studies of software organizations that excelled at the transition to an Agile development methodology.
Inside-Out adoption aligns Agile to the organizational culture and supports it with appropriate structures and practices.
The theme that echoed throughout these successful case studies, was that each transition was led by leaders who tried to make Agile their own through what Pete would describe as “Inside-Out (Cultural Alignment)” adoption.
They were not concerned with the naming conventions of the processes they used, they were just trying to make sure that everyone in the organization could do their job effectively. There are a lot of great examples out there, like this one from Spotify, that describe what that transition was like and why it excelled. In the end, they “owned” the Agile process and created their Scrum practices around what they began to call the “Spotify Engineering Culture”.
Leading Human Element through the Transition
Change happens. Transitions are optional. Transition is psychological and people transition at different paces. Focus on the goal and the journey.
Armed with the conversations that we had with our team members and the shared goal of enhancing culture and delivering software to our clients, we began the transition. What we realized right away, however, was that we were pushing towards a goal that began to be labeled internally as “The New Process.” With that label came attached perceptions, hear-say, telephone conversations, and a variety of issues that were plagued by bad communication. People were a little uneasy about the transition and we realized that it was going to take time for people to come to terms with the change.
It was then that we understood we were going to need to own the process and make it our own. We could not be held down by interpretations of Agile and Scrum. So what we decided to do was to name the process. At this point, the “New Process” died and the “Catalyst Process” was born.
It’s not a new process, it’s our Catalyst Process.
Through the creation of the Catalyst Process, we kept coming back to a few key areas of conflict which were all focused around trust, communication, and flexibility. There were factions of the organization that felt like they had been burned in the past from changes like this. Trying to steer through these waters was challenging at times, but we kept focus on a few key items.
- Being Agile is more than using Scrum
- Focus on guiding internal change
- Make adjustments to culture, structures, and processes
Of course, we were not going to get everything right out of the gate, but we wanted to make sure that everyone understood that there would be a way to correct and adjust as we moved along.
Unleashing the Power of Catalyst
This bring us into the implementation of Catalyst. We started into our sprint cycle on a Tuesday, with the previous Monday set aside for team resource planning. During the Sprint Planning meetings we incorporated retrospectives and previous sprint ratings. In addition, we were rolling iterations of the Catalyst Process on a monthly basis. What we have ended up with is a hybrid approach that fits into the Human Element toolkit. We are seeing improved implementations with most client requests and general happiness from the team on the Sprints. There have been a few bumps, but with an emphasis on communication, we have been able to successfully overcome all of the hurdles without having any major hiccups in releases to our clients’ production environments.
Every implementation of process change in any organization will inevitably lead to issues, but as long as your focus is on your people and culture, everything else will flow out from that.
Special thanks to Pete Behrens for his CAL training and permissions to use content and imagery in this article.
