As agile continues to grow in popularity, more organizations are experiencing the frustration and pain that accompany attempts to move from traditional to agile practices. With that pain comes the awareness that organizational and cultural change is essential to an agile adoption strategy. Ade Shokoya shares proven approaches for “selling agile” to senior management, colleagues, and all business stakeholders. Ade offers up what he calls “stealth agile” as a catalyst for organizational change.
Agile Development Conference & Better Software Conference West 2012
Have you ever delivered an application with functionality that was not what the stakeholders really wanted-or needed? Have you ever discovered that you were listening to the wrong people? Has your team ever developed a really beautiful application that no one uses? A truly successful project delivers what is most important to the business, the sponsor, and the key stakeholders. Carol Askew shares ten requirement-related tips she uses at her large healthcare organization.
Test-driven development (TDD) is a skill that takes patience to master-you can’t learn it reading a book. As with learning any new language, to gain fluency you need to practice TDD with competent coaching and lots of hard work. Many well-intentioned programmers try and finally give up on TDD because they never develop the fluency it requires.
Why do many agile teams fail at testing? Iterations turn into mini-waterfalls with testing at the end; stories never become “done” and carry into the next iteration with unresolved bugs; testers worry they’re losing control or being set up to fail; customers keep changing their minds after all the tests have passed. However, some teams do succeed with testing on agile projects. What do they do differently? Janet Gregory shares the lessons she’s learned that help teams-and especially testers-get agile right.
It's like watching a chase scene in a major summer blockbuster movie. You're totally focused on the action when suddenly you realize the background is a blurry mess. Trees, buildings, street signs, and pedestrians on the sidewalk have become one mass of smeared colors. As we increase the rate of new software releases and rely more and more on running web services for both interfaces and apps, we are beginning to see the boundaries blur between development, test, and operations.
The role of the software tester is continuing to evolve, becoming more complex and more technical. As new methodologies, technologies, and platforms emerge, testers are bombarded with new, so-called "best practices" on how to do their jobs. The problem is that testers have heard the same songs with different lyrics for more than twenty years now. Clint Sprauve takes a contrarian’s view of testing and the quality assurance industry.
There are many paths to innovation. At one extreme, many large companies create research labs, staff them with world-class Ph.D.s, and set them working for years to solve complex technical problems. At the other end is the proverbial "two entrepreneurs in the garage" working on a shoe-string budget. Between these extremes are all sorts of organizational structures, team sizes, budgets, and time horizons to encourage innovation.
Science is the building and organizing of knowledge into testable explanations and predictions about the world; lean is an approach which recognizes and leverages many scientific discoveries to enable faster flow, higher value, and greater capability. When thinking about opportunities for continuous improvement, science and lean should go hand in hand.
You’re familiar with agile and perhaps practicing Scrum. Now, you want to learn about Kanban to see if it is something to add to your development toolkit. Can Kanban help you? How does it differ from Scrum and other agile methodologies? Kanban is quickly being adopted by teams that want to improve their productivity. Kanban focuses on continuous flow and incorporating the theory of constraints which together allow teams to improve and streamline their product delivery.
Teams everywhere have experienced tight deadlines for software development projects. In such time-constrained situations, how can you systematically determine where to focus the team’s efforts? How do you determine the right level of requirements documentation? How do you decide how much testing will be necessary so that you are not doing too little-or too much? Reán Young shows how a risk-based approach to these and many other issues helps you identify project strategy options and set priorities.