Author Archive

One Hit Wonder Friday!

Friday, December 3rd, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

In “The Design of Business“, Roger Martin talks about businesses that find an algorithm and just stick with it. They exploit it and never really dare to explore new ideas or ways of doing things. Sort of like a one hit wonder. You just live off the royalties of that one great idea.

What’s a one hit wonder?

My colleague Mark Gammon and I were talking about Martin’s book and this phenomenon and decided it was time for a “One Hit Wonder Friday”. A one hit wonder is an artist, singer, or group who has made a hit, a really big hit, and yet has not been able to do anything else that really grabbed the public’s attention. Given that the one hit wonder Martin describes in his book is one I’ve loved for a while, we decided to kick-off our Friday series with his example. Here’s who we have in mind: someone who has a song pretty well known even though it is quite old. And yet, the artist (okay, that’s a hint, it is one person) never explored or expanded. It turns out he (okay, it’s a male), has been doing okay living off his royalties. But before we reveal further clues about our artist, first back to business.

Are you living off the royalties of your business “one hit wonder”?

Businesses can end up being one hit wonders too. They find that one “song,” that one big idea, or that one good process and believe they have to stick with it in order to be successful. This is the stuff of bureaucracies. The sad fate of business one hit wonders is that they just aren’t built to last. The idea either dies out or is bought out. One thing for sure, with business one hit wonders there is no room for chance or growth; that is too dangerous.

For your business to avoid the doom of a one hit wonder, you’ll have to challenge yourself continuously in process improvement, in product visioning, and in knowledge sharing. You will have to invite the discomfort of exploration and the unknown. Accepting and embracing the ambiguity of whether you will be a hit or not is not easy. But, as in the Agile world, with frequent feedback and delivery in small batches, you can make quick adjustments through heuristics that set you on  your next big hit.

Back to our “One Hit Wonder Friday!”

Here are a few facts about this week’s one hit wonder (thank you Wikipedia):

He’s a Massachusetts boy, born in the 1940’s. He studied music at Boston University (ah, that paid off :-) Using some of the proceeds from his one hit, he landed a farm outside of Petaluma, CA. So all is not bad for our one hit wonder!  The song itself is remarkably recognizable given that it came out back in 1969-1970 and sold over 2 million copies during that time. (Again, what an algorithm to stick with!) To our one hit wonder’s delight, it has been re-made a number of times, including by the great all girl punk band Fuzzbox (Hint: yes, there is a connection between the term fuzzbox and our song.) This is really good stuff :-)

The song itself had a combination of a sort of spiritual and hippie feel using heavy guitars and hand-clapping. Our artist wrote the song in 15 minutes as his own version of what he thought a gospel song could be. And finally, Rolling Stone rates the song #333 in its top 500 songs of all time.

So who is our one hit wonder this week?



Jean Tabaka is a crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Jean Tabaka original post

N levels of Agile planning and beyond

Monday, November 29th, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

I’ve been pretty passionate about collaboration and knowledge flow throughout the decades of my technical life. This passion led me to author Collaboration Explained. Now I value playing with and applying a variety of visioning, planning, and learning models in Agile organizations. My reading has focused on models for individuals and organizations in how they create flow of value in 21st century businesses. For me, there could be no better place than the Agile context in which to apply these models of rich knowledge sharing. Complex Agile organizations need to consider diverse models that can effectively guide how they plan and deliver.

Agile planning helps us scale and mature across the organizationHarmony, Balance

With this in mind, I’m excited to announce a new series about N levels of Agile planning. I’ll be co-authoring the series with my Rally colleagues Ben Carey, Zach Nies and other Rally folks. Ben, Zach and I want to share some of our informal conversations around Enterprise Agile planning, knowledge creation and knowledge sharing. That means we’ll be blogging about various models we think can be useful for capturing and tracking Agile business value up and down the organization.  Our suspicion is that useful scaling and maturing models coupled with overall team practices bring great value at a variety of levels within an Enterprise Agile organization.

In this series, we’ll share direct experience in applying our models both within Rally and with Rally customers. That means we’ll share some insights about collections of practices at the various levels of Agile planning. We’ll also provide guidance around the Rally services and tooling we believe support planning in continuously innovative, value-driven organizations. Also, be sure to check out Ryan Martens’s series about Scaling Agile to the Strategic Level. Ryan and others will be providing on-going guidance about Rally’s “Project Stratus” tool for road mapping and other strategic practices specifically for Enterprise Agile beyond Release planning.

Ben, Zach and I don’t believe we are the sole experts on this topic!

We’re exposing our frank conversations in hopes of gaining your reactions, insights and feedback. You probably already know about some of Rally’s existing guidance on Agile planning. We just want to dig a little deeper, play a little more with these perspectives and some new approaches that could help you innovate your own Enterprise Agile adoption. While we do this, we’ll be reporting on how we are experimenting with these models here at Rally in our own practices using our own tools and our own services as well as new practices.

Look for our first blog in the next few days describing the overall model of  “Why, How, and What” in positioning the value of Enterprise Agile planning. How many levels of planning will emerge in our exploration, and what will they look like? We aren’t yet prepared to declare in a definitive fashion. Instead, we’ll peek into that together with your input.

