SCRUM is a great framework to adopt if you and your software development team wants to get things done. SCRUM works for us, so we encourage the people we work with to adopt it along with other Agile methods.

Here’s a few reasons why we like it:

• SCRUM can get you the highest business value in the shortest amount of time, assuming your priorities are right.
• It makes the release of your software less of a technical problem and more of a business decision
• It helps to project the amount of value your development team can deliver over a finite period of time
• It helps keep your development team and your product flexible so that it can change with the long-term needs of the business

We try to help all of our clients refine their product development process, so we’ve seen a few roadblocks that get in their way when adopting SCRUM. These are the top 5 ways to cause a SCRUM misfire:

1. Too Much, Too Soon

   Traditional development shops sometimes try to change their ways overnight. If you overwhelm developers with sweeping changes, it’s unlikely that everything will stick. There are many aspects to SCRUM and Agile, so why not take it one step at a time? First, you could start writing user stories. Second, you could start time-boxing your release plan. You can spread out the adoption and sell each facet of SCRUM on its own merit. Being a curmudgeon myself, I respond to change much better when it is spread out over time.

2. Being dogmatic and following the procedures to the letter

   SCRUM is a framework, not a dogma. It annoys me to no end when people criticize others for not having an “up to the letter” implementation of SCRUM. If you’re not changing your ways from iteration to iteration, you’re missing a lot of the benefit that SCRUM provides. During your retrospective, discuss what’s working and what isn’t. Change your ways for the next iteration, and see if things improve. Every company’s culture and operations are different, so why should you try to fit a round peg into a square hole? Bend SCRUM to your team’s will, and find what works for your organization.

   That being said, a lot of people think SCRUM is about having an open floor plan or rapidly changing requirements and development priorities without forethought. If you do only these things, you’re not practicing SCRUM or reaping any of its benefits.

3. No executive buy-in

   We’re getting warmer. It is so important to have C-level support for the long-term adoption of SCRUM and Agile methods. Take considerable time and effort with getting your executive team on board. When you miss your last few stories in a sprint (it will happen), your management team needs to understand the complexity and uncertainty around sprint planning, and how you already have a plan in place to address it.

4. A Bad Product Owner

   I’ve unfortunately seen this more times than I’d like to admit. Bad product owners mean bad user stories and priorities, which translates to sprints that miss the mark in terms of business value. Naturally, if stakeholders and board members aren’t seeing the results you’ve been promising, SCRUM will be forgotten as quickly as what they had for lunch two weeks ago. In the early stages of trying SCRUM out, work with your product owner intensively to make sure he or she is doing a good job of getting the right stories and priorities from stakeholders. If they can’t get make it work within a few sprints, you’ve got to respond quickly and find someone else to fulfill this important role.

5. Split Focus

   So you’ve got this great idea for implementing a framework where you can demonstrate predictable and reasonable estimates of what your team can do in a given slot of time. Your team members, though, are on about 4 different project teams and have their quarterly TPS reports due somewhere towards the end of the sprint. In my opinion, resources that are spread across multiple projects is the #1 cause of SCRUM death in an organization. Fight for your resources! If you can’t get a predictable and dedicated amount of time from your SCRUM team, how can you get can you accurately gauge velocity? If everyone has to work on multiple projects (which is a horrible idea), see if you can get them for dedicated times for every sprint. This will be really hard to do as the project priorities shift and fires need to be put out, so this should be a last resort. If you have some pull in the company, see if you can try restructuring project teams to be more dedicated. Nothing is more important for the successful adoption of SCRUM than protecting your team from distractions and the ever popular “Can you do me a favor?”. As a technical leader or someone that wants to see your product and SCRUM succeed, this is the battle you want to pick.

Are you struggling to get SCRUM working for you? What’s killing the adoption of SCRUM in your organization? We’d love to hear from you in the comments.

under_construction is a jQuery plugin that hides or overlays elements of a design that have not been implemented yet. The best part is that it is done completely with standards compliant markup and unobtrusive JavaScript.

This utility works extremely well in Agile environments where there is design work done upfront. I use it extensively and clients really appreciate the ability to see what’s done and not done in a new application.

In this update:

• improved namespacing – no more collisions. To update, your function calls must be of the form $.under_construction.<function name>
• improved opacity – Due to some functions that were recently made available in the latest versions of jQuery, I was able to restructure the overlay so you get a cleaner look over darker backgrounds.

See the demo for more details.

In the future, I’m hoping to add iteration/sprint labels to the overlays so the client or stakeholder can see at what point the feature is going to be built.

A few weeks ago, I open sourced a tool I often use when developing new products. Meet under_construction – a JQuery utility for hiding/overlaying elements of a design that haven’t been developed yet.

View the Demo

I wanted something that it is entirely unobtrusive and W3C compliant. No funky markup, and when you build a feature, you just remove the pending class from the elements you want to expose.

I’m planning to add more features. It would be great to add labels to the overlays so the stakeholder will know when that feature will be unveiled like Thoughtbot’s Mile Marker. I’m planning to implement that as another class. Of course, the design principal of staying unobtrusive and standards compliant will remain paramount.

Thanks to a great framework like JQuery, building this was a snap. I recommend using it in conjunction with jQuery Hotkeys

Kyle del.icio.us’ed me this article and I really dug it. Work has been really crazy lately – we’ve been ramping up development efforts so both coding and project management needs have increased.

Have you ever asked yourself the question: “Am I busy or productive?”. I’ve been asking myself that lately. Sometimes, less is definitely more. In the Agile Software world, there’s this whole idea of sustainable pace.

How productive are you as a developer after 60 hour workweeks and a lack of sleep? Every good developer should know when quitting is actually more productive than staying busy. If you’re burning the midnight oil and making frequent mistakes give these ideas some thought:

• Am I introducing flawed code that is going to haunt me later?
• If I’m observing many mistakes that I’m making, is it possible there’s many more I’m not realizing?
• Am I really contributing to burndown/velocity effectively?

Know when to quit! Your team members and your supervisors will thank you.

Sorry there’s been a void of posts here. My career has been changing very rapidly. I’ve become a part of a great company, and I’m looking forward to pursuing the opportunity there. There is extreme potential both in the business model and in my ability to grow and learn. I’ve recently been tasked with managing the software development process and with leading a great team.

With that, it is time to take a look at the subject matter of this blog. I’m hoping to gear my content more towards my daily experience as an Agile Software Developer and Project Manager in a startup rather than freelance development and entrepreneurship. I hope you’ll enjoy the small shift in focus as I learn along the way. As always, your feedback and input is what makes this a discussion rather than a monologue. I hope we can all learn from each other’s experience here.