Let’s start out with the agile manifesto.  It’s been 15 years since this was written, and agile is all over the place in different organizations.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan


If you’ve worked with me in the recent past, you’ll read a few of my frequently vented statements from the office.  The word vented is quite important, it’s usually as a result of being unable to change a process or observing a ritual that’s ridiculous.   BUT! This is all caveated with the following statement:

“Companies need to get things done.  They need to understand how their development organizations are organized and working.  They need to be able to plan and forecast expenses and timelines.  I understand their need for process, even if they call it agile.” – Chris F.  (yeah, that’s me)

Individuals and interactions over processes and tools

Data is king.  As a data and process guy, I understand the value in knowing how well a team performs, especially over time.  Let’s compare this to a retail business.   If you don’t have historical data on sales, you can’t reliably plan your upcoming budgets.  Look at seasonal retail, you need to know when you’re in a high income month to hold back some income for the upcoming low seasons.  It’s cash flow planning 101.   The same goes for enterprises managing their development resources.  How many projects can we realistically plan and promise in the next 6 months? There’s no way to do that without knowing the output trends of your teams.

Where groups get in trouble is sacrificing development time and resources to make sure these metrics are buttoned down.  I’m a big fan of planning poker (or whatever the kids are calling it these days).  Using a fibonacci scale (1,2,3,5,8,13) you let your team tell you the complexity of the task they’re working on.   This isn’t a number of hours, it isn’t the number of days a task will take to complete.  It’s a little more granular than a t-shirt size estimate (S, M, L, XL), but not much.  The valuable outcome tells you approximate velocity.  It’s not a set in stone metric, it’s an approximation.  Don’t make it anything more than that.

There are plenty of tools out there to help track stories, points, sprints (oh my!).  Pick a light weight one that matches your natural processes.  Pivotal Tracker works well, Jira works well too.   Don’t over play the tool though. Just get work done!

Working software over comprehensive documentation

Documentation has been the bane of my existence as a software engineer for my entire career.  One of my first jobs was on a CMMI certified project.  Talk about documentation for documentations sake.  Documents that never get read are seriously stupid.  Talk about a waste of time!

No documentation is even stupider, in my opinion.  Remember that proverbial bus?  When your strongest developer gets a much higher paying job, (or gets hit by the proverbial bus), and doesn’t come to work, how do you know what the heck he was working on?   Sure, there are team members, but in my experience, you typically build a lot of domain knowledge in one (maybe two) developers.

Here’s my advice:  Document the process and the components.  How does code get from the source code repository to a production environment.  What steps are automated, what steps are manual.  How does data flow from start to finish? What components pick up data when it comes from a source system?  If you want to document interfaces, that’s a great next step.   Document your APIs, including inputs/outputs, required fields etc.  Define what it takes to integrate with other pieces of tech.

Find the balance between useful and wasteful.   It’s not always a clear answer, but lean to the side of less.

Customer collaboration over contract negotiation

Flashing back to the days of Waterfall.  These days are not totally gone, unfortunately.  Much like the previous point about over documenting, this tenet is similar.  Think about selling a house.   You’re the seller and I’m the buyer.    You write an offer.  I read it and send a counter offer.  You sign it and we’re done!   We never had to meet.  We didn’t talk, and heck, we were separated by another layer: the real estate agent.  This is the extreme of waterfall.  Your customer writes up this gigantic requirements document, ships it over the wall (via a people person, darn it) and the development staff has at it.  6-12+ months later, the developers show the product to the customer, and guess what!  BAM, it is NOT what they wanted.  Are you surprised?

Now imagine the customer and the engineering team working together in much faster cycles.  Instead of the customer seeing a quarterly release (or a final release, I shudder to think), imagine them seeing daily progress, heck, hourly progress.  Embed a customer representative with the developers.  Then the real time collaboration hits and boy is it magical.  “What do you think of this color”, or, “Here’s how the data is flowing, how does this look for a user interaction”.   Real time (or close to it) feedback is the best way to make sure the final result is really what the customer wants.

Responding to change over following a plan

Ever met someone who hates change?  We all get in our groove and really don’t like when others rock the boat, but, there are folks who truly can not deal with change. It gives them anxiety and it’s a weird thing to observe.  One of my natural trait’s is that I’m a rule follower***.  I understand the value and comfort a plan provides.   I’m also a realist and understand that the best laid plans (of mice and men) NEVER stick.  Timelines change, people get sick and most importantly, requirements change!  (I’m sensing a reason these points are laid out the way they are in the manifesto)  Go with the flow!  If you’re 20% through a project, and BAM, you get the best idea ever, then go ahead with your customer and figure out (or if) to change the project, timelines etc.   Your customer might change what they want from you.  If you lose a few weeks/months of time because of it, it’s up to them.  Don’t stress it (but keep notes that it’s the customer that changed plans mid project, don’t get dinged in your performance appraisal!).

There’s another side to this though too.  I’ve worked in two startups in which we’re building a product that has to be sold in the market.  Every week, our sales guys would come in and say “Customer XYZ needs feature ABC in order to close this 300 million dollar deal!!”.   It’s really easy to let the tail (sales) wag the dog (product and overall roadmap).  Don’t chase every sale by losing sight of your product roadmap.  Having a strategy is key.   Product management needs to be really clear and intentional if they change product delivery timelines or priorities of features when sales comes calling.  Good product management and executive leadership will never let a sale change the vision or strategy, but they may allow a slight deviation from the original plan in order to reprioritize!  (Although if it really were a 300 million dollar sale , that may be big enough to derail a lot!)


The tenet’s laid out in the Agile Manifesto were put together by some really , really smart people.  Don’t let the ceremonies and the calendar be the only thing that ‘makes you agile’.  For me, “Individuals and Interactions Over Processes and Tools” are the foundation for the rest of the bullets.  Write good software, and don’t focus on tools that don’t help write good software.

(Simpson car from http://simpsons.wikia.com/wiki/The_Homer )

*** (more to come on what that means, but,  it shows mainly in respecting org charts, staying in roles and responsibilities given, etc..   I do well in chaos, flexible environments, and love when my rule is “no rules!”)

Cross Posted @ LinkedIn