|
|
Collaboration Workshops: Discover, Plan, and Prepare the Product Backlog To deliver high-value products, your agile team must reach a shared understanding of prioritized stakeholder needs. Collaborative techniques are best for this type of work, but not all agile teams use them or use them efficiently. Some rely too heavily on written user stories or story maps and fail to address complex topics or resolve requirements conflicts among stakeholders. Ellen Gottesdiener outlines how you can systematically collaborate about the product backlog in nimble, timely workshops that give your team an open venue for working together to make complicated decisions. Ellen explores collaborative techniques for backlog discovery and preparation. She teaches you to use the Seven Dimensions technique to make sure you capture all product needs.
|
Ellen Gottesdiener, EBG Consulting, Inc.
|
|
|
Restating Scrum: Refining and Extending the Framework 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. Rob Maher explains what elements of Scrum were revised and why, and offers practical guidance on avoiding common missteps that plague failing Scrum teams and organizations. Rob describes the extension model which allows the Scrum Guide to be expanded to support related strategies and practices.
|
Rob Maher, Scrum.org
|
|
|
Performance Appraisals for Agile Teams 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. Michael introduces tangible techniques for measuring agile team performance-end of sprint retrospectives, sprint and project report cards, peer reviews, and annual team performance reviews. To demonstrate what he’s describing, Michael uses role plays to contrast traditional, dysfunctional annual reviews with agile-focused performance reviews.
|
Michael Hall, WorldLink, Inc.
|
|
|
Lessons from a DevOps Journey In large financial institutions, treasury departments-specialized teams of traders and experts in liquidity, risk, accounting, financial forecasting, and quantitative analysis-manage the organization’s wealth and financial risk. These departments require large, complex, third-party software products that must change often to support the treasury’s complicated business processes. Matt Callanan describes how a team of developers and operations staff-the DevOps team-applied agile principles to the “last mile” and reduced software deployment from one week to one day. He discusses how their DevOps team collaborated to develop automation solutions to support ongoing deployment activities and solve many issues in the operational environment.
|
Matt Callanan, Independent
|
|
|
Ready, Really Ready, and Really Really Ready Stories 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. He explains how levels of detail in acceptance tests can help to more closely estimate the effort required by stories and shows how acceptance tests determine when stories are complete. With Ken, you’ll go through creating a “really really ready” story and examine when it should be created and who should participate.
|
Ken Pugh, Net Objectives
|
|
|
Implementing Agile in the Cloud with a Large Distributed Team Jeremy Leach shares Pitney Bowes’ agile development experience implementing a cloud-based application with a large, globally-distributed team. Jeremy’s story recounts challenges working with the very specific delivery cycles required by third-party contractors and hardware vendors. He describes the interactions and complexities that a global engineering team face when multiple project and products must come together into a single release. Learn how outside elements can stress the development rhythm that a team needs, how to mitigate these challenges, and how Pitney Bowes eventually came to embrace them. Jeremy explores how their management evolved and the focus of their communications structure changed from key individuals to group collaboration. In conclusion, Jeremy shares lessons learned and how Pitney Bowes is structuring similar projects for the future.
|
Jeremy Leach, Pitney Bowes
|
|
|
Specification by Example: Building Executable Requirements 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.
|
Michael Connolly, OPOWER
|
|
|
Ten Things You Absolutely Must Know before Touching Agile with a Barge Pole 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. You’ll learn about the three personality types essential to successful agile transformation initiatives and how to avoid the common agile mistake that could cost you your job and/or reputation. Take back a guide to determine the agile transformation strategy best suited to your organization’s size and culture.
|
Ade Shokoya, AgileTV
|
|
|
The Science of Lean 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. Karl Scotland explores some of the science behind lean-from mathematics to neuroscience-in order to explain why and predict how various practices can have a positive impact on the way we work. Gain a deeper understanding of both the science of lean and how to take a scientific approach to learning in order to reap the benefits of paying attention to people, process, and economics. Leave with richer insights into why and how lean approaches work, and the ability to apply the science-and a scientific approach-to your own teams and organizations.
|
Karl Scotland, Rally Software Development
|
|
|
Signs Your Agile Adoption Is Off Track-And How to Fix It 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.
|
Thomas Stiehm, Coveros, Inc.
|
