Agile and DevOps teams, which emphasize continuous improvement, can benefit greatly from effective retrospectives. However, retrospectives can get monotonous, and that’s when they become ineffective. Using gamification in your retrospectives brings a completely different dimension of thinking—and even makes the process fun.
Eitan Schichmanter’s team evolved its development process from a focus on build management to a more robust DevOps transformation, and they designed a custom gated check-in system to help. He shares how they tackled challenges and created an internal solution to address an important technical requirement.
How you handle a postmortem depends on your leadership approach, the culture of your organization, and, of course, your own personal strengths. This article will consider how positive psychology can help you conduct more effective postmortems that lead to process improvements and more effective organizations.
Robbie Bridgewater writes on the difficulty in finding bugs during testing since no single computer can run all of the major browsers—not to mention the added challenge of testing various mobile operating systems. In this article, Robbie compares four possible solutions to this dilemma.
The loudest voice in the room might push for a stable, predictable, repeatable test process that defines itself up front, but each build is different. An adaptive, flexible approach could provide better testing in less time with less cost, more coverage, and less waste.
How do you adapt inspections to a twenty-first century distributed workforce? A key part of the inspection process is the team meeting, which provides peer pressure to participate and consensus on defects. Teams working in multiple time zones have limited opportunities for the team meeting. A list of requirements and the functions needed to solve this problem based on real-world experiences should help anyone faced with this problem.
Code review is one quality initiative you can't afford to skip. Don't have time for a full-blown, line-by-line review? No problem. Discover how even something as simple as a peer review can benefit your project and ultimately improve your code.
Are you suffering from chronic disinterest in what your team is delivering? Are your product owners unavailable or distracted? Are your sprint reviews ho-hum experiences with low attendance? If you answered Yes to any of these questions, your agile teams are in trouble-and you need to attend this session. Experienced agile coach Bob Galen explores real-world patterns for how to increase the interest in-and the energy and value of-your sprint reviews. First, Bob explains how to prepare properly, the keys to dry runs, and the role of a Master of Ceremonies. Then he examines ways to orchestrate pro-active reviews that include the whole team and engage your audience when demonstrating "working software." Next Bob discusses how to perform a review follow-up and gather feedback for high-impact improvements. Finally, Bob wraps up by exploring ways to make sprint reviews a centerpiece of your agile adoption and transformation.
Traditional performance evaluations, which focus solely on individual performance, create a “chasm of disconnect” for agile team members. Because agile is all about team performance and trust, the typical HR performance evaluation system is not congruent with agile development. Based on his practical experience leading agile teams, Michael Hall explores how measurements drive behavior, why team measurement is important, what to measure, and what not to measure. Michael introduces tangible techniques for measuring agile team performance-end of sprint retrospectives, sprint and project report cards, peer reviews, and annual team performance reviews. To demonstrate what he’s describing, Michael uses role plays to contrast traditional, dysfunctional annual reviews with agile-focused performance reviews.
Would you tell your publisher to stop editing in the middle of your manuscript and publish your novel now? Of course not! Then, why would you tell your QA/test team to stop identifying problems with requirements documentation? All deliverables—and especially requirements—should undergo a rigorous assessment based on their quality attributes and measurable evaluation criteria. Mark Haynes describes quality models and attributes he has used to evaluate requirements documents. He shows how you can detect imprecision-that will haunt you later-and remove it with a set of formal criteria and informal heuristics. Discover how you can use quality attributes, even subjective ones, to conduct a quality dialogue within the development team. Mark shares examples of poorly written requirements for you to evaluate and try your hand at improving.
Want to improve the quality of your products? Of course you do. But how? Mette Bruhn-Pedersen uses a simple, but effective method that includes both clients and users in the development process. His company organizes and conducts verification sessions early in the development process. These sessions consist of two parts: First is a demonstration of the implemented functionality using test cases as examples; second is a "play" session in which the customer is given control of the system to explore the functionality from a business perspective. By observing the client, testers get a better understanding of what functionality is most important to the client as well as increasing their knowledge of the software's intended use. Sometimes, the clients find important, new defects during the session. And almost always, testers learn they need to add new test scenarios based on their observations during the play session.