Agile Development East Concurrent Sessions

Of course we know what customers want, right? Product owners have the roadmap. Sales teams know what sells. Support talks to customers every day. So if we really know what our customers want, why is 65 percent of all software functionality rarely or never used? Why aren’t our customers delighted with the products we ship? Stop guessing what customers want and start delivering it! Tom Gimpel discusses the challenges of feature prioritization and determining what your clients really want and what they really need—and why they’re not the same thing. Learn how you can employ the KANO prioritization model to delight your customers by giving them functionality they value without the fluff they won’t use. Learn what’s wrong with most feedback surveys and build your delivery process to maximize customer satisfaction. Take away valuable tools for prioritization including an Excel-based scoring model that actually chooses the “best” possible combination of features that you can ship.

Software processes are commonly portrayed using machine metaphors in which consistency is highly prized. Frequently, organizations set up Centers of Excellence in a well-intentioned effort to create enterprise consistency. Steve Adolph reminds us that, in reality, software development takes place in a diverse ecosystem of corporate policies, competing interests, personal agendas, personality types, and a variety of formal and informal relationships. An aggressive top down imposition of practices is like sending a bulldozer through an ecosystem. This can create a prized consistency, but it also can destroy the environment’s productive vibrancy. It does not matter if the bulldozer says waterfall or agile on the side—it’s still a bulldozer. How do we live in harmony with our ecosystem? We can start by replacing machine metaphors with biological ones about leveraging and embracing diversity. Then use these metaphors to interpret two case studies of how organizations either bulldozed their ecosystem or learned to boost their productivity by living in harmony with it.

The Scrum Guide describes Product Backlog Refinement as “the act of adding detail, estimates, and order to items in the Product Backlog.” New and even experienced agile teams often underestimate the importance of well-groomed stories and find the process of reviewing numerous stories, breaking them down, and estimating the work chaotic and cumbersome. As this happens, teams push problems downstream into sprint planning meetings—or worse, into the sprint. Becky Moshenek shares how, working with the Product Owner, they create stories for backlog items to be reviewed. The stories include a link to the actual item, tasks outlining how and what to review, and a deadline for a future refinement meeting. These become refinement stories that are assigned to team members and brought into a sprint for an allotted ten percent of their time. Coordinating the team’s effort around backlog refinement in this way has cut meeting times, increased team involvement, produced more polished items, and made for a happier team.

Adopting agile development methods in a conservative environment can be a daunting and time-consuming venture, facing resistance at all levels of the organization. You may wonder: Will this organization ever get with the times? Will our leaders ever change their way of thinking? Brian Duncan shares personal experiences and lessons learned in bringing an agile development mindset to two distinct organizations—a bottom-line product-driven software development organization, and the conservative, risk-averse Space Department at the Johns Hopkins Applied Physics Laboratory. Sharing the Good (what worked well), the Bad (what set us back), and the Ugly (what we had to abandon), Brian shows how to bring a slow-to-change organization into the forward-thinking agile methods of today. He presents practical approaches (adoption committees, grassroots techniques) and creative endeavors (free classes, an innovation lab) along with their impact on the organization. With persistence and a multifaceted approach, even risk-averse organizations can adopt agile.

Agile at scale continues to be a hot topic as more large organizations begin their transformation. Many frameworks are available, including SAFe, DAD, LeSS, Enterprise Scrum, and Nexus. Scaling agile across the enterprise is very challenging; even understanding the options is complex. How can you pick one? Do you need to pick just one? Or pick at all? The right answer depends on your unique situation. Smart scaling with the Agile Scaling Knowledgebase (ASK) 2.0 provides a way to compare different approaches, going beyond the more “popular” frameworks to include new, emerging ones. Steve Spearman and Richard Dolman explore the evolution of popular approaches and discuss how you can make the best decision to fit your company and your project. Join the conversation, share your experiences, and learn from others. Get to know ASK as a valuable tool to help you and your organization explore the topic of agile scaling within the context of your organization’s specific needs.

Businesses are hit by thieves from all angles. Thieves often go unnoticed until something is missing. If you are adopting agile, you may have thieves stealing from your transformation right now. Every organization is different, but some thieves of agile adoption are well-known. Francie Van Wirkus shares her “most wanted” list of thieves, common organizational impediments and patterns, and her ideas on how to mitigate them. At the foundation of all solutions is strong leadership muscle, so expect stories and action items on how to raise your leadership game. Francie introduces high-level concepts including the mistakes of managing change instead of leading change, pushing culture ahead of environment, and skipping agile coaching. Awareness of what’s stealing from your agile adoption is only part of the conversation. Francie provides real-life actions to keep your strategy and goals on track. Don’t wait for something to go missing from your organization before you take action.

Is architecture the same as preliminary design in agile? It shouldn't be. Do we do architecture up front, then do iterative development after the architecture is done? That is edging back toward waterfall. Can you explain the purpose of the architecture in just two or three statements? Anthony Crain says that when he asks that question, he gets either verbose answers or blank stares. So Anthony shares an elegantly simple two bullet explanation of what an architecture does. Explore the models architects and designers should produce and learn why the models are so important to keep separate. Understand why it is vital to separate functional from nonfunctional requirements and how this affects architecture, design, and even code and test. Explore what a conceptual architectural model should look like vs. a physical one, and for the conceptual design model vs. a physical one—and the timing of all four models. Finally, explore the impact of iterative development on architecture.

