The Most Important Book on Scrum Since the Original

I have just finished reading a book that is, without a doubt, THE most important book on Scrum that has been published since the original.  This book is Tobias Mayer's, The People's Scrum.


Why should you read this?  

You should read this because you are likely in a system that must be improved--I deeply believe that all of us are.  You will likely not agree with everything, but in order to truly realize the value of Scrum or any agile development framework, there are things that you need to know contained in this book.  If you find yourself in agreement with everything contained within, this will be an excellent reference to share with others who may not be so fortunate.  Ultimately, you want to better the lives of your team mates and yourself in ways that are founded on experience and love (how's that for a bold and courageous statement?)  It's also a nice fast-paced read as these are essentially edited blog posts, none of which are more than five pages.

What was my experience?

As I read this book, it reminded me of the first time I read the Agile Manifesto--my head was nodding in accord so many times, I nearly became dizzy.

Based on the foreword, I was convinced that I would find something to disagree with Tobias on and was looking forward to the opportunity to have a great conversation with him and potentially have my mind expanded. But I didn't...his views are so close to my own as what he says could have been written by me (although I couldn't have written them as well). I suppose that comes as no surprise as one of my early strong influences was Kert Peterson as well. We also seem to share strongly-held (as in concrete reinforced with rebar) views on the importance of humanity, decentralization, and co-location in innovative and creative work.

I suppose I didn't learn too many new things in the book, but they were told in a way to convey important meaning to the people who actually do the work and are the main focus for the Scrum framework. Of course executives and managers should also be exposed to these ideas as they are (fortunately or unfortunately) ultimately responsible for maintaining or at least spawning the systems where the workers create value. These are the people that will receive the most benefit of these essays as I share them with the teams I serve and advise others in the community and our industry.

Agile Austin - Here we Come!

I plan on ordering five copies of this immediately and sharing with the Agile Austin community. We will likely conduct a book discussion group on this book in the July time frame and will report back with comments and observations.

A few shout outs.


Thank you Tobias for this important compendium of essays that continue to be sorely needed across our industry to maximize joy and potential of our people, organizations, and technology users.

Also, a big shout out to Bernardo Salinas for catching me in the airport in Austin and recommending (insisting?) that I read this book!

@MulticastMatt

Making Agile Austin's Membership Participation Based

Hello all:

I'm proud to putting forward a change to the way we define members of Agile Austin.  This is an effort that came from the community and had many many thoughtful minds come up with the best path forward for our community.  I also believe that this may be used as a model for other communities, ensuring that goals are properly aligned when the communities scale.

Thanks to the folks that made this happen--I'm excited to see what comes of the vote next month!

All the best,

Matt

<<

Howdy Fellow Members of Agile Austin:

The least you need to read:

In two days, in addition to the vote on the Agile Austin Board of Directors, we’ll also be putting forth the vote on how we define our membership.  We would like to change Agile Austin membership from being fee-based to being participation-based as It is more meaningful to have people who participate in our programs define the formal leadership of our organization rather than those that can spend thirty dollars. The board and I would like to wholeheartedly endorse this change to our membership definition and ask that each of you vote in favor of it as well. 

We need 50% of all MEMBERS to vote for this change.  We will not make the leap to the next level as a fully participatory community-aligned organization without YOUR help.  Feel free to join at http://www.agileaustin.org/join/ by May 31st in order to help us make this change.  As a Board we cannot do this alone.

Where did this come from?

Over the past 18 months, we have decentralized the control of Agile Austin from a small board of directors to a group of leaders and individuals within the community working in concert with the board.  Listening to existing and former members, I engaged in a series of discussions to change Agile Austin for the better (“DeltaAgileAustin”), including the concept in a change of membership definition.  I’m not sure exactly where the idea came from, but it was definitely a joint jam among community members, board members, and anyone else whose ear we could tug on the subject.  A number of us continued to meet and refine the idea, and we spent a good amount of time in board meetings where we discussed the same.  The result is the language/vote that you see today.

Why?  What’s wrong with how we do it now?

