Wagnerblog

Under the best of circumstances, Agile Methodologies – especially SCRUM – puts the development team smack dab in the center of the process and has the entire life cycle revolve around it. That’s why so many programmers love Agile. But even organizations that, for whatever reason, are not able to support a 100% Agile environment can benefit from some of the basic tenets of SCRUM.

Let’s get one thing out of the way. If you are a programmer, chances are you would love SCRUM. Love with a capital L.  I mean really…. Think about it… if you come from the typical top down process where “Moses delivers the ten commandments to the tribes”  -  in other words the Dir of Development sits the team down and explains XYZ has to be done in 4 weeks – if you come from that sort of place, and find yourself in an agile world where programmers look at “user stories” and estimate sprints while an entire team discusses and sets the schedule – you’d probably feel like you’ve made a wrong turn somewhere and ended in alternate universe.

Suffice it to say there is definitely a culture shift across an entire organization when you switch to Agile. Some companies may not be quite as ready as others to embrace the change.

One of the first victims to get hit by an Agile team is the persona of Heroic Programmer. The type of programmer who by design or default likes to single handedly save everyone’s bacon. Agile focuses on the effort, communication and process of the ENTIRE team – not just the lone gun slinger. People who need to be the Heroic Programmer in a company often will not like Agile very much.

Another victim of the rising popularity of Agile are dev shops that operate on outdated principles and support dysfunctional processes. Through the emphasis on team empowerment I find more and more developers take up the battle cry of “Give me Agile or give me … [fill in the blank]”  A recruiter friend tells me about candidates who will not entertain an offer at all if it  isn’t  in an agile shop. Kudos to them. There is much to like about improved team communication and process enhancements.

Even if your own company cannot be 100%  formally Agile, with everyone buying into the change,  perhaps you can use some aspects of the methodology to improve your own processes. That has been my experience.

One of the key features of Agile (SCRUM) methodologies is the prevention of process hijacking. In  my 20 years of work experience I found two major types of development shops – those driven by engineers and those driven by sales people. Whichever group controls the process ends up setting the corporate culture. Agile shares responsibility between both groups and therefore prevents either group from hijacking the environment. That’s admirable.

Agile teams work hard to deliver predictable, high quality results in a relatively difficult setting. Difficult because software development all too often seems to go against a normal  predictive process. Unlike a Model A Ford, software cannot be built in an assembly line fashion. Hence the difficulty.

The mandate of Agile development is to create an environment where that uncertainty is removed through an iterative process and  much, much, much more communication than any other development methodology I have seen.  Meetings before things get built, meetings while things get built and more meetings after your done building things.

I have seen two interesting situations in all these meetings: programmers who by nature might be more introverted become much more open, and stakeholders who are used to issuing an edict and walking away become much closer to the development team. Both are good things.

There are a number of books on the market that describe Agile and SCRUM better than I can, but in a summarized form, Agile consists of

• A prioritized product backlog of themes, epics and user stories
• A self managing and empowered, cross functional team
• A SCRUM Leader / Master
• One or more product owners / stake holders
• Sprints that break user stories into tasks and produce a certain amount of work over a specified time, most frequently 10 business days.

Of course those are only the highlights. There are a number of important “ceremonies” and behavioral changes that come with the SCRUM territory. For example the practice of daily stand up meetings where team members briefly touch on what is on their plate.

In my own experience, the area where Agile makes the greatest impact is in the shared responsibility and empowerment of the team. By giving the team a way to estimate, manage and build code quickly and iteratively the group as a whole tends to be very productive.

During my time as VP of Server Development of SkillJam Inc. I was able to move a dev team toward a more agile approach by making sure a few key features were in place. First and foremost, we instituted a good product backlog.  I purchased enough licenses of Fogbugz to take care of all developers, QA People,  project managers and product stakeholders in the organization. I cannot tell you how important some of the seemingly simple features of Fogbugz became once we started cranking out code. Something as simple as an email conversation thread being automatically stored and associated with the task or issue in Fogbugz is a life saver. (Instead of logging into Fogbugz to record a comment, an email reply to a mail sent from Fogbugz automatically shows up in the right position within the task comments. Nice!)

Having set up FogBugz we got busy producing a big picture prioritized list of work. Any bug, any feature request and even entire new products where organized by themes , user stories and tasks within the stories.

After some arm wrestling with the key product stakeholders and other Senior Management Team members I was able to get buy-in for the concept of 10 business day sprints ( 2 calendar weeks). These sprints could not be interrupted for unplanned tasks under any circumstances. That’s not to say an emergency shouldn’t be addressed by the team.  But let me tell you,  its not easy convincing a CEO that giving up the ability to demand something RIGHT NOW is good for business. In the end it was the prospect of better schedule adherence, better quality and lower defect counts that sold this effort.

As I said, we were not formally Agile across the entire board. Our organization loved a considerable amount of design up front. That meant more information was written down and documented in formal requirements than you would typically see in an agile shop.

At the same time, our developers and qa analysts met several times a week for progress checks – admittedly this could have been handled with daily stand up meetings to which we could have invited visitors ( as long as the visitors kept quiet), but in a nod to the PMO we continued with the legacy status meetings.

As work progressed through a sprint we needed to look ahead at the pipeline ( the product backlog ) . So toward the end of a given sprint the team leaders and myself would spend some time planning the next iteration to make sure we could address any problems before we had our next Sprint is to kick off. For the actual kick off itself, the entire dev team (including qa people) gathered around a large conference table where we projected to prioritized backlog out of Fogbugz on a large screen. The team as a whole took on the User Stories needing to be built – based on prioritization – and committed to a certain amount of work being done in the sprint. Frequently we invited stakeholders and product owners to these meetings in order to get immediate feedback to questions that helped us with the production of a Sprint schedule.

That’s it. Simple and straight forward. I was blessed with a fantastic team who had been working together for a while already. That made SCRUM planning easier. And yes I know this wasn’t the  comprehensive SCRUM setup that you read about in the many Agile books on the market, but even in this pared-down format we were able to reap the benefits of planned iterative production.