Posted on

InfoQ News: Agile Coaching gains traction

Agile Coaching has emerged as an essential role found in and around agile teams. New teams need basics, competent teams sometimes get lost, and great teams want to get better. Coaching has arrived.

For examples of evidence, consider the following:

1.Agile 2009 had a Coaching ‘Stage’ which is a conference track.

2. Classes exist now on coaching techniques and coaching agile teams.

2. Earlier, Rachel Davies published her book Agile Coaching (Pragmatic Press).

3. The Scrum Alliance has a relatively new, higher-level credential called Certified Agile Coach.

And finally, Addison-Wesley is now shipping the book Coaching Agile Teams by Lyssa Adkins.

InfoQ caught up with author Lyssa Adkins and asked a few question about agile coaching.

Here are the answers:

Your book Coaching Agile Teams is now complete, and in print. How does that make you feel?

I am thrilled beyond belief. I never set out to be an author, it just “happened” to me. It seemed like everyone I knew was saying things to me like, “That’s good! You gotta write that down” and “You should write a book.” So I did. And now I am so pleased to see the results of my agile coaching experience in book form and being used by so many coaches to “up their game” and help their agile teams excel.

What is the one thing you want the Agile community to really, really know? Be specific and detailed.

I am all about helping the next generation of excellent agile coaches to emerge. Why? I believe many organizations have used agile “in the small” so far, as an alternate project management methodology. In its fullest expression, agile is far more powerful than that. Sure, it works for pumping out the same work faster and yet there’s a sense that there’s more to get. And there is.

Excellent agile coaches know how to help their teams get more and move from the mechanical application of agile into a world where teams deepen their experience of agile practices and principles and then go further, to take up their deliberate and joyful pursuit of high performance. All of this made possible because they have an excellent agile coach as their guide. This is what I want the agile community to really, really know.

Why are you so passionate about agile coaching?

I have seen agile used to great effect and I have seen it used poorly and even as a weapon. When it’s used poorly or for ill, I see a wastefulness that I cannot abide. When people tell me they hate agile because it makes them work overtime and squelches their ability to innovate, I cringe and cry, “It doesn’t have to be that way! In fact, agile is set up to give you a work/life mix that works for you and is supposed to unleash your innovative mind.” I believe one of the key differences in a team with a negative experience like this and one with agile in full effectiveness and liveliness is the skill and ability of the agile coach. And, it just so happens that agile coaching is where my personal agile journey occurs, so the need and the personal story merge. That’s why I am laser focused on helping coaches coach agile teams.

The book Lyssa wrote, Coaching Agile Teams , ships to bookstores any day now. The book includes chapters on “Coach as Teacher” and “Coach as Facilitator”. These are particularly interesting chapters, as they are about techniques for accelerating team learning. The chapter “Navigating Conflict” is especially useful for coaches new to facilitating communication between people when substantial differences exist between them. Differences are the raw ingredients of group learning, and this chapter provides solid guidance on navigating these differences such that the team is the winner.

Coaching is part teacher, part mentor, part facilitator, part mediator and part problem solver. The role of agile coach is an interesting and demanding one. Being coached is now established as a valuable practice, and agile coaching is now a profession.

Stay tuned for the upcoming interview of Coaching Agile Teams author Lyssa Adkins, for more detail on the essential role of coaching on agile teams.

About the Author

Dan Mezick is an Agile coach and trainer focused on Scrum. He’s a 3-time presenter at Agile2007, 2008 and 2009 and an invited speaker to the Scrum Gathering (Orlando) in 2010. Dan’s company provides Scrum training and Agile coaching, counsel and guidance to executives, managers and teams. Learn more about Dan here.

Posted on

Scrum Structure for Distributed, non-IT, Volunteer Efforts

Copyright (c) 2009-2010 Dan Mezick. All Rights Reserved.

Background

Work is increasing distributed; Scrum can be adapted to fit. Some projects have these characteristics:

1. Distributed globally; it is unrealistic to assume that the people involved can get face-to-face time
2. Volunteers populate the leadership and teams
3. The work may not be related to IT or Software
4. The work has fuzzy requirements that are ever-changing and based on events
5. The work has the potential to dramatically scale up or down, meaning the total number of people involved must shift quickly to match

