I had the fine fortune of spending a day with Liz Keogh and Eric Willeke in Boulder last week.
What a wonderful experience! The three of us gathered with the goal of producing something for the Lean and Kanban software community. We didn’t know what that would be. We just knew we felt strongly that we should give something to the community.
We were heavily influenced by past conversations with Chris Matts, his call for “fewer leaders, more leadership”, and a desire to see the Lean Software and Systems Consortium (LSSC) learn from some of the trials that other communities and community-leading organizations have undergone. Ryan Martens, the CTO and a founder of Rally, also provided thoughtful input to our discussions during the day.
As we talked, we discovered something. We were all keenly interested in the general notion of “community”. We became less convinced that the LSSC needed a challenge from us, and more convinced that it was applicable to software communities generally. For me, this was a deeply personal statement and commitment. It played heavily into my recent blog posts on “Escalation”. And yet, together, Liz and Eric and I found the same deep conviction. So as you look at the statement I provide below, if it’s exactly the same as the copies on Liz or Eric’s sites, it’s only because their arguments were equally sound and convincing.
Because of that personal nature, we wanted to avoid putting our statement up as some kind of manifesto that people can sign. If you feel strongly enough about this statement that you would want to sign up, copy it. Post it on your own site. Attribute it to wherever you got your copy from – the act of sharing is more important to us than the act of creation – and feel free to change it so that it reflects your own values. I don’t think that any statement like this can ever be perfect, nor will we perfectly live up to it.
I am a member of a community of thinkers. So are you.
“A Community of Thinkers”
I am a member of a community of thinkers.
I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.
I challenge each community in the software industry to:
reflect and honor the practitioners who make its existence possible;
provide an excellent experience for its members;
support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
exemplify, as a body, the professional and humane behavior of its members;
engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
embrace newcomers to the community openly and to celebrate ongoing journeys; and,
thrive on the sustained health of the community and its members through continual reflection and improvement.
I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.
I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.
In this post, I’d like to respond to some questions posed to Johnny and me during the webinar.
JET = Jean Tabaka
What is the measurement of productivity? Is it user stories per lines of code?
JET: We define productivity index with regard to the Michael Mah statistics collected over 7500 products. It is not about lines of code. Rather it is about delivered value. At a very high-level view then, a PI in an Agile team is about the amount of value delivered by a team based on value delivered over the total number of team members.
Michael Mah shows in his studies, which we referenced in our webinar, that Agile teams tend to have a higher ability to delivery value per team member than the norm across all projects he has surveyed. This supports our view that the way to project cut costs is to help team members increase their PI versus cutting team members or off-shoring work.
When you start on Step 1, one team in flow, do you start immediately with 2-week iterations, even if the teams are used to waterfall?
JET: For any team starting its transition to Agile, the important Flow guidance I give is: Choose a timebox, and stick to it. Religiously.
I give guidance that a shorter timebox is preferable to a longer one. This gives the team that moment of pause for inspection and adaption sooner rather than later.
A shorter timebox invites earlier improvements on process. It also affords the Product Owner or customer representative the opportunity to re-prioritize, add, or delete items in their backlog.
Given these parameters, the team commits to what the timebox length will be. So what do I advise? If asked, I tell teams that 2 weeks is a good starting point: shorter time to inspection versus longer wait for improvement opportunities.
How would you apply Agile, and particularly Scrum, to security related software where design and reviews typically take longer than one iteration?
JET: Agile asks us to evaluate how much design and review MUST occur before features can begin to be coded and tested. Your question is all the more important in your context.
Think of it this way: Imagine in a security software environment, you implemented something and then slammed all kinds of vulnerability tests against it to discover its actual vulnerability. Imagine that this could be in addition to, or even as a replacement to, extensive review up front.
I once worked in a security related software environment. We spent months and months reviewing documentation attempting to conduct independent validation and verification about vulnerabilities before any coding began. How I wish we could have just conducted detailed design, code, and test on our riskiest features and applied our hypotheses against these rather than being left to hope our analysis was adequate!
If we want to introduce Agile in a certain project team, what’s the perfect ratio of Agile consultants versus our own personnel?
JET: Perfection is in the eye of the beholder ;-)
I suggest one mentor per team initially. We have also used one mentor for a team of teams, a program. That creates stability and synergy across the teams and encourages all teams to form their own Agile team agreements while also learning from what has worked well with the other teams.
One more thing: Having a mentor at the management/executive-level is also critical. It may be this same person; it may be someone who has more of an executive stature. In the latter case, be sure the two mentors work tightly with one another.
Would you define ‘user stories’? Similar to Use Cases? Difference?
JET: User stories are an expression of a request from the customer or customer representative for a particular function. They are meant to be short, incomplete, and value-based.
They invite conversation and further clarification of completion: “As a < role >, I want to < action > so that I can < benefit >.”
“As a dog, I want access to ‘The Daily Woof” newspaper on my Kindle so that I can flip pages without opposable thumbs.”
This request for action and benefit is elaborated as it rises in rank among all functions requested. We elaborate these in several ways. One way is to start writing acceptance criteria.
Another way might be to elaborate it through a use case that details actor-system interactions, extensions, and so on. A team makes agreements about how function requests grow in clarity; that is, are use cases our best way to declare DONENESS for this request? Or, in our environment, is a simple description and test case sufficient?
How can we get better reporting metrics for roll-up to the executive level? Are there key mash-ups I should/could use?
JET: without digging into specifics with regard to mashups in our Rally tool, I highly recommend looking at a set of metrics we gathered in our whitepaper: “A CIO Playbook for Adopting for Adopting Scrum” co-authored with Ken Schwaber and Dean Leffingwell.
One appendix in the paper guides teams in a quick self-assessment of their Agile uptake. The second offers metrics both teams and executives can use as new measures of success.
Altering how we measure and guide success in Agile has a great impact on the “stickiness” and intended benefits of the Agile rollout. Rally tool mashups simply support real-time access to such measures. This “reporting” style deviates from the traditional “reporting up”. Rather, the metrics we recommend are meant to keep the entire organization informed about what is really happening. This creates organizational ownership of amplified learning and continuous improvement.
Have you integrated user centered design (usability practices) into the Agile development process? If yes, what was your approach? If no, why not?
JET: I believe user-centered design has a place in Agile development. Design emergence doesn’t mean it can only occur in the planning meeting for the next iteration, IMHO.
creates a high-level vision (informed by many sources);
collaborates with the product owners about how to incorporate this across a product roadmap;
provides more detailed guidance about backlog items specific to the user-centered design;
then engages actively within Scrum teams when product backlog items specifically impact user design changes (where she is tester or owner or delivery team depending on the item.)
Do Agile practices only apply to software delivery, or have you ever seen them applied to successful service delivery?
JET: Jeff Sutherland tells a great story about helping his wife apply Scrum in her life as a Unitarian minister. I also have a colleague who uses it in his volunteer organization. And there are people in my Certified ScrumMaster classes from non-software parts of software organizations eager to bring Agile in. Here at Rally, we use Scrum in EVERY department in the company, including at the executive level.
It is already challenging to obtain the time of critical resources (shared among various projects and sustaining). Are every day SCRUM meetings practically possible?
JET: Everyday meetings are faster than having to write them extensive documentation. And, they are less costly than not having them involved at all. Still, teams make agreements about how critical it is for “part-time” experts to be engaged in every meeting. They inspect and adapt.
Is Scrum mostly for R&D projects with more unknowns or is it equally effective on projects with extensive functional and technical knowledge and skills.
In other words, is Waterfall totally obsolete?
JET: Rigid methodologies don’t serve environments where any amount of change can occur. If you have projects that have no change in scope, no mis-interpretations of requirements, no defects in design, no defects found in code test or integration that would require re-work, I see no reason for you to change. I do not know of such projects.
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:
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.
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:
Beginning Agile team in Flow benefiting from the 25% productivity savings of an Agile teams in the same study
Intermediate Agile team in Pull with incremental releases of value
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:
Good waterfall team – ROI – 0.8
Beginning Agile team in Flow – ROI – 1.4 (1.6 factor better than good waterfall team)
Intermediate Agile team in Pull – ROI – 2.6 (3.2 factor better than good waterfall team)
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.
[ UPDATE: Fall 2009 Locations have now been announced for Boston, Seattle, Chicago and London ]
In December 2008, we ran the prototype to our recently announced Agile Success Tour in Austin, Texas. This event was extremely well received, and the majority of attendees would recommend this event to their colleagues. Given the high satisfaction level, I can almost guarantee you will not want to miss the one nearest you. So consider registering for upcoming events in Denver, Los Angeles or New York City. Short of living in Chicago and attending Agile 2009 in August, it has to be the best way to learn from your local peers about the actual benefits and best practices of adopting, scaling and cutting costs with Agile software development.
I was the moderator at our Austin event and while there, we captured short videos of our customers/presenters. These customer videos give you a sample of what you can expect to see and feel in your community.
The videos include comments from:
Israel Gat – former VP of Development at BMC
Jack Yang –Director of Engineering, HomeAway
Gary Allison – VP of Engineering, Convio
Erik Huddleston — CTO, Inovis
I really enjoyed two things about the event. First, attendees got to hear and discuss multiple approaches to Agile adoption, tooling Agile lifecycle management and the business drivers that drove their move to Agile. Second, the interplay between local leaders, including members of the Agile Austin community, resulted in shared learning while enhancing the local professional network. In addition to a brief presentation by Israel, these gentlemen were all allotted enough time to share their stories, answer a few of my questions and field audience questions. Following the panel, breakout groups allowed folks to dive deep on hot topics, get introductions to Rally partners and learn about major enhancements to Rally’s services and applications for Agile lifecycle management. Of course the event was executed flawlessly by our great marketing team including Sonya Breakstone and Michelle Burrows, and was facilitated by Julie Chickering, our Texas-based coach.
The Denver event is set for Tuesday, March 18th in downtown Denver. This event will include:
Peggy Reed — VP of Development at Avaya
Lloyd Star — VP of Engineering/Development at Beatport
Pete Fischer — Product Manager at eCollege
Ray Bagley — Director, Product Planning & Management at Spatial
The Los Angeles event is set for Thursday, March 26th in Manhattan Beach, CA. The event will include:
Christophe Louvion, CTO at Gorilla Nation
Laureen Knudsen, Sr. Dir. of Program Management at Qualcomm
David Annis, VP of Software Development at UTI from Arizona
Chris Babcock, VP of Technology at Real Capital Markets
The New York City event is set for Thursday, April 2nd. This event will include:
Jochen Krebs, Dir. of Program Management at AOL
Brian Stockmoe, Sr. Dir. of Program Management at NBC Universal
Land du Pont, Executive Dir. of Product at Conde Nast Digital
Micah Silverman, Founder & Principal at MPower IT
So, please consider sending a senior member or members of your team to learn from and share with your local peers. Additionally, Israel Gat is slated to participate in each of these three events, where he will share his stories and insights from BMC and other Agile organizations.
Registration is online and is limited to the first 100 people. I do not believe there is an event with a higher return on your personal investment for these times. Agile is proven to dramatically cut costs and increase innovation in any sized software development team. If you are not realizing major benefits from Agile in your organization, you will feel the pull to get started at this event.
As a warm-up to these events, you might also consider having members of your organization attend or view the recordings of a new, two-part Webinar series on Agile Cuts Costs that includes Jean Tabaka and me.
Kai Ryssdal, interviewing JackCovert and Todd Sattersten, asked the two if there is one book they’d recommend to survive a downturn economy. The two have just authored The 100 Best Business Books of All Time so they seemed like the right people to ask. Their answer surprised me in a particularly wonderful way. SPOILER: it wasn’t my book Collaboration Explained :-)
But before I tell you which book it was, let me tell you a little about what made me so happy and amazed.
I teach a class called “Collaboration Explained” through Rally’s Agile University. In this class about facilitating Agile software teams to be truly collaborative, I also touch into how to tell when I team really isn’t collaborative. It could be about the project’s or organization’s leadership; it could be a fundamentally toxic environment.
Whatever the cause, I talk about (1) recognizing certain dysfunctions, (2) why we should care about them in Agile software development, and (3) what to do about them.
What? A book about teams and their dysfunctions as THE business book for surviving a downturn economy? Yes.
Teams in dysfunction can’t perform. And teams that can’t perform can’t be productive. Non-productive teams eat away at organizational performance.
Think about a team you have been on that just never seemed to gel. Stuck in what is sometimes called “Storming”, it just never seemed to be able to pull it together.
Thinking about that team, do some of these descriptions sound familiar?
Absence of trust
Fear of conflict
Lack of commitment
Avoidance of accountability
Inattention to results
As Lencioni in his fable will tell you, these dysfunctions build on one another; that is, until you resolve a fundamental absence of trust, you won’t be able to tackle a fear of conflict. And so on. Individuals on teams stuck in these dysfunctions “act out” in ways that evidence just how pernicious the damage can be from these untreated team ailments:
Invulnerability
Artificial harmony
Ambiguity
Low Standards
Status and Ego
So, back to “Marketplace”, Kai Ryssdal, Jack Covert and Todd Sattersten. Covert and Sattersten believe in the power of this business fable during this downturn economy because of the power and importance of teams in bringing economies back to life. If you are looking to Agile and how it can cut costs for your organization, consider the power of your teams. Work to engender trust and promote an ability to have constructive conflict. Empower your teams and amplify the learning that teams bring to organizations. And, consider that THE book recommended for all businesses by Covert and Sattersten, not just for software teams, in this downturn economy is a book that directly addresses team dysfunctions.
Cut costs, yes. But don’t just cut groups without consideration of Lencioni’s advice. Work to move dysfunctional teams to becoming high-performing. Maintain and nurture those teams that continue to gel and perform. That is how to survive this economy.
I have linked to Israel’s work before and I have seen him talk about the social contract that he made at BMC in 2006.
However this new post and the attached slide share decks give the seldom-heard whole story. Israel has also provided a new introduction with a solid historical as well as current context; this makes the social contract concept even easier to apply in today’s turbulent times.
This post hits the heart and mind of leaders of Agile teams. I have responsibility for our product development and operations teams at Rally. This post caused me to find ways to double my efforts to lead our team from “within” as we are expanding with a new office/team as well as continuing down the flow-pull-innovate road of agile expertise.
Check out some of Israel’s other great work by visiting his blog, The Agile Executive
Side note: Many people love to give folks that live in Boulder, Colorado a ribbing about spiritual “woo-woo” focus (home of natural food including soy and herbal tea, Naropa Insitute and plenty of hippies).
I think many skeptics like to give that same line to folks who talk about the “people” side of effective Agile enterprise adoption.
Israel’s post is all about managing and leading the team – without this kind of leadership you will be destine to always remain an Agile amateur. Think big about your Agile adoption, but also think big about your personal journey to this level of team leadership. Everyone wins on this journey and this posts keeps you on the rails, especially in these times.
Right now, we are all working through our 2009 budget process with the unknowns of the economic recession staring us in the face. This budgeting cycle holds more unknowns than we’ve seen in awhile, so it’s making everyone cautious about finding the right moves that will cut costs in the short term without damaging our businesses.
Unfortunately, layoffs may be part of the solution to achieving short-term savings, especially for firms hit hard by the recession. In short, layoffs suck. These highly personal actions are sad, and I am sure you and your staff may need some time to grieve the losses. But prior to cuts, there is a bigger issue to consider while managing belt tightening -– your long-term vision and direction. Put simply, it is imperative to refresh your 2009 vision before the cutbacks, or you risk destroying the morale of the whole team, losing key personnel, and dropping market share.
As you look to make cost-saving cuts, the first question is, how are you going behave?
Take the easy way out and cut in a way that fixes the short-term at the risk of harming your long-term prospects. “Across the board” cuts fit this behavior.
Rise to the occasion and cut in ways that meet short-term needs and advance your long-term goals.
On Nov. 9, Rahm Emanuel, the new chief of staff for President-elect Barack Obama said, “Rule one: Never allow a crisis to go to waste… They are opportunities to do big things.” Clearly Mr. Emanuel is reacting by rising to the occasion – scenario number 2.
The trick to taking advantage of this crisis is to resist the pressure to simply cut without a long-term plan that everyone understands. When you do not have long-term goals, short-term fixes always lead to unintended consequences that are typically worse than the original problem. Said another way: While we sometimes get some of the intended consequences, we always get all of the unintended consequences.
A key goal of every IT department is to reduce the time and effort needed to deliver value to the business. To accomplish this, the best long-term trend we have in IT beyond Moore’s law and the power of the Internet is the improvement of IT agility. Increasing IT agility is important because it provides a value innovation and delivery method that harnesses these fundamental advances in infrastructure.
Tom Poppendieck, a leader in the Lean IT movement, recently said, “You can’t cut costs by focusing on cutting costs. You’ve got to focus on the changes that will lower your costs over the long run.”
If you are exploring the adoption of agile software development practices and you’re prepared to rise to the occasion, this recession and the resulting belt-tightening gives you an opportunity. You have the opportunity to rally your company around a vision that will not just cut costs, but improve morale and help you grow your business in the next economic spring.
IT agility
For the 70% of you who have not adopted enterprise agility, let’s do a quick overview. Agile practices enable teams to build less, but return the same value by focusing on early delivery of the features that have the highest business value and not wasting money on the features that don’t.
IT agility is driven by three major innovations: agile development, Software as a Service (SaaS), and Web 2.0 social networks. However, without agility in development and software releases, the innovations of service-oriented architecture (SOA) and Web 2.0 are elusive.
There are three costs savings for enterprise IT agility proven through benchmarking analysis:
Lean flow provides more productive development organizations.
Better prioritization delivers the most valuable software first.
Faster time to market and incremental delivery returns income sooner.
To realize those benefits, you and your team must develop, communicate and implement an effective agile enterprise adoption driven by a highly visible roadmap. Since the late 90s, agile adoptions have followed a ground-up and incremental funding approach as early adopters proved the benefits and scalability of agile in the enterprise. Starting in 2005, leadership-led or top-down approaches have begun to dominate the scene. These larger and more systemic approaches are required for organizations that need to act fast to derive short-term gains.
For managers and directors doing their budget planning now, the next three sections outline the proof points for agile, a roadmap to enterprise agility, and the implications on this roadmap from having to make savings cuts ahead of investment.
Proven impact of enterprise IT agility
Many large and distributed development organizations have proven the positive financial impact of agile over the past five years. These findings were quantified in the Agile Impact Report. In that study, QSM Associates benchmarked Agile teams against a database of 7,500 projects and delivered the following results. On average agile teams working with Rally were 25% more productive, had 50% faster time to market, and delivered one-fourth the number of defects. (Those teams not working got 50% of those results.)
Given those improvements, it is becoming a business imperative to adopt agility, especially on your mission-critical applications. In the face of cuts and with a long-term outlook toward enterprise agility, you can now see your way to a 25% savings in 2009.
Enterprise agile adoption roadmap
Like any mission-critical systems or initiative, you need a vision and roadmap to steer your adoption and rally the troops. During the past four years, an approach fashioned from Lean manufacturing concepts and adopted in an incremental approach has proven very effective. The following illustration depicts that method.
There are three keys to effectively managing this process:
Work incrementally, in an agile fashion, through the steps and gain proficiency before widespread scaling.
Develop a vision/roadmap and change backlog with key executives before you attempt to move up to step 3 and beyond.
Share the vision and roadmap with the entire organization and manage the rollout in a collaborative fashion with complete transparency.
Many of these rollouts have started with a grassroots effort to get to Step 1 and Step 2. With the help of external coaching and parallel tool rollouts, many companies have taken more aggressive, “flash-cut” moves with top-down leadership and investment to jump to step 3 in the roadmap within months.
Flash-cut approaches
Given the pressure and opportunity of this crisis, as well as the increasing number of public proof points showing how large organizations can quickly transition to agile, you might be thinking about your ability to do accelerate your adoption and capture savings in 2009 from your efforts. From my experience, there are three things to heed while considering this:
Adopting agile needs complete management buy-in and a true sense of urgency. Many enterprises that have done this have used phrases like “burn the life rafts.” A recent Gartner report, “Case Study: Inovis Uses Agile Methods to Accelerate Product Development,” says, “The ‘big bang’ adoption approach is high risk, but it works in companies or business units with high levels of risk acceptance, and it can manage the ensuing organizational change.” What is it going to take for your management team to get buy-in to adopt Agile on a major portion of your organization? I assume the current recession will amplify any existing business needs.
You are going to need a strategic partner to help you manage this organization change effort. I do not know a company that followed the flash-cut approach without an outside coaching or consulting firm. As a result, you will have to budget for this investment and the time to choose and schedule them. These partners will help you build the organization capacity for agile while also supporting the professional development of your middle managers as the organization becomes flatter and leaner.
This is a whole system change from a world of plan-driven to value-driven ideas. As a result, you will see immediate changes in your process, organization, and technology. This transition will set up a culture of continuous improvement and even drive changes in your overall development and business strategies. To make this transition go well, you are going to need to implement a collaborative project management solution to provide visibility across your development teams. Enterprise IT agility does not scale or distribute around the world without it.
Don’t waste a crisis
We don’t know how long or how deep this recession will be. Belt-tightening and staffing cuts almost seem inevitable. You can either reduce costs by just cutting your budget, or you can use this opportunity to make systemic changes in your business. I strongly urge you to make your cuts in parallel with investment in the long-term to avoid fixes that fail.
Provided you have a longer-term vision of your organization around agile software development, some outside coaching to help accelerate your adoption and solution for distributed management, you can take advantage of this crisis to make big changes very quickly. Enterprise IT agility is proven to do that — more so than investments in technology point solutions that only have a point in time savings. Most important, this approach will help ensure the savings from today’s cuts do not create worse problems in the long run.
RallyDev.com
I had the fine fortune of spending a day with Liz Keogh and Eric Willeke in Boulder last week.
I give guidance that a shorter timebox is preferable to a longer one. This gives the team that moment of pause for inspection and adaption sooner rather than later.