The Agile Manifesto was stated in less than seventy words. Now, fourteen years later, layer upon layer have been added to it. What was supposed to be a simple philosophy has exploded into a gigantic industry. Much of this layering makes agile seem overly complex. We know developers want to focus on getting their work done, unhindered by rules and regulations. Developers should know the priorities of what to work on, do their work, report their progress, and be held accountable. This process should be supportive, not burdensome. Geoff Perlman shows how a small engineering team built a large project (Xojo) with new releases regularly, using a simplified agile process that gets the job done without adding complexity to the lives of the team. If your team is grumbling about your agile processes, join Geoff as he shows you how to focus on the “meat” of agile so you can be both fast and efficient—without the complexity.

We teach managers to foster agility by encouraging their teams to self-organize, stop assigning work, and telling them how to do it. Since the Product Owner defines the what and the team defines the how, what’s left for managers to do? Managers need to become servant leaders. It’s a key success factor for agile transformations. However, most managers have no idea what servant leadership is or what these leaders do. David Grabel teaches the true meaning of servant leadership—transforming it from a buzzword to a guiding principle. Learn how, as a leader, you can accelerate your team’s agile journey. Working in groups, participants discuss the challenges faced by an agile manager. As part of your learning, create artwork using Legos, clay, and pictures to illustrate how a servant leader meets the challenges of today. David defines the new job description for today’s managers in tomorrow’s agile culture. Come and prepare to take your part in it.

Substantial evidence exists that coaching plays an important role in helping an organization successfully transform to agile. External coaches can help an organization as it begins to adopt agile practices, but a sustainable, long-term agile adoption requires the organization to stand on its own. Developing an internal coaching team is an important step toward becoming self-sufficient. Join Sue Johnston and Shawn Button as they explore the process of building a team of competent internal coaches. Discuss how to identify coach candidates, put together and run a coach development program, and create opportunities for learning on-the-job. Talk about potential bumps in the road—those organizational impediments to building coaches—and strategies for overcoming those barriers. Sue and Shawn share their experiences with what works and what doesn’t. Leave with a realistic plan to discover and develop coaches within your organization.

Project Management Professional (PMP) or other detailed training has become almost ubiquitous in the project management profession. Through this training, Brian Watson says that many of us have learned what we should be doing when it comes to managing projects, and this often conflicts with what we are doing. This gets more complicated when transitioning from plan-based methodologies to an agile framework. What may seem like chaos is really the perfect time to stop managing projects through controls that lack trust in the development teams, dust off those skills of empowerment, and embrace those activities we should be doing. Project managers are leaders, and agile transformations are the perfect time to eliminate ineffective, micromanagement processes and to implement collaborative, empowering techniques. Brian shares his experiences combining corporate agile transformations with mentoring project managers on how to leverage agile techniques. Learn how to effectively embrace resource management, estimating, reporting, traceability, and courage—all while project managing in an agile world.

This is the story about the Microsoft Developer Division and their two-year journey to agile—from shipping every three years to shipping every three weeks. In the old days, long stabilization phases were part of its DNA. Managers were rewarded for micromanagement. Commitments were made months in advance. Maintaining the appearance of meeting commitments was valued over transparency. Gregg Boer shares how this organization within Microsoft transitioned to one that values agile principles—controlling technical debt, enabling teams, eliminating bogus commitments, and rewarding transparency. When applying agile to such a large, traditional organization, the key to success is allowing autonomy at the team level, while ensuring alignment with the organization. Gregg shares successes as well as colossal failures. Learn how management sets direction while teams own their own backlog, how communication up and down can be transparent and healthy, and other lessons on their journey to agile.

After implementing Scrum, some organizations slowly stray away from the basics that made their implementation successful. They loosen up Scrum practices, lose sight of core roles and responsibilities, and succumb to their muscle memory of how things were done before. Teams have little accountability and fail the transparency test. Denise Dantzler reminds us of the roles and responsibilities of the ScrumMaster, Product Owner, team member, leadership team, organization, Scrum coach, and stakeholders. She then identifies and discusses pitfalls, and recommended actions in each role to rejuvenate a Scrum implementation. Denise explores overall process improvement opportunities for Scrum implementations, including mid-sprint poker, release planning, and the importance of a Sprint Zero. Learn the critical adjustments you and your organization can make to remain successful over the long haul with Scrum.

Warning! You can still build the wrong product using agile. In Eric Ries’ book The Lean Startup, he poses the question: What if we found ourselves building something that nobody wanted? In that case, what would it matter if we did it on time and on budget? We often assume the Product Owner is smart enough to define the right product. But what if we are wrong? Michael Hall shares lean startup principles and how they can be applied to ensure that the product we are building is righteous. Learn new agile concepts such as hypothesis-driven project vision, knowledge broker personas, learning maps, minimum learning product, experiment backlogs, experiment test iterations, validated learning, and pivot/persevere decisions. Case studies and Michael’s first-hand product experience emphasize the learning points. New and mature agilistas alike will leave the session armed with Lean Startup agile techniques that can be applied immediately on their agile projects.

In less than one year, a leading software company's product team transitioned from a twenty-five year history of waterfall development to using agile methodologies. They had produced software the old-fashioned way—sequentially, firmly entrenched in the process and procedure of pure waterfall. Long release cycles, a mature code base, and an ingrained development model prevented their rapid response to the needs of their customers. The “rush for the finish line” left schedules and deadlines shredded, quality and development staff exhausted, and management frustrated. Andrew Montcrieff describes the processes, challenges, and lessons learned while moving from waterfall to agile. He provides insight on how they dealt with the problems encountered along the way. Andrew will make you feel more comfortable with moving a legacy waterfall product to a more predictable, reliable, agile methodology-driven product by learning what to expect and how to deal with the obstacles you’ll likely encounter along the way.