Agile Programming

I’m always on the lookout for exercises and activities that illustrate some of the harder-to-convey issues in Scrum and agile. I just read a blog post by Certified Scrum Trainer Michael James that provides instructions for an exercise called “Planning a Party” that perfectly communicates the value of writing strong user stories and prioritizing them in a considered manner. You can take a look here.

It’s funny to think that something as simple as “planning a party” could better illustrate the function and value of user stories than something within a developer’s native environment, but everybody likes parties, so this one works great. As James describes it, participants are asked to imagine that their boss is throwing a holiday party for his co-workers and, in typical boss fashion, he wants the employees to do all the work! So participants are then given a list of vague and sometimes big directives and then asked to re-write them as agile-friendly user stories. Suddenly, questions about priority (which story is most important?) and order (which story should be completed first?) start driving the conversation. Before they know it, participants have simulated the same process of prioritization a Product Owner faces when prioritizing work and planning release dates. But since the context is immediately understood, it’s somehow less daunting than considering the same factors for a software project.

So who wants to plan a party?

Posted: August 12th, 2009 under Scrum.
Comments: none

Because I’m always on the lookout for great materials on new programming techniques, languages, and applications, I’m an avid reader of DZone’s Refcardz series. If you’re not familiar, the website DZone (www.dzone.com) publishes a series of educational resources that tackle important technical topics for developers. They’re short documents that target people who are essentially unfamiliar with the topic, so they’re great ways to get up to speed on emerging development techniques and quickly assess if you’d like to learn even more. Or, if it’s a topic you’re already an expert on, Refcardz can be great resources for educating new team members.

DZone’s most recent Refcard departs from its usual technical focus for a discussion of the agile project management framework, Scrum. It was written by a real expert on the subject, Michael James, who is a Certified Scrum Trainer for Danube, the company that makes the agile management tool, ScrumWorks Pro. Many people have a hard time articulating what Scrum is or how it differs from traditional project management, but James outlines Scrum’s roles, meetings, and artifacts in a way that is concise and easy to understand. It’ll be mostly review for those who already work in a Scrum environment, but, even then, I suspect veteran Scrum practitioners will recognize how well-organized James’ overview is and want to use it to help new team members smoothly transition into life on a Scrum team.

I’ve posted it for download below. Take a look. I think you’ll find it to be very valuable.

Scrum_Refcard.pdf

Posted: May 5th, 2009 under Scrum.
Comments: none

InfoQ’s picked up a heated debate on the Scrum Development list which is focusing on the rather pesky role of the Product Owner. Namely, who should be a team’s Product Owner? And should the Product Owner be dedicated to a single team or serve multiple teams. As the post points out, most Scrum practitioners are very divided on this topic and they tend to fall into one of two camps: those who think a Product Owner should be responsible for a single team and those who think that a Product Owner can handle multiple teams.

My two cents? Personally, I tend to think that a Product Owner should not divide his or her attention. If the Product Owner is having a hard time finding enough to do, chances are he or she could take a more hands-on role with the team. And given that there is considerable disparity in terms of authority between the team and the Product Owner, I think that Product Owners should be selected from outside of the team, not appointed from within.

Here’s CST Dan Rawsthorne echoing my sentiments on the topic: “I always have a simple answer to ‘who will be your product owner.’ I just ask ‘who are you holding accountable for success? Who has the bullseye on his back? That’s your product owner.’ In my experience, the PO is usually anointed from the outside.”

If you don’t agree with my take on the Product Owner, there are plenty of vocal Scrum practitioners ready to take your side on the Scrum Development list.

