It's not a coincidence that the RallyON welcome reception has a three-ring circus theme. The circus part seems natural, given the challenges in herding people, process and technology (another three) to align toward a common objective. Transforming into an Agile organization takes the skills of a lion tamer, the orchestration of a ringmaster (hello, ScrumMaster!) and the acrobatics of the high-flying trapeze performers. But when it all comes together, the energy is palpable. The crowd oohs and ahhs, and all are amazed. OK, so perhaps a bit dramatic for real-world Agile, but many have witnessed faster delivery and more motivated people with high-performing Agile teams.

Setting aside the circus metaphor, let's look at the number three. For this year's RallyON, we centered on where organizations derive value: people, the largest source of intellectual property, the processes that drive effectiveness, and the technology that facilitates communication, collaboration and visibility. Threes abound.

And, as the wise say, good things come in threes, so it's no coincidence that RallyON is also three days long. Three days of in-depth technical sessions, Agile 201 training from our Rally experts, practitioners sharing their stories of success and the obstacles they met along the way, tracks dedicated to transformative Agile in leadership and collaboration, and an open space marketplace where visionaries meet to exchange ideas and innovate. We'll come together to learn and contribute -- and walk the tightrope that is the path to an Agile organization. Come join the circus, at least for one night.

Rally Software

1. The Scaled Agile Framework®, or SAFe, provides a recipe for adopting Agile at enterprise scale.  It is illustrated in the big picture.

As Scrum is to the Agile team, SAFe is to the Agile enterprise.

2. SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale.  It is field-tested and enterprise-friendly.
3. SAFe is the brainchild of Dean Leffingwell.

As Ken Schwaber and Jeff Sutherland are to Scrum,
Dean Leffingwell is to SAFe.

4. SAFe is based on Lean and Agile principles.
5. There are three levels in SAFe:
   * Team
   * Program
   * Portfolio

At the Team Level:

6. Scrum with XP engineering practices are used.
7. Design/Build/Test (DBT) teams deliver working, fully tested software every two weeks.  There are five to nine members of each team.
8. Rally’s weekly TeamStart webinar series covers the basic practices at the team level.

At the Program Level:

9. SAFe defines an Agile Release Train (ART).  As iteration is to team, train is to program.
10. The ART (or train) is the primary vehicle for value delivery at the program level.  It delivers a value stream for the organization.
11. SAFe is three letter acronym (TLA) heaven – DBT, ART, RTE, PSI, NFR, RMT and I&A!
12. Between 5 and 10 teams work together on a train.  They synchronize their release boundaries and their iteration boundaries.
13. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI).  A demo and inspect and adapt sessions are held.  Planning begins for the next PSI.
14. PSIs provide a steady cadence for the development cycle.  They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.
15. New program level roles are defined
    * System Team
    * Product Manager
    * System Architect
    * Release Train Engineer (RTE)
    * UX and Shared Resources (e.g., security, DBA)
    * Release Management Team
16. In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles.  If they have deep domain expertise, they are likely to fill the Product Manager role.  If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.
17. SAFe defines a Scaled Agilist (SA) certification program for executives, managers, architects and change agents responsible for leading SAFe implementations.  Rally provides regular public and private Leading SAFe certification classes.
18. SAFe makes a distinction between content (what the system does) and design (how the system does it).  There is separate “authority” for content and design.
19. The Product Manager (Program Manager) has content authority at the program level.  She defines and prioritizes the program backlog.
20. SAFe defines an artifact hierarchy of Epics – Features – User Stories.  The program backlog is a prioritized list of features.  Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level.  Features decompose to User Stories which flow to Team-level backlogs.
21. Features are prioritized based on Don Reinersten’s Weighted Shortest Job First (WSJF) economic decision framework.
22. The System Architect has design authority at the program level.  He collaborates day to day with the teams, ensuring that non-functional requirements (NFRs) are met.  He works with the enterprise architect at the portfolio level to ensure that there is sufficient architectural runway to support upcoming user and business needs.
23. The UX Designer(s) provides UI design, UX guidelines and design elements for the teams.  In a similar manner, shared specialists provide services such as security, performance and database administration across the teams.
24. The Release Train Engineer (RTE) is the Uber-ScrumMaster.
25. The Release Management Team is a cross-functional team - with representation from marketing, dev, quality, ops and deployment – that approves frequent releases of quality solutions to customers.
26. Rally’s monthly Program webinar series provides an overview of Scaling Agile Programs with SAFe.

