Posted on

Perfection

In golf, the perfect score is 18.

In communication between 2 people, the ideal is mind-reading.

In communication inside groups, the ideal is a flow of serendipitous interactions, perfect communication flow, with no meetings.

In teams whose aim is to create value, the ideal is continuous flow.

None of these ideals is attainable. That said, is it useful to consider available devices that might help you get close. In golf, there is practice and coaching and play. In 2-person communication, we might try SVO-p, or Nonviolent Communication, to help us get closer to perfect communication. For team-level communication about things that matter, we might try Scrum or Kanban.

What I want you to see is that perfect is something to shoot for, and that NOT getting there is normal. Therefore, to throw dimes (show disrespect) to devices that help is never productive … and actually counter-productive. Saying things like “The ideal is flow rather than kanban” completely misses the point.

Kanban is a very useful device for getting closer and closer to the perfection of continuous flow. To devalue a device because it does not achieve perfection is a perfectly flawed argument. That is like saying that focusing on your golf swing is stupid because people who have done so previously have never achieved the perfect score of 18.

Realize that perfection, by definition, is something you get close to, and by definition, never attain. That is NOT a reason to devalue devices that get you closer and closer and closer still, to perfection. Kanban is useful for paying attention to a continuous flow of value, and the relentless pursuit of perfecting that flow.

Posted on

Agile Boston Leadership & Governance

Agile Boston has a vision, mission and set of supporting values. These statements of intent and supporting core values create a basic set of understandings about who we are and what we are here to do. We use these statements of intent and corresponding core values to guide plans and decision-making.

 

Structure must be able to scale up AND down as needed. Decisions must be made without delay; consistent with wise decision-making. A bias toward action tends to create at least the potential for great results. Community activities can be predictable and orderly at one extreme, and unpredictable and chaotic at the other. Given this reality, we assemble a toolbox and we implement it. This set of structural tools allows us to optimize on relationship and connection … with the ability to rapidly respond to change,  as we execute on our stated intent to: innovate as we help raise the level of Agility in Greater Boston.

Here are the tools we use to structure our work, listing from widest to narrowest scope:

  • Sociocracy– a governance structure based on consent, circles and double-linking.
  • Scrum– One way to do work in teams
  • The Core Protocols– Structured Interactions for team greatness

 

Sociocracy: We use sociocracy for defining leadership relationships, roles, and related interactions. Sociocracy is a governance structure optimized on relationships. The assumption is that respectful relations lead to greater decisions and results aligned with intentions, or ‘aim’. Sociocracy provides rules for elections, making decisions, and acting. The case history of sociocracy includes scaling to very large structures of several thousand people. The Agile Boston Leadership Circle implements the canonical sociocracy structure. John Buck and Sharon Villines are the authors of WE THE PEOPLE, the definitive sociocracy guide.

See Sociocracy and We The People: Consenting to a Deeper Democracy

 

Scrum: Sociocracy supports any practice that is in alignment with sociocratic principles. Scrum is aligned with and supports sociocracy, and vice-versa. We therefore include Scrum in our toolbox for executing on authorized work. Scrum features are used to varying degrees based on the aims of the people doing the work. We Agile folks are familar with Scrum principles and therefore find them an easy fit when executing on tasks like executing community meetings, larger events and the like. The Leadership Circle uses Scrum as needed. It is important to note that Scrum is one of several available ways to organize, consistent with the principles of sociocracy. Any useful tool or framework in alignment with sociocratic principles qualifies for consideration and possible use when doing work. Jeff Sutherland and Ken Schwaber are the stewards of the canonical Scrum standard.

See Scrum Guide and Scrum Values. Agile Boston core values derive from Scrum’s 5-value set. See Scrum Values for more detail on this.

 

Core Protocols: The Core Protocols are formalized, interpersonal interaction patterns that tend to associate with genuine team greatness. Scrum and sociocracy alike support self-organization of teams. Self-organizing includes defining ways of engaging in dialogue, reflecting, deciding and the like. Other important interactions that great teams must address include asking for help, sending and receiving feedback, and developing interpersonal alignments. The Core Protocols from Jim and Michele McCarthy provide guidance and structure for these tasks.

We use the Core Protocols to help create a bias toward action. When we are struck, we evoke the Core and use it to get movement. The Core Protocols are 11 core interactions based upon 11 (hard) core commitments.

