Heather McLean

I just registered to head to Agile Development Practices 2008 in Orlando, Florida. I will be there for two tutorial and two conference days, November 10 – 13. I won’t be making the APLN summit due to a conflict on the 14th. I will be posting about the conference ongoing while I’m there.

Here’s what my schedule’s looking like.

Monday, November 10

8:30 -12:00, 1:00 – 4:00: The Zen of Agile Management with David Anderson

Tuesday, November 11

8:30 – 12:00: Leading Successful Projects in Changing Environments with Pollyanna Pixton
1:00 – 4:00: Practical Agile: Real World Practices with Jared Richardson

Wednesday, November 12

8:30 – 8:45: Opening Remarks with Lee Copeland
8:45 – 9:45: Seven Years Later: What the Agile Manifesto Left Out with Brian Marick
10:00 – 11:30: Are We There Yet? Defining “Done” with Mitch Lacey
12:45 – 2:15: Pragmatic Agility with Andy Hunt
2:45 – 4:15: Beyond Best Practices: Keeping Agile Agile with Dan North

Thursday, November 13

8:30 – 8:45: Opening Remarks with Lee Copeland
8:45 – 9:45: Collaborative Leadership: A Secret to Agile Success with Pollyanna Pixton
10:00 – 11:30: When to Step Up, When to Step Back: How to Lead Collaboration with Pollyanna Pixton
12:45 – 2:15: Maximizing Team Dynamics and Overcoming Dysfunction in Agile Environments with Michael Mah
2:45 – 4:15: Scaling Agile Up and Out: A Tale from the Trenches with Ade Miller

Of course, this is just all the scheduled activities. In between there’s plenty of time for networking, discussion, and food. :)

It seems that now we have agile processes in place, we’re starting to look at lean as well. The topic of lean software development within the Scrum framework came up at a meeting earlier this week at my office and sparked a lot of discussion. Oddly enough, the topic also came up on David J Anderson’s blog this morning as well.

In particular, some of our Scrum Masters were talking about possibly adapting and adopting Scrum-ban¹, which uses the principles of the kanban² lean production process to implement a pull methodology in Scrum. This looks very interesting on the surface as it affords greater flexibility for inidividual tasks that are under development, but I have some reservations as well.

There are some advantages here that I see as appealing. One of the problems we sometimes run into with Scrum (and perhaps a symptom of our particualr implementation of it) is that occassionaly some team members will be over-allocated and others under-allocated. When we do our sprint planning, we assign stories to particular team members at that time, which obviously has the flaw of not really knowing (especially at this stage of maturity) how well each team member is actually utilized or if they’re going to get distracted with administrative or support tasks during the sprint. Scrum-ban emphasizes only assigning a minimum amount of work-in-progress to get started, then as tasks are completed, team members can pull a new task off the “ready” list. In this way, Scrum-ban seems to be even more “agile” than regular Scrum.

On the other hand, there’s a couple big stickers for me on Scrum-ban. First, it seems to throw iterations out the window on a surface level. As team members constantly pull tasks from the “ready” list, it seems that there is no well-defined start or end to ongoing work without artificially halting the process at some point. This could create a situation where some team members are idle while waiting for others to catch up with the end of the iteration.

Another one is that it seems to move in the opposite direction as Scrum regarding “individuals and interactions over processes and tools.”³ In level 2 Scrum-ban, the process divides up the task queue into several chunks: backlog, ready, specifiy, complete, and done.² (Some of my colleagues proposed additional classifictions, but I will only address the ones described in the article.) I’ll admit I’m just looking at this from an academic standpoint rather than the experience of actual practice, but it appears that this adds more administrative overhead. First, someone has to define what things like “ready,” “specify,” “complete,” and “done” really mean in the particular domain. Second, someone has to be constantly monitoring the ready queue to make sure it has a suitable amount of tasks classified as “ready” available to the team. Third, team members have to do two iterations of each task, first specifying and then completing the actual work. I would argue that specification should have been done before the task was classified as “ready,” though this admittedly depends on your definitions of “ready” and “specify.” Lastly, someone must confirm that “done” items are really done pertaining to the established definition. I think that Scrum-ban at this level is making Scrum more complicated than it really should be.

