I am starting a new section on my blog, called “what’s the deal with…”. Recently I’ve found a need to preface most of my discussions by setting expectations about semantics. Moving forward, I will be sharing some of my thoughts/opinions/insights on various buzzwords, trends or topics.

When I worked at LexisNexis, I had the opportunity to work on LexisNexis Publisher, which was run as an agile project (as opposed to as a more traditional “waterfall” software development life cycle project.) I came into the project mid-stream so did not get all the initial training the rest of the team did. However, I was quickly able to recognize what made this methodology so different, and the pros and cons of the approach.

Some of the principles behind the agile manifesto (which I just pulled off wikipedia, and of which I had not been aware existed before tonight) are as follows:

• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcomed
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication (Co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

In my time on the project team, these underlying principles were very evident. We had “sprints” of roughly 30 days. Activities were broken down into tasks that could be accomplished within that time. We would meet with the appropriate business units to establish the overall project priorities and the goals of the sprint, and then meet throughout the sprint for clarification as required. The basic premise was that you could never really get too far down the wrong path. This falls completely into my line of thinking, which I often chalk up to user-centered design.. In actuality, it’s simply about ensuring you’re meeting the client needs.

Once a month, we would present our completed work for the last sprint, and then prioritize features for the upcoming one. There was an ongoing list of features that the business units could add to at any time, and then at the sprint planning meeting, they set up a prioritized list. It was then up to the team to determine how much could be committed to based on feature estimates and overall hours of availability. The team would then divide up the tasks, and we would have a plan for the next month’s activities and commitments. The idea of having releasable code every month was a bit of a challenge in some cases. The idea was that no task should extend from one sprint to the next, and activities that consist of several subtasks can make that a challenge (for example, a UI redesign may require wireframes, creative, development and testing - all the while developers must not be ‘waiting’ for other activities to perform).

Every day we had a 15 minute stand-up meeting, where every team contributor answers three questions:

1. What did I do yesterday
2. What am I doing today
3. What are my impediments

This gives the whole team complete visibility into how things are progressing.

Agile software development was initially designed for a team of developers, so the idea is that any team member can take over any task. By answering the above questions at a stand-up meeting, it is easy to identify if tasks are taking longer than anticipated, and other team members can pitch in. Each team member is accountable for his own progress, but tasks can be easily reassigned as needed. We also had a spreadsheet that was updated daily that showed the hours burned towards the project and specific tasks, to ensure we were progressing towards our goal appropriately. Although I never participated in this, I’ve heard of agile teams where all the tasks were written on post-it notes, and stuck to a wall. In the daily meeting, everyone would grab a sticky note, and that would be his work for the day. It was generally expected that team members were 100% dedicated to this project This helped to ensure “other commitments” were not holding up progress.

The notion of a self-organizing team is quite interesting. The scrum methodology refers to team members as either “pigs” or “chickens”. This is related to the level of commitment to the project. Like a restaurant that serves ham and eggs, pigs are completely committed, which chickens are only involved. The ‘ScrumMaster’ (basically, a project manager in non-scrum terms) is a chicken, while the developers are the pigs. In a daily stand-up, the pigs run the show, and often the chickens don’t get to talk at all. I personally found the idea of the team managing itself very empowering, and useful. As the developers, we are the most aware of what needs to get done and the means to get there. The team was able to rapidly identify and mitigate risk internally.

Our team was quite diverse: I was specifically a front-end developer, and we also had testers, visual designers and writers thrown in the mix. This introduced some challenges, as there was not the umbrella support from other developers for these individuals with more specialized skill sets. Ideally, there should be no impediments from within the team, but this was a risk with tasks only specific people could perform. I believe, however, that this is simply a matter of theory being put into practice. If we wanted to streamline development, we had to have those specialized individuals in the room as well, to ensure the developers are getting the support they need to work effectively.

Another common assessment of agile development processes is that it’s a way to slim down estimates and effort; not requiring documentation. To some extent, this may be true. There is less of a need for firm documented requirements and implementation guidelines due to the speed of the implementation itself. However, a desire not to have to document is not a valid rationale for trying to work within the agile methodology. Documentation can only be omitted if the benefits it offers (rationale for design or development decisions, tracking functionality changes or enhancements, specifying best practices) are captured otherwise. In some cases, this may involve having consistent resources on the team that can offer that history. Some organizations still document architectural decisions or practices, just in a more light-weight form.

Naturally, a lack of documentation has drawbacks. It’s been noted that agile teams are most successful when the team are co-located, and consist of senior developers. Documentation can help bridge the gap when developers are not in close contact or do not have as strong a development background. In other instances, quick and dirty, poorly documented code can dramatically impact not only the quality of the code, but also the ability to build upon it moving forward. With such rapid development cycles, code must at least be in a state that future enhancements or refinements can build upon it.
This is actually another aspect of agile that was sometimes a challenge to developers. All the work done of the project should be a direct result of the prioritization by the business units. This means that some clean-up or optimization tasks that developers may want to do, may not receive the appropriate approval. It is up to a project team to determine how best to balance these pressures.

Even several years removed from working within this methodology, it still strikes me as a very viable, beneficial development process - under the right circumstances. I like the benefit to the client: they have performed the prioritization exercise and will get what the consider the most significant features. In return, they receive a realistic list from the developers of what is feasible within the time alloted. At the end of each month, they have the freedom to release code, to roll back, or to change direction completely. Developers can focus on development, having a clear sense of what is expected of them on a daily basis. It is easy for the whole team to identify and mitigate risk rapidly.

Because scrum is so team-focused, it’s important that the right people comprise the team. While the goal is for the entire team to be cross-functional from a capabilities standpoint, there is still a need for the team to comprise of strong, motivated, talented developers. There must be a high level of trust and personal responsibility for the team (as well as the project, and product) to thrive.