At the Portfolio Level:

27. PPM has a central role in Strategy, Investment Funding, Program Management and Governance.
28. Investment Themes drive budget allocations.
29. Themes are done as part of the budgeting process with a lifespan of 6-12 months.
30. Portfolio philosophy is centralized strategy with local execution.
31. Epics define large development initiatives that encapsulate the new development necessary to realize the benefits of investment themes.
32. There are business epics (customer-facing) and architectural epics (technology solutions).
33. Business and architectural epics are managed in parallel Kanban systems.
34. Objective metrics support IT governance and continuous improvement.
35. Enterprise architecture is a first class citizen.  The concept of Intentional Architecture provides a set of planned initiatives to enhance solution design, performance, security and usability.
36. SAFe patterns provide a transformation roadmap.

  Legacy Approach Lean-Agile Pattern

#1

Centralized control

Decentralized decision-making

#2

Project overload

Continuous value flow

#3

Detailed project plans

Lightweight business cases

#4

Centralized annual planning

Decentralized, rolling wave planning

#5

Work breakdown structures

Agile estimating and planning

#6

Project-based funding

Agile Release Trains

#7

Projects and PMBOK

Self-managing teams and programs

#8

Waterfall milestones

Objective, fact-based measures and milestones.

Table above reproduced with permission of Leffingwell LLC and Scaled Agile Inc

37. Rally’s monthly Portfolio webinar series provides guidance on Lean | Agile approaches to PPM.

Adoption

38. Adoption focuses on identifying a value stream.  A value stream is a sequence of activities intended to produce a consistent set of deliverables of value to customers.  Value streams are realized via an Agile Release Train (ART).
39. SAFe poses questions to help identify value streams (ARTs):
    * What program might adopt the new process the fastest?
    * Which executives are ready for a transition?
    * What are the geographical locations and how are the team members distributed?
    * What programs are the most challenged, or represent the biggest opportunities?
40. When you identify a value stream, you go “All In” and “All at Once” for that train.
41. Rally is an SAI Gold Partner.  Rally’s cloud-based solutions for managing the Agile development lifecycle directly support SAFe.  Read two independent analyst reports that show why “Rally Software continues its leadership in Agile/Lean.[1]”

[1] The Forrester Wave™: Application Life-Cycle Management, Q4 2012

