Sequential and Collaborative Planning - "Oppa Sashimi Style"

Hi all:

My friend and sometimes colleague John Heintz asked me to play the straight man in his first experiment in professional video blogging.  John is a powerful advisor to many agile and lean software engineering teams, managers, and executives around the world and he described the collaborative planning concept as something that he's "drawn on a whiteboard over a hundred times."

Photo courtesy of rofi/flickr

His idea certainly resonates with me as I have discussed the concept of "sashimi" for software teams where the phases of development on a particular user story are focused less on strict hand-offs between separate teams and more on overlapping phases of development to collaboratively get work to done in priority order. The hand-offs and silos implicit in the waterfall model caused many problems, especially in getting work to done with high quality.  In many teams following Scrum, they have still maintained this model, although in shorter, iterative cycles, creating a "Scrumfall" environment.  I've asked Scrum teams that I've advised to consider a model where they attempt to reduce work-in-process by having a number of cross-functional team members "swarm" on each user story in priority order, focusing on architecture, design, development, testing, and documentation with overlapping phases.  This allows ample opportunity for real-time feedback to affect each of the now "fuzzy phases", cross-team education, and insight into the earlier phases by team members that may be able to build quality in, versus test (or worse, document) it out.

Protip:  when you're planning work around a user story, don't try to model dependencies, just assign a number of story points or hours in a bucket, and let the work flow naturally, allowing the work to be the focus as opposed to the plan or the team member allocation.  Monitor the work on a daily basis.

Protip:  if you're 40% through your sprint (e.g. the fourth day of a ten day sprint), and all or most stories are in progress and nothing is done yet, you're likely in "Scrumfall" and you are likely performing sequential versus collaborative planning.

Without further ado, here's our first experiment together in video blogging around the benefits of a collaborative planning model:

http://www.youtube.com/watch?v=2aho4WbJprg

Here's his full blog post:  http://gistlabs.com/2013/09/video-sequential-and-collaborative-planning/

Does this concept resonate with you?  What has been your experience?

@MulticastMatt

Continuous Development Team Product Innovation in an Agile/Lean World

Hi all:

I presented one of my favorite topics at last weekend's Product Camp Austin 11 here in Austin, TX.  While the crowd turnout was fairly small, it was still a great session packed with tons of interactivity.  I have presented this content to the Agile Austin community a number of times, so I've been able to synthesize all the feedback from a variety of groups (Development, Product Management, Project Management) into the following slide deck.  The best way to convey the information is face-to-face, so I'd be happy to share my insights, challenges, and what we've learned if you have the time and inclination.

I also found this great article by Jeff Atwood titled "Today is Goof Off at Work Day" about the broader topic of open time for developers to innovate.

Enjoy!

~@MulticastMatt

A tribute to a great team bulit over 5 years

October 16, 2014

I debated removing this page when I left CA Technologies in April, but thought that I would leave it as a tribute to an incredibly special team that we created together.  Unfortunately, as the saying approximately goes, "every positive cultural change is one manager change away from failure," and the overall direction was no longer compatible with my personal values and it was time to leave.  Perhaps one day I'll write about that experience.  However, I'm really excited about the new team we're building at Socialware, which I've been long-overdue to write about!  -m@

July 19, 2013

Welcome!

You've probably arrived on this page as someone forwarded you over a position for our team at CA Technologies here in Austin.  Yes, we're hiring in a relatively big way, but we do things a little different here.  I thought it would be good that you know a little bit about us before you consider joining.

Keeping CA Technologies Weird

It's important to know our heritage: our team is composed of the former NetQoS and Hyperformix development teams.  We are part of CA Technologies, and we don't pine for the "good old days", but we are "keeping CA Technologies weird" in the following ways:

Party Bus w/Karaoke for Offsite Toobing Day

