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.
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.
In the last month, I have gotten the question “Where does Agile *not* work?” numerous times, mainly from large firms planning their first Agile rollout efforts. That question is quickly followed by, “And I don’t want to hear that it works everywhere!”
Admittedly, that’s a tough one for me. My answer is that Agile approaches can be applied anywhere – from your home moving project to the creation of space crafts. So I usually flip the question. If Agile conceivably could work anywhere, the question is really, “On which projects do you choose to start your Agile adoption?”
Where To Start
Jean and I and our fellow Rally coach Ronica Roth tend to apply two criteria: the strategic importance and risk of the effort. The iterative nature of Agile development is going to provide you with the tools to steer a risky and highly strategic project much better than phased development approach.
Our rendition from "Stand Back and Deliver"
In their new book Stand Back and Deliver, Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald provide a more elaborate portfolio model to assess your efforts. They map uncertainty versus complexity in a 2×2 matrix with nice labels of colts, bulls, sheepdogs and cows. I find the model is very effectively elaborated in the book and some very useful implications for staffing, selecting and managing the value flow are discussed. The variables used in the book include:
Complexity Attributes: Team size, mission critical, team locations, team maturity, domain gaps, dependencies
Three Perspectives
We agree with the authors, the best place to start using Agile practices are projects that are High Uncertainty (because you leverage Agile to learn as you go) and Low Complexity (to avoid the headaches of technical risk).
If the risk to the business is significant, such as eroding market share or the possibility the project will be canceled, then accept the technical risk and use Agile for a High Uncertainty-High Complexity project. The use of Agile will help with the uncertainty. It will be important on those projects to increase the discipline level around process and communication.
Projects of Low Uncertainty and Low Complexity rank third. They could easily transition to Agile and benefit from the improvements to productivity, quality, and collaboration. Yet they don’t need Agile to be successful. For these projects, the tie-breaker may be the next set of criteria – the environment.
Environmental Factors
Once the project is right for Agile by its nature, the next question is whether you can quickly create an environment for success. Many people talk about this as the organizational readiness for Agile or assess these concepts via Agile team assessments. Here is a snippet of that kind of team assessment:
Does the Product Owner have the right level of authority and influence? Are they…
Embedded with team?
Dedicated to the project?
Able to gain consensus from stakeholders on goals and features?
Able to evolve the product backlog (with training)?
Able to support the team through constant feedback and decision-making?
The team is dedicated to the work being planned using Agile (note: The team could actually work on multiple projects, as long as they are working a single backlog and work from all projects is scheduled via Agile planning cycles).
ScrumMaster, Product Owner, Product Development and Quality Assurance must be full-time dedicated resources.
Other resources might be part-time for any one Scrum team, but they should be spread across as few Scrum teams as possible. These include: Database, User Education, Apps Architect and Ops Architect.
Architects might be contributing members, or might be advisory.
Is the team co-located?
It’s not required, but can be a risk factor.
For distributed teams, it is important to have good communication constructs, and to have a leader in remote locations to partner with the ScrumMaster and Product Owner of the core team.
Do you have an Uber Product Owner and Uber ScrumMaster?
For multi-Scrum-team projects, it is important to have an overall Product Owner and ScrumMaster to own releases and communication across teams.
Is there a controlled build environment?
To ensure quality and a smooth flow of work, the team should be able to provide QA with builds multiple times during a two-week sprint.
As a Scrum team matures, and to increase velocity, the team will want to integrate code to a shared dev environment continuously (at least daily).
You can get a copy of Rally’s Team Agility Assessment and we welcome your feedback. I hope you will buy their book and try team assessments to help you map your own approach. To me, Agile works everywhere, it is just a question of how good do you want to be and by when.
“The greatest obstacle to discovery is not ignorance – it is the illusion of knowledge.” – Daniel J. Boorstin
Here’s something your team should look to avoid – Cargo Cult Scrum.
Members of the John Frum cargo cult
Cargo Cult Scrum is what happens when you adopt the practices, vocabulary, and artifacts of scrum but you don’t understand why or how they work. Cargo Cult scrum is bad. It is accidental and is based on ignorance.
Here’s a tiny piece of what Wikipedia has to say about cargo cults:
“A cargo cult is a type of religious practice that may appear in tribal societies in the wake of interaction with technologically advanced, non-native cultures. The cults are focused on obtaining the material wealth of the advanced culture through magical thinking, religious rituals and practices…”
When we talk about cargo cult implementations of scrum we are talking about people who seize on the advanced ideas of scrum and expect magical, unexplainable benefit to come from them, not realizing that informed usage is required in the bargain.
Craig Larman and Bas Vodde talk briefly about Cargo Cult Scrum adoption in their excellent book “Scaling Lean & Agile Development” in a section titled Avoid…Fake ScrumMasters. Fake ScrumMasters are created by “…Changing the title of someone to ‘ScrumMaster’ while he acts like – and is encouraged by the organization to act like – a project manager.”
They go on to describe the ultimate cargo cult scrum implementation:
“We adopted Scrum. Our Sprint length is the length of our project. The Product Owner decides the items in the Sprint and the project manager acts as ScrumMaster. He makes the Sprint Backlog and assigns the tasks to people in the team.”
So what does Cargo Cult Scrum look like?
Here are some examples that I’ve seen in the field:
I recently attended a meeting at a company that considers itself to be agile. It was a regular meeting that occurred every two weeks. It was not attended by a scrum team, but instead by a bunch of people from two different groups. The three questions were not used. The meeting was scheduled for, and took, 30 minutes. Yet the meeting was called a scrum. Other meetings at this company are called scrums, so much so that ’scrum’ has become a synonym for ‘meeting’. This is a cargo cult. The true meaning of ‘daily scrum’ has been lost, if it was ever apprehended in the first place.
I’ve also seen organizations in which people call every item on the Product Backlog a User Story (which is not the same thing as every item on the Product Backlog actually being a user story).
Another example is this actual [paraphrased] conversation I had with a potential customer:
Customer: Oh yes, we’ve been doing agile for a while. Coach: That’s great! So you haven’t had any trouble getting the Product Owner to work closely with the team? Customer: Well, we…uh…don’t really have a Product Owner. Coach: Oh. Well, who keeps the Product Backlog in shape? Customer: Well, we…uh…don’t really have a Product Backlog, per se. Coach: Oh. So how do you plan your sprints? Customer: Well, we really don’t do that in a very formal way. But we do meet every morning. That’s what it’s all about, right?
And my all time favorite. I was once told by a manager of a supposedly Agile group: “We like things the way they are. We know it’s not perfect. We don’t want to change.” Yikes. So much for Continuous Improvement.
Though you shouldn’t do Cargo Cult Scrum for any reason, the reality is that any step down the road to scrum is usually better than whatever preceded it.
Don’t feel bad if your scrum implementation isn’t the same as what’s in the books. Feel bad if you are have stopped trying to make it better.
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.
I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.
One of the replies on the Agile Alliance Group of Linked-Incountered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.
“The term Oxymoron originates from the Greekoxy (”sharp” or “pointed”) and moros (”dull”). Thus the word oxymoron is itself an oxymoron.” Wikipedia’s Etymology for Oxymoron
Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.
Agile as an umbrella term
First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code. It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.
My rendition of the geneology of Software Development Approaches
Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.
I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.
Lean merges with capital-A Agile
I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.
Small batch sizes, short cycles that create rhythm
Reduction in queues through pull
Reduction in work in process inventory
Design quality in
Stop-the-line defect control
Value streams the link to the customer
Integrated learning through reflection
Last responsible moment decision making
These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD. I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me.
What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?
At Rally, we often get questions about how Agile fits in with a variety of other practices and processes, so the below questions about Agile and CMMI, Agile and RUP, and Agile and Architecture come as no surprise. Stay tuned for the final Q&A on Agile champions.
DW – is Dave West from Forrester
RAM – is Ryan Martens from Rally
How can Agile be integrated in a CMMI certified application in regards to the tremendous amounts of required CMMI artifacts (documentation)?
DW – The flippant answer is it can’t. ☺ But actually I have seen some great systems integrators use CMMI to help check list their processes of which some of those processes are Agile. Agile development works really well at the team level, but it needs to be surrounded with other processes. CMMI makes sure you remember those processes, some of which are inside the Agile team, others are not. The PA’s always seem to imply lots of documentation, but they do not have. You can keep the documentation to a minimum, but still deliver them. Do not, however, burden the Agile team with proving their compliance – Use the checklist, build the software and get others to prove they did what they said they did.
RAM – I am not quite as negative as Dave on this topic. CMMI and Agile combine just fine. There are a number of proof points that are easily found from past Agile conferences and by searching “Agile and CMMI.” The problem is that many folk misinterpret CMMI and are convinced that it mandates waterfall, heavy process and heavy documentation. According to SEI, it does not. Most teams would not adopt CMMI without a specific business need.
The other day, I noticed that the water is draining rather slowly out of my bathtub at home. That is annoying…
It means that I haven’t really kept my drain as clean as I should. Or perhaps I should be “snaking” the pipes more regularly. One thing for sure, if I don’t get this fixed, eventually my tub will stop flowing entirely. If I try to add water, my bathtub will just overflow and I won’t be able to use it without a major plumbing expense. Ugh!
What does this have to do with my latest topic of cutting costs with Agile development? Well, I’ve been reading a great little book by Linda Booth Sweeney, When a Butterfly Sneezes. It’s a sweet, simple way to learn about systems thinking by using children’s stories for examples of various systems’ archetypes. To kick things off she uses a bathtub analogy to explain stocks and flows and how they impact one another.
Aha! That is what I care about when I am developing software!
Imagine that the faucet to my tub is all the features I am putting into my product. My bathtub is my product stock. As I add features, my bathwater level goes up. Now think of the drain as the “flow” by which I get the “stock” out to my customers.
If my drain is clogged up even a little, I can’t get the flow of features, my value, out to my customers as quickly as I’d like. And if I have a really bad situation, then I actually can’t keep adding features into my stock (my bathtub) because it will just overflow. Features (value) will never get to my customers. They’ll just end up as a major mop up for me, lots of work that doesn’t deliver anything but frustration.
So what are the clogs in my software bathtub? Defects.
A few defects unattended to will just slow down my value delivery. Not too bad. But if I allow defects to accumulate, that technical debt can bring my value delivery to a crawl. I’ve got lots of stock and yet my inattention to defects has cut off flow to my customers. Crumb.
Agile cuts costs because it requires us to keep our drain clean, not let defects accumulate. Agile guides us to not over-emphasize adding features to our tub while disregarding accumulating defect residue. Rather, we are guided to add high-quality features with a zero-defect mentality. Think of it this way -
Adding a little Scrum will help you eliminate the scum.
Now, whenever you are ready to open the drain for a release of software, there are no last minute plumbing repairs necessary to let the value flow. Keeping the drain defect-free means I can keep adding features into my stock and let them flow out anytime I want. I can even have sustainable, even continuous, inflows and outflows to and from my stock. The cost of delivery of value slowly goes down, I have sustainable and reliable flow, and all because I was willing to do a little continuous bathtub maintenance.
Don’t let defects clog your feature bathwater. Use Agile to stop the defect clogs and keep the value water flowing!
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.
Efficiency
