Agile Development Blog

We’re looking for a Director of HR

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.

Tim Miller is a dropout from the University of Colorado but somehow has two degrees from CU. He keeps sane by playing golf and tennis and is the CEO at Rally Software Development.

On April 21 in Atlanta, the Lean Software and Systems Consortium will come together for its second US conference.  Last year’s event in Miami was “amazing” according to Jean.  So this year, Rally is exhibiting, I am speaking while Jean and Aaron are running the open space on Friday.  The price per attendee goes up by $250 on March 31st, so if you do intend to go, REGISTER now.

At our booth, Rally will be demonstrating its product support for highly-visible Kanban, WIP/Cumulative Flow reports, and cycle-time  metrics. Join Alan Atlas, Jean Tabaka, Aaron Sanders and Craig Langenfeld in our booth.

I will be presenting an experience report titled: PDCA: Beyond Simple Inspect and Adapt. On spring break this week, I’ve been thinking more about the details of my talk. Here is my abstract and outline for those of you who might consider attending:

Lean and Kanban focus on practices of continuous flow of product delivery. Plan-Do-Check-Act (PDCA) is a Lean discipline that moves beyond inspect and adapt of Agile team-level processes.  At a corporate level, PDCA provides guidance for strategy as well as problem-solving work. In 2009, I led Rally’s move to PDCA for the company’s strategy process at both the annual and quarterly levels.  My primary guide was Pascal Dennis’ “Getting the Right Things Done”. In this experience report, I share Rally’s PDCA first year of adoption: where we started, how this impacted our corporate behaviors, and where we are now. I want to share Rally’s story to compel participants to embrace PDCA and get good at it. I ask each participant to come with its organization’s #1 goal and success criteria. I will close with a planning A3 exercise from Pascal’s book .

Outline

1. What brought me here—background on why I am passionate about sharing my organization’s overall Lean story including the addition of PDCA, A3’s and concurrent set-based development.  This talk focuses on PDCA as the critical step in increasing structure and discipline in strategy execution.
2. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
3. Benefits — Mature your strategic planning and execution environment to handle the complexity of increasing speed, agility and scale and to gain alignment, pull and innovation.
4. Where we were and what was not working
   1. The context at Rally was based on a couple of key concepts:
      1. Core Values, Core Purpose, Sandbox and BHAG from Jim Collins
      2. 3 to 5 Quarterly Rocks, success criteria and Scoreboards from Gazelles
      3. Rock team structures  – cross departmental and story based
      4. Facilitated, highly collaborative cross-departmental meeting of 30+ managers and above
   2. What we noticed
      1. Rock work as a second or third job
      2. Wisdom of the Crowds to help fix over-reaction and group think
      3. Too much on the fly, not enough backlog grooming
      4. Highly critical, non-cross departmental initiatives were de-prioritized
      5. ORID process added to keep from jumping too solutions, but the data was not visible enough
5. What we decided to do about this:
   1. Explanation of PDCA — A brief overview of PDCA in general and then specifically what I used as guidance from the Pascal Dennis book, “Getting the Right Things Done: A Leader’s Guide to Planning and Execution”.
   2. Our initial experiments with A3 process the year prior — Working with our Ops team and product marketing teams on problem solving using real data
   3. First quarter — How we kick-started Rally’s company-wide adoption of PDCA . I describe our “Mountain Team” and their transitional role.
      1. Defining Rally’s True North
      2. Creating our second level tree with current and needed metrics
      3. Socializing these throughout the company seeking feedback in anticipation of our annual and quarterly planning
      4. Started new experiments based on quarterly planning decisions
   4. Next Quarter – Review new experiments, discussed learning and drive A3’s into the planning process
   5. Mid-course adjustment by Mountain team, in middle of the quarter – What we discovered working and not working
      1. The rocks were all dependent on each other.
      2. Had to run Rock of Rock team meetings to steer to a final solution
      3. Coordinated release planning would have
   6. Final quarter – We worked to expand the plan. We took the Mountain team’s True North and feedback to drive our PDCA for Rally’s Annual Corporate planning by:
      1. 1. Taking company-wide feedback into our Annual planning to collaboratively drive cross-department A3 creation around each branch of the tree
         2. Mountain Team retrospective over the course of year 1 that helped create a planning rock team.  The Mountain team’s role as a transition team ended.
   7. Year 2 – Doubling down our efforts to go from amateurs to intermediates —Changing our process to institutionalize A3’s and PDCA as our strategy execution approach:
      1. Quarterly rocks moved to a world of pre-defined from developed on the fly
      2. Quarterly planning moved from ad-hoc based on yesterday’s weather to more programmed based on True North and meeting the target metrics
      3. Strategic planning worked to validate annual True North in the context of long-term planning, shared vision development, cross-boundary collaboration and larger systems
