Agile Development Blog

Last week was quite a week here at Rally. Given the many activities we experienced, I was reminded of our engineering “hackathons” except applied in a whole new way.

Why do we only talk about hackathons for developers and the engineering team? (If you aren’t familiar with hackathons, you might start by reading our series on how to foster a culture of innovation.)

Hackathon – a time-boxed event, typically a day or a week, used to build prototypes of innovations that could be helpful in enhancing user experience, architectural capacity, or development team effectiveness.

Given this definition and given the work we accomplished last week, it became clear to me that what we had done was run culture and space hackathons

Monday and Tuesday – knowledge team leadership and hacking your culture

On Monday and Tuesday, we took 30 folks at Rally through Christopher Avery’s “Knowledge Team Leadership” course. We’d invited Christopher in after great reports from two folks we sent to his class last year. Based on that feedback, we decided to try the course out as a “management training course” internally at Rally. There was a ton of added value in that course for new managers as well as executives.  Included in Chris’ class is his work on the responsibility process, seen in the picture below. (click on the image to get to Chris’s site.)

Chris Avery's Responsibility Model

The really cool thing about the course is that, while we were learning about teams and leadership, Christopher had us apply our course work in separate, meaningful small projects that run concurrently with the course.  With our 30 people, we subdivided into five small teams, where two teams decided to work on one project together. Because this was a private course, each group chose a project related to Rally’s culture.  I would argue that they all turned out to be culture hackathon projects given that we only had 6 clock hours to produce a cultural innovation “product”. And boy did we get some great stuff:

• Rallypedia – a new internal wiki at Rally that has an encyclopedia of terms, models, stories and lore at Rally.  This site is critical to keeping our culture strong in a rapidly growing, geographically distributed company. What a great cultural contribution.
• Beyond Rally - a new wiki site for after-hours and non-work related announcements at Rally.  This open site shares music and other social events, for sale items as well upcoming volunteering opportunities.
• Core Values Revisited – a new wiki site that shares stories about us living our core values.  It is a platform to revisit these values and separate core values from cultural norms.  This project is a critical part of us creating our shared vision for 2020 at Rally.
• Rally teams video – a 5-minute video that introduces new employees to the importance of teams at Rally. The video explains five key components of teamwork and how this will inform and guide any new employee into our collaborative culture

Two of the projects launched at the “project demos” event during the course. The other two will launch later this month.  It was a testament to how well some of Christopher’s approach works for quickly, building high-performance teams.  It was also a testament to effectiveness of holding non-software hackathons.  Those two days of project work left all of us on a real high as hackathons tend to do. For me, we had taken advantage of that hackathon sense of innovation and urgency and applied it to great ideas about extending our culture.

Wednesday and Thursday – Design Thinking and hacking on your space

After two days of training with Christopher and our culture hackathon, I got to spend most of Wednesday and Thursday with a group that was focused on shaping our new office space.  (Yes, we are moving again!)  We have learned about building effective team rooms as we have moved our team to six locations since starting in 2003.  I see these six moves as a real gift.  It has forced us to keep playing around with furniture and space to help enable the emergence of high-performance and collaborative teams.  With each move, we are invited to purposefully pay attention to our culture and our knowledge flow. So our goal with this latest move is to be even more impactful and extend these innovations in space design to our entire office space.

To enable this kind of innovation to emerge, we had a space design charrette that was facilitated by George Kembel, Executive Director at the d.school at Stanford University.  This was a natural out growth of the innovations that I got to work with at while at the d.social summit this summer.  It could not have happened without John Kembel (yes George’s twin brother) and his team at RightNow here in Boulder.   Due to the successful RightNow acquisition of HiveLive, the RightNow office is growing and forcing a move here in Boulder as well.    It was really cool to experience this space type of hackathon with two companies of two different sizes in two different contexts with two different cultures at once.

Roughly five people from each company gathered in a large open space in the Rally offices to run their hackathon. After establishing clear tasks for each team, surfacing motivations, making some agreements, crafting a higher elevating goal for each team, and celebrating the diversity, we jumped in to an iterative process.  That process had the two teams move through four different process steps:

• point of view & strategy
• approach and empathy
• low resolution prototypes
• iterate on build-out plans

As a result of that work, the RightNow team created three floor designs using floor tape, tables and foam core. It was cool to watch that team focus on the prototype stage.  Because Rally is dealing with 65,000 feet and a move-in date of February, we were more focused on planning next steps and learning from a rapid prototyping experiment that we plan to start in our current office next week.   To aid us in our prototyping efforts, we have already built three different T-Walls based on formations I had seen at the d.school. We’ve let the T-walls loose in an area close to Support and Product Development to get feedback.  We also plan to tear out a couple of large tables in two of our conference rooms to make room for more flexible uses in those team huddle rooms.

Huddle Room at d.school

From our space hackathon, we hope to learn from those prototypes in the next month and let them inform what furniture components we will order for the space.  These low-resolution, non-precious prototypes will hopefully allow teams to experiment with more flexible solutions for their work spaces, team rooms, huddle rooms and conference/training rooms.

With regard to our point of view, strategy and approach, our prototyping team is resolved to run way through the finish line and set a cadence for continually hacking our space.  We are likely to be in our new space for a long time.  As a result, we need to keep the spirit of innovation alive and drive down the set-up time and costs for changing our space to suit the emergent nature of teams around Rally.