• We are entrepreneurial and motivated by delivering direct value to our customers by eliminating waste (as identified by the team members) and eschew process that doesn't make sense.
• We are a 95%+ co-located team.
• We have fun, but not in a pinball machine/video game kinda way.  Don't get me wrong, we have that stuff, but the most fun (for us) is solving really challenging problems with a reach nearly unparalleled by other companies in the local market. Winning is also really fun.
• People should be and are unique.  We don't have a dress code, and people have flexible work styles. We do emphasize being in the same place at the same time for a good amount of the day, but understand why that's important.
• We have a sense of humor and treat people as responsible adults.  Experience has shown that the benefits of this far outweigh the risks in this approach.
• We ask A LOT of questions around why things should be done, especially when someone else is telling us to do them.  We've kinda got a reputation....but that reputation is superseded by our ability to deliver valuable software to our customers and make money.  Funny how that works out.
• We all figure that a culture of fear has pretty much been played out by now.  Individual and team empowerment is engaging--we like that.
• Our management team "walks the talk" of acting as servant-leaders.  We are here to help things "go righter"

Service Day at KIPP Austin

Why you might want to work on this team

In addition to being OK with the above, you:

• Love solving very tough problems and truly love to learn.
• Focus on quick delivery to get rapid feedback into what our products should be for our customers
• Are inspired by how technologies can affect people's lives for the better
• Can deal with constant experiments in how our work is done 
• Work really well with others in tight teams yet still have independent minds
• Are OK with doing any job on the team, but realize that it makes sense to focus on your strengths
• Have a passion for building products that deliver real value to customers
• Are open to the possibility that all this "agile stuff" just might not be management bullshit.  You've looked at the Agile Manifesto and the Principles, and that sounds really good to you.  You have hopes that someone, somewhere really pays attention to this stuff.
• Want a real work/life balance.  This is again, not bullshit.  I have not asked the teams that I serve to work a night or a weekend for four years running.  We practice sustainable pace (and fully know why we do).
• Want to develop your "career capital"--we carve out one week a year for everyone to train and build it into our schedules.  Yes, there's budget too.  No, it doesn't get cancelled, but you'll need to have some level of independent motivation.
• Want a certain paycheck and sweet benefits.  CA Technologies is a big company, we enjoy more than five weeks of vacation a year.  Yes, you heard that right, and that's before holidays.

I know the above sounds a bit too hard to believe, but you can ask any team member.

At a recent "Science Faire" where the team takes two days
every four weeks to work on their innovative projects.

Why you might not want to work on the team

There's nothing wrong with these things at all, but please don't apply if the following resonate with you, as you won't be a good cultural fit for the team:

