ADS specializes in using Ruby on Rails to build advanced, scalable, database-backed web sites for organizations of all sizes. Find out more at our website.

I’m a member of the Scrum Development group on Yahoo!, and after lurking for more than a month, have joined the conversations going on there. A recent thread that I responded to was started by a gentleman in a semi-government organization dealing with some major issues while implementing Scrum. His manager is unsupportive, his team does not see him as a leader (he was previously a peer), and due to a lack of responsibility being put on the team the entire process has gone down the tubes. He’s been dealing with this for a more than a year and his frustration comes through in his writing.

This leads to the question: is Scrum for everyone?

When I spoke at RailsConf about Agile Development with Scrum one question I was asked was whether or not Scrum is a good fit for all teams. In short my answer is it could be, but you might run into challenges. Some of the biggies that stand out are:

• No top-down buy-in from management
• Project managers are unwilling or unable to use a new method
• Micro-management abounds and there is seemingly no way of changing that
• General ignorance of how Scrum works and its’ benefits

The last point is the easiest to deal with - education. The other three are tougher nuts to crack. With Scrum leadership is stressed over management. My advice: lead by example, start small, and prove its worth. Scrum isn’t an all-or-nothing proposition; the larger the organization the longer it may take. Stay positive and keep moving forward with it. The results will speak for themselves.

I was having lunch today with a new client that is interested in implementing scrum in their organization. They are a very large company where a single project can have five or more departments involved as stakeholders. They are not interested in turning on a switch and being 100% agile overnight. For a company such as this, they need to be more prudent in bringing scrum online. In addition, the move to scrum should be transparent to everyone outside of IT and software development. Thankfully the planets are in alignment for us and they have the perfect opportunity to use scrum: a project that needs to be completed, and a staff and higher-ups wanting to use scrum.

Often times we look at a project as an all or nothing proposition. We do this with many other things including improving development practices and business processes. Introducing scrum does not have to be done in one large, sweeping move. I recommend against doing that. It is those instances where scrum is introduced too quickly, on too large of a scale, or in areas where scrum is not useful, that cause projects to fail and everyone blames scrum. That is akin to blaming a framework for scalability issues where the framework isn’t to blame, but rather the implementation.

If you have a project or a small set of tasks where you can apply scrum use that as the test bed. You can even start using it without telling anyone. “Geez, how is Jim able to crank out so much stuff in such a short amount of time? I love seeing new stuff every couple of weeks.” Scrum. It’s great stuff; however, it is a paradigm shift for many. Don’t dive in too quickly lest you end up in shallow waters and bonk your head. Use it on a project, achieve a great success, and use that as proof that it can work. Then build on it.

If you were at my talk on Agile Development at RailsConf 2008 and want the slides then you are in luck! You can grab my slides along with those of other presenters on the RailsConf 2008 presentation files page. Enjoy!

Update: for some reason the slides aren’t appearing on the RailsConf site. So, click here to grab em.