Join us as we go into N levels of Agile planning and beyond. We’re looking forward to great dialogue with you through the comments you bring.

Jean Tabaka is a crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Jean Tabaka original post

N levels of Agile planning and beyond

Monday, November 29th, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

I’ve been pretty passionate about collaboration and knowledge flow throughout the decades of my technical life. This passion led me to author Collaboration Explained. Now I value playing with and applying a variety of visioning, planning, and learning models in Agile organizations. My reading has focused on models for individuals and organizations in how they create flow of value in 21st century businesses. For me, there could be no better place than the Agile context in which to apply these models of rich knowledge sharing. Complex Agile organizations need to consider diverse models that can effectively guide how they plan and deliver.

Agile planning helps us scale and mature across the organizationHarmony, Balance

With this in mind, I’m excited to announce a new series about N levels of Agile planning. I’ll be co-authoring the series with my Rally colleagues Ben Carey, Zach Nies and other Rally folks. Ben, Zach and I want to share some of our informal conversations around Enterprise Agile planning, knowledge creation and knowledge sharing. That means we’ll be blogging about various models we think can be useful for capturing and tracking Agile business value up and down the organization.  Our suspicion is that useful scaling and maturing models coupled with overall team practices bring great value at a variety of levels within an Enterprise Agile organization.

In this series, we’ll share direct experience in applying our models both within Rally and with Rally customers. That means we’ll share some insights about collections of practices at the various levels of Agile planning. We’ll also provide guidance around the Rally services and tooling we believe support planning in continuously innovative, value-driven organizations. Also, be sure to check out Ryan Martens’s series about Scaling Agile to the Strategic Level. Ryan and others will be providing on-going guidance about Rally’s “Project Stratus” tool for road mapping and other strategic practices specifically for Enterprise Agile beyond Release planning.

Ben, Zach and I don’t believe we are the sole experts on this topic!

We’re exposing our frank conversations in hopes of gaining your reactions, insights and feedback. You probably already know about some of Rally’s existing guidance on Agile planning. We just want to dig a little deeper, play a little more with these perspectives and some new approaches that could help you innovate your own Enterprise Agile adoption. While we do this, we’ll be reporting on how we are experimenting with these models here at Rally in our own practices using our own tools and our own services as well as new practices.

Look for our first blog in the next few days describing the overall model of  “Why, How, and What” in positioning the value of Enterprise Agile planning. How many levels of planning will emerge in our exploration, and what will they look like? We aren’t yet prepared to declare in a definitive fashion. Instead, we’ll peek into that together with your input.

Join us as we go into N levels of Agile planning and beyond. We’re looking forward to great dialogue with you through the comments you bring.

Jean Tabaka is a crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Jean Tabaka original post

Rally On Both Coasts

Tuesday, November 2nd, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

It’s shaping up to be a busy November for us here at Rally with conferences on both coasts. We’re a Silver sponsor of Gartner’s Application Architecture, Development & Integration (AADI) Summit November 15-17 in Los Angeles. For Agile Development Practices (ADP) East November 14-19 in Orlando, Rally is the Conference Sponsor and once again I’m honored to be presenting. We’re coast to coast, and we’ve got discount codes for both conferences (see below).

Rally Booth

Rally on the West coast with AADI

Rally is excited to be a part of Gartner’s AADI Summit that focuses on powering the Agile enterprise. The summit includes a key conference track on Agile and highlights three critical building blocks of a successful applications strategy—Cloud, SOA and the overhaul of existing Applications. Stop by the Rally booth to talk with one of our Agile coaches or other team members to learn how we can help move your organization into the next phase of Agile adoption.

In addition, one of Rally’s high-profile, enterprise customers will be speaking about how their adoption of Agile practices in an 800-person development organization (within a $15 billion division) has delivered:

  • 3X better throughput
  • an 89% bug reduction
  • the elimination of over 180,000 hours of development time in one quarter

For more news and information about the summit, follow the #GartnerAADI hashtag on Twitter. Also, stop by the Rally booth (F) to pick up a hat, register for a chance to win an iPad, and to learn more about how we can partner with you in achieving Agile success.

Rally on the East coast with ADP East

Once again, Rally is proud to be the Conference Sponsor for ADP East. This conference is a great opportunity to dive into both Agile basics and the latest trends in Agile. Participants will gain guidance in testing, development and organizational best practices.

I always love the ADP conferences because of the energy of the participants and the variety of topics. The conference is a great venue in which to share new ideas and experiences. This year I’m excited about exploring new trends in Kanban as well as revisiting Agile basics such as story writing.

Be sure to check out my two sessions on Monday and Wednesday along with these other opportunities to join with us at the conference:

  • Monday, 11/15 at 8:30 am – Writing Great User Stories 1/2 day tutorial
  • Tuesday, 11/16 at 4:30 pm - Welcome Reception, sponsored by Rally
  • Wednesday, 11/17 at 12:45 pm – Lean, Kanban and the Art of Flow regular session with Bill Wake, Senior Coach at Industrial Logic, Inc.
  • Wednesday, 11/17 at 2:45 pm – Agile with the Right Tools can Maximize Developer Productivity with Collin O’Brien, Technical Account Manager and Sean Billow, Major Account Manager at Rally Software
  • Visit the Rally Software booth # 7 & 8 to chat with Agile coaches and other Rally team members about how we partner with organizations through tools, coaching and community to help achieve Agile success. Rally is also contributing an iPad to the conference Passport game, so be sure to stop by to get your passport stamp.

