Author(s): Mitch Lacey
Few people aware of Ziv's law: Software development is unpredictable. The large failure rate on projects worldwide is largely due to lack of understanding of this problem and the proper approach to deal with it.
Conway's law: The structure of the organization will be reflected in the code. A traditional hierarchical organisational structure negatively impacts object-oriented design, resulting in brittle code, bad architecture, poor maintainability and adaptability, along with excessive costs and high failure rates.... Improvements never ends.
When your team is hurting or in trouble, you can turn to the chapter that most closely matches your symptoms and find, if not a cure, at least a way to relieve the pain.
Throughout this book, you may find yourself thinking. "I wish I had a tool or downloadable template to help me implement that concept." In many cases, you do. If you go to http://www.mitchlacey.com/supplements/, you will find a list of various files, images, spreadsheets, and tools that I use in my everyday Scrum projects.
Certified Scrum Trainer (CST), a PMI Project Management Professional (PMP), and an Agile Certified Practitioner (ACP).
To focus means to concentrate, to direct attention on something. In Scrum, the team must have focus if it is to accomplish everything that needs to be done to deliver a potentially releasable increment of functionality. Focus means working on one project at a time. It may mean having dedicated "team time", where the entire team is off email, instant messaging, mobile phones, and meetings. Focus is doing whatever it takes to allow the team to concentrate on the delivery at hand for the entire length of any given sprint.... As the saying goes, respect is earned, not granted.... In the story that opened this chapter, testers and developers were clearly at odds and had little respect for each other. The team was lucky, though, in that the people had not yet lost all respect for each other, as evidenced by their ability to come together in the end.
Understanding common reactions to change is key to a successful Scrum implementation. Virginia Satir was a family therapist who, through clinical studies, identified a common pattern in the way people experience change. The stages include the late status quo, the introduction of a foreign element, chaos, integration and practice, and the new status quo.
When people are in the status quo, they are comfortable. Often, people find excuses to stay in the status quo because it is the world they are familiar with. People tend to ignore the need for change and just keep doing the same thing, only better, harder, or more diligently.
Eight-step model for addressing change: 1. Establish a sense of urgency. 2. Form a powerful guiding coalition. 3. Create a vision. 4. Communicate the vision. 5. Empower others to act on the vision. 6. Plan for and create short-term wins. 7. Consolidate improvements and produce still more change. 8. Institutionalize new approaches.
When showing working software, always remember to be transparent and honest - be up front about both the good and the bad of the project and embrace the changes that are being made.
Plant the seeds but the willing to let them grow. People learn at different paces and using different styles. What convinced you may not work for everyone.
Data show that the best team sizes are between five and nine people, all of whom are fully dedicated to a project for the duration of the project, and who work together in a cross-functional way to deliver working software at the end of every sprint.
To pleasure our customers, we need to have employees who are vested in the projects. The best way for us to do this is to have them sign up for work and manage their own schedules. We've said we want to be a learning organisation, a company filled with empowered employees who are cross-trained and satisfied with their work. This model seems like a way to please our customers by delivering what they need when they need it. At the time, it gives us a way to foster happy employees who want to stay with the company long term.
On a cross-functional Scrum team, core team members continually learn new skills and are able to stay focused on a single project. As such, the business profits by having a stable workforce that is continually learning. enabling the business to remain competitive and responsive to change.
Rank each individual on a scale of zero to five stars. Remember, there is nothing quantitative about this task; it is purely subjective.
How big should a core team be and how many consultants should it have? A study done by Lawrence H. Putnam and Ware Myers in 1998 investigated team size.... What Putnam and Myers confirmed was not only that smaller teams of five to seven delivered in less time but also that a significant increase in effort occurred when team sizes reached nine or more.
For instance, imagine that David is a team consultant. David frequently commits to teams but either fails to deliver on time or turns in low-quality work. The end result is that David does not have many teams willing to work with him, either because his reputation precedes him or because they have worked with him before. If someone like David is allowed to continue at the company despite his poor track records, it would be demotivating for the other team consultants and for the core team members who would be forced to work with him. The better course of action is to treat him like the unnecessary overhead he has become and remove him from payroll.
Remind the business of the importance of an actual core team supplemented by consultants and reboot. Having a dedicated team with all the skills necessary to get the project completed is ideal. But most teams will, at some point in the project, find themselves wishing for a particular expertise. If you have internal people who can fill this gap on a temporary basis, bring them in to the project. If your organization does not have team consultants who can fill the gaps, you may want to bring in external consultants for limited engagements. A team consultant can sometimes score a lot of points for a project that might otherwise struggle with a skill gap.
use Osborn’s brainstorming technique... to identify the tasks. This is a highly interactive process and is most effective if everyone participates.
Points-to-Hours Approximation Suppose that when the hours for each task are added together, the total for the reference story is 14 hours. The next step is to extrapolate: All two-point stories in the product backlog will take the team roughly 14 hours to complete. Of course, in actuality the team might complete this, or any other two-point story, in 2 hours, 8 hours, or 16 hours. It’s a rough estimate—and for the purposes of blind estimation, that’s okay. From this, you can determine a points-to-hours approximation. 14 hours/2 points = 7 hours per point
The team planned to run three sprints, capturing the observed velocity data at the end of each one. I prefer this option because the team is making its calculations based on real data, data that does not exist until the project is running.... The benefits of waiting to the management team and lay out a plan as to when twill provide numbers and why real data is worth waiting for. When using real data, you should follow these steps: 1. Collect and chart your actual velocity for at least three sprints. 2. Calculate average velocity, but communicate a range. 3. Map your velocity range to the product backlog. 4. Update your velocity and likely velocity range after each sprint.
To determine the team’s degree of confidence, have each team member write down his or her confidence rating on a piece of paper—when everyone has a number written down, flip over all the written pages at once. You can skip this if your team is comfortable doing this verbally and just have everyone answer at the same time. The point is to prevent people from being influenced by others’ answers.
No one on a Scrum team should wear multiple hats; I don’t care how small the team is! ... Consider each of the roles, starting with the product owner. The primary job of the product owner is to be the customer representative, turning the vision into a workable product backlog for the team to execute and managing the return on investment/business value of the product or service under development. The product owner helps bring clarity to the vision of the product to be delivered and then works with the customers and stakeholders to build a list of requirements called a product backlog.
Typical items in a product backlog include stories (or features), taxes, spikes, and preconditions. ... The role of the ScrumMaster is multifaceted. First, the ScrumMaster should work to build and maintain a high-performing team. On the surface, this role appears to be simple: Manage the daily scrum, collect status from the team, and coordinate the various meetings and tasks. The truth is, though, that nothing about a ScrumMaster’s job is simple. The ScrumMaster is not the team manager or leader; on the contrary, the ScrumMaster is the fluid that ensures the team’s engine is firing on all cylinders. ScrumMasters keep the team focused and on track. To do this effectively, ScrumMasters need to be able to see the forest for the trees—to see the big picture and look for places where the team can make improvements.
A combination product owner/ScrumMaster is akin to a two-headed dragon. Eventually one head will eat the other. The product owner and ScrumMaster roles are in conflict with each other by design. One exists to drive the team, the other to protect the team. ... The product owner might not care if the team is keeping its morale up and might not even care if quality suffers, as long as the dates are hit and the customer’s needs are perceived to have been met. ... It’s equally ineffective to have a ScrumMaster but no product owner. Without the sense of urgency a product owner brings, it is likely that the team will move too slowly. Without a product owner to keep the team focused on delivering value, the team might include functionality that it thinks would be fun to build or would be something nice to have. The team, not the customer, soon ends up driving the product vision. In these cases, the customer will soon begin to question whether the product will ever be delivered, will wonder whether the team could be moving faster, and will wonder why it is paying for features it did not ask for. Eventually, the customer will lose faith in the team altogether.
What about Extreme Programming’s call for having the “customer in the room,” which I am all for but rarely, if ever, see? Could having a combination client/product owner be the next best thing? Sometimes. First, consider that if the product owner is the actual client, he holds the money. This gives him the power to pull the “I have the money card, so do what I say” routine—not a fun situation for the team or the ScrumMaster who is trying to protect that team.
Hopefully by this point I have made a clear case for not mixing the roles. I realize, though, that you’re probably going to try it anyway. When you do, I suggest you mix only the team member and ScrumMaster roles. Why? It’s the least damaging combination, puts the ScrumMaster in the room with the team, and will likely be the easiest to sell to management, especially if they are saying you “cannot do Scrum” because of the perceived additional overhead in the roles. Be careful when you do it, and make sure everyone on the team is on the same page from the beginning.
Determining Sprint Length There is no one-size-fits-all magic bullet for determining a sprint length that works well for every team. Originally, Scrum called for one-month sprints, but nowadays many teams have been successful with two-week or even one-week sprints.
Project Duration Sprint lengths should be chosen in relation to project duration; however, they should never be longer than one month.
As a rule, an inexperienced Scrum team should stick with two-week to one-month sprints because a one-week sprint is much more advanced and better suited for established teams that have a good working relationship.
Finally, don’t forget the reasons you are working in short iterations: to gather stakeholder feedback, to show project progress through working software, and to frequently deliver a project that is potentially shippable. The right sprint length balances the team’s craving for feedback and input with the team’s ability to deliver and the stakeholder’s ability to respond.
To teams that use it, the definition of done becomes a way of life—not a checklist to follow but a commitment to excellence.
Alex F. Osborn is widely known as the father of brainstorming. In his books, "Your Creative Power" and "Applied Imagination", Osborn outlines the brainstorming technique, a system that uses the brain to “storm” creative solutions to a problem. This creative approach is designed to generate a free flow of ideas. In the brainstorming session, there are no right or wrong answers. There is no criticism, there are only ideas. The rules of brainstorming, outlined by Osborn, are simple: - No criticism of ideas. - Go for large quantities of ideas. - Build on each other’s ideas. - Encourage wild and exaggerated ideas.
Scum Master ... looks up from the noise of everyday to see trends, patterns, problems that are blocking the team from going faster.
The ScrumMaster job is like that. I’m still hands-on. My hands are just busy doing other things. I lead and guide the team through the process all the while keeping a higher-level view of what needs to be done. I remove impediments, keep everyone focused, find ways to improve, all in the name of increasing velocity.
One of the jobs of the ScrumMaster is to remove impediments. Another is educating the Scrum team (including the product owner), stakeholders, and others in the organization so that the team is eventually able to resolve its own impediments. This ultimately results in more efficient teams that can get more done. Good ScrumMasters function as the oil in the engine—they reduce or remove friction, enabling teams to move to a high-performing state.
The job of ScrumMaster is real. It can have a big impact on costs, as illustrated previously, saving the company money—period. But what does a ScrumMaster do all day to justify a full-time role? The following list encompasses most, but not all, of the day-to-day tasks. - Remove impediments/resolve problems. - Break up fights/quarrels. - Act as a team mom. - Report team data. - Facilitate. - Help out where needed. - Educate the organization. - Drive organizational change.
TDD significantly streamlines the writing of code, helps prevent analysis paralysis, minimizes impediments (like spending lots of time in the debugger), and gives teams the priceless gift of peace of mind. For these reasons, TDD is essential for teams that want to grow to be high-performing Scrum teams. And, remember, the compiler only tells you if your code obeys the rules of the language; your tests prove that your code executes correctly.
One of my favourite books on continuous integration is "Continuous Integration: Improving Software Quality and Reducing Risk" by Paul M. Duvall.
It is important to understand that practicing pair programming does not necessarily mean work takes twice as long. While at the University of Utah, Laurie Williams found that pair programming was 15 percent slower than two independent developers but produced 15 percent fewer bugs.... There are some great papers and books on pair programming. Start with an older book, Pair Programming Illuminated, by Laurie Williams and Robert Kessler. Another good reference is The Art of Agile Development by James Shore. To understand the cost benefits of pairing, read “The Economics of Software Development by Pair Programmers” by Hakan Erdogmus and Laurie Williams.
Integration tests are designed to test various integration points in your system. They are designed to ensure that APIs, data formats, and interfaces are all working as expected while the team is developing the code.... Acceptance tests are designed to emulate the behaviour of the user. If you are building a system with a UI, these tests will be scripted to click and emulate the behaviour of the user.
Get Training/Coaching Don’t expect people to “just do it.” Teach them how. You can do this by hiring a coach, finding someone in your company who has this experience, buying books, or sending them to training classes. If money is an issue, realize that the benefit that modern engineering practices will bring back to the company will be far greater than the financial investment being made up front.
Establishing core hours is a small detail that can have a big impact on team performance. Calculate how many hours you are spending as a co-located team and work together to maximize those core hours while maintaining individual team members’ flexibility. Charting core hours is a small but powerful tool that can help you build a high- performing team.
“I just wonder why a five-minute task for me will take your team eight hours. How many other five-minute tasks are in there that you are all masking in huge numbers of hours?” asked Ron. “It’s no wonder you guys think you need to extend your sprints; you have easy tasks that take forever!”
A story will have multiple tasks. A sprint will have multiple stories. A release might have multiple sprints. I say might because while many teams don’t release every sprint, some teams actually do. That’s why Scrum uses the words potentially shippable to describe completed stories; the stories theoretically could be released at the end of the sprint, but it might not be economically practical.
Another indicator that stories or tasks are the correct size is that independent estimates during planning are roughly equal. When stories/tasks are hiding additional work, estimates will vary wildly. This disparity can be uncovered using Planning Poker.
I am a strong advocate for prioritizing quality above all else, when it makes sense. I also understand that even code that lives up to the highest quality standards will never be perfect—will never be forever free from defects and maintenance. As such, I accept that defects are a part of life. That doesn’t mean, however, that teams don’t need a technique for managing them, preferably in real time.
2002. Johanna Rothman published an article on the StickyMinds website. In her article, based on customers she works with, she concluded that a team that waits until the very end to fix defects will have a defect cost price 400 percent larger than a team that addresses defects in real time or near real time.
Michael Feathers "Working Effectively with Legacy Code"
The sprint review occurs on the last day of the sprint. The duration varies depending on sprint length. For a one-week sprint, the meeting should last about 30 minutes to an hour; a two-week sprint, an hour to an hour and a half. Teams running four-week sprints should allow two to four hours for this meeting. Besides acceptance of the sprint work, other intended outcomes of the meeting include additional customer interaction, increased feedback, and additions or changes to the backlog based on the interaction and feedback.
Document Decisions People all forget things, but it seems people are especially good at forgetting the things that they need to remember, such as a workflow, a colour choice, a button location. When a decision is made during a review, write it down and keep it safe. I’ve been in too many reviews where a customer says, “I don’t remember that decision. I’m not paying for this and that.”... Asking the customer to accept the stories during the meeting allows you to release soon after the review.
Once teams start skipping retrospectives, the downward spiral begins.
Retrospectives are a key part of a team’s inspect-and-adapt cycle. Every other part of the sprint (sprint planning, daily scrums, the sprint review) focuses on delivering working software. The retrospective is the sole opportunity for team members to examine how they work and how they are working together.... Retrospectives have a more subtle benefit as well. They give teams the opportunity to change behavior and team culture. They are a safe place for team members to share, constructively, feedback with others on how their actions (or inactions) impact the quality, morale, and attitude of the team. Left alone, these small problems fester, like an unattended cut. Retrospectives, on the other hand, allow teams to attend to their small wounds quickly, reducing the chance of infection.
Communication Good communication starts with setting expectations up front. At the beginning of any Scrum project, publish all scheduled meetings and send out notifications to all invited parties. Retrospectives should be on every team member’s calendar. In addition, prior to each retrospective, send a meeting reminder that includes an agenda. This agenda should remind everyone what the meeting is about, why it is important, the benefits to the team, and how to prepare. It should also include a rough outline of how the time will be spent and a sentence summarizing the end goal.
Luke Hohmann describes a similar game called “Buy a Feature” in his book Innovation Games [HOHMANN]. It can also be used in this situation (prioritization).
Derby and Larsen summarize it best in Agile Retrospectives: “Productive teams judge retrospectives by their results”.... New Scrum teams sometimes drop retrospectives because they fail to understand the purpose of the meetings—the why. Dropping retrospectives can cause catastrophic problems—glitches that are relatively easy to solve when they are fresh can stagnate, fester, and grow into larger issues.... Without learning and continuous improvement, teams will fall back to their old habits and begin to wonder what happened—and they will usually blame Scrum for their failure.
For maximum effectiveness, you should read Project Retrospectives: A Handbook for Team Reviews by Norman Kerth and Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. When I first read Kerth’s book, it influenced how I ran project postmortems. It was not until I moved to Scrum and XP, however, that I fully realized the potential of a well-executed retrospective.
We are here to answer our questions. These questions are, What did you do since the last meeting?, What will you do today?, and What impediments do you have? (some teams add a fourth question) Who would like to start?” Repeat this mantra every single. Repetition leads to muscle memory.... The purpose of limiting the number of questions is to keep things moving and to keep people focused. Every team member should come to every daily scrum having already considered the answers to the three questions. Lack of preparedness is almost as bad as being late because though the team members show up on time, they are not really there.
Mentors identifies five attributes of strain: conformity, ritualism, retrealism, rebellion, and innovation.
Skills, after all, are easy to learn and can be picked up in a matter of months... especially when paired with an experienced programmer.