See the Core Commitments, The Core Protocols, and the web site of McCarthy Technologies.

The formulators of these important social technologies, Jim and Michele McCarthy, periodically post important podcasts and blog entries here.

 

 

Agile Boston Leadership Circle

The circle is composed of members who have demonstrated and invested substantial effort and energy in service to the wide Agile community located in the Greater Boston region. Additional circle members are elected by consent. Consent here is the sociocratic definition of that term. You may learn more about sociocratic consent here.

The Agile Boston Leadership Circle’s aim is to ensure all activities of Agile Boston are aligned with the stated intent of the group as articulated by the vision, mission and core values.

 

Current Agile Boston Leadership Circle Members Include:

Karen Spencer

Karen Favazza Spencer is an Agile Coach and Scrum Master living on the Boston North Shore. Karen has also held the corporate roles of Project Lead, Business Analyst and Business Manager. She has a background in Education and Psychology and a Masters degree in the Learning Process from Lesley College. An energetic and up-beat person, Karen maintains a strong user perspective and consultative focus when working with teams. She is known for her ability to clearly communicate complexity to both technical and non-technical audiences. Karen strives to “make it easy” for her associates with an attitude of shared ownership. She coaches teams in behaviors that strengthen collaboration and capture complex conversations with paper models that literally, as well as metaphorically, get teams on the “same page.”
Follow Karen on Twitter: http://twitter.com/#!/Seabreezes1

 

Dan LeFebvre

Dan LeFebvre is the founder of DCL Agility, LLC, a provider of agile and Scrum coaching, training, and transition services. He is the first Certified Scrum Coach in New England with over twenty years in software product development as a developer, manager, director, and coach. He has been applying agile practices to successfully deliver products since 2003.

Dan spent two years as the internal agile coach for Kronos, a Boston-based software company, where he coordinated and implemented Scrum within the 700 person engineering organization across all sites including Massachusetts, Atlanta, Chicago, Oregon, Montreal, British Columbia, Belgium and India. This resulted in increased visibility into the development process and a reduction in defects by 60% in 18 months.

 

Don Blair

Don BlairWith a passion for building high-energy, high-performance teams, Don led the adoption of agile for a pilot project with 40 developers at Cisco Systems.   Following the successful completion of the project, he worked with the leadership team in extending agile to the entire business unit spanning 6 products, 30 scrum teams and 200 engineers. Business grew by 28% and customer satisfaction reached an all-time high during this time, even while employee morale rose 10% as measured by an annual corporate employee survey.  Inspired to use his talents to benefit the larger Boston business community, Don now works as an independent agile trainer and coach. Reach Don via LinkedIn.

 

Ralph Fink

Ralph is an Open Space facilitator who has studied under Harrison Owen and facilitated Open Space events for Agile Boston, Sikorsky Aircraft, and many commercial and non-profit organizations. Currently pursuing a Doctorate of Management in Organizational Leadership, Ralph is a Product Development Technical Lead at Sikorsky Aircraft. Ralph provides technical direction and development expertise for ground-based information systems and leads Agile adoption efforts at the company.

Ralph has 25 years of software development experience and is a distinguished graduate of Temple University (BSEE) and Drexel University (MSEE). Ralph’s interest are diverse and include attending Group Relations conferences as well as mountaineering seminars and events.

Ralph is an avid outdoorsman and hike leader for the Appalachian Mountain Club. Ralph holds a Wilderness First Aid certificate and is an expert in four-season backpacking. By being close to nature, Ralph believes in the development of the human potential.

 

Dan Mezick

Dan Mezick smallDan is a coach and trusted advisor to executives, project sponsors, managers and teams developing complex products using Agile and Scrum. Dan’s firm New Technology Solutions, Inc. delivers Agile training, execuitve coaching and consulting to businesses of all sizes. Clients include Zappos Insights, Orpheus Orchestra, CIGNA, The Hartford Insurance companies, SUNGARD Financial. Siemens Corporation, Sikorsky Aircraft and dozens of mid-market organizations. Read his Blog, follow him on Twitter, see http://newtechusa.net or connect or email at dan [at] newtechusa [dot] net.

 

Leadership Entry Points