For more information and updates about the event, follow the #ADP10 conference hashtag on Twitter.

If you’d like to join us for either of these events, use the following registration links and discount codes: Gartner AADI use code ADRD to save $300; ADP use code RAAV to save $200

Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

Jean Tabaka original post

Bob Payne and the Art of Agile Philanthropy

Monday, August 2nd, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

bob_headI have a reason for liking Bob Payne. Bob has empathy and a true love for giving back. That resonates with some of what we are trying to do here in Boulder. Rally, as a B Corporation, has expressly created a charter about giving back to the community: 1% equity giveback, 1% employee volunteer hours (over 2500/year in the last two years) and a number of other local not for profit initiatives. For Bob and us, adopting Agile has  been an important component in how will pull our empathy and our software skills together. With Agile, we seek to deliver feasible, effective, desirable solutions in our complex world. And reaching beyond our corporate walls to deliver that desirability catapults us to being truly empathic in our solutions.

When you meet Bob, you immediately get what “giving back” and empathy is about in his Agile work and beyond. Bob is always looking for new ways to bring Agile to our community and the greater community: our complex world. Out of his own interest in giving back to the Agile community, Bob set up his Agiletoolkit podcasts site. A gift for all of us. At the recent ADP West conference, Bob was there with his sound setup.  Bob took interest in Rally’s Agile Zen acquisition when interviewing Ryan Martens. And I  had the great fun of talking about Seth Godin’s book “Linchpin” that both Bob and I had read.

In this post, I’m so honored to have the opportunity to turn the tables on Bob and be the interviewer.

“Bob, what got you started recording your Agiletoolkit podcasts?”

I began recording the Agiletoolkit podcasts in 2005 after hearing several interesting podcasts and wondering if anyone would be interested in a podcast about Agile. I had always been a gadget person so fiddling with recording equipment and microphones was a natural for me. In fact, I now also have an iPhone App for the podcasts.

I love having the conversations and the podcast gave me an excuse/push to have conversations with people that I might not connect with in the halls at a conference.  A good example of that was when someone said to me, “You have to talk to this guy Arlo.” Without that introduction via the podcast I am sure I would not know Arlo Belshee as well as I do now.

While I am by nature gregarious, I do not search out “networking opportunities”. The podcasts have forced me into a new comfort zone that includes a lot more people from the community than I would have connected with through normal channels.  While I hope people appreciate and benefit from the podcasts, I do them for myself.  That affects the style of the podcasts. Since I am not trying to be polished or create an edited product, the podcasts have a more natural/comfortable feel.  I just wish I said “UM” less and a was little more polished on my delivery. But…I am who I am and it is what it is.

“How did you get into Agile philanthropy?”

man a mano babyAgile philanthropy started as a way of trying to meld my passion for doing good in the world with my passion for agile methods.  Using the power that is evident in the agile community to do great things is one of the goals of Agile Philanthropy.  Ideally we will get to the point that this movement is self-sustaining. But we are really just starting out on this journey.  I hope that I can grow the movement in the direction of local chapters doing work for local not for profits. Right now everyone is very busy and I am the bottleneck.  We are currently working with Mano a Mano and Haiti Partners. And, I would love to have people with a passion for a particular cause to contact me and start up their own chapter.

“What about your other philanthropic interests?”

I am very interested in local sustainable food, economic development and social justice. I volunteer in my kids’ schools quite a bit.  Most recently, I built incubators with the kids and hatched chickens and worked with the teachers to incorporate that into the curriculum. I have been working to get local food into the schools; to create school gardens; and, to relax the laws in Washington DC as they pertain to the keeping of bees and hens. Most of my other work is more directly related to the work I do in Agile Philanthropy.

“When did you start the Mano a Mano project work and what have you and your yearly teams accomplished at the Agile conferences?”

Seems like forever but we introduced Mano a Mano three years ago when the conference was in DC.  I was running the development lab in the basement and hoped that I could get some real work done in the lab that would do some good.  After that, I tried to make it more formal and improve what we have done for them each year.  They have been very appreciative and very patient with us since I am learning as I go with this process.

To date, we have moved them onto a Content Management Platform and developed their iPhone optimized donation page.  Most importantly, I am happy that I have connected Mano a Mano with David Hussman and a number of other volunteers in the Twin Cities that are helping out on a regular basis.  Wayne Simacek showed up for an event that Jeff Patton and Ed Kraay were holding to help Mano a Mano define their web strategy and ended up staying on as a volunteer member of their IT staff.

It is that kind of leverage that I hope to bring by connecting the two communities.

“What do you have in store for us at the Agile2010 conference?”

