Program planners in IT organizations have a dilemma: On one hand, their agile teams tell them that if requirements are defined up front, agile teams cannot operate; but on the other hand, the program’s budget and scope need to be defined so that resources can be allocated and contracts can be written for the work. How does one reconcile these conflicting demands?
Team members involved in hopeless projects become dejected, stressed, and overworked. Are there any silver linings to working on a doomed project? This article argues that there are. When you and your teammates are stretched to your limits, you can learn a lot about each other, your managers, and what it takes to make a successful product.
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.
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.
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.
Pini Reznik explains how containers can help shorten the software development feedback loop by drastically reducing the overhead involved in deploying new software environments. This leads to faster build and test executions and simplifies the standardization of the development and production environments, allowing for an easier transition to continuous deployment.
Holly Bielawa explains that being a a requirements craftsman means that you need to test your assumptions in real time while developing a product. Then you pivot as needed, change your business model as you learn, and constantly get out of the building and gather data to determine your minimally marketable product.
The needs to improve the time to market of a quality product and adapt to a changing business environment are driving organizations to adopt agile practices in order to be competitive in the marketplace. However, a project team is bound to face difficulties if it is not trained on the fundamentals of agile. Read on to learn how to design scenarios for agile stories using a structured framework.