Infecting a team with Agile: Part 4:

By jonezy | Published: January 26, 2010

There is no part 4, things fell apart when it actually came time for me to start writing code again.  With nobody to keep the agile push going it just died.

I am really bummed about it, we have still kept a few of the philosophies around in spirit, but all of the practical implementations are gone.

I’m very lucky in that where I work there is no real waterfall type planning either,  either individual developers or small teams of 2 are left alone and trusted to do the work (example of one of the philosophies that existed before and after trying to adopt agile) so there is little time for gantt charts and all that other nonsense.  We like to get work done :)

So i’m going to shift focus again on the blog.  Not sure what that focus will be but for now let’s just see what happens.

Posted in agile-series, jonezy.org | Leave a comment

so

By jonezy | Published: January 14, 2010

i tried upgrading my blog here to 2.9.1 but i couldn’t because the version of mysql 1and1.com is using is too old.

completely fucked i tell ya.

Posted in Uncategorized | Leave a comment

Infecting a team with Agile: Part 3: Educating Management

By jonezy | Published: November 25, 2009

In part 2 of the series we reviewed some ways to bring an inexperienced development team up to speed on some of the core concepts and fundamentals of agile. This week we will talk about the same topic but with a different target audience. Management.

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…

Posted in agile, agile-series, work | Leave a comment

Infecting a team with agile “Part 2″ – Education

By jonezy | Published: November 11, 2009

In part one of the series I covered some of the preparation I had to go through to start on the journey of getting my new team infected with agile. Things have been going ok, there are some improvements to some of the tools I would like to see, but hey that’s the point right? If it doesn’t work ditch it for something that does!

In part two, we are going to talk about some preparation that I am doing with my dev team.

To give some background, I work at a marketing company in toronto. Previous to my arrival the majority of the web development that was happening was doing one off service based work for clients, nothing wrong with that but the boys wanted to take things to the next level, be more efficient, start working on bigger more exciting projects, and that’s where I came in.

Getting back on track, the team I was brought into, while passionate and hard working had never really had any exposure to (for lack of better wording) real programming. The kind of programming that happens in agile environments , things like TDD, object oriented programming, pair programming, code reviews, source control, build servers, automation… you know the stuff that makes working fun!

Learning all this stuff is a daunting task on a good day! Having been through this process myself before I felt I could help the guys on my team take on this challenge.

Lunch and Learns

Lunch is often seen as a bit of wasted time during the day, why not take that time and learn something! I’ve scheduled a lunch and learn with my team once a week every friday. To start we are reading the foundations of programming pdf book (which is fantastic btw). Were covering a chapter a week, and we review and discuss the chapter for about 30 mins. The discussions that come up are surprising, interesting and challenging.

Code Reviews

Code reviews are an integral part of maintaining high quality work, but at the same time they are a great opportunity to teach. Having developer who’s in the process of learning new concepts act as the reviewer during a code review is a golden opportunity to go over the architecture and design decisions you made while developing the feature in question, it gives the reviewer not only the opportunity to look at the code, but to understand the thought process behind it.

Pair Programming

One of the simplest ways to teach another developer a new concept is to have them sit with you in a pair programming session. Start coding as you normally would, but pass the keyboard off after a bit and start talking your partner through the rest of the steps, help them write some unit tests, etc. It’s an excellent way to quickly introduce new stuff.

These are just a few options for learning that I think work well, and have worked well for me in the past.  I would love to hear how other people are tackling this problem, comments and emails!

Posted in agile-series, work | Leave a comment

Infecting a team with Agile: Part 1 – Preparation

By jonezy | Published: November 6, 2009

One of the core tenants of agile is:

“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!

Posted in agile, agile-series, richmondday, work | 3 Comments

Infecting a team with agile

By jonezy | Published: November 4, 2009

Part of what I’m doing at my job is getting the development practices we use internally up to date.  Previous to my current job i worked at a company that went through adopting agile as it’s primary development practice.  The result was a fantastic working environment and that is my goal here, to create a place that will not only produce amazing work, but will attract the best talent available.

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!

Posted in agile, agile-series, richmondday, work | Leave a comment

Connecting to different database on the fly using Subsonic 2.x

By jonezy | Published: November 3, 2009

Recently I started working on a project at work that requires me to connect to more then a single database at a time (different parts of the app connecting to different databases at the same time). I figured this should be pretty straight forward, Subsonic is relatively mature and should probably support this out of the box.

It doesn’t.

After figuring out that there was no simple easy solution for this, the next logical step was to start googling for answers right? Obviously. Off I went, finding little bits and pieces here and there, never the complete solution though, I thought I had a solution and my app worked for a couple of weeks until all of a sudden one day I could no longer connect to more than a single database! FML as they say!

I happened to stumble on this stackoverflow post that sort of addressed my issue, it gave some of the pieces of the solution, but I had to piece the rest of it together myself.  After finally fixing my problem I give to you, dear reader, my solution.

Note: this post assumes that you have used subsonic, are fairly well versed in using it and have had the exact same problem as me.

1. Generate you DAL as normal using whatever method you like (i write a batch file to generate mine)

2. Create a file called whatever and place it in your subsonic project with this code in it (links to snipt.org, i’m straight copying and pasting my file, so change your namespaces and all that business).

3. Create a base class that all of your data access classes will inherit from (I call my RepositoryBase.cs)

4. Have the repository classes accept a connection string as part of the constructor, and pass it on to the base class.

5. In the base class, call the static method in the file you created in step 2 like so:

SSPProvider.SetProvider(”ConnectionStringName”, “ConnectionString”);

6. All of your subsonic related code will now use whatever connection string you passed to the SetProvider method.

7. ???

8. Profit?

Not so sure about the profit thing, but the code to switch databases works like a charm.

If there is interest I can post a more complete example but this should get you going for now.

Posted in development, programming, work | Leave a comment

subsonic won’t update my bit field?

By jonezy | Published: October 28, 2009

I recently ran into a really strange problem while using SubSonic.  I had a bit column in my database that was set to not allow nulls and had a default value of false.  Pretty standard stuff in the world of database design I guess.

When it came time to start saving my entities to the database, everything was working ok, except…. except after I had created a record in the database I could never change the IsActive column, like wtf?  I could never toggle between true and false on an existing record, but an insert would save the record perfectly every time.

To make a long incredibly frustrating story short, it turns out that if you have a bit field, that is set to allow nulls and has a default value of false it will never update (this is only using SubSonic).

So to ensure your bit fields work correctly in SubSonic, make sure those bit columns allow null and don’t have any default values!

Posted in Code, SubSonic, programming, work | Leave a comment

xcopy won’t copy .css files

By jonezy | Published: October 20, 2009

I use xcopy as part of a build script to copy a bunch of files and directories from a subversion checkout directory to another directory so that I can zip them and upload them to a server.

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!

Posted in agile, programming, work | Leave a comment

If your gonna fuck up, do it early

By jonezy | Published: October 15, 2009

I’ve worked in the online industry for the last 12 years or so, one thing above all else I’ve learned in my time in this industry

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.

Posted in agile, development, programming, work | Leave a comment