For the Agile2010 Conference, I am working again with the UX stage to do an Extreme Makeover for the Mano a Mano web presence.  We hope to be able to work on their information architecture and site design to improve the impact of the message that Mano a Mano is putting out. We are looking for volunteers to come by the LiveAid lab and help with the effort (hint, hint).

I also hope to get people interested in replicating this model for not for profits that they are passionate about.

You can do this too

To end this post, I want to thank Bob for the example he sets for all of us. I also want to emphasize Bob’s call to action to get engaged locally. You can do this through your existing local Agile group. Or, you can create a new group with an express charter to give back to the community. Recently Brad Feld here in Boulder wrote about the “Boulder New Technology Meetup” event that supported over 300 people engaged with 20 local non-profits. And here at Rally, we are marching along with Bob philanthopically working to give back: supporting  Intercambrio, donating time to local non-profits (Community Food Share and Growing Gardens) and working with the Salesforce Foundation.

Jean Tabaka original post

“Dear Agile”– A Love Letter

Monday, July 19th, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

Dear Readers,

Writing or receiving a break-up letter can be fairly daunting or shattering, letters-1depending on which end of the letter your name appears. That letter puts a pretty hard stop to a relationship. It’s communicating detachment and finality. It can create a lot of pain whether intended or not. In contrast, a love letter is uplifting. The endorphins fly! Someone is revealing their attraction for you, and their hopes and wishes for a future with you.

Now, there is a reason I have these letters on my mind. I’ve just returned from Rally’s Agile Leadership Forum – a great gathering of people eager to lead successful Agile transitions in their organizations. The event included a lively presentation from Forrester Research’s Senior Analyst Dave West: “Agile Adoption – Research Findings on the Adoption of Agile.” (You can find some of Dave’s data in the “Forrester Wave: Agile Development Management Tools, Q2 2010″). We also enjoyed an inspirational talk from our CTO Ryan Martens, called “Moving Agile Beyond Software.” These great presentations were followed by breakout sessions and a panel discussion about Agile challenges. Now, how to end the event?

As emcee of the forum, I not only kicked off the event, but it was my job to bring closure to the gathering as well. How can we have people walk away with thoughts about Agile? Why are they interested in the first place, and where do their concerns lie?  I was inspired by a video I recently saw about “breakup letters.” The Breakup Letter is a design research tool that Smart Design uses to understand the emotional connection between people and their products, services, and experiences. One person broke up with his cell phone, another, her single-cup coffee maker.agilelove

Now, just how does this relate to the Agile Leadership Forum? I liked the concept of the breakup letter, but I decided to entirely flip the idea and close the event by asking everyone to write love letters instead. In the spirit of Cyrano de Bergerac, I asked each table of participants to work together in crafting a “Dear Agile” letter. In this letter, they were to convey their attraction to Agile. And, they were to reveal where they were concerned about as well. All letters were to be from a secret admirer :-)

Once the groups began to read their letters, I knew we were on to something. Though I don’t have the reading of the letters on video, here are a few examples of our “Dear Agile” love letters.

 

Run this exercise in your own group to find out what the Agile “lure” looks like and also what the “turn-offs” might be.

Breathlessly awaiting your comments,

Jean


p.s. If you want to read some of the transcribed texts of the love letters, read on!

__________________________


Dear Agile,

I have admired you from a distance for some time. Waterfall and I are in the process of an ugly breakup. There is so much about you I need to know. My friend says great things about you. You are so simple and straightforward– no mind games like Waterfall.

This won’t be simple. Waterfall still has clothes at my place. My Facebook status is confused.

In the relationship as we get to know one another, we will have to know each other carefully– co-locating right away? Are we sprinting too fast?

Be gentle with me.

Looking forward to a rapidly developing future.

xoxoxo,

Secret Admirer

__________________________

Dear Agile,

I love you because you offer quick cycles, better quality, and better teamwork. From the first time I saw you, I thought I could begin saving money and add business value.

But, fair Agile, you are not so simple. I’ve heard you are a micro-manager. I don’t totally understand you. Some people are confused by you. On the surface, you sound so perfect and simple, but the more I get to know you the more questions I have.

But, among all my choices, I choose you. You promote collaboration, and allow me to turn things around quickly. You’ve helped me trim weight and stay lean. Don’t disappointment me, I trust you!

With all my love,

Megedá

___________________________

Dear Agile,

I loved you from the first moment I saw you, I loved your fast, speedy releases and that you don’t come with a lot of baggage or documentation. You’re simple and down to earth. You are a great communicator. I always know where you are and my friends love you, too.

I am, however, a bit concerned that not everyone accepts our relationship. I am worried that as my job continually grows and my needs scale up, whether you can handle the increasing challenges. And I’m concerned whether I can afford you… Our relationship and your attachments are what intrigue me the most.

Looking forward to spending more time with you and getting to know you better.  – Your secret admirer.

___________________________

Dear Agile,

We love you, we think you are awesome – for the following (bulleted) reasons:

  • Agile accepts changes and encourages frequent changes
  • Agile can start implementation before full requirements are known.

We do however have a few problems with you agile –

  • Handling cultural change in the organization
  • Does not solve all our issues
  • Makes distributed teams harder to work with

- Your secret admirer -


