Rally is proud of its continued growth since our inception 8 years ago. In the last 2 years, we’ve practically doubled in size. And now we need help sustaining our pride in our company, our culture, and our people. We need a great, unique Director of HR.
Rally Looks Different
Taking its lead from Jim Collins “Good to Great”, Rally truly lives by its core values. For us, our Director of HR would be both an internal and external model and supporter of these values: Create your own reality; Respect people; Make and meet commitments; Give back to the community; Theory-driven decision making; Sustainable work-life balance.
We’re proud of our awards!
Named the Best Company to Work For in Colorado in 2009 and 2010, and ranked the #6 Best Places to Work in the nation from Outside Magazine in 2010, Rally offers a highly collaborative culture and work-life balance that attracts top talent. Our product gets plenty of accolades too, winning four consecutive Jolt Awards (the software industry’s equivalent of the Oscars®) in our category 2006-2009 and recently recognized by industry analyst Forester Research as “offering the best combination of capability and strategy of Agile ALM tools.”
Agile organizations look different
From the start, Rally has prided itself in being a truly Agile organization in the software industry. What does it mean to be a Director of HR in an Agile company? Here are a few characteristics of Agile we value:
Servant Leadership — our management model takes a page out of the Robert Greenleaf approach to leadership: lead by serving and serve by leading. Our Director of HR must be someone who can sustain this environment, mentor others in it, and create professional development opportunities for growth in this management style.
Self-Organizing Teams — part of being an organization of servant leaders includes a strong belief in the value of self-organizing teams. We eschew command-and-control style management. Rather, we seek insights from teams and turn to them to guide our solutions that align with our corporate vision.
Emphasis on Teams — Rally embraces a strong culture of collaboration. For us, that means that we value team accomplishments over individualism or heroism. Our HR Director needs to help us guide employees in the value of team ownership and the intrinsic rewards therein.
De-emphasis on hierarchy — Finally, in our Agile company, we de-emphasize traditional hierarchical organizational structures. Rally is proud of maintaining a fairly flat organization even as we grow upwards of 250 people.
Could This Be You?
So, our Director of HR may look a bit different than you might expect. Still, we are looking for some great solid HR credentials that should look very familiar to you. If this sounds like you, we would love to hear from you via the career section of our web site. There you will find a detailed job description and other benefit details. If this is not you, but you know someone who might be interested, please share this with your friends and with your networks using the “ShareThis” button below or through our LinkedIn post.
As geeky as it sounds, I love learning. When I was first exposed to the world of organizational learning back in the 90′s, I picked up a couple of handy phrases that I chant on weekly basis:
Learn – Teach – Learn
No Theory, No Learn
These phrases capture two of my mental models on organizational learning. Mainly that it is an iterative cycle, only comes through sharing, and requires reflection and measurement on your theory to learn. With that in mind, we frequently open our doors to our customers to Learn and Teach. They observe our stand-ups and planning meetings and we discuss how Agile development has infiltrated not just our development team, but our entire business. I always try to ask them – “What is your Theory?” before they come.
Creative Commons Kathy Sierra - Click to view her blog post on the topic
What’s Your Theory?
Many organizations are simply happy to take the first step toward the smooth and continuous flow of Agile development. But what I love about working with many of our customers like Pinnacol Assurance is their desire to go beyond amateurism, what Kathy Sierra shows as the road to becoming an expert. Amateurism is not enough; they want to become experts by fully adopting Agile throughout their organization and through a continuous improvement process.
At our last release planning session in April, members of the Pinnacol’s IT team participated right alongside our internal team. Wednesday of this week, members of Pinnacol’s leadership team shared in our company-wide rhythm of daily stand-up meetings, rotating through a variety of stand-ups from the dev team to IT to marketing.
How about a Learning Journey?
The goal of their trip was bringing mental models from outside of Pinnacol into their organization. I love that approach and it’s one we use ourselves at Rally. If we see a company doing something particularly well – whether it’s supporting their customers or hosting an out-of-this-world event – we ask to visit their company, shadow them for a day or two, and get first-hand knowledge of their success. It’s one of the best ways I know to quickly learn a model in a very hands-on way and almost immediately translate that into success at your own company – all without reinventing the wheel. Otto Scharmer who developed Theory U calls these trips – Learning Journeys. They are the first step to help you see what you do not know and getting you to open up and learn as a team.
Pinnacol has been very successful at attaining the benefits of Agile in flow inside of IT, but they are already looking above and beyond. They brought business representatives and operations leaders to share and learn about increasing agility in a larger, enterprise-wide context. I am really looking forward to hearing more about Pinnacol’s path to fast learning. You can read about Pinnacol’s adoption of Agile and Rally in the case study.
While the answer MAY be “Yes!”, I posited that there may be a way to save our PMOs from going the way of the now extinct dodo bird.
8 Ways To Re-Tool a PMO in an Agile Environment
Have the PMO involved in helping rollout Agile on several pilot projects
This experience forms the roots for how the Agile PMO will engage throughout the organization with other project teams.
Besides ensuring that Agile training occurs, the Agile PMO can become the coaches of coaches, training the ScrumMasters of each team. They can also be the Agile voice into the business to ensure the Product representatives are fully bought into their role in Agile.
Learn from Lean: start a Kaizen and Gemba mentality now
The PMO should be the shepherds of continuous improvement so that the Agile adoption is not only sustained; it is vibrantly organic, every improving. This means moving beyond team-level iteration-focused retrospectives.
Kaizen events create cross-team learning. This learning exposes team practices that can be useful at an organizational level. In such cases, the team practices are elevated to the organizational “Standard of Work” (see later item). Moreover, the Kaizen event clarifies when a practice does not serve the entire organization and can remain a team practice, supported by team agreements and adhered to by the team.
In addition, in between Kaizen events, apply “Gemba”. An Agile PMO learns about the organization and spreads knowledge through the organization by being involved in projects. That means going to see, or “Gemba” according to Lean practices.
Being engaged with teams rather than dictating from afar may be a dramatic shift in PMO behavior. And, it is pivotal to teams’ respecting the role of the PMO in creating a successful Agile adoption.
Change your definition of “Standard of Work”
This is not a set of standards defined by and enforced by the PMO for project conformance.
In Agile, as guided by Lean practices, a standard of work is a statement of what is currently useful, how things are currently done. It provides a team a backdrop from which to perform continuous improvement through Kaizen events such as retrospectives.
The Agile PMO, rather than controlling and patrolling, engages in facilitating teams in continuous learning. This PMO encourages empowered teams and amplifies the learning that arises when such teams are truly empowered.
A great way to provide this facilitation and to engender cross-team involvement is to help organize and facilitate program-level and multi-program release planning meetings and product councils. The Agile PMO formulates a rhythm and a continuously improving agenda to help these meetings deliver the greatest benefit across teams.
Along with being facilitative, Agile PMOs act as Servant Leaders. They serve their organizations by finding out what they need and getting it for them.
They lead by serving. They remove impediments. They measure what is a problem for teams so that they can serve teams be removing the problem. They don’t look for status from teams; they look for how they can serve teams.
So, for an Agile PMO, leading the Agile rollout means finding out what teams need and delivering that. It is about creating collaborative plans, not collecting statuses. For more about Servant Leaders in Agile, check out the first section of my book Collaboration Explained.
Provide guidance on regulatory adherence
In organizations that must adhere to Sarbanes-Oxley, FDA, HIPAA, or other regulatory guidelines, the Agile PMO can represent these “red” (immutable) stories in each team’s Product Backlog.
The PMO governance work can be the guide to each Product Owner on how to deliver the documents or features that help the entire organization remain in compliance with these regulatory constraints. Governance is now a service to project teams versus being a control mechanism.
Seek guidance from Lean to use Flow, Pull, and Innovate as guidelines for organizational-level Agile adoption
Much of the guidance here has a hint of Lean about it. That is because PMOs work at an organizational level. Moving Agile beyond one or more pilot teams requires guidance for maturing and scaling.
I recommend applying a 5-step approach which is based on Full, Pull and Innovate principles from Lean Thinking.
Once Development group is working with the business to deliver prioritized, valued items, the Agile PMO can bring in other ‘back office” functions to help ensure a growing Agile adoption.
Finance, HR, infrastructure, the executive team, and others must eventually all accept the Agile approach for true organizational change and value.
The Agile PMO has an opportunity to be the mentors and guides for this growth and maturation.
Foster useful metrics
Let go of that Waterfall security blanket around what are useful project or program metrics.
Determine which metrics to track that directly help organizations concentrate on value delivery.
Whatever does not deliver value is waste. It may be temporarily necessary waste. Or it may be a pernicious, embedded waste that has been assumed to be necessary.
An Agile PMO ferrets out these “false friend” metrics and works with teams to determine metrics around value: test coverage, team velocity, agile adoption assessment, defect counts, definition of done.
Today at Rally, we completed a redesign of Agile Commons and changed a number of other things in our online communities. As a result, you are now receiving RSS updates from the AgileBlog instead of the Commons Blog in Agile Commons. If you would like to continue following RSS feeds from Agile Commons, please take a look around the redesign and subscribe inside the Commons.
To understand all the things we are doing with regard to this blog and Agile Commons, click on More.
Several weeks ago, in an interview with Dave West of Forrester Research, Dave posed a provocative question to me.
“Do you have to be smart to do Agile?”
In retrospect, Dave’s question reminded me of an old joke: “Have you stopped beating your wife?“ In this “deeply philosophical” question, there is really no good answer. “Yes” looks bad; “No” looks worse. Answering the question about Agile and smartness could be the same. For me to answer “Yes” could be interpreted as, “Gee of course; look how brilliant I am!” To answer “No” could be interpreted as, “Gee of course not! Look at me! I’m as dumb as a doorknob!“
All jokes aside, I answered “No,” to Dave’s question and here is why.
The real question is not about individuals. The real question is, “Do Agile TEAMS have to be smart?” And to that question, I would answer “Yes.“
Agile relies on the collective wisdom of the team, not on the brilliance of one individual. I learned a lot about this, not just in my research of Katzenbach and Smith’s The Wisdom of Teams. I also have experienced it in the variety of teams in which I have worked and with the teams I have mentored. High team E.Q. (emotional quotient) is what makes Agile really hum. In fact, high team collaboration, their ability to invite and manage conflict, and their ability to create consensus, actually is the fiber that weaves the cloth of a high-performance team. High-performance teams have a collective high goal for which they hold themselves mutually accountable. It is about the team and its commitment to one another and their goal.
So, back to our title math question.
7 + 2 = 5 if your team mistakes collaboration as working in a “dumb down” or “group think” mode. That is not the intent of Agile collaboration or consensus. We’re an Agile team because we intend to increase our collective wisdom.
7 +2 = 9if you are not gathering all the insights of all the team members to inform your decisions in your work. You are not quite yet truly Agile.
7 + 2 = 11 is where the collective wisdom of the Agile team raises its team I.Q. That is, the Agile whole team is indeed greater than the sum of its parts. And besides, as Spinal Tap says, it’s great to, “Go to 11!”
RallyDev.com