6. What we learned and what you should do about it
   1. The cycle of adoption is a year, quarterly cycles work to improve the process, but it is hard to make leaps on a quarterly basis.
      1. Year 0 – Introduce Lean thinking (A3 in our case)
         
      2. Year 1 – Introduce PDCA (Novice)
      3. Year 2 – Invest or abandon (Your choice)
         1. A3 is now the language for problem solving
         2. Making sure we are solving the right problem (aka slowing down to speed up)
   2. Do not have a overall guidance team steering the continued PDCA process – it is owned by the “team”
   3. Putting pressure on the organization to get more clear about our economic models to mature from “Theory-based decision making toward the right solution,” Now “Data-driven decision making toward the right problem”
   4. Where to start – The Strategy A3 an exercise
   5. What is next? – We call it the Innovative or Lean Organization. Seeing large systems, collaborating across boundaries and creating your reality.
      
7. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
8. Call to Action – Introduce the language of A3’s through problem solving or Strategy A3’s
9. Benefits — Help build a company of problem solvers to focus your efforts on the critical few things.
10. Where I hope you go with this: Great companies build great software, great experiences and work on creating win/win scenarios.
    

And the number #1 Characteristic of an Agile Organization is…

“The Commitment to be Great”

The ability to make the commitment to be more than just good comes from the ability to drive a culture of discipline that balances the metrics of profitability and reputation.  Hopefully you have seen and heard that message come through in the other items in our top 10 list; I applied these concepts from Jim Collins’ in “Good to Great.”

“Greatness is not a function of circumstance.  Greatness is largely a matter of conscious choice and discipline.”

In the world of software development, an agile organization does not settle for having agile stuck in ghettos.  An agile organization makes the commitment to go up the learning curve and blow past amateurism.  As Jim describes this takes an organization that can increase the discipline to support increasing levels and scale of agility. Discipline to:

• Regularly plan at the five levels (daily, iteration, release, roadmap and long-term vision)
• Regularly make and meet the commitments you make based on a sustainable pace
• Regularly inspect the progress & metrics and adapt the plans at each level
• Make decisions based on the data, culture, and purpose

As Alan talks about at Amazon, it was just the OK from management that was needed.  As Israel talks about at BMC, it was a Social Contract.   You know what kind of commitment you need at your organization to scale agile.  You need to get it to really improve and make your transition happen.  Please, don’t settle for a weak commitment.  It leads to isolated adoption,  ghettos, and a slow, muddling adoption process.  Scaling agility beyond just the development teams can be simple and rewarding, as long as you start with the commitment.

Here is a quick refresher of the complete Top 10  list:

#1 Commitment to be great; disciplined culture and metrics

#2 Creating Your Own Reality and Corporate Vision

#3 Quality and Faster

#4 Personal Flexibility and Rhythm

#5 Bottom-up and Top-down Decision Making

#6 Collaborative and Smart

#7 Contributing to the Community and Maintaining a Profitable Company

#8 Sustainable and Successful

#9 Servant and Leader

#10 Work/Life Balance and Consistent Delivery

I hope you have enjoyed our series on the top 10 Characteristics of an Agile organization, it was a pleasure doing this with Jean, Anne and Grant.

Let us know if we missed something?

#2 in our list of the Top 10 characteristics of an Agile organization is about the great combination of “Create your own reality” and Corporate Vision.

At Rally, one of our core values is “Create your own reality.” In this 3 minute video, I talk about how successful Agile organizations embrace a practice of holding a corporate vision and yet encouraging people to find where they can best bring their talents to bear. In a traditional organization, a corporate vision may be the source of very strict, very detailed role descriptions and role assignments. The corporate vision in an Agile organization acts as a guide for how to help people contribute their best work for the overall corporate goals.

