This week, I attended a week-long agile training class provided by Rally. Overall, I thought the experience was positive. The company brought all of the development and product departments together for an agile overview. While many of us felt the material was remedial, there was clear value in having the same material presented to the entire software development community at once. Through exercises like the ball point game, we learned the mantra of inspect and adapt.

Some of us remained for the scrum master and product owner training. I applaud the leadership team for insisting that prospective scrum masters attend PO training, and vice versa. Since the two roles work together to fuel an agile delivery team, they wanted us to gain an appreciation and understanding of the other role. I recommend this approach.

There were portions of the training I really enjoyed. For example, many of us got some value from the facilitation techniques they introduced – I hope the company follows up with in-depth training. And I enjoyed the exercise of dreaming up a mobile phone application, creating personas, and developing and refining the product’s epics, features and stories. Our team came up with Mahalo, the water sports equipment rental application. Our stories read, “As a surfer dude or chick…” and our error messages inevitably started with “Bummer, dude….” Entertaining and educational.

While I am a certified scrum master, I haven’t had as much exposure to the product owner material. On my first team at the company, I had trouble mentoring our product owner in fulfilling his role. Neither of us had formal PO training, and the company’s expectations of him were different than the normal scrum expectations of the role. For example, the company’s title for this role has the word “manager” in it, and it led him to try to manage the delivery team. The resulting churn was frustrating for everyone.

I happened to sit next to him during the product owner training, and a part of me wishes I could be back on that team. I think he took the training to heart and I think the team will benefit from clear role delineation and expectations. I’m sure similar insights happened throughout the room, and that will pay strong dividends going forward. Now having been through this training, I think if I found myself in a similar situation, I have a better idea how to approach helping another PO. I certainly gained an appreciation for the challenges of the role during James Shore’s Offing the Offsite Customer simulation game.

On the other side of the coin, I was frustrated at times by the training. For me, the training did not have much depth in any area. Many of my colleagues and I commiserated that just when something got interesting, we had to move on to keep pace with the agenda. A glaring example: our facilitator Chris showed a video of Simon Sinek on Start with Why: How Great Leaders Inspire Action, but ironically, he stopped the video about 5 minutes in right when Simon started to talk about why to start with why. Despite the groans in the room and calls to play it through, we had to move on.

Wanting more, I was encouraged to hear that the company plans to have a coaching engagement. I think that having agile coaches come in, observe our process, and help up fine-tune it would be a tremendous value. Imagine my dismay when I later heard that coaching is seen as a two-week engagement for a couple of troubled teams. I wish Rally had spent time talking about how to evolve your agile practice to fit your business. It’s like David Snowden of Cynefin fame says, “practice without sound theory will not scale”.

It also seemed like the leadership team was hoping that the training would validate the company’s delivery process. They had a committee create a new working agreement between development and product, and unveiled it just prior to the training. Judging from the number of questions and concerns that were raised, it seems that there are a number of crucial conversations needed before we can implement it as written in earnest. However, I should also add that the parts of the executive team did stay for the whole training and they repeatedly stated an interest in candid and frequent feedback, so perhaps this is a communication issue rather than a philosophical one.

Having lead a number of teams in my time, I chuckle at the idea of using the same working agreement for all of them. They had different personalities, different types of work (greenfield app development versus customer support), and different levels of agile experience. For some, by the book Scrum was the most appropriate approach. For others, a lean workflow organized through Kanban worked wonders. Furthermore, the approach changed over time. By forcing all the teams to use vanilla scrum and requiring company-wide adoption of any changes, I am concerned that the company capped its agile skills by teaching to the lowest common denominator. This approach doesn’t work well in our American school systems, and I doubt it will be successful here.

Case in point, we spent a frustrating two hours trying to develop a standard user story template in Rally. I question the value of the exercise: of the agile adoption challenges the company faces, consistent user story formatting would not have been my top choice, and having 50+ people collaborate on writing a comprehensive template was wasteful. My main takeaway was that teams were using existing fields to combat shortcomings in Rally’s product, whether those are because the features don’t exist or whether they are hard to discover. For example, it seems many teams put the feature ID in the story title so that when they export story data, they can tie it back to a feature. To me, this is a Rally feature request for either more robust reporting or navigation capability – a request that won’t be solved with a user story template.

I wish the company’s communication emphasized a unified desire and approach to discovering the best process for the business, rather than an emphasis on standardizing on a common implementation of agile at a team level. I worry that elements of the process will get codified and fixed. As Nick Oostvogels points out, standardization in agile teams, “standards need to be alive and constantly change for the better”. It’s the principle of inspect and adapt, applied to the delivery process. I hope the company will take that principle to heart.