Projects like this need a flexible Scrum structure. The following Scrum structure can adapt and be flexible as the project scales up and down. The structure can contain the current workload and scale—up and down. We do not want to change Scrum structure all the time as the project shrinks and grows. We need a durable and lasting and effective structure. It must handle distributed, global, all time zones, non-IT project, fuzzy ever-changing requirements, and no known end date, all done with volunteers.

Proposed Scrum structure
The following diagram and text describes a candidate structure that addresses the challenges of a distributed volunteer project while remaining true to the Scrum values. This diagram depicts the largest scale and is fractal; that is, it can be repeated to any arbitrary size and scope.

Projects with the characteristics above need a flexible Scrum structure. The following Scrum structure can adapt and be flexible as the project scales up and down. The structure can contain the current workload and scale—up and down. We do not want to change Scrum structure all the time as the project shrinks and grows. We need a durable and lasting and effective structure. It must handle distributed, global, all time zones, non-IT project, fuzzy ever-changing requirements, and no known end date, all done with volunteers.

Please note that a more compact form of this structure is described at the end of this document. That more compact structure can be used as a starting point. As the project grows, it can grow in this direction. Click the link to see this more compact form, based on the Bioteams model.

This is a flexible Scrum form, that is durable at any size, from very small to very big. Thus this structure encourages shared understanding at all phases. This eliminates the waste inherent in having to negotiate a new structure every time the project changes in size, scope, up or down, etc.

Diagram notes:

1. AUTHENTIC SCRUM STRUCTURE
a. Team Count. Topmost structure is bounded by green perimeter. It includes PO, SM and team of 7 or less members. This 7 is a rule to keep complexity low for the topmost PO.
b. Roles. The 3 Scrum roles serve to reduce complexity. Many roles, much complexity. Fewer (3 Scrum) roles, dramatically reduced complexity.
c. Top PO. The Topmost PO’s primary role is to a)see the big picture, b)make adjustments to direction based on that, and c) to at all times encourage and enforce values via positive and negative reinforcement of same. The top-level PO is/must be the key influencer of Culture across the entire project.


2. AUTHENTIC SCRUM CULTURE IS KEY
a. Culture. Culture is a collection of Values which inform the behavior of a group. Beliefs inform Values. Therefore Culture and Beliefs are linked via Values. The [Beliefs-Values-Behavior] needs to be constantly reiterated to the entire community of project participants. This is what makes the distributed worldwide effort cohesive and effective. Therefore, the Scrum values are key, as is reiteration, repetition and reinforcement of those values. The top level PO must embody these ideas.


3. ADAPTED SCRUM STRUCTURE:
a. Structure: Topmost Backlog is 7 Epics, each Team member owns one Epic. The red border depicts how each Team member is also a (sub)PO for a (sub) project, 1 per Epic.


4. 1:1 TEAM MEMBER:EPIC relationship, 1-to-1.
a. Each Team member is in turn a (sub)PO for a (sub)Backlog. The (sub)Backlog deconstructs the Epic into many Stories.
b. Topmost Team members play a two roles at two levels: Team member and PO for an Epic-based (sub)Project.


5. CADENCE; ITERATION PERIOD.
a. Iterations are two weeks long.
b. The topmost PO and SM run a weekly concall. This concall is in the daily Scrum format. The primary purpose of the concall is to track progress since the last call and to detect any “values events” since last call, to be addressed.
6. 1:M SM:TEAMS.
a. Each (sub)Project that addresses a single Epic is managed via a Scrum PO and SM. One SM can Scrum 2 or more projects. The area bounded in blue depicts one person occupying multiple SM roles across 2 or more projects. Thus, only 3 or 4 SMs are needed at the top.
7. AUTONOMY.
a. (sub)PO’s are free to run the project as they see fit, consistent with Scrum values. Each PO has a SM and a Team.


8. BACKLOG GROOMING AND PRIORITIZATION.