• You just want to do your "own" work, and it doesn't make any difference where or when you do it
• You want someone to clearly tell you what to do and how to do it
• You are a <fill in the blank> technologist (e.g. Java, C++, C#, RoR, Scala, Fortran, LOGO, Perl, etc.)  and really aren't interested in anything else
• You believe that agile, at it's core, just another management fad, as is Lean and all the others.  Just let me code and don't worry about process.
• Automation is of no interest to you
• You are upset with the world for some reason, and believe work is a great place to express it
• You have to be the smartest person in the room

Seeing our software running on mobile for the first time!

~ @MulticastMatt

Can Sustaining Engineering Be Agile and Engaging for Team Members?

Hi all:

I recently talked with a manager whose team's role is changing from main line product development to Sustaining Engineering (also known as Maintenance). He first wanted to understand how to adapt the agile process for his team, but as we talked, it became apparent that the bigger issue was keeping his team happy and engaged, as they were a bit nervous about what the change meant for them and their careers.

I was interested in exploring this area with him, and thought it would be worthwhile to discuss the concerns he had for his team.  I must be transparent and state that I have never served as a manager for a dedicated sustaining engineering team, so many of my thoughts in this area come without direct experience.  Perhaps it would be best to explain why this is the case.

Why Have I Never Had a Sustaining Team? 

It's not that I've never had the opportunity to have one, I simply rejected the notion and made it part of the responsibilities of the product development team.  I firmly believe that the notion of "sustaining engineering" may be indicative of a failure mode*.  Separating the responsibility for how code runs in production can lead to another "throw it over the wall" type of mentality that we as an industry are just starting to make headway on between development and QA.  More critically, it can totally disconnect crucial feedback to the product development team causing years and years of waste that could otherwise be invested in creating customer value.  

Here are some of the arguments I've heard in support of a Sustaining Team:

• "If we could free our development team from all those damn critical situations that come up in production, we could finally get some valuable features out the door and make some money."
• "We can get cheap resources overseas to handle fixing the defects and focus our expensive resources on the things that customers really want.  It just makes good business sense."
• "Development is constantly interrupted by fixing low-priority nits and we keep missing our release dates or drop planned functionality.  This has to end!"
• "Our releases are too long for customers to wait.  A sustaining engineering team will prevent our generally late releases from being even more so."
• "Are you kidding me?  We can't have our developers actually talking to customers, those guys are a bunch of mutants that can barely communicate with each other!"  (OK, I haven't heard this explicitly, but it's certainly implied.)

Each one of these points constitutes a failure mode that I won't go into here, but may be good fodder for another blog post.  As agile is "the art of the possible," I didn't see this as an opportunity to challenge the notion of the sustaining team, but I thought I'd help with ideas to make the team as effective and engaged as possible.

*Note:  one possibility of a non-failure mode could be a distinction between a team that is primarily interrupt-driven, and one that is focused on long-term goals.  This point was brought up by my colleague and may be useful to folks in some situations.  However, it is critical that the whole is being maximized for the benefit of the customer, company, and the individual software engineers.

Can Sustaining Engineering be Agile?

Sure--why not?  If you look at the Agile Manifesto there's nothing in there that that precludes the values and principals that are universal to software engineering and the humans who are engaged in its practice.  Process improvement frameworks geared towards software engineering such as Scrum and Kanban, and the modern engineering practices that support them (e.g. XP, TDD, etc.) are certainly as valid for sustaining a product where the work tends to focus on fix packs, platform certifications, and minor feature improvement.

Some might argue the semantics of "agile" vs. "lean" and say that Sustaining Engineering isn't agile and should be run through a Kanban process.  I would tend to agree that there can be benefits of running sustaining requests (essentially tickets) through a Kanban system, if for no other reason than the fact that near constant reprioritizations happen when dealing with a mature mission-critical product that is loaded with technical debt.  There tends to be a real need to release extremely quickly to production as well and the changes are smaller than large marquee features/epics associated with new product development.

One of the nicest things about Kanban, however, is it tends to visualize the entire value chain, at least when implemented to obtain the greatest customer value in the smallest amount of time.  Seeking to "maximize the whole" may lead to some very beneficial activities, which get to the manager's concern about having an engaged team.

"Re-Imagining" Sustaining Engineering through Engagement

Back to our conversation with the newly minted Sustaining Engineering Manager...He was nervous that his team may not be as engaged in their new work assignments and they would no longer be writing new valuable features and functionality.  As someone whose success is more than partially defined by the innovative products that the teams he serves delivers, I can definitely understand his concern.  It would be mine if I was in his place as well, and I came up with a few ideas.  It's important to keep in mind the context of these ideas--this is a team of product developers who are changing roles into sustaining engineers.  I'm not sure that they would apply to every Sustaining Engineering team.  My basic premise here would be to put yourself "out of a job" by eliminating sustaining requests through the constant improvement of the codebase.  What should be left is platform certifications (browser compatibility, operating system,  JVM version, .NET version, etc.) that are always changing and can be handled by the same team now that they have the capacity to do new feature development.

Note:  This is not a comprehensive list of "best practices" for Sustaining or Support--there are a ton of those.  These are just a few ideas about how to help a team of software engineers be fully engaged while they are part of a sustaining group.

• Create a target of business-specific technical debt reduction.  Identify common root-case problems in the codebase, often a source of Technical Debt to remediate common-occurrence problems.  In general, never have the same type of defect show up more than twice (fix it "right" the first or at worst the second time).  It is possible to eliminate enough of this debt where having a sustaining team just won't make sense.
• Fix the leak first before mopping the floor.  Reducing technical debt by a sustaining team will be useless if there is a product development team continuously creating it and making it worse with each new release.   A sustaining team can be engaged in evaluating new code that is delivered and acting as an advocate to increase code quality, or at least prevent new code from creating the next wave of customer critical situations.  
• Develop and employ modern engineering practices to analyze the code base and ensure that regressions are not "developed" along with fixes.  Many legacy code bases have weak automated testing, automated unit tests, and coverage mechanisms.  Configuration / builds tend to rely on "magic" of people who are long gone, or at least not accessible.
• Act as an alpha tester of new releases from the product development team.  No one knows better what kind of problems are out in the field and how the best features may flop when put into production more than sustaining teams.  Embed yourselves in sprint reviews (demos) and quite possibly act as the owner of final user story acceptance.  How's that for engagement?
• Funnel innovation - because a sustaining team operates so close to the customer, they are many times the closest ones to know what the customer pain points actually are.  Sustaining members can act as powerful contributors to a product advisory board/committee and have the weight of real customer feedback when they speak.
• Delight customers by being able to predictably deliver fixes.  One powerful technique to do this involves measuring average cycle time for defect fixes though a process such as Kanban.  Scrum iterations can also be used effectively here as well.  Most customers don't need their fixes "right now," but have been burned so many times by missed expectations.  If a schedule can be made transparent to customers and that schedule is constantly made good, customers will start properly assigning severity to issues.
• Rotate with the active product development team.  This gets really close to my initial idea of just having one team that does both new product development and sustaining work.  Think of this as a hybrid model where there is a constant trade of learning between new product developers and developers that couldn't be closer to customers.

Additional Reading

Thanks to John Heintz (@jheintz) for some additional great reading around Sustaining Engineering, some of which may contradict or amplify the ideas I've presented:

• Everything I can find about software maintenance /DZone
• David Anderson's "From Worst to Best in 9 Months", which was used as part of the basis of his work developing Kanban.

What do you think?  Do you agree/disagree with these points?  What's worked for you as a Sustaining Engineer to have mastery, autonomy, and purpose in your work as a team member?

Image via Creative Commons, Jose Franco's (jose_franco_) Flickr photostream. (source)

Guest Blog: Are Doc Sprints Really Agile?

Welcome once again to my friend and colleague, Janice Hamrick, with her latest perspective on helping whole development teams attain agility through effective technical writing.  Unfortunately, technical writers, who are crucial members of the product development team, are often siloed for the sake of "efficiency."  I've been serving my teams for years by insisting that stories are not complete until there is adequate documentation, and it has driven dramatic positive changes from the perspective of people, product, process, and tools.   If you like this post, please check out her other two posts (How Agile is Like a Guitar and Tech Info Fits Into Agile Software Development and 3 Ways to Make Documentation as Agile as Development).
~@MulticastMatt

Some development teams choose to separate documentation from the rest of the development work.  In fact, the Society for Technical Communication (STC) recently held a seminar entitled, “Doc Sprints: The Ultimate in Collaborative Doc Development,” which included the following description:

“Many technical writers find themselves in agile environments, where time is at a premium and it can be difficult to pry the developers and other subject matter experts away from their day-to-day deadlines.”

The problem with this practice is that it violates almost every principle of Agile and causes problems for all members of a team.

What is a “doc sprint” as opposed to a sprint?

A doc sprint is just that – a sprint containing only documentation tasks. Often, the only member of the sprinting team is the writer, with nonexistent or at best nominal support from the rest of the team. Dev and Doc are like milk and cookies - they should always go together.  If you are having separate doc sprints that lag behind development sprints, YOUR TEAM IS NOT AGILE.  Documentation is as important to software development as coding and QA - no story is done unless it’s fully coded, tested, and documented. 

Why should it be difficult to pry developers away from their deadlines?

If your team is truly Agile, EVERY team member is responsible for every user story. This means that developers are as responsible for providing content and reviews as they are for coding.  If a writer is blocked and a doc task can’t be completed, then the story can’t be closed.  This provides the means and the motivation for excellent communication and cooperation among all members of the team, and ensures the documentation gets the attention it needs from all concerned.  If a team conducts separate doc sprints, dev and QA have already moved on to something else by the time the writer starts and will have to switch context to provide information. Moreover, dev and QA very likely have not budgeted time into their own sprints to work with the writer – after all, their stories apparently can close without documentation. This leaves the writer in the uncomfortable position of “prying” developers away from their “real work” or resorting to begging (or threats). Plus, the likelihood of missing information altogether (because it’s no longer current) or of being shortchanged during review cycles increases astronomically. The doc quality suffers, team relationships suffer, and ultimately product quality suffers.

Why are writers different from any other team member?

The short answer is that they shouldn’t be! However, in many organizations, tech writers report to a different business unit than development teams, a situation that can leave writers feeling like outsiders because they are treated like outsiders. I know writers who are left off mailing lists, who aren’t included in team-building training, and who are sometimes the last to know about feature changes.  

For real Agile success, writers must be real team members. It might not be possible or even desirable to change the management hierarchy of your organization, but it is possible for teams to ensure that writers are first-class team members.  The first steps include making sure everyone on the team understands this (management support is essential), eliminating doc sprints, ensuring doc tasks are part of the team user stories, and planning for the time needed to provide content, write, and review the doc. 

Is there ever a good reason to have a doc sprint?

Probably not.  There might be a reason occasionally to have a doc-only user story (for example, if your team decides the product needs a new user guide), but even in that case the team is responsible for content and reviews.  No one team member, whether writer or not, ever works in a vacuum. All stories require commitment by the team, and as such should be incorporated into team sprints.

Your thoughts?

Does your team hold separate doc sprints or are your documentation tasks integrated into the development sprints? How does that work for your team and the quality of your product? 

About the Author

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-winningJocelyn Shore mystery series (DEATH ON TOUR, DEATH MAKES THE CUT, and DEATH RIDES AGAIN, Minotaur Books), and is currently working on a new novel.  She lives in Austin, Texas.

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

Improvisational Running

Hi all:

Some of you may know that running has been a major part of a number of life changes I made on September 11th, 2001.  I usually run with either my running group (AustinFit) or my running partner who happens to be my very good friend and neighbor.  These runs are designed to keep me in shape (or at least try to retard the ongoing damages of age and Friday morning doughnuts) or prepare me for an event such as a 5k, 10k, or half marathon.  The thing that almost all these runs have in common is that they are timeboxed to get on with a normal workday and/or regimented to achieve a personal goal.  Unlike "Whose Line is it Anyway," improvisation is an afterthought, if it's there at all.

Vacation runs are different--while I start out with a specific goal in mind, I almost always become diverted.  Paths that veer off to the side seem more interesting than staying at a steady pace.  The quick reflection behind a copse of trees could lead to running water (maybe even a waterfall!).  I'll have to squeeze through an opening generally smaller than me and I might have to turn off my music, just when I was getting into it.  About half the time, my concentration is broken and I end up walking and needing to psyche myself up to start pounding miles.  However, many other times I'm rewarded with a hidden waterfall, a secret overlook into a gaping chasm, or a chance encounter with a local inhabitant who clues me into other treasures off the beaten path that will bear further exploration now or later.

A chance encounter on this morning's run in Kauai

There is another "lucky" factor at play here of course.  Vacation spots, at least for my wife and I, tend to be filled with these types of gems.  That's why we're here, to engage in a target-rich environment for adventure and exploration.  While we have guidebooks and do some level of research, some of the best finds are done by foot.  Many do so by walking/hiking, but running offers the option of covering approximately twice as much ground in the same time frame. It's something like a fast forward button to skip through the boring parts and focus on the YouTube equivalent of the cat actually playing the piano.

But is this experience only limited to those places surrounded in natural beauty in concentrations as rich as Thomas' English Muffins' nooks and crannies?  Probably not.  Now that I think about it, some of my best regular trails came about from a minor incursion into some foreign territory.  They were so good, I just stopped improvising and tuned out to focus on the "main objective." Perhaps I need to rethink that strategy as well-worn ruts can be certainly comfortable and objective-oriented, but they'll never result in a new experience inspirational enough to blog about.

@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

GUEST BLOG: 3 Ways to Make Documentation as Agile as Development

Welcome back to a colleague and friend of mine, Janice Hamrick, who is an outstanding Technical Information Engineer (aka Tech Writer) and a totally entertaining mystery writer. I read the following three ways to achieve true agility across all development team disciplines and LOVED it.   However, I felt that a fourth point was necessary:

#4 - Be Prepared to Design!

I have often thought that one of the most powerful, yet underutilized, roles of Technical Information Engineers is to make software usable. Sitting alongside of the developers while the software is being created is a huge benefit as they can answer questions like “how am I possibly going to document that???” Serving as de facto Subject Matter Experts across the product, they can also help find potential flaws and opportunities for excellent feature design and simplification. 
~ @MulticastMatt

We all know that the rules of Agile software development decree that user stories must be shippable at the end of a sprint. In other words, a feature must be fully coded, fully tested, fully documented, and fully accepted by the product owner before you can call it done.

To those new to Agile, this seemingly defies the natural order of the universe. After all, everyone knows that documentation always follows development, right? In fact, some teams so firmly believe it’s impossible to have both in the same sprint that they plan to have documentation lag one sprint behind. What they might not realize is that they are no longer practicing Agile development. Because in Agile, you’re not done until you’re done. And let’s face it:

If it’s not documented, it’s not done.

So how do you make documentation as Agile as development?

1. Make Documentation Visible

When story planning, give documentation the same weight you give any other critical-path task. EVERY story should include four documentation tasks:

• Provide content for docs.
• Document the feature.
• Review the documentation.
• Update the doc based on review feedback.

Notice that two of these tasks are the responsibility of someone other than the writer. The team commits to providing information in a timely manner and the team commits to providing thorough reviews to ensure accuracy and completeness of the documentation.

Tip 1: Don’t be afraid to mark the doc task as blocked if time is running short. You want it to be obvious that the story cannot close without its documentation.
Tip 2: Don’t skimp on the estimated hours for these tasks. If you need two different reviewers, put in twice the hours on that task or, even better, put in two review tasks.

2. Be Willing To Write Reality

Be willing to write your documentation to reflect reality. You need to document each feature as defined by the user story, even though you know that eventually you’ll have to rewrite the same topic – either to add the next new bit of functionality or to alter what was previously done because something changed. We’re all familiar with those epic stories that span multiple sprints. The developers break a standard CRUD story (CReate, UPdate, Delete) into three parts and deliver one piece per sprint. Yes, it might be easier to wait until all three are done or even to write anticipatory information, but it’s critical to be able to demonstrate the current functionality when the sprint ends. This puts you in a marvelous position of being able to ship a beta with no notice whatsoever (and yes, that’s happened to me). It also means no revisiting your topics if time runs out and the forecast development changes don’t actually make it into the release.

3. Be Willing To Write Fiction

As a semi-contradictory corollary to the reality rule, be willing to write fiction. Once a feature has been defined for a sprint, you can get started on the documentation. Creating process flow graphics, defining the scenario, providing the key background information, even updating the list of new features in the release notes can all be done before the first line of code is written. Yes, you run the risk that you’ll need to rewrite if something changes, but getting a jump start can be critical to success. You also run the risk of providing unexpected value for your team – timely user-focused questions can help the developers improve the feature as they go.

Tip: Don’t let your fiction be confused with fact. If a feature looks like it’s not going to be completed in a sprint, mark the corresponding docs with a “Do Not Publish” condition and only remove the tag after the code is accepted.

The Bottom Line
So, is it possible for documentation to be as Agile as development? As with all things Agile, success is up to the team. In Agile, everyone on the team is responsible for every story, which means everyone on the team is responsible for documentation.

As soon as your team commits to this principle, the answer is a resounding YES!

How do you keep your documentation agile? Share your tips in the comments. 

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. 

Summer Soujourn in Juneau

Summer Soujourn in Juneau, a photo by cpgmattr on Flickr.

A cloudy day in Austin reminds me of a "sunny" day in Southeastern Alaska nearly five years ago.

@multicastmatt

Timid Incrementalism Will Get You Nowhere

Hi all:

When I came on board at Hyperformix, just over four years ago, I was impressed with many things about the company, most notably its leadership (both technical and managerial).  As part of the Senior Management Team, I had an opportunity to work with an amazing VP of Products and Marketing, Bruce Milne.  I'll never forget the sign he had on his wall--it was a standard sheet of 8 1/2" x 11" paper printed out some time ago as it had seen some weathering.  Upon this paper was the fading ink that had no small impact on my mind and life almost every day since.

TIMID INCREMENTALISM WILL GET YOU NOWHERE

In agile software development, we practice iterative as opposed to incremental development.  There is a big distinction as the latter does not allow for dynamic change while the former anticipates and embraces it.  Perhaps a corresponding statement could be "FOCUSED BOLD ITERATION WILL DELIVER DISPROPORTIONATE VALUE" in agile and lean product development.  I'll admit, it's not as catchy and sounds more like management speak.  Give me a few days to wordsmith it :)