Read more on InfoQ (http://www.infoq.com/news/2009/02/product-owner-one-person) or follow the whole thread here: http://groups.yahoo.com/group/scrumdevelopment/message/36389.

Posted: March 5th, 2009 under Scrum.
Comments: 1

One of the trickiest problems that Scrum teams face is whether to allow a Product Owner to serve as a team member. Most Certified Scrum Trainers I’ve heard discuss the topic recommend that Product Owners not be a part of the team. The problem is that when a Product Owner participates in the team’s day-to-day activities, he or she undermines the team’s ability to self-organize. That’s not to say that Product Owners willfully sabotage a team’s chance at success. On the contrary, the sheer difference of the Product Owner’s “status” exerts its influence on the team’s perceived sense of autonomy to choose its course of action. For instance, Scrum asks that when a team estimates the level of effort it will require to complete a given story, the Product Owner not attend so that all team members feel at ease to honestly evaluate the story’s level of difficulty.

This problem gets even trickier if your Product Owner is also your Boss with a capital B. For smaller organizations, it’s not uncommon that the president or CEO would also act as a Product Owner. When that happens, it might be even harder to ask that he or she limit her involvement in the Scrum team. But the same rules apply. For Scrum to truly facilitate hyper-performing teams, those teams must be empowered to decide how they pursue their work. After all, that responsibility is accompanied by a sense of ownership over its success and a commitment to realize that success that is shared with the rest of the team. Besides, when a team is experienced at making tough decisions to get results, that frees up the Product Owner—and, in this scenario, president or CEO—to think about big-picture strategy. In that sense, Scrum is a sensible framework because it acknowledges that the Product Owner can’t—and shouldn’t—have his finger in every aspect of the business. Instead, Scrum recognizes the necessity of distributing both responsibility and authority.

Posted: January 16th, 2009 under Scrum.
Comments: none

When Scrum is introduced to an organization, it injects the company culture with a few concepts—self-organization, transparent communication—that may be somewhat foreign. Another idea that Scrum introduces that can rattle traditional managers is consensus decision-making.

Because Scrum asks that teams self-organize, that means that they must decide among themselves how to accomplish sprint goals. Invariably, not everyone on the team will agree as to what the best route to success is. When that happens, the team must reach a decision that everyone can live with, working toward a compromise between the team’s most extreme perspectives.

Unlike authoritarian decision-making, this process can take time. Instead of a single manager dictating a decision, the team must take into account a wider range of ideas and opinions and negotiate a middle ground that best addresses the problem. By considering so many points of view, the team is essentially consulting a wider range of knowledge and experience than a single decision-maker possibly could. It’s a process that certainly takes longer, which has led to some criticizing consensus-based decision-making as inefficient. But in reality, this approach yields decisions that are better informed and, consequently, drive results.

Posted: October 13th, 2008 under Scrum.
Comments: none

I recently read about an exercise that agile pioneer Boris Gloger created to illustrate how process flow in Scrum works. I haven’t had a chance to play it with my team yet, but it’s clear from reading about it that captures the basics of Scrum in a fun, memorable group activity.

To play, you’ll need as many as 20 balls (Boris recommends using tennis balls) and for your team to form a circle in an open area. The objective is for every person on the team to touch the ball once and to pass as many balls among the team as possible. The rules are: Every member of the team must touch the ball at least once.

1. Each ball must have “air” time.
2. Balls cannot be passed to neighboring team members.
3. Each ball must end with the team member with whom it began.
4. The entire process is time-boxed at two minutes and repeated a total of five times.

As you can imagine, it’s very difficult to pass even a single tennis ball among the team the first time. However, the team gets to see that, over the course of playing the game just five times, its performance improves greatly—and becomes more fun. It is recommended that the team debrief for 10 minutes after the five iterations to discuss what they observed. Usually, the team will note that its velocity improved with each iteration. It’s a simple game, which doubles as a great team-building exercise, but it captures how Scrum’s iterative development can lead teams to perform more efficiently than they thought possible.

Posted: October 13th, 2008 under Scrum.
Comments: none

As Scrum’s popularity increases, there is a rising demand for professionals with Scrum experience. However, since Scrum is still a fairly new management method, that puts many aspiring Scrum practitioners in a tough spot: They want the experience of working in a Scrum environment, but they need Scrum experience to get the job. Obviously, then, there is no better experience than actually working in a Scrum environment, but there are plenty of ways to build experience that will pay off in that environment.

One way to secure valuable experience is to attend a two-day Certified ScrumMaster (CSM) course. CSM courses focus on an interactive approach to learning the basics of Scrum, including its vocabulary, principles, and practices. The course lasts only two days, but most attendees find that the information covered really sticks due to the hands-on nature of the course. Several companies offer CSM courses and a full list of trainers and their schedule of courses is located on the Scrum Alliance website.

Of course, real life experience working in a Scrum environment is far more compelling than simply attending a CSM course. When an individual works on a Scrum team—whether as a ScrumMaster, Product Owner, Analyst, Developer, Tester, etc.—for a full year since completing a CSM course, he or she may apply to become a Certified Scrum Practitioner (CSP). The Scrum Alliance reviews and, based on one’s qualifications, approves the CSP designation. Clearly, the CSP title is attractive for employers, who view it as proof that an individual understands Scrum’s principles and processes and has practiced them.

Short of getting experience on a Scrum team, the next best thing is to illustrate to your prospective employer that you possess qualities valued within a Scrum environment. These might include skills such as pair-programming, test-driven development, continuous integration, and refactoring code. Apart from these development techniques, it’s important to demonstrate a strong background in collaboration and facilitation. Since Scrum places greater emphasis on the success of the team, rather than personal heroics, an individual who has proven his or her leadership potential—without extensive authority—would be an excellent candidate for the ScrumMaster role.

Beyond Scrum courses or, of course, working in a Scrum environment, an individual can prepare for a career in Scrum by developing certain skill sets and demonstrating personality attributes that would fit within the Scrum paradigm.

Posted: August 20th, 2008 under Scrum.
Comments: none