Beware of the Meltdown: A CSP Shares Her Meltdown Stories and Tips for Avoiding Your Own

By Carrie Schonhoff

It happens when you least expect it. At some point when a Scrum team is just forming (despite training, agreeing on team rules, and doing some team building), most teams experience a meltdown. The good news is that once the meltdown has passed, these same teams really start to understand the Scrum framework. 

From Fear to Trust

This phenomenon is not unique to Scrum. I think it happens to all of us when faced with a change that we are not prepared for. I remember when my company changed its health insurance coverage and doubled the premium. I had a meltdown!  I started thinking, “How could this happen?” “I had no idea!” “Why do we have to pay that much?” Once I talked to a couple of people and commiserated with them, I began to accept the fact that I had no choice and this was the way it was going to be from now on. I moved on. After I got over the initial shock, the changes from Human Resources didn’t seem as harsh – I understood that changes to benefits were a given.

This is how it is with Scrum. We often react defensively as a kneejerk reaction to the changes Scrum brings. It challenges the way we’ve thought about not only projects, but how we have worked in the past as well. We're forced to confront the big picture we’ve been sheltered from, yet we find it hard to see it clearly. We aren't sure how to problem-solve. And now that no one is feeding us our tasks, we are supposed to think of what to do on our own. It can be overwhelming. 

Continue reading this article.

Owning an Agile Product: One CSPO's Experiences Driving Scrum Projects.

By Edward Wehr

Being a product owner and having responsibility for a product's development using agile methods can be a bit overwhelming. Creating any product can be challenge. With a product being developed at the speed of agility, these challenges increase. Nothing is more frightening than feeling out of control while going at a high rate of speed. Let me reassure you, though, that it does get better. The first time you drive down that agile highway (even if you aren't yet going fast enough), it's scary. But with practice and a good understanding of what to watch for, driving an agile project becomes easier.

Because training and certification for product owners is fairly new, I've included some wisdom I've gained from my time on the agile road, which includes guiding four different teams over the past several years.

Priorities Are Priority One.

What teams need most is a product owner who is able to prioritize the product backlog. This includes adjusting priority based on new information and juggling the team's needs for work against customer features. A product owner must understand and be willing to have the critical conversations with team members regarding stories (work) that are not direct customer features, yet will develop an architecture that will enable the team to achieve more work (higher velocity) in the future. Balancing all of these competing stories, and the emerging importance and changing priorities that come with them, is a constant struggle.

Continue reading this article.

The Quest for High Performance: How one CSP gets his teams off to the right start

By Tom Reynolds

Over recent months I have been working with Lyssa Adkins to improve my coaching skills. One of our areas of focus has been team start-up and our expectation that we have for our teams to become high performing. In our work together, Lyssa shared some team start-up exercises to use with new teams. I had an opportunity to put some of these ideas into practice recently and want to share that experience with the Scrum community.

Team start ups cover three areas:

• The process
• The team and individuals
• The project

This article will focus on the work I did with the process.

Starting a team off on the right foot is an essential part of building solid foundations for the team.  Don’t skip this step. It’s true that start-up exercises take some effort and thought to prepare; however, the work that is put in at the start will pay dividends further down the line.

Continue reading this article.

My Journey as a Coach: How I came to be a coach and why you should be one, too

By Skip Angel

Helping others. That’s been my purpose in life at even an early age. When I saw somebody in need, I was there to help. When a fellow student didn’t understand an assignment or how to apply something new that they learned, I was usually there helping them figure it out. As a developer starting out my career, I often paired with other developers and worked through solutions, well before agile came into being. As a manager, the chance to mentor others and improve processes to make life easier for others was the parts of the job I enjoyed the most. I guess you could say I was destined to become a coach, it seemed to be part of my DNA. 

After learning and applying Scrum to an organization where I was the Chief Technology Officer, I realized that I needed to help other organizations as an external coach. Some thought I was crazy, giving up a key position in a stable company in very unstable times. Though there have been risks, the rewards that have come with coaching far outweigh them. I have been involved in both small and large organizations, with various size teams across many locations throughout the world. There is no better thrill than when a person comes up to me and says, “I now know what you have been talking to us about and I get it.” My goal for every company is to reduce the pain of delivering software and bring the fun back so people enjoy their jobs. My greatest joy is when my coaching makes a difference to the operations and bottom line of the business. It is these situations that drive me towards continual growth and improvement in my role.

Continue reading this article

Going from Candidate to Certified Scrum Trainer: A CST shares his advice on surviving the CST application review process

By Michael Vizdos