I've googled the original phrase and can't see if it had any origin other than Bruce.  I believe it has implications across both business, creative, and personal life and I always keep it close to the front of my mind and helps me to focus on "thinking big".

I hope this is of value to others!

@multicastmatt

The Ripples of Pebble Across My Life's Pond

Hello all:

On Saturday, March 16th 2013,  I unboxed my Pebble, which represents a "new" era of wearable computing.  For those that don't know, the Pebble was an insanely successful kickstarter project to build an e-paper watch as an extension to your smart phone (iPhone or Adroid).  They acheived 10,000% of their funding plan with $10,000,000 of $100,000 raised. 

Here's their kickstarter page:  http://www.kickstarter.com/projects/597507018/pebble-e-paper-watch-for-iphone-and-android.

I thought I would keep a running total of ways that this "wearable computing" has affected my life.  Note, as I have my phone with me so much, I already feel as though I have wearable computing integrated in my life--perhaps too much.

But first, why did I back the Pebble?  Well, all the cool kids were doing it.  OK, they weren't.  I was pretty early on, but I really liked the idea of this scrappy company using Kickstarter to get their product funded.  It allowed me to play VC (venture capitalist) at a very low entry point.  Note:  playing VC meant that I could have lost all money and gotten nothing in return or gotten a potato in a dozen years.  I don't know how many backers really understood that concept given the online groaning about the missed delivery dates.

