Zach Nies brings close to 20 years of engineering and product development experience to Rally’s innovative products. Prior to joining Rally, Zach served as Principal Architect and Director of Systems Architecture for Level 3 Communications and founded a small start up which was quickly acquired by the publicly traded Creo, Inc, now a division of Kodak. He also served as Chief Software Architect at Quark, where he provided the overarching technological vision for the company. Zach’s product vision has won numerous industry awards, including Jolt Product Excellence awards, Seybold HotPicks and the prized MacWorld Best of Show. Zach has served on standards bodies such as the W3C's HTML working group and currently serves on the board of directors for Agile Denver.

Q: How does Rally do release planning?

Zach: To prepare for release planning, we have a Product Council process to involve the business in our planning cycles. The Product Council is made of stakeholders across the business and helps the Product Owners with the prioritization of backlog items. This is a key feedback loop where the business can be part of the release and roadmap planning cycles.

We release every eight weeks and for each product line, there is a four meeting cycle for the Product Council. This includes a retrospective meeting, a meeting where everyone brings in their business cases for a specific feature or enhancement, a presentation of design continuums for epics, and finally, a presentation of the release backlog. The product backlog from the final presentation goes into release planning. For release planning, we follow the agenda recommended by our Services team and our Uber-ScrumMaster facilitates it.

The high-level agenda includes:

1.       The teams are presented, along with any other commitments individual team members might have during the release, such as vacations or upcoming time off.

2.       Issues and impediments that would hamper team’s ability to make commitment to the release are presented and cleared.

3.       All Product Owners present backlogs for each Scrum to each team.

4.       Metrics and the definition of “done” is established and agreed upon.

5.       Release date and iteration time boxes are agreed upon.

6.       Teams then go off to map out the backlog against iterations in release.

7.       Once the teams have met separately, all teams come back together and each team presents to the whole group to show how a story is laid out across iterations.

8.       Each team identifies dependencies, conflicts or issues of how stories are mapping out across their iterations.

9.       All dependencies and issues are cleared out, and stories are potentially moved around as needed.

10.   Fun event for release is then decided upon. Past events have included Wii bowling, poker night and a foosball tournament.

11.   The entire team commits to the release plan with a “fist of five”.*

12.   Finally, a retrospective on the meeting is completed.

During the release, Product Owners are working to prepare for the next release. The Product Council is where the planning and preparation that the Product Owners have completed is presented to the business.

Q: How do you do long term planning (i.e. roadmap)?

Zach: Product Line Managers build a rolling twelve-month roadmap. Then, Ryan (Rally’s CTO) and I look at the alignment of the product lines and ensure we are optimizing for the whole of the business. This happens each quarter in conjunction with Rally’s quarterly business planning cycles.

Annual business planning and quarterly planning cycles serve as the feedback loop for the planning we do for the product.

Q: How large are your teams at Rally?

Zach: We have teams of seven, plus or minus two, so Scrums are never bigger than nine.

Q: How does QA work with engineering? How are they organized?

Zach:We have one manual tester on each Scrum. This person is responsible for manual walk throughs of the application in a way that represents the end user. But, it is important to note that everyone on the team is responsible for quality. All engineers write unit level tests, along with automated functional testing. PO’s, testers, and engineers all conduct manual end to end testing of functionality.

We bug bash at the end of every iteration. During our bug bash, a person from one scrum pairs up with a person from another scrum and they get together to test new functionality built during the iteration. At Rally, we have a zero defect mentality and we always try to fix bugs before working on new functionality. Having fully tested software without any bugs is part of our definition of “done” for new work.

Q: Does Rally do TDD (Test Driven Development)?

Zach: Yes, you can find out more information on this in the interview with Bob Cotton.

Q: Do you use points or hours?

Zach: We estimate in points for stories. Points are a relative estimate of size, not duration. In order to get accurate estimates for future work, relative size is more important than duration. We then estimate tasks in hours.

Q: As an Agile organization, what is your PO (Product Owner) team’s biggest challenge?

Zach: I would say their biggest challenge is balancing all that there is to do – the preparation cycle getting ready for next release, the preparation cycle for the next iteration, the day to day interaction with engineering and making sure they are not blocked by anything, and working with the whole team to make sure what is being built maximizes customer value. The PO’s put in a lot of time and energy balancing stakeholders’ desires – the business and the users. Here at Rally, we receive a lot of feedback from users on Agile Commons and from customers through RPM (Rally Product Manager). We use RPM heavily to help us prioritize and manage our backlog.  In a way, Product Owners have to ‘slice’ their brains between different members of the team and different time scales.

Q:  Any other tips, hints, or best practices for VP of Products or Product Owners?

Zach: I would recommend that they listen to our most recent webinars on being a Product Owner on an Agile team and on Product Management. I would also stress that it is important to have a Product Council or some sort of structured way to align the feedback of the users, the business and the development team.

*Fist of five:  Simple dispute resolution technique (used in a non-threatening environment) under which members of a group raise fist (to indicate a value of 0, or disagreement) or one or more fingers (to indicate values from 1 to 5) to express their level of agreement with a proposed solution, or understanding of a problem.

1. One finger = serious concerns that have not been heard or addressed
2. Two fingers = still have unaddressed concerns
3. Three fingers = consent with major reservation
4. Four fingers = consent with slight reservation
5. Five fingers = full consent