.content td { padding: 2px 6px; } ol li { margin-bottom: 13px !important; } .safe-table th { background: #444444; font-size: 13px; color: #fff; border: 0; padding: 8px 0 0 8px; } .safe-table td { padding: 11px; background: #f4f4f4; border-top: 3px solid #fff; border-left: 3px solid #fff; } .safe-table td.first_col { border: 3px solid #fff; } .safe-table td { font-size: 13px; color: #444; margin-bottom: 8px } .safe-table td p { margin-bottom: 3px; } Rob Pinna

Countdown: 17 days until RallyON!  As we get closer to the event, we are knee-deep in content (and planning a welcome reception that will knock your socks off). We're refining the sessions and how they map to our overall themes of people, practice, and technology. This year's conference adds a new focus on Rally's platform, and how to optimize up and across the organization.

People - What makes an Agile leader different? What kinds of trade-offs are involved in their decision-making? Find out as Rally's Tim Miller and Christopher Avery explore what it means to consciously lead an Agile organization.  Also find out Jean Tabaka's "secret sauce" that Agile heroes use to keep their world in peace and deliver at scale.

Practice - One of our customers is presenting "Beyond Swarm Soccer," and the name says it all. Are we all chasing the ball, or do we work in concert across the field? Also, as Agile practitioners, how do you know when you're getting better? Applying extensive research, we've identified the Seven Deadly Sins of Agile Measurement, and will discuss which metrics matter.

Technology - We're taking a technical deep-dive this year by sharing lessons learned from both our customers and our own use. Sessions include product development using a build-measure-learn process, creating the most useful and used dashboards, and managing complex QA and test automation.  Our own engineers take center stage to discuss Rally's approach to building Lean product experiments and how we apply that to our product roadmaps.

There are too many great sessions to choose from, so bring a colleague -- or seven -- to share the learning.  We’ll see you next month in Boulder.  

Rally Software

Since Rally launched Rally Portfolio Manager in Dec 2011, I have worked with many PMOs, program managers and portfolio managers who ask: How can I adopt Rally’s portfolio management solution when I already have a PPM tool?

The answer: Use a Rally--PPM tool integration.  But what does this look like, and what does it provide?

Integrations ensure your PPM dashboards keep their value.

As Gartner stated at their PPM and IT Governance Summit last year, there is not a “ one size fits all” solution in the portfolio management world right now. That world is experiencing a major disruption and until it settles, which likely will take years, PPM providers have to play well with one another for the sake of providing you with comprehensive solutions that provide real value.

Here is one example. Agile continues to grow as a standard for project management. So portfolio dashboards must include Agile projects as well as traditional waterfall projects or risk losing their value. An integration with Rally would make sense here.

Which PPM vendors have partnered with Rally?

In 2011, several PPM vendors (Daptiv, Planisware, Oracle) partnered with Rally to offer an integration to Rally’s Agile solution. With the launch of Rally Portfolio Manager in late 2011, more integration possibilities arose. In 2012 Innotas created a bidirectional integration, Pervasive Software (now Actian Corporation) wrote the CA Clarity integration, and Rally’s own services group built an integration to HP PPM. The latest PPM integration was co-designed with Planview for several joint customers.

The benefits of integration are extensive.

The integration with Planview Enterprise is currently the most extensive bidirectional third-party integration to date between Rally and a PPM solution. Planview leveraged several new aspects of our free API to provide these key benefits:

1. Synchronization. The Planview integration automatically creates a matching Program/Initiative in Rally Portfolio Manager when you create portfolio initiatives or programs in Planview
2. Delivery of Valuable Increments. Focus on delivering valuable increments for the Program/Initiative (instead of focusing on being ‘on time and on budget’) by creating Features below the Program/Initiative in Rally Portfolio Manager
3. Real-time Status. As Agile teams work on implementing the Program/Initiative, portfolio managers & PMOs automatically view the progress of those Programs/Initiatives in the Planview portfolio dashboards, including the percent of work done based on actual Agile execution facts. Red-green-yellow status indicators are based on actual Agile execution,  actual start and end dates... you get the idea :).
4. More accurate cost data. If your organization is required to track software capitalization using a PPM tool, the integration synchronizes Rally’s timesheets with Planview’s timesheets so that everyone can stay productive in their own tool and avoid context-switching. The result? Your cost data is more accurate than when developers enter their time weekly or bi-weekly in a separate PPM tool.

If your organization currently uses mixed development methodologies (Agile, waterfall, iterative), then PPM / Rally integrations provide a way to adopt Agile at your pace while retaining your current portfolio dashboards. Now you can include your Agile programs in those dashboards.

See the integrations in action

Customers will present their use of the Planview and CA Clarity integrations at our RallyON user conference in June. If you are attending Gartner PPM shows late this month in the US or early next month in the UK, come on by our booth to see live demos!

Catherine Connor

I love riding 100 mph on twisty, turning race tracks -- my favorite is Laguna Seca in Monterey, California. In racing, as in business, keeping the finish line in mind is important, but if you can’t negotiate the curves and respond quickly to changing conditions along the way -- you won’t win.

In this uber-competitive technology marketplace, the pace of change is only increasing. Disruptive new technologies are changing the game. Savvy business leaders are applying key agile concepts of continuous innovation, shorter iterations, and fail early/fail fast/fail often experiments not only to the development team - but to the entire portfolio management process.

Agile is not just for developers anymore. Once considered an esoteric “thing” that software developers “did,” Agile practices have moved mainstream and are spreading across the the enterprise. Business leaders are working to engage more people throughout the entire company to make more informed decisions at a faster pace.  The demand for better business agility is especially evident for portfolio management and strategic planning that has traditionally been tied to annual planning cycles.

