If you saw us present at Agile 2007 or saw Jean last week at SD Best Practices in Boston.

Please provide comments and thoughts on our "Enterprise Agile Rollout - Greening of the Software Industry" talk in the greening hive.

If you want to see me present it, come next week to Agile Vancouver's conference or the week following to San Jose California and Software Business 2007.

Jean, Hubert, Evan, Ronica, Rachel and Cynthia will be reviewing the feedback from all these talks at our services meeting in October. It would be great to have your comments soon.

Today at Rally, we released two new products that round out a suite of products on Salesforce's AppExchange and Force.com platform as a service. This suite of products work to extend Agility beyond the development team.

We built these tools initially to help us run our business on the Salesforce platform. Over the past two years, as the Salesforce platform as gotten increasingly capable, we have moved to package these solutions for the increasing number of joint customers between Rally and Salesforce.

This level of integration becomes critical in helping agile software teams manage feedback for prioritization and steering. The following diagram portraits the entire suite including Rally's Agile Life-cycle Management solution on the far end.

You can get an overview and access to these products on the AppExchange.

Rally Product Manager is a native Salesforce application that helps product managers and product marketers manage the flow of market feedback into prioritization. It shipped first in May 2006 and was update in May 2007 and is available today for Free as Agile Product Manager.

Rally Community Manager is a new Web 2.0 platform, from HiveLive packaged with templates and Salesforce integrations as support-in-a-box from Rally. This solution is based on the work we have done with HiveLive to make the Agile Commons site work for our customers and prospects. This product sells for $1.50 per active user per month with a minimum of 1500 users.

Rally Support Connector is a new native solution on the Salesforce platform to close-the-loop on support cases through development. This is our third instance of this solution based on various platform upgrades. We put a substantial amount of work into the product to make it really easy for support users and seamless for Rally users. It is available for Free on AppExchange.

Details on the entire solution are provided in the press release and at our Agility Suite for AppExchange site.

Rally Customers can view and comment on the backlog for these products in the Agility Suite Backlog Hive and you post feature requests or comments about these products in the Rally Feature Requests Hive.

I miss the big blow out post-shipment parties every 18 months. You celebrated shipping something that was a long, hard go. Unfortunately, you were also ready to see it go. In the end you hacked and patched where you could to make a critical date for revenue recognition around upgrades. Those parties seemed like post-mortems. They were great to mend the wounds on the team, but it was hard to know if the release was really going to be a small, moderate or huge success.

Then you go agile and start shipping every six weeks or so. You deliver value on a regular cadence, respond quickly to your customers' needs and are suddenly nimble enough to leapfrog your competitors. But being agile has one Achilles' heel - it's hard to know when to celebrate.

Well, then you take home the top industry prize, two years in a row, in the face of capable competitors and while the market is growing and evolving. (If you didn't see the press release yet, Rally did this March 21 at the Jolt award ceremony.) And then you know the whole engine is working to shape the right product for the market. That is a much better reason to have a party. Lucky for us the Jolt awards happen every 12 months!

Nice work, everyone, for contributing to Rally's second consecutive win of the Jolt Product Excellence Award. Thank you to our customers and partners who have helped drive us to create a family of agile life cycle management products that help teams achieve the benefits of agile at any scale. Last but not least, thank you to the stellar team of Jolt award judges. We were honored to win Product Excellence last year, and now we're grinning ear to ear with the honor of being awarded the top prize two years in a row.

Without the big bang, post-mortem parties, when should you celebrate? At Rally, we have product engineering release lunches with each release. Usually it ends with a few too many margaritas and a causal afternoon at work. We also have regular company celebrations if we meet our quarterly performance goals.

As for when your team should celebrate its Agile success, I think every release, when it helps meet your corporate performance targets and when the market tells you. Don't miss an opportunity to celebrate. We're not. :)

People often ask me how well Rally lives by its own Agile principles. Yes, Rally teaches Agile, but are we truly Agile? The short answer is yes with a “but,” because in keeping with Agile principles we are inspecting and adapting (and hopefully improving) all the time. The long answer can be explained through Rally’s core values.

In this part 1 of 5, I’ll outline one of our values – Creating Your Own Reality. Whether you practice Agile or are interested in Agile or are simply trying to get through the day, I hope this post will lend to creating a better workplace for yourself and a better work product for your company. I don’t claim to be an expert or to profess anything you haven’t heard before in a half-read business book sitting on your nightstand, but I do believe that through Agile, we’ve found a better way to do what we do. So here it is: Tim’s step-by-step guide to creating your own reality.

