The latest blog post from Mike Kavis on Valpak’s Agile transformation story.
Tag Archives: Agile transformation
I am very pleased to introduce guest blogger, Toby Morris, for this latest post. Toby, known around these parts as “The Amazing Toby”, is a software developer at Valpak. Toby has been with Valpak for many years and has had the opportunity to experience our Agile transformation from the trenches, as the title of this post suggests. Toby gives a (sometimes brutally) honest and extremely insightful perspective on Agile. Enjoy!
Over the past year, this blog has chronicled the Agile transformation of a company from the viewpoint of a self-professed “Agile enthusiast”. So, you have to take those posts with a grain of salt. Of course she’s going to have a relatively rosy version of things, seeing the big picture, seeing how upper management reacts to the change, seeing how the new practices is affecting the quality and quantity of product being produced. But one of Agile’s tenants is people over processes. So to truly judge the success and impact of Agile on a company, you have to get in the trenches and see how those changes are impacting the grunts. From the viewpoint of a grunt, I’m pleased with the change.
To show how things have changed, I have to tell you how they were. Just prior to our Agile transformation, we had several problems as a department. Morale was pretty low, and people were fairly unhappy with their jobs. Our department held a series of meetings to try and find the root of this dissatisfaction. After a few talks, some common themes emerged.
Most technical workers in the department had a director, a manager, and sometimes a lead. Most worked on multiple project teams, and each project team had at least one Project Manager. Each Project Manager considered their projects and tasks to be the highest priority for their teams. People were being pulled apart by competing PMs.
Another common issue was unrealistic expectations for project performance. We frequently worked on projects that were breaking new ground, but were required to make estimates that were little more than wild guesses, and we were held to them. If we “guessed” it would take six months to learn and implement a new technology, but it actually took eight or nine months, we would fail, leaving a shattered trail of disappointed business people and angry project managers.
Along with the missed deadlines, the business was becoming concerned about our ability to deliver quality products in reasonable amounts of time. We constantly ran over, and with every looming deadline, overtime pushes, sometimes all night and all weekend long, were the norm.
When the big leap was announced, there was a lot of skepticism. We were in a very sore spot, and now someone wanted to move our cheese. They actually wanted to replace our cheese with some type of healthy, new age vegetable, and we were scared. We were confused. There was a great deal of apprehension. How could we do everything we’ve been doing in a tried and true Waterfall world in short, little two-week sprints? And even if we could do it, why bother? Would it really make a difference?
Yes, it did.
We went from having multiple overseers to overseeing ourselves. We had one person determining what we’d work on, and we would decide how we did it. We broke big, multi-month projects into small, two-week stories. Some teams even broke them down smaller, opting to work in simulated one-week sprints.
It wasn’t easy to change. We all had to move, physically, to be closer to our teams. And we lost our walls. We moved into more collaborative cube setups. This provided a much more significant benefit than imagined. Sure, we could communicate readily now. No more emails or phone calls. No more standing up and walking across the room to ask a simple question. We could now turn, get the person’s attention and get our answer in seconds. Sure we could more easily collaborate. Having the developer sitting next to the QA, or the front tier, middle tier and back-end guy sitting next to each other, we could make changes and fixes in minutes rather than hours. But the real benefit is camaraderie. These people that we self-organize with become more like friends than just co-workers. A true sense of team starts up, and before you know it, you’re working together more efficiently.
We also had to learn new words and principles and practices. We learned how to effectively scrum each morning. We learned how to write user stories, and break them into actionable tasks. We even got yellow penalty flags to throw at others when they slipped up and let some waterfall back in.
We had a lot of changes.
But we got more benefit from those changes than imagined. Working in small, self-organizing teams, with a single product owner determining what we were working on for the next two weeks made all the difference. No longer did we have ambiguously ranked priorities. We knew exactly what needed to be done first, second and third. No more were we getting constant interruptions and additional tasks from various project managers. What we have to work on at the start of the sprint is what we’re working on for the whole sprint, and heaven help the person that tries to add a user story mid-sprint.
By our second sprint the business had already noticed and welcomed the new process. Instead of waiting months to see anything tangible, and to find out a project would be delayed even further for obscure, incomprehensible technical reasons, they were now seeing incremental upgrades to existing apps and new features being added to new apps on a bi-weekly basis. And even better, their feedback was incorporated into the rapidly evolving applications they depend on. They were helping to shape the tools they use.
Having a business person intimately connected to each technical team also opened the top secret technical world up and exposed our black magic. We gave our product owner an understanding of the whys and hows of software development. There were no longer the “we’re unable to do that for technical reasons”. Now, we would tell him that the protocol we’re using doesn’t support that level of encryption, and that we’d need to re-engineer the system to use a different API to achieve his needs. And that it would take another sprint to discover what that would require. And he would understand what we’re saying, why it’s causing a delay, how long the delay will be and ways to work around it. The smaller tasks and user stories mean smaller and easily recoverable failures.
Collaborative and adaptive. That’s how we work now. Morale from a technical worker standpoint has significantly improved. Our products are visibly more stable, bug-free, and valuable. Our business teams are now part of the team, and believe in our ability to make their jobs easier. We are no longer adversaries. We are agile, not hostile.
The more popular this blog gets, the more calls I get from Agile consulting companies wanting to “help”. That’s sweet and all, but we already work with an Agile coach here in Tampa Bay. Since 2011, we’ve partnered with AgileThought. They have “Agile” in their name so they must know what they’re doing! But seriously, we’ve got their CTO, Ryan Dorrell, as our Agile coach. He has the best bedside manner we could have hoped for and is always the voice of reason on all things Agile. And, Ryan will forever be my Agile phone-a-friend. Our arrangement consisted of customized training, coaching, and strategic guidance, among other things. In fact, our relationship has been so successful that we are submitting for a local collaboration award as we speak. Wish us luck!
Now that that is cleared up, I do want to take a moment to express the importance of having an external / independent Agile Coach to assist and guide your transformation. Attempting to DIY (Do It Yourself) Agile can sometimes backfire. In my experience, money spent on an Agile coach is definitely money well spent! You need to spend the money to bring on an Agile coach for at least 6-months to train the teams and support the process. As human beings, we can laugh about the notion that we are more willing to take advice from a stranger than from a family member. This is true in the business world as well (and that’s why consulting is big business). Companies often tend to appreciate the advice of an independent expert more than a trusted member of the company’s own staff. Also, an Agile coach can really have your back when it comes to resistance at any level.
Now, where I could use some help is if you are an Agile speaker and plan to be in the Tampa Bay area. The Tampa Bay Agile Meetup group is always in need of speakers. It might just be your way of reaching other companies that do indeed help with their Agile transformation. Leave a comment if that opportunity interests you.
I know I’ve been promising this for a while, but now I’m delivering on that promise. I have for you the world premiere of Valpak’s Agile Transformation video.
Give a listen to my guest spot on the Talking Work podcast on goin’ Agile. Enjoy!
Last week, we had three tours in three days around here. Yes, I said “tours”. “A tour of what?”, you may ask. A tour of our Agile transformation! Now, understand you-me that tours are typically reserved for our state-of-the-art manufacturing facility (not a plug, just a reality). At first, I didn’t realize there was much of a show to be had with all our old cubicles and dingy carpet, but apparently I was all wrong. The tours were such a hit that we’re now making a video! Yes, that’s right, a video… an Agile transformation video.
We gave tours to three different groups, two stakeholder groups and one VIP. Each tour began at our local copy of The Agile Manifesto where we explained the values and principles that guide us. Then, the tour moved into our beloved Scrum Pit (a.k.a., “The Pig Sty”) where we used the 9 Scrum Boards to visually eplain how Scrum works. Last but not least, we walked the tour groups through the bullpen areas for 6 of our 9 Scrum teams to demonstrate the open collaboration environment we’ve established.
The mere fact that we had three tours in three days really demonstrated two things to me: 1) Our leadership is proud of what we’ve accomplished with our Agile transformation in just 8 sprints and 2) we’ve really done well by way of “visible information radiators”. Like the old saying, “A picture is worth a thousand words”, a Scrum Board is worth a thousand words too! Our towering walls of magnetic whiteboards with index cards seemingly-chaotic, yet intentionally-placed really seemed to leave quite the impression with our tour groups. I know now that having handed them a document or an illustration or shown information buried in some tool wouldn’t have nearly the impact. Our visible information radiators worked! At the time of the tours, we were mid-way through the 8th sprint across 9 Scrum teams, and progress (or lack thereof) was clearly visible within a 360° view of the Scrum Pit. I guess what I’m getting at here is simple … When your hand gets tired of writing story after story or task after task and you’ve got paper cuts on both hands, just remember that a well-constructed, well-maintained Scrum Board is the ultimate visible information radiator and worth a thousand words.