An Agile business will establish a much faster cadence than the traditional annual planning cycle.  It doesn’t start and stop each quarter or once per year.  Planning and preparation become a continuous flow process with a regular cadence of weekly, monthly, and quarterly events for planning, execution, and strategic decision making.

No Time to Wait: Embrace the MVP

Betting on a big-bang project to deliver new software in a 12-to-24 month development cycle is a potential recipe for failure given the current pace of change.  Even if you are trying to plan a six-month product cycle, you may miss the latest handsets and the latest tablets - in other words, you are going to be behind.

An Agile business focuses on delivering incremental value in shorter time frames.  This means each increment has to be smaller and hyper-focused on the value to the business or customer. Desired capabilities need to be reduced to Minimal Viable Features that are validated for the scenarios people want and use.  By delivering functional software sooner, you have more opportunities to get customer feedback, adjust and adapt.

In some scenarios, evidence will suggest making small adjustments - other times a major pivot may be called for. Instead of betting the whole pot up front (as in waterfall), break opportunities into incremental objectives that can be validated along the way. By embracing the concept of a Minimum Viable Product, you can get to market quickly, then refine and expand.

Visibility and feedback are critical for steering effectively and making smart decisions.  Kanban boards help people collaborate by making it easy to see the stage of planning or development key projects are in.  Simply getting executives involved to see how much work is “in flight” on a Kanban board often brings an “ah ha” about what really matters to the business. Then, everyone can agree on working on the most important things first.

Don’t Be Left Behind

A new wave of Agile transformation is changing the way businesses fund and develop projects. Business must learn to embrace agility as more than a development approach if they are to survive. Strategic planning, product and portfolio management are now recognizing that Agile offers the best chance to keep pace and win the race. Agile is becoming a necessity for businesses trying to keep current in this changing marketplace.

To learn more about how to build an Agile business, sign up for Rally’s conference, RallyON June 3-5, 2013 and attend my session on Monster Portfolios.

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Bruce Winegarden

How do you prioritize your features?  Is it a gut-feel kind of thing?  Is it based on who’s yelling the loudest?  Is it based on what drives your next big sale?  Do you do it collaboratively or alone?

In his book Principles of Product Development Flow, Don Reinertsen suggests using calculated economic models to decide what work to do first.  Specifically, he advocates an approach called Weighted Shortest-Job-First, or WSJF.  All other things being equal, the shortest job will deliver value soonest, so you should do that one first.  

But all other things are not equal - some projects reduce risk more than others, some enable other opportunities, and some are more important to your customers.   So you weight the scores - roughly, value over job size.

This approach is gaining popularity in part because the SAFe framework suggests you use it.  And it sounds great on paper.  But how does it work in the real world?

At Rally, we recently held a roadmap planning meeting with one of our product lines, and we tried a collaborative game to incorporate this economic technique into our planning session.  

We started by estimating relative job size.  Our group of 14 tech leads, product owners, and other leaders started with a bunch of stickies on a whiteboard representing value we wanted to deliver.   I asked the team to sort them by size - smallest items at the top of the board; largest at the top.  As they moved the items, they discussed each move.  People took turns, and asked clarifying questions.  

“Why do you think that one is so huge?” asked Greg, a product marketing director.  

“Because I have no idea what it means! It could be anything!” replied Ryan, a dev manager.   Together, they were able to clarify some details and get it sized, and we processed about 40 items in about 20 minutes.

As the movements slowed down, I stepped in and forced the stickies into 5 clusters.  I asked the team to correct my clustering if I had made mistakes, and they adjusted a few stickies.

We then translated them into rough cost.

I then asked the group about the smallest cluster.   “Do we think each one of these on its own could be completed by a team in significantly less than 3 months?”.  They said yes.  “How about the next group? Is that still less than 3 months?”  Yes.  “How about this next group?  Is it about 3 months, or is it more?”.  I did some simple math to figure a rough loaded cost for a team for a month, and used that to put rough dollar amounts on each size - $100k, $150k, $250k, $750, $1M+.

A couple of things about this:

1. You don’t have to be very accurate about this.  You just need a rough sense of relative size.
2. The dollar cost went up steeply for the larger items.  I wanted a dollar amount on the bigger items that would prompt fear, and then conversation about how it could be broken down.  Beyond 3 months, you have no idea how big these items really are.  But, if they’re valuable, you can break them down more.

