Chandra Munagavalasa writes that because the requirements change over time, the product backlog is never complete. As the project progresses and more detailed information becomes available, the product backlog items and their rankings change continually. One of the many techniques available for ranking the product backlog is the Kano model.
Developing software correctly is a detail-oriented business. George Dinwiddie writes on how using the Three Amigos strategy can help you develop great user stories. Remember, the goal is to have the work done just in time for planning and development. It should be complete enough to avoid stoppages to build more understanding, but not so far in advance that the details get stale.
Using metrics such as cumulative flow to monitor throughput and quantitative thinking may not seem very humanistic, but by depersonalizing the work being done, we can focus our energies on solving actual problems instead of conducting a daily witch-hunt and shaming people into high performance.
Kristin Cowhey explains how z/OS development has evolved throughout the years and what that means for developers and tech personnel. With legacy developers leaving the workforce, there’s a dire need to replace the knowledge in order to maintain the mainframe systems and applications that are still in use today.
Sarah Johnson explains the role of writing in an agile world and how to educate your team members. Remember, agile takes into account that each situation is unique, and you need to determine what makes the most sense for your particular Scrum team.
Johanna Rothman writes that organization-wide standards don’t help if management imposes them. If people ask for help with standards, then you can provide local help to each team. And if the teams are part of a program where you have one business objective common to multiple projects, make sure the program understands the problem.
Mike Talks shares with us the unlikely story of how his pet German Shepherd inadvertently became his team's QA manager. Talks explains how his German Shepherd was able to gather people together and have them talk to each other, similiar to what a QA manager does—keeping people on task, handing out assignments, and following up with team members.
Lawrence Putnam explains whether or not big agile is an enterprise savior or an oxymoron. What if agile only works when teams and projects stay relatively small? That’s the question most CIOs want answered before investing scarce time, energy, or resources chasing the big agile paradigm.
Enterprise development organizations are increasingly embracing agile as a concept, if not entirely in practice. That’s because adopting and scaling agile methodologies for large, complex enterprise software projects can seem daunting. Larry Ayres shares some tips for scaling agile development for enterprise software.
In today’s fast-paced workplace, software developers and project managers are confronted with a painful paradox. They are faced with continual pressure to accelerate the development process, but this “need for speed” can result in communication failures—and the accompanying project and quality problems.