It’s been told a million times in as many CEO handbooks, but it’s true that you will never accomplish a goal you don’t verbalize. Once you verbalize a goal, you can literally train your brain to begin to recognize opportunities that you never knew existed. My favorite example of this is a little simple but very telling. Several years ago, my wife and I decided to buy a Honda Accord. Not until after I was behind the wheel did I realize that literally every third car on the road was an Accord. How on Earth had I not noticed this before? (As it turns out, the Accord was the top selling car that year.) Stating the goal (and driving the car) opened my eyes to the world around me.

Don’t set constraints on your goals. It doesn’t matter whether a goal is right or not, at least initially. Once you learn more about the goal, you may have to adjust and adapt, but you’ll never progress forward if you haven’t at least defined a direction (maybe not the direction) for yourself.

One of our Testing Managers (and Rally blogger) Bob Cotton at one point set a goal to someday run a company of his own. After leadership experience at Rally and probably some soul-searching of his own, Bob has a new goal to dive deep into the technical experience of software development and write a book. Was his initial goal wrong? It doesn’t matter. While moving toward his first goal, he learned enough to alter his course and is now fulfilling a dream of becoming an author. Being an Agile practitioner myself, I can’t think of too many examples in life where being Agile is a disadvantage. It’s certainly an advantage in goal setting.

For those of us in the high-tech industry, mapping your reality in your current job, and the next job, and the next one, is particularly important. High-tech companies aren’t around forever, and very few individual contributors make it through waves of acquisitions, IPOs or whatever else may come along.

My advice to Rally employees probably seems odd coming from the CEO, but I say be selfish. Know what you want to accomplish and use the company as a vessel. If you’re not taking care of yourself, you’re probably not doing a good job for the company either. So what if you work for a software company but your goal is to lead a non-profit? Take on new projects in marketing, help the company plan an event, lead the organization’s charitable efforts. It’s your responsibility to create and use the opportunities in front of you.

Ultimately, we all have to be entrepreneurs with our own careers, even if you don’t want to be one in business. Try emailing yourself your goal – right, wrong or indifferent. You may start seeing a few more Honda Accords than you thought you would.

Since the start of 2007, I have found myself repeatedly saying that I am “living the dream.” With the formation of the Entrepreneurs Foundation of Colorado this week, another piece became reality.

Although it sounds like a lofty (or maybe just plain unrealistic) goal, I started Rally to help change the world. Through the use of Software-as-a-Service (SaaS) and Agile software development methods, Rally focuses on changing the world of software to be more “green” – more efficient, less wasteful and ultimately more valuable for its end-users. On the personal side, I also hoped to change the world of social equity by bringing foundation-like giving models to start-ups and their young employees.

I believe the economic model of today is growing at the expense of our social and ecological capital – in essence, we are borrowing from our own future. During the early days of Rally, I was introduced to sustainable business models from Paul Hawken, The Natural Step for Business by Brian Nattrass and Mary Altomare, Lester Brown and Peter Senge. However, it was the vivid Conservation Economy models at EcoTrust that stick in my mind. They help paint a vision of what an upgrade to a sustainable model could look like. The Conservation Economy model balances and reinforces the economic, social and environmental capital. My hope and motivation is to help this model emerge. To me, the Entrepreneurs Foundation of Colorado is effectively working to enact the patterns of social equity and civic society from the EcoTrust model.

Through the hard work of Brad Feld, Mike Platt, and The Community Foundation of Boulder County, the board of the Entrepreneurs Foundation of Colorado was able to make a major simplifying enhancement to Rally’s original 1% fund concept from 2003. As a result, we have approximately 1% of the Series A equity from five rapidly growing Colorado startups set aside to endow Colorado’s communities. In addition to equity from the founders, the Entrepreneurs Foundation of Colorado model gets endowment capital from early investors too. As a board, we also continue to explore ways for individual employees to participate. I found in my last company, it was hard to encourage giving at the time the company was sold. With the Entreprenuers Foundation of Colorado model, we are having the social endowment conversation during the formation stages of the company and with all the stakeholders, including investors and employees. This timing change is huge and will impact a positive change that will should increase the philanthropic giving rate in our “start-up crazy” community.