So you want to be a Certified Scrum Trainer. And to do that, you are entering into the candidate review process. Or maybe you’re just curious as to what it takes to earn the Certified Scrum Trainer designation. Wherever you are on your agile journey, I wanted to take a moment to give you my two cents on the new candidate review process from the CST perspective. We’ll talk about what the process is, what I’ve learned so far, and what it means (and doesn’t mean) for the Scrum community as a whole.

The Process Itself

First, please remember that certifications from the Scrum Alliance, whatever they are (CSM, CSPO, CSP, CSC, or CST), are really just the beginning of a journey for people who receive them.  I received my initial CSM in 2004 with Ken Schwaber, and at the end of 2006 was designated as a CST (also granted by Ken Schwaber). The process has gone through many iterations over the years. While I have watched this happening, I have learned one thing -- the process will continue to evolve.

It must. Over the past six months, the Scrum Alliance has been trying some new techniques for a person to become Certified Scrum Trainer (CST).  The current process, called "V8", is located at http://bit.ly/simple-CST-process-v8. Today, as long as you are a Certified Scrum Professional (CSP) you can follow the five-step process and apply to become a CST. The first part of this process requires the CST candidate to register a statement of intent and have two people from the current CST community vouch for their integrity and act as their champions through this process.

Continue reading this article.

Adopt with Care: One CSM's 8-step approach to successfully transitioning to Scrum

By Prashant Pund

Do any of these statements sound familiar?

“Sure, we're using agile methods. I mean, we aren't entirely sure, but we think we're agile.”
“Well, the team conducts daily scrums, so they must be agile.”
“I have been tense since this guy introduced Scrum. Every morning I have to give a status report. It’s really taxing.”
“This fellow read something on the Internet about Scrum and said, let’s start Scrum tomorrow. I'm not worried. It's just another fad to ride out.”
“I heard there is a change in our process. The Process Group person is here to explain the new process, something called Scrum.”

If so, your organization likely is suffering from Scrum Mis-adoption Syndrome (SMS). SMS causes disinterest, failures to deliver, and profound distrust. The best way to treat it? Prevent it from happening in the first place.

A successful Scrum adoption requires a profound transformation of the organization. This change will be felt at the team level, yes, but will ultimately affect all layers of the organization. This then begs the question, How can I, being at the level of PM/Lead, bring in such a transformation? Shouldn’t it come from the top? The answer is both Yes and No. Yes, because indeed the transformation needs to have buy-in and support from the top. No, because a top-down approach is not sufficient. As Mike Cohn puts it, “Change is not top-bottom or (emphasis added) bottom-up; it’s both." In view of this, here is the approach I suggest to those who are trying to transition to an agile methodology such as Scrum.

Continue reading this article

From Meager Beginnings to Masterful Ends: Taking Scrum beyond IT One Iteration at a Time

By Maria Matarelli

I’ve used Scrum on many software development and IT projects.  In addition to the projects I was working on, I received a request to work on a role-advisory team tasked with analyzing the effectiveness of a specialized project role.  This new team was pulled together with minimal allocations and replaced a full-time team that had just been disassembled due to budget cuts.  Given the constraints and uniqueness of the project, we decided to use Scrum for our approach.  It worked—flawlessly.

Demanding Circumstances

The going was uphill from the start.  We were a team of ten, allocated to contribute only 20 hours per person over the entire calendar year.  The team was just told, “Go.”  Success was undefined and the scope was unclear.  With a meager budget and minimal direction, we had to guide role development, training, knowledge sharing, and create a solution to provide overall direction to support more than 150 people.  The only thing we knew for certain was that the requirements were bound to change as work progressed.

As we discussed our options, it became more and more apparent Scrum was the right approach.  The limited ingredients and project constraints were the perfect recipe for a self-directed team.  Though we could have easily made the business case for additional funding, we were told from the beginning that “additional funding is not possible.”  Any solutions we found would have to be found within the team itself.  Frequent, incremental deliveries would help bring clarity to the project vision.  Though only few of us had used Scrum outside of IT (and most of the team had never used Scrum at all) we felt it was the perfect solution for the constraints facing our team, constraints that probably sound familiar to many teams out there.

Continue reading this article.

Are We Headed to Abilene? How the Abilene Paradox Hinders Team Collaboration

By Badri N Srinivasan

Collaboration is an important aspect of any complex activity. On complex projects, a single individual cannot guarantee successful customer delivery—one that meets schedule, quality, cost, and other parameters. It takes a cohesive team.

