I’ve found that Scrum, and Agile methods in general, are incredibly valuable in single-man “teams” if done properly.  In my experience though, there are some sticking points that need to be worked through with how you work with your clients and manage communications.  These will have a significant impact on your projects and how successful Scrum can be for you.

Before I get too far, let me give a quick overview of Scrum:

Scrum development is a business process that seeks to speed up development, decrease bugs, and increase the quality of products that are delivered.  It doesn’t have to be focused on software development, but that’s where it has the greatest pull right now, and the use that I am going to focus on.

Scrum, at least how we use it (mixed with Extreme Programming), uses several key components:

• Iterative and Incremental Development – A product is released after each “Sprint” (typically 1-4 weeks).
• Test Driven Development – Automated unit tests are created to test the code, databases, and user interface.  For PHP, we use PHPUnit and some in-house database testing tools.  For Java and integration endpoint API tests (regardless of language), we use JUnit.
• One-Touch Build, Document & Deploy – Automated build and deployment sequences are developed to reduce variables, problems and time.  Ant is a great tool for this.
• Continual Integration – The software is compiled and thoroughly tested nightly (and as needed) throughout the sprint.  CruiseControl is useful for this, although you can also do something as easy as schedule a nightly cron job to execute an ant build file.
• Source Version Control – We use a central version control system (Subversion), to manage our code.  This allows me to work from multiple computers on the same code (such as when I’m traveling), and it also allows me to work with other developers when I’m partnering or outsourcing work.
• Product Backlog – Stories and feature sets that our customers want in the software that haven’t been completed yet.  Prioritized by business necessity.  I’ve heard good things about XPlanner and Pivotal Tracker, but we’re using simple index cards.
• Sprint Backlog – Stories & feature sets that we will complete during a sprint.  Negotiated between us and our client.  Here, we feed the index card stories plus any information from our client into (dotProject).  It’s not fancy, but it’s working for us today.
• Sprint Review – Lessons learned, what went well, and what didn’t go well.  Also, client’s likes/dislikes of the last product release are included.  We use a wiki for this, such as MediaWiki or dokuWiki.

A typical Scrum team consists of:

• Product owner – Your point-of-contact, who is responsible for the project.  Usually a Business Analyst or Project Manager.
• Users - The end-users, commonly the client’s staff.
• Stakeholders - Typically, these people are the client-side Project Managers and are the ones that are paying for the product.
• Scrum Master – The member of the consulting or development team that is responsible for delivery of the product.
• Team members – The actual development team

Things get really interesting when you start looking at roles for Micro-Scrums.  When you are running a Micro-Scrum (such as if you are a lone consultant), the scrum master, team members and product owner are consolidated to a single person (you).  And when your client is a small business, your contact ends up filling multiple roles, so your actual Scrum roles look more like this:

• Scrum Master/Team/Product Owner (Consultant)
• Stakeholder/User (President, CEO, or General Manager, etc.)
• User (Client’s Staff)

Consolidating those roles makes things both easier and harder at the same time.  It’s a bit easier because there are fewer people that you need to communicate with.  It also makes things more difficult because I, as the Product Owner, now don’t just need to make sure that the product is developed and delivered.  I also need to fill the roll of a Business Analyst, so I need to understand the business case, consolidate all the user’s needs and prioritize their importance.

I also have to avoid focusing on my own “pet features”, which developers can sometimes do, and instead have to focus on what will bring my client the greatest value in the shortest amount of time.

Now that I’ve mapped out the landscape and I’ve distilled all those roles down to 2-3 people, let’s get into some details…

Starting a small-business development project as a Micro-Scrum involves a lot of communication.  In my experience, clear communication will make the greatest impact on the success or failure of a project.  There needs to be a very clear understanding from both the client and the consultant on what is going to happen and how the product is going to be developed and delivered.  If you are on the same page and can negotiate the priorities, things work well.  When your client can’t understand the iterative mindset and he wants it all done right now without prioritizing, it’s a lot more difficult.

Here are some lessons that I’ve learned the hard way:

Lessons Learned

In Micro-Scrum, the focus needs to be on quality, NOT on cost.