I’m going to take some time in the near future to analyze Scrum-ban in depth. I think I might be able to use the Scrum/kanban hybrid approach effectively, but it will need to be different than what Scrum-ban proposes to address my particular needs. I’ll post more on that later.

Additional reading:
Managing Change Requests Using Lean Methods and a Kanban Board
KanbanCon

Sometimes I wonder if some people just like to follow agile processes for the sake of the process itself. Such is how a heated discussion started earlier this week with some colleages over the topic of Scrum and iterative releases.

There were two sides to the debate. One the one hand, following the Scrum pinciple of “release early, release often” has a lot of benefit and fits will into iterative development. On the other hand, following what the Product Owner says sometimes comes into conflict: “What you did this sprint looks really great, but we want you to add these few things before you release…”

I personally think that the Product Owner should always be able to trump the process in this regard. Just because you produce potentially shippable code doesn’t mean that you should or have to release, especially if the Product Owner doesn’t feel that the current feature set is what he or she wants to release.

A vocal colleague of mine (who also happens to be a Scrum Master) was of the opinion that the team needs to see visible success. His opinion was the Product Owner shouldn’t be able to hold the team back from releasing indefinitely. The longer the “one more thing” attitude continues to proliferate, the closer you get to going back towards waterfall and killing your team’s morale.

I can see his argument, but at the same time enforcing the frequent release schedule like a hard rule just feels wrong. Agile is about adapting and responding to change, and if you can’t change the process to accommodate business needs, it seems somewhat hypocritical.

Of course, I also agree that the business shouldn’t be able to resort to old tactics to delay releases that would be perfectly viable. There has to be some sort of middle ground when negotiating with the Product Owner about what should and should not be released, and that part is where the Agile Manifesto comes into play.

“Individuals and interactions over processes and tools.” This is the part where individuals and interactions come into play. Regardless of whether you believe that releases should or should not be held to a regular iteration, in the end it should be the team’s decision. That decision should include the Product Owner, the Scrum Master, and the rest of the team. This way, you can achieve the result that is best for the business and best for the team.

Continuing my discussion about Scrum Masters from last week, I wanted to talk a little about “good” Scrum Masters. This came to my mind after conducting some interviews for my company for the position of Scrum Master of one of our more complex teams.

When I’m looking at a potential Scrum Master candidate, there are a few things I examine:

• Has the candidate actually done Scrum before? You laugh, but you’d be surprised how many people get in the door for the interview and then admit that they’ve only read about Scrum or done something only tangentially related like Agile Unified Process (AUP).
• Does the candidate understand the basic terminology of Scrum, such as “sprint”, “backlog”, and “velocity”?
• Does the candidate have experience with varying iteration lengths other than the standard 30-day sprint? Understanding the dynamics and contrast of running one- and two-week sprints is important.
• Has the candidate taught Scrum to others?
• Has the candidate dealt with problematic Product Owners, stakeholders, and team members before? If so, what were his or her tactics for reducing conflict and facilitating productivity and success?
• What has the candidate done to increase the morale of a team?
• What has the candidate done to coach a team to be self-empowering and self-managing?
• Has the candidate experienced failure with Scrum? If so, what did he or she learn from it?
• Has the candidate experienced success with Scrum? If so, what did he or she learn from it?
• What are the candidate’s feelings on team members fulfilling multiple roles, such as the Scrum Master also being a team member?

This series of questions allows me to gauge several facets of the potential Scrum Master. Namely:

• Does he or she understand Scrum both academically and practically?
• Has he or she encountered an extensive number of hurdles surrounding Scrum and handled them effectively?
• Is he or she willing to take a leadership role in coaching the team on Scrum and ensuring their success?
• Can he or she communicate effectively with team members, stakeholders, and Product Owners?
• Is he or she capable of handling failure as well as success?

Of course, that’s not taking into account the candidate’s particular temperament and ability to fit in with the corporate culture or any technical expertise they may bring to the table, but it does give me a good idea of their ability and scope as a ScrumMaster.