The Coaching blog focuses on Agile with an emphasis on helping organizations turn Agile principals into successful Agile practices. The blog contains posts from across Rally's Coaching, Services, and Technical Account Manager teams.
You’ve probably heard by now that Rally Software has become part of the CA Technologies family. As a result we’re moving the agile blogs you know and love from here, to there: http://blogs.ca.com/tag/agile-management/.
Beginning in mid-October, the Rally blogs will no longer be available in their current locations.
I want a number, a metric, that tells me how productive our teams are!”
challenged my former Head of IT, some years ago. Certainly, it’s a reasonable request to ask how productive a team (or a whole system) is.
But first let’s look at the why behind the question. Why do we measure productivity? Because we should? Because we can? For transparency? Accountability? To drive behaviors and influence culture? Should we measure it at all?
The Scrum approach to delivery has produced the greatest team in the world. And the elements behind the team’s success are repeatable, meaning your team could be next in becoming the greatest team in the world. (That sure has a nice ring to it.)
At a large big room planning (BRP) event run by one of our customers recently, between 400 and 500 people spent two days planning their next 12 weeks of work. The stakes were high, as the health care product they are racing their competitors to deliver must go live by January 1st.
Getting onboard with Agile methods across your organization is no small task. To do it well requires knowledge, culture change, and practice — lots of practice — at all levels.
Rally is fortunate to have some of the most experienced practitioners in the industry. Their broad experience working onsite with customers and their deep knowledge of Agile practices, organizational culture, and human behavior only excites in them a deeper curiosity and eagerness to learn. As you can imagine, this makes them great advice-givers and storytellers!
In light of the discussion over at kanbandev about the feasibility of how SAFe’s WiP limiting approaches work at the portfolio level, there are few nuances that are important to understand. (I've included references below for more information at the Scaled Agile Inc. website, and more information can also be found in the portfolio module of the course materials.)
Our coaching team is having a bit of an internal discussion about the role of PI (Program Increment) Objectives and their importance, and this debate has touched on the nature of Agile Release Trains themselves. I’ve put a lot of thought into this and I feel that organizations are wasting some of the deeper power of SAFe® when misusing them, so I thought I'd share some opinions here.