Additional Leadership Circle members are elected as needed from the ranks for Volunteers. Agile Boston Volunteers must first signal a clear understanding of the group’s core values and consent to aligning with them. Alignment in this context means applying the core values consistently, as guidance, when executing authorized tasks as a person occupying a Agile Boston Volunteer role.

Questions? Contact Us.

 

 

Posted on

Kanban and Scrum are Verbs, Not Nouns

Is it just me? The Kanban community folks appear to encourage and be fond of bashing Scrum. This is unfortunate since the Kanban and the Scrum are so closely related. These are not distant cousins but rather, brothers. They both encourage a generative flow of We.

Positioning Kanban as superior to Scrum and vice-versa is contributing to a sense of meaningless around the word Agile. Agile is beginning to mean “whoever had the biggest ego and yells loudest. Whoever can grab the socio-apparatus of the Agile community (The Scrum Alliance, Agile Alliance, the conferences etc) to steer them. Whoever can advocate their position even louder and more convincingly.”

Exhibit A is the artificial debate between which is better for Agile teams: Kanban or Scrum. Yes, Scrum fails in some organizations and does not  create much improvement in results. Kanban also suffers from these failures, typically in the same organizations.

In general, any failures of either are related to the culture in the implementing organization. In either case, Scrum and/or Kanban, the organizations doing the implementation need pain-killing drugs (commonly called a prescription) and a doctor (commonly called a coach). If they do not need a prescription or a doctor (to help them heal) they’d already be healthy, right?

 

Language is the Key

In the post The Flow of We I discuss nominalization, the act of changing verbs and adverbs (and other kinds of words) into nouns. Click the link to learn about it. We all do it all the time. It creates space to compare, contrast, disagree, and debate. Naming people, places and things is the primary way we make sense of the world we live in.

Scrum and Kanban are most useful to us in the English language when referred to as verbs, not nouns. We Scrum, and we Kanban. When we Kanban, We pay attention to the flow of work items through our group. We work with upstream and downstream partners to increase the flow of value. When We Kanban we increase the flow of We, by paying attention, as a group, to things that matter, like work items, classes of service, cycle times etc.

Likewise, we Scrum. When we Scrum, we first agree to some basic understandings, about roles and meetings and rules. Then We Scrum. When We Scrum, We open conversational space to discuss the actual details of requirements. We time-box most of these discussions. After We do some work, We reflect formally during a meeting We call “the Retrospective”. We also timebox this meeting.

Scrum is a verb. We Scrum. Kanban is a verb. We Kanban.

The Kanban community already realizes this, well below the level of collective awareness. What, you disagree, and do not think so? Guess again.

Check out this poster and slogan again, it says:

[Yes] … we Kanban. THAT is using the word Kanban as a VERB.

 

 

 

 

Post Script: 3 hours later, I already got three emails on this from folks out there. Moral of story: language matters.

 

 

 

 

 

 

Posted on

The Flow of We

The goal of a good team is continuous flow. Continuous Flow of what? Some say, “value”. Not so fast. Value is a function of We.

There is a “state of flow”. We think of this flow as an individual state, where personal productivity soars as time passes very quickly for a single person, where that person enters a slightly altered state of consciousness. That is an individual concept.

Some are talking about how, in the industrial revolution, We measured productivity by the widgets-per-day count, and how We are now 100% out of the industrial revolution. So far so good. Now,  these same folks argue that the new widget, the thing to measure, is something called flow. I totally disagree with using flow as the unit of measure of productivity, because flow as defined in pop-culture is an individual concept, not a collective concept.

In the modern world of work, productivity is a macro-property of teams, not individuals.

What really needs to be measured is the group-level flow of We or We-flow.

 

The Flow… of We

We is the collective sense that all of us (in the group) have substantial alignment, and that we all know what we are collectively doing. Alignment is the sense that We agree on some specific ideas, such as core values, that guide our collective and individual actions. So, flow is a pop-culture concept that applies to individuals. We is a collective sense. Flow of We is that flow of a collectively held sense of alignment.

Still with me? Flow of We is that exact same pop-culture individual-flow concept, experienced as a team. The flow of We has several subsidiary flows, or constituent parts:

  • We-Communication. This is the flow of Sending and Receiving at the level of We. It is verbal, and non-verbal. Think serendipitous interactions.
  • We-Knowledge. Knowledge flow requires We-Communication flow. This flow includes knowledge of the work, and each other.
  • We-Feelings. The flow of this social substance increases and can substantially accelerate flow of We-Knowledge.
  • We-Awareness. The flow of this social substance raises the level of consciousness of the group, resulting in more flow of We overall.

