Review of "Succeeding With Agile" by Mike Cohn

It all sounded nice and rosy to begin with, but, reality keeps smashing you in the face. With scrum, things never go as smoothly as in the books. Sounds familiar?

The Book Is Not For Starters

It has now been a few years since AnvilEight started to move towards agile and scrum. As expected, the transition did not happen overnight. In the early days of scrum it seemed relatively easy to follow the routines and procedures defined by a scrum, however, many more problems surfaced during this journey.

Now, our company has come far from those baby steps, and we’re now moving beyond being novices to an “intermediate” level . This book is exactly what a company like ours requires in this phase of transition that we’re in.

So far, it is the most sophisticated book I’ve read on integrating agile practices . I would recommend it to those, who having learned the basics of these practices, want to master them now.

Starting With Agile Is Still Hard

TThe author opts for a somewhat lengthy introduction on getting started with agile even though the foreword explicitly mentions “This is not a book for those who are completely new to Scrum or agile.”

It’s probably a good idea, after all, to remind us again that Scrum is hard However, here are a few things that I took away from the first part

• Best” practices can be harmful. Calling a process the “best” way to do something, implies that you are no longer open to improving it.

• Scrum is different, pervasive and requires promotion. It demands a leap of faith.

• Start small unless there is a time constraint or you are absolutely confident about your success.

• Prepare for resistance. Split-and-seed vs. grow-and-split. Go public vs. stealth mode. Start asap vs. delay until better times. All of these are ways to work with resistance that you will inevitably encounter.

• Create a transitional backlog. Get the budgets. Get approvals from the top management. Create improvement communities.

The first part is a little boring and a tad obvious. Despite that, I would still recommend reading it to refresh your understanding and revise what you already know.

Face And Embrace Resistance For Good

What do you do when people are saying NO? There are two aspects of change that need to be considered: technical and social. In a nutshell, technical means altering routines, while social deals with how the change will affect the relationships in the organization.

There is an entire article on this written in Harvard Business Review by Paul Lawrence. Mike Cohn argues that it is often the social aspect that creates resistance and is the one that is most neglected.

Some of the reasons why people will be reluctant:

• Lack of awareness
• Fear of the unknown
• Fear of losing control
• Lack of time
• No tangible answer to the question, “What will this change bring me?”
• Comfort with status quo

Those, who have something to lose will resist the most. Evidently, there is always a fear behind every I don’t like it or We will fail inevitably. I found it particularly useful to think in terms of fears associated, when facing refusal of any kind.

What makes them afraid/averse?

Common Misconceptions About Scrum

Here are a few of the most common objections that people who are new to agile have:

• Scrum is unpredictable, thus we can not make commitments to the client
• Scrum is not working with distributed teams
• Our culture is simply different and doesn’t allow agile
• Our project is too complicated for a scrum
• There is no architecture in scrum projects. We can’t afford it

Fears Accompanied The Change

People may not say this directly, but in one way or another, they may express one of these fears:

• They will see how little I really do
• I don’t think I will be valuable anymore
• I will be fired
• It’s much easier when someone else tells me exactly what to do
• It’s much easier when I just say, people, what to do
• I am afraid of conflicts

This section is my favourite. Indeed, we’ve all had similar thoughts in our life and admitting to them is an act of courage.

Ways To Overcome

So what we are going to do with that?

As a leader, listen to what your employees say. I really like this idea - to try to finish the sentence: “I can’t do scrum because it means that…”:

• I would have to work more than I do now
• I wouldn’t be doing the part of my job that I enjoy
• I wouldn’t be able to hide that I am no longer a good programmer
• I would lose people who are reporting to me

This can go on and on. I found this part especially interesting. I think this is relevant to any kind of change, not just transition to agile. Depending on the motives, there could be four categories of people:

Depending on the motives, there could be four categories of people:

• Skeptics - passive, don’t like scrum
• Followers - passive, like status quo
• Saboteurs - active, don’t like scrum
• Diehards - active, like status quo

Status quo examples:

• I don’t like changes
• We failed many times already. There is no point to start another change
• I have a very good title. I don’t want to lose the prestige

Examples of not liking scrum:

• Scrum won’t work on for our products
• I don’t want to spend too much time on discussions
• I like to work with my headphones on

The book talks in great detail about approaching each of these types and the possible means to deal with them. Besides, it also gives lot of examples.

Resistance As a Way To Identify Problems