a. Current items. Each iteration, PO prioritizes the 7 items. If backlog item X is topmost for current iteration, then PO says that. If X and Y need to be priority #1 and #2 on backlog for this iteration, with a 60-40 split, PO says that.
i. From there Team members figure it out, AFTER the call.
b. New Items. If a new item appears, PO places on backlog. Team figures out where it fall ‘under’. If it is a top-most item, one of the existing 7 must be folded-under-another to keep the count at 7.
i. The team figures all of this out during call but likely (and probably more effectively) the next day after thinking hard about it.
c. Item completion. When one of the 7 items is complete, it can be deleted to make room for another new item to add in to form the 7-max. As a top-most item becomes done or less important or nearly done, it can be subsumed by the existing remaining 6, opening up a new spot for a new item.
d. Summary. The topmost 7 items are adaptive yet highly structured with intent to dramatically reduce complexity for PO, who can now focus on the horizon and near-term effects without being overwhelmed.


9. SCALE.
a. (sub)Projects that become large may further subdivide, by taking on the adapted yet authentic Scrum PO/SM/Team structure, where each item on the backlog is an Epic, there are never more than 7 items, and each Team member owns an Epic and develops a (sub)Backlog. This is done as needed, as the project evolves in scope, magnitude and volume of work.
10. STAKEHOLDERS.
a. Not depicted in the diagram are the stakeholders related to each PO in the structure. Stakeholders may advise any any PO on any matter at any time.


11. BACKLOG MAINTENANCE BY PO
a. Add Item
i. Items are held to 7, when a new item is added, it as appended to become 8. The team figures out how to incorporate the item to bring the count down to 7. How this is accomplished can take many forms. The team decides the form of incorporation of the new element in to the 7.
b. Change Item
i. PO communicates to team about the changed item. Team figures out how to incorporate the change to maintain stability of the 7 items while incorporating the change.
c. Remove Item
i. Done. Items may be removed as the backlog item gets done. A backlog item’s remaining few elements may be placed elsewhere, such that the backlog item is nullified. Takes the count down to 6 and makes room for a new 7th item. PO’s job as backlog owner is to notice the done-ness and communicate to team the perception that this backlog item is done. Team decides how to clean it up.
ii. Obsolete. Items may become obsolete. Events and situation may render an item so unimportant that does not just have a low priority, but in fact needs to be removed from the backlog to make room for a more pressing set of concerns. PO communicates the fact that the backlog item is obsolete; team decides how to close it down in a timely manner.
iii. Items may need to be split due to growth. In this case PO communicates to team the perception that a Epic is too big, and needs to be split. If there are now 6 items, this is easy since there is room for a 7th. If there are now 7 items, some items need to be collapsed elsewhere to make room. In all cases team works with PO to accomplish the split and related delete(s) that may be needed.
d. Prioritize Item
i. At the start of each iteration, PO prioritizes backlog. PO orders the 7 items and communicates to team the percentage of focus on each item for this iteration. Team figures out how to accomplish this during the iteration.
1. Typically, the iteration focuses on the top 2 or 3 backlog items. Each of these is assigned a percentage of the total effort, for example 60-40 or 50-30-20.
2. Top-level team members (1 of the 7) who have bottom-most backlog items for this iteration volunteer to the extent they are willing, to enlist as sub-backlog team members. The team figures this out.
3. Note that the entire focus of the team of 7 is on the topmost prioritized backlog items as communicated by the PO. This is pure Scrum, adapted to a distributed, all-volunteer, non-IT project.
12. CORE TEAM MAINTENANCE
a. Seven backlog Items, seven people: The team is always 7 or less people, each tied to an Epic on the topmost backlog.
b. Selection of the 7. Initially there are 7, selected according to some criteria. Once the 7 are formed and linked to the 7 backlog Epics, some process for rotating people out and selecting new people in to the team is needed.
i. Fluidity. The team of 7 work as a fluid team, working where they need to work per iteration,. This is based on PO’s prioritization. If my Epic is low-priority, I enlist as a member of the sub-team that is addressing the work for this iteration. Thus, I work with you (as a peer), I work for you (as a member of your team) , and sometimes you work for me as a member of my team when my Epic is the focus of the iteration. Note that this requires an advanced skills in teamwork and a real sense of team overall.
ii. Term limits. The top-level 7 team members probably need to have some kind of term limit, such that new candidates are constantly being groomed. This encourages a healthy, robust system of team development and a farm system based on accountability, mentoring and trust. The 3-rings of Accountability inherent in the Bioteams model is the preferred way of pulling this off. However each individual in the team of 7 may organize their teams in the way they prefer. Over time best practices emerge and everyone gains experience on each other’s teams, on a per-iteration basis. See 12.b.i.
iii. Core team, Extended team, Ancillary team. The bioteams model has 3 rings.
1. Core team. The Core team is the center and has the most authority and information and connection to sub-PO. The Core team takes direction from the PO.