These elements manifest the overall flow of We. When one of these subsidiary flows gets clogged, the We-flow can suddenly stop. Reduced flows of the 4 elements above can literally stop the flow of We.

When it stops, it is a symptom that We have some fundamental problems with our team. Our sense of shared vision is diminished. This is what happens when Scrum and Kanban break down as devices. Scrum, Kanban and all the rest offer the possibility but not the promise of a flow of We. From the flow of We comes a nearly-guaranteed flow of insanely great products and services.

In the modern world of work, being great means being great with others. Greatness is being in the flow of We.

When the flow of We is continuous, you have a genius team. Jim and Michele McCarthy argue that average people can form a collective We-genius, at will, in the form of a team. I tend to agree. When you get there, you get flow at the level of team: time passes quickly, productivity soars, there is collective immersion.

The McCarthys often talk about how We no longer have to wait 30-35 years for individual geniuses like Einstein, Mozart, Freud or Jobs to show up and make a dent in the universe for us. Instead, We can make that dent in that universe right now, by building genius teams with currently available and well-understood socio-technologies like Core Protocols, Triads, Kanban, etc.

There are specific socio-technologies that can be used to increase the flow of We. These include Kanban, Scrum, Lean, Core Protocols and other practices with specific names.

Note that Kanban “Classes of Service” are a key device for generating both flow of We and the derivative flow of value so often discussed in Kanban circles. Likewise Scrum can help teams create insanely great products, by the same method: creating a steady flow of We on the team. Scrum encourages the flow of We through its mechanisms of the Daily Scrum, Retrospective etc.

This is somewhat stilted since Scrum has a start/stop nature by virtue of iterations. Thus Scrum is training wheels to help begin generating a flow of We in teams. Both Scrum and Kanban are used in teams and organizations with alignment problems. If they have good alignment, the We is flowing and in theory, there is no need for Scrum or Kanban.  Since these flows are almost nonexistent on most teams, we must use these devices. When we do, we get some good results right away, but not because these are great technologies. Rather it is because our We-flow is nonexistent. The subsidiary flows of Communication, Knowledge, Feelings and Awareness are low or otherwise not working well.

Scrum, Kanban and other social/team technology is just the starting point. Remember, team learning is not random. You have to intend it. If you have no intent to learn together, you literally have no shot at doing so. Teams that want to be great find the coaches and technologies and techniques they require to achieve their aims. And often, the great coaches find them.

That’s just the way it works.

Related Post: Team Learning is Not Random

Posted on

Open Space (Part 1)

Open Space is about an invitation. It is an invitation you can opt-out on. “Whoever comes are the right people”. If you show up, you are one of the right people. You opt-in to Open Space. No one makes you show up, except YOU.

The Agile community uses Open Space the same way kids play with matches. It’s acknowledged that the thing has power, and by playing with it, we admit we do not how to use it.

Open Space is about the transformation of teams, departments, divisions and entire enterprises. It’s about the transformation of entire groups of people; this includes volitional, intentional communities of practice.

 

 

 

Posted on

Stop Having Meetings

If you are really in a state of Free Standing Agility, you probably are not having very many meeting. That is because you have replaced them with serendipitous interactions.

Serendipitous interactions are nodes in an endless flow or chain of interactions. Examples include brief conversations of 2,3 4 or more people. These conversations are usually ‘listenable’ by others in proximity.

Think about co-located space. When a team is on one room, the entire space facilitates one flow-chain of conversation through time. I can initiate a conversation, or be invited to converse, or listen to the conversations of others. Co-location is a very good tool for eliminating the typical meeting.

The typical meeting is complicated to arrange, and has nearly-automatic dysfunction potential. I plan to explain this dynamic in much more detail a bit later. Let’s just assume for now that meetings are generally counter-productive. Don’t agree? OK, here, I have a question for you: when is the last time you participated in a KICK-ASS conference call? When is the last time you can out of meeting energized? OK, now let’s change channels: when is the last time you were in a meeting and wondered why you had to be there? When is the last time you told yourself, “this meeting is a complete waste of my time”. And so on. STOP HAVING MEETINGS.