Value Scoring

Once we had our jobs roughly sized, we used a Google spreadsheet to value score them. Dean Leffingwell and the SAFe folks recommend calculating relative scores for user value, time value, and risk/reduction opportunity enablement value for each item to get a good sense of cost of delay. But I had 14 people in the room and I figured across the group I could get similar results a quicker way.

I went with Johanna Rothman’s suggestion to let people distribute value points across all the items any way they wanted, and then explain their rationale.  

Here’s how it looked:

It’s not a ‘buy-a-feature’ activity.  Rather, each person got 10,000 points (enough to feel rich) to distribute however they wanted across all the items.  After 5 minutes, each person talked through their rationale.

This was the important part.

If Tom and Alan are using completely different rationales to prioritize, and then we just use a formula to rank our items, and that formula happens to put Alan’s favorites at the top of the list, Tom doesn’t feel heard.  The reality is that each person has a very good reason for the scores they offered.  The goal of this meeting is to have a really rich conversation about value.  I want to go beyond Reinertsen’s goal of getting our priorities right.

I want the whole team bought in to our decisions.  The conversation about the rationale helps us get there.

Then we sorted the list, highest value score first.  This was interesting - we saw a lot of obviously important items bubble to the top.  Some of them were very large.  We talked about how people felt about the results - what was missing that they felt should have been higher.  

The magical calculation

Then Michael, an internal coach, spoke up, and suggested we try a weighted-shortest-job-first score.  To do this, we divided our total value score by the cost (the value/cost column in the picture above).  A number of items that were small but valuable jumped higher up in our list.  This led to another valuable conversation

So we’re done, right?

Does the WSJF scoring solve all prioritization problems?  Do you work on items in exactly that order?  Not exactly.    We did another activity to lay out our work into our roadmap, and this led to further conversations about the capabilities of different teams, dependencies with other groups, and the like.  It’s not a perfect technique, but it was an incredibly valuable input for us.

For more on  managing a portfolio, tracking and prioritizing work according to its value, and effectively aligning business strategy with development work, join our Portfolio webinar series.

Alex Pukinskis

More than 1,000 developers across 72 events will join together on June 1-2 for National Day of Civic Hacking. Their mission? To use publicly-released data, and code to solve challenges relevant to our neighborhoods, our cities, our states and our country.

Here are 10 reasons why you should join:

1. Make a difference while building your local Agile and open source community
2. It’s only one or two days! And it might also open minds, hearts and doors to work that extends us beyond all of our “day jobs”
3. 24 data feeds and 17 federal government partners will lead to some great hackathon magic
4. President Obama and Todd Park, National CTO, are opening the White House for hacking via a lottery, and as a demo platform for the best applications
5. All this work will help the government open more data and thus create a better informed public
6. Tim O'Reilly will be proven as a prophet and general good guy for helping promote open source, open data and hacking for the last decade 
7. Get $200 off your registration for our RallyON conference by joining us to hack with the team from the National Renewable Energy Lab in Boulder
8. Your volunteering opens your eyes to the role of citizen engineers in solving the world’s toughest problems
9. Don’t have an event near you? Join a Rally team remotely using FlowDock and AgileZen
10. Support a culture of hacking that can lead to continuous innovation in your own organization

As part of our Rally for Impact efforts to help create and mobilize citizen engineers that are technically, environmentally and socially responsible, we are a proud sponsor of the National Day of Civic Hacking. Thanks to organizers like Code for America, Innovation Endeavors and Random Hacks of Kindness. And thanks to the organizational skills built by Second Muse, sites are finding great local and state resources.

Please consider joining, sharing and re-posting about National Day of Civic Hacking in your company and community

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Ryan Martens

It's been just over a week since Rally's IPO on the NYSE under the symbol RALY. We're settling back into our everyday work, and as I look back, I am again humbled to be one of the companies that trade in the public markets, and proud to be listed on the NYSE.

The morning of our IPO, I got to see Rally's logo on the front of the iconic NYSE building, I stood on the bell podium and pushed a giant green button with our founder Ryan Martens. And I toasted (with orange juice) enthusiastic employees in their offices around the world live from the bustling trading floor. 

