Now a good friend of mine, and colleague that I learned agile and scrum under just wrote a great blog post on how to communicate the need for agile to be introduced in an environment where there is resistence. There is some great advice here for that particular topic, but for this post I am going to talk about my experience bringing agile to a company.

I was very fortunate in that I was brought in to the company that I work at with this specific purpose in mind, how to move us from being a service based company to one that had more focus on product development and more so how to increase efficiency and how work flows through the company.

Now that being said, your probably thinking “wow, talk about the dream job, you get to come in, with a mandate and with very little resistance or push back”. Well your wrong. Just because everyone agreed that we would do this and we were all on board there is still a lot of work that needs to be done to educate management.

Educating management is a whole different beast. Were not talking about getting them to learn new concepts, operate as a self managing team. Were talking about getting people who run a business to completely change the way they work. Gone are traditional functional specs in, is customer collaboration and just in time planning. No more cowboy coding and long ridiculous hours in, is doing things right, negotiating with your team. Out goes control and in comes trust.

That last idea is always the major sticking point i’ve found, the one thing that takes the longest time but has the largest amount of benefit in the end. When you trust that your team is going to to do what is best for the business and what is best for the team you are going to start hitting your agile stride.

Now one last point before I finish up. This relates to managing an agile team but it’s something that I’ve picked up over a couple of years of experience in working on agile teams. A successful agile implementation makes your development team very happy, and in turn keeps a lot of your employees right where you want them. In your office churning out amazing work. I’m not sure if employee retention was a desired outcome of running an agile shop, but in 3 years at my last job we lost one scrum master and one programmer before I left. 3 years and only 2 people in the dev team left (and the reasons weren’t all related to agile). Everyone running a business knows that one of the silent killers is employee turnover, it costs a lot of money to find train and get new people integrated into a team. Especially in the development world these types of turnover not only cost the company money but it introduces all kinds of other delays and issues.

So am I saying that by implementing agile at your shop your going to instantly have a bunch of super happy developers that never want to leave?

Well that’s entirely up to you! If your a large company, grab a small team on a small project and let them try agile. If your a small company, get your entire development team on agile right away, let them try, let them fail and most importantly let them learn.

Oh, and don’t forget to take some notes yourself, agile doesn’t just work for developers you know…

“Individuals and interactions over processes and tools”

But anyone that has done any work in an agile shop knows that to achieve many of the goals of agile you need to have certain types of tools in place to facilitate the process.  This past week I have been preparing for the start of our first sprint this Monday.

What I’ve been doing is picking and choosing tools to help implement many of the details in agile, here are a list of the tools that I’ve chosen and what aspect the process they fulfill.

• Google Spreadsheets – for user stories and task breakouts
• Google Sites – for tracking stand-up notes and logging issues
• Beanstalk – hosted subversion for well, subversion.
• Team City – continuous integration and deployment

In subsequent posts I’ll go into more detail about how I’m using each of these tools, and if i’m actually still using them.  One of the amazing things that I have found when working in an agile environment is that the process makes people far more open to change, so if we find a better tool to fit the need then we will switch to it.

Today was our first team (3 of us for now) lunch and learn.  We reviewed the first chapter of the Foundations of programming pdf.  The other 2 members of my team are junior and intermediate developers and I’m actually relishing the opportunity to share some of the things that I learned in my time at Q4 Web Systems (where i worked in an agile environment for 3 years).

I actually started infection the company with agile quite some time ago, from the top down.  I was brought in to take the company from a strict marketing company to one that focuses more on product development.  This is a big step for me and I’m committed to making it work.

Next up I’ll review our first sprint mid week and let you know how it goes!

This is the first post in what will become a long running series on how this process has gone, it’s part content generation for this blog, part help and advice for you the reader and part excersize for myself in tracking the progress I make.

Hope you find this helpful!

I have an exclude file that I use to tell xcopy to ignore files like the obj directory and .cs codebehind files.  I noticed that none of my .ascx and .css files were being copied?!  Turns out the .cs entry in my excludes list was causing those other files that had .cs in the extension not to get copied.