The premise is that any sort of resistance or objection is an opportunity to find a **bottleneck in the existing process or system. Personally, I found that this resonated with me quite deeply. These “red flags” could be very useful in transition, if they are seen as an alarm that alerts you to something going wrong instead of being seen an enemy that should be fought. Summarizing this section, I found many of these examples relevant and worth considering.

New roles vs. old responsibilities

Scrum introduces new roles such as scrum master and product owner. Key points here:

• Scrum doesn’t recognize titles. A team is just a team of people
• Scrum master facilitates cooperation, discussion, and teamwork
• Scrum master is here to help a team and remove impediments
• Rotating scrum masters usually is a bad idea, however, occasionally it might be useful for learning purposes
• Product owner is responsible for the vision and backlog
• It is critical for a product owner to be available for the team. Being within reach is enough. No need of ²⁴⁄₇ availability
• There is only one product owner for a team

Another aspect that author advocates the idea of splitting scrum master and product owner. In other words, those two roles should not be combined. There must be certain tension between product owner who pushes a team to do more things and scrum master who protects a team from unrealistic goals, sporadic changes, and other disturbances.

There is a lot to say about changed responsibilities within roles, but I found the following changes to be the most important:

• No hand-offs of the product
  
• Designers go a little bit ahead of the programmers
• Become proactive
• Work incrementally
• Aim to create a potentially shippable product within the sprint
• Work iteratively. Functionality can be revisited in subsequent sprints
• Work beyond your specialty

Project manager

• A project manager is now split into scrum master and product owner. Leaning towards product owner role
• A project manager should overcome the urge to direct people and start to guide them instead
• Leaders should become builders of a learning organization. They communicate the overall direction and express willingness to help team and coach. No to “Follow the rules” or “Here is what and how to do it” approaches

Programmers

• Programmers have to start communicating much more

• The old way of “Give me the perfect specification; then go away and wait until I make the system do exactly what you requested” is no longer valid

• The way testers clarify requirements now is by talking to the product owner

Technical excellence is now vital

• Go for TDD. There is always time for bug fixes but never for writing tests
• Continuously learn and improve your skills
• Maintain a refactoring backlog
• Use continuous integration (and delivery)
• Build often and fast
• The code is now whole team’s responsibility
• Do pair programming to increase collective ownership. Agree on devoting two hours next week for PP just to see if it works
• Architectural design is now emergent
• It’s ok to do some design upfront but not too much. Refactor as the system grows. Don’t be afraid of reworking

Overall, this section can be summarized as follows: ** Improving technical practices is not optional **. The book was written far back in 2010, but the importance of that statement has only grown since then. It seems like the perfect technical skills will become a standard at some point and a default attribute of any team that hopes for success.

Small teams have better productivity per person

Many studies suggest that adding more engineers to the team reduces the performance of each person. While this is true, a number of problems can arise with the one-man army approach. To name just a few few: hard to find such a multi-faceted person, slow overall speed, no room for discussions, etc. Long story short: 3-5 people is optimal It is far better to have teams working on features rather than modules or components. This is how teams become responsible for delivering shippable increments rather than a bunch of code.

Self-organized teams

First of all, it does not mean that they are randomly organized. It also doesn’t mean that the workers engineer an organization design, as opposed to the manager. Here are a few rules to follow when assembling a team:

• Make sure that all skills are included
• Mix technical skill levels (have juniors and seniors)

• Keep them together for a longer period. Allow them to develop the necessary pathways to working together

• Seek diversity

Encourage your team to self-organize by not making all their decisions for them. If they look to you in a meeting, look back at them. Train them to make decisions on their own.

One person works on a single project at a time

Multitasking is bad for you. Distractions and switching back and forth backfires majorly and reduces the overall performance. Switching may consume as much as 80% of your valuable time!

Allow for some breathing room between projects.There is always overhead on starting the project and finishing it. Multitasking can occur at those stages if not planned carefully. Finish one, then start another.

Whole-team responsibility

“When everyone is responsible - no one is responsible” is a false premise, even though it might be convenient for the management to have someone to blame if something goes wrong. However, it doesn’t do much good to the project. Mike cites an analogy of parents raising a child. Who’s responsible for the child’s well-being? The answer is both. Same applies to a team. All members must embrace that responsibility.