In the case of Rally, the philanthropy discussion has translated into a core value of the company. “Giving Back to our Communities” is one of our five core values. In addition to our Entrepreneurs Foundation of Colorado equity endowment, we have a goal of donating 1% of our time to non-profit organizations. We also hope to follow the 1% of profits model made famous by folks like Marc Benioff of Salesforce.com in his book Compassionate Capitalism, when we become profitable.

Thank you to everyone who made this happen. For me, this is a personal victory and one of my early goals in founding the company. Please contact me or the Entrepreneurs Foundation of Colorado for more details about this program. I am glad to help any founder work through the issues to make this part of their start-up.

You could find energy and passion everywhere at this year’s show, but it was easy to get lost too. With 1100+ attendees (up 40% from last year) and twice the number of tracks, this conference was BIG. With 250 new companies and 60% of those attending for the first time, the conference was full of newbies (Official attendance stats from the Agile Alliance should be published in September). At the same time, all the big thought leaders of Agile were there and were heavily engaged. Even more than last year, the conference catered to the Agile newbies with a dedicated track and many of the largest talks focused on best practices and initial Agile adoption. The more intermediate and advanced folks seemed to get most of their value from Experience Reports and Open Space sessions on large-scale adoption, distribution and team motivation. These sessions shared experiences from the field that could be adjusted and applied in your own context. For a virtual tour of the show, I recommend listening to Bob Payne’s Agile Toolkit podcasts, he did some 26 recordings at the show this year.

Rally has been tracking right along with the Agile movement since our inception in 2002. The following three paragraphs highlight the show from a vendor’s point of view as well as Rally’s achievements along the way.

Last year in Denver, the Agile 2005 show was a sell out at with over 700 attendees. Rally was joined by other product vendors on the show floor, including Agitar and Microsoft’s Visual Studio. We led seven sessions, announced our services partner program and launched Rally Program edition, which added program management support to a proven base of Agile project management and lifecycle support of tests, defects and requirements. As a well-capitalized company, the rapid up-take of Rally’s Agile solution has allowed us to quickly grow in just two years to 50 employees and a customer base of over 200 companies with 3,000 users in over 20 countries.

This year in Minneapolis, the Agile 2006 show sold out with 1100 attendees, and Rally’s presence was joined by different product vendors including IBM’s Eclipse Process Framework, VersionOne and GreenPepper. Rally’s Agile coaches led 10 sessions, and we expanded our Agile Accelerator Services available through Rally and our service partners. On the product side, we now have five distinct offerings including our stand-alone Agile Planner, an Agile product management solution, Rally Team edition, Rally Program edition and a newly announced Rally Enterprise edition. These on-demand and on-premise solutions start at $19/user/month and allow us to align with a customers specific level of Agile scale and maturity. We anticipate the success of Agile and these well-packaged offerings of products and services will allow us to more than double our customer base before next year’s Agile conference.