To engineer these interaction flows, you need certain elements to be in place. These are depicted in the Swiss Cheese Model of Serendipity, depicted below:

 

Source of clip: http://informationr.net/ir/16-3/p491fig3.jpg

 

For now, suspend your disbelief. Act ‘as if’ this might be true, OK? Imagine a world of ‘no meetings’. What does it look like?

Now …..imagine a perfect score for number-of-meetings is ‘zero’, just like a perfect golf score is ’18’. We can never reach this ideal perfect score, and that is OK. What is more important is that we know the perfect score, and try to get closer and closer to it.

Yes, some meetings are essential. MOST ARE NOT.

Pay attention and notice that Scrum minimizes the meetings. It still has three. Scrum tends to minimize the number of necessary meetings. Scrum can get you questioning why you have 87 meetings a month. Co-location also tends to do this same thing.

Stop having meetings. Instead, focus on communication-flow in your work place, and engineer as much of this as you can. Did I mention that meetings can actually reduce communication flow across your organization?

In what other ways can you reduce your meeting count?

What changes can you make? What online tools might reduce your meeting count?

How many meeting that you attend do you actually enjoy?

What meeting are essential for your context? Which ones do not really matter?

What is energizing your organization’s focus on non-essential meetings?

Why are you attending meeting that you do not enjoy?

A good Agile Coach can help you think about (and execute on) reducing your meeting count while actually increasing your overall communication frequency and level of alignment across teams and the entire organization.

Posted on

Agile Coaching, Client Learning, and Money (Part 1)

Is client learning inversely proportional to short-term coaching revenue?

If the client learns quickly … and gets to Free Standing Agility (FSA) … does this reduce or even terminate short-term coaching revenue?

I have to say, generally speaking, YES. However, like any good policy, after a delay, being a service-oriented, service-optimized coach is optimal for revenue generation. It ends up making much more money over the long term… after a delay. Contributing factors include the generation of successful case studies, development of the client’s FSA, and the development of close friends and strong reputation.

Let’s do some analysis by unpacking this graph:

The horizontal axis depicts levels of short-term (not long term) revenue. This axis can be viewed as depicting the collection of billing over time. This axis is labeled [Coaches Billing and Revenues]. The vertical axis labeled [Free Standing Agility] depicts levels of client ability to proceed without requiring a coach to help continuously. The term Free-Standing Agility refers to a level of ability to identify and respond to change, as an organization, without help from an external source like a coach.

What is the Responsibility of the Client?

Clients often ask for a authoritative prescription– in effect, projecting authority on the coach … and expecting the coach to tell them what they “should” do.

What is the correct response from the coach in this spot?

Clients must be told they are responsible for their own learning, and that the coach plans to completely help with that … by conveying as much knowledge as possible in the shortest amount of time possible. By mentoring, by assisting in skills development, and as much as possible, not authoritatively prescribing. The goal is FSA- Free Standing Agility- for the client.

I want to make it clear that the client organization co-creates the learning situation with the coach. However, all too often what the client asks for is an authoritative prescription, the very opposite of what Agile is all about. This opens the door to all kinds of dysfunction in the coach-client relationship. Coaches need to be ready to discuss this dynamic with the client, in effect assisting the client in the development of rapid organizational learning.

OK, on to the graph. The graph (below) depicts four coach types: Service-oriented, Competent, Average and “Zombie”. Let’s look at the first three of these:

Service-Oriented Agile Coach

Depicted in green. Coach has high integrity. Coach is reflective and has achieved day-to-day personal mastery over his/her own behavior. Exhibits high levels of awareness and self-control and is consciously intentional. Coaching approach is optimized on client learning. Coach is willing to limit short-term revenues in pursuit of wider organizational learning development. Coach understands the inverse relationship between client learning velocity and short-term revenue generation. Coach actively chooses client learning over short-term revenue generation. Coach employs various methods and relationship structures to accelerate client learning velocities. Techniques may include arms-length agreements, limited-authority role, short-duration engagements, formal and frequent coach-client retrospectives, and other techniques executed with client, all designed to rapidly optimize client learning levels and ongoing organizational learning velocities.

Coach understands the nature of delays in long-term revenue generation. Coach accepts these delays and takes the long view. The Service-Oriented coach tends to make less money in the short-term and much more in the long term.