Daily scrum as a tool for commitments. On a daily meeting, everyone makes commitments to others by saying “I will do this” so that the rest of the team expect him or her to say “I’ve done that”at the next daily meeting. It doesn’t matter if you’ve completed your tasks or not. What matters is whether the goal was achieved or not. Team members are encouraged to occasionally do things that are outside their speciality.

Finish things quickly. Don’t wait until the end of the sprint to finish bits of functionality. It is better to have two things completed 100% than to have five at 90%.

Designs teams for learning

While reading this book, I feel like the success of moving to scrum relies heavily on learning. Making it priority number one in the organization is absolutely crucial. The book offers a few tips on how to make this happen.

• Make it ok to fail. Let people know that it is alright to be wrong sometimes
• Present a challenge
• As a leader, support and emphasize learning
• Avoid scatter. Examples are:
  • Asking to stop doing what team is doing and switch to feature X
  • All actions X must be provided with document Y describing an impact
  • All the breaks in the flow of work and distractions
  • Breaking a day into small pieces
• Avoid hand-offs - transferring the responsibility to someone else. For instance, Architect -> programmers -> testers -> project manager
• Eliminate knowledge waste and wishful thinking
• When a team detects a complicated issue but fails to automate the test to ensure that the bug won’t reappear. It is called discarding knowledge

Word on leadership

It may sound like there is little room for leaders in self-organized teams. Actually, nothing could be further away from the truth. It’s just that a leader’s responsibility has now shifted towards influencing the team rather than just telling them what to do. The author presents the concept of containers, differences, and exchanges as a way to make an impact.

Containers

The certain context within which self-organization happens. It is rules and restrictions imposed on the team.

• Giving more or fewer responsibilities
• Add or remove people from the project
• Create a new container. For example, a community of practice
• Rearrange the team’s space - move people in a single room, etc.

Differences

Amplify the difference by asking hard questions:

• What else was considered before this decision was made?
• What can go wrong if we take this decision?
• Is the team too similar or too different? Which ones can be amplified to improve team’s performance? Which ones are harmful?

Exchanges

How do people interact within a team? What processes can be added or removed to alter the exchange? Introduce face-to-face meetings or document exchange if needed. Make exchanges more or less often.

Managing evolution

So what exactly leader is now managing? There are several things that leaders can influence:

• Environment - physical, what projects are taken, how much, what is the approach to creating new things
• Performance - what types of behavior are appreciated by the company? What is considered as a good performance?
• Meaning - help team interpret messages sent to the system
• Vicarious selection systems - systems that naturally help the company to make decisions without having a lengthy formal process
• Energize the system. Entropy increases and things stagnate if no energy put into the system. Leaders are those who put that energy in. Press releases, announcements, reviews.

Shifting from writing requirements to talking about them

Backlog, in a nutshell, is a list of the desired functions in order of priority.

• Items with the highest priority are more detailed
• Add more details as the item approaches development
• Written documents look important and official but it doesn’t make them any more accurate

Example:

— Please, book a hotel in New York

15 minutes later

— Booked

Is the booking completed? Or is the hotel is full? One way to overcome the communication challenge is
to agree that team will discuss the user story before it starts to work on it with the product owner.

Constantly refine details

We have to have a specification since it should be written in the contract.

We can pretend that we came up with the requirements, but they will change inevitably. It’s better to admit that change will happen and prepare for it. Trond Pedersen describes it this way:

“Complaining about requirement change is like complaining about the weather. You can’t really change the way the world is, but you can find ways to deal with it. Don’t make an offering to Thor [the Viking god of thunder] to make the rain stop; get an umbrella.”

Split the backlog into the epics -> stories -> smaller stories

Grooming is a discussion that shapes the short term stories and adds more details to them. There is no need to plan far ahead. Keep in mind a big picture but focus on the near-term goals.

Start without a specification. Develop it as you go. Use user stories as a description of the behavior of the system.

Written specs are still useful for specific purposes: * Calculations and tables * Algorithms * Everything that is hard to comprehend verbally

I’ve created several more blog posts on user stories already.

Testers are responsible for specs since they are the primary users of it. It is a great idea to put testers in charge with requirements since they are the ones who will eventually use it to assure the quality.

Define potentially shippable

• Tested - it is reasonably good
• Integrated — branches are merged
• Doesn’t necessarily have all the feature set
• Team shares the definition of done
• Deliver something that is valuable every sprint

This is maybe 60% of the book so far. I will keep adding more notes as I go