Michael Hugos, principal at Center for Systems Innovation [c4si], writes, speaks and consults on strategies for IT and business agility and mentors development teams. He spent six years as CIO of a multibillion dollar distribution cooperative developing a suite of supply chain and business systems that transformed the company’s operations and revenue model. He won the CIO 100 Award and Premier 100 Award for his work. He’s author of several books and writes an online column for CIO magazine called “Doing Business in Real Time.” We recently met with Michael at the Agile 2010 conference, which resulted in “Agile is Ready for the Enterprise” and sparked the idea for this blog post.
Rally asks: What issues and trends are you seeing across technology departments, development teams and in discussions with CIOs?
Michael Hugos answers: The example set by companies such as Google, Facebook and Netflix shows how companies can use iterative development to continuously enhance products and grow market share. This is being noticed by business and technology leaders in other companies and they are asking if they can do the same thing to drive development in their own companies. People realize that IT is right down the middle of everything a company does, and that traditional software release cycles of once a year, or even once a quarter, are not able to keep up with the pace of change and innovation these days.
Just like the word “athlete,” the word “Agile” grabs your attention; it sounds great. But moving from desire to reality always tests peoples’ commitment. A lot of companies are struggling with the all-too-common reaction of, “That’s not the way we do things here…” Agile approaches are interesting and fascinating to companies, but then there is the tendency to immediately criticize new ideas – we’re all prone to it. As soon as someone suggests a new way of doing something, we all think of 10 reasons why that can’t be done or why it won’t work.
Rally: What is driving enterprise adoption of Agile?
MH: To begin with, agility is no longer just a good idea; it’s now backed by law – the law of probability. This law says if a company can’t keep up with rapid rates of change in the world then its probability of success is getting smaller and smaller every day. And since companies need IT infrastructure and applications to operate, just as our bodies need a nervous system and muscles to move, IT agility is critical for a company to achieve business agility.
In the last few years, software tools have enabled executives to measure and track progress on Agile projects and to see the performance of Agile teams in widely dispersed geographical locations. That makes Agile methods more feasible for large companies. A pervading feeling exists throughout business that just about everything else has been tried and IT groups are still not really keeping up with the backlog of user requests. Users are starting to go around IT and do their own things using SaaS, social media and mashups to put together systems. So why not give Agile a try?
Rally: How do Agile methodologies help large organizations foster, regain or accelerate the pace of innovation?
MH: Agile practices offer the best way to improve communication and collaboration between business and IT. Meaningful innovation always starts with communication and collaboration. Another thing that Agile practices enable is the ability to try out new ideas and explore opportunities quickly without investing a lot of money up front. With more traditional approaches, companies invest a lot of time and money planning up front before they start something new. This is expensive. And since most new ideas don’t pan out in the end, this traditional approach makes it difficult (if not impossible) for companies to try out enough new ideas in a year to find that small handful of ideas that do work out and deliver the profits they are looking for.
I like to say that in this high-change and unpredictable economic environment, companies need to: “Think big, start small and deliver quickly.” That’s the best way to keep up, adapt and respond to change, and find the opportunities they are looking for. Agility means letting go of slow, deliberate decision-making in favor of quick, repeatedly-tested decisions. That’s why Agile methods are so appropriate for energizing companies and helping them develop innovative products and services.
Rally: How do you make a case for Agile and address the fears of risk-averse CIOs, CTOs or CEOs?
MH: First, I remind executives of something that has become a fact in the last 10 years: business operations and technology are so tightly intertwined that there is no meaningful distinction left between the two; you can’t do business without technology. That might seem obvious to many but, executives who have been around for a while (like me) may still remember the days when IT was just a back office operation.
Once people acknowledge this reality then I point out that, over the last 10 years, Agile practices have been thoroughly field tested and have an impressive track record for delivering success. There are software tools now, like Rally and others, that address Agile project management and reporting, business and IT collaboration, software testing, and the continuous integration of new software with existing systems infrastructure. So going Agile is not just a leap of faith anymore.
Agile is actually a better way to manage risk versus using traditional waterfall approaches. With Agile practices, big projects are divided into lots of smaller projects that build on each other. This enables people to employ short feedback loops, learn quickly and change plans in light of new information. Two of the biggest causes for failure in business and failure in new development projects is that companies have no inexpensive way to investigate new opportunities, and they blindly follow predefined project plans without change – even as the world itself keeps changing.
The IT profession is at a turning point: one group of IT practitioners has learned that agility is the way to go, but more traditional practitioners still call it radical. Yet, the traditionalists continue to apply the same old ways of doing things that result in the same old horrendously expensive, multi-year projects that produce systems barely better than what was there before, if they even work at all. More and more business executives are coming to the conclusion that the effective support of business agility is the main reason for their company to have an internal IT group. Otherwise, there are options now to just outsource IT operations to cloud computing vendors and get new applications from SaaS providers and social media.
Rally: What does the future hold for Agile and Lean development practices?
MH: Probably the biggest change will be analogous to what happens when a company grows and transitions from an entrepreneurial startup to an established business. When this transition happens, there is a need to become more pragmatic and less idealistic. In the Agile world, this means that “Scrum-but” will actually be the best way for most companies to adopt Agile methods. Each company will customize versions of Agile that best fit their needs and it will be some combination of practices from Scrum, XP, Lean, Kanban, etc. Even waterfall practices have some benefits which should be incorporated where they make sense. Agile practices will not be set in concrete; they will continue to evolve over time as companies learn more and the world keeps changing.
Another big change for Agile is the realization that Agile development is not an end in itself. The value of IT agility is its ability to drive business agility. In the end, agility is more about business than about IT. Instead of co-locating business people with development teams, we will embed IT people in business operating units and co-locate development teams with business people.
I talk about this in my most recent book Business Agility: Sustainable Prosperity in a Relentlessly Competitive World. Agile companies will become real-time organizations that use IT to drive a process of continuous focusing on and responding to opportunities and threats. They will employ IT to drive three continuous feedback loops that make their real-time operations possible. The first feedback loop (I use the Yin-Yang symbol), provides awareness of a changing environment and identifies threats and opportunities. The second loop (I use a sunflower because of how it constantly adjusts itself to follow the sun across the sky), provides balance and continuously adjusts existing operations and processes to fit changing circumstances. And the third loop (I use the leaping panther), provides agility in the sense that it is how companies create new processes and products to seize new opportunities. The figure below illustrates this.
It’s clear, there is not a one-size-fits-all way to define Agile success. Every organization is different, every Agile team is different, and every software development project is different. Each organization has to figure out how to pilot, extend and excel at Agile. Distinct Agile teams within the organization also have to determine how to move to performance in their own ways and make the most effective use of team members to meet their commitments. Full participation from everyone involved is critical to move the organization, process and infrastructure to a better place. The successful approach to adopting Agile acknowledges Agile is not just fad or a quick fix, it is part of an ongoing dialogue of what’s working, what’s not and what are we going to change.
Bringing the Agile community together is a great way for both new and mature Agile teams to share best practices, pain points and success stories. Rally hosts regional events, called Agile Success Tours, to bring the Agile community together for just this purpose. At a recent event in Dallas, we asked participants how they defined Agile success and posed the same question to Twitter. We caught some great answers on video and got some nice, succinct tweets defining Agile success:
These answers illuminate that Agile is a different way of thinking and working for organizations. It’s a smarter, more skeptical and fun craft that addresses the systemic issues found in our increasingly complex and interconnected world. Through Rally’s work over the years helping organizations both large and small adopt Agile, we’ve come to figure out some fundamental components of what success looks like. Agile success comes down to creating the yearning to continue to ratchet up your agility and discipline as a team.
There truly is a simplicity behind Agile adoption when you create the shared commitment and vision that drives your organization – then you begin to see the beauty and the possibilities attainable in an Agile business.
I would like to welcome Ed Willis to our blog, as a guest blogger. I spent a couple of days with Ed and his team of internal coaches this Winter and I am glad to have him share some of their lessons from the field of large distributed Agile – Ryan
Question: What are we, as Scrum team members, committing to in a sprint?
The higher-level Sprint Goal or the more detailed set of selected Product Backlog? If you are a customer of the team, what is the team telling you it will do?
I recall being pretty confused about what the team was committing to in Sprint planning after reading Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, for the first time. There seemed to be some ambiguity around whether the Scrum Team commits to the set of selected Product Backlog items or to the Sprint Goal, which is a higher level and less precise concept. A couple of quotes from that book will help illuminate the situation:
“A team commits to achieving a Sprint Goal.”
“The Scrum Team commits to turn a selected set of Product Backlog into a working product.”
And this from Schwaber’s The Enterprise and Scrum: “… the team selects as much Product Backlog as it believes that it can transform into a completed increment of potentially shippable product functionality by the end of the Sprint. The team commits to the Product Owner to do its best to complete that amount of functionality.”
From the first book again, “The Sprint Goal is an objective that will be met through the implementation of the Product Backlog … The reason for having a Sprint Goal is to give the team some wiggle room regarding the functionality … If the work turns out to be harder than the team had expected, then the team might only partially implement the functionality. “
Note that that last quote appears nearly verbatim in a recent (Feb 2010) version of the Scrum Guide published on scrum.org.
Between the current Scrum Guide and 2001’s “Agile Software Development with Scrum”, Schwaber’s Agile Project Management with Scrum presents an overview of Scrum in its first chapter which does not discuss the Sprint Goal at all – similarly, “The Enterprise and Scrum” provides a summary of Scrum in an appendix that does not talk about the Sprint Goal.
So what are we, as Scrum team members, committing to: the higher-level Sprint Goal or to the more specific set of selected Product Backlog? And why am I so focused on Sprint-level commitments? I focus on commitments because my stakeholders and customers value them. Their plans are in part based on my team’s delivery and so being able to make and meet short-term commitments makes us a better partner to them – “don’t trouble your customer”.
Can You Commit to an Incomplete Sprint?
“Agile Software Development with Scrum” states, “Sometimes only a partial Sprint Backlog can be created … define the initial investigation, design, and architecture work in as much detail as possible, and leave reminders for work that will probably have to be done once the investigation or design has been completed.”
Both that quote and the earlier one on the purpose of the Sprint Goal suggest that the Scrum canon allows for both incomplete Sprint planning and a mechanism to de-scope the Sprint if the team falls behind. If you find yourself in a situation similar to mine (and I suspect many, many of us find ourselves in this situation) where your customers and stakeholders really do value the ability to make and meet high-level commitments in terms of working software that will be delivered at Sprint’s end, then I think that finding a way to do this more regularly is a path you can and should pursue. And it’s one my colleagues and I have embarked on wholeheartedly. All you really need to do to become a better partner in this regard is advance your Sprint planning practices and adapt the strategies you use when you discover you’ve fallen behind.
Reliably Committing to the Selected Product Backlog – One Group’s Perspective
Being able to reliably deliver against Product Backlog commitments isn’t hard conceptually – it starts with doing a better job in Sprint planning. There are probably many ways to do this but I thought I’d share what we’ve done to accomplish this.
Capacity Planning
Our Sprint planning starts with a detailed view into capacity. Is anyone on the team going to be away on training or vacation during the Sprint? Will the remainder of their time be focused on the Sprint? If not, how much do time they think they’ll have to spend in the Sprint? Knowing the total capacity of the team in the coming Sprint is the foundation of a solid Sprint plan.
Ideal Time Estimation
To estimate our Sprint Backlog tasks, we use “ideal time” as it is described in Planning Extreme Programming by Beck and Fowler: “Ideal time is time without interruption where you can concentrate on your work and feel fully productive.” Ideal time on any given task is in essence the answer to the question “how long would this task take you in a perfect world?” Ideal time is then converted into real time in a very similar manner to how story points are converted into expected duration for stories – you measure the velocity of the team. For example, if ideal time velocity of a team is measured at 0.66, then two ideal days of work has been seen in the past to be about three calendar days.
That use of past experience is critical because it rolls up estimation error, overhead, interruptions et al into a single factor used to improve the accuracy of the task estimates while only requiring of the people doing the estimates that they do so consistently. We’ve found it useful. Conceptually I also like it because, along with the use of story points and their corresponding velocity, it increases Scrum’s fractal, self-similar nature.
Assigning Tasks
Typically we assign all the tasks in the Sprint Backlog during the planning meeting. There’s probably enough divergence of thought on this point to warrant its own post, but to stick to the matter at hand, we do this for reasons relevant to the goal of producing more reliable Sprint plans. One major motivation is the fact that estimates provided by the person who will actually do the work are demonstrably more accurate. The second major motivation is our observation that, when trying to achieve greater work sharing and improve the flow of value to the customer by avoiding bottlenecking through specialists, we do a better job of supporting people who are branching out into unfamiliar territory if we know they’re going to do so a priori. Specifically, we can build time into our Sprints for the people who are more knowledgeable in a given area to mentor or review the work of those who are working in areas less familiar to them.
Spikes
We make frequent use of spikes to allow us to develop a better or more complete understanding of what a given story will entail thus giving us the insight needed to build more complete Sprint plans.
Reviewing the Sprint Plan
We review our Sprint plans to look for mistakes we commonly make. We’ve gone as far as enumerating the mistakes we make most often to help us look specifically for those as we do Sprint planning. Most of these are different flavors of not applying our “definition of done” and thus ending up with incomplete plans. If your goal is to develop challenging plans but plans that you’re likely to deliver on, then trying hard to ensure your plans are complete is important.
Note that none of the above should be intended to suggest that we value immutable Sprint Backlogs or task assignments. We can and do frequently grow and shrink the Sprint Backlog as the team uncovers more information about what’s needed to deliver the committed Product Backlog. Similarly, we shuffle (and re-estimate) tasks regularly. What we don’t do is allow significant parts of the work to go unplanned or unassigned at the point we decide what we’re committing to deliver.
Beyond Yes or No
Beyond improved Sprint planning, the second critical aspect for us in delivering committed Product Backlog in a Sprint is how we deal with falling behind. I frequently say in delivering Scrum training that if someone comes to you asking if a bunch of features can get done given fixed resourcing by a given date, that the best of all possible answers is “yes”. The worst of all possible answers is “no” – but not because you’re delivering bad news but rather because saying “no” reinforces the fallacy that that decision is really binary in nature and ignores the great value to be gained by digging into the details to see what’s actually possible.
Similarly when Scrum teams fall behind, they frequently see their choices as being to either: stick with the plan or remove lower priority Product Backlog in consultation with the Product Owner. Those are reasonable choices but I much prefer a third option: work very closely with the Product Owner to find an easier way to deliver the committed Product Backlog items in the time remaining – essentially, use the combined talents and insights of the Product Owner and the team to find simpler, cheaper ways to get the selected Product Backlog done. Honestly, it can feel like magic when it happens.
We once had a Sprint on a tool development project that had fallen far behind – it appeared that no amount of plan scrubbing or task shuffling would allow us to deliver the committed Product Backlog by Sprint’s end. We met with the Product Owner with the intention of choosing Product Backlog to remove from the Sprint. In the course of conversation though, the Product Owner got a better feel for the approach the team was taking in developing one specific item – the item that was driving most of the over-run. Collectively, they realized that the approach was fancier than was really required and in short order sketched out an alternative. We immediately revised our Sprint Backlog to remove the old approach and built a plan for the new one – in about an hour, we went from hopelessly behind with no chance of delivering the complete set of Product Backlog to being close to on schedule. I think having a strong team desire to deliver the whole of the selected Product Backlog was key to making this happen.
Anecdotally, I can say that my colleagues and I worked hard to improve our Sprint planning and replanning practices and pretty quickly found ourselves doing much better in meeting our Product Backlog commitments. For example, during one ten month stretch, I counted 93% of Product Backlog items delivered on time in the Sprints in which they were planned. This isn’t the only thing that matters but it made a big difference to us and our stakeholders: it gave us confidence in the team.
Conclusions
Use the Sprint Goal to capture over-arching but incremental project goals if this concept is meaningful to you and if goals like these are more meaningful commitments than would be the selected Product Backlog – but definitely don’t use the Sprint Goal as a crutch to support poor Sprint planning practices.
Don’t let the Scrum canon hinder your team’s thinking when tuning your process to better satisfy your business needs – the canon wasn’t created to limit your thinking.
And above all, don’t believe that your team won’t be able to reliably commit to the selected Product Backlog Sprint over Sprint – you almost certainly can and, if your team and your stakeholders value this, then by all means pursue improvements in this area.
I’d like to thank Anne Greenhaw, Selaine Henriksen and Ryan Martens for their help in developing this post. Thanks to Ryan also for inviting me to post here.
About the Author:This is the first guest blog post of Ed Willis. Ed was a soldier, a cab driver, a security guard, a tree planter, an auto glass installer and shop manager, an employee of several bookstores, a house painter, a dish-washer, and a foot messenger, among at least a few other things before buying his first computer. Since then he has worked as a research assistant at Queen’s University, driven a data mining company into the ground and ridden Nortel Networks nearly all the way down. He currently works for company in telecommunications. Born in NY, NY, he now lives in Ottawa, Ontario.
As some of you have already begun to notice, the Rally Engineering team is now in full effect with their very own Blog.
This blog provides a great opportunity to (1) gain further insight into Rally’s development environment, (2) ask questions and interact with a high performing Agile engineering team and (3) learn tip’s and tricks from the team’s experience working in a wide variety of technologies.
I have read all their posts and there is something in there for all the rolls and levels of experience on agile teams. It is unique because of the open authoring model for all members of a fast growing set of agile teams.
We received lots of great questions and shared them with the webinar attendees, but thought they would also be valuable to other Agile practitioners. This first series of questions tackle the obstacles of adopting Agile. Stay tuned for the remaining questions in later posts.
What are the biggest blockers you see to good Agile?
DW – My pet peeves are people that resist change without really thinking about it. That treat software like car production and think that you can plan, deliver in that manner. These same people often lament the ability of the software teams to deliver good code at the right price. Software is a fundamental part of business change – If you need a new part to your business it will most likely require software, which may require development and integration. Connecting up their development with the people who have the problem is the first step to success, empowering teams to try new things and question the status quo in support of those business needs is key. Organizations that put artificial walls between the problem and the solution are the biggest blockers. These may come in the form of planning processes, business access, travel budgets, governance models, standards or culture.
RAM – Good Agile development is a mindset change like Dave is describing above. Overly aggressive or passive plans are the biggest blockers to “good Agile.” You need to think about this change as incremental and iterative with a strong focus on continuous improvement and learning through inspect and adapt feedback loops.
Before I dive into Part 3 on my series about Agile Process Overhead, I wanted to review where we are and interject a little wisdom around all of this.
You may recall that I had a client come to me with great concern (frustration?) about all the “overhead” in adopting Agile. Specifically, they wanted to address:
What goes in the Sprint Backlog?
How do you allocate your time effectively?
How do you “plan” for unplanned work?
Each of these seemed to cause a lot of overhead for their ScrumMaster and the team. That confused me and so I decided to post some ideas about them. I addressed the first bullet in Part 1 of this series, and the second bullet in Part 2.
So let’s take a break before moving on to Part 3,: “How do you ‘plan’ for unplanned work?” Here is what I want to raise as a guiding mental model: the 5 Orders of Ignorance. This may appear to have nothing to do with the perceived process overhead with Agile. I think it has everything to do with it.
If we are looking at process overhead, I think applying the 5 Orders of Ignorance is great guidance:
0th Order Ignorance: Lack of Ignorance
I (probably) know something
1st Order Ignorance: Lack of Knowledge
I do not know something
2nd Order Ignorance: Lack of Awareness
I do not know that I do not know something
3rd Order Ignorance: Lack of Process
I do not know a (suitably effective) way to find out that I don’t know something
4th Order Ignorance: Meta-Ignorance
I do not know about the 5 Orders of Ignorance
Where do you think the troubled team is in the 5 Orders of Ignorance when they are struggling with Agile Process Overhead in the guise of an overloaded Sprint Backlog, allocating team members, and planning for unplanned work? How do you think Agile and Lean approaches actually directly impact the 5 Orders of Ignorance? And, in so doing, can you see ways that, in attacking the 5 Orders of Ignorance, they directly impact costs to teams and organizations in a variety of domains?
If you have ever wondered what to do with the growing number of features in your software applications, you are not the only one. There is some useful guidance from The Standish Group survey quantifing that only 20% of all delivered software features are “often or always used.” For a team under the pressure of today’s economy to do more with less, here is a way to conceptually cut 80% of your effort and still deliver the high-value essentials. But wait it gets better. If you do not completely elaborate, build, test or document these features, you save once. But you also save again: with the future maintenance costs, the training users, the bug fixing and the regressing these features would have required. This is clearly the biggest lever for cutting software development costs using Agile. And yet it seems to be the hardest to attain.
Features used in Commercial Software - Reported by Jim Johnson of the Standish Group at XP2002
This pairing back to the simple, important few takes tons of discipline and that level of discipline is only be made easier as your agility maturity increases. Most agile books and coaches will call this the discipline of “Brutal Prioritization.” The folks from 37Signals call it: “Getting Real.” In either case, brutal prioritization means two things:
Not letting the fat slip into the backlog
Keeping the backlog prioritized by value and risk
First, lets talk about fat or wasteful features. Please note, fat or wasteful features come from all directions from the business and customers, but also from developers, support, and product owners. Your features may be fat or wasteful if they:
Do not help the most important user persona in your domain achieve breakthrough results or competitive advantage
Have not be proven to work and are based on a hopes and prayers
Look like pets that someone is protecting
Are weak features that degrade the product because they are not complete enough to meet minimum expectations
So if you are in the customer role or customer proxy role such as the Scrum product owner role, the technical product management or a business analyst role, it is your job to control yourself and help the team to keep the fat off the backlog. If you are on the agile team, it is your job to keep these roles honest about WHY these features are so valuable. This leads right to ranking the items into a prioritized backlog. (A few comments in this area would be really helpful – let’s hear what you use to spot fat features?)
[ 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.
This Friday, February 27th, I will be speaking on a panel at the New Jersey Technology Council’s 2009 CIO Conference called “Moving to a Virtual World” ( www.njtc.org). The panel is on Cloud Computing and it is a mixed collection of vendors and CIO’s talking about the rapid arrival, the clear benefits and struggles of adopting Cloud Computing.
At Rally, we have gained some firsthand knowledge of these technologies, platforms and applications as we try to find the most energy efficient, stable and cost effective solutions for us and our customers. As a small fast growing technology company, we are an ideal customer for Cloud Computing and I am sitting on this panel as a user, supplier and leader on software development for the cloud. (We use Amazon EC2, VMWare ESX, Salesforce and seven App-Exchange Apps, Google Apps Premier to run our business and manage our own multi-tenant SaaS/PaaS application in the cloud.)
In preparation for the panel, I was brushing up on some of the latest news and views on this topic.
Here are the worthwhile Cloud Computing links that I used to prepare my talking points:
Cloud Computing – you have to start on Wikipedia to make sure your definition is grounded
In the mid-1990’s, I worked on a great team (which included three members of Rally’s current technical team) as a consultant and eventually as a Director of IT at US WEST Communications in a part of the IT organization that became known at the Global Village Labs.
Sherman, a 25-year veteran of the Bell system, was rebelling against slow IT services in the age of the 1996 Telecommunications deregulation act. To meet the rapidly changing needs of open network, he built this amazingly agile organization that leveraged Mosaic and then Netscape browsers to screen scrape mainframes using ORAPerl.
We used these agile teams of 5 to 10 people to build tools for customer service representatives and field technicians. These were typically simple tools that bridged a couple of mainframes to build compound views that could answer really tough questions.
These questions were hard because each role was only trained in a limited scope in limited mainframes and that full training took 24 months. So we used early Internet technology to open the access and bridge that gap with simple tools.
We made it into Fortune Magazine because our time to market was measured in months and our ROI was 1000%. In our agile model, we delivered our first working increment to the business on test servers in a fixed time box of six weeks. If these solutions showed value and promise for 5 users, we would run another 6-week time box and then roll the application to 50 users. Successful projects then went on to 500, 5,000 and then up to 20,000+ users following this 6-week time box approach. Marginally valuable applications got tabled at the end of the 5 or 50 user-demonstration time-box.
As a result, we grew the group from the initial 10 folks to the 150 person organization in IT in just 18 months. (See the internal brochure we used to drive business to our group – (BTW, this was really fun to research on the Internet – such good memories.)
QSMA Agile Impact Report showing Agile teams 25 to 50% faster versus 7,500 other projects
50% Faster Time to Market OR 50% Less Staff?
It was all about Time to Market (TTM) for GV Labs and for most folks adopting Agile in this decade. However, now with the cost-cutting focus of these turbulent times, we see many organizations trading off some of the TTM for cost savings. As a result, they will use fewer Agile teams on a project and deliver a lower throughput per agile, time-box cycle. In many cases they are using fewer people, because they have fewer people due to staff cuts. (If you have not taken staff cuts and are wondering how to do that and maximize your Agile success, read an earlier article of mine on TechTarget – Cutting Your Way to Increased Agility and my post on Israel Gat’s Social Contract for Agile Software Development)
Of course this is a continuum of speed and these savings exist in either getting done faster with more or getting done slower with less. You and your organization should be careful to consider the total cost and benefit of the project when right-sizing the team size to completion date. There is an optimal range for most projects and with true agile project teams you get the benefit of adjusting this based on actual performance over short time-boxes.
To gain these benefits, you have to actually become Agile and not just adopt some of the practices. Agile means dedicating you and your team to learning and continuous improvement. We did it at US WEST in the 90’s and QSMA shows how many of our customers are doing it today.
If you truely become agile in these times, you can accelerate out of this downtrun smarter, stronger and leaner.
RallyDev.com
Michael Hugos, principal at Center for Systems Innovation [c4si], writes, speaks and consults on strategies for IT and business agility and mentors development teams. He spent six years as CIO of a multibillion dollar distribution cooperative developing a suite of supply chain and business systems that transformed the company’s operations and revenue model. He won the CIO 100 Award and Premier 100 Award for his work. He’s author of several books and writes an online column for CIO magazine called “Doing Business in Real Time.” We recently met with Michael at the Agile 2010 conference, which resulted in “Agile is Ready for the Enterprise” and sparked the idea for this blog post.
I recall being pretty confused about what the team was committing to in Sprint planning after reading 
Similarly when Scrum teams fall behind, they frequently see their choices as being to either: stick with the plan or remove lower priority Product Backlog in consultation with the Product Owner. Those are reasonable choices but I much prefer a third option: work very closely with the Product Owner to find an easier way to deliver the committed Product Backlog items in the time remaining – essentially, use the combined talents and insights of the Product Owner and the team to find simpler, cheaper ways to get the selected Product Backlog done. Honestly, it can feel like magic when it happens.
About the Author: This is the first guest blog post of Ed Willis. 
If we are looking at process overhead, I think applying the 5 Orders of Ignorance is great guidance:
