Agile Development

It’s usually the finer points of the user experience (UX) design that separate good-enough software from really-great software. For companies launching new products or adding new capabilities, how well they understand their users and their needs differentiates the wild successes from the dismal failures. This is user experience design, and doing it well in the past took experienced specialists and lots of time. But the world has changed. Jeff Patton describes how Lean UX turns product design into a team sport in which everyone participates. Learn how Lean UX thinking breaks what we thought were good design rules. In Lean UX design, it’s OK to guess. It's OK for developers to talk to users. It’s OK for bad artists to design user interfaces. And, it’s OK to demonstrate half-baked ideas. You’d think that if we break all these rules, good user experience couldn’t possibly result—but it does. Jeff shares examples of how all this rule breaking is supported by a culture of experimentation and learning—and that makes all the difference.

Al Shalloway introduces Leanban, the next major agile approach following Scrum, XP, and Kanban—and the first explicitly based on lean software development principles. While each of these earlier approaches is a manifestation of selected Lean principles, none of them were fully Lean. The result is that each approach, while valuable, is incomplete and useful in only certain situations. Al explains how Leanban is an explicit manifestation of Lean principles while incorporating what we’ve learned from previous agile methods. It encompasses culture, Lean flow, how people learn, the importance of systems thinking, technical practices, and management, providing a consistent set of principles and core set of practices. Al presents Leanban's well-defined starting points and then discusses Leanban's well-defined migration path from one practice to another as teams learn or their situation changes. Al concludes by discussing how teams currently doing XP, Scrum or Kanban can extend their current practices with Leanban.

Garren DiPasquale says that holistic design strategy in an iterative agile environment is difficult. So how does design thinking deliver awesome applications and features for your customers? Why should your agile team care? How do you develop a macro understanding while developing micro solutions? Can you get designers and developers on the same page? As the market continues to move forward, our customers are expecting polished, delightful, and easy-to-use software. To deliver software that matches these expectations, we must adjust our product design practices to move as fast as our development counterparts. Garren introduces a model for getting designers and developers to work together―breaking problems down, and aligning both design and agile methodologies to form one cohesive team. Discover the objections designers have to agile, eliminate handoff problems, and deliver better software with a practical design framework that can be implemented on agile teams large and small.

It is challenging—if not impossible—to find local experts in low-level Linux or specific open-source software projects. However, this isn’t a challenge with a fully-distributed organization which has this talent worldwide. So the challenge becomes how to effectively manage, motivate, and retain this talent. At Linaro, Alan Bennett is responsible for producing many of their open source products. Having successfully worked with Kanban and Scrum in the past, Alan was surprised how difficult implementing agile practices was when the workdays of most team members overlapped only an hour or less. Realizing that their sprint planning and retrospectives were not going to be sustainable, the team knew they would have to make some changes. Alan shows you how his teams effectively manage their workload, combine agile with open source software processes, and create a system that survives and thrives even with the extreme communication latencies of a fully-distributed team.

Have limited time monitoring complex projects? Need to be fast on your feet during your teams’ standups? It’s a daunting task to keep track of the current work in flight. Steve Dempsen shares a mnemonic technique―WATCH—to help you think of and articulate critical questions to ask on the fly. For story cards remember W―Where is the card? Where should it be? A―What is the average time for a story this size? Are we on schedule? T―What is the status of testing? Test coverage and complexity? C―Is the story complete? consistent? And H―Is help needed? Who should we turn to? With limited time and complex subjects, ScrumMasters can use each letter in WATCH to quickly help their teams remain aware of the key aspects of development and remain focused on delivering effective solutions.

“Going agile” at a fifty-person startup is easy; at a 5,000 person ISV it’s impressive; and in a Fortune 500 company it’s often a nightmare. At large scale, the sheer number of legacy systems, stakeholder specific tools, and governance processes can turn even a simple agile deployment into a water-scrum-fall abomination. The ability to scale agile is critical for any size organization aspiring to remain competitive in a software-driven economy. Jeff Downs leads a discussion about being agile by keeping the focus on people—rather than processes and tools—through integration. Jeff introduces several tool-agnostic integration patterns, including defect unification, agile orchestration, and supply chain integration, which are critical to any organization trying to succeed with large scale agile. Learn how these integration patterns lead to an integrated agile tool suite that breaks down the barriers between teams, puts your people in a position to continuously collaborate, and enables a scaled agile initiative.

How agile are you? Once you jump off the waterfall and drink from the agile pool, there will probably be varying opinions as to the state of the organization’s agility. Some will be concerned that they are not agile enough; others will think they are agile while still adhering to old waterfall principles. Adapting to agile requires process changes that can cause friction within and between teams. Max McGregor’s organization Venafi has several teams working on multiple projects, spread worldwide. Even after a number of software releases using agile methods, teams still have challenges. Max provides insight into one mid-sized organization’s evolution through this process—where it’s working well, what the biggest challenges are, and what’s being done to increase its success with agile. Join Max to determine how agile you can or should become, and take back new ideas and methods to your teams to help them succeed.

Agile—a single word that sparked unprecedented confusion in the technology world. When it went agile, did your organization throw out your business analyst team? Have they banned all requirements documentation? Are teams struggling to see the big picture? Brian Watson has encountered each of these scenarios. Brian reveals the facts and busts the myths about requirements, documentation, teamwork, and the role of the business analyst in an agile environment. The relationship between the product owner and the team often develops through the activities normally associated with business analysts. Learn how this relationship grows through identifying and building a minimum viable product, see which Agile Manifesto principles are critical to business analysts, uncover the truth behind the cost of extensive documentation, determine how to use just enough documentation to be successful, and find out how to harness your business analysis skills to navigate the stormy waters of an agile transformation.

Does speaking to your company’s management or executives about agile scare you half to death? If so, you aren’t alone. Bob Hartman explains the most common scenarios that trigger these fears. An interactive exercise using these scenarios gives you a baseline of insights into the causes of the fear or anxiety we experience in these situations. Bob uses these insights to help you understand the basic skills necessary to effectively communicate with people in positions of authority. He explores the importance of having empathy, understanding motivation, and using basic negotiation skills in the context of having meaningful conversations. In addition, he shares several common communication methods that fall flat when speaking to executives. Bob concludes with an exercise to ensure everyone leaves with the critical understanding of both the positive techniques to use and the negative techniques to avoid during these difficult conversations.

Transforming an organization to become more agile requires leadership. But what kind of leadership? Who does the leading? When? How? Chris Sims guides you through the process of mapping the styles of leadership needed at various points in your company’s agile transformation. Chris explores the six leadership styles Daniel Goleman described in his Harvard Business Review Study Leadership That Gets Results and learn when each style is effective. He mixes in the Satir Change Model that describes how people and organizations process their way through change. Work in small groups to synthesize these two models, creating a map for applying different leadership styles at points along the change curve of an agile adoption. There is no one correct answer. Each group creates a map based on their experiences and their organizations. Chris facilitates a final review of the maps created to share insights and create deeper understanding.