How Agile Technical Practices Facilitate Disruptive Innovation
Leaders of development teams want to be able to adapt their existing product to innovative ideas and shifting market conditions. This is often the reason organizations "go Agile," yet this flexible ability to deliver rich business value is often frustratingly out of reach.
Agile teams and their management are also familiar with the value of individual development practices. For example, Test-Driven Development's ability to catch defects early, and to provide the team with the ability to confidently extend the product. What Rob has found by working with a number of teams, each for six months or more, is another much greater--and more rare--source of business value resulting from diligent attention to software craftsmanship and the resulting two-way trust that forms between Development and Product.
You will hear a handful of surprising (but real) first-person tales, each detailing a time when changing market forces, dramatic pivots, disruptive technological changes, or insightful requests were managed by the delivery team within a single two-week sprint. Each of these "Black Swan User Stories" (Rob's term for powerful, risky, and unforeseen user-stories) resulted in multiplying user productivity, opening whole new markets, or delighting and retaining critical customers.
What we found in each case was that rapid completion of our Black Swan User Stories was the result of diligent, disciplined application of a few Agile technical practices; and that this resulted in the concrete realization of organizations' long-held expectations for Agile software development.
Outline/structure of the Session
0:00 Quick Intro: Who am I? What are the Agile Technical Practices?
Very briefly: My experience as player-coach on a half-dozen XP teams. What are the Agile Technical Practices aka Scrum Developer Practices?
0:03 The Cases: Two or more "Black Swan User Story" success stories, time permitting.
I'll explain my term "Black Swan User-Story" as being a user-story that has Taleb's attributes of a Black Swan Event: Surprising, disruptive, and potentially expensive. I'll draw out the barbell distribution curve, and explain that most stories (and their required code maintenance) fall on the left side of the curve, and the rare few Black Swan Stories land on the right hill of the curve: Much more rare, much greater impact on the business.
I'll then tell two or more (it's a self-adjusting talk) of my favorite first-person experiences building innovative features on Agile teams, told as short, entertaining (and sometimes funny) narratives. They are:
- 2001: Internationalize a custom survey-builder to preserve existing customers in Japan, and to make the product available to other nations.
- 2002: Allow surgeons to create PDF reports from their ad hoc HTML reports, to better fit into patient medical records. This single change greatly streamlined the process of getting reports into records, which was being handled by nurses and interns.
- 2002: Allow for the nightly conversion of existing patient data and database schemas from an old FoxBase database to a new Oracle database (with an unstable data model). This adaptation and reuse recouped 80% of one medical records team's time.
- 2004: Convert the company's proprietary XML schema to a partner's schema for cleaner business-to-business workflows.
0:25 What is common in all cases?
I'll then summarize the conditions common to all cases:
- The user-story was a surprise to everyone, including the Product owner/advocate who invented it. I call them "Black Swan User Stories": Surprising, disruptive, potentially quite valuable, and potentially quite expensive. On a long-standing Agile team, such a story results from the Product advocate's knowledge of the software's existing capabilities, the team's skills and reliability, and the needs of the market. A Black Swan Story is frequently the innovative pivot, the wildly insightful customer request, or a clever repurposing. Once implemented, the Black Swan Story opens a whole new market segment, improves the flow of value in another area of the organization, or greatly aids in retaining critically important customers.
- The user-stories seemed at first to be nearly impossible to implement in any reasonable amount of time. Many team members saw the Black Swan as a major architectural change, based on their decades of experience on pre-Agile teams. Yet every user-story was completed in less than a sprint. In each case, the teams were able to prepare the code to facilitate the new enhancements by using rapid, often dramatic, refactorings.
- In each case, upon reflecting on root causes, the team involved determined that the software design's existing flexibility was key to completing the story.
- Furthermore, that design was in place due to disciplined efforts to refactor away "code-smells" (i.e., design problems).
- That in turn was only possible due to a comprehensive and very fast suite of regression tests built and executed continuously over all sprints.
- That suite was the result of disciplined Test-Driven Development. Every developer acknowledged that the suite would not have been as robust, or as fast, or as helpful, if unit-tests had been retrofitted rather than written test-first.
0:35 Conclusions: How rare are Black Swan Stories? And "Not a guarantee!"
- Though we may have expected Black Swan Stories to be rare; in my experience, they have occurred roughly once or twice per year on every long-term Agile team that focused on disciplined software craftsmanship using Agile Technical Practices.
- So it's not a guarantee, but the opposite is a near certainty. Based on a decade of pre-Agile software development experience, and experience coaching hundreds of Agile teams who chose not to strengthen these skills, I've also noticed the opposite: Without very fast, comprehensive testing, teams' Black Swan stories were either repeatedly rejected as too expensive and dangerous, or took many months to complete, sometimes missing a critical competitive window. Some of those companies no longer exist.
0:40 Final questions, clarifying anything still unclear, or that invokes skepticism.
The remaining time will be used for quick questions, and I'll let folks know where to contact me for further lively and respectful debate.
- Hear real examples of how maintainable, high quality code is critical to the rapid completion of innovative user stories.
- Explore the surprisingly direct path between software craftsmanship and business value.
- Learn why leadership would want to encourage, support, and defend a team's dedication to software craftsmanship and the use of Agile technical practices such as Test-Driven Development.
- Learn why an early commitment to developer practices is crucial to product longevity and innovation.
Executives, Leaders, Product Managers, Development Managers, Developers
Experience with an Agile framework (Scrum, Kanban, XP) and perhaps some painful experience failing (despite Agile) to sustain quality and the delivery of value over time.
schedule Submitted 1 week ago
People who liked this proposal, also liked:
Understanding Agile & Lean CoachingPaul Boos
schedule 6 days agoSold Out!
So you are considering getting a coach to help you in your transition to Agile. Or perhaps you are an Agile practitioner considering becoming an Agile coach. What do these Agile coaches do? What makes them different?
This session will enter the foyer of the house that describes what coaches do and considerations one can have when they think about coaching (including hiring one). Prepare to be challenged and to learn a bit of what it takes to be or work with a coach; it has little to do with courses or certifications, though they may help. In covering what coaches do, one can now begin to think along the lines of what the skills one may need to improve.
Catalytic LeadershipPaul Boos
schedule 1 week agoSold Out!
Losing good people during your transformation? Getting more resistance than you expected? You may be producing unwanted reactions in the way you are leading your people through change. If you want your Agile transformation firing on all cylinders without the harmful side-effects, people at all levels need to become Catalysts.
Catalytic leaders help lead continual improvement - change. How can we do that? How can anyone be a leader? This workshop will mix presentation with exercises to help you understand practical things you can do to lead change effectively.
Kanban in Action: Thoughtfully Observing Flow
Imagine you were hired to provide consulting assistance for a new team just starting out with Kanban. The team has been struggling with their implementation and is looking forward to your expert guidance, support, and advice. It’s your first day and you just walked into the team room to look at their board. You want to make smart observations and thoughtful interpretations so you can have meaningful conversations with the team members. The team starts assembling in the team room for the daily standup and you plan on making some comments afterwards.
What comments would you make? What thoughtful questions would you ask?
This interactive presentation provides a detailed look at how to interpret and thoughtfully observe Kanban Boards to better understand the work of your teams. We will start with an overview of the Lean Kanban Method and then proceed through a series of interactive exercises that give you an opportunity to review and interpret various Kanban boards. The exercises will increase your understanding of Kanban systems and provide opportunities to practice interpreting various board setups so you can have thoughtful and meaningful conversations with your teams.
Improving Your CyberSecurity Posture with Agility
As we have seen from recent reports in the news and elsewhere, cyberattacks come many sources. How can we use Agile practices to improve organization's information security posture?
In this session, Dan and Paul will discuss techniques that can help make information security an important part of software development and speed your response to threats. The use of hardening pipelines, dark stories, and user stories/acceptance criteria that map to policy guidance based on NIST 800-53 controls will be discussed and how each approaches improving your security posture from a different angle.
Powerful Tools for Affecting Change: Personal and Social IdentityJulie Bright
schedule 1 month agoSold Out!
Scrum Masters and Agile Coaches wear many hats, but one of the most important is that of the Change Artist. Understanding what people need in order to move through a change curve is critical to success, but often overlooked in the toolkit is the role of Identity. Our self-perception, both as individuals and within the context of a group, is foundational to our psychology, and can be leveraged to affect and nurture powerful, long-lasting change.
So You Want To Go Faster?Daniel Davis
schedule 1 week agoSold Out!
How frequently does a good agile team deploy to production? Not every team is capable of deploying "on every commit". What does it take for a team to even start deploying at the end of each sprint, or each week, or each day?
Most companies don't realize that deploying more frequently often requires both significant technical change as well as cultural change. In this talk, I'll guide you through what it takes to deploy more frequently, both from the technical side of setting up pipelines as well as the organizational side of removing red tape. I'll draw on the unique challenges that teams must overcome at each step of the way, from deploying once a month all the way down to full continuous delivery. If your team has been struggling to go faster, come see how you can change to get there. And if you already are at full continuous delivery, come see how to go even faster than that!