a. Core team members are candidates for ‘team of 7’ membership on the top-most backlog.
2. Extended team. The Extended team has a little less authority, less information, and less direct contact with PO. The extended team executes on work that is largely prepared by the Core Team.
3. Ancillary team. This Ancillary Team has little authority, and little information beyond the detail found in pullable backlog items. This is the entry point for anyone that wants to come into the project.

BIOTEAMS RINGED STRUCTURE

3: Core team; 2: Extended team; 1: Ancillary team

13. ALTERNATE STARTING POINT; SMALLER SCALE
a. Overview. The project can start smaller, with a team that has a bioteam structure, with the same max 7 Core team members, and an Extended and Ancillary team as outer concentric rings. In this compact form, there is one huge backlog, one top-level PO, one top-level SM, and one Team with 7 Core members. This structure can later scale up as needed.
b. Detail.
i. The bioteams structure provides an entry point, a “farm system”, and a progression of Commitment.
1. Entry point. The outermost Ancillary team is the porous entry point where anyone can probe the project by pulling backlog items. These items available to Ancillary team members are NEVER on the critical path.

2. Farm system. One of the 3 rings is the Extended team. This non-Core team layer provides the candidates for Core team membership and allows a rotation of Core team members.
3. Progression of Commitment. People who join the project can enter at the Ancillary Team level, prove they can do work, and then move into the Extended team, where they get closer to the Core, get more access to more responsibility, authority and information, and develop as candidates for Core team membership

BioTeams References:

http://www.bioteams.com/2008/09/08/the_3_rings.html#more

http://www.bioteams.com/flash/IsYourGroupaBioteam.html

http://www.bioteams.com/2008/04/04/online_team_assessment.html

http://www.bioteams.com/2009/01/12/bioteams_101_introduction.html#more

**end**

Posted on

News and Events of Interest to Agile Boston Members:

August 16 2008: The Connecticut DotNet Users Group is holding the 1st annual CODECAMP event in Bloomfield, CT (a Saturday). This event is a FREE, community-driven, all-day event for developers. Speakers are local or regional developers. Topics are based on community interest. Sessions are original and feature a heavy technical focus.

Dan Mezick is scheduled to speak on Visual Studio/.NET 3.5 topics including Advanced Object-Oriented Techniques, Language Integrated Query, Reflection with Attributes, and of course the main event is: the presentation of Scrum Best Practices. Learn more at the CTDOTNET.ORG web site.

May 05 2008: The Agile2008 conference leadership has invited APLN leader Dan Mezick to present his original research on The Hidden Life of Groups at the Agile 2008 Conference to be held in Toronto August 4-8. The session is scheduled for the Breaking Acts stage of the Conference. See the session abstract here.

April 16 2008: SNEC-PMI (Southern New England Connecticut Project Management Institute) is having Dan Mezick speak on: The Agile Revolution. Sign up at snec-pmi.org. See the session abstract here.

Posted on

How to Become a Member of Agile Boston

Anyone can attend a meeting and meetings are FREE for members. Non-members pay a $5 admission.

Membership at Agile Boston gets you:

1. Complimentary admission to monthly meetings of AGILE BOSTON;

2. Access to jobs listings;

3. The ability to post job listings;

4. Discounts on events like GIVE THANKS FOR SCRUM and AGILE BOSTON OPEN SPACE;

5. Access to exclusive MEMBERS-ONLY meetings !!

Typical AGILE BOSTON attendance is in the range of 80 to 100 members.

A representative from sponsor Rally Software, addressing a meeting.

Membership cost is nominal and saves you money. We charge a small amount for each meeting and the membership is a little more than 1/2 the price of attending each meeting during the year.

