Mike Benner

One of the concepts in Agile Development is use automation tools.  These tools can run through a wide range of options, but typically you would have automated server builds, testing suites, deployment tools, etc.  These tools should be stable and reliable.  In the Rails world things change quickly and updates are pushed out a much faster intervals than other non open source environments.  This can cause your tools to become out of date and less than reliable rather quickly.

When this happens, you may find yourself, hacking together work arounds or just plain doing it manually because of your work load.  While this may seem like a good idea in the short term, the long term affects can become paralyzing and complete efficiency killers.  When you find this happening to you and your team, stop sawing.  Sawing with a dull blade will get you nowhere.  Not only that, but it can lead to bad habits.

Team members can become apathetic about the problems, can start to lose pride in their work and environment or worst yet, stop doing that extra step that makes them better because it "isn't worth the effort/time".  Visibility drops and the Agile process can start to break down.  If you find this happening, take the time to fix the problems.  Too busy sawing?  Work a second shift, come in on a Saturday, rally the team to do nothing but sharpen the tools.  A good team can get the process back on track rather quickly and the overall results will be seen almost immediately.

Estimating has always been a hot bed of contention everywhere I have worked, including my own business.  This has been a hot issue around the office over the last few weeks.  There has been talk of over estimating (aka padding), under estimating and incorrect baselines to name a few of the problems thrown around.  But more important than those "problems",  what is starting the dialogue?

To begin with developers get caught up with the "I burned through more points than you did" mentality.  Depending on how you do your baselines, you can't be competitive with someone on another project.  The least complex story (1 point) and the most complex story (13 points) can be drastically different between a simple online store and a full blown CMS.  So we need to set that competition aside and not worry that I was only able to keep a velocity of 18 points while my team member burned 38 points.

Another reason these discussions begin is caused by acceptance criteria.  The product owner starts adding criteria that makes that 3 point story seem like an 8 point story.  This is where dialogue between you and the Product Owner comes into play.  Remembering that an estimate is just an estimate and is based on the simplest possible solution, what can happen here is scope creep.  Product Owners will sometimes build other stories into their criteria and other times simplest possible is not what they want.  This is not the fault of the estimation, as a matter of fact, it isn't a fault of anything, it is why we adopt an Agile methodology.  The criteria, if large enough and justifiably, can be broken into multiple stories, then do that.  Have estimations done on the new stories and keep that dialogue going with the product owner.

Also, there is the problem of experience and knowledge level.  What may seem complex to you, may be simple for another team member.  But, if you are properly running as a team, that should also make it simple for you when you bring it up at your morning stand up session.  Set some time aside and time box a quick session with a team member to pair with and get that complexity down for you.  Learn how to use that plugin you have never heard of, learn a pattern you have never used or even try that obscure method that is buried in the framework.

Ultimately, remember an estimation is just an estimation and the reason for Agile is to adapt and iterate in quick sprints that will allow for changes, that yes, will sometimes make the original estimate seem off, but what matters is your daily dialogue with the product owner and holding to a true maintainable velocity, even if it is only 9 points a sprint.

Apple did it with the iPod and now it appears Amazon is doing it with the Kindle.  Much like MP3 players, Amazon is taking a technology that has been around for awhile and bringing it to the masses.  As, an owner of the Sony Reader, I am happy to see this happening.  While not in the format of my choice, and likely to cause another format war, this is a good thing.  Most magazines are trying their hand at digital distribution, as are many book publishers.  Some have gotten it right, many are getting it wrong.

Take, for example, Servo, Nuts N Volts and Make magazines.  All offer digital subscriptions and all suffer from forcing you into their reader.  This is a shame as the eReaders cannot load these and enable you to take them on the road.  Then you have Fusion Authority, Flex Authority and GroovyMag.  These publishers went with PDF format and while that is better it is not perfect.  I have to commend GroovyMag for working towards the solution.  They are currently working on Kindle and Sony Reader formats which is awesome news.  This is what everyone should be doing.

Read more...

There has been a lot of talk lately about the economy, the government\'s bailout plan, the effect of taxes on the entrepreneur and it has been mostly doom and gloom.  Heck, just today the stock market hit 7200.  While all of these things can be worrisome and cause for concern, let us not make this a self-fulling prophecy and lose sight of what makes us entrepreneurs in the first place.  Innovation and the willingness to take the risk and bet on the come.

Most companies (including your competitors) are busy "Right Sizing" and protecting their existing capital and not planning for recovery, future growth and R&D on their products.  I say seize this moment.  Do what we do best, take a chance.  Most of us are "small" and with that comes great agility

Read more...