By Bryan Phillips on Apr 18, 2015 10:45 PM

Agile methodology is a team development style that offers quick turnaround and committed goals.  Many teams use different variations of Agile that work for them.  This isn't a silver bullet to getting your projects done quicker, but it's a step in the right direction.  The thing that large companies don't really understand is what they "need".  Over the years, I've heard management slam the gavel saying that they NEED a research document.  And that they NEED the release notes printed.  As a developer, I fail to understand why all this is more important that you NEEDing to get the project done.  Agile is a way to "cut the fat" from the old mindset.  It's a blueprint to take developers and letting them be productive.  In Agile there isn't a manager, there is a "Scrum Master".  While it's a funny term, that role is the most important job.  It basically shields the developers from the "riff-raff".  The "Scrum Master" every day meets with the team and asks what their impediments are.  His job is to keep the developers coding and removing road-blocks.   

I've worked in both environments, a startup and a company.  I did the startup on nights and weekends, while trying to balance family and my full-time job.  The company I work for (for 13 years) is faster than most, but it's still large and slow to get things accomplished.  We are separated into about 6 teams with anywhere from 2-10 people on a team.  Over the last 5 years we've moved into an Agile development methodology.   Some teams have rebelled and still do "waterfall".  Between the 2 methodologies, it's easy to see the vast difference in productivity.  "Waterfall" is a development methodology where you have a developer estimate the size of a change.  Then they do a research document to write up what changes they would have made.  Whenever that gets approved, a developer is assigned to it, and can start working.  But wait!  The developer that researched it might not be the one who is doing the development (or the research was done months ago and you forgot what to do) so the developer needs to read the research document and program it.  If your company does this still internally, then your leadership is from the 1990's, and they shouldn't be driving technology.  If you're a manager reading this, and require your developers do this, then please do us all a favor and go put in your 2 weeks..  In my opinion, research documents should only be written when doing work across companies.    

 

Agile is the most effective development methodology I've used to date.  Although we don't use it exactly how "they say to", we've customized it to fit our teams mindset and be even quicker.  For example, we don't do the retro.  We sit in a open room and are very vocal about how the sprint is going day-to-day.  So sitting down at the end of the sprint and hashing it out again would be pointless for us.  We also don't estimate in "story points".  We use hours for all our sprints, tasks and velocity.  It's just easier for us, because we found ourselves always doing a calculation back to hours anyway.

 

If you haven't tried Agile yet, I highly recommend you do!  Here are some great resources to help you get started.

http://agilemethodology.org/ 

www.google.com  :)

 
By Bryan Phillips on Apr 18, 2015 09:48 PM

We've all heard of startups that accomplish these huge goals and in most cases did what large companies have tried and failed.  Why is this?  Most startups don't have any money or resources.  They're just running with a dream.  So how effective can a dream be?  How come the larger companies cannot accomplish these goals when they have all the resources?  

 

Not all startups are wildly successful.  We only hear about the ones that are.  But startups are more productive, for various reasons.  The biggest key to a successful startup and any company is the people and freedom to be efficient.   Startups typically have very small management structures.  The communication process is streamlined.  Any development team with vast knowledge and determination can do amazing things.  You just need to give them direction and turn them loose.  Startups kind of create this "perfect storm" where you have 5 super determined geeks who want to get something done quickly.  They don't need to do the mundane tasks of recording their time, writing developer documents, discussing change processes, etc.  The reason is because none of that is in their goal.  Their goal is to finish the project quickly.  

 

Startups and companies are not apples to apples

Startups have the luxury of not having people who've been there for years.  That save time, because now the process is being designed as you go.  Nothings more frustrating than learning a process that offers no value but is "they way we've always done it".

 

Startups have people who WANT to be there.  They just want to code like a mad man and hopefully get paid at the end.  The startup is a stepping stone, not a destination.  Because if the startup is successful, then it slows down and turns into a company.

 

No legacy problems.  Everything is entirely new, so the only problems you have are the ones you create.

 

Startups are entirely evolved around quick turnaround.  You need to get your project done to get paid.  And you need to get it to market faster than the other guy.  

 

My advice for companies

Mix and match.  Find what works for you.  Don't make your developers write docs, it's unproductive and the business requirements should do that anyway!  Don't be afraid to try something different.  It could make your life easier and more productive.  Remember, every process has room for improvement.  And please, PROTOTYPE, PROTOTYPE, PROTOTYPE!  This concept works and is quick to market.  Over the 13 years at my company, I've done around 30 prototypes, and we're using them all in production today.