Membership Annual Dues: $29

Each Meeting, non-members: $5

Each year, we hold a couple of BIGGER events.

Attending these events automatically gets you membership for the current year.

This means that when you attend an event like AGILE BOSTON OPEN SPACE 2010, you are actually purchasing an annual membership and getting the event for FREE.

The crowd of 240++ at GIVE THANKS FOR SCRUM 11/25/2010

Got questions about membership?

Contact Us to discuss Agile Boston membership.

Posted on

Q & A With Johanna Rothman of Rothman Consulting Group

Johanna Rothman of Rothman Consulting Group works with companies to improve how they manage their product development–to maximize management and technical staff productivity and to improve product quality. Johanna is a prolific author on project management topics. She is also most recently the volunteer Chair of the Agile2009 conference, the largest Agile community conference in the world (see http://www.agile2009.com/).

Johanna is speaking at Agile Boston on September 23, 2009. You may RSVP here.

One of Johanna’s passions is applying agile techniques to project portfolio managment. She speaks on this topic at Agile Boston on Sept 23 2009. What follows is a quick interview on what this is and why you care. It’s important !!

THE INTERVIEW: with JOHANNA ROTHMAN

1. What is Agile Portfolio Planning?

Planning (that is managing the project portfolio) is the set of decisions about when to start and stop each project and which project is #1. It works well with agile projects because agile provides a chance to re-evaluate the portfolio at the end of each iteration.

2. Why is it important?

It’s important because otherwise people are likely to multitask. The multitasking doesn’t even have to be on other projects. If someone interrupts you with a question from another project, do you know if you should answer it? If your project has a higher rank, that person should not ask you. If that project has a higher rank, it’s ok to ask and take the context switch. That’s because the other project is more important than yours, and you can take the context switch hit, but missing information on the other project is not acceptable.

3. What beliefs must be held by the organization to effective plan with
agility?

The organization must understand and be able to deliver in increments. I prefer time-boxed increments, but I can live with increments 🙂

4. Are there any cultural beliefs in an organization that might be impediments to this approach?

Of course! If the culture does not allow questioning, such as “Should we do this project at all?” I don’t see how to succeed with project portfolio planning. If the culture will not accept management collaboration to determine the project portfolio, that’s an impediment.

5. Tell us a scary story about portfolio planning, or the lack of it.

I once worked for an organization that didn’t have enough people to staff all of its projects (Sound familiar?). We had a strategic planning offsite. We spent 2 days working through what our strategy was, and came up with “Focus on Five.”

You know as well as I do that people don’t focus on *five*. They focus on *one*. We didn’t have a useful project portfolio, we didn’t choose good projects to work on, nothing changed. Oh, except we wasted two days at the offsite.

You’ve probably heard people say “I’m working on so many projects I don’t know what to do first.” That’s the problem that project portfolio planning solves.

Johanna’s book on the subject ‘MANAGING YOUR PROJECT PORTFOLIO:

6. You write ALOT, where can I find some of your writing on this topic?

On my blog, http://jrothman.com/blog/mpd. I’m also writing for PM Boulevard, specifically on this topic, and a little on gantthead.com .

7. What books are out there on this topic? Is yours the first?

Jochen Krebs has a book out, and I haven’t read it. I’m not aware of others.

8. You are the Chair of the Agile2009 conference just past. Did you any apply agile portfolio planning techniques to this project? If so, where.

Yes and No.

No, because this was a project. I was the project manager and there were no other projects from the Agile Alliance for me to try to manage.

Yes, because I was balancing all my other work. I would work until I got to a done place on other projects, or decide which project was most important right then.

9. Most people want to avoid “being wrong” and technology people are especially skewed this way. How can we encourage portfolio planners to ‘fail fast’ if they have a bias against admitting a mistake? How important is it to be willing to admit mistakes in this domain?

Instead of calling it a mistake, call it “more information.” Then, it’s not so hard to know if we’ve made a mistake, but we are getting more information. If you’re planning a project portfolio, the idea is to build in feedback loops so you can stop a project once it’s delivered enough value. That’s the more information part.

10. In your writing, you suggest that program managers meet with project managers once per iteration. Please explain why that frequency is better than, say, once a week or even more frequently.

Assuming an iteration is no more than two weeks long, once an iteration is probably enough. At a program team meeting, it’s important to air risks to the entire program. Some folks try to do this with Scrum of Scrums, and maybe for software-only projects a short once-daily meeting is right. My experience has been that once daily is too often, that once weekly *or* as often as people know enough about risks to the entire program is the right amount of time.

I also recommend that people use their brains, so if you think that once a day is right for your project, go for it! As long as you can talk about progress, or lack of expected progress, and risks, you’re meeting at the right time.

BTW, if you’re not using agile, I strongly recommend that program managers meet with the program team once weekly. Not any less often. That way, everyone is accountable for progress and risks.

11. How important is it for the iterations of multiple related projects to begin and end on the same day? Is it important at all? If so tell us why.

It’s critically important that everyone have the same drumbeat, which is why iterations need to start and end on the same day. Otherwise, people can cherry-pick the backlog, among other problems. It’s also too easy for people in offset iterations to break the build–unintentionally–and delay others from making progress.

12. Assume the reader has no plans to attend your talk on September 23,due to a commitment elsewhere. What is the single most important agile portfolio planning fact you want this person to know?

Do not multitask on several projects. Choose one project for now, work on the most valuable things you can do for that project, and get to a finish state.

Attend the Meeting !!

Johanna is speaking at Agile Boston on September 23, 2009. You may RSVP here.

Please help us deliver a great meeting by complying with these simple ground rules.

DIRECTIONS TO MICROSOFT WALTHAM.

Posted on

About Live Music from Dan Hermes, innovator and developer of ClassiGroove

Dan performs for us from time to time

Dan performs for us next on November 25 2009

Dan Hermes, born 1970, is an internationally recognized audiovisual artist, curator, composer, keyboardist, technologist, and founder of Dan Hermes Fine Art , the Hermes Orchestra ,and Lexicon Systems.

In 2004 his debut CD, Hermes Orchestra: Live, aired on National Public Radio and in Europe. The Hermes Orchestra completed a concert series in 2003 sponsored by International Society at the Tremont Theatre.

Mr. Hermes scored six films for the Boston-based “Midnight Shorts” project. He was sound editor on NYC-shot short film “Malefactor”, which screened at the Pawtucket Film Festival in 2003. Commissions include Suite for Cello, Flute, Piano and Synthesizer for the Essex Chamber Music Players. For composer Mark Perreault, Mr. Hermes produced a CD of the Newton Symphony Orchestra entitled “The Testing LP”. Mr. Hermes DJed a rap battle for T-Nice Records in Waltham, MA.

He produced, arranged, and engineered pop, rock, soul, folk, and industrial dance music written by Kyra Marino, Arian Allen, Cameen Copeland, and Eric Kneipfer, among others. Mr. Hermes performs solo piano concerts, most recently at the Zeitgeist Gallery, Tremont Theatre, and at the Essex Chamber Music Players Piano-thon. Author of the manual series “Classigroov: Modern Improvisation for the Classical Musician”, Mr. Hermes has developed a unique style of modern improvisation called Classigroov and provides lessons and workshops on the topic in the Boston area.
With over twenty years experience in the software industry, Mr. Hermes is the founder and senior IT Consultant for Lexicon Systems, Inc., a Boston-based enterprise software development firm, serving clients such as Fidelity, Blue Cross and Blue Shield, and Computerworld Magazine. He provides .NET Architecture and IT Management Consulting services throughout New England.

LINKS TO THE WORK OF DAN HERMES

Artist/General Bio:

http://www.danhermes.com/

Audio Clips: playable in Windows Media Player

Clip Title: WAKE … http://www.hermesorchestra.com/mp3/Classigroov/PianoSolo/Wake.m3u

Clip Title: HABIT … http://www.hermesorchestra.com/mp3/Classigroov/PianoSolo/Habit.m3u

Lexicon Systems, Dan’s IT services consultancy:

http://www.lexiconsystemsinc.com/

Dan plays for us for the first time on September 23, 2009 at our MONTHLY MEETING

DIRECTIONS TO MICROSOFT WALTHAM.