What a great week for implementing culture and space hackathons. I hope you and your organization are doing the same.

What has worked in hacking your space or your culture?

For more ideas from the d.school do not miss their site and blog and the tour of the new space.

Ryan Martens is a tomatillo salso maker, school board member at Friend School Boulder, and CTO at Rally Software Development.

Over the last several months, I led four breakout sessions on Agile quality at our Agile Success Tour and in the process I heard these troubling comments:

“We don’t have enough time to test, because the developers give us working builds way too late in the cycle.”

“I wish our quality was better, but it’s out of my control to change anything.”

“Poor quality must be our fault as testers, since we are the ones responsible for testing.”

“We should test more, or we should develop slower, or we should specify our requirements better – that should improve quality.”

Agile development advocates that the whole team owns quality, but clearly many teams face barriers to accomplishing that goal. I’ve been thinking about these comments a lot lately, and I think the problem is that basic and predictable human responses are getting in the way of achieving higher quality.

You can certainly improve quality through changes in process (and many of those changes are at the center of Agile adoption), but more often when people ask me process questions, I hear teams struggling with the human aspects of those process improvements. By paying attention to the ways everyone naturally avoids responsibility, you will be able to move past the barriers that contribute to poor quality.

The best model I’ve seen for how to do this is Christopher Avery’s Responsibility Process. The basis of this model is that when problems arise, every individual goes through a very predictable series of thoughts that allow him to cope with what just happened, but also block him from moving into a mindset of learning and improving.

It starts with blaming someone or something. When you move past blame, then you justify the event with a story you tell yourself. Once you move past that story, then you turn the blame to yourself and feel shame. Acting on that shames often leads to feeling a sense of obligation. If the shame and obligation become too unbearable, then you will quit or detach to escape from those feelings.

All of these thoughts prevent you from taking responsibility and ultimately moving into a mindset of learning and acting. Sound familiar?

This same pattern subtly plays itself out every day for you and your team around you, especially with issues of quality. According to the Responsibility Process, there are three keys to taking responsibility: (1) intention, (2) awareness and (3) confront.

To learn more, I encourage you to join me and Christopher Avery for our January 12th On Demand webcast, The Best Kept Secret in Agile Quality, where we will talk about :

• the relationship between quality and ownership
• the difference between accountability and ownership, and how this difference affects quality
• how the Responsibility Process can be used as a framework to continuously improve quality through a focus on people and interactions
• how to apply the Responsibility Process to your development team

I’m really excited about what we’ve put together for this and would love to see all of you attend.[Reserve your spot now by CLICKING HERE]

About the Author: Zach Nies is a golfer, expert on Agile quality and VP of Products at Rally Software Development. Subscribe today to get free updates by email or RSS.

When Agile teams start to plateau (or worse yet slide back to the old ways), I often hear this complaint:

“There is too much time in meetings with Agile Software Development, we give up!”

I usually follow that up with a question: What are you doing to fix that?

An overabundance of meeting time is a problem that many organizations face, but I’d argue that Agile practices are the solution instead of the cause.

If I can get the team to ask me for suggestions, I always point them to my friend Jean Tabaka’s great reference book on running Agile meetings – called Collaboration Explained. But today I saw yet another wonderful nugget from Seth Godin about general meetings.

Seth Godin’s Suggestions on Serious Meeting Practices

Many of his suggestions relate to the practices of Agile and are disciplines we use at Rally to keep from meeting to death.  Seth’s portion in quotes below: 

• “Remove all the chairs from the conference room. I’m serious.“
  New employees to an Agile team or company often laugh at the idea of a daily stand-up meeting, but literally standing during the meeting encourages people to be concise, attentive and then get on with their work. The best stand-ups at our company happen at around 9:00 am daily.

• “Understand that all problems are not the same. So why are your meetings? Does every issue deserve an hour? Why is there a default length?“
  Agile helps us drive this discipline. Stand-up meetings are less than 15 minutes, iteration planning is a half-day for a new team and 1-2 hours for seasoned team.  Release planning is a 4 to 8 hours and my require a part of second day to handle dependencies across multiple synchronized teams. Allocate the right time for the right purpose, and bring in a professional Agile facilitator (or assign a neutral party from another department if you don’t have the budget) to keep the goals of the meeting moving. Having a agenda with time limits per section helps. So does a big buzzer (we have one of these at each table of attendees) to hit when people get off topic.

• “If someone is more than two minutes later than the last person to the meeting, they have to pay a fine of $10 to the coffee fund.“
  We do this at our executive stand-up meetings (with a slightly lighter sentence), and recommend customers do the same. Late attendees pay $1; if you’re late AND the last one in the door, it’s $5.

• “Require preparation. Give people things to read or do before the meeting, and if they don’t, kick them out.”
  Before release planning, we create a collaborative web site where materials are stored. All pre-reading is assigned in advance, and all attendees have to load their slides to the site before the meeting begins. We even have a “no thumb drive” rule to discourage last-minute slide creation.

So what’s my point? Don’t blame the methods and practices for your lack of personal discipline and commitment to get better.

If you are going to win in this global economy, you have to find ways to constantly improve, and Lean and Agile development are proven cures. It is too easy to give up, so instead stand-up and, as Christopher Avery teaches, take some personal responsibility to make it better – start from within!

Do you have other meeting guidelines that you’ve used successfully? How much of your company’s meeting addiction gets blamed on Agile practices? How has your organization adapted to better meeting discipline?