Managing work in progress (WIP) is a sign of maturity. For some reason, most people want to start working on everything at once. I call this the curse of multitasking. Yes, we live in a time that seems to demand that we multitask, but in my mind, it's more valuable to get stuff done. Getting stuff done requires that we focus...
It's better to have fifty percent of your stories one hundred percent done than one hundred percent of your stories fifty percent done.
Both defects and technical debt should not be assigned story points. They should negatively affect velocity and give an accurate picture of how fast the team is getting features done.
Waterfall encourages a team to hide the bad stuff. Scrum will expose the bad stuff… quickly. The beauty of this is that once the bad stuff is exposed, the team can easily remove it because following Agile methodology requires a constant striving to get better.
Stories always need to be written from the customer’s point of view...
Personas are a powerful tool that the Scrum Master and Product Owner can use to keep the team focused on the customer’s perspective.
Scrum Harmony... there are the levels that you will pass through:
... it is a simple example of the stages a team will go through when learning a new discipline.
Tech lead, or architect they should be working with, or preferably part of the architecture team to get architecture defined in the Backlog...
“A spike is a small story you use to go off and do research. I usually insist that a spike not take up a whole Sprint. The result of a spike should be enough information to write stories.”...
Scrum relies on what is called emergent architecture. Emergent architecture emerges (hence the name) as work is done, and comes from within the Scrum team. It is usually discovered during story refinement.
That’s why we have an architecture team here. Their job is to work with Scrum teams and to influence how architecture evolves.
The PO will tell you what she wants, but it’s up to you guys — the TEAM — to decide how to turn the PO’s idea into working product. Every decision belongs to the team. From training requirements to what coding language to use. A Scrum team owns what it works on.”... Some of you need to find your voice and speak up. No matter what you say, getting involved adds perspective and information to the conversation
Adding or removing members is disruptive and should be avoided if possible. Instead of disrupting the team, move work to the team. If the work is important enough to break a team up, consider having the whole team do it. Moving work to the team enables the team to stay together and the business to meet its needs.
The rule is that you fix defects in the iteration they are found in. If stories need to be removed from the Sprint and put back in the Backlog to account for the time needed to fix defects, so be it. Sometimes it’s helpful to look at a situation from a different perspective to fully understand the impact.
Coaching is like a muscle; you use it or you lose it. As I’ve said before in this book, there is a difference between coaching and teaching and mentoring. There is also a difference between Agile coaching and professional coaching. Agile coaching is where you help folks with their Agile competency and skills. The goal of professional coaching is to help individuals improve performance.
I’ve heard the Agile rituals (stand-ups, Sprint Planning, Retrospectives, and so on) described as distractions that get in the way of “real” development work. Um… no. These meetings are not “overhead.” They are there to provide the structure and rhythm necessary for work to get done, and for important information and updates to be communicated between team members. Decisions about direction are discussed and commitments are made to each other. The meetings allow the entire team to participate, collaborate, and (dare I say) self-organize.
Not finishing stories in a Sprint makes it tempting to fall back into Waterfall-style behaviors. Remember, the idea is to deliver working software every Sprint. Allowing stories to slip will not allow the team to demo the minimally viable product that they committed to delivering. It also creates a domino effect. When a story slips to the next Sprint, there is a good chance that the team will not be able to finish all of the stories in that next Sprint. So the team does not complete all of the stories again. Stories slip again, and again, and again...
There is also the issue of taking too much time talking about stories and not enough time actually working on them. Perfection is a mortal enemy of a Scrum team. Remember, working software is what we are after. Get something built and into the customer’s hands. Instead of arguing about how a piece of functionality should work, get it in the customer’s hands and let them tell you.
Failure is the best teacher in the world. One of the things I encourage teams to do is experiment and fail if necessary. I just want it to happen quickly. A team failing over and over repeatedly isn’t healthy and doesn’t deliver value to customers. Fail quickly, learn from it, inspect and adapt, and move on. A team that experiments often and learns from their failures is well on the way to being a high-performing team. A team should experiment so that they can learn what can and cannot be done…
There is nothing like experimentation to help the team understand its capabilities.
At some point, the coach will start to ask open-ended questions. For example, “What have you tried to do to this point?” One of my favorites is “If this had gone perfectly, what would it look like?” By having the person being coached explain how the perfect scenario would work, you may just get them to blurt out the solution.
Time-boxing keeps my natural tendency to procrastinate in check. It helps me to better organize my time.
The magic number or sweet spot is “three to one,” as in three positive statements for every negative one. If you want a team of high-performing rock stars, you need to get that ratio closer to five to one.
Delivering a minimally viable product every two weeks can be difficult to achieve. It may require the Scrum team to change the way they go about their business.
When you try to define the exact level of scope, exact cost, and exact time on a project, you guarantee failure because there is no flexibility should something change. You are not accounting for variability or expecting things to change. One of the reasons we are doing Scrum is that we recognize that it’s impossible to plan everything out at the beginning of a project.
I like to see at least 30 percent of release capacity focused on something other than the release itself so that the team has the ability to realistically address deficiencies.