Jean Tabaka original post

I’m Not a Wildebeest–Setting the Right Goals Matters

Wednesday, May 26th, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

Managing the right goals in software development can have a major impact on your team’s success. You get what you measure. In this regard, the goals you choose can be a defining factor in whether your organization’s Agile adoption thrives or dives. So, what are your choices?

wildebeest

A story about goal-setting

Imagine you are a runner. You have a running coach defining targets for you. Your coach chooses miles and seconds in order to measure you. These metrics turn out to be useful; they are universally understood by you, your coach and your competitors. That’s a good thing. A target goal exchange around these metrics might look like the following:

Coach: “I need you to run a 2-minute mile.”

You: “Uh, I’m not sure I can do that. In fact I don’t think it has ever been done before by any land animal other than a wildebeest, a pronghorn antelope or a cheetah. And, I’m not a wildebeest.”

Coach: “You’re not listening. I already told Sports Illustrated you will. Don’t make me look bad.”

You: “Seriously I’m pretty sure that’s just not humanly possible. I’m no Usain Bolt and I’m not sure even he could sustain a 2-minute mile.”

Coach: “Hey, I set the goals. Run that mile in 2 minutes. Just hunker down and work harder. 2-minutes is the target goal. If you don’t meet it, I’m kicking you off the team.”

You: (muttering under your breath to self, “I can’t do it, you aren’t listening to me, and you are a moron. Why do I even bother to open my mouth?”)

Why goals matter

Get the idea? I’ve been reading John Seddon’s Freedom from Command and Control: Rethinking Management for Lean Service. My colleague Alan Atlas recommended the book. Then my manager Ryan Martens became very interested which led to a book appearing on my desk. Soon after, Karl Scotland mentioned it in an informal conversation about Lean and Kanban. Time to pop it to the top of my reading stack!

Seddon sets a context about Purpose driving Measures that then drive Methods. The combination of purpose and measures start to look like goals. And Seddon breaks goals into two types: Target Goals and Capability Goals. While John’s book is not specifically about software, I could see how we use and abuse goals in our software world. So I decided to delve deeper.

Freedom from Command and Control -- Seddon

Target goals are arbitrary and doom-laden

Target goals are set to measure hopeful results, often an arbitrary number. Think about our runner story and the 2-minute mile. That target goal was  set by someone else. A target goal typically does not account for your strengths, capabilities , availability and skills. Target goals don’t serve you. They don’t serve organizations either. And yet we cling to them. Consider if, as a developer, I hear the following from my manager:

“Jean! You missed the release deadline we gave you. We told marketing and sales who then told our customers that dev would deliver this specific functionality on this specific date. You’re ruining everything. We’re doomed I tell you, doomed! And all because YOU didn’t hit YOUR deadline.”

Uh, it wasn’t my deadline. And yet, missing that goal is now rippling negatively through the organization. This is a lose-lose situation all due to expectations hinged to an arbitrary target goal.

So why do target goals exist?

In many hierarchical, command-and-control software organizations, target goals are how deadlines are set. As Seddon points out, use of ineffective target goals usually arises due to an impossible purpose coupled with non-value add methods. The measures (or goals) are meant to drive teams to the impossible purpose. A command-and-control organization believes that goals must be set top down. The negative impact of these goals is inextricably woven into unrealistic expectations, death marches, and non-value add methods for controlling the work toward the goals.

Enter the capability goal

Let’s replay the runner scenario again.

Coach: “There is a race coming up, a half marathon. That means we need to start training now. What is your time currently?”

You: “I haven’t been really running lately. Rather than guess my times, I’ll start running now. Do you want to know in terms of how long it takes me to run a mile, or how far I can run in a specific timebox?”

Coach: “Let’s start with how you finish a mile. What is your typical way of getting going?”

You: “First, I do a walk/run combination. Then I can give you my actual mile capability in a week.”

Coach: “Okay, let’s set up a plan and together set some sort of goals based on your capabilities. That will help me guide you and figure out when we are faltering. I know you can do this. I’m going to work with you starting right now.”

You: (muttering under your breath, “This is amazing; yea me! I am going to finally put my passion for running to work, keep improving, and run my first half marathon. I love my coach!)

Capability goals are based on real data

Together, the runner and the coach watch the capabilities of the runner to define goals. The purpose of the goal is clear. Measures are set up that usefully help determine the runner’s progress. The method (or running regimen) for attaining the goal is then applied. Simple.

We use this same approach in Agile teams. A team lead or project manager does not set an arbitrary target goal. Rather, the Product Owner sets an overall purpose/vision. The Agile lead, often referred to as the ScrumMaster, works with the team to assess what goals can be reached based on a team’s capabilities and availability. From iteration to iteration, the team provides feedback on what it is able to complete based on its capabilities. The Product Owner absorbs this information and sets expectations outside the team. The process of continuous improvement continues. The team declares, “Based on what we tend to complete, and given the purpose from the Product Owner, we are going to improve our methods in the following ways.”

When good capability goals go bad

There’s a Gary Larsen “Far Side” cartoon of an open refrigerator with a bowl of glop inside holding a gun. The caption? “When good potato salad goes bad”.

