Git In Continuous Deployment

I put together a slide deck for a presentation I gave to a client on a possible model for continuous deployment and how git fits into that.  It's purpose was to get people thinking about what kind of process they want to develop and deploy software and the tools that are available to get there.

Lessons Learned: How to Launch Better Software Faster

Shipping Greatness by Chris Vander Meyhttp://www.shippinggreatness.com/
Twitter: @shippingchris

Notes taken from How to Launch Better Software Faster, an O'reilly webcast on Nov. 13, 2012

http://event.on24.com/r.htm?e=511276&s=1&k=77D7C33E4A6B9F49DCC3353C1B05C109

• Get right components into place before writing software.
  • Mission Statement; short and sweet
    • example: "Enhance customer delight"
    • Aligns your team to drive forward
• Team
  • Hiring; only hire the very best people you can
    • trustworthy and independent
    • Managers need to dedicate a large amount of time to talent acquisition
    • error on side of not making a hiring mistake
  • Job Selection
    • Find a team that you love to work with
    • Smaller teams may yield greater results
    • Good balanced teams: senior for each junior
• Right Process
  • Too much process: example may be daily stand up meetings for 45 minutes
    • hard to move forward if tied up in process
  • Too little process: example may be no status updates
    • teams are going in different directions
  • Need to find a balance for your team
  • Error on side of too little process
    • move quickly
    • empowers team members
• Faster
  • Faster release increase cash flow
  • Get users feedback faster
  • Employees/team members see progress; motivation increases
• Crisp Communication
  • Sharing ideas clearly and quickly
    • example may be a 1 page document to share an idea or problem
  • Generates less confusion
  • Less time taken to document
  • Be clear and specific, actual numbers and figures.  
  • Start with most important thing
  • Don't hide your data
• Fight The Right Battles
  • Understand the true cost of a battle
    • If you can afford to lose, lose quickly
  • Focus on goals
    • Don't make the argument about 'you' or 'I' 
• Spend Wisely
  • Time is very precious...use it wisely
  • 'Do we have to have a meeting for this?'
  • FAQ Documents may help save time 
  • Meetings need an agenda...if there is no agenda, ask for one
    • Be as efficient as possible

The Tragedy of Agile

I've recently become aware of some recent complaints about the agile methodology and as I've thought about these complaints it seems to me that the reason for these complaints is because people are too locked into doing what someone has ordered them to do to. What I mean by that is too often we're not able to ask why we're doing something other than the boss (or someone else like an expensive consultant) said so.

All too often agile, or any process decision, is directed from the top-down.  An executive/manager/lead gets wind of a way to make all their buggy, late, and expensive software problems go away.  All you have to do is follow a few simple rules.  Now the tragedy is the people who have to carry out these rules are never asked how they feel about these rules before they're told to do them.  What we're seeing is a bureaucratic, closed, and stale culture trying to implement a set of rules that are based on an open, transparent, and continuously improving culture.  The rules for the software development process just don't seem to fit, but luckily nothing is set in stone.

This is your process...not Scrum's

During my grad studies I took a class about lean manufacturing which is the basis for the Toyota Production System (TPS).  Basically, TPS is a culture, set of rules, guidelines, and processes that enable Toyota to eliminate waste in their business.   Eventually Toyota realized that it needed to help their suppliers eliminate waste so that they could work together better.  Our class took a tour of one of these suppliers called Autoliv.  Autoliv builds parts for Toyota's airbags and with Toyota's help they've been able to create a more efficient production system.  Now, do they call it the Toyota Production System?  No way.  Why?  Because they're not Toyota, they're Autoliv.  It's the Autoliv Production System.  It was modeled after TPS but modified for their specific needs.

Don't say we use the Scrum or OpenAgile or Waterfall or whatever methodology you're basing your process off, because the truth of the matter is you aren't.  You're taking whatever you understand these methodologies to be and you're applying it to your circumstances.  When you say you're using Scrum it's too easy to blame your problems on Scrum.  Take ownership of your development process because if there is a problem, you'll need to fix it.  And by you I mean everyone on your team.  

Empower the team.  They will come.

I've come to discover that self-organizing teams are incredibly productive and for the most part a lot happier than your traditional team (I wish I had empirical proof, but I don't).  Part of the self-organizing team is shared responsibility.  You fail together and you succeed together.  Most people I've come across(sure there's a few dicks out there) are going to want the team to succeed and will share ideas on how to improve. Whether code or development process, the team needs to be able to adjust to better increase their chances of success.  In order to do that they need to be able to experiment with their ideas without going through miles of red tape.  Does experimentation lead to some failures?  Absolutely, but it is the only way to improve.  

Another important aspect of the team is having clear roles.  Generally, you'll have your product owner and your customers and your project manager (some people might call this scrum master for some weird reason), and your developers.  Your process might have more and maybe less (do you see a problem with having less?), but the fact of the matter is if you know who has what role, and what specific duties are included in that role, there won't be as many conflicts of people trying to do the same thing.  For example, if you have a clear product owner who is driving the direction of the project you won't be receiving conflicting feature requests.  Again, it's important to understand why you have each role on the team.  If you don't know why, you probably don't need it and you can move that person to QA since they're probably overloaded anyways.

Tool not rules

As I've come to better understand agile, lean, theory of constraints, and other ideas of improving processes the better I've come to understand that all the ideas and strategies are simply tools.  Tools that I can choose to use in a certain situation where necessary or, if it wouldn't be effective, to leave in the toolbox.  You wouldn't use a sledge hammer to hang a picture would you?

In carpentry it's generally pretty easy to decide on which tool for a job, but it may not be so easy for software development.  For this reason it's important that you're measuring the right things to see if a tool really is beneficial.  I agree that this is way easier said than done, but at the very least you should know how long, on average, a feature takes to go from inception to release.  That way you can monitor any changes that come about from your experimentation(remember the scientific method?).

Some other useful metrics might be ROI, velocity and there are a slew of others.  And once again, understand why you're measuring something, because truth be told, measuring can be a pain.

So...

If I were to have you remember anything from this article, understand why you're doing what you're doing. I sincerely hope that you're in an organization where that's okay.  If not you might have a hard time trying to convince people to change, but I've found that most people are willing to change If they understand why it would be better.

And if you were to remember some other things it would be good to also remember that it's YOUR software development process, for better or for worse.  The sooner you realize that the better for you and your team. And lastly, use tools that are good for the job.  

So, by following these few simple rules (maybe I'll name it the Be Awesome To Each Other Methodology), you too can enjoy your job in software development.  

Seriously though,  I am interested in your stories, ideas, anecdotes, etc.