But what struck me most throughout that day, and the days following, was the gratitude I felt. Tremendous gratitude. 

Thank you, Rally team. Rally is made up of individuals who are smart, committed and passionate. I am humbled that I get to come to work with you every day.

Thank you, customers. We work with and constantly learn from our customers and users. We continue to look to our customers as guides and partners, many of whom are helping redefine their industries through innovative software-powered products and services. We dedicate our success to date and our focus into the future to them. 

Thank you, partners, vendors and community members. Rally's ecosystem is strong and vibrant, and I know we are lucky to have those support systems all over the world.

In the midst of a lot of really hard work, we've had some fun and celebrations over the last week or so. Below are some of my highlights:

Here is a video of the NYSE opening bell ceremony:

Later I was proud to represent Rally, and our customers in talking with the media about a very special day for our company. Here's one take by our Boulder, Colorado-based Daily Camera.

Most fun for me as someone who values our culture so highly, here are a few photos of our employee celebrations that took place nearly simultaneously around the world.

Thank you for joining us on this journey, it's been – and will continue to be – a great ride.

Tim Miller

“A four-hour remote meeting with four geographies spanning and nine time zones AND I walked out more energized than I walked in.”

- Brent, product line manager in our Kirkland, WA office.

We just had our quarterly portfolio steering meeting, where we take a holistic look at our strategies and roadmaps across the company and make adjustments.   As Rally has grown, we’ve added engineering locations all around the world, and so this meeting involved engineering directors and product line managers in Helsinki, Raleigh, Boulder, and Seattle.  

In the past, I’d asked everyone to come to Boulder for a day for this kind of work, but the carbon footprint for the meeting goes way up when you do that.  And, five people would have spent a day or more in travel time.  So this time we decided to do the meeting fully distributed.

A four hour distributed meeting?  Sounds horrible, to be honest.   And I was worried about how we’d stay focused and get our work done without someone developing deep vein thrombosis from extended sitting.  But with a few of the old tricks, and a couple of new ones, we were able to make it work.  

Start with good video/audio

We’ve invested in Lifesize high-definition video units, which help a lot not only in direct communication, but also indirect - you can see when someone’s standing up, pacing around, started eating lunch, or left the room on a break.  Seeing the view out the window helps the group come together, too.   We watched the sky turn blue and black behind Otto in Helsinki, which reminded us of how late he was staying for the meeting.   We saw the sun brightening the harbor near Seattle, which reminded us that people were just getting started with their day out there.

Make content available in advance

This kind of meeting has a lot of readouts.  We did 7-minute readouts from the owners of cross-cutting strategies, and 7-10 minute readouts of roadmaps for each product line.  Some of these were available ahead of time, and we were able to spend more time discussing the topic and less time orienting around new information.  

Meetings like this are like board meetings, and Brad Feld’s advice on creating a board package is really relevant here.  Next time I’ll probably put together a package and send it out (as faciliator) rather than simply asking participants to share their content before the meeting.  We’d have had much more time for discussion if we had done less reading out.

2 conversations at a time

When I’m facilitating an in-person meeting, one of the working agreements I often use is that we should have 1 conversation at a time.  But with this meeting, we tried explicitly having 2 conversations at once - the out-loud conversation, and a parallel thread in Flowdock.  This took some getting used to, but it had some benefits.

As each person read out on their area, I asked other participants to note #surprises, #puzzles, #risks, and #dependencies in Flowdock.   This led to the following:

1. Participants often saw their own personal reactions corroborated by others, leading to ‘+1’ comments, which made it easier to discuss uncomfortable observations.
2. We didn’t have to do small group reaction debriefs.  Often there is an emotional response to a presentation that leads to a ‘need to be heard’.  Flowdock enabled us to meet that need, and that meant no further discussion was needed on many of the items.
3. We had an electronic record of these items.  For #puzzles and #risks, this produced a set of things we could easily carry out of the meeting and go forward.
4. Michael Ball, our internal coach, started noting the agenda items in the flow as we started new agenda items, so we could group the reactions by agenda item.

