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.

Reflections of CodeRetreat 14.05

This weekend, I attended CodeRetreat 14.05.  This is the 4th code retreat that I have attended.  The pattern continued that despite attending these events multiple times, I have still walked away with some valuable lessons learned.  

Here's a few of my key take-aways from this code retreat:

Rust - the language

I had the opportunity to hack around in the rust programming language.  Despite not making tons of progress with the game of life kata during this session, I was still able to experience hacking around with another fun languages.  I enjoyed seeing Rust’s approach to mutability. In Rust, every field is non-mutable unless you expressly make it such.  That seems like a good practice, because it forces you to think about which data you are okay with being mutated.  No surprises with your data changing from underneath you, and that’s a feels like a good thing.

Rust - my skills

I’ve been programming almost exclusively in Go for the past few months.  In one pairing session we began to write some unit tests in Ruby and I mixed up the syntax for GinkGo and RSpec.. a lot!  This was a friendly reminder that it’s important to practice and stay fresh in all of the languages you care about.  Many times when I am writing ruby specs I have plenty of examples laying around in the code base. When it’s a blank slate there is nothing created yet. You are left with only your your memory and the internet for googling examples. Once I got a few rspec tests written it was clear sailing, but there was a humbling moment or two getting the first test wired up.

I also had the opportunity to do this kata in C# with NUnit.  This technology set used to be my wheelhouse, and I was pleased to see that it didn’t take me much time to get back into the saddle.  My fingers even remembered most of the ReSharper shortcuts I know and love. Another neat thing is that I got to try out VIM-VS. I could leverage all of the shortcuts and keyboard navigation goodness that I have learned in VIM, while doing it inside of VisualStudio. This was a new and fun way to experience writing C# code again, but with some added editing niceties I've been practicing. This setup wasn't flawless, and I think this setup would take some tweaking in order for it to be really effective.

Golang

Last time I attended this event, I felt like my skills on Go were not strong enough that I could effectively lead a pairing session with someone who has never programmed in go, so I didn't even push the issue. I spent most of the day in Ruby that day. This time, I was determined to solve the kata in golang this session, even if I was the only Gopher there. Luckily, I wasn't. I had the pleasure of pairing with another Gopher at this code retreat and was lucky enough to be able to introduce them into using GinkGo. I'm glad to see a few others in this area using Golang.

Primitive Obsession

Like many people in this industry, there has been more than once in my career where I have over engineered a problem.  By practicing TDD so much over the past few years, I think that forcing myself to write tests first has eliminated many of the pitfalls of doing a bunch of design work first.  The problem with doing this is I think I stepped out of the “over engineering” category and into the “primitive obsession” category.  Having the challenge of doing Conways Game of Life without the use of any native datatypes exposed was a good way for me to let design for your objects to occur naturally.  I found it also drastically increased the readability of my code.  I plan on keeping a more watchful eye when using primitives to represent anything in the domain.

Remote pair programming

Where I work, we do a decent bit of pair programming.  We also gear ourselves up the right tools to do this job effectively.  We use tmux, google hangouts, and vim daily even when we're not pairing. It’s pretty typically that when pairing remotely that both developers will SSH into one of the pairing sessions.  I learned about a tools call wemux.  This seems to take some of the initial setup work out of the equation and make it easier for attaching to eachother’s tmux session without having to SSH into a shared computer.  

Learning and Teaching

Events like these are always a good experience for me.  Even when I feel like I'm ahead of the curve on some of the exercises like red/green/refactor, frequent check ins, and ping pong pairing, Jim Hurne is still an excellent facilitator and mixes up the exercises enough that can stretch my skills.   When I was in college I got a job as as tutor.  I was recently reminded how much fun it can be to teach.  I was also reminded how much you can learn by teaching.  Being able to justify what you are doing and and why you are doing it keeps your mind right.  I've been impressed how many college students and hobby programmers have been attending the code retreats recently.  It's good to see such a wiliness to learn and grow from an early age in your software development career.  It's fun and exciting to showing a disbeliever how to really write the tests first, or seeing someones mind blown when you show them a new trick, shortcut, or tool.  

