Yesterday, we kicked off Rally’s Roadshow announcing the industry’s first Agile Portfolio Management solution. What an incredible opportunity to tell the Rally story, hear an inspiring presentation from Geoffrey Moore on how to escape the pull of the past, listen to the real-life story of aligning strategy and execution from Nina Schoen at Getty Images, and moderate a panel so lively that the panelists starting asking each other the questions.
Catch the Next Agile Portfolio Management Roadshow
The best way to learn more about this new solution is to tune in to our Agile Portfolio Management roadshow. Although we kicked it off this morning in the Bay Area, you can still catch Dec 8 in Boston (with Dave West from Forrester Research, Chris Haley from The CBORD Group, and Rallyers Todd Olson, Ann Konkler, Rick Simmons and others) and Dec 13 in Dallas (with author Dean Leffingwell, Chad Holdorf from John Deere, and Rallyers Todd Olson, Isaac Montgomery, Julie Chickering and others). If you can’t attend in-person, sign up for the virtual event where we webcast nearly the entire event from keynote to panel presentation, and incorporate online questions.
Self-Serve Materials to Learn More
Below are a few additional materials if you’re the self-serve type. The recorded webcast and slides of the above roadshows will be posted soon as well.
Strategy Meets Execution web site - Learn about the full solution, including Rally Portfolio Manager, Agile Portfolio Steering Workshop and educational resources.
IDC case study – Pay special attention to the great case study written by Melinda Ballou that highlights the work of Nina Schoen and her team at Getty Images on getting alignment through Kanban portfolios. Nina spoke about her real-life experiences at this morning’s Bay Area event.
This post has been a long time coming. I’ve started and restarted it at least a half-dozen times.
Quality – there may be no more multi-faceted and powerful attribute in successful software development. Quality is central to everything we do and seek.
Higher quality leads to greater productivity, throughput and velocity
Higher quality leads to increased responsiveness, reduced cycle-times, shorter lead-times
Higher quality leads to improved customer satisfaction, employee satisfaction
Higher quality leads to better predictability, reduced risk, improved decision making
Or at least that’s my hypothesis…
And that hypothesis is widely shared amongst the Agile and product development communities. We’ve developed numerous principles, practices and techniques intended to improve quality: Test Driven Development; Continuous Integration; Automated Build and Deploy; Pair Programming; Customer Demos; Behavior Driven Development; Acceptance Test Driven Development; and Set-based Design techniques are all at least partially focused on yielding quality improvements.
But quality can’t simply be viewed as a set of tools and techniques – independent variables/levers which we hypothesize will lead to improved business outcomes. Quality is also a business outcome unto itself.
This series emphasizes the need to focus on business outcomes (success) first – methods and practices second. So, putting aside the methods and good practice assumptions of Agile, and focusing solely on the business outcome of improved quality:
Quality = Fewer Defects in Production
We apply Agile quality practices and techniques, because we believe that doing so will yield improved business outcomes – quality (fewer defects in production) being one of those outcomes – along with productivity, predictability, responsiveness, customer and employee satisfaction.
Large, manual, end-of-cycle execution of formal testing by an independent QA organization is also a method aimed at improving these business outcomes. I hypothesize that it is less effective than alternative Agile techniques. But I don’t take that on faith, and neither should you. We must test our hypothesis.
How Do We Measure Quality?
There are innumerable quality metrics that have been devised over the years – each with its own strengths and weaknesses. In my experience, it’s important to keep metrics simple, and to not let great become the enemy of good enough. In other words, if you have a metric that does a good job of providing insight into the quality of your product/solution, and is simple to collect and interpret; that is likely better than chasing after a metric that will do a great job, but would be more complicated.
For my part, I’ve had success over the years using a couple relatively simple metrics:
DEFECT DENSITY – # Defects / KLOC
DEFECT ARRIVAL – # Defects Identified / Month
What Do We Consider a Defect?
In both cases, I include only defects in the production system.
Measuring defects found and eliminated during the development cycle may be useful for managing your development and quality processes. But from a business outcomes perspective, our focus is reducing the number of defects that make it to production – not making assumptions about how or when to achieve that.
Not All Defects Are Created Equal
Any good metric should drive in more questions than answers. I find it useful to tag defects with information about type and severity, so that we can consider some of those questions more deeply.
Our defect density is high; but our severity 1 & 2 density is low. What is the impact on other outcomes (productivity, customer satisfaction, etc.) if we were to invest in reducing our low severity defects?
Our defect arrival is very high immediately following a major release. But the defects are mostly Type = Usability. Why are our customers having such a tough time using our new features; and how can we ease them through the learning curve?
You may have some hypotheses based on these questions. Perhaps those hypotheses involve application or improved use of Agile tools and techniques. What experiments would you run to prove or disprove your hypothesis? What new questions will those results yield?
Isaac Montgomery is the harried father of twin sons, a frustrated hack on the golf course, and an Agile Coach at Rally Software. He blogs at Leading Results, you can follow him on twitter at @iwmontgomery
It’s March Madness for college basketball here in the US. And if you know me, you know I am a nut about college hoops. Hence my metaphor for David Anderson’s recent book, “Kanban”. It is a true dream team of material and I am a true fan.
I had been flipping through David’s book, a bit here, a bit there. And then one day, found myself completely absorbed. I am so struck by David’s expanse of knowledge, his well-founded observations, and his breadth of very accessible experience. What strikes me most though is the clarity of voice in which David offers us his depth of guidance on Kanban.
I first remember hearing David’s passion around Kanban at the Agile 2007 conference in Washington. Just a few feet away from where I was putting final touches on my systems thinking talk, here was David. In the Open Space of the conference, he collected anyone interested to listen to his passion about Kanban. I watched the small group of people grow to a larger group. For me, that was the moment I started to see David and Kanban become synonymous.
Since that 2007 conference, Kanban has become a much sought after topic by organizations looking for visualization, transparency, and continuous improvement in their processes. David’s book is a wonderful place in which to begin your Kanban immersion. Through David’s book, we learn why we should care about Kanban; how principles of flow guide our perspectives on Kanban; and what the Kanban practices are that specifically help us continuously deliver value in the larger context of our organizations.
Now, to admit my particular biases about why David’s “Kanban” is a top seed in my brackets:
I love the “Takeaways” at the end of each chapter. Each snippet is spot on.
I already mentioned it but the clarity of voice. It is key in how David brings us Kanban in such an accessible way.
Everything about WIP limits. David has a “cool your jets” approach to how to set WIP limits and then watch how they help or hinder the value stream.
“Dragos and the 25 Days.” Sound like a children’s book? Too bad. You are going to have to read David’s book to find out why Dragos and his 25 days, for me, is like an incredible 3-point fadeaway shot, all net, with one second on the clock!
I am fortunate to be in an organization that is embracing Kanban. I am fortunate to experience Kanban day-to-day as well as to bring my experiences to others. I am so fortunate I have other colleagues here at Rally passionate about Kanban. I’m very fortunate to be involved in the upcoming Lean SSC conference in Long Beach where many of us will be coming to talk about Lean and Kanban. And, I am so fortunate to have been there in 2007 for David’s talk about Kanban and to now have David’s “Kanban” book in my toolbox of Kanban goodness.
Read this book and embrace David’s advice. It will not only put you and your organization at the top of your bracket; it will keep you there.
Jean Tabaka is a March Madness college hoops freak, a crash skier, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka
As a part of our series on Scaling Agile to the Strategic Level, I have invited our product lead on this project, Catherine Connor, to tell us about her experience in creating Project Stratus. Thank you for the great work and help on this series Catherine.
Project Stratus was conceived over a year ago from numerous customer discovery interviews geared at understanding the challenges of strategic planning with agile execution. From these interviews we started to form an idea of what an agile strategic planning tool could look like, but we also knew that we would need to do serious customer validation before getting to productize a solution.
We’d already selected a disciplined approach to customer validation based on The Four Steps to the Epiphany – Successful Strategies for Products that Win by Steven Blank. Although the book focuses on startups, many of the ideas, such as diligently conducting customer validation and creating a sales roadmap (i.e. a repeatable process to sell your product) can also be applied to new products in existing compagnies. The basic premise of Blank’s approach is that if you solve a problem for customers (called “earlyvangelists”) who are so acutely affected by that problem that they are willing to build a solution themselves, you are more likely to deliver a product that will solve that same problem for many more customers.
Project Stratus was drastically accelerated in April 2010 at the LeanSSC conference in Atlanta, when one of our customers unveiled the agile product portfolio scheduler application they’d built to solve their own strategic planning needs. Not only did the application visualize where we were heading, it also happened to be built on the Rally Platform. We’d just found our first earlyvangelist.
Four months later, at Agile2010, we privately introduced Project Stratus to a handful of industry analysts and customers to gauge their reaction. Based on their overwhelming excitement, we proceeded in identifying additional earlyvangelists from past customer interactions. An earlyvangelist is like a P1 defect, when you find one, you know right away. These customers are so excited to see a provider like Rally think up a commercially supported solution to the problem they have been trying to solve themselves, they are anxious to guide you, and some are even irritated by the fact that the product is not out yet; when all along we’ve been thinking not to deliver such a thing! I could tell when I first engaged with Paul, Dale, Nina, Christophe and others, that they would be partners in shaping Project Stratus to become a valuable product. The beauty of Blank’s technique is in its reciprocity. We, the solution provider, get to build a product that solves real needs, earlyvangelists get to shape a supported solution to replace their manual solution, and customers get to benefit from their peers’ expertise.
With earlyvangelists on hand, we sat down to define the set of hypotheses to validate. This is an important step to ensure that interviews provide meaningful outcomes. Nothing is more deflating than spending an hour with a customer only to find yourself with no good answer to “exactly what did I learn from this call?” Listing hypotheses is also a great way to communicate to yourself and others in your company what you are trying to find out and what you are purposefully setting aside for another time. This is very much like “theory-based decision making”, one of Rally’s corporate core values.
Since August, we have been incrementally evolving Stratus, one weekly build at a time, diligently validating our hypotheses one at a time. Earlyvangelists’ real-life experiences combined with our coaches yearning to apply agile and lean principles to the strategic level are informing the direction of Stratus. I feel really good about where Stratus is going.
As an agile product manager who has seen several projects being productized prematurely, I am truly enjoying following Blank’s rigorous Customer Development approach and definitely would recommend it to my product manager comrades. You do need executive support which thankfully Rally provides me. Following Blank’s technique is no small feat however, it is hard and diligent work with no guaranteed productization plans until you pass his customer validation final exam: “you have proven you have understood customer problems, found a set of earlyvangelists and delivered a product that customers want to buy, developed a repeatable and scalable sales process and demonstrated you have a profitable business model.” Then, and only then, will we graduate to Blank’s customer creation step, aka the delivery of an official Rally offering for Strategic Planning.
The customer validation step for Project Stratus is going full steam. We welcome more earlyvangelists to partner with us in this exciting endeavor. The more input we receive, the more valuable the product will be. If you have strategic planning challenges and a passion for applying agile principles for solving them, I invite you to reach out to us at stratus@rallydev.com. – Catherine Connor
The work done by Steve Blank on this method is fantastic. In addition to Project Stratus, I have used it with our large on-premise customers and with TechStars companies in order to keep from leaping to conclusions and trying to by-pass the customer creation stage. I hope many of you can empathize with the discipline required to do both of these things in the world of product development.
Catherine Connor is a Product Manager at Rally SoftwareDevelopment. She focuses on the product manager role in our customers’ agile transformation endeavors.
Last Thursday, Ben Carey kicked-off our latest and largest webinar on the topic “How Teams Succeed with Agile Quality and Testing.”
Thank you everyone for the great compliments; a majority of the compliments should go to Ben, Jessica, Bob and the folks from SQE for the quality effort. Thanks to these great folks, it was technically perfect, visually pleasing, entertaining, impacting and backed up by great supporting content. If you missed it, you can see the video reply to this webinar. You can find the supporting content under the Learn Agile part of the Rally web site.
Following that webinar, I saw a twitter post from one of our customers about the meeting they had following our webinar. This “Lunch and Learn” session allowed the team to reflect on what the heard immediately following the webinar.
“Having a post-webinar discussion with our SQA group on the #rallydev seminar. Nicely done @RallyOn & @BenCarey”
This is a great example of self educating on this topic. It is the first of four steps that we recommend in the webinar:
Self-educate and discuss to set the context
Find an external driver for your change to keep from having drifting goals (customer, competitor, benchmark)
Make a commitment as a team to move forward
Find your first practice to adjust and adjust just that one only
If you liked the webinar and content, I encourage you to set up a lunch and learn to view and discus these topics on your team or program. If you are interested in more depth, you might consider our next webinar in the series, Pulling Quality Forward: Agile Testing and Tooling for Embedded Software Development. The live presentation will take place on Wednesday, September 30th at Noon MDT with Zach Nies, VP of Product Development at Rally and Paul Henderson from WindRiver/Intel . You can register on-line and learn more about the details.
I have found the quality topic to be great for team lunches. It is can be a sticking point especially for functionally divided teams and quality has to be owned by the whole team. I encourage you to take advantage of either of these webinars to hold a “lunch and learn” topic for your team. Maybe after your next demo and before your next retrospective.
Walter: “So Sarah, I am trying to get started with this Agile stuff.” Sarah: “Great, I am here to help. What have you done so far?”
Walter: “Well, I get that we deliver something every two weeks. Agile makes us hyper-productive. And to do that, my job is to make sure everyone is busy all the time, right? We’ll get the most features if I get people to sign up for the maximum amount of work at the start of the two weeks. This is easy!”
Sarah: “Hmm, I think we better take a step back. You may be misunderstanding something about productivity. Have you ever heard about Slack or Done or Flow?”
Walter: “You mean like Slackers who just blow off work? Sure! And done means its coded, right? And Flow must have something to do with how you hide under the radar to get away with slacking how much you code. Gee, this Agile stuff doesn’t sound very productive after all!”
Sarah: “Well, Walter, I think we need to have a long talk. Coffee or martinis? Pick your poison.”
So What’s so great about Flow?
Walter is stumbling on how to get his teams started with Agile. He holds the notion that it is HIS job to make sure everyone is fully allocated, super-productive. And for him, productivity is measured in lots of features coded.
Sarah has some great advice here guided by the Lean principle of Flow. Productivity is not about filling our plates to maximum capacity during planning meetings. Rather, we encourage team members to build in “slack” in their commitments. They seek Flow of value delivery versus 100% allocation. That is: “Of our total time at work in this 2 weeks, we really only have this much time available (e.g. X hours). And because we need to allow room for discovering what we can’t know, we are only going to sign up for and commit to this much (e.g. 80% of X) work.” As for “done”, a team commits to a certain, attainable level of doneness that includes more than code: testing, documentation, code review, acceptance, etc.
When teams pull these two fundamental Agile practices together, they are invoking the Lean Principle of Flow as guidance.
This is important to understand. Agile teams paying attention to Flow do not bloat estimates in order to manage uncertainty. Nor do they use bloated estimates to artificially create 100% allocation within a timebox. Rather, teams give their most accurate estimates for the work. These estimates include what work it will take to adhere to their definition of “done”. Embedding slack in team capacity absorbs the uncertainty and doubt incumbent in new work. And, at the end of the timebox, a team truly committed to Flow checks in on how it delivered value. It then inspects and adapts how it can continue this smooth value delivery.
Sarah, gets this. New Agile teams that concentrate on Flow before moving to other rigors create a sturdy foundation for continuous improvement.
To be clear, here is what we mean by Flow.
A team commits to only taking on as much work as they can deliver consistently over time. Think of Flow as the work that can smoothly move through a pipe that delivers value to customers. If we fill the pipe to 100% capacity (as Walter is eager to do), we create at the very least turbulence. At its worst, value delivery stops entirely. When Flow becomes this turbulent, work becomes sloppy and quality suffers.
So how can you tell if your team has embraced Flow?
There are a few basic tell-tale practices you should see. Teams in Flow:
Are empowered and collaborative in decision making
Don’t over commit to what they can deliver
Declare a definition of “done” for how they make commitments to value delivery
Use a time-boxed rhythm with slack for high-quality product delivery
Engage in inspection and adaption practices that amplify their learning about team agreements, process and their definition of “done”
Most importantly, teams in Flow have a smooth reliable rhythm of delivery. They can be seen making and meeting their iteration commitments and thus have a stable iterative and incremental process. This is the key first stepping stone to Agile adoption.
Sarah will stick with Walter and his team in their adoption of these Agile practices of Flow. She’ll check in with them for a couple of iterations to help them inspect and adapt while adhering to Flow. Sarah knows there are tons of quick wins to find when teams move to true Flow. And she’ll be there to guide Walter and his team even when the roadblocks to those wins seem insurmountable.
About the Author: Jean Tabakais a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
As part of our goal to have a zero carbon footprint by 2020, we calculate our total carbon footprint each year including building facilities, travel, commuting, IT and waste. As we get more accurate every year, we are adding in the impact of using Software-as-a-Service (SaaS) to that calculation. I have been unable to find a benchmark of other SaaS companies carbon footprints, so I am putting out a call for SaaS companies to share their footprint per user.
Rally’s benchmark – 8 tons of CO2 per year for every 100 users
At Rally, we have been growing steadily (227% in 2005-2007, 242% in 2007-2009) at the same time working hard to limit our carbon footprint. Unfortunately, as a company grows, its carbon footprint often grows with it.
We have been able to keep carbon per 100 users flat at 8 tons per year for the last two years – the same amount produced by a single person flying from New York to Deli, India round trip 4 times. In addition, we estimate that our SaaS customers are avoiding an additional 1 ton per year of CO2 as compared to running an application in a robust manner in their own data center.
What is your SaaS carbon footprint per 100 users?
Lacking any other information, I used our figure – 8 tons per 100 users per year – to calculate our carbon use per 100 SaaS seats for each of our SaaS suppliers including: Google Enterprise Apps, Salesforce Unlimited, NetSuite, Big Machines, Eloqua, Xactly, and Open Air. I assume our numbers are conservative because we are not the scale of the Google or Salesforce, and we count airline miles and employee commute in our footprint. Can any other SaaS providers tell me your carbon per 100 users to increase the accuracy of our calculations?
Like Salesforce, we buy renewable energy credits from NativeEnergy to offset the carbon of hosted operations. This is a very small portion of our overall carbon footprint - about 7 tons per quarter. However, it does a couple of things for us: 1) It supports our SaaS service being carbon neutral since 2008, 2) It keeps us learning about carbon credits at a national and local level, and 3) most importantly, it keeps us focused on our goal of zero carbon by 2020.
Do you want to partner?
In addition to our efforts to battle climate change in our industry, we are also working hard in social responsibility by following the 1% model started by Marc Benioff and Suzanne DiBianca at SalesforceFoundation.org. Last year, we hit our 1% target of volunteer time with over 2,500 hours helping 90 charities. This year, we are in search for a strategic non-profit partner to help us focus our corporate social responsibility efforts and volunteer time in one of three areas:
Reducing the environmental burden from the IT industry (carbon, e-waste, toxins, take-back efforts)
Decreasing the digital divide in society (universal access to the Internet)
Increasing the level and engagement in corporate social responsibility behaviors
If your non-profit believes it can leverage the 3000+ volunteer hours from a company in Colorado, North Carolina and the UK to help on one of these efforts, please contact us. We are looking for a true partner who wants to start developing a relationship in 2009.
The importance of sustainability at Rally
Our efforts are based on trying to stand on the shoulders of Ray Anderson from Interface. See Ray’s Fortune interview on pushing through on sustainability in light of the current economic crisis that is radically affecting his commercial carpet business. Since then, Google’s efforts and Salesforce’s efforts in the SaaS IT space have kept us moving forward.
We look forward to driving zero footprint data centers, increasing remote collaboration technology and having a zero footprint campus in the next decade. We are preparing a sustainability report for 2008, following the Global Reporting Initiative format. It is not a small project, but it was the clear next step for our sustainability efforts that started in earnest in 2007. Our goal is to release it by July 1st so stay tuned.
ADDED After Publishing and based on comments:
A better video of Ray Anderson is his speech at TED in 2009, it gives more background, and more data. – Thanks to David Koontz
Graphic below to provide clear breakdown on sources of Carbon in our business – 6/17/09
On our recent webinar “Demystifying Cloud, The Next Generation Architecture” we had a number of thoughtful and tough questions related to security, intellectual property and risks. We provided answers to these questions in the recording, but I found the recent SD Times article “Cloud Providers Answer Tough Questions” an even better source. In this article, a number of experts on specific platforms from Microsoft, Google, Salesforce as well as Rally’s own Zach Nies answer questions about security, lock-in and IP.
Henry Ford didn't foresee the impact of the first car - do we foresee the true impact of the Cloud?
Daryl Plummer from Gartner also did a great job recently describing the real point of cloud computing as he reviews Russ Daniels recent Forbes article. Russ says:
“In my view, the ability to facilitate innovation and entrepreneurship in this new model is one of the most promising ways to ignite the next wave of economic growth. We can no more see the full impact of the cloud than Henry Ford foresaw the impact of his desire to produce more cars in less time.”
As a result of SD Times’ tough questions and our desire to “ignite the next wave of economic growth,” we decided to talk in our next webinar with Global Logic and IBM about how to go to the cloud and mitigate risk along the way. As with any pilot, the goal is to enter wisely, learn fast and then move forward. Given the iterative and incremental method of Agile is best suited for this fast-learning approach, we will title our next talk “Going to the Cloud – the Agile Way.”
We are structuring the content now, but I would love to hear your ideas, questions or feedback on this topic. I will also post a registration link for the webinar as soon as I have it.
Thesis: Taking a learning-first approach to your cloud efforts can help you avoid the risks of vendor lock-in, IP security and a spectacular failure
Proposed Agenda:
Review the innovation, benefits and risks
Typical approach – Choosing early, over selling, dramatic big bang
The Agile/Lean approach – Set-based, scientific and learning-based
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:
Core Agile Development
Disciplined Agile Delivery
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.
Is it a blob that will cause you to lose all control, including your job?
Or, is it an amazing innovation that will save your company from this world-wide recession?
Or the it's The Blob - Buy the classic @ Turner by clicking image
On April 15th, I will be fortunate enough to join Sachin Saxena from Global Logic and Mac Devine, the AIM SaaS/Cloud CTO at IBM, for a webinar to attempt to answer these questions (learn more and register here). They are both experts in internet technology and hold deep knowledge (along with beautiful slides) on the topic of cloud computing. Their goal is to help you understand the massive energy, time and computer savings made possible by the many cloud options.
Specifically, they will define the cloud, its opportunities and roadblocks. They both plan to highlight case studies, and my role will be as a customer and extensive user of cloud solutions. This is much the same role that I played at the New Jersey CIO summit in February. (If you can’t wait for the webinar – don’t miss Troy Angrignon’s opinion post at Sandhill.com about the implications on cloud computing on software firms.)
At Rally, we are very comfortable with the application of these technologies. As a 160 person SaaS firm provider, we have been in the early market for many of these technologies. It was fun for us to benefit from the fast move to free of hypervisor/virtualization portion of this wave. Listen to Mike Cote’s podcast on the topic at RedMonk. He has been covering the Cloud/virtualization for years as an open source analyst.
As a result, I believe that 100% of the companies who attend this webinar will leverage these technologies in 2009 in a strategy to reduce risk and cut costs. But what are the other rationales for the cloud? What are your stories? I think cloud/SaaS, Agile development and web 2.0 customer communities are an even bigger story, but one that will take longer to develop than the use of public/private clouds and virtualization technology.
Next up on this topic will be the actual energy savings reports from our virtualization and power management efforts lead by our internal green team.
RallyDev.com
Ryan Martens is CTO/Founder of Rally Software, a recovering Entrepreneur-in-Residence at the Unreasonable Institute and chief promoter of the Entrepreneurs Foundation of Colorado. You can follow him on Twitter @RallyOn. 
The customer validation step for Project Stratus is going full steam. We welcome more earlyvangelists to partner with us in this exciting endeavor. The more input we receive, the more valuable the product will be. If you have strategic planning challenges and a passion for applying agile principles for solving them, I invite you to reach out to us at 
and CMM. What Jean and I present in our whitepaper titled “
