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. This direct approach, in which requirements are elaborated via executable code, creates a solid communication bridge between non-technical and technical staff and managers within the organization. Eventually, these executable requirements become the basis for the system’s acceptance test suite. As a take away, Michael provides participants with a lightweight requirements document format and an acceptance criteria framework to help you translate written specifications into automation.
Acceptance Test-driven Development (ATDD) is a popular topic these days-everyone’s excited about the idea of writing tests prior to development. Yet many teams run into difficulties as they attempt to implement this practice. It’s all too easy to fall into the trap of writing acceptance tests that mostly specify keystrokes and button clicks. Join "Cheezy" Morgan as he offers an overview of ATDD while sharing his experiences and insights gained working with numerous teams implementing ATDD. "Cheezy" will take you on a journey of discovery, demonstrating practical techniques for writing ATDD tests that describe the essence of what they are specifying while hiding unnecessary details that obfuscate their meaning. Because ease of maintenance is a key to ATDD’s long-term ROI, "Cheezy" shows how to structure and layer test code to reduce brittleness and fragility so your ATDD test suite will retain its usefulness well into the future.
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. Leveraging ten years of experience helping teams adopt agile, Tom walks through the many successes and failures he’s seen and, more importantly, the mistakes companies and people made that led to those failures. Learn the remediation steps you can take to re-energize and re-center your adoption efforts. Don’t let small missteps cascade into failure. Instead, join in and take back an action plan that’s sure to increase the odds of making your agile adoption a win for you, your teams, and your company.
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. With examples from her real-world experiences, Janet describes the testing traps and the practice or process to help fix each one. One example is “forgetting the big picture”-so easy when you are testing small, granular stories. A practice to put in place that avoids this trap is implementing feature acceptance tests to supplement story acceptance tests.
Every day more agile practices and styles emerge, overlap, and compete. This proliferation challenges you to choose from among XP, Scrum, lean, Kanban, or the ways of the emerging Lean Start Up crowd. Rather than stumbling down one path or another, join David Hussman as he shares tools for assessing and designing an agile process with practices that address your specific needs and constraints. David starts by teaching a simple assessment process to help you understand where you are today. Then, he offers ideas for selecting a meaningful set of practices and moves on to teach you how to create a meaningful and measurable coaching plan. David covers the selection of product planning tools, iterative delivery tools, tracking tools, and more. If you want to clear the fog about which agile practice will really help you, come for some answers. Even if you don’t yet know what questions to ask, David can help.
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. Learn about Kanban-not only the theory, but also practical lessons on transitioning your team to Kanban. Get insight into moving from Scrum to Kanban and pick up techniques that can aid any team. See cumulative flow diagrams, WIP (work-in-progress) limits, classes of services in action, and hear about other ideas from the Kanban toolset. Come and grow your agile repertoire!
While Scrum and XP have become very popular in agile development shops, most companies adopting them run into problems beyond just a few teams. These challenges often fall into a common set of patterns, which points to a lack of systems thinking-the process of understanding how things influence one another within a larger whole. Alan Shalloway shares his ideas on how the agile community can move beyond its team-centric approach to adopt a more holistic, systems-based approach. Systems thinking creates new opportunities to create substantially larger development teams-Alan calls them “pan-teams.” These teams work interdependently with a common vision and context. Pan-teams enhance the motivations for the teams and individuals to collaborate as a normal part of their daily work thus reducing the amount of forced collaboration.
In a world where technology is rapidly changing, development practices are quickly evolving, and teams are frequently reorganized, how can you remain steady and true to yourself? Even though things are changing around you, you can build a solid framework of personal beliefs to guide you throughout your professional career. To develop a credo-from the Latin “I believe”-is to take a personal journey through your professional life and the ideas that shaped it, ultimately creating your own statement of core beliefs. This credo forms a stable foundation for personal plans and actions. Marlena Compton shares the framework she’s used to build her professional credo. She examines manifestos and mission statements that have influenced her beliefs about building software and how she uses her credo as a basis to form concrete goals and take action.
By next year, 90 percent of large enterprises will include open-source software as business critical elements of their IT portfolios. However, most software development organizations have limited capability to govern the process of selecting, managing, and distributing open-source components-leaving them exposed to unforeseen technical and compliance risks. Larry Roshfeld examines how open-source components-and their dependencies-may expose your company to unforeseen and unnecessary vulnerabilities. He outlines the significant threats to software quality, stability, performance, security, and intellectual property that have occurred using such components. Then, Larry shares an action plan for balancing the risk/reward trade-offs of open-source software in the enterprise. Find out how to ensure that your organization uses only the highest quality open-source components and avoids the common vulnerabilities.
Speedy delivery is almost always a primary project goal or a significant project constraint. To shorten project duration without sacrificing quality or budget, you need to know where to focus the team’s efforts. Mining the QSM database containing many quantitative metrics and numerous qualitative attributes, Paul Below shares the factors that have the greatest influence on project duration. While he’s at it, Paul debunks a couple of myths. For example, many managers consider team skill to be important in determining duration of software projects-not so. The most important factors are certain types of tooling, architecture, testing efficiency, and management/leadership skills, which Paul explores in depth. Learn a technique for normalizing your projects for size by computing the standardized residual of duration.