Monthly Archives: April 2013

Agile Transformation: From The Trenches

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.

Advertisements

“Agile just doesn’t work for us”

I bet I grabbed your attention with that title.  Before you proceed on, please be warned that this post is definitely more of a rant.  But, if you can’t occasionally rant on your own blog, then what’s it good for anyhow?

To those that say “Agile just doesn’t work for us”, I say bullshit!  For some reason, some people think their company / organization / product is so different from the rest of the world that a process like Agile will not work for them.  When it comes to work, we are all more alike than different.  Those same people tend to look for every opportunity to blame any issue on Agile.    The team didn’t get a user story done … “Agile just doesn’t work for us”.  A stakeholder made a late change … “Agile just doesn’t work for us”.  I can’t make it to the stand-up on time … “Agile just doesn’t work for us”.  We had a bad retrospective … “Agile just doesn’t work for us”.  We deployed a bug to production … “Agile just doesn’t work for us”.  It rained today … “Agile just isn’t working for us”.  You get the point, I’m sure.

Now, don’t get me wrong … I totally get statements like “This isn’t Agile” or “We aren’t being Agile”; that, I can deal with.  Just don’t make rash statements that insinuate that the process is to blame for what is a problem that would / may exist regardless of Agile.  In other words, don’t hate the process, hate the weaknesses in ourselves that the process exacerbates … whatever it may be, lack of discipline, poor collaboration, no accountability, bad leadership, etc.

Dig deeper beyond the rash statement and you will find that often it is not the process that doesn’t work for us, but rather we don’t work for the process.  When I hear “Agile just doesn’t work for us”, I like to probe further with questions like …

  • What specifically do you think is not working about Agile?
  • What have you done to try to solve the problem?
  • Would this / did this / could this problem exist under any other process?

So, to all those that are quick to say “Agile just doesn’t work for us”, don’t be a hater.  Look within your own locus of control (never thought I’d have the opportunity to use that phrase beyond college) before you jump to judgement about a process that has worked successfully for many diverse companies all over the world for many years.