(Rally's Michele Sliger and Hubert Smits get ready for one of the 10 Rally led sessions)

Next year in Washington DC, the Agile 2007 show will be capped at 1500 attendees and Rally’s presence will be joined by still more product vendors. In order to accommodate the various levels of Agile knowledge at the show, I expect we will see an even better separation of tracks based on Agile maturity and more vendor solutions.

In the meantime, if you haven’t done so already, I recommend you visit our Agile Knowledge portal for the best recorded talks, customer experience reports and product tips to help you and your team become experts at scaling software agility. In the upcoming weeks, we will provide you with the recorded versions of our coaches’ Agile 2006 talks, links to the beta and GA version of Rally’s open-source, Eclipse-based Agile Planner and an invitation to our new Agile Commons.

In March I wrote about how Theory of Constraints (TOC) maps to software development. It turns out Scrum is a great engine for applying TOC to a software company. Here's why.

For those who haven't read The Goal, Eli Goldratt's first novel on TOC, the approach focuses on maximizing throughput of a system by finding bottlenecks and optimizing the system's performance around those bottlenecks. Imagine yourself walking into a manufacturing plant - how do you find the bottlenecks? It's easy - the bottlenecks have piles of inventory in front of them.

People in all kinds of businesses read The Goal with enthusiasm but then got stuck. If your business isn't manufacturing it's not quite so easy to spot the bottlenecks.

What if your business is software, or marketing, or organizational change? Goldratt's second book, It's Not Luck, is a huge help with this. The book presents two tools: the Current Reality Tree and the Future Reality Tree. Used in combination, the tools enable you to model the "manufacturing plant" of problems you're trying to solve, zero in on the core problem, and begin optimizing your throughput.

This approach actually works quite well, although it's quite time-consuming. I've applied it on a few projects with good results, but it always seems to take days of mapping to work everything out.

What's exciting about Scrum is this: Scrum harnesses the collective intelligence of the entire team to identify and elevate constraints in realtime.

Remember that Scrum is a process framework intended to get organizations unstuck. Through its inspect and adapt mechanisms, Scrum tends to find your current organizational problems and throw them right in your face. (Many people adopt Scrum without realizing that this is going to happen; often it causes a big problem in organizations that are not prepared!)

In Scrum's daily standup meeting, each individual reports on what are the obstacles standing in the way of delivering value. Many of these obstacles are resolved right away; some need to be escalated. With a working Scrum-of-Scrums meeting following the individual Scrum team standup meetings, the escalated obstacles are consolidated and handled, providing a realtime mechanism for bottleneck optimization.

Sometimes these obstacles can't be resolved right away, because they're too big. Also, remember that Scrum teams hold a retrospective at the end of each 2-4 week Sprint. These retrospectives also identify obstacles that may require more work to resolve.

These longer-term obstacles are the bottlenecks or constraints that TOC would be looking at. Through the natural Scrum process, these constraints are identified, elevated, and optimized, without the work of building elaborate trees to model them. It's usually good enough to take each obstacle and ask "Why" five times to find the root cause; good Scrum teams will generally do this as a matter of course.

This is why Scrum's so exciting - it's not a process so much as an organizational optimization mechanism.

This post turned out longer then I had anticipated, so I'm breaking into several posts.

Being a leader in any area often brings questions of "How do you do it?" Our sales team and technical account managers are often asked about our tooling. Some questions are about our development tools, but mostly it's about test tools. So I thought I spend some time talking about the tools we use.

I'll start this from the bottom up, making broad strokes over the development tools.

Development

We're a Java shop, and our architecture reflects that. We have a pretty traditional J2EE stack:

• RedHat Enterprise Linux is our deployment platform
• Oracle serves as the persistence tier
• Oracle's TopLink is the Object/Relational mapping layer for our domain model
• Stateless session beans provide a Service Layer on top of the domain
• Spring MVC and (some) Spring Web Flow provides the foundation of the Application tier
• JSP and Javascript form the presentation layer
• JBoss is the EJB container

All in all pretty straightforward. Most of the developers prefer Intellij Idea, a few use Eclipse. A vast majority develop on Macs, with the remaining on Linux.

Next I'll be talking about the testing tools we currently use and a bit about those we've tried and discarded.

Pete Beherns at Trailridge consulting has just put up a new survey on Agile tools. Please join in to help steer the industry towards positive solutions. (http://trailridgeconsulting.com/surveys.html)

On the Trailridge home page you will see this introduction:

“What Tools Enable Your Agile Process?
We are interested in knowing what tools your team and organization use to enable, manage and scale your agile process. Survey closes by October 31, 2006."

On the Survey page, Pete writes;
The Agile Manifesto states: “Individuals and Interactions over Process and Tools”.
This survey is seeking to identify the Process Lifecycle Management Tools teams and organizations depend on to enable, manage and scale their agile process. This survey is only intended for teams implementing an agile process. For this survey, a process is defined as Agile if it is implementing some form of Scrum, XP, FDD, DSDM, Crystal or combined process.

This survey is not attempting to identify whether or not your team is “Agile”, but rather what types of tools your organization uses and depends on to enable, scale and maintain your agility.

This survey is independent from any particular tool vendor and is not intended to be used for marketing purposes for any particular vendor.

This survey contains only 16 questions and should take you less than 5 minutes. Completing this survey will enter you into a drawing to win an iPod shuffle.

You are invited to participate and asked to help retain the integrity of the survey data through honest responses. If you consult with multiple organizations, or know another organization implementing an agile process, you are encouraged to invite them to fill out this survey.

For questions, comments or feedback, please contact pete@trailridgeconsulting.com

I took the survey in about a little less than 5 minutes. There is only one open ended, essay like question and it is for providing survey feedback. Take it! It’s painless.

So my husband gave me a really cool gadget for my birthday two weeks ago (as if I needed another). This one is really cool: a Garmin Forerunner 305, which is a GPS wristwatch that allows a person to track time, distance, heart rate, calories burned, etc. An off-and-on runner, I once experienced the rush of endorphins when completing a five-mile race two years ago; I’ve always dreamed of running a half-marathon and sometimes can be seen in airports with Runner’s World in hand. It’s one of those activities that I truly wish I had more time for.

I went out for a run today. The introvert’s perfect sport - I took off with iPod in tow, Forerunner strapped to my wrist, heart monitor around my rib cage. As I started ambling up the hills and sprinting down the valleys, I began to think what a nifty thing it is to look down at my wrist and monitor my progress. I could see my heart rate which let me know if I was about to have a heart attack :), I could see how far I’ve gone (instant gratification!) and I could measure distance against my time.

Then I started thinking: what a cool thing it is that we have tools that help us ‘see’ how we’re doing. Up until I got the Forerunner, it was always an educated guess as to how far or how fast I had run, and sure, I could always stretch it a little. I am sure many four-milers were really three-point-something-or-another.

Here are a few thoughts I had about running and being on an agile team.

- Fuel. I’ve noticed a direct increase in performance when I am properly fueled. Fuel consists of food, water and motivation. On an agile team, a team member is fueled by a common goal, a paycheck and other incentives.
- The Course. This would be synonymous with the goal of the team. A team that doesn’t have a goal is just hanging out. I could keep running and running, but to where? And why?
- Quality. I thought about this one for awhile. How would I measure the quality of my run? Then it dawned on me: it’s my heart rate. How am I physically withstanding the challenges of the goal? Is my heart rate sustainable? Am I going too fast and pushing my heart to a point that is not healthy? My heart rate tells me when to back off. Too high, I need to slow down or find a flat run. Too low and I'm not challenging myself enough.
- Pace. Is it sustainable? Am I embarrassed by it or is it going to cause a shin splint tomorrow?
- Skillset. Obviously I’m no Olympic contender. Can someone like me realistically think that a two-mile run is possible? Am I nuts? Agile teams must have the skillsets necessary to complete the goal, or be prepared for lots of
conditioning (ramp-up).
- Tools. How do you know to make adjustments in your pace if you don’t know what your pace is? Well, in running I can certainly use intangibles such as breathing too heavy, dizziness, weakness, etc., but knowing my heart rate and trying to level that out was key in not burning out too quickly today. My little wrist gadget made it possible for me to know exactly where I stood (or ran, I suppose). And what’s really cool is that when I got home I connected it to the computer and viola! Now I can study my progress on a day-by-day basis, looking at data such as speed, heartrate, elevation, etc. See the graph of speed/heart rate below. It’s easy to say, “oh yes, I ran exactly 2.09 miles. My heart rate increased at the end because of the big hill and fatigue. Next time, I’ll run the course backwards to get the big hill over with first...” You get the picture. Obviously, the tools I choose are there to support my run, and I still have to use common sense. My tools consist of: running shoes, GPS, iPod, heart monitor, running log, comfy clothes and the landscape. What tools do you use? Are they overkill or are they supporting your sprint?

This evening’s run transformed me. I have decided to take up running – seriously this time. My goal is to run a five-mile race in October or early November in 45-50 minutes, which is a serious increase in my pace (like I said, I’m no Olympic contender!). Posting my blog will keep my progress visible and provide me with a locale for notes, thoughts and challenges. Funny how making this visible to the world really makes me take a deep breath and realize how accountable I must be now.

For now, I am going to sit back and enjoy these endorphins. Stay tuned…

My Garmin Forerunner 305

Your beloved coach with iPod & 305

Motivation to get outside

Even though I’m heavily involved in the agile community – a community that stresses the importance of a sustainable pace – I continue to witness both my clients and my colleagues struggling with their workloads. Whether it’s a desire to please, or a fear of being labeled as unhelpful, or simply a passionate interest that drives them, these bright and focused people consistently over-commit themselves.

This reoccurring pattern of being unable or unwilling to say no has truly vexed me, so much so that I wrote an article for Better Software magazine on this subject. I treated it lightly in a fictionalized piece called “In Search of Commitment Clarity,” but the topic is a serious one for me. (Read “In Search of Commitment Clarity” here: http://www.stickyminds.com/s.asp?F=S11712_ART_2)

I’ve never had trouble saying no. I’m sure if my mother were still alive she’d be happy to tell stories about how I practiced this art by saying no to her repeatedly! So I was lucky enough to learn the fine art of saying no at an early age, and as I grew into adulthood I gradually learned how to say no with some tact, so it didn’t sound quite so harsh.

Why can’t others say no? I’ve asked this question of many people over the past year as I try to better understand the issue. Some of the answers I’ve received include “We’re not allowed to say no here,” “I’m afraid I’ll get fired if I don’t do what they ask me to,” “It just never occurred to me that saying no was an option,” “Saying no is not acceptable in my culture – it would convey a lack of respect,” and “I really want to do this, even though it’ll kill me.”

Based on these conversations, I’ve come to the conclusion that there are two types of people with “saying no” problems: those who want to say no and can’t figure out how to do so safely and respectfully, and those who don’t want to say no because they don’t want to miss out on anything.

I can’t help those who don’t want to say no, but I would like to find a way to help those who do want to say no. It seems to be a matter of conquering fear and/or feeling safe, coupled with learning the right ways to say no – ways that don’t shut down conversation and aren’t offensive.

I’ll be pulling some exercises and recommendations together around these ideas, and I would love your help, gentle reader. Share some of your experiences with us here on this blog! Why can’t you say no? Do you wish you could learn how to? If you have no trouble saying no, tell us how you learned to do this. Was there ever an epiphany that helped guide you in offering up “no” as needed? Was there a book or article that really helped you in this respect? I’d love to hear your comments and learn from your experiences.

Testing the Process

A tool is only useful if you have a plan on how to use it. A circular saw is a powerful tool; without a goal in mind, it can do great harm. Our choices in tooling reflected the process decisions we made about testing.

Testing is one place where we’ve experimented the most, both with testing in our process and tooling. Early on, our thinking about testing was influenced the most by Mike Cohn. Two things that Mike said had a profound impact on our world view with respect to testing (I’m paraphrasing here):

1. Those things you never have time to finish (in the iteration), do them first.
2. Focus your testing energy proportionally based on the testing pyramid.

Putting testing first in the process forced us to change the conversations in our iteration planning meetings. Instead of “How are we going to build it?” we moved to “How are we going to test it?”. This conversation involved everyone on the team, product owners, development, and testers. The outcome of this conversation was a list of tests modeled on the “testing pyramid”.

Mike Cohn’s “testing pyramid” describes a model for how much effort should be put towards each of three testing areas; Unit testing, Business Rules, and GUI.

Unit testing is the “bottom” third of the pyramid. It’s the largest part of the pyramid, by volume, so most of your energy should be focused there. Unit tests are the easiest to write and maintain.

The middle third of the pyramid should be “business rule” testing. These are the things that the product owner and the business are most interested in. Validate the business rules in your application using tools like Fit or FitNesse (more on those later).

The top third being the smallest, by volume, is reserved for GUI testing. This is not functional testing through the GUI but a validation that the GUI is behaving as intended. For example, don’t test that when a button is pressed that the record is written to the database, rather test that the button called the correct function (that ultimately writes the record to the database).

For each story we identify all tests necessary for acceptance. Unit tests, business logic tests, GUI tests, functional tests, performance tests, and manual tests may be included in the scope of work for a given story. Some stories only have unit tests, others may have more functional tests; but for everything that makes sense, we automate.

Next I’ll be talking about our testing tools, I promise!

On the second day of a recent CSM training I was conducting, I decided to hold an exercise to test how well the previous day’s teachings had taken hold in the attendees’ freshly Scrum-laden minds. The group broke into teams and selected one question card from a deck of Scrum questions I provided. Their goal was to answer the question in the form of a presentation to the rest of the group. I was specific in that I did not care how they chose to convey the answer. They could sing a song, do a dance, perform a play, create a flipchart drawing, give a lecture, or whatever else they might feel inclined to do.

The team that picked the question “What is the Scrum framework?” decided to do a brief play. It was very creative and was one of the more interesting visual representations of Scrum that I’ve seen. I wish I had videotaped it! Here’s how it went:

One fellow standing to the side of the “stage” says: “I am a ScrumMaster. I would like to do Scrum, but first I need some very important things. Oh, if only I had a vision!”

A woman holding a sheet of flipchart paper turned sideways that reads “VISION” in giant letters dances across the floor.

ScrumMaster: “Oh good! A vision! Now if only I had a Product Owner who could share this vision with a team!”

A man holding a flipchart paper that reads “BACKLOG” in giant letters strolls coolly across the floor and stands next to the Vision.

ScrumMaster: “Great, I have a vision and a product owner and a backlog! Now all I need is a team to do the work.”

A man steps forward and waves his arms around in the air.

ScrumMaster: “Wonderful – I have everything I need to get started! I guess we should have our Sprint Planning Meeting now.”

The ScrumMaster, Product Owner, Vision, and Delivery Team stand in a circle. The Product Owner tears off a small slice of the BACKLOG flipchart paper – essentially shearing off the B – and hands it to the Delivery Team. The Vision dances around them both as this is occurring.

The Delivery Team takes the strip of paper and starts ripping it into smaller pieces – the tasks! Once this is complete, they all commit.

ScrumMaster: “We are underway! Let’s check in now with our daily stand-up.” They hold a brief stand-up. Everyone is deliriously happy with the progress.

(At this point the play ends – the team had forgotten about the Sprint Review meeting. So instead I’ll make up the perfect ending to this play…)

ScrumMaster: “Our sprint is over! It’s time for our Sprint Review meeting!"

The ScrumMaster, Product Owner, Vision, and Delivery Team stand in a circle around a laptop. The Delivery Team pushes a button and waves his hand.

All: “Ooooooh! Aaaaaaaaah!”

Product Owner: “I accept this!” Everyone shakes hands.

-The End-

I loved the way the Vision continually danced around all parties during the play, and the way they used the flipchart paper to represent smaller and smaller chunks of work. It was a quick and simple abstract of the Scrum framework and worthy of a Tony award! I’m hoping that at our next Scrum Gathering (May 2007 in Portland, OR) we’ll be able to recreate this and film it. So mark this on your calendars and practice your lines – we’ll be looking for volunteers to play these parts!

In the meantime check out the contribution from the November Scrum Gathering’s Scrumotions team to increasing Scrum awareness on YouTube: http://www.youtube.com/watch?v=B3htbxIkzzM

Proving the need for another Agile survey, TrailRidge Consulting recently completed a survey of 550+ international respondents who currently practice Agile software development and use a tool. (And yes, for full disclosure’s sake, TrailRidge is a Rally partner.)

One of the most interesting findings: Over 40% of firms are now choosing to use specialized “Agile” tools instead of more traditional vendors that have ruled the software roost for over a decade. In contrast, traditional tools for requirements management, item workflow tracking and project management tools only get used around 10 to 20% by respondents. I suspect this figure was only that high because most teams used multiple tools.

The reason for selecting Agile project management (APM) tools varied between large and small organizations, but both groups put these three criteria in their top five:

- Faster and more efficient
- Matches Agile process
- Traceability and tracking

Given these reasons for selecting a tool, it's obvious why respondents have passed over the traditionally large, waterfall-oriented tools from incumbent vendors like IBM, Mercury, Borland and Telelogic:

- Not fast and efficient
- No matching Agile processes
- Cumbersome traceability

Not to mention the total cost of ownership in buying, installing, training and maintaining these products. As the survey predicts, “APM tooling adoption will continue to rise.”

Of course the story gets worse for incumbent vendors. As Agile teams mature, the need for speed, visibility and Agile enablement increases.

For those of you who have already read and digested this survey, I’m sure there is yet another question on the tip of your tongue (or keyboard, as the case may be). In an Agile tooling survey, how did Rally fare? Not surprising to us, Rally was selected as the #1 provider for large enterprises, but not for small teams. At Rally, we are building a whole solution to help you be successful at Agile with a time-proven approach to adopting Agile in small, medium and large-complex organizations. But I think the true reason Rally was selected as the preferred provider for large organizations is that only Rally’s combination of Agile Lifecycle Management and Agile Product Management solutions can deliver a tooling solution that addresses the needs and complexities of large software organizations.

In our case studies on BMC Software and Shopzilla, you can hear how this whole solution approach helped them deliver Agile success.

If you're currently practicing Agile (or even if you're not), this recent survey from Trail Ridge definitely qualifies as recommended reading.

When teams start using agile practices to deliver software, they often start with an attempt to squeeze a waterfall into two or four weeks. The iteration starts with work for an analyst (or architect), then design takes place, and the code gets developed. Near the end of the iteration the features are tested (system or integration test) and are accepted by the product owner.

This is a good example of the V model shown below, which is the foundation for the waterfall methodologies of this world. The model illustrates a downfall of a waterfall approach: the earliest decisions (architecture) are tested last. We all know when we don’t want to discover flaws in our system - at the end of the delivery process. Looking at the V model, it is clear how to solve this problem of late issue discovery - by folding the V into an I or moving the testing forward in time.

The result is an I-model as pictured below. Instead of writing analysis or architecture documents, the involved team members write acceptance tests for the desired features. The same happens during the design stage; system tests are written to specify the desired behavior of the new features. And the developers: they move to a Test Driven Development approach, as described by one of the 12 Extreme Programming (XP) practices.

Through this approach the analysts, testers and designers have a role earlier in the delivery process, and their knowledge gets used for more purposes (just think how much system knowledge every tester has stored in their test cases). And they provide the delivery team with requirements that are formatted for optimal use: tests cases. When the delivery team delivers features that pass all these tests, then they know they are done with coding the feature. Through this approach problems are discovered as early in the delivery process as possible.

And the characters show another advantage: the width of a V is more than an I, or, acceptance test driven delivery goes faster then mini-waterfalls.

My name is Bob Cotton, Test Architect at Rally Software. I'll be posting here periodically explaining how we do testing and test automation.

I came to Rally about 2 1/2 years ago from a another SaaS company where I was the system architect on a high transaction hotel central reservation system. Until recently my role at Rally has been the Engineering Manager, with test and development reporting to me. Which such a great team, there isn't much "managing" to do, so I contributed in other areas. I am a member of the Product Management team, I act as a technical sounding board for the developers, I collaborate with our operations team on the production systems, and, to keep my geek on, I've helped design and build several incarnations of our GUI test automation system.

As we all know, test automation is a difficult problem, both technically and organizationally. Having someone who can can be a champion on both fronts can be quite an asset. While we were looking for that ever elusive tester-who-can-code who would own our automation solution, I finally started believing my own words, "This is a great career opportunity, anyone who can own the test automation space can write their own ticket".

One of Rally's core values is "Create your own reality". If there's something that you are passionate about, the company will help you to pursue your goals, within reason of course. So I stepped up and "applied" for the position. I had been working on our test automation for some time, so it was a natural fit. Rally, of course, agreed and we decided that the position's responsibilities would include writing about our experiences with testing and test automation. This position holds the title Test Architect.

I will be describing the testing journey we've been on here at Rally. I will also be explaining the more technical aspects of our test automation framework in my personal blog, Test Architecture (http://www.testarchitecture.com/blog), I hope you will join me.

Rally is participating in the following recruiting event. Please swing by if you can!

Join Rally Software, along with StillSecure, Me.dium, Newsgator and Gold Systems for a high-tech recruiting event on the Front Range. Rally, StillSecure, Me.dium, NewsGator and Gold Systems are leading their industries in terms of innovation and growth and are funded by our community's most prestigious investors. These five Boulder/Denver area companies are currently looking for people who are enthusiastic about technology, enjoy the energy of a start-up culture and can deliver results. Meet hiring managers, make some local connections and maybe find the job of your dreams. Positions are open in: Sales, Marketing, Engineering, Services, Support and Accounting.

Event Logistics:
Wednesday, March 7
5:30 – 7:30 p.m.
Westin Westminster

Process and Questions:
Arrive anytime between 5:30 and 7:30 p.m. on March 7. Tables will be set up to meet with representatives from Rally, StillSecure, Me.dium, Newsgator and Gold Systems. Please bring plenty of copies of your resume and any other relevant work samples; registration is not required. Business attire is recommended, and tea, coffee and light snacks will be provided.

Participating Companies:
- Rally Software – Voted the best tech company to work for in Colorado, Rally leads its industry by providing tools and coaching services for Agile software development – one of the fastest-growing trends in the technology space. Search open positions at Rally.

- StillSecure - Ranked #12 on Deloitte's Technology Fast 500 Rising Star list, StillSecure creates network security software products covering network access control, vulnerability management and intrusion detection/prevention. Search open positions at StillSecure.

- Me.dium – One of the most blogged about Colorado tech start-ups, Me.dium has developed a window that reveals the hidden world of activity behind a browser, allowing people to see their online world for the first time. Search open positions at Me.dium.

- NewsGator – Headquartered in Denver, NewsGator is the world’s leading RSS company and develops and markets its RSS aggregation solutions for individual end users, enterprises and online content providers. Search open positions at NewsGator.

- Gold Systems – Since its founding in 1991, Gold Systems has been hailed as one of Colorado’s biggest high-tech successes, and its software has helped automate more than 1 billion telephone calls around the world. Search open positions at Gold Systems.

For additional questions, email jobs@rallydev.com.