Agile and the Chocolate Shop
Agile and the Chocolate Shop
The story of how the former Director of Architecture of Sprint found himself the owner of a chocolate shop, and how it's run on agile methods.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
As an agile trainer, coach, and consultant, I have often worked with organizations that see agile as a software development practice and nothing else. As popular as the talk of enterprise agility has become in the business press, it’s still a rare experience to work with an enterprise that perceives agility as a corporate objective and not primarily an IT thing.
That’s why the story of Nick Xidis, owner of Hazel Hill Chocolates in Kansas, fascinated me. How does a former Director of Architecture for Sprint, and former VP of Application Development at se2, end up as the owner of a chocolate shop? “It’s been my family trade for three generations now”, Nick explained when we chatted. I talked with Nick for a couple of reasons. I’d heard from a mutual friend that Nick was running his chocolate shop on agile principles, which he had transferred from his software development work. Since I’m currently writing a book on enterprise agility, I wanted to see how these principles could apply in a confectionary, seemingly as far from software development as possible.
That’s interesting enough, but there’s an even bigger reason why I wanted to chat with Nick. Hazel Hill Chocolates, with stores in Topeka and Manhattan (KS), had just experienced a couple of downtown restoration projects, one in each city, that illustrated the use of agile principles in an even more incongruous setting: municipal construction.
Let’s see what Nick had to say about transferring agile ideas to the chocolate shop. “We make most of our stuff.” Nick told me. “We have a manufacturing and a retail side. I have a background in agile, and it just made sense to use a lean, agile process to manage that.”
Of course, the columns on Nick’s WIP board are a bit different than those of a typical dev team. Here’s a snapshot of Nick’s board:
“We also have a release planning pipeline on a series of clipboards all over the walls.” Nick told me.
I find, in my consulting practice, that many non-software firms are, consciously or unconsciously, adopting scrum-like practices. I recently worked with a home-finishings company that has also instituted a scrum board, to track the progress of interior design projects through the shop. So the use of a WIP board is not that unusual, although it seems odd in the context of a chocolate shop.
The main reason I wanted to chat with Nick was the other part of the story, his experience with municipal construction in both Topeka and Manhattan. I’ll let him tell it:
“We had a similar reconstruction project in both locations, both downtown rehabs, replacing streets and sidewalks. They were going to dig underneath, and deal with sewer lines and things like that. The folks in Manhattan took the approach of doing one side of the street, one block at a time, going six weeks, start to finish, on each block, and everyone needed to do the work is there. When we get that one done we’ll move to the next.”
“Topeka took a very different approach. They wanted to do a large project, multiple blocks at once, running in stages. Their idea was that this would optimize the contractor’s experience, and so result in a lower cost. Topeka worked on multiple blocks and tore the whole thing up for about two and a half years. It was a very different experience to have things torn up for six weeks versus two and a half years.”
The parallels to agile vs. waterfall are obvious, From the iterative approach, to the cross-functional teams with full responsibility for the outcomes, the Manhattan approach clearly resembles an agile project, while Topeka’s big-up-front-plan was, in my view, destined to create disruption and dissatisfaction.
Nick continued; “In Topeka, as you’d expect, there were times when not a lot was going on, with a flurry of activity as we approached the finish line. There’s a perceived efficiency to the idea of taking these things in large chunks, that really doesn’t play out in reality. The two approaches create a different incentive structure for those doing the work. With a six week timebox to do the work, it becomes very easy to create an incentive for things to be done the way we want them to. With the Topeka approach, you’re creating an incentive for the contractor to fill the space with other work, and the same is true in software development. With the focus factor of short term, prioritized deliverables, you’re not going to find people trying to balance five or ten different projects. I don’t think the kind of work makes a difference, the principles apply whether you’re building roads or building software.”
Imagine the difference for a retail store, having the sidewalk torn up for two years versus a weekend. “As a customer, the impact to me is many times smaller to have an incremental approach rather than a big bang. The financial difference was hundreds of times different.”
Here's a shot of Nick’s Topeka store, where the street was practically inaccessible for over two years:
Nick’s construction story is perfect example of the applicability of agile principles far beyond the IT shop. Construction contracting is not the typical place to look for agility, but, when it is applied, it makes a tremendous difference, both to the customer and the team of ‘do-ers’. For the contractors in Manhattan, the incentive was clear; get it done in increments, bring together a cross-functional team that owns the entire outcome, and deliver value continuously on an iterative basis. For the Topeka team, the incentive was also obvious; low-bid the project to win the work, and then fill it in with more profitable outside work to build profitability. This big-bang approach resulted in distracted workers and a serial approach to delivery, with sewers, cables, and other underground elements done first, then sidewalks and finishing, in an unconnected manner that left businesses high-and-dry and cost millions in lost profits. The end-of-project rush is totally predictable for any project manager that has migrated from waterfall to agile.
Nick made it clear, that, as an ex-IT manager himself, he understood the reasons why each town had taken its selected approach. He was careful not to denigrate either municipality, as they both had reasons, from budgeting to municipal planning, that made their choice sensible to them. To me, however, this story illustrates two important points. Agility can be applied in almost any enterprise setting, and, when it’s applied thoughtfully, can mean greater customer satisfaction, greater team satisfaction, and increased profitability. Those outcomes seem compelling to me, and, I believe, they will become increasingly compelling to every kind of business, from Kansas to Croatia, and far beyond.
Opinions expressed by DZone contributors are their own.