Watch my video for more about why I truly believe in both “Create your own reality” and Corporate Vision as key success factors in Agile organizations.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company, #6 Collaborative and Smart, #5 Bottom-up and Top-down Decision Making, #4 Flexibility and Rhythm, and #3 Quality and Faster.

Stay tuned to find out the #1 Characteristic of an Agile Organization

#4 in our list of the Top Characteristics of an Agile Organization is about the importance of Flexibility and Rhythm.

With regard to the video reference to Jim Collins, you can read the interview about his new book and his personal rhythm on the NYTimes site. Verne Harnish’s Gazelles.com teaches the Rockefeller Habits on business rhythm.

In the last couple of months, IBM (via Scott Ambler) has blogged, hosted webinars and talked to the media about an Agile process maturity model (APMM).  I am sure this will hit a new height today with the start of the Rational Users Conference and the release of the e-book.  I have been asked to comment on this work by a number of press and analysts.  Since my perspective will be published shortly, I thought I would go on record.

IBM splashes its way into Agile development

As the Agile market grows and takes hold in truly mainstream audiences, everyone is looking for easy, step-by-step guides to smooth Agile adoption. IBM is proposing one option under the name “Agile Process Maturity Model.”  I think it is a nice marketing strategy for selling IBM’s Rational Team Concert products to companies that want to adopt the Jazz platform, copying their 90′s success with RUP.  But I don’t believe it is actually an Agile process maturity model, and further, Agile doesn’t need one.

IBM’s proposal for an Agile Process Maturity Model

Scott says, “The goal of the APMM is to help categorize and understand agile processes, not to rate your adoption level (the CMMI Defined approach can address that need).”