Scrum promotes these cohesive, self-organizing teams. Scrum teams are tasked with finding the most optimal way to accomplish the work. To do this, they make decisions ranging from how best to meet goals to who should work on which tasks. Reaching group consensus can be difficult. Some opinions are more dominant than others; some voices more hesitant to speak out. Even in agreement, true consensus might not exist. One manifestation of this is the Abilene Paradox.

Abilene Paradox Explained

The Abilene Paradox happens when a group of people collectively decide on a course of action that is counter to the preferences of any of the individuals in the group. This occurs because each member mistakenly believes that his own preferences are a contradiction to the group and, therefore, does not raise objections. When this happens, team members, in an effort not to "rock the boat," don’t voice their thoughts, desires, or intentions.

Continue reading this article.

Go with the Workflow: Focus on process instead of definitions to help new teams deal with product backlog items

By Henri Stegehuis

I love my work. Implementing Scrum is fantastic. Every company I work with has different processes and cultures. Coaching teams in this drastic new approach we call Scrum is always fun (afterwards). Working with people, breaking traditional patterns in common sense, creating a physical/visible presence, and fostering honest communication is a roller-coaster experience. Every team is unique, every time surprising me with interesting reactions and sometimes unexpected results.

In the past, some of these unexpected results have sprung from my attempts to explain the concept of a product backlog item (PBI). For teams raised in traditional development, the ins and outs of product backlog items can be difficult to grasp. When I talked with these teams about PBIs, I made the mistake of going into too much detail too early. I would start with the definition, explaining that a PBI is "up to half of an A4 page describing a requested feature from a market point of view." This, while a correct description, opened the floodgates for the skeptics and perfectionists within the team, who asserted that there was no way they could write a complete product backlog item in that amount of space. We would get off track, and it would take me some time before I could refocus the team.

Continue reading this article.

Managing Myopia with Release Burndowns

By Pat Guariglia

The burndown chart is one of the staples of Scrum. Many of us use and love it. Its simplicity and straightforwardness makes it an effective tool for project teams, management, and for the passive observer. A well-displayed burndown chart is one of the greatest information radiators you can use. From time to time, however, project sponsors, functional managers, and others on the periphery misunderstand its purpose. They can sometimes view a project burndown as a short-sighted tool that fails to provide insight into how the project’s end date is affected when features and tasks are re-prioritized and/or moved out of an iteration to meet the sprint’s burndown target. Stakeholder education certainly mitigates the risk of this misconception, but introducing “whole” project burndown charts, or release burndowns, seals the deal for upper management.

The effectiveness of my team’s burndown charts is demonstrated daily. Once I started using burndown charts regularly, I became a better ScrumMaster and communicator, plus my teams became more productive and predictable. I became almost proud of the success of using burndown charts on my projects and felt the need to talk about the charts and use them in presentations to upper management. This served me well and poorly at the same time.

Continue reading this article.

Effective Retrospectives & Reviews: A CSP’s perspective on continuously improving both the process and the product.

By Marco Mulder

Continuous improvement is a key principle of Scrum. Yet, though most Scrum teams conduct a sprint review and a retrospective at the end of each sprint, too many teams fail to implement the improvements they identify. In my experience, there are two common causes for this:

• Teams don’t have or maintain explicit standards for their product and process;

• Teams don't use the product backlog to schedule improvements.

Set a Dynamic Standard

A definition of done in Scrum defines general acceptance criteria to which all implemented features should adhere. This ensures that everyone has the same understanding of what it means for a feature to be “done.” Team members must all know these general acceptance criteria so that they know when they’re finished. The product owner and stakeholders need a definition of done so that they know what they can expect from the features delivered by the team. That does not mean, however, that the initial definition of done is the one you will want to use throughout the project's lifecycle. In fact, one of the reasons why an explicit definition of done is important is that it not only says what will be included in each feature, it also makes explicit what is not included. Some of the things not included may be planned additions later in the project.

Continue reading this article.

Agile Coaching Qualities, from A to Z

By Sunil Upadhye

Successful ScrumMasters and agile coaches share many positive qualities—listed here from A&A to Z&Z.

Attitude & Affirmations

Dress up your attitude and you can achieve 100 percent success. Affirmation is a self talk – whatever you say to yourself will be reflected in your behavior. Be kind to yourself and nice things will happen.

Balance & Benchmark

Create a balance in your mind. Be unshakable in the war against Naya – No Sayers. Create a benchmark of your work today. track the progress of your team through constant feedback mechanism.

Courage & Collaboration

Only courage can create highly collaborative team.

Determination & Desire

Have a strong determination to make others successful. Desire success. Look for the good in everyone. You will find excellent things in every human being.

Continue reading this article.