Lessons From My First Attempt At Bringing Agile Into A Non-Agile shop.

Since I’m moving on from my current employer I figure now is a great time to share my post-mortem of my time there, specifically what worked, what didn’t and what did I learn.

Iterations Of Any Length

We tried 3 weeks, 2 weeks, 1 week, monthly and eventually just sort of tossed the system out all together as our team got shrunk from 5 to 2.  We did find get a fairly desirable result ultimately but more on that later.  Ultimately our problem was especially as we got smaller, dealing with our “particular” realities made iterations tend to fall apart, we were spending a fair amount of time trying to torture ever more atomic stories together.  Cutting iterations out all together and focusing on features being completed was MUCH more time effective for us.

Continuous Integration

We had 3 different build servers at various points. All worked well, and our scripts were build server agnostic enough to not take long to switch over. There was a bit of a learning curve with some projects and the build system (modular dll’s and app domains especially).  While in the end this worked well for our purposes, I failed in sharing the knowledge here, and never figured out how to get other members of the team to get up to speed on the entire build server concept . 

Note: oddly no “build applet” was nearly as effective at letting people know the build failed as sending them an email automatically on failure.

TDD, BDD And Unit Testing

Very mixed bag here. I was successful in getting the concept of unit testing in, but not TDD.  However, our tests still are not totally flexible, and the training to do that is significant (creates dependencies on a fair amount of knowledge not specifically related to testing).  For my part it honestly took me a year to be able to write a test that was not brittle. 

I’m still a bit stumped how to get a typically trained Microsoft developer team to really dive into the concept of TDD, “writing the code you want” was met with blank stares.  Data driven mindset was maintained to some degree throughout my time there.

BDD took me awhile to get something I felt comfortable with so I don’t think I trained with the proper approach. I emphasized specification and example a lot and for some reason this lead to everyone striving for functional tests. 

Finally, handing customers spec results was somewhat helpful. Still had some things “be fine” then “that’s not what I meant”, but it still cut down the amount of misunderstanding.

SOLID Principles

This was the easiest thing overall. DIP and IoC was resisted heavily at first, but it was not much effort to come up with scenarios where it was patently obvious how much more flexible code became.  I focused a ton of “different data sources” since we have a number of api’s we deal with that gave me the buy-in I needed.

SRP took a bit but once they got it they got it big (almost too well). Ultimately, I think the dev’s enjoyed having “another box to check off” as they finished each class.  Resharper training also helped cut down the time to make classes and methods I believed this also had a role in SRP adoption.

OCP came with focusing on IoC and DiP so heavily.

LSP only came up occasionally since we tended to have a lot of small classes.


YAGNI – Always fought this myself, and correspondingly my team struggled with both as well.  YAGNI by the end started to work just because I began stripping out all extra requirements full stop, and immediately stopping any development when “extra” features were added out of the blue by an enthusiastic developer. This took a heavy hand and vigilance, and convincing was less the issue than fighting habits developed over years.

DRY – Was especially rampant in our test code, and we had our bits of duplication across projects and different developers. Like our YAGNI violations I think this was years of habits holding us back.

Automated Acceptance Tests

Never got close. Not enough stakeholders were interested, the training on acceptance tests ran into the same problem I had with build scripts that no one understood systems enough to make this function properly unless I was involved heavily, and then breaks also required my involvement. Finally scrapped them and moved to specs and manual acceptance testing by the stakeholders that cared about it in the way that they cared about it.

Release Frequently Release Often

The more we released the better it worked for us. For us there was a clear link between stakeholder satisfaction and frequent releases (10+ some weeks). I have a few theories about this:

  1. We had stakeholders with various levels of comfort on their subject matter. Domain experts that knew everything about their domain did not need as much “final product” feedback as some others, who really were only happy when they saw the end product after every request.
  2. Most of our projects had few moving parts. The tendency of past development seems to have been drawn to complexity, even when the raw domain didn’t need it.  Simple projects can be released more often when less moving parts are there to break.
  3. Our stakeholders seemed to be far more results driven than UI driven. We seemed to attract a lot of process driven people who were content with having a lousy limited UI as long as the file went out in the correct format. We could again release more often with a stubbed in UI without any real penalty, as ultimately they just wanted at least one front to back business case working.


There is more that I’m sure that I’m missing that may be useful. In the end, I was disappointed in my attempt to move the shop to an Agile concept only because I was not able to spread the knowledge effectively. My inexperience at the time in Agile myself made it rougher on everyone else trying to learn from me.

If I had to do it over again, I’d focus on SOLID, YAGNI, DRY and training a systems administrator in build scripts (it’s just a hard skill set for the average MS developer), and of course release often. If I had focused on these things first the immediate dividends would have been far larger.  Once they had the necessary engineering credentials, TDD would have been less of a time sink, and maybe we’d have had the discipline for Iterations.  Someday I hope to have the opportunity to build an Agile team from scratch again.  I’m grateful to my employer and my co-workers who gave me the opportunity to try and advance things forward (which we did, just not as far as I would have liked).

About Ryan Svihla

