Last summer, Rally started a video series called “Chalk Talks“.
I was fortunate enough to have filmed several“Chalk Talk” videos about some of the basics of Agile software development (The Agile Manifesto, Scrum Basics, Iteration Demo and Review Meeting, and other topics).
We also tapped into the wisdom of some of our other Agile Coaches: Julie Chickering, Mark Kilby, and Ken Clyne.
Our Rally Chalk Talks are informal videos, typically 3 – 5 minutes long, intended to provide quick, easy introductions to Agile topics.
Filmed in a short, tutorial format, these videos are great to share with your team as they are getting up to speed on Agile.
To get a feel for our latest work, here’s Rally Agile Coach Ronica Roth in her great Chalk Talk on User Stories. ( during which you can find out why a dog would want his own laptop :D)
Be sure to check out our entire catalog of Chalk Talks and subscribe to our YouTube channel if you’d like to be notified when we publish new videos. We already have two more Chalk Talks queued up: “Kanban and Scrum” and “Agile and Lean”.
As you look through our current catalog of talks, be sure to let us know what other topics you’d like us to cover in future talks.
For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”
I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie. There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile. Now is not the time to stop and eat.
For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.
I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :
a defined a bar that is deep in skill, knowledge and practice
a significant enough bar to engage College and University study and examination
research and curriculum that explore the tough questions in a scientific method
development of more flexible or “T” shaped individuals that can see and work beyond silo roles.
I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.
A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:
I encourage everyone in our community to figure out how to put energy toward one or more of these efforts. The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking. Thus broader education and difficult certification helps create a “Community of Thinkers.” And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.
As a Scotsman living in the US I take more than my fair share of trips through Heathrow airport.
There are many things I enjoy about being back in the UK but Heathrow airport is certainly not one of them. For a while HSBC bank tried valiantly to cheer us up, and as we trudged wearily from terminal to terminal, our journey was made more colorful by the many posters from their What’s Your Point of View campaign.
Here is an example of one of their posters:
Looking at these posters made me reflect on my own work as an Agile Coach and how I am often confronted by different points of view.
If I am speaking to a group and criticize waterfall development there is a chance someone will feel I am disparaging their team or their efforts. Sometimes use of the word agile does not serve a good purpose. Many have negative perceptions of Agile and believe it to be chaotic, undisciplined and unpredictable.
As a coach, I don’t like to spend time fixing negative perceptions of Agile. My passion is making teams and organizations successful. I like to steer away from the waterfall vs. agile discussion.
Instead, I focus on sharing what I see happening in high performance teams and organizations:
Without knowing what value really is we can’t reduce waste. Afocus on customer value answerstwo key questions: (1) Who am I building this for? and (2) Why am I building this?Once we have a keen sense of what value is we can then prioritize our work to deliver the highest value first.
By delivering early and often we give ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can help us improve.
One of the biggest impediments to delivering early and often is the inability to reduce batch size and many teams struggle with this. This is a battle worth fighting.
Another impediment to delivering value is not pull testing forward. If we don’t complete our work as we iterate then we are creating technical debt that will affect our ability to release.
Successful teams know it is best to take small incremental steps towards improvement and to establish a rhythm of continuous improvement. We don’t try to define the perfect process, we don’t set the bar too high and we continuously inspect and adapt.
As Émile Chartrier once said “nothing is more dangerous than an idea when you only have one”. Successful teams and organizations know that to survive long-term they need to create a collaborative culture that fosters innovation and shared commitment.
Are these are agile principles or lean principles? Some like to draw an ideological line between the two but like Wille Faler I don’t believe that’s a bottom-line discussion. Call them waterfall if you like, so long as you’re successful.
You might not like my list and that’s fine too. Make your own list but don’t just pull it out of a book. Visit the gemba and come up with something visceral that your team can identify with.
I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
In one part of the comment stream, I heard and felt the call for an effort to get to the root cause of such deep-rooted assumptions.
According to the Systems Thinking Toolbox from Pegasus Communications,to break an Escalation structure, ask the following questions:
What is the relative measure that pits one party against the other and can you change it?
What are the significant delays in the system that may distort the true nature of the threat?
What are the deep-rooted assumptions that lie beneath the actions taken in response to the threat?
So, in our system of sharing information in the Agile community, we have to ask, “Are we setting up a dynamic that pits us against one another?” If this is true, then we have to ask, “How can this be addressed and still ensure that we share insights?”
Guided by Systems Thinking, that means we need to check in with: what is distorting our communications and what might our deep-rooted assumptions be that would have us act as we do?
Here is an example:
I created a delay in feedback by my not responding to posted comments. I believe that created assumptions around what I may or may not have intended in the post. I think some individuals thought I had written the post pointed specifically at them. Faster feedback would have helped quell that assumption.
I was writing about, and continue to write about, the Systems Thinking Escalation archetype and how I see it in our community. I was and am looking at a dynamic not at an individual. Escalation is NEVER about an individual; it is about the system in which blame is occurring and allowed to continue. I am fearful that blame and the win/lose game are in our system and that is what I do not like and I want to address.
Some of the comments to my post seemed to indicate that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must.
In this model, Kaner insists that, to get to high performance we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.
Conflict in this context is dialogue. It seeks insights. It invites greater and greater participation. I also want to emphasize that in this context of dialogue and non-escalation, our purpose is to engage in forward thinking. We let go and we look forward. And as we look forward, we let go.
So, as a member of the Agile community, my interest in expending energy in discussions is to seek insights, encourage divergence, and discover convergence as it emerges. All of these practices help and encourage me to create more and more forward thinking. If this is not occurring in our community, then we are not getting enough for the energies we expend. If in our community we really “must win” in order to “be heard”, we are stuck in an “Escalation” archetype. And, that means we are all trapped on an up escalator to nowhere.
What could any individual do to break an escalation pattern in a system? Create energy around your insights and share them without a need to apply win/lose stakes. Stop expending energy to refute others.
Here is a simple formula for bringing your viewpoint to bear without escalation:
Show up. (Be willing to be engaged.)
Find out what has meaning to you. (Be willing to be honest about your perspective.)
Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
Let go of what happens. (Be courageous enough to allow others to agree or disagree.)
I believe this formula provides guidance on how to remain forward thinking, remain open-minded, and remain engaged.
I have some more mental models I want to offer here. But they will wait for another post.
Thank you in advance for your considerations, insights, and comments.
Clippy - the ultimate bearer of redundant information
Remember this guy? He used to pop-up when you least expected him and offered up information about something you already knew.
I’m sometimes reminded of Clippy when I hear the rhetoric from some in our Agile community.
We’re at an inflection point right now. The pragmatists and the conservatives are realizing the fallacy of large upfront planning.
As teams from these later adopters are striving to become leaner and more Agile, they struggle with the inertia that is inherent in large organizations.
They know that co-located teams are more successful but they prefer an environment that extends the benefits of working from home.
They know that it is much more efficient to work on one task at a time but someone way above their pay grade won’t let them have such a single minded focus. This is not a battle they can win right now.
They know that value can be delivered faster if testing can be pulled forward yet they don’t have budget to buy the tools they need.
For such decisions Clippy always knows the right answers for everybody. But Clippy doesn’t have to walk in their shoes and it won’t be Clippy who gets fired for taking a risk.
“Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”
“I think we need to acknowledge that there are parts of organizations that will be less agile than others while moving from traditional to agile projects. That the big ole ship can’t turn on a dime. To me this is part of being a trusted partner.”
As you strive to become leaner and more agile, you don’t need Paper Clip Consulting, you need a trusted partner. You need someone that will begin with the end in mind yet not seek to get there immediately. A trusted partner will take the time to understand your environment, accept that there are always constraints and help you establish a cadence of continuous improvement.
About the Author: Ken Clyneis a kayaker, Certified ScrumMaster and Agile Coach at Rally Software Development. Subscribe today to get free updates by emailor RSS.
Remember this guy. He used to pop-up when you least expected him and offered up information about something you already knew.
I’m sometimes reminded of Clippy when I hear the rhetoric from some in our agile community.
We’re at an inflection point right now. The pragmatists and the conservatives are realizing the fallacy of large upfront planning.
As teams from these later adopters are striving to become leaner and more agile they struggle with the inertia that is inherent in large organizations.
They know that co-located teams are more successful but they prefer an environment that extends the benefits of working from home.
They know that it is much more efficient to work on one task at a time but someone way above their pay grade won’t let them have such a single minded focus. This is not a battle they can win right now.
They know that value can be delivered faster if testing can be pulled forward yet they don’t have budget to buy the tools they need. They understand very well the return on investment and to Clippy it’s a no-brainer but Clippy doesn’t have to walk in their shoes. Maybe Clippy needs to talk to the CFO.
Maybe Clippy needs to listen to Norm Kerth (from his book Project Retrospectives)
“Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”
or as my colleague Julie Chickering says:
“I think we need to acknowledge that there are parts of organizations that will be less agile than others while moving from traditional to agile projects. That the big ole ship cant turn on a dime. To me this is part of being the trusted partner.”
I was teaching a CSM course a few months back when a question came up, as one often does, that needed an answer built around the concept of swarming.
An extremely creative example of the swarming concept
Swarming is something that is strangely alien to many folks in software development, so I’ll explain it here. Also, if I don’t explain it here then I won’t have enough to make a good blog post, and we can’t have that, can we?
The idea of swarming is to get the whole scrum team, or as much of the team as possible, to all jump onto a Product Backlog item (PBI) together and get it done in one fell swoop, as quickly and decisively as possible, by working together.
This has the benefit of being fun while at the same time implementing the idea of value-based delivery on the micro level. If a team swarms, it will tend to complete PBIs one after another rather than starting on several PBIs at a time and not completing any of them. So swarming on PBIs in priority order tends to deliver them in priority order while at the same time reducing the number of partially done PBIs (often called Work in Progress and considered to be a Bad Thing) that are hanging around waiting to be finished.
Swarming is something that good scrum teams do.
Side note: Those of you who are constantly asking what to do about the problem of testers not having anything to do until the last two days of the sprint, you should read this post twice. Those of you who are constantly carrying over unfinished PBIs to the next sprint, read this three times.
So, in response to the question, I told the story of swarming to the CSM kids as we sat around the campfire in the training room, eating smores, and they were enraptured. Entranced, really. Lightbulbs were flashing above heads. For some reason, for this class, the idea of swarming really hit home.
We had already discussed the Tuckman model of team dynamics earlier in the course. The Tuckman model, based on observations of lots of teams, simply lays out a four-stage pattern that teams seem to go through as they evolve.
The four stages of the Tuckman model are Forming, Storming, Norming, and Performing.
Forming is fun because everything is new and nothing bad has happened yet. Of course, not a lot gets done during this stage, comparatively speaking.
Storming is what happens as the team begins to try to get work done and the inevitable power struggles and turf wars begin. It’s not a particularly fun time, but it seems to be something that just happens when people try to work together.
Norming occurs as the team resolves its internal strife and figures out how to work together.
Performing is where the team can go when they learn to improve from their Norming plateau into a highly productive, smoothly-operating group of peer professionals.
The phrase “Forming, Storming, Norming, and Performing” is familiar to people who have been exposed to the Tuckman model for as little as 2.5 minutes.
So, in a burst of enthusiasm, one of the students in my class (remember the class?) suddenly shouted (well, to be honest, he only said it in a loud voice) “Forming, Storming, Norming, and Swarming!”
Which was great because Swarming is kinda one quick way to describe a Scrum team that is in the Performing phase.
Everybody laughed happily, and I thought, that’s a blog post right there. And look! I was right.
About the Author: Alan Atlasis a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
I do not believe there is a recipe for Agile enterprise transition plans because good ones must take the context and setting of the organization into account.
I do believe that starting step-by-step is the only way to get the snow ball of incremental improvement rolling down hill. Our model, Flow-Pull-Innovate, is based on a strategy of creating a self-funding sustainable approach to adopting Agile; where some of the savings/profits from each step are reinvested in the next improvement step. (See my post An Alternative to Agile Adoption Cookbooks – Flow, Pull, Innovate for details on this approach.)
In addition to a step-by-step transition plan, you need a vision, shared commitment and social contract to be successful. Although, The Flow-Pull-Innovate model does provide sign-posts for your roadmap, the actual stories necessary to transition vary. When we work with groups or organizations to build a plan that will take them from one step to another, we use a transition planning model that I helped define in the mid-1990′s. This planning model is based on organizational change work from Peter Senge’sDance of Change and Michael Hammer’sReengineering the Corporation.
In this step-by-step plan, we use these high-level variables for planning change; “Strategy, Process, Organization and Technology.” In these transition steps, a typical story starts with the implementation of new technical and organizational infrastructure to support new methods, tools and techniques that lead to new way of working. Download An Example Transition Plan (PDF).
An Example Transition Plan based on the Flow-Pull-Innovate model for Enterprise Agile Adoption
Again, please note this plan is very high-level and a fairly generic application of the Flow-Pull-Innovate approach. (See Jean’s post on What’s So Great about Flow? for more details on the first step.) I have seen many variations on these detailed plans over that last 6 years. Use this as a simple starting point for you and your group to think about your own situation. If you work with Rally coaches to help you plan your organization’s transition, you benefit from their years of experience and ability to start with a clean white version of this model.
Transitioning to Agile at the enterprise level can be a very simple step-by-step process as long as you and your group thinks about it in this way. If you do a good job of defining “Done” for your steps, you will then be able to inspect your progress and adjust your plans based on empirical feedback. In this way your adoption approach is just like the Agile process your adopting for software development; an empirical process that you steer with regularly schedule inspection and adjustment.
If, on the other hand, you think about the adoption as a “Big-Bang” that will be done on a certain date, I believe your “plan-driven” thinking will cause you to miss the real opportunity. You will typically end up with only incremental improvement and not have the momentum to enable your teams to keep up the good work. And, you will fail to get on the continuous improvement curve that will lead towards Agile/Lean expertise. Given that most organizations are operating in a “plan-driven” world, this is not a surprising reaction to Agile adoption. Agile success comes as you gain success incrementally by taking one step after another, while keeping process, technology and organization change areas aligned.
In CMMI, Level 5 teams get to a place where they “become continuous improvement teams.“ In enterprise Agile adoptions, we start folks at continuous improvement and watch them benefit from creating employees and teams that both solve their own problems and continue to re-focus on value delivery through each step.
Your company is insane and you might be insane, too.
I bet you’re suspicious right now, aren’t you? You think this sensational opener is there just to suck you in and get you to read something that’s totally unrelated. Well, I mean what I said. Let me explain.
There’s this old joke. I think it’s a joke. Maybe it’s a saying. Or it could be an adage. I’m pretty sure it’s not an axiom and I know it’s not a koan. Hmmm. Might be a riddle. Anyway, where was I?
Oh yeah. The joke. It goes like this:
Q. What’s the definition of insanity? A. Doing the same thing over and over again and expecting different results.
OK, so maybe “joke” was stretching it a little, but it is kind of pithy, don’t you think?
Why do companies want to adopt Agile methods?After all, it’s expensive and painful what with all the training and change management and readjustments and FUD (Fear, Uncertainty, and Doubt) and so forth. And why do people come to CSM courses hoping to find new ways to build software? Because they’re bored and they want to get into arguments with their management? Probably not.
I think the reason is the same for both. It’s because pretty much everybody wants better (different) results from their software development efforts. Management wants more software to sell, and they want it to be higher quality, and to arrive faster, and to be more liked by their customers.
Employees would like at least an even chance of succeeding in what they do, and they’d like to feel like they are contributing the best that they have to offer as a valued part of their company. They want to feel like an accomplished, highly skilled professional and not some interchangeable cog in a soulless production machine.
OK, fine. So far so good. Everybody is aligned. It’s win-win all around. What could possibly go wrong? Well, here comes the funny part. Nearly all companies, nearly all management teams, and many employees don’t seem to understand that getting different results is going to require doing different things, or doing things differently (I’m not sure if those two are the same or not).
When I’m teaching the CSM course or introducing Agile at a company, the minute I bring something up that is actually, obviously different from what they are doing today, somebody gets upset.
When one of my students gets upset, they start raising objections such as:
“Oh, well, we can’t do it that way at our company.” (Betcha you can.)
“That’s not how it is at our company.” (Isn’t that what I’ve been trying to tell you?)
“But what about having the complete architecture before I start? I have to have that!” (Should I do this the nice way or the mean way?)
“We can’t do all of that testing. We don’t have testers.”(Gosh, I hadn’t thought of that. I guess you’re right. Just do the Agile without the testing and you’ll be fine. I’m sure no one will notice.)
“We don’t actually have anybody who could be the Product Owner.”(Do you hear what you’re saying?)
“We have a very mature phase-gate development process that we have to keep in place as we move to Agile.”(Say what????)
“I’m a manager and I’m paid to leverage my maturity and experience by telling people what to do so they don’t make mistakes. I’ll be doing that with the Agile teams, too.”(Don’t roll your eyes…don’t roll your eyes…)
“Our QA is in a separate group and they won’t talk to us until we have a complete set of specs to give them.”(And how’s that working for you, and them, and your company?)
And on and on and on. I talk about this when I teach Agile to new teams or new CSMs and CSPOs. Then later on during the class, when they start in with this stuff, I can get away with saying:
“Oh! So you mean your company is insane. They sent you here to learn a new way to build software, but they won’t let you build software in a new way!”
This is fun because I get to call companies and my students insane in a way that’s fun and also makes a point.
What to do about this is a serious question for those of us who coach, train, consult, or champion Agile within our organizations. Teams tend to get it, but I fear that companies of a certain size tend not to get it. And they keep not getting it while their Agile adoption loses steam, fails to deliver as well as it could, and finally fades away entirely. This is where many of those “scrum failed” stories come from. What happened was that in reality, they didn’t really try scrum because they were afraid to change anything.
Your company is insane because what they wish is that you could somehow get all the benefits of Agile without making any difficult or scary changes. You might be insane because you think some things can’t be changed and we can still get the benefits of Agile without changing them. As long as either you or your company is insane, neither of you will get the benefits of Agile adoption.
I guess that’s all I wanted to say.
About the Author: Alan Atlasis a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
Recently, I filmed several “Chalk Talk” videos about some of the basics of Agile software development.
These 3 – 5 minute informal videos are intended to provide quick, easy introductions to Agile topics. This first set of talks focus on thee Agile Manifesto, the Iteration Retrospective, and the Iteration Demo and Review (yes, I think these latter two are different!) My intent here is to provide you with an alternate way to get access to these fundamentals.
These easy-to-follow videos are great resources to share with your team as they are getting up to speed on the Agile process.
Besides being a quick-start source for your own team, consider using these videos as a quick reference for others. They can be an easy introduction to Agile for people in your organization interested in getting some basic “look-and-feel” without having to read several books. My hope is that each “Chalk Talk” starts or furthers a conversation about the particular topic. I started with the Agile Manifesto in order to lay the ground work about why anyone should care about Agile, what were its roots.
The other two topics are provided here are in no particular order. They are just topics about which I am passionate. I also chose these 2 “Chalk Talk” topics because I find they are very often misunderstood with regard to purpose and attendees and agenda. See if these meeting descriptions look like your iteration meetings.
I have some other Chalk Talks already queued up, so stay tuned! I plan to keep recording Chalk Talk videos around Agile principles and practices. I’d love to hear your feedback on what other topics you’d like me to cover. Coming up, look for an overview of Scrum and some of the other meetings we use in Agile. For now, watch these videos and tell me what you think.
The Agile Blog is proud to present the first post from our newest contributor, Agile Coach Ben Carey
As part of our coaching at Rally, we usually recommend that new Agile teams use capacity as a countermeasure for not having a historical velocity. Considering individual and team capacity can help the team make an informed commitment for their iteration plan if they don’t have a historical velocity.
One general way to calculate the capacity can be seen below:
A team can use their individual capacities to indicate the maximum theoretical amount of work that each individual can complete in an iteration. Reviewing individual capacities against task estimates can help the individuals not over-commit and also help the team determine the amount of risk in committing to the stories that have been chosen for an iteration.
You can see your utilization percentage in Rally by looking at the Team Status page. As a general rule, I usually recommend that a team try not to exceed 70% of their capacity for each individual on the team.
There are many times that this recommendation is met with resistance because of the basic assumption that 100% utilization (total work divided by capacity) is the ideal state. I’m often asked to justify my general rule of 70% and asked why I would pick a number that is lower than the maximum.
Why I recommend capping individual capacity at 70%:
At a basic level, it seems to makes sense that we want everyone to run at full capacity. If the capacity exists, why shouldn’t we use it? Why would we ever want someone to do six tasks if they have the capability to do eight?
The problem with the 100% utilization mindset is that we have assumed that our outcomes of the iteration are fully deterministic.
When we consider the delivery of software, we need to acknowledge that a given set of inputs do not always result in a given set of outputs due to various degrees of variation in multiple aspects of the process (e.g. fire-fighting, estimation precision, defect introduction, management directives, interpersonal interaction, et cetera). In reality, software development activities are stochastic in nature.
If we look at other areas that are defined as being stochastic, we can build a mental model that can help us understand why 100% utilization isn’t the ultimate desirable state.
A few general observations, you’ve likely noticed:
The highway typically slows significantly below 100% utilization (the maximum number of cars that can fit on the road).
The rate at which the highway slows is non-linear. Traffic will start to slow significantly faster between 80% and 90% utilization that it would between 40% and 50% utilization.
When accidents occur or a lane shuts down, the effect is much more significant at times of high utilization (rush hour) than at times of low utilization (late night).
The likelihood of reaching gridlock in a fully utilized highway becomes almost certain if it fills to capacity.
These observations can all be attributed to variation in the process.
In many ways, creating software is very similar to driving along a highway. There are a variety of unknowns, a variety of random events that might occur, continuous minor corrections, and a variety of options in getting to our end goal.
Luckily, software development isn’t the only place that we can look for to get some guidance on how to effectively determine our utilization.The nature of stochastic systems has been studied in many fields (telecommunications, fast-food restaurants, transportation systems, manufacturing, processors, and many others). In many of these fields, the general approach at modeling the variation in the system can be found in the study of queueing theory.
If we look to queueing theory, we can find some level of guidance with the following general capacity model.
This model shows us that utilization in a stochastic system follows a power-law distribution.
As we reach the upper levels of utilization, the nature of the work we are performing will likely lead to intense thrashing and will likely have impact across all areas of the work that we are performing. If anything doesn’t go exactly to plan or any other non-planned items come into play, we are likely to jeopardize our commitment.
Given the rate that these items tend to occur, I recommend not aiming for 100% utilization.
Bottom Line: When I see a team of individuals that have (1) calculated a realistic capacity, (2) applied honest estimates to their tasks, and (3) targeted a maximum capacity of 70% – then I feel good that they have done their best to provide a realistic commitment to achieving the completion of their stories for the iteration.
[ Check out more posts from Ben Carey by visitng his blog - The Sherpa Project ]
RallyDev.com
I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
Your company is insane and you might be insane, too.