Figure 1: Short-term revenue dynamics of client learning, by Coach profile type. The 'Zombie' coach generates FOUR times as much billing overall, but client learning levels are about ONE QUARTER of what a Service-Oriented coach can help create. What gives here?

 

 

 

 

 

 

 

 

 

 

 

 

 

Competent Agile Coach

Depicted in orange. Coach has sincerity. Coach has competence and potential for mastery. Approach is optimized on client competence in prescribed and improvisational ways of Agile doing and being. Coach is interested in pursuit of good agility levels, and wider organizational learning. Coach is aware of the inverse relationship between client learning velocity and short-term revenue generation. Coach usually  chooses client learning over short-term revenue generation. Coach may or may not various advanced methods to accelerate client learning velocities. Coach understands the nature of delays in long-term revenue generation based on reputation and results, and is beginning to take the long view.

Average Agile Coach

Depicted in red. Coach has sincerity. Coach has competencies and is growing them. Approach is optimized on teaching the client  standard, semi-prescribed ways of doing and being Agile, in standard formats. Coach is interested in seeing team velocity increase. Coach is starting to be aware of the inverse relationship between client learning velocity and short-term revenue generation. Coach has less than 2 years experience and is gaining in competencies. Coach typically does not use ground rules and techniques like arms-length agreements to accelerate client learning velocities. Instead, coach focuses on delivery of A-B-C techniques such as canonical Scrum, basic and sound implementations of Kanban, TDD etc.

Coach probably has not thought deeply about the dynamics of short-term and long-term revenue generation from coaching.

Summary

The Service-oriented Coach is the ideal. Getting there takes experience, and a valuing of client learning over short-term revenue optimization. After a delay, the Service-Oriented Agile Coach develops positive change, wonderful case studies, many genuine friends, and a great reputation. All of this leads to more long-term opportunities to do great things, with great people, and be paid handsomely for this privilege.

Let’s go to work developing the profession of Agile Coaching. Part of that work includes paying explicit attention to genuine service as we examine what’s normal in our community.

In the next part in this series, we look at the Zombie coach: the coach that values revenue over client learning.

Thomas Paine says it best:

“A long habit of not thinking a thing wrong gives it a superficial appearance of being right.”

 

See also:

Previous Posts on Agile Coaching Ethics

Posted on

December 12-13, 2011 CLASS: Coaching Agile Teams

The Coaching Agile Teams class returns to Boston on December 12 & 13 ! Get more course detail here.

Coaching Agile Teams course description

Outcome

You’ll walk away from the course with your personal coaching improvement backlog – a tangible plan you can use to thoughtfully improve your coaching when you’re back in your daily circumstances.  We use your real world situations and scenarios throughout the class allowing you to craft powerful ways to address the challenges you face.  You’ll also have many new things to try with your teams and you will probably depart with a few provocative ideas to chew on (in fact, maybe wrangle with for a while). All of these outcomes add up to your ability to become the excellent agile coach your teams need.

Audience
The Coaching Agile Teams course is meant for ScrumMasters, agile coaches and project managers in transition – people  who are ready to take the next step beyond practices and principles and move into activating teams to achieve the full promise of agile.

 

The course in Boston is scheduled for December 12 and 13. Get more course detail here.

Coaching Agile Teams Instructor Michael Spayd

 

This course is tailor-made for you if:

  • You’ve had a few experiences as an agile coach and it just doesn’t seem to be working for you.
  • Your job has become routine and you notice the teams seem to be going through the motions, too.
  • Your teams get the practices and are doing well, but not getting the fabulous results you were supposed to get.
  • Your are an awesome agile coach and you want the skills that will help you earn the Certified Scrum Coach designation.
  • You are spread across many agile teams because your managers think agile coaching is not a full-time job.
  • You are not sure if the agile coach role is really right for you.

Course Content

  • What is Agile Coaching? :: Why is it Important?
  • The Being and the Doing of Agile Coaching
  • Interlocking Roles: Agile Coach, Product Owner, Agile Manager
  • When to Coach the Team, When to Coach Individuals
  • Skills for Coaching Teams, Team Members, Product Owners, Managers, Stakeholders
  • Coaching Styles and When to Use Them
  • Setting the Environment for High Performance Teams
  • Detecting and Solving Problems
  • Starting up Great Teams :: Repairing Existing Teams
  • Agile Coach Failure, Recovery and Success Modes

 