Also, as a facilitator, time management was easier.  As we ran out of time on a topic, I didn’t have to worry about evaluating whether the discussion should continue.  I simply said, “Ok, we’re going to move on, but whoever’s interested can continue this conversation in Flowdock.” A few people would stay engaged in typing, but usually the majority of the group would focus on the next area.  For a meeting that’s more about strategic alignment than precise agreement, this worked well.

Keeping people engaged

Whenever I sit on a call for hours, and I try to stand up, I realize I should have taken a break sooner.  With big, distributed steering meetings it’s critical to do frequent breaks - we stopped for 5-15 minutes every hour.  Set a precise time to come back together so people can plan their calls, bathroom visits, or whatever.  

When I facilitate in-person meetings, I usually use what my colleague Stephen Younge refers to as a ‘digital hat rack’ - laptops and phones get stacked on a table by the door.  You can leave your phone on, and you can answer it if it rings, but you can’t be texting and reading email the whole time.  This leads to deep engagement, focus, and participants demand more progress and effectiveness.

But for a distributed meeting, we’re stuck with the electronics.  What I found as I glanced around the room in Boulder was that everyone had Flowdock up.  Some people had it full-screen.  Others had a split-screen - half email, half Flowdock.  The Flowdock desktop client beeps as new messages come in, and this helped pull people back into the meeting; it prevented them getting completely lost in email for the most part.

The reality is that the bar is much higher in a distributed meeting when it comes to facilitation.  You have to keep the meeting focused and interesting for everyone.  There’s a certain amount of positive human feedback that happens when you’re all in the same room - you feel good and productive simply because you’re working together, even when the meeting is unfocused.  

When the group is distributed, that part gets stripped away, and you really have to make sure the work is important, people are prepared, you have exactly the right people (not too many), and that you’re making good progress if you want people to stay engaged.  Flowdock was a great help in this.  

Brent wrote later that Flowdock created  “some great dynamics: there was a balance of power with each person having a voice; conversations were focused without friction so they seemed to use time better.”  Is that what you need in your next steering meeting? It might be time to give Flowdock a try.

Alex Pukinskis

As we prepare for RallyON, our annual user conference here in Boulder, I got to thinking about some parallels in my life as a purveyor of eggs. Our Rally staff is well familiar with the dozens of eggs I bring each week from our small farm, laid by my varied chicken population. They sit in cartons at the feet of my stuffed penguin muse, Bernard. Bernard nurtures and guards those eggs like any male penguin (March of the Penguins, anyone?). But what does this have to do with a user conference? Back to the eggs, and their source: the hens that lay them.

We have several nest boxes back at Martens Farms Incorporated, each shared by the many hens that are laying eggs. Interestingly, the hens are only in the nesting boxes to lay eggs; they are purposeful in that visit. Each hen contributes to the daily egg production, and is identifiable by the egg itself. When we gather the eggs, I know that our Bantams lay the small white ones (most of their energy is put into growing flamboyant feathers), our Araucana lays the light blue ones, and the very large brown eggs are from our Orpingtons.

Where am I going with this? In our Agile practices we collaborate across roles, across functions and across projects, contributing to the common vision and organizational goals. We share nest boxes (or in office parlance, cubicles or open space) to facilitate that collaboration. And we trust and celebrate each team member's unique and valued contribution (blue eggs!). The overall Agile organism–or organization–is bettered and team members interact in ways that serve each and all.

When we come together as a cross-functional group, removing even company and organization boundaries, we all get better. We share a nest box of ideas, new ways of thinking, and open minds to the different colors of eggs in our collections. RallyON is just such a place, where collaboration is celebrated, innovation is fostered and practices are developed or re-defined. I hope you'll join Bernard and me for this year's conference, where we'll carve a new path forward for Agile leadership at scale. And who knows, maybe I'll bring over a few blue eggs.

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Ryan Martens

Before I joined Rally full time, Ryan and I sat down in 2003 and talked about what we wanted to do this time around. We had built other companies together and knew each other pretty well at that point. Though we loved very different things, we shared a worldview that was harmonious and compatible. I wanted to build a company of real scale. I knew that I wanted to have a tremendous impact on our community, on our customers, and on our employees. I wanted to build something that wasn't just a build-to-flip company.

So we created Rally. We hired our first group of developers, many of whom stood with us today, sharing our excitement on the floor of the New York Stock Exchange. Today's achievement represents a goal that was only a dream when we started.