The solution?  Add a backslash to the end of the .cs entry so it looks like this:

.cs\

All your other files with .cs in the extension will now get copied.

Hope this helped someone!

You are going to fuck it up

Now I use the phrase “fuck it up” in place of fail for effect, for impact, ya know if this was a power point there would be one whole slide dedicated to the phrase “you are going to fuck it up” yes, that lesson is that important.

Now you might think what a great way to instantly ruin any project! So what your telling me Chris is no matter what, I’m going to fuck this project I’m about to start working on up?

Yes, that is what I’m telling you… But, its not the only thing that I’m going to tell you.

There’s an expression that’s become increasingly popular in the development world as the popularity of agile and lean development rises.

“Fail early, fail often”

It sounds so insanely wrong so anti everything you’ve ever learned doesn’t it?  Once you get over the stigma of failure you’ll quickly realize that failure isn’t as bad as you’ve been conditioned to perceive it.  Early failures cost less both in financial terms as well as in more personal ways that we won’t touch on here.

The concept of fail early, fail often is wonderfully summed up (quote stolen from codinghorror.com)

Learning doesn’t happen from failure itself but rather from analyzing the failure, making a change, and then trying again. Over time this gives you a deep understanding of the problem domain. (Michael Hunter on fail early and often)

I sum it up a bit differently: “The only real failures are ones that you don’t learn from”

So go out there dev’s and fail away, not only are you going to understand more about the stuff your working on, but you’ll likely discover more about yourself and the people around you as well.

Like all good agile practitioners, we set out some guidelines at the start of the meeting. We would time box each story discussion at 8 minutes and then move on. As well, we decided that each team member would take turns reading one of the stories so that everyone was involved and engaged. We started out well and made some progress but it was obvious that things were coming off the rails, and fast. Team members were getting frustrated, a couple of members were just pointing stories really high because they weren’t understanding the business value that each story conveyed (the product owner was present, and the team had met previously and discussed the stories in a brain storming capacity), the product owner was getting more and more frustrated, the team members quickly lost interest and everyone left the room feeling a bit worse for the participating.

I thought I would highlight some of the issues and try to address them:

History repeating
Some of the team members had worked on implementing the feature that we were pointing in the meeting in a past iteration of the project. The attempt failed costing the team of 3 people a months worth of time. It was obvious that this weighed heavily on those specific members and it was influencing there estimates. Understandably one can be sympathetic of this attitude, failing at the same thing over and over again is demoralizing and soul crushing. The thing is that scrum accounts for failure as long as you learn from it, I think though that this issue is a very difficult one to get past and I can’t really criticize too harshly on the topic.

Breaking the law
After the first story was done and pointed in the time allotted, we quickly ran overtime on the second and it just got worse for each subsequent story. We had completely ignored what we all agreed on at the start of the meeting and it turned a 30 minute exercise into a 90 minute marathon. I think in this case sticking to what we agreed to at the start would have made for a much more satisfying meeting, I think the desire to please the product owner and get the stories point outweighed the obvious fact that we weren’t doing a good job pointing them. I think in retrospect we should have just stopped the meeting and moved onto other work and reconvened another day, it probably would have saved a lot of people a lot of time and energy. This is something to try next time for sure.

A couple of interesting things happened later in the day that this meeting took place, my co-worker Jason Little wrote a blog post talking about this exact topic (I think the meeting had a pretty deep impact on all involved), go check his post out .

The other interesting thing is that I caught a tweet on twitter that stated “storming is the most interesting part of team formation”. This kinda made me think for a second, so I Googled the term and came to this interesting wikipedia page. The really interesting bit for me is the entry on storming:

The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Tolerance of each team member and their differences needs to be emphasized. Without tolerance and patience the team will fail. This phase can become destructive to the team and will lower motivation if allowed to get out of control.

This so quantified the exact feelings I was having about the meeting, it really reassured me that this is a normal process and it eventually leads to bigger and better things. It certainly made me feel much better about the situation and that we can and will progress past that stage onto more productive and fulfilling team situations.