Event Details
Location & Dates
Event Management
Agile IT! is a production of the No Fluff Just Stuff Symposium Series. Since 2002, NFJS has produced over 130 technical events with over 21,000 participants. Be sure to attend Agile IT! and find out what the NFJS experience is all about!
Learn Better Ways to Develop Software Faster
The central theme of Agile ITX is to help your team consistently deliver better software. We'll focus on the entire software development life cycle, from requirements management to test automation to software process. You'll learn how to Develop in Iterations, Collaborate with Customers, and Respond to Change. Software is a difficult field with high rates of failure. Our world-class speakers will help you implement best practices, deal with persistent problems, and recognize opportunities to improve your existing practices.
This event will take place June 26 - 28, 2008 in Reston, Virginia.
Sessions at Agile ITX will cover topics such as: Continuous Integration (CI), Test Driven Development (TDD), Testing Strategies, Team Building, Agile Architecture, Dependency Management, Code Metrics & Analysis, Acceleration & Automation, and Code Quality. Our experts are successful leaders, authors, mentors, and trainers who have helped thousands of developers create better software.
Who should attend? This event is targeted to developers and technical management.
Video
Jay Zimmerman - What to Expect at Agile IT!
Jay Zimmerman is the director of the No Fluff Just Stuff Symposium Series.
In this video, Jay describes why he decided to create Agile IT!
Watch Video »
Venkat Subramaniam - Agile Design and Testing
Agility doesn't involve tradtional front-heavy design
followed by monumental development cycles.
So what is Agile design? Venkat calls it evolutionairy design.
Watch Video »
Featured Speakers
Registration Includes 3 Essential Books
The cost of registration includes 3 essential Agile books from The Pragmatic Programmers bookshelf.
Ship It!: A Practical Guide to Successful Software Projects
Many software projects run into trouble, and many never ship at all. Others run like well-oiled machines. This book shows you the basics of how to get your project well on the road to success.
Ship It! bucks current fashion trends and marketing hype; instead, you'll find page after page of solid advice, all tried and tested in the real world: a collection of tips that show you what tools a successful team has to use, and how to use them well. You'll get quick, easy-to-follow advice on modern techniques and when they should be applied.
Release It!: Design and Deploy Production Ready Software
2008 Jolt Productivity Award Winner
"Feature complete" is not the same as "production ready."
Whether it's in Java, .NET, or Ruby on Rails, getting your application ready to ship is only half the battle. Did you design your system to survive a sudden rush of visitors from Digg or Slashdot? Or an influx of real world customers from 100 different countries? Are you ready for a world filled with flakey networks, tangled databases, and impatient users?
If you're a developer and don't want to be on call at 3AM for the rest of your life, this book will help you.
Manage It!: Your Guide to Modern Pragmatic Project Management
2008 Jolt Productivity Award Winner
This book is a reality-based guide for modern projects. You'll learn how to recognize your project's potholes and ruts, and determine the best way to fix problems-without causing more problems.
Featured Sessions
By Andrew Glover
The discussion around Agile software development often times centers on the notion of increased software quality-- while this is a benefit of disciplined Agile software development, quality doesn't sell. While surveys often site quality as a prime concern of businesses, quality rarely gets attention when it comes to budgets. Try as you might, if you wave the quality flag, you'll be ignored. On the contrary, speed is what sells. The beauty of Agile, of course, is that if you do it right, you get both increased software quality and most importantly, a faster delivery speed.
By Chris D'Agostino
There is a lot of debate over the use of open source software compared
to buying COTS. While the cost of open source may be appealing, the
level of skill needed to integrate disparate open source products and
the technical support available might make selecting a well-designed,
well-supported COTS solution a better choice.
By David Bock
Agile software development isn't just about the development team or managers... the customer has an active role too. The customer should be prioritizing the stories in each release, potentially working onsite in constant contact with the development team, and even participating in daily status meetings.
Done well, the customer's presence has a positive influence on the development iteration. Done poorly, the customer detracts from the team's focus. So how do you be the customer of an agile team? How do you teach someone to be that customer?
By David Hussman
Management and agility are not mutually exclusive. Many managers are already working in an agile manner as a means to improve, produce, or simply survive. Other managers hear about projects using agile methods and struggle to find a place in the project community.
This session provides a new way to think about managing projects. Some managers will find that their existing practices and skills are supported and enhanced by the forums and metrics provided within an agile project while others will be challenged by some of the principles and practices.
By David Hussman
Successfully coaching agile communities involves using a wide variety of skills. Coaches help guide coding and design, collaboration and communication, the writing and telling of user stories and much more. The coach needs to continuously show and teach the varied interactions that connect and support the entire project community.
This session will explore and teach coaching skills. The session will reference a wide variety of agile coaching as well as drawing from cross disciplinary techniques like those used by music producers to help foster creativity while helping to ensure products are delivered and challenges confronted.
By David Hussman
Agile methods have cut through the noise and lighten the burden of crafting requirements documents. While this is good, it also shows clearly see that defining and guiding the creation of software products is challenging work. Most agile projects use a product backlog as a place to hold anything that will improve the product.
Creating strong product backlogs is less defined than many of the other agile practices. Backlogs contain many items: user stories, architectural spikes, investments in updating and maintaining development and other environments, and more. While it is clear that developers primarily code, it is often less clear who adds to and grooms the backlog.
By David Hussman
Why do we wait to test? Of course when you read this your thoughts went to testing code. While we still wait to test code and products early, we also wait to test ideas, projects, product direction, meeting and more. This session will show you (or challenge you) to think about test driven beyond the coding realm. You will be doing some thinking and talking and other things that involve more than just listening to someone talk with slides for 90 minutes.
By Jared Richardson
A great team builds great software, but how do you build a great team?
By Jared Richardson
An agile team is first and foremost "a team". When that gets lost in the rush to get a product out the door, the people suffer as well as the products. It's bad for the company, but even worse for the team members. We'll learn how to defuse some of the more common problems you'll run into on dysfunctional teams.
By Jared Richardson
Creating and maintaining a solid automated test suite is critical to an Agile strategy, but often we're just told to "Do it." In this talk we'll look at several pragmatic strategies for creating and building your suite.
By Johanna Rothman
You've managed projects but they're never easy. They don't fit into the nice definitions found in project management books. Your schedules are generally off. There are always unkind surprises. Although you're not failing, you feel you could be more successful.
By Johanna Rothman
Is your project plodding along? Would you like to know how to speed it up?
You and your team can learn how to start a project faster. Learn how to estimate your organization's "sweet spot," that period of time in which your organization can start and end projects. Discover how to make decisions about whether or not to start a project, including how to help your managers define the project portfolio to see where your project fits.
By Johanna Rothman
Even the people who claim experience on Agile teams are not necessarily working the way your team works. And, because not everyone is using Agile approaches, some people who aren't using strictly Agile approaches may be perfect for your team. If you've tried to hire people recently, you know you can't reply on people with or without "Agile" experience to be just right for your open position--and it wasn't a question of technical skill.
By Johanna Rothman
Are your schedules off as soon as you create them? Does your management expect you to meet impossible deadlines? Have you ever been surprised by how long tasks took to complete? If you answer yes to any of these questions, chances are someone in your organization is playing schedule games.
By John Carnell
The role of the technical lead has radically changed over the last several years. It used to be the technical lead was about being the senior developer on a team that made sure the code was getting written. You were the individual who knew the most about the technology stack you were the application with.
However, as projects have gotten larger and technical leads now having to deal with such things as offshore development teams and rapid delivery, the role of a technical lead has now shifted from less about technology and more about leading other people. The success or failure of project often hinges on the quality and depth of its leadership and most of us in our careers can point back to exactly this.
By Kirk Knoernschild
Agile has grown and evolved from a very simple developer centric process defined by Extreme Programming to a complex product brand that enterprises are using to bring more resiliency to governance programs, enterprise architecture initiatives, and application portfolio management efforts. But at its roots, there remains a key fundamental aspect that defines the essence of agility on the software development project.
Continuous Integration is a strategy where software is integrated and built continuously, or at least as frequently as is feasibly possible. Many teams have adopted a continuous integration strategy, yet do not fully capitalize on the benefits that continuous integration brings to the software development effort. This session discusses the subtle though significant ways that continuous integration can be leveraged strategically - from helping to align IT with the business to enforcing architectural constraints - and shows that this fundamental aspect of agility is the defining and necessary element of a truly agile development experience.
By Kirk Knoernschild
The practice of Continuous Integration facilitates early visibility into the development process by regularly conducting software builds, thus integrating disparate software pieces earlier than later, which often times minimizes the interval between when a defect is coded and when it is discovered. Often times though, Continuous Integration is thought of as a tool, which leads to a false sense of ease when it comes to adopting a Continuous Integration process.
This tutorial will walk students through a series of exercises on a fictional Java project where an automated build system is created that facilitates compilation, testing, inspection, and deployment. This build system is then plugged into a CI server and students will code a series of features using Agile techniques like developer testing, which will ultimately demonstrate how a Continuous Integration process reduces risk and improves software quality.
By Mark Johnson
As developers we dread when management requests a project estimate. Typically, you do not have the opportunity to understand all the requirements, the team composition is unknown, and you have been given until tomorrow end of day to produce an estimate. Several months later everyone is yelling at you about the software estimation errors encountered during the project.
By Mark Johnson
Development teams are increasingly scattered all over the world, often a development manager now days will never meet the entire team face to face.
By Mark Johnson
You have just received the much desired promotion to Technical Team Lead The team is waiting your direction. You What should you do now?
By Michael Nygard
The typical JEE application does not reach the fabled "five nines" of availability. Far from it. It's more like "double eights". Come see why enterprise applications and web sites are only serving users 88% of the time instead of 99.999%.
The bad news: applications are more complex and error-prone than ever. Site development projects are really enterprise application integration projects in disguise. SOA portends far-flung interdependencies among unreliable services. Failures will spread wider and wider, reaching across your company and even crossing boundaries between companies.
How do monumentally costly failures begin, develop, and spread?
Can they be averted?
Once you hit Release 1.0, your system will be living in the real world. It has to survive everything the messy, noisy real world can throw at it: from flash mobs to Slashdot. Once the public starts beating on your system, it has to survive--without you.
Did you know that just having your database behind a firewall can bring down your system? Ill show you that and many other risks to your system. You will learn the biggest risks to your system and how to counter them with stability design patterns. We'll talk about the best way to define the term "availability" and why the textbooks get it all wrong.
By Michael Nygard
What do you get when you add agile programming, automated deployment, self-describing systems, and virtualization? You get the quickest path from a great idea to a live site.
In this session, Michael will create and deploy a fully-functional web site. By the end of 90 minutes, you will be able to access the fully-deployed site live on the 'Net.
It used to take weeks and months to stand up a new site. You had to buy hardware, rent (or build) space, rack, stack, and cable it, and then you'd finally get to start installing operating systems, databases, and so on.
These days, none of that is necessary. You can run a real business on the net without ever owning anything. Best of all, you can be up and running in a single day.
By Ryan Shriver
Agile methods are increasingly becoming mainstream as teams and organizations transition from traditional "waterfall" methods. Adopting concepts from Lean and Scrum often have dramatic impacts on reducing delivery times for software projects, but without a committed focus on quality from architects and developers, these initial gains may fade in time. As the size and complexity of larger projects challenge organizations new to agile, a tendency to revert back to "big upfront design", "analysis paralysis" and "test and fix" cycles may return. This doesn't have to be the case, even on very large projects, teams and systems.
By Ryan Shriver
Everybody is talking about delivering business value but what does this mean in Agile? Scrum, for example, puts a lot of emphasis on the Product Owner's role of prioritizing backlog features and ensuring the highest priority features are delivered first. But how does a product owner do this so they can demonstrate measurable value delivered? How do the product owners, or the business leaders, articulate the real goals of the project or product under development for everyone to clearly understand?
By Ryan Shriver
Agile methods are increasingly becoming mainstream as teams and organizations transition from traditional "waterfall" methods. Adopting concepts from Lean and Scrum often have dramatic impacts on reducing delivery times for software projects, but without a committed focus on quality from management, these initial gains may fade in time. As the size and complexity of larger projects challenge organizations new to agile, a tendency to revert back to "over-definition of requirements" and "big upfront design" cycles may return. This doesn't have to be the case, even on very large projects, teams and systems.
By Venkat Subramaniam
Unit Testing is easy if the object you're testing has no dependencies. In reality, however, objects have dependencies,
often making it difficult, if not impossible, to automate tests. Mock objects can help deal with these dependencies
and allow you to automate your tests.
By Venkat Subramaniam
You have worked on software projects with varying degree of success. What were the reasons for the success of your last project? What were the reasons for those that failed? A number of issues contribute to project success - some non-technical in nature. In this presentation the speakers will share with you practices in a number of areas including coding, developer attitude, debugging, and feedback. The discussions are based on the 2007 Jolt productivity award winning book with the same title as the talk.
By Venkat Subramaniam
The first item in the Agile Manifesto reads that we must prefer "people and interaction over process and tools."
Given a choice between average people with superior tools and superior people with average tools, you are likely
to achieve greater success with the latter. However, it is important to be continuous and not be episodic?so you
want to get continuous feedback about the state, health, and quality of your code and application. Tools can
help us a great deal to realize this and make us productive.
By Venkat Subramaniam
A good design is critical for success with agile development.
That does not mean a big up-front design. The design has to
be evolutionary. However, the design you evolve must be
extensible and maintainable. After all, you can't be agile
if your design sucks.