Unfortunately, I’ve seen good capability goals go bad in a number of organizations. Listen to this conversation:

Program Director: “I see that our Agile teams are all now using these things called story points to track their work.”

Me: “Yes, it’s working well. Each team has a good sense of what it is capable of delivering iteration over iteration. That helps me figure out how to help remove impediments, where bottlenecks are, and where any team may need us to better resource them. It’s great!”

Program Director: “Hmmmm.”

Me: (muttering under my breath: “That ‘Hmmmm’ just doesn’t sound good. I think I’m about to get sick.”)

Program Director: “So, what’s the highest story point commitment a team has made?”

Me: “27.”

Program Director: “Great!  I’m setting 27 points as the target goal for all teams to commit to for each iteration. Every point will represent 3 hours of work. This precision will help me calculate exactly what we’ll deliver when. Plus, I’ll know which teams are really working and which ones are slackers.”

Me: “Hmmmm.”

Program Manager: “So, let’s get out there and commit! This Agile stuff is great!”

Me: (muttering under my breath, “We’re doomed, I tell you doomed!”)

What just happened must not be allowed

As you roll out your organizational Agile adoption, you’ll encounter many challenges. Pay attention to the usefulness of capability goals. Insist on using them.  Non-Agile organizations won’t like this. At times, you may feel like Sisyphus pushing a rock up hill for all eternity. Be strong. Don’t allow Agile measurement abuse. Create team and organizational trust.  Remove target goals and embrace the incredible value of capability goals. And, don’t allow any backslide. Don’t let your capability goals devolve slowly into target goals in sheep’s clothing.

You: (muttering under your breath, “You know? This MAY just work. Capability goals versus target goals. For the sake of my team, our organization, and the value we deliver to our customers, I’m going to do it!”)

Jean Tabaka original post

What do Toyota, Tabaka, GM, and NUMMI have in Common?

Friday, April 16th, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

My name is Jean Tabaka.

I live in an Agile and Lean world where we take a “stop the line” mentality for granted.  I am encouraged to give my observations and recommendations about continuous improvement. I’ve been learning to create my own reality, to continue learning and to find my strengths in cross-functional work. I passionately read about, talk about, and practice Agile and Lean principles. These principles continually inform how I can create benefit for my company and how I derive benefit from my company.

I’m the lucky Tabaka.

Army JimMy father, Jim Tabaka, was a life-time white collar worker for GM, starting fresh out of University of Illinois with his mechanical engineering degree.  He worked 12 hour days, on his feet the entire time, walking the plant floor, making sure cars kept coming off the line at all costs. He retired at age 55 with a great pension and unbelievable health benefits.

Tim TabakaMy brother Tim Tabaka is a retired GM blue collar autoworker. Well, retired is the euphemism for, “Would you please leave early so that we can bring in a younger, less experienced, cheaper workforce?”  During his time at GM he worked any shift he was told to work. He even moved to a different, older plant. Why? He needed the job and they wanted to replace the older workforce with a cheaper, younger workforce.

My nephew, Andrew Tabaka is a current GM autoworker. He came in under-skilled and now works a night shift for a GM subsidiary building brake assemblies. Andrew is one of the people Tim trained on his way out. Andrew is 24 and this is his first job. I suspect he intends it to be his life-time job. Well.Andrew Tabaka

I’ve never worked for GM but learned to drive a stick-shift on a Chevy Corvette (yes!) And, while growing up, my dad used to take me to visit the plant where he worked in St. Louis. The acres of parking lot outside the plant were for all the cars that had rolled off the line but could not be shipped to a dealer. Too many defects.

Get the picture? We have been and are a GM family.

And I’m telling you this for a reason.

In 1984, GM and Toyota entered into the NUMMI (New United Motor Manufacturing Inc.) agreement to co-run an auto plant in Fremont CA. NUMMI made big news at the time. It took an existing, highly dysfunctional GM workforce and turned them into one of the most productive auto plants in the US. A documentary about this recently aired on Ira Glass’s “This American Life”. What a story, too fantastic to be made up: the complete turn-around of a failing GM plant to a thriving joint venture. The documentary recounts 30 disgruntled, unmotivated GM employees traveling to Japan to work with Toyota employees to learn “The Toyota Way”. It features commentary from Jeffrey Liker (author of “The Toyota Way”) John Shook (author of “ Managing to Learn”) as well GM line workers and GM management. The power punch of the Ira’s story? GM never replicated the success at the NUMMI plant.  Several theories about this failure are postulated at the end of the documentary. It is up to the listener to form their own conclusions.

Two weeks ago, as a coda to the documentary:

The Fremont NUMMI plant had its last Corolla roll off the line. NUMMI was shut down, this time for good. It was the first factory ever shut down by Toyota.

I care both personally and professionally about that darn NUMMI plant. The Ira Glass documentary about NUMMI’s turnaround and GM’s failure to replicate struck a deep chord for me. I called my brother Tim that evening to get the real scoop. I had heard him recount what his life was like in a GM plant and I wanted to hear it from him again.