Agile is not just about transforming the way organizations manage the software development lifecycle. It's about creating an environment where people truly love to come to work. It gives me great pride that we can have an influence on that. Ultimately, work is just part of our life.

I'm exhausted. I'm excited. I am so very thankful to all of our employees, our customers, and to everybody who has had even a small hand in supporting Rally over the years. And now I think I’m going to go to bed and sleep for 18 hours.

 

Tim Miller

We have lots of conversations with customers about how testing should work and when it should happen. Often, customers want to have an ‘in test’ state, or column on their boards. Agile coaches often cringe at this because agile approaches generally don’t prescribe a test ‘stage’ for features - the idea is that developers and testers should work together to do development and testing at the same time.

But a new pattern is cropping up on kanban boards, and I’m now comfortable saying that it’s ok to have a test column on your boards.

It just needs to be LEFT of the dev column.

Take a look at this team’s kanban board:

They work on testing before starting coding. Before a story leaves that column, they agree to:

• check existing coverage around the story
• have a conversation between dev and testers about the scenarios that matter and how they should be tested.
• identify needed usage and performance gestures.

Many of our teams have created columns like this, because putting on the testing hat before the story even begins uncovers issues much faster (and at lower cost) than waiting until after the story has started.

Before items can leave the “Dev/Test” column, the team agrees that:

• All acceptance criteria are met, or moved to another story.
• Standard Definition of Done for stories has been met
• Automated test, usage, and performance gestures have been implemented for all workflows
• A walkthrough has been completed on a local machine with a tester on the team - someone sitting within 10 feet of the developer.

When are you doing your testing? If you implemented a test column before your dev column, would you deliver value faster?

Alex Pukinskis

Agile development is all about collaboration. The writers of the Agile Manifesto value customer collaboration over contract negotiation. There was definitely a sense that we had gone off the rails - that software development had become too much about contracts and too little about common-sense, face-to-face negotiations.

But if you think about contracts, they’re really just a tool to reinforce trust. I think of the Scrum process as a series of micro-contracts. In exchange for a promise to deliver a working piece of software in two weeks, a team is given great latitude to work the way they want to work. Each time a team delivers on their sprint goal, they reinforce the trust that the business has placed in them. A track record of 25 successful sprints over a year or so goes a long way to showing that a team can be trusted.

Step up a level to the product owner, though. In a larger enterprise, many product owners are prioritizing backlogs for many teams. A product owner working with two scrum teams is responsible for a $2M annual investment. That’s significant. What’s the right way for a business to protect itself from the risk?

Contracts.

An agile portfolio contract is a lightweight thing. It’s less than a hundred words long. It defines an initiative that is meant to take 3-6 months to complete, with one or a couple of teams. It includes a hypothesis about value (“if users can get instant credit decisioning more small business loans applications will complete”) a list of 3-5 measurable success criteria (“completion rate is doubled among users who get to step 4 of the loan”) and a list of assumptions to be validated (“we can get responses from the decisioning engine in less than 2 seconds on average”). It includes a cost (1 team for 3 months).

What it doesn’t include is a detailed, locked-in feature list. The PO needs to retain discretion on the features in order to be able to negotiate scope to meet the planned end date.

There are 2 ways a PO can come out as a winner in this contract:

• Deliver the succcess criteria before the planned end date
• Raise risks within the first month and renegotiate the contract

On the other hand, a PO who plans badly, defers risky work until late in the initiative, and doesn’t let stakeholders know until a month before the end (or worse, after the end), weakens the trust the organization has put in them.

In your organization, do your POs have specific, measurable goals they’re trying to achieve? Or have you just given them a blank check? It seems like the blank check approach is more agile, but in a large organization, it’s impossible to ensure that all of your POs are making good calls all of the time. You need a basic framework to negotiate with them, and to build up that trust. PO fails to deliver on a 6-month initiative? Maybe next time they get 2 months to build their credibility back up.

At Rally, one of our core values is cultivating trust and respect. Trust is something that is continually built and rebuilt. Is your portfolio helping your POs to build trust, or are you setting them up to be less and less trustworthy?

Alex Pukinskis