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.
Team 100% allocated commits to 8 Items for the Iteration
This is the final post in my series about a client’s consternation with regard to Agile Process Overhead. This last topic had to do with their Sprint Planning Meeting and how to make commitments.
The problem? “Jean, how do we plan for unplanned work?”
In this case, the team was referring to production issues that would come up that HAD to be addressed, even though they could not be predicted during the Sprint/Iteration Planning Meeting.
So, how DO you plan for unplanned work? If you look at my post about the 5 Orders of Ignorance, where would you place this issue? Well, it is the 1st Order of Ignorance:
1st Order Ignorance: Lack of Knowledge
I do not know something
For this team, in their planning meeting, they truly can say with conviction, “We know that we don’t know something.” That is, for this team, they know that they can’t know all the production issues that may come up. Fortunately for this team, they don’t fall into the higher orders of ignorance. Most notably, they are not in the clammy grasp of the 3rd Order of Ignorance:
3rd Order Ignorance: Lack of Process
I do not know a (suitably effective) way to find out that I don’t know something
We have a process! It is called Agile software development! And here is how Agile helps us plan for unplanned work, the things we know that we do not know.
Do not commit all of your team capacity to the work you DO know about (i.e. Prioritized Backlog Items)
Track Iteration over Iteration the amount of unplanned production work that comes in (e.g. “Last Iteration we didn’t finish 3 of our committed items because we had 5 major production issues come in. The Iteration before that, we had 6 minor production issues come in; we did not complete 1 of our committed items.”)
Declare and hold a buffer that is an average percentage of time you have production/unplanned work arrive after Sprint Planning (Iteration = Sprint in Scrum) has completed (e.g. “Based on the last 5 Iterations, we have spent an average of 30% of our time on production issues. Therefore, we must hold back a 30% buffer from our Sprint Planning capacity this timebox.”)
During the Sprint/Iteration, continue to track how much unplanned work comes in that impacts the team.
Report this unplanned work and its impact in the Sprint Demo and Review meeting. Continue to evaluate its impact on the team’s ability to take on new, value-based, innovative work during the Sprint/Iteration.
If NO unplanned work comes in during the Sprint, consult with the Product Owner about the next highest priority items the team could invite into their commitment for the Sprint. (Some teams like to talk about this “back burner” work during the Sprint Planning Meeting. They plan it out with tasks and estimates but do not commit to it.)
Team buffers and only commits to 6 Items for the Iteration
Finally, a team that finds itself continually taking on more and more unplanned work needs to run a Retrospective specifically on this topic.
This is part and parcel of a real Agile culture: retrospect on items that are getting in the way of our ability to deliver value.
Where is all the unplanned work coming from? Do we really not know our priorities? Do we really not stick to our Sprint Plan?
Is our product technical debt so great that we are forever mired down in triaging the product? Is our testing strategy not disciplined enough with regard to how we declare “Done” items? What new agreements or strategies must we put into place to reduce the amount of unplanned work?
Now we have a process for how we deal with work that we cannot plan for. Hold your resolve around this. Do not be pressured into fully filling your Sprint/Iteration until you are able to successfully deliver committed items.
Your Burndown Chart will have a more gentle slope; your Sprint/Iteration backlog will have fewer items. AND, you will be able to absorb that work we know that we don’t know.
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.
I eluded to two other perceived Agile Process overheads, one of which I’d like to peek at today: how do you allocate your time effectively?
This came about from the same client discussion that prompted the post on the Sprint Backlog. In conversation, I discovered that the team believed that they had to be 100% allocated for the entire duration of their Sprint. Hence, the lengthy, detailed nature of their Sprint Backlog. Time to back up.
Team Members determine their ideal effort availability
We’ve already covered one problem with this allocation paradigm: you are tracking the wrong thing in your Sprint Backlog if it is not showing value-add work completion. Now, here is the second villain. No-one can accurately account for all hours of every working day as “ideal effort hours”; that is, hours of completely uninterrupted, undistracted work. Ravi Jha stole some of my thunder on this with his great comment to my previous post. Heed his advice from February 27!
Teams preparing to plan their commitment for a Sprint/Iteration look at their capacity; that is, how much work do we believe we can take on and complete by the end of the Sprint? As Ravi pointed out, a good team assumes from the start that it cannot devote a full 8-hours a day strictly to product backlog value-add work. A good beginning capacity number is 6. Why 6? Because it is not 8. Until informed otherwise, of our 8-hour work day, we believe each of us can truly be heads-down concentrating for 6 of those hours. The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions.
Now, here is the sticky part. As I mentioned in Part 1 of this series, Agile teams must also take into account slack for what they can’t know. This is different than the 6 hour number of ideal effort hours. When we make a commitment in a Sprint Planning meeting, the commitment is:
We are committing to moving forward with what we currently know so that we can continue to learn by building a potentially shippable increment of the product.
Our intention is to complete all of these Sprint Backlog items based on the analysis and conversation that has happened to this point.
We think it will take these many ideal effort hours and we believe we have this many hours available.
Everyday, we will honestly evaluate how we are doing with our commitment so that we can improve on meeting this commitment AND improve on how we make commitments in the future.
Therefore, a team, not knowing what it doesn’t know, applies a certain additional level of slack or buffer to how it commits. Call this the “Commitment – Buffer of Unknownables” (or C-BOUs). Now the team that has 6 uninterrupted hours per team member per day may additionally say, “Our C-BOU is about 1 hour person right now per day because we just don’t know this product or this process very well. We don’t know what we don’t know, though we know we want to get better.” As the team evaluates the Product Backlog Items with the Product Owner, and as they determine tasks and estimates for this work, they are keeping in mind:
what ideal hours they will need
what ideal hours do they have
how much C-BOU should they hold back
By the end of the Sprint Planning meeting, a commitment then truly represents:
Items of value we intend to deliver
Commitment by the team to learn about commitment
Intention to use the buffer for what they couldn’t have known
Agreement to evaluate the C-BOU at each retrospective to see if it needs to be bigger or smaller
Some teams call for a bigger C-BOU due to the volatility of their environment. (Okay, they prefer to say their business is very “organic”.) Tracking this capacity buffer is a great way to enable getting to the root of that “organic” nature. Without paying explicit attention to the truth of unknowns and the amount of time they take, a team and the agile project management can create waste and overhead. Teams go into a frenzy mode to meet a commitment that allowed for no buffer, no unknowns. Management applies pressure to meet the commitment despite the clear and present issues that are eating up the efforrt. None of these tactics improve team commitment; they create overhead, waste, and low morale. And they add the cost of manaing all three of these.
That’s it for Part 2. In Part 3, I’ll talk about how you plan for unplanned work, without using a crystal ball :- )
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
RallyDev.com
Last Thursday, Ben Carey kicked-off our latest and largest webinar on the topic “How Teams Succeed with Agile Quality and Testing.”
and CMM. What Jean and I present in our whitepaper titled “