He continues, “Unfortunately, the term ‘maturity’ is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integration (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another…” 

I am confused by the title and the orthogonality, so let’s peel the onion on this one.

What is a process maturity model?

The origins of process maturity models come from the manufacturing industry, but the software version was created in the 1990′s by Carnegie Mellon’s Software Engineering Institute (SEI). It is well known as three Capability Maturity Models – CMM for software, CMM for people and CMMI.

If you read Watts Humphrey’s work, you will see this is a management framework that measures the level of discipline of  your organization. In essence, organizations that are certified Level 5 have implemented continuous improvement and have the disciplines and practices in place to effectively manage large complex projects with effective controls.  The framework does not say anything about how the software should be developed.  I make no claims to being a CMMI expert, but you can read a few of the “CMMI agile” search results to see how they work together.

Though not the stated intent of the framework, it has been closely associated with waterfall development and used to defend heavy process approaches. I disagree with that belief and prescribe to Jim Collin’s model of blending  discipline and agility together to move from good to great. I think the CMM framework is a great checklist for organizations measuring their level of discipline… and we don’t need another one.

The 3 levels of IBM’s APMM

Scott’s APMM post describes three levels:

1. Core Agile Development
2. Disciplined Agile Delivery
3. Agility at Scale

I struggle to see how these three labels or the supporting details provide a framework that helps categorize and understand Agile processes.  These titles grow in scope and scale, but do not speak to increasing agility.  (Faster cycles, less waste, less work-in-progress, more value.) When you look deeper, it smells of a cookbook of when to apply processes and tools from IBM.  That is fine, and I agree customers need this. However, I would argue this should not be used to guide companies in their Agile adoption.

By mashing size, scope, increased agility and disciplines on one scale, the APMM does none well.  In addition, it will lead to amateur implementations where continuous improvement mentality never sets in. Where adopting scaling software agility is thought to be just a transition from A to B.  To me that thinking is very limiting and will lead to gains followed by declines.

IBM in the Agile space – all good

I am thrilled with IBM’s entrance into the Agile space with their Jazz platform and related products – really. When I was at BEA/Weblogic, I can tell you that we did not have a market for Java Application servers until the industry’s gorillas, IBM and Oracle, entered for real.

During this year, Jazz and its supporting products will actually manage the workflow of projects in a way that works with Agile development instead of against it. This is huge change from the ALM 1.0 point products that actually reinforced the silos and phased approaches that created queues, caused hand-off delays and kept quality as an after-thought.

The IBM gorilla in the software development space will make the Agile sea rise and help break down major organizational barriers to bringing the benefits of Agile practices and tools to the mainstream development community.

There is no cookbook for adopting Agile

I believe that enterprises need an adoption model that helps them balance discipline and agility in an incremental fashion that creates incremental success and fuels continued investment and improvement. The enterprise Agile adoption model Jean Tabaka and I have synthesized is based on Lean concepts and is rooted in Deming’s work, just like Watts Humphrey and CMM. What Jean and I present in our whitepaper titled “Leaning IT: Moving to Program Pull” is how to move up the adoption curve of Agile by learning quickly,  maturing before scaling and working incrementally. 

This transition planning framework focuses on attaining benefits of agility by moving to lean states of flow, pull and ultimately the perfection of continuous innovation before adding the disciplines necessary to scale.  It discusses the general steps, but does not prescribe a change approach to organizational, technological, process or strategy transitions.   Your approach is dependent upon your corporate and technological situation.  We recommend an iterative approach, facilitated by experienced coaches and peer support.

What does the Agile community need from IBM?

Mary and Tom Poppendieck’s new book called “Leading Lean Software Development” (out soon) has tremendously strong stories, models and insights from bringing lean concepts to software. In chapter six,  they highlight a success story from working on lean with Sue McKinney at IBM.  This success story, along with the Eclipse success stories, are critical for IBM to be telling the market regarding the impact of Agile and Lean in the large inside IBM.

In 2008 and four years after IBM started developing Jazz, we talked to IBM about integrating Rally’s award winning Agile Lifecycle Management solution onto IBM’s collaborative development platform, called Jazz Foundation.  They said no, you have to wait until the GA release of Jazz. This would be a similar integration that we provide to Microsoft Team Foundation Server for managing code check-in’s and automated builds with a slick interface into the IDE.  I am hopeful that IBM will GA the 1.0 version of the Jazz Foundation for partners to actually integrate with.  They are saying all the right things on the Jazz.net site, here is hoping for some positive news at this week’s Rational User’s Conference.  Finally, I am very excited about IBM’s global dialogue on Building a Smarter Planet. IBM needs to do a better job telling the story about how software agility is a critical component to building that sustainable planet. (It was nice to see the smarter planet splash at the front of the ebook, but it still represents a huge missed opportunity.)

What do you think? Does Agile need its own process maturity model?

Again, I was surprised by the title of IBM’s Agile Process Maturity Model and hope they will consider changing it before more marketing dollars are spent.  It does not improve on the CMM, nor in my opinion does it help CMM certified companies adopt Agile.  I assume IBM has a huge role to play in helping those CMM certified companies add agility and innovation to their highly disciplined organizations. If they don’t, we are glad to help today.

About the Author: Ryan Martens is a happy father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Original F4 Technologies logo 2002-2004

I know what you are thinking with the title of this post – I am drinking the Kool-Aid. Just bear with me  for a minute. Back in 2002, when I started working on Rally, it was originally known as F4 Technologies. It was known as F4 because I did not want to work on anything that did not have the potential impact of a Factor of Four, for example a 4X increase in productivity or effectiveness.   There are two reasons for this:

1. Andrew MacAfee and John Gourville at HBS have shown that you need a 9X improvement with a new tool, technique or method to un-seed the incumbent.
2. According to Paul Hawken in Natural Capitalism, we need a 4X productivity increase in the use of natural resources to get to a sustainable place with the current population in the world.  Chapter 7 of that book helped form the core purpose and mantra of Rally – “Muda, Service and Flow.”

Now seven years into Rally, we have the proof that teams – including large and distributed teams – can be 4 to 10X more productive by following Lean principles and effectively implementing Agile development.  Like the story of “Good to Great”  from Jim Collins, you can’t leap here, but you can put yourself on that path by adopting a continuous improvement approach like Agile.  If you do that, you can be a “great” software development organization that dominates your market and is 10X better than the good ones.  Great organizations that dominate in their industry also have the knowledge and resources to change world, a la Google.org, the Salesforce.com Foundation and or through my favorite the Entrepreneur’s Foundation.

My summary take-away from Good to Great is:

“Right people building the right things right”

“Disciplined people, Disciplined thought, Disciplined culture “

If you are working toward this, I believe you increase your business value by 4 to 10 times.  I am going to make the case with the help of ROI models from David Anderson.  (BTW, I love his book – it does a great job explaining the simple physics of Agile.)

From Chapter 2 - David Anderson's "Agile Management for Software Engineering"

This is a very simple model of software process.  David shows more complex ones that model all the loop backs of large shipping software, but let’s work with this one.  So, the rough equations to calculate the business benefit of the process are the following:

Net Profit = Throughput – Operating Expense 
ROI = Net Profit / Investment

In the following four pages, I am going to look at how this equation plays out for four different scenarios:

1. Good waterfall team, on the mean line of the QSMA Agile Impact Report
2. Beginning Agile team in Flow benefiting from the 25% productivity savings of an Agile teams in the same study
3. Intermediate Agile team in Pull with incremental releases of value
4. Advanced team in Innovate that cuts time-to-market in 1/2 to end early after delivering 50% of the work but 80%the value

What you will see in this hypothetical modeling exercise is the true power of Agile to dramatically impact the software development teams in the organization. For a deeper understanding of what I mean by Flow, Pull and Innovate, please Jean and I’s white paper on moving to Program Pull.

Here is the summary:

1. Good waterfall team – ROI – 0.8
2. Beginning Agile team in Flow  – ROI – 1.4 (1.6 factor better than good waterfall team)
3. Intermediate Agile team in Pull  – ROI – 2.6 (3.2 factor better than good waterfall team)
4. Advanced Agile team in Innovate  – ROI – 6.3 (7.7 factor better than good waterfall team)

Factor or Four or better – that is why there is such a rush towards Agile development.  Of course, you can’t have your cake and  eat it too.  Moving up this maturity curve takes long-term dedication to increasing discipline and agility across the entire organization, but there are dramatic benefits if you can get on the continuous improvement path and stay there.

There was much to celebrate as an American last Tuesday. The President’s speech took me back to core values and principles. This quote struck me hard as we work through this recession.

“Those ideals still light the world, and we will not give them up for expedience’s sake.”

In the flurry to find ways to take cost out of the business quickly, it is very easy to get carried away and have everyone run to the cost-cutting side of the boat.  There are two things to watch out for as your company’s suggestion box fills-up:

1. Selecting quick fixes without an eye for the long-term implications or unintended consequences
2. Letting your goals or values drift in the short-term at the expense of true on-going success

Cover of HBR Article on Core Values

If you enjoy the writings of Jim Collins, like this Harvard Business Review classic , you believe that only with the guidance of core values and principles can you make the tough decisions needed to steer through this rough time.

Again, from the new President’s inauguration address:

“Our challenges may be new, the instruments with which we meet them may be new, but those values upon which our success depends, honesty and hard work, courage and fair play, tolerance and curiosity, loyalty and patriotism — these things are old.”

For many software-driven organizations, I believe Agile development is the “new instrument” to meet these new challenges.  Now for the good news – since core values are “forever,” these certainly do not need to change with even the largest scale Agile adoption across the software development lifecycle.

So, as we explore the notion of cutting costs through Agile adoption, let’s start with a frame of core values. Rally’s core values are captured on our backgrounder for hiring new employees.

Where are your company’s core values? How can you leverage them to adopt Agile in this historic time?

Further Reading:

• Growth Hides All Issues and Quick Fixes Mostly Fail
• Work/Life Balance – Top Characteristics of an Agile Organization
  
• Where to Turn in a Down Economy?

The NPR (National Public Radio) inauguration coverage of President Obama got me thinking about patterns for 2009. First, I was enjoying the notion that Obama created today as a national day of service (see a new clearinghouse for local service opportunities at www.usaservice.org and www.mlkday.gov), but I was lamenting that I did not have enough time to drum up some organized effort at Rally or with EFCO.

Listing of Service Opportunities around Boulder, CO from USAservice.org

My Start, Stop and Keep Doing List

That got me thinking about my focus for 2009.  Over our holiday week off at Rally, I took time to create a Stop, Start and Keep Doing list, which is a practice encouraged by Jim Collins, among others.

For example, one of the things on my Start Doing list is to be the Executive Director of EFCO, working on scaling my dream around socially responsible businesses.  I’ll focus more on corporate social responsibility later, but for 2009I think folks who are employed should all be focused on their Stop Doing list.

(more…)