nthread

To get started with the basics, agile in the context of development is a family of methodologies for managing software development projects with grey boundaries.  A lot of times, when people discuss agile development vs. other development methodologies, they talk about agile as though there is just one way to do it.  I think it’s because they don’t really understand the variables in a software project.

I think that the software development methodologies form a spectrum from the ones that require the most up front design to the least.  I see the most commonly used methodologies shaking out in this order (this isn’t meant to be all inclusive):

Waterfall -

• requirements, design, implement, test, release

Mini Waterfall

• requirements, design, implement, test, release, repeat

Scrum

• add known issues and wants to feature backlog, group features into sprint (2-4 weeks development), prototype as needed, development and test, repeat

Extreme & Microsoft Agile

• create user story, prototype as needed, break story into developer & designer tasks, implement and test task implementations, repeat

Cowboy Coding

• design interfaces and write code, show it to people
• I think the name makes is sound worse than it is.

Most of the time, people talk about whether to use agile methodologies or more traditional waterfall approaches.  I think this misses the more common scenario at startups, where they are often using cowboy coding to get things done.  The name doesn’t make it sound all that good, I think that “cowboy” sort of refers to the fact that developers are off writing code and no one knows what the hell they are doing.

Agile development strategies and waterfall are designed in a way to give metrics that can help non-team members have the warm and fuzzy feeling that they know how things are progessing, and are helpful to the team to some degree as well.  I’m not trying to weigh agile techniques against waterfall, as far as I’m concerned, that ship has sailed and agile is the only way to go.  I am trying to contrast the difference between formal approaches and informal approaches.  In cowboy coding, you don’t have metrics, only a system that is hopefully taking shape.  This is hard for non-team developers to project and resource against, and it’s hard for non-team people to work with.

Basically, I see cowboy coding as being the cult of the developer, and the more formal methods as being centered around project managers and other folks.

Think About The Great Startups

I don’t think that Page & Brin were having sprint meetings and working with product managers.  I don’t think that Fake and Butterfield from Flickr were sitting around having meetings all day long.  Zuckerberg understood the idea of Facebook when it was explained to him, took the idea for his own, and ran with it (so it is said).

All of these companies were probably doing their most important foundational work with cowboy coding and not that many people.  Later, they hired many more people and switched to formal development approaches to ensure that they could have developers working towards the ends sought out by the business development people, but at the start, I think they were all cowboy.

It’s just my alternate view on the whole agile vs. waterfall discussions that happen often.  What about agile vs. cowboy?  What about hiring good developers and just telling them to roll on the idea.  Okay, it’s hard to manage and won’t work on scale, but are you at scale yet?  At least think about it before you put in more process than makes sense.