At the dawn of Agile Austin, we had little in the way of resources to achieve our mission (http://www.agileaustin.org/agile-austin-charter/).  The framers thought rightly that if we charged a bit of money, we could cover food, supplies, and never be strapped for cash.  Since then, we’ve grown up and have a rich ecosystem of partners and sponsors.  No longer are we dependent on our membership for dues to fund our activities.  As a board, we have dispensed with every single benefit of paid membership, with the exception of voting for the board of directors.  We believe that it’s more meaningful to have people who participate in our programs define the formal leadership of our organization rather than those that can spend thirty dollars.  Frankly, it seems a bit distasteful to pay to vote as it can encourage unethical behavior.

We thought about giving the vote to anyone in the community, since that’s who we serve, but thought it made more sense to give a vote to one who meaningfully participated in our programs.  With about 20 programs per month, this gives everyone approximately 240 opportunities a year to participate.  We agreed that six meetings constituted “meaningful participation.” 

I also believe that this represents an innovative model in how a large and powerful user community can effectively be run, and may be used by other organizations.  Coupled with the other changes we have made, we have largely open-sourced the management of the community, which has been directly responsible for the growth and impact Agile Austin has on the software development community in Austin.

You convinced me—how do I make this happen?

You must be a member to vote for this—indeed we need 50% of our membership as of May 31, 2013 to vote favorably to make this change.  You can join here: http://www.agileaustin.org/join/ (yes I get joining and voting for this will negate (eventually) the method of joining—just the way it works).  The vote will come out with the election vote in early June.

OK, we have sponsors now, what if that changes in the future?  What if people want to sponsor Agile Austin monetarily?

No problem—we can change the definition of membership in the future like we’re doing now.  There’s nothing preventing us from having a “personal sponsorship” either—we just don’t want the money to be associated with the vote.

But I’d like to make a change to the wording!

We have had meetings on this for about a year and we have had the language available for review for a while.  If it does not pass this time, we can consider it for the future. 

The full text of the vote and the details:

The Agile Austin board proposes that the definition of an Agile Austin member change from fee-based ($30/year) to participation based (attending at least 6 meetings in the last 12 months).  Note that at least 50% of members must vote for this proposal in order for it to be adopted.  If adopted, this proposal will take effect on September 1, 2013.

Specifically:

•  "Membership in the Corporation shall become effective upon receipt of a properly completed application form, receipt of specific dues and approval of the application by the Secretary of the Corporation in accordance with the Bylaws and criteria developed by the Board of Directors of the Corporation." from Section 2.1 will be changed to: "Membership in the Corporation shall become effective upon confirmation of attendance of the minimum number of meetings specified by criteria developed by the Board of Directors of the Corporation.".
• "Membership shall terminate upon the occurrence of any of the following: (i) nonpayment of dues by a member within 30 days of due date..." of section 2.2 will be changed to "Membership shall terminate upon the occurrence of any of the following: (i) failing to attend at least the  minimum number of meetings specified by criteria developed by the Board of Directors of the Corporation...".
• Section 2.3: "Dues. Annual dues shall be established by the Board. No portion of the due paid by any member shall be refundable because their membership is terminated for any reason. Annual dues for new members are due at the time of application. Annual dues shall cover one calendar year of membership and are due for renewal in the month of initial application. The Board shall have the authority, upon application by a member, to waive or reduce the annual dues on a case-by-case basis, for that member." shall be removed.

Tracking of participation will be determined by the board and adjusted based on community feedback (i.e., we will inspect and adapt in an agile fashion).  Our initial plan is as follows:

•  People in the community will register interest in becoming a member by giving their name and email address to an Agile Austin program lead at any Agile Austin meeting (this could be as simple as giving a lead your business card).
•  On registration, potential members will receive an email from the Agile Austin Board with details on becoming a member.
•  As currently, meeting participants will register for meetings via Eventbrite.
•  At the meeting, Agile Austin program leads will check in people who are interested in membership via the Eventbrite app (or other means).
•  Once a potential member has attended 6 meetings within a 12 month period, they will receive an email confirming their membership and their right to vote in elections and other matters.
•  If a member gets to the point that they have not attended 6 meetings within the last 12 months, they will receive an email that their membership has expired.
•  For Agile Austin's current paid members, membership will remain effect until it expires (12 months from when membership started / it was last renewed).
•  No new memberships / renewals will be granted based on payment of membership fees.
•  If less than 12 months of data is available, membership will be determined by attendance in the time period from the adoption of this proposal to date. In other words, if a membership vote was done on September 1, 2013, those who paid for membership on or after September 1, 2012 and those who have attended 6 meetings since the adoption of this proposal would be able to vote.

I still have questions--can we talk before I vote?

Sure--feel free to send a message to board@agileaustin.org or send a note to the Agile Austin Yahoo notification group to engage in public discourse.

All the best,

Matt Roberts
President, Agile Austin
president@agileaustin.org

>>

[Delta Agile Austin]One Year Later - The Impact of the Change

Hi all:

It’s been about a year since we last met to discuss changes that the community would like to see in the way that Agile Austin is run, the programs that we host, and the mission and purpose of this now-gigantic and much more decentralized user group.

Some of the key changes that have come about from these efforts in the past have included:

• Opening of every single Agile Austin program to all members of the Austin community.
• Opening of the board meetings to all members of the Austin community.
• Publication of the notes from board meetings to all members of the Austin community.
• Advance insight and ability to put items onto the board meeting agenda for all members of the Austin community.
• Reconsideration of membership—we will put forth a proposal in the next election to change Agile Austin membership to be not fee-based ($30/year) but participation-based.
• Deprecating the practice of having any fees associated with any Agile Austin program including the book discussion group—any exceptions now need a board meeting vote.  In the past year, we had one exception, which was the Keep Austin Agile Conference.

While we did not implement every change that was suggested, I represented all ideas in front of the board.  Now that our board meetings are open, it may be fine to deprecate this program, but I wanted to see if there was any interest.

These discussions were the engines that drove increased quality, expanded breadth and depth, and more inclusive nature of our programs.  I really enjoyed them as they were intense, sometimes heated, but always made me think different(ly).  Perhaps that's the biggest and most persistent delta (i.e. "change")--the change of mind that will continue to push us to work together and continue to focus on the community as we build this amazing organization by and for our friends and colleagues.

If anyone is interested in continuing the discussion, please let me know and I’ll set up an open meeting.

All the best,

Matt Roberts
president@agileaustin.org

@multicastmatt

Why Did We Stop Doing Annual Performance Reviews When Adopting Agile?

I delivered this presentation at the Agile Austin (www.agileaustin.org) Leaders' SIG on June 1, 2012.  This covers, at a high level, the reasons why we decided to deprecate the annual performance review when we switched to an agile philosophy/mindset for delivering valuable and usable customer software.  The system we put in place was primarily designed to encourage/codify alignment of the work of all team members with the highest business priorities, while remaining flexible enough to deal with important change.

A "side" benefit was that the amount of waste avoided in the effort that allowed the team to stay razor focused on innovative product development.  I talked with a few other companies in Austin that were considering doing something similar.  One of them had calculated that they spent a fully month of their organization's capacity (i.e. November) doing annual performance appraisals.  Once they stopped doing them, they received over 8% productivity back immediately!

Note that I am a strong proponent of putting in performance plans in place when it makes sense from an improvement basis.  There are good reasons for doing so legally, in order to protect all parties (including the individual contributor).

Like all things it was a bit of a compromise as I was still against the compensation payouts, but our agile culture was a constant reminder to not implement incentives that would take away from teamwork and collaboration.  Once we came into CA Technologies, this system was deprecated for a more traditional annual performance review system (I'll blog about that later), but the team was still laser focused on the top business priorities, without the need for any other extrinsic motivation mechanism.

I would be interested in hearing others' learnings in this area, as I see traditional annual performance reviews as key impediments to adopting an agile culture and enjoying the full impacts of its benefits.

Here's the slideshare link:
http://www.slideshare.net/MattRoberts6/agile-performance-management

Another source of wisdom is Dr. Deming, the quality prophet who taught Japan to dominate the U.S. auto industry.  In this video, he talks about the Five Deadly Diseases of Modern Management.  Number three is: Annual Rating of Performance at 4:58.  It's only a few minutes long but has a very large impact.

-@multicastmatt

Can Rules Create Engagement?

Here's a quick story about one of our practices to encourage engagement through structured self-organization for our agile software development teams.

- @MulticastMatt

Why Structure Is Important in a Self-Organizing Agile Environment

Like many aspects of agile software development, there are different interpretations of some of the practices that are espoused, especially by novices.  In particular, we tend to encourage team members to volunteer for work versus being "signed up" for it by, in days of yore, a manager.  Some times this is taken to an extreme, and team members may not sign up for any work, or sign up for work that is currently not a high priority.  This can be problematic as it leaves holes in work that must be done.  Therefore, some level of structure is required to get the highest priority (and hopefully valuable) work to be done.  This includes the necessary collaborative meetings that, with appropriate engagement, can be phenomenally productive.

An Example:  The Rules of "Engagement"

Last year, I came up with a simple list of rules for our larger team meetings to encourage participants to focus on the goal and to eliminate wasted time (muda).  This was in response to complaints from the team that larger meetings (backlog prioritization, release planning, sprint planning, etc.) were "painful" due to the propensity to get off track and only be interesting to a few participants at a time.  Key symptoms included heads bobbing behind laptops, bent heads staring down at what we hoped were the individuals' smart phones, and the standard response of "huh?" when an opinion was solicited of a team member in either of the two former states. The rules were designed to create a system where the team could feel comfortable holding themselves, each other, and their manager accountable to achieve the stated goal and maximize the value obtained by all participants.  I refer to these as the "Rules of Engagement," pictured below.

Rules of "Engagement" Poster Used in our Larger Planning Meetings

The ultimate rule, dubbed "The Rule of Two Feet", was repurposed from the Open Space Law of Two Feet, which states: "If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else."  This would be the ultimate solution to disengagement, but I thought it made sense to have the departing team member discuss why they were leaving with the rest of the team.  In this system, team members are empowered with the flexibility to leave if they feel the content is off-topic, does not apply to them, or any other reason.  However, it encourages potential continuous improvement (kaizen) moments, including the discontinuation of practices that no longer serve the team.

Team Response to the Rules of "Engagement"

These rules have been put to the test on a few occasions and resulted in the deprecation of a release planning ritual that seemed to work and had been a standard for the team.  One team member was fairly frustrated with this process and stood up to leave but gave his feedback first.  We then went on to have an open dialog in front of the rest of the team.  This led to a much richer discussion about what we were trying to accomplish and the best way to do it, which continued beyond the original meeting.  While the goal had not changed, we learned a more effective way to get there by discontinuing the process, thereby eliminating wasted time.  I feel that if the initial team member had just walked out, we would have missed that critical kaizen moment.  

This is certainly a success story, but it worked within a larger framework of trust that we had developed over close to three years of working together.  As with most practices, your mileage may vary.

Our Standard Rules of "Engagement"

We at CA Technologies host a bevy of Agile Austin meetings, and the poster above tends to be an item of interest.  In fact, many visitors have taken pictures of it and brought it back to their teams.  This is great, but it's important that everyone understand the context in which it was developed.  It is critical that the team buy into this for specific reasons, understanding the why.  Like other standards, rules, process, etc., the team needs to be free to change them as they see fit when there are new kaizen moments.  

Here's a transcription in case my writing is hard to decipher:

• Cell phones down / away (unless taking pictures of story point estimation)
• Laptops closed unless
• You're taking notes for the team
• You're presenting
• You're remote
• You desire employment elsewhere :)
• Break for 10 minutes every 80 minutes
• If you're late, you missed it
• Time boxes will be maintained by the MC
• Raise your hand if you think the discussion is off-track or the Rules of "Engagement" are being violated
• Consider remote team members
• One conversation at a time
• Consider the goal of the meeting
• "Rule of 2 feet" is justified, but should be discussed

An Aside - Freedom and Organization

Many organizations have unpaid volunteers (local political campaigns, open source software projects, Agile Austin, etc.) but that does not imply that everyone is free to do whatever they would like.  There is a mission or a purpose that drives the most effective organization.  As the definition of "organization" is: "The structure or arrangement of related or connected items,"  organization implies structure.  Generally, people come in as novices, learn the system and then are entrusted with some span of control beyond themselves once they have attained some level of mastery.  It's naive to believe that volunteering is equivalent to the ability to do whatever one desires in any type of complex organization.  I see the same thing in organizations trying to create software.  

Allowing for self-organization and self-management is essential for software development teams where agility is critical.  Indeed, it creates an environment where team members are fully engaged in creating usable and valuable software.  However, self-direction may lead away from the goal of the organization.  Striking that balance is something that no "best-practice" can ever dictate--indeed it requires experience and a deep understanding of many dynamics.  For those in entrusted with managerial or technical leadership positions, this can be an area of extreme benefit or dismay and thus should be a focused area of learning.

GUEST BLOG: How Agile is Like a Guitar and Tech Info Fits Into Agile Software Development

A colleague and friend of mine, Janice Hamrick is an outstanding Technical Information Engineer (aka Tech Writer) and a totally entertaining mystery writer.  She attended last year's Keep Agile Austin Conference and wrote up a great piece on it.  I'm honored to have her as my first guest blog!  @MulticastMatt

When I told a friend I was attending an Agile Austin conference, she asked me if it was a new exercise program. Naturally, I said it was. Who am I to argue with someone who is willing to believe that I’m exercising? But for those of you who know better, the Agile Austin 2012 Conference was a day-long symposium centered on Agile software development.

Three years ago, I joined Hyperformix as the technical writer for two development teams. A week later, Matt Roberts (soon to be president of Agile Austin) joined as manager and led the teams through a transition from an unsatisfactory blend of waterfall and pseudo-Agile to an extraordinarily successful Agile development organization. Hyperformix was acquired by CA Technologies a year later, and CA is going through its own transition to Agile. As I watch the beginning of this much larger scale Agile transformation, I’m also watching Technical Information trying to find its rightful place in the mix. Technical writers often find themselves left out of the Agile process (particularly when they are not fully integrated into their development teams).

At Agile Austin 2012, the keynote speech by David Hussman set the tone for the day. He said, “Agile is as interesting to agility as a guitar is to music. Both are tools.” He then added, “If you strum a saxophone, it’s not the saxophone’s fault.”

Knowing how to play the Agile instrument is a matter of experimentation, education, and adaptation. It can be a bumpy process, but the most important thing is remembering that the people on your team – including the writers – are like members of a band. Everyone needs to be invited to the rehearsals, and everyone needs to play the same song and keep the same beat.  Holding planning meetings and estimating stories and tasks without including writers is like holding a secret band practice without the guitarist.

As with most conferences, I found the discussions that took place between sessions at Agile Austin 2012 to be as informative and interesting as the sessions themselves. I spoke with one writer who said he didn’t really see the value in retrospectives (the meeting after each sprint in which an Agile team discusses what worked, what didn’t work, and how to improve things).  I was surprised because these meetings not only improve processes but they help build trust among team members. But he then mentioned that his team’s version of a retrospective was an electronic survey sent out at the end of each sprint.  That team is strumming a saxophone, and then wondering why it doesn’t sound like a guitar.  I’ve also spoken with writers who can’t participate in standups because they can’t hear properly over the phone or who are assigned documentation tasks that they can’t possibly complete long after the sprint planning (to which they weren’t invited) had taken place. It’s no wonder that many writers feel frustrated by what they believe is “Agile” when in fact it’s not really Agile at all.

One of the many benefits of living in a town with an organization like Agile Austin is having such a terrific resource to assist you when Agile isn’t working for your or when you think that there must be a better way. Chances are, someone else out there has been in your position and has a suggestion or two that could help make your team and your life easier, better, and more agile.  If Agile isn’t working for you as a writer, then it’s not working for your development teams either (whether they know it or not). It might be time for some guitar lessons.

 About the Guest Blogger

Janice Hamrick joined CA Technologies in 2010 as the Senior Technical Information Engineer for the Capacity Management suite of products (formerly Hyperformix).  Before joining Hyperformix, she spent years writing documentation for backup and recovery products for a rival company whose three initials shall remain unnamed. It is a myth that she has worked as a technical writer in the software industry since dinosaurs roamed the earth, but she does remember when “agile” was something you had to be to avoid the saber-toothed tigers.

Outside of work, Janice is the author of the award-winning Jocelyn Shore mystery series (DEATH ON TOUR and DEATH MAKES THE CUT, Minotaur Books).  She has completed the third novel in the series which will be published in 2013 and is currently working on a new and much darker mystery series.  Learn more at www.janicehamrick.com. 

Problems Maintaining Product Development Innovation in an Agile/Lean World

Hi all:


I'll be presenting the following discussion at the Agile Austin Leaders SIG on Friday, March 1st, 2013 at CA Technologies in Austin, TX.  I'm really looking forward to feedback!

@multicastmatt

Sign up:

http://www.eventbrite.com/event/5381488176 

Abstract:

One of the benefits that many product development teams are able to realize when they switch to an iterative or limited WIP process for developing software is (finally!) a ranking of work items on which the team can focus.  Over time, this allows a good deal predictability for the stakeholders of the project, especially when work items have corresponding “done” criteria that are adhered to.  Some organizations are so enamored with the results of this shift that they begin to assemble all members of team into these types of structures, including team members that were previously dedicated to research or advanced product development efforts.  While this is not necessarily a bad decision for these organizations, some face issues with maintaining a level of innovation in the product efforts as there may be a perception that there is neither time nor the people to work on important innovation efforts.  Further, some of these team members may be doing work that is neither challenging to them as individuals nor is bringing the appropriate value to the company.

In this discussion, Matt will help shine a light on this issue that can be especially challenging for a product development company that seeks to maximize the velocity of a product team working against the near-term roadmap but may lose sight of competitive challenges that may change the very nature of the playing field.  He will describe the challenges faced by teams he has worked with both in the past and currently and share what he has learned.  A healthy discussion is expected to follow!

Bio:

Matt Roberts is an agile pragmatist continuing his lifelong learning journey, currently serving multiple teams as Senior Director of Software Engineering and Agile Coach at CA Technologies. His experience is wide-ranging as he has developed software and led efforts to create systems for product development teams to deliver innovative solutions in companies ranging from early-stage startup to publicly-traded companies in both consulting and full-time roles. He has had the privilege of serving the Austin software development community as Agile Austin President over the past two and half years and as Secretary for the IEEE Computer Society over the past eighteen months.
Matt holds certifications as a Certified Scrum Practitioner (CSP), Certified Scrum Master (CSM), and Certified Scrum Product Owner (CSPO).  If you’d like to learn more about him, please visit http://linkedin.com/in/cpgmattr or see his latest thoughts at multicastmatt.blogspot.com.

Introduction to David Hussman (The Dude) at the Agile Austin 2012 Conference

With apologies to the Cohen brothers, my modifications in italics.  

Way up North there was this fella I wanna tell ya about. Goes by the name of David Hussman. At least that was the handle his loving parents gave him, but he never had much use for it himself. See, this Hussman, he called himself "The Dude". Now, "Dude" - there's a name no man would self-apply where I come from. But then there was a lot about the Dude that didn't make a whole lot of sense to some. And a lot about where he keynoted, likewise. But then again, maybe that's why I found the place so darned interestin'.

See, they call Austin the "Capitol of Live Music"; but I didn't find it to be that, exactly. But I'll allow it as there are some nice clubs there. 'Course I ain't never been to London, and I ain't never seen France. And I ain't never seen no queen in her damned undies, so the feller says. But I'll tell you what - after seeing Austin, and this here Agile Austin 2012 Conference about to unfold, well, I guess I seen somethin' every bit as stupefyin' as you'd seen in any of them other places. And in English, too. So I can die with a smile on my face, without feelin' like the good Lord gypped me.

Now this here Agile Austin Conference about to unfold took place in the early '10s - just about the time that agile adoption hit its stride, but people were starting to miss the point. I only mention it because sometimes there's a man... I won't say a hero, 'cause, what's a hero? Sometimes, there's a man. And I'm talkin' about the Dude here - the Dude from Minneapolis. Sometimes, there's a man, well, he's the man for his time and place. He fits right in there. And that's the Dude. The Dude, from Minneapolis. And even if he's an agile man - and the Dude was most certainly that. Quite possibly the agilist in all of Minneapolis, which would place him high in the runnin' for agilst worldwide. Sometimes there's a man, sometimes, there's a man. Well, I lost my train of thought here. But... aw, hell. I've done introduced it enough.  

[DeltaAgileAustin]Agile Austin Membership Definition Vote June Feedback and Upcoming Vote!

As discussed, June was the month that we would discuss, as a community, the proposed change in Agile Austin membership from paying annual dues to meeting attendance, as a number of us believe that the latter signifies a greater dedication to the organization for the purposes of voting.

The least you need to know

The board of Agile Austin will be voting this evening on putting a vote to the members asking them to amend the charter so that membership definition will change from an annual subscription for a $30 fee to attendance at six Agile Austin meetings in a twelve-month timeframe.

If you’re interested in being part of the discussion at the Open Board Meeting, please join us this evening at 6:30 PM (let me know soon so we can order you some tacos):

http://www.eventbrite.com/event/3638569058

Detail

I held two meetings this month on this subject.  These meetings were  in addition to the previous DeltaAgileAustin meetings that occurred earlier this year, as well as ongoing open Agile Austin board meetings, where this subject has been discussed in length.  Of these two meetings, there was only one participant besides me.  This participant was our Vice President, Walter Bodwell.  We came up with the following proposal, which we should feel free to discuss in this forum.  Any and all comments are welcome, especially in this discuss thread.

Point 1:  What is the value of membership—why should someone be a member?

·         Membership creates a benefit to elect the Board of Directors of Agile Austin, which is a 501I6 non-profit organization. 

·         Board meetings are currently only open to Agile Austin members (however, we would like to change this to be open to any participant and will vote on this at the next board meeting)

·         Historically, there have been training discounts only available to Agile Austin members.  However, this too could be discontinued as the vendors normally don’t care and would like to extend them to the entire community.  We will vote on this as well at the next board meeting as we cannot recall a specific member’s only discount being issued any time in the past twelve months.

·         Historically an annual membership came with a premium such as a coffee mug or T-Shirt.  We saw no reason to discontinue this with a change in membership definition. 

Point 2:  What would be the minimum number of meetings to attend in order to gain membership?

·         Reflecting what was discussed in previous DeltaAgileAustin meetings as well as what seemed to make sense, both Walter and I agreed that the number should be six.  This equates to one meeting every other month.  A meeting would be defined as any officially-sponsored Agile Austin meeting including, but not limited to monthly meetings, special interest groups (SIGs), workshops, dojo, community series, etc.  In the month of June, there were over 15 meetings, which is normal.  Attending six meetings in one year would equate to approximately going to 3% of the total meetings in a year.

Point 3:  What would be the language of the vote?  Do we want to make it specific, or allow the board to have broad scope in modifying the membership definition?

·         There are certain benefits to make the language of membership definition broad.  If we made it specific to a certain number per year, any modification would have to go back to the membership to make a change.  However, this is one of the most critical aspects of membership, so it may be better to leave it specific and require a vote each time it’s changed.

·         Ultimately, Walter and I agreed that we would make the vote specific as opposed to giving the board broad powers of definition.  Of course, we can always revisit this if it doesn’t work.

Point 4:  How will we count the number of times someone attends a meeting?

·         The main thing that we need to focus on is ease-of-use in this area for both the participants and the program leads.  We strongly desire to eliminate paperwork and challenging processes.

·         In order to count, the board will develop a “Roll Call” application that can be used quickly via cell phone to register for events.  There will always be a manual backup in case the Roll Call application is not available. 

·         Earlier this year, the Board voted to move the annual Board vote to June, so we’d need to calculate this on May 31, 2013 to send out the ballots.  We would also conduct a trial run on May 1st letting people know how many events they’ve attended and how many more they’ll need as of May 31st.

Point 5:  When do we stop charging/Current members?

·         All membership is valid for the period until such time as it expires.

·         Once we have the new membership process in place (member vote to change the charter and the Roll Call implemented), the paid membership will be discontinued.

Point 6:  What are the dependencies of this change?

·         We need to have Roll Call working before we call a vote of the membership so we can immediately implement it.  We will begin beta testing this in July at a variety of the SIGs.

Point 7:  How will people know whether they are a member or not?

·         They can ask—sending a message to info@agileaustin.org

·         We would like to have an automated way for them to check

·         We would like to have an automated system send email when the member has reached membership status or is about to go off membership.  We might just do this as a simple rails app backed by a database so we could always have the information quickly and easily available for everyone.

·         We may be able to print special badges denoting members

Again, please let us know if you have any questions or comments.  I’ll also be available to discuss this after our next monthly meeting on July 10^th.

AgileAustin Conference Pitfall! Theme

About a month ago, the AgileAustin Conference Team was discussing various ideas on themes for the conference.  Janelle Klein originally had some ideas around problems with trying to adopt "A"gile (as opposed to agile--more on that later).  Paraphrasing her idea, it would be framed as a conference on Agile Problems.  I thought that was a brilliant idea as we've seen so many challenges on so many levels over time.  However, the consensus from the conference team was that it may not be inclusive enough or have more of a negative focus.

So, I had a problem that needed fixing, and harkening back to the 1980's where the A-Team could solve anything, I decided to call upon that golden era with a single word that evokes memories of massive problems overcome and treasure gained, all under 2KB of RAM--"Pitfall!"

Here was my concept drawing that I doodled during the meeting:



I threw it up on the whiteboard to see what everyone thought.  A lot of folks in the room identified with it and really liked it.  We delved into the various aspects of what it meant, and we started tweaking the concept.  I originally wrote "For Use by Intermediate and Experienced Teams" but was swayed by folks who thought we could be more inclusive, so I wrote "For Use in Learning Agile Organizations." I realize I was trying to focus our conference on the "swingers" to focus our efforts in the conference.  However, when I heard how many were planning to attend that were very new to agile concepts, I changed my mind.  There will ALWAYS be pitfalls for new teams running into that brick wall or teams that had been swinging through the jungle for a while.

The theming is excellent--gold bars (e.g. technical debt reduction, cost-of-delay value measurement, exploiting variability for profit), brick walls ("doing" vs. "being" agile, queues, siloed knowledge, lack of transparency), logs (technical debt, not focusing on engineering principles, work-in-process, beauracratic processes), aligators, scorpions, pits...It's a rich area for metaphor to say the least.

We ended with a decision that this might not be appropriate for a main conference theme, but it could certainly work for one of the four conference tracks.  I'm happy with that, especially given my recent thoughts on the "Mix Tape" Open Space.

I'd love to hear what everyone else thinks here!

Oh, and here's a simulation of how I spent a great deal of time in the mid-1980s. 
http://www.youtube.com/watch?v=MhXMYw1lXY0




@MulticastMatt

AgileAustin Conference 2012 - "Mix Tape" - Does anyone have Open Space experience?

There are some really exciting things happening with the conference planning and things are proceeding nicely.  I noticed however that the team had initially been struggling with some of the following challenges:

-          Should it be paid vs. free?

-          Should it be on a Friday or Saturday?

-          Should it be content tracks or Open Space / Unconference?

-          What should our theme or themes be?

It dawned on me that AND is often more helpful than OR, so I came up with a proposal (enclosed) for a Saturday Open Space that would be free for all conference participants.  It would also be free for anyone else who wanted to attend that was not a paid conference attendee J

The theme is “mix tape” (80’s lingo—it could be “mashup” 00’s lingo) where the goal would be to have every session be a mix of at least two (more = better) disciplines getting together to achieve agility.  These can be cross-functional, cross-organizational, etc.  The classic example is something like DevOps, but what about UX and QA, executives and individual contributors, technical writers and salesfolk, chip designers and product marketing folks?  It could also be a conference track in and of itself and the open space could riff off of that.  Think about it—one day of presentations/workshops, and the next day of engaged discussions. To me, this is a really exciting idea.

In my typical style, I have signed up to run this if no one else does.  However, seeing as I’ve never run an open space conference before it would be really nice if there was someone in the community who had the experience and wanted to partner with me in this effort. 

Please let me know if this strikes your fancy and you have some relevant experience in doing this type of thing.  As usual, we’ll have all the logistical support (room, food, sponsor, etc.) from AgileAustin.

Thanks everyone!

@MulticastMatt