The course in Boston is scheduled for December 12 and 13. Get more course detail here.

 

Lyssa Adkins is teaching the class with Michael Spayd in Boston

Prerequisites
You must be a practicing agile coach with at least 6 months of hands-on experience. Ideally, you will also have Certified ScrumMaster or equivalent agile training.  This is not an Introduction level course, and we will not be covering the basics of agile or Scrum.  In addition, you will be asked to use what you know about your real teams throughout the class so that you can leave with ideas for helping them as soon as you get back.

The course in Boston is scheduled for December 12 and 13. Get more course detail here.

 

Posted on

November 22, 2011 EVENT: The 3rd Annual GIVE THANKS FOR SCRUM Event !

GIVE THANKS FOR SCRUM is the uniquely BOSTON Agile event.

No other city in the world can do it. Boston is the BIRTHPLACE of Scrum, because it is the home of Ken Schwaber and Jeff Sutherland, the formulators of Scrum.

To get an idea of how significant and unique this event is, you must examine the past events. Click here to see pictures and the goings-on from the 2010 GIVE THANKS FOR SCRUM event.

It’s that time again!

The Thanksgiving Tradition in Boston: Give Thanks for Scrum, Q&A on Scrum with Jeff & Ken, circa 2010

Time to honor the tribal elders of Scrum, Boston natives both, Jeff Sutherland (Somerville, MA) and Ken Schwaber (Lexington, MA). We can thank Ken and Jeff for formulating Scrum right under our noses here in Boston. That formulation went on to be adopted throughout the world, changing the working lives of many people for the better. And so, each year here in Boston, we GIVE THANKS FOR SCRUM.

 

 

 

 

There’s only a few places in the world you can capture a picture like this one:

Tribal Elders, passing the buck

Boston is one of these places. Where else can you get a picture of Jeff and Ken doing Q&A like this?

For 2011, you can  expect great sessions, great food, some live music, and a great day of socializing and learning about Scrum here in Boston. Seating is limited this year, to keep the quality of the experience high. Tickets go up in price as they are purchased, when about 150 tickets are sold, that’s it. No more seats. If you want to attend, hop on now. Don’t worry, we have a fantastic program planned.

You get THREE HOURS of Jeff and Ken at this event !

Ken & Jeff, chilling out, 2010
Ken & Jeff, Tribal Elders of Scrum, 2010

 

 

 

 

 

 

 

Please consider our GIVE THANKS FOR SCRUM sponsors:

 

The Sessions:

KEN SCHWABER on: What a Year !

The Standish Group now reports that agile projects are three times more successful than waterfall. People are noticing. Ken will talk about some changes that he and Jeff made to Scrum, how future changes will emerge, and the clarified role of the Product Owner. Bring drumsticks.

 

 

 

JEFF SUTHERLAND on: Why Teams Are Not Hyperproductive!

At Agile 2011 the authors of the Agile Manifesto agreed the only thing we would add to the Manifesto is “We Really Meant It!”. For some reason, most teams that claim to be agile are not following the Agile Manifesto and think that it is OK to suck forever.

We know exactly, step by step, how every team can increase velocity by at least 400%. In this presentation we will cover the specific issues that are not addressed by agile teams that keep them dysfunctional and cause them to fail to deliver on the promise. By eliminating these impediments every team can radically improve performance.

 

DAN LE FEBVRE on: Self-Organization and Transparency: Team Freedom ? Or a Path to Micro-Management?

With visible task boards, burncharts, and daily Scrums; the team has many tools to organize and manage themselves. But can management abuse these tools? Can it turn into a better way to micro-manage? One of the hardest habits that managers have trouble breaking is the need to drive the team by making task assignments and tracking the results. Even those who truly want to help their teams by managing the task board is not really serving them. Scrum calls for self-organizing teams. The Scrum Master’s job is to help teach the team to self-organize. We’ll talk about how to avoid the traps of micro-management and truly lead the team to freedom at work through self-organization.

 

 

DAN MEZICK on: News and Views (AM and PM)

Dan MezickDan facilitates the GIVE THANKS FOR SCRUM event, and covers Agile community news related to Scrum, Agile Boston guiding values and how Scrum relates to Kanban, Occupy Wall Street, Agile Coaching Ethics, and Agile Day in Boston, during the brief opening remarks in the morning and afternoon.