General information

Agile Development: Building an Agile Culture

Over the last few months I have described various components of Agile development. This time around I want to talk about building an Agile culture. Agile is more than just a codified process; it is a development approach, a philosophy, one that stresses flexibility and communication. In order for a development team to successfully implement Agile the organization must embrace and practice the appropriate culture. In this post will to briefly discuss several tips that will help develop Agile development. The Right People It all starts here: as with pretty much any undertaking, you need the right people in place, which is not necessarily the same as saying the best people. Agile development necessitates a specific set of skills that are not intrinsically related to coding mastery: flexibility, teamwork, and ability to take responsibility for a project’s ultimate success are all extremely important. Once the team is formed, management should work to bring team members closer together and create the right environment for…

General information

Agile Development: Sprint Retrospective

In my last two posts I’ve discussed how to carry out sprint review and sprint planning meetings. This month we’ll look at the final component of the sprint boundary process, the sprint retrospective, which is where the team analyzes its inner workings. Objective The sprint retrospective is an opportunity for the development team to review their performance over the previous sprint, identify strengths and weaknesses, and modify processes to increase productivity and well-being. Timing The retrospective should take place near the end of the iteration. It usually follows the sprint review, and can be held immediately following, but some sort of boundary should be established (take a short break, change the room, etc.) to make it clear that these are two very different meetings with very different purposes. The length of the meeting will change from sprint to sprint; budget as much time as you think you will need to fully explore team performance. If there isn’t much of substance…

Original Content

Agile Development: Sprint Planning Meeting

In my last post, I talked about the sprint review meeting; this month we look into planning a sprint. As I said last time, this meeting should be separate from the review, both to differentiate the two and to avoid meeting fatigue. Objective Sprint planning takes into account the overall project plan and the results of the previous sprint (as presented in the sprint review) and sets out a plan for the next week discrete development time period. Timing The timing of the sprint planning meeting is the subject of much discussion, and different teams adopt different conventions based on what they feel is the best fit for their particular process. Personally, I prefer to hold the planning meeting on the same day as the review. While this puts pressure on the Product Owner to quickly adjust planning materials based on the outcome of the review, it has several important advantages: The knowledge acquired…

Original Content

Agile Development: Sprint Review

At the boundary between sprints, there are three different tasks that an Agile team should perform: Review and demo the work completed in the finished sprint (Sprint Review) Plan the next iteration (Sprint Planning) Evaluate the team’s performance during the sprint and look for improvements (Sprint Retrospective) While it may be tempting to package that entire list into one long meeting, these should really be separate sessions. Each one requires a different focus and a unique cast of characters; plus, meetings can only last so long before efficiency plummets. Over the next set of posts I will be discussing each of these tasks separately, in the order in which I listed them. Even though planning happens first in any particular sprint, I prefer to look at the transition between sprints as a single process. So, we’ll start with Sprint Review. Objective As we’ve discussed previously, one of the core values of Agile is to prioritize working…

Original Content

Agile Development: The Daily Standup

The cornerstone of Agile development is the sharing of information. An Agile team that does  not communicate well is destined to fail: the focus on efficiency and short,  independent development cycles means development moves at a rapid pace, and there is much slack in the timeline to account for communication hiccups. Therefore, the each member of the team needs to be aware of what everyone else is working on, as well as any impacts and dependencies between her assigned tasks and those of her coworkers. With sprints lasting two or three weeks each, it’s imperative that team members be proactive about sharing the status of their work. While this can (and should) happen as informal conversations between team members, Agile provides a tool to encourage frequent communication: the daily standup. What it Is The daily standup is a meeting where team members discuss their own immediate goals and challenges. It is typically held at the…

Original Content

Agile Development: Tracking Progress

In my last post, I discussed effort estimation and scheduling, which leads into the beginning of actual development. But first, you need to decide how you’re going to track progress. Here are some commonly used methods: The Big Board In keeping with Agile philosophy, you should choose the simplest tool that gives you the functionality you need. If your team does all of its development work in the same physical space, you could get by with post-it notes on a big white board. There’s a lot to be said for a tangible object: it communicates the independent nature of each task or story in a way that software may not. It provides the team with a ready-made meeting point: if you want to see how the project is going, you have to go stand in front of the big board. A board can also help to keep projects lean and simple, because there’s only so much available…

General information

Agile Development: Estimation and Scheduling

In my last post, I discussed the creation of Agile user stories. This time I’m going to talk about what to do with them once you have them. There are two big steps that need to be completed in order to move from user story creation to development: effort estimation and prioritization. Each poses its own problems. Estimating Effort Because Agile development relies on flexibility and adaptation, creating a bottom-up effort estimation analysis is both difficult and impractical. You don’t want to spend valuable time analyzing a piece of functionality up front only to have the implementation details change because of something that happens earlier in the development process, be it a change in another story, customer feedback, etc. Instead, it’s better to rely on your development team’s expertise and come up with top-down estimates that are accurate enough to get the development process started. This may at times make you feel uncomfortable,…

Original Content

Agile Development: What is a User Story?

So far in this series, I’ve talked about the pros and cons of Agile, and reviewed the methodology’s core values. Today I want to move beyond the “what” and into more of the “how.” I’ll start by looking at user stories. A user story is the basic unit of Agile development. User stories should be written by the business, not by the development team. They should clearly state the business value that the project is expected to create, as well as the user that will benefit. The focus should be on the problem being solved, not the software being built. This not only increases efficiency, but also provides flexibility for the development team: how they solve the problem is up to them. There’s a generally accepted template for writing user stories: “As a [user type], I want to [specific functionality] so that [tangible benefit].” I’m not crazy about using this convention because it…

Original Content

Agile Development: Core Values

In my last post, I talked about some of the advantages of and potential problems with using Agile as your development philosophy. Today I’d like to build on that topic by talking about the fundamental principles that guide Agile development. There are four, each seemingly described as a choice between two competing priorities: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan In reality, the core values should not be taken as “do this, NOT that” statements, but rather as reminders that help the team prioritize the activities and attitudes that create the most value. 1. Individuals and interactions over processes and tools The first core value is my favorite one: start with the right people, then build your processes and select your tools to best fit them, rather than the other way around. A good development team…

Original Content

Agile Development: Pros and Cons

Recently I’ve been involved in a couple of my library’s web development projects that have used the Agile development framework, so I thought I’d share how Agile can help or hinder technical projects. In my last (non-library) job I worked for a software company that chose to make a full-scale transition from traditional development to an Agile development environment, so this is a topic that I’ve been thinking about for quite a while. Agile, for those unfamiliar with the basic idea, is an attempt to streamline development work by focusing on producing modular pieces of software that perform simple tasks on their own, but also build on each other to form more complex tools (kind of like the Voltron of software development). So what are the advantages and potential pitfalls of Agile? Pros Focus on Usability: The basic unit in Agile development is the user story, which documents a specific…