Ruby Newbie Guide to Getting Started with Ubuntu for Software Development

This is a reference guide for how to get started using Ubuntu as a development environment.  I use OS X at work and I use Windows 8.1 at home on my beefy gaming desktop.  I wanted to find an ideal development environment at home to make developing a smooth experience.  The languages I currently use most are Ruby and Golang.  This makes using Windows less than ideal for development.  I know there are some tools and support for getting this done, but without getting into a holy war, I humbly choose Ubuntu instead.  To make good use of my gaming PC hardware, I decided to dual boot it and share a set of instructions and tips that helped me along the way on this journey.

Ubuntu Setup

Download the Ubuntu 14.04 image and burn it to a DVD or some other bootable media.

Prepare the drive

Since I was starting with a Windows 8 computer, I created a bootable Partition Magic disc and partitioned the hard drive in half.  I then formatted the new half of the drive.

Install Ubuntu!

Reboot and use the bootable Ubuntu disc your made earlier and install to the freshly formatted partition.   When installing Ubuntu I chose to use the EXT4 file system.

Get your dev environment setup

You can run this script as sudo to install some of the basics like git, curl and vim.  

Code & Text Editor

VIM is my linux/osx editor of choice.  But if you haven't learned VIM yet, consider using an editor that has a lower learning curve like Sublime Text for now.  We'll revisit the topic of using vim in a later blog post.

Setup ssh keys

Hopefully you have a backup of your private .ssh key.  You’ll want to copy that file to either ~/.ssh/keys or a subfolder inside of that directory.  When they are in the base folder every key gets added by default by some kind of ssh keyring manager.  I’m a bit more interested in choosing which keys I’d like to add and when.  So I keep mine in ~/.ssh/keys/users

Bash profile

Setup your bash profile however you like it best. I have a list of aliases I like to have available, and also making sure that VI mode is on.

Virtualization

Many of the applications my team develops now use Vagrant because we want to develop in the same environment that we deploy and to eliminate questions about tool chains to get the application built.  Skip these steps if you don't plan on using Vagrant or Virtual Machines.

Download Virtualbox and install.  
Download Vagrant and install. Vagrant Up's getting started guides are very good if you haven’t used vagrant before.

Make running spinning up vagrant boxes with vagrant actually work.  
There is currently a bug provisioning custom vagrant boxes for the first time with the latest versions described in this guide.  This Ubuntu First VM dance link will fix you up.

If you need Cisco VPN

Run this huge Cisco VPN setup script.  This is a HUGE .sh file.  Looks like it contains enough binary in it to produce their client from scratch.  This should be posted somewhere public on the Cisco site.. but I sometimes have a hard time finding it.  Use the link above for one I know works.

Another option that many linux users may prefer is using OpenConnect with Gnome's network manager (via network-manager-openconnect-gnome).

If you need Oracle SQL Developer

Then first off… I’m sorry.  It’s a pain in the neck to get installed, but worth it.  At least it was when I did this with Linux Mint.  It looks easier to do on Ubuntu, you could try following this oracle noob guide.

Making Windows and Ubuntu play nicely together

Download Virtualbox for windows

Download an Ubuntu image to be used as a shared VM between OSes.  If you download this while on Windows..make sure to just run the .ova file.  You can’t mount or create the VM from within the VirtualBox manager.  The ova file is a package that has everything you need by just running it.  You do also need to download Oracle VM Extension Pack if you want USB 2.0 support.

Credentials for Ubuntu base virtual image -  ubuntu/reverse  You may consider changing these later.

Enable file sharing between the Windows 8.1 and Ubuntu so you can share your VMs and use them anywhere.

Closing Notes

Thanks to @jesse_szwedko for reviewing this article and providing some suggestions.