I consider myself a full stack polyglot, and I have been writing a lot of JS and Ruby as of late. Currently, I'm a solutions architect at DataStax
This entry was posted in Agile, Lean. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • martin

    So tell us why did you move on and what are you doing now?

  • Thanks for post-morten, Ryan. There’s a lot of good ‘rubber-meets-the-road’ information in here for anyone trying to introduce these principles into an established shop. I found myself nodding along several times. I also found a few explanations for things I’d witnessed myself but not understood why yet.


  • Rackspace http://www.rackspace.com provided a much stronger opportunity for me in a LOT of ways. I start in a couple of weeks and I am very anxious to sink my teeth into the technology there.

    Farm Bureau Bank was a great experience for me, I’m very grateful for what they’ve done for me and its a place where I grew leaps and bounds, but after solving our maintenance issues (from 60-80 hours of dev time a week to 0-4 hours) I’ve run out of interesting problems to solve.

  • Ryan,

    Excellent post. It sounds like you did an excellent job getting agile/lean development started. As far as iterations go, we started with 1-week and tried 2-week and 3-week. Eventually, we started reading about Kanban and lean, which led us to no iterations. Why may our customers wait 3 weeks? Now we realease as soon as we have something that provides business value.

    Again, great post. I hope to see more of these from people as they try to implement agile processes where they work.


  • Louis Salin

    Great wisdom shared here. Awesome! Thanks for the info.

  • jdn

    “There is more that I’m sure that I’m missing that may be useful. In the end, I was disappointed in my attempt to move the shop to an Agile concept only because I was not able to spread the knowledge effectively.”

    I don’t know, it sounds to me like you accomplished quite a lot in a relatively short amount of time.

    And that’s coming from “the glass is half empty” guy.

    You should take pride in your efforts, I think.

  • @JDN i don’t think I did a very good job of explaining what I was disappointed about.

    I was pleased with everyone’s efforts and the things that did end up working out very well in the end (release often, SOLID, feature based releases). I was also very pleased with how well we did considering the big deck we had stacked against us (majority of all development time was maintenance).

    I was not pleased that I was unable to transfer more knowledge. Therefore, I’m leaving some heartache behind because of it. Whats the point of building something that won’t be able to be maintained? I’m confident the staff here will step up to the plate and it’ll all work out in the end, but I certainly made it harder on them than I would have liked, and that’s where if I had a chance to do it over again I would focus things.

  • release often

    Agile shop customers view: Release Frequently Release Often = excuse to release shit.

  • @release often
    Well that’s one perspective. It may be true where you are but not so much for us.

    In our case we tried longer (1 month) release cycles and feature based ones.

    Customer satisfaction rose greatly when we shortened our cycle, and continued as we implemented feature based releases. Also, overall feature implementation time is lower on average.

  • “Note: oddly no “build applet” was nearly as effective at letting people know the build failed as sending them an email automatically on failure.”

    I don’t think that’s that odd: emails have a certain taste of “officialdom”, which forces people into action. Of course, if you bombard them with too much email, the taste wears off…

  • It’s always good to hear other folks real life experiences. Much of what you say is exactly the kinds of issue I’ve had too. What particularaly resonates is trying to introduce ideas, when your no an expert yourself. Very real for me too.

    For me though I would not give up on introducing the unit testing (even if you don’t push full TDD). The thing is that testability has a major architrectural impact. Folks won’t understand the advantage of say DI, unless there trying to unit tests.


  • @mat
    introducing TDD or SOLID first is major topic of discussion and a lot of smart people disagree. I can without any shadow of doubt say in our situation it was a disaster to teach TDD first and SOLID was trivial to teach even though they never got “testability” fully. What progress we made in testing was AFTER a full on introduction to SOLID.

    We did teach TDD first and for many months with limited progress, because they didn’t have the engineering skills or feedback skill set to pick it up. For me it was definitely easier to learn TDD first, and with my sysadmin testing-verifying oriented background. I’m reasonably certain for different groups and backgrounds the appropriate answer is different.

    For this group DI just involved showing how to cut down lines of code, and make flexible changes when the inevitable frequent change requests came in. Tying this in with Windsor, ActiveRecord, Monorail, AOP logging and security. I sold the toolset instead of just the approach.

    Thanks again for the feedback, and i know this is a debate where my opinion on things is just an opinion and not hard fact.

  • Alex Mancilla

    I was part of the Experiment that Ryan performed(for about 6 months or so), I’ve read this post and I just feel like , in the technical aspect is covering almost everything, but there were some other aspects in the interpersonal level, that also affect the reaction on the team and how easy they can embrace one’s Ideas, I like this part “Thanks again for the feedback, and i know this is a debate where my opinion on things is just an opinion and not hard fact.”
    Because when you try to make the people change their mindset, there’s always some pride and Ego involved, some people recognize a good Idea in the voice of other, and some people need to hear it in their own voices, so then It’s not good Just because, someone else said so but because they said so. What I mean is, in order to create an agile group you should first sell the IDEA to the agile-to-be group, and the same goes to TDD, SOLID, and whatever else you want to add. People should embrace those Ideas as actual better ways to develop software.
    It happened to me, I didn’t see anything wrong on my classes and my Manual testing, and seems to me that Unit Testing was an extra burden. Until I forced myself to forget what I’ve learned before, and open my mind to this new Ideas, gave it a try, Read some good books, tried the samples and then I saw the benefits for myself, there it came the epiphany “This is Actually good” I remember I said to myself(and to Ryan later). And form that moment my point of view was changed, my approach to unit test and code changed too. I was willing to go all the way with the agile Thing.
    I’m really glad I was part of the experiment, It certainly changed my “developer lifestyle” I’m very thankful with Ryan for expose me to this Ideas and technology. I think the most valuable lesson for me was focus on the Idea/Concept/Methodology not the tool. And As Agile Joe says “Agile is not the Silver Bullet …It Depends”. Where I’m working now they’re trying to go Agile, but they aren’t there yet, and there’s mostly because they haven’t mastered the Unit Testing, Actually they have mostly automated Integration tests not really unit tests.