From a pure feature and benefit perspective (i.e. logical), I thought it would be a kick ass way to remotely control my iPhone, which is usually in my pocket or on my arm band when I'm running or riding.  There is promised RunKeeper integration which could have additional benefits, unknown to me at the time of writing.  I have made certain allowances to spend any monies necessary to keep my exercise plan on track--this fell (after some heated internal debate) under those auspices.  Additionally, I thought it would be a good way to get status messages that may or may not be important when in meetings with others and I don't want to be so rude as to check my phone, but checking one's watch is perfectly socially acceptable (mostly).

The Pebble replaces the Timex Ironman watch that I've been wearing since 2008, and whose features I use just about every day when it comes to seeing day/date and time and timing my well-defined runs and moutain bike rides.  I use to use my Garmin for the latter, but given the propensity for my running partner and I to run the same routes, I found I didn't need the distance piece as it was essentially the same every time (note, this might be an issue and we should consider changing it up).

So here it is, my ongoing observation log of the ripples in my life from Pebble in reverse chronological order.  The ones in bold are a bit more meaninful:

• [March 18] No one at work has noticed my Pebble at work.  What is wrong with people? :)
• [March 18] I keep looking down at the watch (currently in "TextWatch" face (right now it reads "one six" with the six below the one in modern font) looking for the day and date.  I find it irritating that it's not there, but I'm not willing to switch to any other watch face that includes it as it isn't as cool.
• [March 17] I've figured out a great new feature--I can use the music control to find my iPhone!  I know that there is an app for that, and I do have it, but it takes about two seconds to start playing tunes on my watch--no need to find a computer or iPad, log in, wait for it to find it, and then tell it to play the tune.  I'm amazed that the bluetooth actually reaches across my first floor.  This is a very usable feature!
• [March 17] I keep getting notified on my phone that the Pebble app wants to communicate with the Pebble.  I don't know why--I'm all up-to-date.
• [March 17] Realization--while there aren't too many features available today, I feel like the folks at Pebble have created a great minimum viable product (MVP) with time, date, music control, alarm.  I believe that this can be extended through software in the future akin to the original iPhone.  I'm really glad I backed this project.
• [March 17] Notifications are going to be a bit more of an issue than I had first thought.  You have to go through a manual series of steps to get them to come across correctly. 
• [March 16] Downloading the first update was unsuccessful the first few times, then it wasn't.  It seems to help for the watch to be close to the iPhone.
• [March 16] Getting intimate with Pebble in our first shower together--I CAN CHANGE MUSIC IN THE SHOWER-WOOT! Yes, it's water resistant to 5 ATM.  I wasn't expecting that when I backed it, but it's really nice for it to be there, especially given the exercise implications.
• [March 16] Argh!  There is no stopwatch (chronograph).  Wow, at least for the short term, I'm going to need to use my other watch for runs.

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