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.