Software development organizations adopting Scrum have struggled to apply it to big projects with multiple teams. Dan Rawsthorne is frequently asked, “What does ‘big’ Scrum look like?” Because no two organizations are alike, this simple question does not have a simple answer. However, Dan has discovered patterns that are common in organizations that successfully implement “big” scrum. The first pattern he explores-Product Owner Team-allows the organization to handle agility up and down the hierarchy.
Agile Development Conference & Better Software Conference West 2012
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.
Product owners create stories they believe are ready for development. Developers accept and then estimate stories that are not really ready to be started. This disconnect between being “ready” and “really ready” results in miscommunication and frustration. For example, story development can take much longer than original estimates because of the details and “sad paths” that were not expressed in the story. Ken Pugh describes how to turn vague acceptance criteria into specific acceptance tests.
Knowing the rules of chess doesn’t equip you with strategies to win the game-much less make you a chess master. In the same way, many Scrum teams and their organizations know the rules but never consider longer-term strategies for getting the most out of Scrum. Sadly, of the thousands of organizations using Scrum, only a small fraction realizes Scrum’s true potential. To help address this epidemic and offer teams and companies ways to get more out of Scrum, the Scrum Framework has been codified in the Scrum Guide 2011.
Because the mobile market is extremely dynamic, maintaining consistent application quality is always difficult. Managing the risk exposures with mobile apps and embedded software requires comprehensive testing of a wide variety of platforms operating on multiple networks. Testers have to contend with short development cycles that require continuous QA efforts.
It is easy to find a million ways that software development and project managers can let down their teams and their projects. Ken Whitaker has identified seven pragmatic leadership tips and techniques you can use to build and sustain a great team that consistently delivers great software.
Adopting agile is often a difficult proposition with many variables and sometimes uneven results. Recognizing when your adoption isn't working well and taking pro-active actions to put it back on track are essential. So, how do you know if your adoption is proceeding through rough but expected waters or running the risk of failing? Thomas Stiehm describes the signs of serious adoption problems and the steps you can take to fix them.
Just as John Steinbeck was able to identify the complex system of tides, eddies, and other currents that bring nutrients to support life in the Pacific Ocean, you need to do the same for the complex human system that builds software products. Ray Arell argues that development productivity can increase only when you enable developers to grow and master the craftsmanship around their work.
Specification by Example is a collaborative approach for constructing executable requirements. Examples demonstrate how the system should operate through the eyes of its users and shows understanding of the application’s functions. Michael Connolly demonstrates the practical and easy-to-implement Specification by Example method which he uses to write user stories and acceptance criteria.
Businesses demand high levels of product quality, development productivity, planning reliability, employee satisfaction, and customer loyalty. And yet, people and organizations often ignore all those goals and focus on building systems with as many features as possible delivered by a specific due date. When the work is complete, retrospectives surface the dissatisfaction concerning missed dates, poor quality, technical debt, and more.