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.
At Rally, we are always working on both maturing and growing our use of Agile. We started with a single development team and over the past 6 years have been through the process of splitting, growing, partnering, and acquiring.
We did this while continuing to inspect and adapt our development and our strategy execution processes. We have teams in various stages of maturity using Scrum and Kanban to run all parts of our company. As the CTO, I have my focus on our strategic planning and execution process.
As part of that effort, we worked to change our quarterly and annual planning process to specifically follow a Plan-Do-Check-Adjust model. (Note that I like Pascal’s use of Adjust, not Act which is typically quoted in the Toyota models.)
Prior to 2009, we were simply using an inspect and adapt process to determine annual and quarterly priorities, aka quarterly rocks, based on feedback from last quarter’s results and the corporate roadmap.
This process worked well, but we had some issues including:
A moving definition of done based on different standards of work (research, implementation, campaigns..)
A delay in the feedback loop on strategic efforts made it hard to check and close well
Too many efforts in a quarter lead to poor quality (We found 5 rocks to be too many for us during a quarter)
None of these are different than what most teams experience with going Agile. So we (1) adjusted and moved to limit our WIP to three rocks, (2) focused on inspecting the definition of done in the meeting, (3) used company wide survey’s to keep from developing group think and (4) chose to do company celebration based on quarterly metrics and not the completion of quarterly rocks.
These all helped make the current process work, but the process was still frustratingly unpredictable, semi-random and always left something to be desired. Many of the reasons for this are explained in Alan Shalloway’s and Don Reinertsen’s posts on PDCA and types of process The Difference Between “Inspect and Adapt” and Plan-Do-Check-Act (PDCA). Unlike Alan, I do not see or perceive a big issue with Scrum. Based on my previous post around the roots of agile; Dean Leffingwell and I are in the same camp; Scrum is Lean.
As a result of moving to PDCA approach, we created a single “True-North” goal for the year and drove our quarterly rocks towards that goal.
Now in Q4 of the year, we had some new changes to our process. By following the PDCA cycle for the year, we put a fine point on CHECK in this final quarter; Subsequently, we have a Q4 quarterly rock focused solely on checking our Q3 and annual work to fine tune it based on real output. This is an example of where PDCA cycle is more intentional than basic inspect and adapt at forcing the discipline of checking.
We focused a quarterly rock on checking to make sure that we are done-done-done with our True North goal for the year. We also have another Q4, cross-functional rock team focused on preparing for Q1 and 2010 annual planning. This PDCA-driven rock is a major milestone for me personally. It moves annual planning solely from my shoulders to a team effort; this pushes ownership of strategy down to the extended management team. As a result, I am very happy with the move to PDCA for our 2009 strategy execution process. In Don Rienertsen’s terms, our PDCA-driven process is more defined, while still with un-predictable output and governed with lots of feedback. This was simply an increase in process maturity that was mandated by our continuing growth.
To do this, we create a team, called the Mountain team, to help the company transition our strategy execution process. This team steered the transition and proposed our quarterly rocks based on the PDCA process. And thanks to the ego-less and steady hand of our CEO, we have a very collaborative culture that quickly converge on these changes and quickly put them into action.
I hope this was helpful for you to learn about our experiences with continuous process improvement and our step-function transition processes. Please note that we are not a perfect comparison to larger organizations trying to transition to large scale agility. In addition to doing lots of growing, we have another difference that started when we began back in 2003. We built Agile and Lean principles into our core values. You can see the difference this might make in my comments to Israel Gat’s post More on Agile Social Contracts.
Specifically our core values are:
Create your own reality
Make and meet commitments
Theory-driven decision making
Treat people with respect
Support our community and give back
Maintain a healthy work/life balance
This is the social contract that we keep with employees. During transitions like this you need culture or a social contract to reinforce your moves toward Agile and Lean behaviors.
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.
In addition to being fashion forward - the Musketeers were also great at signaling the end of their stand-ups
I was struck recently by the low energy of a daily stand-up that did not signal the end. Some people headed back to work, others started follow-on discussions and others were not sure if the meeting was over or not.
The lack of a clear sign that the stand-up is over can lead to problems:
People feeling left out
Not having the right people there when decisions are made
Time wasted on interesting rather than useful discussions
People starting to question the merits of a daily stand-up that consumes a lot of team capacity
One way to avoid a never-ending stand-up is to have a clear signal at the end.
The ScrumMaster is the facilitator for the daily stand-up so I prefer that they not assume authority to close the meeting. I like a signal coming from anyone (not necessarily the ScrumMaster) followed by a response from all.
A friend of mine enjoys climbing. At the end of his daily stand-ups he would signal “On Belay?” and the rest of the team would respond “Belay On”.
Sports teams are good at signaling the end of the huddle. One of my favorites is the team portrayed in the classic book by Alexandre Dumas. The Three Musketeers would end their stand-ups with a single cry of “All for one” which then be followed by the refrain “and one for all”
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.
When I am coaching a team through their first iteration, I often have a Scrum Master and/or team lead pull me aside prior to the retrospective to express concerns.
Sometimes its about things they know the team should address in the retrospective.
(e.g. “we need to get better at estimating”)
It may also be about things they wish the team wouldn’t bring into the retrospective.
(e.g. “we want longer iterations”)
These team supporters are coming from a place of concern for the success of the team and their Agile adoption, but they aren’t trusting that the team will make the right decisions on their own.
They want me to make sure the team talks about - and only about – these specific items, sometimes asking me to explicitly bring the issues in with a softer (i.e. manipulative) approach. I tell them I can’t and I won’t.
I tell them they need to trust the team and trust the process to determine where to focus their collective energy, passion and time in order to improve their process and product. And almost always, the issue a compassionate and involved leader hopes the team will focus on is exactly what the team ends up discussing and moving forward with.
This isn’t just about the team taking responsibility for their work and their improvements, it’s about creating sustainable decisions the team can own.
Good team leaders and Scrum Masters create a space where teams can inspect and adapt safely and successfully, so they can continue to find ways to improve.
“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.
Ryan and I have been talking about quality and faster as necessary components of an Agile organization for awhile. A non-Agile view of a successful organization would have us believe that pushing more and more features into a release and to the market necessitates a loss, or at least reduction or great variance, in quality. In an Agile organization, the thinking is quite the opposite.
Curiously, when we speak of quality and faster inside Rally or with clients, we talk about each being indispensable to the other.
For a traditional, non-Agile case study, let’s look at the RCA case study Ralph Aguayo brings up in his book “Dr. Deming: The American Who Taught the Japanese About Quality.” At its height, RCA’s business model focused on getting as many televisions into the hands of consumers as possible. (Did your family have an RCA T.V. when you were growing up? Mine did!) Quality was secondary to the savings RCA could make from cheap components and speed of product to market. Cheap and fast meant greater profits. Well, as it turned out, no…
Nipper on RCA's first color tv set - the CT 100
Unfortunately for RCA, their model began to crumble when television sets started being returned due to defects, lots of them all still in the warranty period. The cost of attending to these faulty sets ended up being as much as 25% more than the cost of manufacturing the existing set.
Do you have a similar situation in your software product delivery? Are you trying to get profits by pushing features out with “defective parts” because they are “cheaper”?
And to throw another wrench into the works, are you taking so long to get these feature sets pushed out that you have too much of a delay in your feedback to find either the defects or the value of the features you pushed? In other words, is your emphasis on speed, at the expense of quality, coupled with very large feature-rich releases, exactly the wrong way to create greater value and fewer defects?
In an Agile organization, the entire organization concentrates on value delivery and quick feedback on that value.
That is, “are we delivering the right features to the market?” In turn, a real Agile organization understands, “there ain’t no such thing as a free lunch,” and they do increase throughput without the traditional expense of decreasing quality. Defects held in check through a “stop the line” mentality free-up the organization to always respond to value feedback information faster. Think about RCA. If your scarce resources are tied up in managing defects and “returns,” they can’t be working on new feature sets. Or the feature sets delivered are being pushed on defects not yet resolved.
And so, the notion of “quality and faster” is not so counterintuitive as we may have once thought.
We need faster and faster feedback loops in time-to-market in order to continuously improve our ability to deliver quality (defect-free and valuable) features back to the market. Symmetrically, we need higher and higher quality features that are not defect-ridden or dubious in value in order to respond ever faster and more innovatively to the market.
With regard to the video reference to Jim Collins, you can read the interview about his new book and his personal rhythm on the NYTimes site. Verne Harnish’s Gazelles.com teaches the Rockefeller Habits on business rhythm.
RallyDev.com
#3 in our list of the 
#4 in our list of the 