All too often, small Agile studios like mine are compared to freelancers or overseas developers on sites like Elance and Guru.  The bottom line is that we cannot complete with their hourly cost, so we don’t even try.  What we focus on is Quality, above all else.  Unit-tested code, usability & acceptance tests, code reviews, security audits, and active communication with our clients throughout the entire process.

It has worked well for us, and we’ve kept our current clients for nearly 2 years at full workload.  The past year has been our best year ever, despite the recession.

Micro-Scrum development usually costs more, initially, than methodology-less development (aka cowboy coding).

This goes along with the previous lesson.  The up-front costs are usually higher, however the bug rate is much lower and the documentation is better.  Also, the risk and time involved when refactoring and modifying the code is MUCH lower.  Software changes are anticipated, so we develop with that in mind.

When working with a new client, deliver early and often.

When working with non-tech-savy businesses, keep the sprints short.  We like to do 2-3 day sprints at the beginning to get them accustomed to the process.  Even if that means just delivering them a framework, some raw code, a library or sketches, it pays off dividends over the course of the project.  It opens up communication and makes sure that our direction matches their vision.

In addition, you get to run through a deployment dry run each time.  If you notice problems in the process, you can fix them early on rather than waiting until the end and being surprised that their server doesn’t support a dependency that you built into your software.  (It may sound silly, but it happens.)

The risk with this rapid iteration is that if you don’t explain why you’re doing this, your client may feel like you just don’t understand what they want.  And they’d be right.  The entire purpose of these short sprints at the beginning is to learn what your client wants by giving them something tangible that they can critique and use as a reference.  That tangible prototype can help you understand what they really want.

Keep the up-front requirements gathering as short as possible.

Feel free to post flame-comments below. 

What I’ve run into many times is that clients don’t always know how to explain their vision and be clear with what they want.  For about 1 full month back in 2008, I beat my head against a wall because one of my clients seemed to contradict their needs on a weekly basis with an accounting system I was developing for them.

I decided, out of desperation, to cut the requirements gathering short and push forward with what I had at that point.  Amazingly, I was pretty much right.  After Sprint 1, there were some modifications and changes, of course, but I was able to hit the target with only about 30% of the requirements being known up-front.  In addition, it forced us to build a very flexible architecture so that we could easily adapt to the unknowns and changes when we hit them.

What we do now is start with a very quick Sprint 0, maybe a week at most, and build the user stories, initial specifications and product backlog.  There will be lots of unknowns and changes later on.  Managing and working around those is just part of software development, especially when you’re working with companies that don’t understand software development.

Failure is GOOD!

This may seem counter-intuitive, but failure is a good thing.  It opens the lines of communication for constructive feedback.

Our goals with all our projects is to “fail fast.”  What that means is that we deliver a product in an early iteration (ideally Sprint 1) that our client will see lots of problems with.  Maybe the interface doesn’t meet their needs, or the work flow isn’t intuitive.  Whatever it is, I actually want my client to come back to me and say “I don’t like this.”  I then ask them “What specifically don’t you like?”  Or my favorite: “Let’s do a screencast and you can show me what’s happening.”

Take each failure as an opportunity to open the lines of communication even further.  Learn exactly what your client wants by watching him or her use your application.  Developing a Micro-Scrum team takes time, and building the relationship and trust through open communication is essential.

I’m sure you’ve noticed that communication is a common theme in Micro-Scrum.  Actually, it’s really the primary driver behind Scrum and any other Project Management methodology.  In order to deliver what a client wants, you need to have clear communication to truly understand their needs.  In my eyes, there is no other way to deliver a successful product.

Scrum formalizes the communications and works to get everyone, from the users and stakeholders to the developers, engaged in the success of the product.  When you are Micro-Scrumming, this communication becomes even more vital since there are fewer people involved and more responsibility on each person.  Harnessed wisely, it can lead to very successful projects that have good short-term value and outstanding long-term value.

If you’re in the Columbus, OH area and want to learn more about Agile Software Development, I highly suggest going to the Columbus Ohio Agile Alliance (COHAA) meetings and getting involved in TechLife Columbus meetup group.

Technorati Tags: agile, junit, microscrum, phpunit, scrum, submerged solutions