|
|
|
 |
Flow, Pull, Innovate: How Agile Teams Mature and Scale
Jean Tabaka, Rally Software Development
Jean Tabaka offers straightforward advice on how agile teams can mature and learn to scale up to larger and larger projects. The three steps of her approach emphasize a path based on principles of Lean Thinking—Flow, Pull, and Innovate. Flow is about creating smooth delivery of value. Pull is the way teams pull ready items for delivery, and the business pulls ready, tested, and valuable features into productive use. Innovate is about how the organization drives improvements rather than merely responding to issues. For each of the three steps, Jean outlines practices for growth and identifies pitfalls to avoid and roadblocks to navigate around. You can apply the disciplines discussed in this class to a single co-located team, a team of teams, or an entire organization eager to take advantage of both agile and lean approaches. Join Jean and learn to achieve the greatest innovations with a much lower risk of failure.
|
|
|
|
Jean Tabaka is an Agile Mentor and Coach with Rally Software Development. In addition to being a Certified Scrum Trainer and Practitioner, she is also a Certified Professional Facilitator. Her unique blend of passions and skills has been applied in a variety of organizations—large and small, co-located and distributed—eager to adopt the best of agile and bring out the best in their teams. Author of the Agile Software Development Series book Collaboration Explained, Jean holds a Masters in Computer Science from Johns Hopkins University. When not sharing her agile passion with clients, she resides in beautiful Boulder, Colorado. |
|
|
| |
|
|
Agile Processes and Organization |
Maintaining Sustainable Agility
David Hussman, DevJam
Once your agile project is rolling, there are still many bumps and roadblocks—any one of which can derail the train. Whether you are leading the project formally or informally, there are a variety of useful techniques to keep the project alive and innovative. David Hussman shares his coaching approach and techniques for growing and maintaining sustainable agile communities. David starts by reviewing basics that must be in place and then moves on to advanced techniques—maintaining a living backlog, adapting to change, growing meaningful metrics, radiating information, working with project members, anti-coaching, and more. He also discusses a collection of useful monitors—spontaneous pairing, “us” and “them”, presence of pride, emergence of leaders— to determine when to effectively employ one or more of the coaching techniques.
|
|
|
|
David Hussman leads DevJam, a company comprised of agile collaborators working on assignments worldwide. As mentors and practitioners, DevJam focuses on using agile methods to help people and companies improve their software production skills. In addition to coaching, teaching, and leading workshops and tutorials at conferences in the US and Europe, David has contributed to several books (Managing Agile Projects and Agile in the Large), worked on agile curriculum for The University of Minnesota and Capella University, and currently is writing a book for the Pragmatic Programmer series. |
|
|
| |
Empirical Studies of Agile Practices
Laurie Williams, North Carolina State University
Gone are the religious wars of plan-driven vs. agile software development methodologies and practices. Recent surveys indicate agile practices are being adopted in many software development organizations, with others seriously contemplating making the switch. The question from most organizations now has turned from plan-driven vs. agile to which agile practices they should use in their development process to most improve their business results. The experiences of other organizations that have adopted agile practices help answer this question. Based on her empirical studies of Extreme Programming teams and other agile practices, Laurie Williams shares her views on which agile methods have been most beneficial to industrial teams practicing agile development. Armed with real data, you can implement changes with more confidence that they will add value in your organization.
|
|
|
|
An Associate Professor in the Department of Computer Science at North Carolina State University, Laurie Williams is the lead author of Pair Programming Illuminated and a co-editor of Extreme Programming Perspectives. Laurie received her MBA from Duke University and worked at IBM for nine years before obtaining her Ph.D. in Computer Science from the University of Utah. She was a founder of the XP Universe conference, which has evolved into the Agile Software Development conference. Laurie has conducted empirical studies on Extreme Programming and other agile development practices. |
|
|
| |
Leading Successful Projects in Changing Environments
Pollyanna Pixton, Accelinnova
There’s no doubt about it—agile has gone mainstream. Short delivery iterations give organizations the means to incorporate change safely, reach go/no-go decisions early, and discover realistic team velocities. Managers can better determine if market windows can be reached—thus placing successful products in customers’ hands. What if the ground beneath the project team is changing rapidly even as it is trying to make progress? Pollyanna Pixton shares a collaboration model and iterative delivery process that will help you succeed, even in unstable conditions. She shares her ideas on creating an open environment, identifying the talent the team needs, managing risks, and creating team ownership to ensure great results. Among the skills you need are a collaborative, transparent leadership style; an approach to positively influence outcomes; collaborative communication—and then the knowledge of when to stand back and let things happen. Leave this class with some keys to successfully lead agile project teams—even in the midst of chaos.
|
|
|
|
Pollyanna Pixton has implemented large-scale agile projects including developing the Swiss Electronic Stock Exchange and control systems for electrical power plants throughout the world. She teaches Agile Project Management at the University of Utah and in organizations. Pollyanna has a Bachelors degree in mathematics, Masters degree in computer science, and graduate studies in theoretical physics. She co-founded the Agile Project Leadership Network (APLN) and chaired the Agile 2006 Leadership Summits in London and Minneapolis. Contact Pollyanna at [email protected]. |
|
|
| |
Refactoring: Where Do I Start?
J.B. Rainsberger, Diaspar Software Services
Since Martin Fowler completed his now-classic work Refactoring: Improving the Design of Existing Code, few programming practices have been more effective—and more controversial—than refactoring. Refactoring is effective when you study and practice it diligently. It remains controversial because many development managers think developers should be adding features, not reworking old code. J.B. Rainsberger takes you deep inside the process of refactoring, including: how to refactor code you don't know well, when to refactor toward a design pattern, and the four key elements of simple design that should guide your refactoring. He explains the hazards of refactoring, when not to refactor, and how to refactor in such a way as not to upset your boss. After this class, you will be able to refactor your own code more confidently and effectively. You might just impress some of your colleagues along the way.
Calling all code bases! J. B. Rainsberger would like to refactor your code, live on stage at his session "Refactoring: Where Do I Start?" Find out how to send him the code you'd like to see refactored.
|
|
|
|
J. B. (Joe) Rainsberger is a programmer, coach, mentor, and author. His book JUnit Recipes, which has become "the bible of JUnit", is a manual for Java programmers to improve their programming skills through programmer testing. Beyond helping programmers learn how to test, Joe teaches teams about XP, teamwork, and object-oriented design. He is a dynamic presenter who likes to teach by example. Read his popular blog at jbrains.ca or his column "Not Just Coding" in IEEE Software magazine. |
|
|
|
|
|
Agile Design and Programming |
Behavior Driven Database Design
Scott Ambler, IBM Rational
In Behavior Driven Development (BDD), you write behavioral tests of an application just-in-time, one test at a time to express its design. You can take a BDD approach to a database schema in the same way. Scott Ambler presents the Behavior Driven Database Design (BDDD) technique. He explains its relationship to Agile Model Driven Development (AMDD) and how it fits into agile software development in general. Find out how to refactor a database by applying simple changes that improve the design without changing its semantics. Create a comprehensive regression test suite to validate your database on a regular basis, ideally whenever a change is made to the database schema itself or when the database is accessed in a new way. Go even further and implement continuous database integration where the database is automatically rebuilt and retested whenever its schema changes.
|
|
|
|
Scott Ambler is the Practice Leader Agile Development in IBM’s Methods Group. He is the founder of the Agile Modeling, Agile Data, Agile Unified Process, and Enterprise Unified Process methodologies. Scott is the (co-)author of nineteen books, including Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, and The Enterprise Unified Process. Scott is a senior contributing editor with Dr. Dobb’s Journal. His personal home page is www.ibm.com/software/rational/bios/ambler.html. |
|
|
|
| |
Open Spaces Runs All Day!
Want to discuss a topic that is not on the program? Great! You need Open Spaces.
We supply the room and the chairs. You supply the ideas and the leadership. Choose a topic you’d like to discuss, pick your timeslot, promote your topic at the conference, enroll others, and have a ball.
That’s what Open Spaces is all about—you are in charge of your learning.
The basic principle is: Everyone who comes to an Open Space session must be passionate about the topic and willing to take some responsibility for creating learning out of that passion.
Five other key principles are:
1. Whoever attends is the right person.
2. Whatever happens is the only thing that could have happened.
3. Whenever it starts is the right time.
4. When it is over, it is over.
5. The Law of Two Feet—If you find yourself in a situation where you aren't learning or contributing, go somewhere else.
If you’ve never tried Open Spaces, do it now. You'll teach and you'll learn.
|
|
|
| |
|
Using the Theory of Constraints to Coach Agile Teams
Naresh Jain, ThoughtWorks
Even as a large number of teams are adopting agile methods, some teams are finding this transition to be a big leap. Because each team is unique, they are not able to follow all of the practices “by the book.” Each team must customize certain practices to best suit its needs and abilities. Naresh Jain shares his experiences guiding agile teams through this transition. He introduces a technique of coaching teams that employs Goldratt’s Theory of Constraints to identify the bottlenecks and issues faced by the team during the agile adoption process. Naresh shows how more experienced agile teams can use the Theory of Constraints technique as a just-in-time practice to eliminate bottlenecks and deliver new knowledge and experience to the team.
|
|
|
|
Naresh Jain is a software craftsman working as a consultant for ThoughtWorks India. He has worked on a variety of software projects utilizing XP, Scrum, and CMMI5i in India and the US. Naresh is the founder and vice-chairman of the Agile Software Community of India and the organizer of the Simple Design and Testing Conference (SDTConf). He has helped start various agile user groups including the Agile Philly User Group and several groups in India. By becoming part of a team, Naresh helps software companies embrace agile. Naresh enjoys beer, music, adventure sports, and spicy food of any color. You can reach him at [email protected]. |
|
|
| |
|
|
Agile Processes and Organization |
Making People and Processes Congruent
Ken Pugh, Net Objectives
Agile processes work better if developers and customers have specific aptitudes and attitudes, such as the ability and willingness to handle rapid change. Members of an agile product team cannot always be selected to ensure that they innately possess these capabilities. Developers may not appreciate the need for unit testing. Customers may not be able to interact easily to create just-in-time requirements. You must adapt your agile implementation so that team members can work effectively within their capabilities. In this interactive class, participants first outline people issues they have faced. Based on common issues, the class self-selects into small groups to discuss their challenges in more depth. Each group develops ways to approach these issues and improve their teams. At the end, groups share their key results with the whole class.
|
|
|
|
A fellow consultant with Net Objectives, Ken Pugh ([email protected]) consults, trains, mentors, and testifies on technology topics ranging from object-oriented design to Linux/Unix to the system development process. He has written several programming books, including the Jolt Award winner Prefactoring and has served clients from London to Sydney. When not computing, Ken enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail. |
|
|
|
Agile Development and Its Impact on Productivity
David Garmus, The David Consulting Group
An agile approach can deliver recognizable value to organizations. Using examples from recent projects, David Garmus demonstrates that software development projects can benefit from using the agile methodology when appropriate. Delivering a project in an organization that is following an agile implementation methodology can be faster and more productive than the same project in an organization that is using the traditional waterfall approach. David provides actual delivery (project performance)
rates and productivity comparisons to support these conclusions. The most productive agile development projects that David has observed typically have similar characteristics and core practices. He offers a set of selection factors—project characteristics, application complexity, application interfaces, project size, team composition, team size, and financial risk—to help you decide when agile development is right for your next project.
|
|
|
|
David Garmus is a founder of The David Consulting Group (DCG), an SEI CMMI® Approved Transition Partner, which supports software development organizations in achieving software excellence with a metric-centered approach. David is an acknowledged authority in the sizing, measurement, and estimation of software application development. He is a past president of the International Function Point Users Group (IFPUG) and a member of their Counting Practices Committee. A member of PMI, SEI and QAI, David has spoken at numerous conferences and written several books and many articles. |
|
|
|
Scrum: An Introduction (Part 1)
Hubert Smits, Rally Software Development
Scrum is the most popular agile project management method today. Hubert Smits illustrates the basics of this method based on his experiences in implementing Scrum in many organizations. He explains the concepts of Scrum to software developers, development managers, and CIOs who are adopting—or thinking about adopting—Scrum in their organizations. After discussing the position of Scrum within the agile world and comparing it to methods like Extreme Programming and Lean Software Development, Hubert takes you through the full Scrum methodology and explains the meanings and practical implementations of Product Backlog, Sprint Planning, Product Increments, and Retrospectives. Join Hubert for a highly interactive discussion of this important project management approach.
See T17 for Part 2 of this class.
|
|
|
|
Hubert Smits is an Agile Coach, working for Rally Software Development in Boulder, Colorado. In this role he travels the world to support organizations in the implementation of agile methods. He works with teams to train them during the implementation cycle, facilitates planning meetings, and coaches executive teams in the management of the new approach to software development. A Certified ScrumMaster and Scrum Trainer, Hubert has authored papers on Scrum implementations (“The CIO Playbook of Implementing Scrum” – with Ken Schwaber) and planning in agile projects (“Five Levels of Agile Planning”). |
|
|
|
Agile Software Testing Strategies
Jared Richardson, Agile Artisans
Test automation is like exercise. We know both are great ideas, but most of us don’t do much of either. Although we know that creating a solid automated test suite is critical to any agile testing strategy, we are often just told to “Do it” without much support—money or people. Jared Richardson examines the infrastructure and tools you need for your automated testing to succeed and prosper. Jared examines three strategies—Test-Driven Development, Defect Driven Testing, and Blitzkrieg Testing—you can use to ensure great test coverage on your projects. Looking at real life scenarios as a backdrop, Jared discusses appropriate testing strategies for your current project or the next one down the road. Jared will get you moving toward automated testing, whether you're starting fresh or trying to clean up an existing project.
|
|
|
|
Jared Richardson, co-author of Ship It! A Practical Guide to Successful Software Projects, is a speaker and independent consultant who specializes in using off-the-shelf technologies to solve tough problems. With more than ten years of experience, Jared has been a consultant, developer, tester, and manager, including Director of Development at several companies. Until recently he managed a team of developers and testers at SAS Institute, Inc., and deployed a continuous integration system for nearly 300 projects, five million lines of code, and more than 1,800 developers. He also led a company-wide effort to increase the use of test automation. Jared can be found online at JaredRichardson.net. |
|
|
|
|
|
Agile Design and Programming |
API Design for Testability
Roy Osherove, Sela Group, Israel
Many who try to unit test their applications—whether using agile or traditional methods—quickly find that doing a thorough job can be difficult if the code was not designed with testability in mind. Roy Osherove describes dependency injection methods for designing APIs so that they are easier to test. He explains how design patterns can help and how to implement applications with interface-based programming. Roy shares his insight on what “evolving a design” really means in the context of test-driven development. For those who are living with legacy code, he discusses special techniques for managing and implementing unit testing. In addition, Roy discusses the build life cycle and how continuous integration fits into the mix.
|
|
|
|
A recognized Microsoft MVP, Roy Osherove has been in the software development business for more than a decade and is a frequent speaker at international conferences. Roy is one of the leading agile development experts in Israel and is the founder of the Agile Israel user group. He is currently writing a book The Art of Unit Testing and consults regularly about agile development practices, unit testing, and deep .NET architecture for companies around the world. Currently, Roy leads the agile area at Sela Group. You can find Roy's blog at www.ISerializable.com. |
|
|
|
|
|
Climbing the Decision Tree: Reaching High Quality Team Decisions
Diana Larsen, FutureWorks Consulting
When teams “go agile,” members of the whole team take on greater responsibility for thinking and deciding as a unit. Though individual team members may know how to make great individual decisions, few people bring the skills or perspective needed to make high quality decisions as a group. Teams need to plan for all elements of high quality team decisions, balancing technical quality, commitment to implementation, efficiency, and opportunities for team development. Rather than relying solely on a consensus model, an effective team will have a repertoire of decision-making methods and select the best approach for their decisions before they face each choice point. Diana Larsen introduces a decision tree model for teams and covers the what, who, when, where, why, and how of team decision-making.
|
|
|
|
Diana Larsen consults with leaders and teams to improve project performance, support innovation, and establish satisfying, results-oriented workplaces. With more than fifteen years of organizational development experience working with technical professionals, Diana brings focus to the human side of software development. Her clients value her collaboration in building their capability to interact, self-organize, and shape an environment for productive teams. A former board member of the Agile Alliance, Diana co-authored Agile Retrospectives: Making Good Teams Great. |
|
|
| |
|
|
Agile Processes and Organization |
Organizational Patterns: The Foundations of Agile
James Coplien, Nordija A/S
Organizational patterns describe the inner-workings of organizational structures. These patterns are the foundation for agile competence and take you far beyond basic out-of-the box methods to provide deeper insights into agile. Both Scrum and XP have their roots in these patterns, focusing on project management and developer practices respectively. Jim (Cope) Coplien explains the other 75% of the good stuff —the things that Scrum, XP, and other methodologies gloss over. Cope presents the “Top 10” organizational patterns—those that correlate most strongly to organizational success. Do you capitalize on DOMAIN EXPERTISE IN ROLES? How about ARCHITECT ALSO IMPLEMENTS, or the important role of the manager as FIREWALL to distance the developers from “those who want to help?” What important concepts are you missing in your agile practices?
|
|
|
|
A Senior Agile Coach and Software Architect at Nordija A/S in Copenhagen, James Coplien is the co-author of Organizational Patterns of Agile Software Development. Cope's perspectives are grounded not only in extensive empirical research but also in his long-standing and ongoing work writing production software. His current endeavors include consulting on software architecture and organizational structure, agile readiness assessments, software usability consulting and training, and research into patterns for highly dynamic systems. James has never designed a programming language and has never created a methodology.
|
|
|
The Impact of Poor Estimating—And How to Fix It
Mitch Lacey, Ascentium Corporation
The team, running Scrum by-the-book for three months, was continually failing to meet its delivery dates. As a result, trust between the business managers and the team degraded almost to a point-of-no-return. The team, which held bi-weekly retrospectives, could not pinpoint the problems causing its inability to ship. Mitch Lacey was asked to assist the team in finding the root cause of its problems. He analyzed multiple aspects of the project—from individual work items to planning meetings. While multiple issues were identified, one thing stood out above all others—the estimation process used had caused the team to miss its deadlines. Mitch discusses the estimation problems the team was having, how they were discovered and fixed, and the resulting improvement in financial and customer satisfaction.
|
|
|
|
A Technical Project Manager with Ascentium Corporation, a technology and marketing consulting firm, Mitch Lacey has ten years of project management experience, managing numerous plan driven and agile projects over his career. Mitch honed his agile skills at Microsoft Corporation, where he successfully released large backend core services for Windows Live. From this, he transitioned roles from Program Manager to Agile Coach, where he worked hand in hand with other groups throughout their transition to agile practices. Mitch is a registered Project Management Professional (PMP) and a Certified Scrum Trainer (CST). |
|
|
| |
Scrum: Roadmap for Implementation (Part 2)
Hubert Smits, Rally Software Development
With quite a few successful agile implementations under his belt, Hubert Smits guides you through the steps for implementing Scrum in an organization. Scrum implementation grows from a single team working on a pilot project, to multiple development programs running in parallel—all with Scrum as the underlying methodology. Hubert explains how to train and motivate your pilot teams and replace your project requirements documents with a backlog. He outlines the roles of architect, business analyst, and tester in a Scrum-led project. Learn what happens when multiple teams have to work together and how dependencies between teams are discovered and managed. Find out how change management becomes an integral part of the project and discover new management tools that you can use in an agile project.
See T11 for Part 1 of this class.
|
|
|
|
Hubert Smits is an Agile Coach, working for Rally Software Development in Boulder, Colorado. In this role he travels the world to support organizations in the implementation of agile methods. He works with teams to train them during the implementation cycle, facilitates planning meetings, and coaches executive teams in the management of the new approach to software development. A Certified ScrumMaster and Scrum Trainer, Hubert has authored papers on Scrum implementations (“The CIO Playbook of Implementing Scrum” – with Ken Schwaber) and planning in agile projects (“Five Levels of Agile Planning”). |
|
|
| |
That's Not Right! Using Fit to Prevent Business Rule Defects
James Shore, Titanium IT
Sophisticated applications involve huge numbers of detailed domain business rules. These rules are the heart of the application, determining critical details such as how much money is transferred between two banks (in a financial application), which compounds have been identified in a sample (in a chemistry application), or how a customer's money should be refunded (in a point-of-sale application). These details, while crucial, are too easy to get wrong. Sometimes, only the business experts can tell when the software is right or wrong. That's where open source Fit can help you. Fit is an automation tool for helping improve communication between business experts and programmers, allowing you to identify miscommunication and prevent business rule defects before they happen. Join James Shore for an introduction to using Fit in your project.
|
|
|
|
James Shore is an award-winning agile practitioner and coach. A professional software developer since 1994, he has been leading teams since 1999. The Agile Alliance awarded James the Gordon Pask Award for Contributions to Agile Practice. His recent book, The Art of Agile Development (co-authored with Shane Warden), was published by O'Reilly in September. Find more of James’ work on his Web site, www.jamesshore.com. |
|
|
| |
|
|
Agile Design and Programming |
Executable Documentation
David Hussman, DevJam
Why is so much project documentation outdated and worthless? Simply put, the real value is in the final product; so, that’s where the money goes. Wouldn't it be nice if your documentation actually reflected the functionality in the system? One way to do this is to create executable documentation, also known as executable specifications. Join David Hussman for this class if you are struggling with ambiguous requirements, lack of collaboration with users, or a lack of communication among developers, business stakeholders, and testers. Although David uses open source Fit as a vehicle for demonstrating executable documentation, the class will teach you how to develop the information you need to make any similar tool serve up meaningful requirements that have two states—red (dead) or green (alive). Starting down the path to executable documentation is a great way to remove waste and more quickly produce better software.
|
|
|
|
David Hussman leads DevJam, a company comprised of agile collaborators working on assignments worldwide. As mentors and practitioners, DevJam focuses on using agile methods to help people and companies improve their software production skills. In addition to coaching, teaching, and leading workshops and tutorials at conferences in the US and Europe, David has contributed to several books (Managing Agile Projects and Agile in the Large), worked on agile curriculum for The University of Minnesota and Capella University, and currently is writing a book for the Pragmatic Programmer series. |
|
|
| |
|
|
