Scrum, kanban, agile or XP? Which is right for my team?

Design patterns in software development are often times used to quickly describe a set of design principles that when combined solve a certain type of programming problem can provide a solution to the problem in limited number of words.  Each design pattern has it’s strengths and weaknesses to solve certain types of problems. It takes practicing building applications and learning from your mistakes to help you recognize when to apply each pattern.  

 I feel like same analogy can be made for agile processes.  There are certain modes of development process can be applied to help collaborate in the ways that best suit them.  To make these decisions about which methodologies to choose consider these factors:

Get your Mind right

Before you get deep into choosing the processes, reviewing the principles of the agile manifesto helps get my mind pointed in the right direction to remind myself why the process around software development is important.  

Here’s a few of my favorite principles that helped guide and agile manifesto
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
“The best architectures, requirements, and designs emerge from self-organizing teams.”
"Continuous attention to technical excellence and good design enhances agility."

Reviewing the entire list is a good thing.  Finding the principles that your team values most will go a long way.  

Get familiar with agile processes & patterns

Extreme Programming
Scrum
Kanban
Continuous Delivery

In order to decide whether or not to apply design patterns to a certain problem, you must understand the problem you are attempting to solve, and understand the design pattern.  If the two are a good match, solving this problem will have a higher likelihood for success.  The same mentality can be applied to choosing agile processes and principles.  Groking the processes and patterns will arm you with the information needed to size up your process decisions.

Know thy self

When deciding which agile processes to apply, one must understand the problem they are attempting to solve.  Many people don’t have the luxury of knowing how their teammates prior to working with them.  Some people are resistant to change.  This resistance may be because what they are doing now is “working” and they want to focus on the actual coding aspects.  When I’m neck deep working on something I’m not thinking about the stuff AROUND software.  

Software is a team sport.  There are plenty of lone rangers and duct tape programmers out there. They don't’ dare talk about process and certainly would not not formalize the manner in which they operate.  I’m not even saying that’s a bad thing either!  This could be a good thing if they are indeed informally following the principles of the agile manifesto.   A well tuned mature team doesn't need to be bound with tons of process.  They inertly grok how to get software out the door.  

For example, here’s a snapshot of how my team at work mainly collaborates:

• Pair programming on demand, not required.
• Bouncer role - keeps the rest of the team focused.
• BDD almost all new code
• Stand ups
• Retros
• Kanban Board
• Another tracker - for larger epic level stories, also keeps kanban board concise.
• Continuous Delivery.  Automate and script as much as possible.  Release as often as possible.

So if I add up the components for how we work.. which model does that put us in?  We’re not exactly kanban, because kanban doesn’t say anything about a pair programming and many of the other ingredients.  In fact neither does SCRUM!  This model doesn't fit anywhere on any existing best practices.  This is any okay thing.

Get ready to learn and grow

“Planning is a process of choosing among those many options. If we do not choose to plan, then we choose to have others plan for us.”   If you choose nothing else, please plan to learn and grow.  Don’t change any of your processes, but do have a weekly or biweekly retro about how the team is working together.  Figure out what isn’t working.. and change one little thing at a time.  Massive process overhaul isn’t necessary if you can always slowly improve.  Fine tuning how you work is especially important for when you get into crunch time.  I’ve found that during crunch times, many want to revamp their processes to align with GTD.  If your process has already been finely tuned to optimize sustainable performance, making any transitions necessary to achieve higher performance is a matter of turning a couple knobs, not trying something completely new.

I really like this mantra:  

Sometimes you just need to start with one thing.

And I think that thing is culture.  Fostering an environment where it is okay to fail, learn and grow is one of the most commonly overlooked crucial components in software development.  The most important thing is that we are always taking a step in the right direction.  When it comes to software development, sometimes taking a big leap can be risky to the big project you are working on.  It’s important to minimize that risk as early as possible.  Focusing on continuous delivery is a model that can help risk more risk sooner. Getting your software in front of your customers ASAP will help you learn if you are marching in the right direction.

So which one?  Scrum, kanban, agile or XP?

I've heard the phrase that “scrum is like training wheels” for agile.  It provides a few of the necessarily components to solving the problem and sets you off in hopefully the right direction.  Once your team matures and groks scrum you can remove the training wheels and modify your processes for what works best for you. It’s important to find the right balance of process to getting things done. The key is growing a software development methodology with culture seeded deep into it’s roots.  This is how great teams and software are built.