The truth is the NUMMI success DID have an impact on GM outside the Fremont plant. Prior to the NUMMI conversion, life in the Oklahoma City plant where Tim worked was miserable. As in the story “Rivethead” by Ben Hamper about GM plant life in the 1970’s, alcohol abuse, absenteeism and nervous breakdowns were common place at Tim’s workplace. He lived the life documented about the Fremont plant prior to the Toyota venture.

Life with the Andon.

In the late 1980’s though, Tim told my about how things were changing, amazingly so. A “stop the line” mentality was adopted at their plant. Use of an “andon” was introduced. One tug on the andon was the alert to call over for some help; a second tug was “stop the line” we need more time to fix this. Tim was one of the people who roamed the plant floor prepared to assist when the andon was pulled once so that it wouldn’t have to be pulled again. Every station had its own andon “song”. (Apparently the “Baby Elephant” song became the bane of my brother’s existence.)

Life was so much better (the “Baby Elephant” notwithstanding). Workers were encouraged to stop the line and fix problems versus pushing cars through. Teams were brought together to offer suggestions for how to improve the work processes and the flow within the plant. Quality went way up and defects went down. Morale and motivation went up. Alcohol and drug abuse went down (this is anecdotal from my brother, not based on an actual study.) And for Tim personally, plant life improved dramatically. The new system played into his strength: being a cross-functional team member, challenged and rewarded for doing his work.

Back to the NUMMI story and what GM ultimately adopted.

NUMMIFair enough. I have my brother Tim as an example of an autoworker who benefited (well, except for the darn “Baby Elephant” team’s issues). But I also have a father who, as a GM executive was expected to tirelessly follow and communicate the GM line. It took its own deep toll on him. And I have a nephew who continues to work as a very replaceable night shift cog in a different plant in the GM machine. GM has declared bankruptcy for any number of reasons. And now, my mother’s benefits, my brother’s pension, and my nephew’s pay are in peril.

My name is Jean Tabaka, daughter of Jim Tabaka, sister of Tim Tabaka, and aunt of Andrew Tabaka. My father never benefited from Lean thinking. My brother had a wonderful brief taste of it. And my nephew is now somewhere in an odd stew of Lean and non-Lean practices.

I’m the lucky Tabaka. Lean has brought me a lot and taught me a lot in my Agile world. While Lean may be most closely affiliated with the Toyota Production System; and while it may be assumed that failure to adopt the TPS was GM’s ultimate demise, I believe the Lean lessons have continued to grow, spread, and morph as a result of both success and of failure in Lean adoptions.

GM, Toyota (yes Toyota), NUMMI, the Oklahoma City plant and others all have their stories of success and failure. Each had their approach to Lean adoption. Like Tim Tabaka and NUMMI, we have our lessons to learn from Lean in our software world. Lean is not the panacea. The TPS cannot tackle all issues. Agile is not the panacea. No one methodology can guarantee product success in all situations. Our continued belief in checking the value of our adoptions is critical. Our conviction to pay attention to failure modes as well as success is key. If you don’t believe me, ask my brother Tim.

Jean Tabaka original post

78 Things I Have Learned in 6 Years of Agile Coaching

Monday, March 1st, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

I have been an Agile Coach for over 6 years now.  I’ve learned a lot during this time, and I’m still learning.