Come learn about agile development with scrum at RailsConf 2008. I’ll cover what scrum is all about and demystify all the jargon we all hear around agile development. While at RailsConf come by our booth (#611 - the one with the giant ADS banner) and learn more about our referral program. See you all next week at RailsConf!

Is there some magic in a version number that I don’t know about? There must be, since so many applications use version numbers. I was thinking about this as I was adding tickets to the project from which What’s up in Ruby sprang, and mindlessly creating versions and putting tickets under each.

What constitutes a version? Is it a certain number of bug fixes or features? Perhaps a combination of both?

It struck me that in the web development world we don’t put version numbers on our apps, at least not externally. Last week we offered this set of features, and this week we have these new features. Great! But mommy always said it is good to have goals, so what are we to do?

First, stop labeling anything “beta” or “alpha” or “version 1.” There’s either something out there, or there isn’t. It might be available to a select few, but it’s out there.

Second, implement scrum. Put all of your tickets into a backlog and prioritize them. Plan what you will do for a sprint (10 working business days for us), do it, and then deploy it. At the end of that sprint you should have potentially shippable product. If you need more time extend the sprint. Be flexible with what a sprint means to you, as long as it isn’t longer than a month.

Don’t make your users wait for new features. If they work, put them out there. Get feedback quickly and respond accordingly. Software is continuously evolving. Let that evolution happen incrementally rather that in giant leaps. Involve your users in the process and you will reap the reward: happy users.

Atlantic Dominion Solutions uses agile development and scrum to successfully launch sites for our clients. But what is agile, what is scrum? You’ve heard the jargon - self-organizing teams, self-managing teams, scrum master - but they are rarely if ever explained. No more of that!

Come to our talk at RailsConf on Saturday May31st at 4:25, learn what agile and scrum are all about, and find out how you can use it to lead successful software development projects. Stop by our booth (#611) and learn more too. See you there!

Agile development not only benefits businesses that work with agile development teams, whether internal or external, it also benefits the teams. Here are the top 5 reasons to keep the team agile.

More involvement with the customer

Our team agrees that this is the #1 benefit of agile development. Damien told me, “…so you both gain a better understanding of how the app will work and be able to resolve issues and design adjustments quicker.” I couldn’t agree more. When I was playing the middle man role of PM I found that my translating back to the team wasn’t always 100%. When the team can interact directly with the customer, asking questions, getting clarification, discussing ideas, then there is a greater likelihood that what is produced is what the customer wants. This will, in our experience, work out well if the following is in place:

• The scrum master trusts their team
• The project is using scrum
• The customer understands scrum
• The customer understands that once a sprint begins it cannot be changed, unless they decide to prematurely stop it, and have meeting explaining why

Self-managing teams

As I said in my post about the business benefits of agile, I had heard this term thrown about without explanation. Let me explain it here. With scrum, the product owner (a.k.a. customer) puts stories into the backlog, and then controls the development by prioritizing the stories, with the most important on the top. At the beginning of each sprint at the sprint planning meeting, the team determines what they will commit to over the next 10 business days. They write out the tasks that make that story happen, and development begins. Each day there is a scrum, where the team and the scrum master get together. The team reports on the following:

• What did you do since the last scrum?
• What are you planning to do until the next scrum?
• Is anything holding back your progress?

In the daily scrum, the scrum master is a leader, leading the team through the process. While the scrum master can offer advice, he does not tell the team how to go about their daily development activities. It is up to the team to decide the best course of action. They are empowered! What a novel idea, empowering the people that are doing the actual work. That is what is meant by self management: the team manages the “how” rather than a project manager telling them. For us, this is a no brainer. There is literally no way for me, as a manager, to be involved in the code as deeply as the development team, so why not have them make their own decisions? I trust them, and we all learn from our mistakes.

Centralized controls fail in the face of increased complexity

Another step in removing the bureaucracy of the past is to delegate decision making to the feet on the ground people, in our case the development team. This becomes increasingly important as complexity grows. Should the understanding of what “done” means for a particular story, the team is the best equipped to determine impact, to decide what changes are necessary, and to put the changes in place.

Increased team participation

According to Ken Schwaber in Agile Project Management with Scrum, “optimally, a team should include seven people.” Schwaber is obviously referring to larger projects, as that would involve our entire team. The point here though is that the larger the group, the less overall communication you have. I will use my senior project class as an example. We had 21 people in the class and started out using a waterfall methodology (due to the teacher creating the groups - UI, database, etc.). When we were all together as a large group, the dominant personalities stood out and only they spoke. When we broke into our smaller groups there was a lot more interaction and everyone had a chance to speak. Perhaps there is something intimidating about large groups that cause many to shy away from speaking…

Happy developers == productive developers

Moving to agile development and scrum, empowering our team to make their own decisions, and removing the communication barrier between our team and our customers are definitely the best decisions I have made in regards to our development methodology. Our entire team is very happy to be using agile, and love daily scrum; we look forward to it every day. The team knows that they are trusted to make their own decisions, and don’t have to check with a manager before implementing them. They are happier developers for it, and are many times more productive, as they are left to focus on producing the highest quality product that the possibly can.

Using agile development with scrum can require a fundamental shift in the way project managers think and approach software development projects. It requires one to be more of a leader than a manager. It requires a great amount of trust; however, if you don’t trust those you work with then there is a fundamental problem that cannot be addressed in this post. Ultimately, in my experience, the result is a happier customer who is getting what they want - a high quality product that is what the envisioned. If the customer is happy, then we have been successful.