Alright, so you’ve started with scrum.
It all sounded well and round but reality keep smashing you. People are not willing to do scrum as you though, things do go that smooth described in the books.
The Book Is Not For Starters
It is now a few years since AnvilEight started to move towards agile and scrum. As it was expected, the transition did not happen overnight. In early days of scrum it seemed relatively easy to follow routines and procedures defined by a scrum, however, many more problems was uncovered during this journey.
Now, the company has done its baby steps and moving beyond “novice” level to intermediate. This book is exactly what company like ours requires at this point of transition.
So far, it is the most sophisticated book on integrating agile practices I’ve read. I would recommend it for reading to those, who have learned the basics and wants to master them now.
There is a reading list that I manage and refine constantly with more books and reviews.
Starting With Agile Is Still Hard
The author goes for a somewhat lengthy introduction of how to get started with agile even tho the foreword explicitly mentions that “This is not a book for those who are completely new to Scrum or agile.”
Probably, it is still good to remind ourselves that scrum is hard. Although, there are few take offs I made out of the first part:
- Best practices can be harmful. Stating that some process is the “best” way to do the thing, implies that you are no longer consider to improve it.
- Scrum is different, pervasive and requires promotion. It is a leap of faith.
- Start small unless there is a time pressure or absolute confidence in 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 will inevitably occur.
- Create a transitional backlog. Get the budgets. Get approvals from the top management. Create improvement communities.
The first part is a little bit boring and obvious. Despite that, I still recommend to read it to refresh the memories of what you already know.
Face And Embrace Resistance For Good
What to do when people saying NO?
There are two aspects of the change to be considered: technical and social. In short, technical means altering routines, while social concerns how the change will affect the relationships in the organization. There is entire article on this written in Harvard Business Review by Paul Lawrence. Mike Cohn argues that it is a social aspect that creates the resistance and is the 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 answer to “What will this change bring me?”
- Comfort with status quo
Those, who have something to loose 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 fear?
Common Misconceptions About Scrum
There is number of objections that people who are new to agile will express:
- 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 the following 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 favorite. Indeed, we all had similar thoughts in our life and admitting them is an act of courage.
Ways To Overcome
So what we are going to do with that?
As a leader, listen to what employees say. I liked an 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 relates to any kind of a change, not only transition to agile.
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 tells in great detail how to approach each of these types and what are the possibilities to deal with them. Besides, there are a 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 this very resonating with me. These “red flags” could be very useful in transition, if treated as a signal that something is going wrong instead of 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 24⁄7 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
- 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 have to start to communicate much more
- 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 is now 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 per person. While this is true, there is number of problems arise with the one-man army approach. To name few: hard to find such a multi-tool 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 increment rather than a bunch of code.
First, it does not mean that they are randomly organized. It also doesn’t mean that workers instead of managers engineer an organization design. 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. Let them develop the paths to work together
- Seek diversity
Engage team to self-organize by not making decisions for them in all cases. If they look to you on a meeting, look back at them. Coach 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 all fires back and reduces the overall performance. Switching may consume as much as 80% of the valuable time!
Give some breathing room between the projects. There is always overhead on starting the project and finishing it. Multitasking can occur at those stages if not planned carefully. Finish one, start on another.
“When everyone is responsible - no one is responsible” is a false premise. It is easy for management to have someone to blame if something goes wrong. Although, it doesn’t do any good for the project. Mike provides an analogy with parents who raise the 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 do things that are outside their specialty occasionally.
Finish things quickly. Don’t wait until the end of the sprint to finish certain functionality. It is better to have two things completed for 100% than five for 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. There are few tips suggested in the book 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 that there is little room for leaders in self-organized teams. Nothing can be far away from the truth. Leader’s responsibility is now shifted towards influencing team rather than telling what to do. The author presents a concept of containers, differences, and exchanges as a way to make an impact.
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.
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?
How people interact within a team? What process 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.
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
— Please, book a hotel in New York
15 minutes later
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