Here are 78 things I have learned so far:

  1. Number of people to whom you ask to describe “Agile”  = Total number of Agile mental models  + or -  2
  2. Distributed teams need love and a ScrumMaster at each site
  3. A foosball table may be one of your best Agile tools
  4. Geography is more than a timezone issue; it needs infrastructure support
  5. It’s massively worth the effort to stay engaged in the Agile community through local events, online lists, conferences, and casual meet-ups
  6. Having a Product Owner is non-negotiable
  7. Avoid Cargo Cult Scrum at all costs!
  8. Agile teams need to have fun
  9. The best Agile teams and companies rely on Servant Leaders
  10. Embracing a real Agile culture is often more than one team can create on its own
  11. Agile development can only cut costs if you are willing to spend time and money on it
  12. A great approach to agile maturing and scaling is Flow Pull innovate guidance from Lean
  13. Burndown charts are about the team commitment to doneness, not about individual performance or time tracking
  14. Ensure your sprint backlog reflects the delivery of product value
  15. Escalation doesn’t serve either the Agile or Lean community in continuous improvement of practices
  16. You need to have more than checkbook buy-in from your Executive to be successful
  17. Mature your Agile team practices before attempting to scale to more teams
  18. Not having a clear signal to end your stand-up can lead to problems
  19. The Lean principle on Flow guides Agile teams on how to tighten up their practices
  20. Get everyone in your Release Planning meetings if you want true commitment to the Release’s vision
  21. Command-and-control ScrumMasters reduce the intelligence of their teams
  22. Co-located teams move to being high-performing, high trust teams far easier and far faster than non-co-located teams
  23. Frequent communication through site visits, IM, Skype, email, Facebook, Yammer, video conferencing and other technologies help distributed teams gel and feel the love
  24. Agile teams invite healthy conflict in order to become great, enduring teams
  25. Velocity: it’s about the team not the individual
  26. Kanban is helping teams find new measurements for constant flow of value -  so let’s pay attention.
  27. No product owner or too many product owners add up to the same Agile adoption smell: no definitive decision on ranking or acceptance
  28. A Product Council is an effective way to manage stakeholders and minimize backlog churn
  29. Story points help teams separate calendar hour and number of team members from the story’s complexity, effort, and doubt
  30. Stories have relative sizes to one another; only tasks take on effort estimates
  31. A well-written story (small, about benefit to a role) doesn’t lie; requirements do by their shear volume of content
  32. A product backlog is ALWAYS ranked
  33. A product backlog is not a task list; tasks only appear after estimating and planning by the team
  34. Agile improves the quality of life for employees
  35. Great teams are made of collaborative team members
  36. Agile doesn’t create the messages it exposes them
  37. Pair programming raises team awareness and code integrity
  38. Use consensus, not forced compromise or command and control, to gain full team commitment
  39. Effective team meetings require structure and discipline
  40. Commit to Agile values and principles; your practices will follow
  41. Transparency is an Agile virtue not a punishment
  42. Agile is about commitment not tools; tools support those commitments and make them visible
  43. Product owners who make their decisions in a vacuum are not Agile
  44. Agile teams invoke respect and kindness even in stressful times
  45. Teams that don’t retrospect are not Agile
  46. Retrospectives are not about blame
  47. Retrospectives bring continuous improvement of process and working agreements
  48. If you don’t have team working agreements, create them now
  49. If you don’t hang your team working agreements on the wall, put them up there now
  50. Aggressively cap your utilization capacity until you know your velocity
  51. Blog your Agile experiences; more people want to hear them than you think
  52. Test driven development doesn’t just create better code; it creates better conversations that create better acceptance
  53. Agile Architects and Product Owners work side-by-side to rank product backlogs
  54. Give your Agile teams a break such as a “hackathon” built into the cadence of the team’s release schedule
  55. High capacity utilization is deceptively evil
  56. Quality is everyone’s responsibility
  57. Small increments quickly inform us about our work and produce feature sets faster
  58. Lean has had a great impact on my Agile language
  59. Hiring the best” can be yet another cliche in Agile
  60. Hire wisely not cheaply
  61. When hiring new members, team consensus is a must
  62. Use 5 levels of planning: Vision, Product Roadmap, Release Planning, Iteration Planning and Daily Planning
  63. Release planning is one of my favorite Agile activities
  64. Teams and stakeholders invite release planning to see beyond the next iteration
  65. FYI, good brainstorming requires lots of post-it notes and sharpies
  66. Pay attention to your facilitation skills so that you don’t takeover decisions and don’t let others do the same
  67. Keep Agile meetings focused, stick to the purpose and timebox
  68. Turn your electronics off in Agile meetings; focused meetings are productive and end on time
  69. The biggest cost cutting lever in Agile is prioritization
  70. Don’t be afraid to try new practices; your velocity and quality may thank you
  71. Agile is useful beyond software; take it up and out the organization
  72. Old tools stand in the way of new tricks; MS project is not the way to go Agile
  73. Team identity is important, individual heroics are dangerous
  74. Individual appreciations in retrospectives are a great way to create space for the growth of Agile team trust
  75. Agile maturity is NOT about a CMMI-like maturity model
  76. The war between Agile and Waterfall is over; get on with your continuous delivery of valued items
  77. Agile asks us to slow down in order to speed up; just do it
  78. I love Agile.

This is far from a comprehensive list. I still have plenty more to learn about Agile. I’d love to get some insight from you about what you would add to the list.

What have you learned in your experience practicing Agile?

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

Jean Tabaka original post

Rally Chalk Talks – A Great Resource for Getting up to Speed

Thursday, February 18th, 2010

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /var/www/wordpress/wp-includes/shortcodes.php on line 227

Original Post by Jean Tabaka

Last summer, Rally started a video series called “Chalk Talks“.

I was fortunate enough to have filmed several “Chalk Talk” videos about some of the basics of Agile software development (The Agile Manifesto, Scrum Basics, Iteration Demo and Review Meeting, and other topics).

Since then, Rally’s expert team of Agile Coaches have joined the party and recorded additional Chalk Talks, again on some great basic Agile topics: Ronica Roth on User Stories, John Martin on Story Points, and Rachel Weston on Release Planning in Agile just to name a few.

We also tapped into the wisdom of some of our other Agile Coaches: Julie Chickering, Mark Kilby, and Ken Clyne.

Our Rally Chalk Talks are informal videos, typically 3 – 5 minutes long, intended to provide quick, easy introductions to Agile topics.

Filmed in a short, tutorial format, these videos are great to share with your team as they are getting up to speed on Agile.

To get a feel for our latest work, here’s Rally Agile Coach Ronica Roth in her great Chalk Talk on User Stories. ( during which you can find out why a dog would want his own laptop :D )


Be sure to check out our entire catalog of Chalk Talks and subscribe to our YouTube channel if you’d like to be notified when we publish new videos. We already have two more Chalk Talks queued up: “Kanban and Scrum” and “Agile and Lean”.

As you look through our current catalog of talks, be sure to let us know what other topics you’d like us to cover in future talks.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

Jean Tabaka original post