In our enthusiasm for the incredible wealth of useful practice for delivering software that's emerged from the agile community, we seem to have lost the plot. We've become the next wave of people enamored with our process and believing it cures all software development ills. This is the Achilles-heel that proved to be the downfall of our well-meaning process predecessor. In this talk I'll discuss how to evaluate your process on the values and principles that motivate it - and add back in the key missing value: product success. It's the success of software in the real world that the business and consumers are hungry for. It's about time we positioned agile methods as the way to get that, and not just another stupid process.
Is it easier to transform an existing culture to agile or build one from scratch? Menlo Innovationsâ€™ CEO Richard Sheridan will share two tales of Agile transformation. The first occurred when Sheridan was a VP of a 30-year old technology company and he transformed his existing team by adopting Extreme Programming. The second occurred two years later, when he chose entrepreneurship and started a new company using these same practices. True Agile adoption is hard. This talk will explore three barriers to Agile transformation: the executive team, the tech team, and Sheridan himself.
Managing Agile involves designing, supporting and reinforcing a system of work to deliver business value. â€œPrevailingâ€ organizational systems often reinforce and reward management behaviors that produce three dysfunctional paradigms: 1) magical thinking, 2) the illusion of control, and 3) the fantasy of individual blame. The transforming antidotes to these dysfunctions emerge from three key strengths of Agile approaches: relying on data and evidence; accepting uncertainty and unpredictability; and maintaining a whole systems view. In this talk, Diana Larsen will describe ways organizations have reduced their dependence on the dysfunctions and built on the strengths of an Agile way of doing business.
While many organizations have adopted Agile approaches at a project level, few have effectively aligned their human performance management processes with Agile values. This presentation and discussion will explore the subject of creating a truly holistic performance system that not only adheres to Agile principles, but actively promotes maturity in applying them to the delivery of measurable business and user value.
A great agile design process is complementary to a great agile development process, producing products that people love. Thereâ€™s a tension between the notion of ultimate flexibility that agile proposes, and the need for coherency and excellence that great design provides. This talk is intended to provide a framework to help yourself ask, as a designer or as a developer, â€œWhat is Enough Design?â€ and to share my experience as to what has worked well in practice on our many projects at Pivotal Labs.
Technical debt had originally been conceived as an expediency measure â€“ â€œa little debt speeds development so long as it is paid back promptly with a rewrite.â€ However, like financial debt, unrestrained borrowing can lead to a broad spectrum of difficulties, from collapsed roadmaps to inability to respond to customer problems in a timely manner, and anything in between. Recent advances in source code analysis enable us to quantify technical debt and express it in $$ terms. Technical debt analytics can help your team improve its design, coding, testing and project management skills.
Because of Eric Evansâ€™ Domain Driven Design, agile developers are familiar with embedding their domain models in their code, but architecture and design remain hard to see from the code. How can we improve that? This session presents a new agile technical practice, an architecturally-evident coding style, that lets you drop hints to code readers so that they can correctly infer the design and architecture. It builds upon ideas like Kent Beckâ€™s Intention Revealing Method Name pattern and provides a set of lightweight coding patterns and idioms that let you express your design intent in the code.
Your brain is literally wired to be agile. Are you working with itâ€™s strengths? Do you know how to tell if youâ€™re not? In this session weâ€™ll explore some exciting discoveries in neuroscience and psychology, and then immediately put this knowledge to use creating iterative change inside our brains. If you want to fine-tune your teamâ€™s agile processes, or if you just think it would be fun to know how to hack a debug breakpoint into somebody elseâ€™s brain, this session is for you!
Designing software is hard; designing quality software is even harder. Quality software should be more than just data with algorithms, more than a sum of its parts. One key to achieving this is to change your thinking and focus on the humanity inherent in all software. This talk will introduce anthropomorphic ideas for composing objects. Iâ€™ll discuss how to achieve collaboration in our objects vs. the more common command-and-control style. Iâ€™ll explore the importance of metaphor in designing our code. And Iâ€™ll describe how to achieve better design by anthropomorphizing your domain.
Agile Product Owners are under a lot of pressure. On one side, customers, stakeholders, and users provide a constan
For many organizations, Agile methods have been a proven answer to the vexing questions of developing better software. But now that many organizations have mastered Agility, they are once again turning to Innovation. In this talk, weâ€™ll explore how collaborative play and serious games can help organizations improve their agile and innovation processes.
One of the toughest problems facing agile UX designers is keeping the big picture in mind while designing incrementally. This talk builds on prior work at Alias (now Autodesk) that described successful agile adaptations of usability testing, contextual inquiry and iterative prototyping. Iâ€™ll present a framework we used to create and implement multi-sprint designs for a complex product without violating the agile taboo against big design.
Agile strives for good communication with their customers. The Embedded User Experience works with the customer to und
Eight thousand eight hundred and twenty-nine hours of pair programming â€“ does that make us experts yet? No, but we sure have learned a few things in five plus years. Many agile programmers see pair programming as too hard, but donâ€™t have the advantage of pairing all the time. Without applying pairing consistently, team members will not gain trust quickly. Without trust, pairing is difficult. This session will examine how practice makes perfect when it comes to being a good pair partner.
Mock objects are a good way to break apart a legacy system to test it. However, they do not improve coupling (few dependencies between units) or cohesion (each unit does one thing). Making code easy to change requires using indirections with looser coupling. In this information-dense, code-oriented session, weâ€™ll learn key indirections and their impacts on your design. Next time, choose the right indirection for the job rather than just reaching for another mock object.
The intern program at inContact uses 5-10 interns every quarter for a period of 10 weeks, and has been running for 1 1/2 years. Some of the challenges with using interns are discussed:
This experience report is about early adoption issues within two companies which share certain similarities (large, very distributed) but have differences as well (services vs products, IT vs engineering focus, close vs distant customers).
We're so used to talking about processes and methodologies in the form of big manuals, techniques and procedures from the 1980s and 1990s that we haven't noticed that the new methodologies aren't methodologies. They aren't even collections of practices. They're something else, something we don't yet have a word for. They incorporate a world view, practitioner promises for how to behave while getting work done, a few starter rules and an admission that the real work goes on between (hopefully) properly trained and skilled teammates. In this talk, Dr. Cockburn will introduce the problem we are having in talking about these non-methodologies, and show the shape of what is going on, as evidenced in Scrum and Crystal 2.0.
Great software is only possible in a true Learning Organization. This talk gives a pragmatic exploration of the connections between Sengeâ€™s five disciplines for learning organizations and the Agile software development framework. Specifically making use of Sengeâ€™s three legged stool of Aspiration, Understanding Complexity, and Reflective Conversation, Agile provides a strong pattern for creating and changing the realities of business and customer value delivery.
In 2000, Agile was revolutionary. In 2010, Agile is stagnant. There are two Agile worlds today: The first is pushing the same practices and processes theyâ€™ve been pushing for the last decade. The second takes many of these practices and processes for granted. Sadly, thereâ€™s little interaction between the two. In this discussion, weâ€™ll look at the rift between the two communities, how to bridge it, and the exciting possibilities that can exist when we do.
Agile methods promise an iterative and incremental approach to building software. Unfortunately, the iterative portion is often omitted when it comes to incorporating true user feedback and observation. In this workshop, participants will learn how to apply a method known as â€œdiscount usability testingâ€ to allow for fast and useful feedback from users that can be incorporated into their product delivery process.
Everyone has been to an Agile meeting that has little or no value and thatâ€™s felt like a complete waste of time. Facilitation Foundations is designed to offer attendees a chance to learn more about how to make meetings more valuable and save everyone time and money. This talk focuses on what makes meetings work and identifies negative experiences we all encounter when it comes time to attend or facilitate these common meetings. What should we be doing? What should we be avoiding? What could we do to improve the way we facilitate and or attend meetings? How can we make them more effective?
User Stories have become common practice among Agile teams. Cucumber is a Behaviour Driven Development (BDD) tool, written in Ruby, that allows teams to capture these stories in plain English as a series of scenarios. These scenarios become executable acceptance criteria that are incorporated into the development cycle allowing the developer to always know â€œwhatâ€™s nextâ€ and when the software is â€œdoneâ€. This talk is for every Agile team member but will provide enough technical details to enable a tester or developer to start using Cucumber immediately.
Is Certification important? Well that is a debatable topic that can take days and months to conclude. The fact is that for some people, in some cultures, and for some organizations certifications are important and have value; that is a fact. Our goal at the International Consortium for Agile (ICAgile) is to develop a certification program that truly adds value and assesses the skill set as well as knowledge of the individual before calling them certified anything. With this mission in mind, we have spent the last numerous months developing a strong certification program for the agile community. The objective behind this session is to introduce the new certification program and hear your feedback and opinions about it.
Agile developers and UX designers have a lot more in common than you might think. Weâ€™ll show that both agile design and development work best when they integrate and when users are put at the center of the process. Weâ€™ll focus on what works and what doesnâ€™t. Much of this presentation will build off of a national research study on design and development practices as well as case studies from Adaptive Path project teams.
We present a whirlwind tour of Michael Featherâ€™s book â€œWorking Effectively With Legacy Code,â€ showing and discussing specific techniques from the book, with full examples in code. Our intent is to display a variety of different ways to â€œslip testability into the cracksâ€ of existing codebases.