Session Schedule

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.

In this session, we'll discuss Agile engineering principles that yield faster delivery of features with measurable quality. You'll learn that if you plan to sell Agile within an organization, big or small, if you start with speed, you'll get much much farther.

By Andrew Glover
Behavior-driven development, or BDD, has attracted a lot of attention via RSpec in the Ruby community, but BDD's roots stem from JBehave, a Java based framework modeled off of the xUnit paradigm.

But JBehave isn't the only framework available for Java developers-- with the advent of Groovy, new options are available for embracing BDD in the spirit of RSpec's innovative behavior based DSL.

By Bob Payne
In theory, theory and practice are the same … in practice they never are.

This workshop will discuss the real world challenges and techniques used
for scalling agile projects gained on multiple 100+ member agile projects.


Attendees will be presented with specific challenges to address and work
in small teams to come up with strategies to address those challenges. Bob
will then discuss the approaches that were used and how the theory played
out in practice.

By Bob Payne
Experience the joy of coordinating and integrating the code of multiple
teams and multiple applications and save the world. This Scrum of Scrums
simmulation will provide attendees insights into the complexity of
coordinating multiple projects in an agile manner.

This simmulation is intended to exercise the following Agile Practices.

- Cross Team Integration with a Scrum of Scrums
- Story Card Estimation
- Iteration Planning
- Continuous integration across multiple code bases
- Supporting integration with Test Automation

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.

This talk will compare the pros/cons of various large scale implementations using each and
the tradeoffs of having an average development team versus a mediocre commercial product.

By Chris D'Agostino
So your organization's strategic IT direction is to use Agile, but word is it's just a fad, and anyway, using Agile means that your project is going to be filled with undisciplined, unplanned, unpredictable development...right? Just the opposite. Walk away from this presentation with field-tested tips, lessons learned, and case studies on using Agile to deploy high-quality software that your customers actually need and use.

In this talk you will learn how to:

* Run a project using the SCRUM methodology so that your customer stays committed and your team delivers on its promises.

* De-compose requirements into manageable chunks and accurately estimate how long it will take to develop the application.

* Measure your team's progress and keep the project moving in the right direction

* Receive and incorporate CRITICAL feedback from your end users

* Deliver an application that meets the ACTUAL needs of your users

By David Bock
Agile development teams should always be looking for ways do develop software better, and the iteration is the perfect tool for doing so. Each iteration we can tweak, tune, adjust, and readjust our practices. So how does an agile team decide what to tweak? This is the purpose of the Agile Retrospective.


On one end of the spectrum we have the 15 minute "what works and what didn't" meeting, and on the other hand we have the "offsite summit" looking at the entire project timeline, from the first handshake with the client to the deployment of maintenance releases. Where do these kinds of meetings fit in the Agile project lifecycle? What kinds of things can we expect to learn? Are there any topics off-limits to the critiquing eye of improvement? How do we keep the focus on the software and not the people? Will we have to manage personnel conflict?

In this session we will learn how to run an agile retrospective while keeping focus on the goal: uncovering better ways of developing software.

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?


In this session we will look at an overview of agile methodologies and the role of the customer, customer proxy, and other versions of the "product owner", and their responsibilities in ensuring the success of an agile software development project.

By David Bock
After months of effort, your software is done. Or is it? Very few successful projects in our industry are really 'done'... The success of the software often breeds feature requests, spinoff ideas, scalability concerns, not to mention the continued maintenance of the hosting platform, security, data backup, and so on.

In this session we will look at how to set your project up for continued agility after the bottle of champagne has been opened. Starting with good practices for configuration management, a checklist of the kinds of things for which we need to plan, and ideas for managing your 'maintenance', your project can survive its own success.

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.

From product definition to project chartering to planning, estimating, and tracking, this session will discuss practices of agile managers working on agile projects of all sizes. The session will contains a collection of interactions meant to teach, challenge, and immerse you in the managing and leading an agile project.

By David Hussman
Why should the value of test driven development (TDD) stay stuck in the realm of coding? The ideas behind TDD are now being successfully applied to the automation of business value. While this has been going on for some time within the agile community, it is not starting to spread to main stream development.

There are more tools are coming available everyday which allow developers, testers, and customers (or product owners) to work together to automate acceptance tests. This process helps clarify the needs of the end user before development begins and removes more of the wasteful work based on incorrect assumptions from vague requirements.


This session will talk about how to get people working together to automate acceptance testing. We will cover the creation of testable work units, like user stories, the collaboration around creating the initial acceptance tests, and several ways for various people in your project community to come together to automate acceptance tests and delivery more and better software.

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.

We will discuss ways to help a community find their groove in the first few iterations and we will end by talking about techniques for keeping the groove alive past the first release and into the future of the project.

Some of the many areas that will be covered are:
- Organizing and leading a chartering session
- Creating a creative work space
- Helping to write stories and build an initial backlog
- Getting people talking and collaborating
- Raising awareness with meaningful metrics and information radiators
- Connecting with the difficult or uninterested players
- Growing community coaches

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.


The sessions covers the creation, prioritization, maintenance and grooming of a product backlog. We will cover core topics like user stories and personas, and we will also dig into the challenges of keeping a backlog healthy. We will examine various ways that project communities contribute to and draw from a backlog, and we will examines several example projects and how they have learned the best way to collaborate around the backlog to make sure the product evolves in the most valuable direction.

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.

Along with testing driven development, it is possible to test drive projects, meetings, and more. Using vehicles like project chartering, release planning, story tests, we will discuss concrete techniques you can use to infuse test driven into your project community, allowing you to remove duplication and discover dependencies.

By Esther Derby
"Experience is not what happens to a man; it is what a man does with what happens to him." A. Huxley.
The same is true for software teams. Too often, we don't do much ? if anything ? to squeeze learning out of experience. Retrospectives are a way to take "what happens" during a software development project and use it to build understanding and capability. This team learning process is an integral part of every Agile method.

This interactive session will cover a flexible framework to help teams think and learn together in iteration, release and project retrospectives.

By Esther Derby
When agile teams self-organize, some managers believe their work is done. Not so. While a manager?s focus may shift away from delegating, making assignments, and tracking progress, there is still plenty to do.

In this interactive talk, we?ll look at the new role of facilitative managers in organizations with Agile teams: managing constraints and boundaries, attending to team membership, and working across the organization.

By Jared Richardson
A great team builds great software, but how do you build a great team?

Let's move beyond getting lucky and look at some key practices that will help you build your scattered cats into a well-oiled machine.

By Jared Richardson
Agile practices are popular because they work, but getting people to take that first step can be tricky.

We'll look at how continuous integration was successfully introduced to a very large, established software shop and used to introduce other Agile practices. Let's see what lessons we can draw from this example that you can take back to your shop.

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.

Restoring trust and providing visibility is hard once you've been burned. It's not always possible, but we'll examine concrete steps you can take to start rebuilding your trust and your team.

By Jared Richardson
Technical debt has long been recognized in technical circles for years, but convincing your manager to budget time to repay "technical debt" has always been problematic. Let's couch the term technical debt concept in language more familiar to our managers: credit card debt.

Like credit card debt, technical debt accumulates slowly over time, and usually takes just as long to pay off. The interest slowly builds up until you're no longer able to pay off the principle: your entire development cycle is devoted to just "paying the interest". We'll examine common types of technical debt and strategies to effectively communicating the problems, and their solutions, to your managers.

By Jared Richardson
There are a number of great techniques you can use across technologies and projects. Come hear some of my favorites and contribute a few of your own. We'll discuss topics from DRY to creating a zone defense for your product.

In this session we'll discuss:
-grassroots process improvement
-DRY code: why and how
-establish a zone defense for your code
-tracer bullets
-test automation
-lunch and learn
-the home server
-leaving your comfort zone for fun and profit

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.

We'll examine these strategies and then look at scenarios for using them next week. This presentation will get you started whether you're starting a new project or trying to clean up an existing one.

By Jeff Kunkle
The benefits associated with having your development staff exposed to multiple languages, even if they deploy applications in one primary language, are enormous.

New languages expose developers to new ways of thinking about software and highlight the pain points of your current
technology stack. It forces organizations to move outside their comfort zone in an effort to deliver robust applications quickly.

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.

There is a solution--actually several possibilities. You can take a more pragmatic approach. Employ mini-projects and iterations to explore alternatives technologies. Use incremental steps to finish features one-at-a-time when you don't know how far along you are. Make sure stakeholders agree on what "done" really means. Learn how to escape the dreaded trap of multi-tasking, a management style that drains energy from everyone whenever there is a task switch. One final secret every project manager must discover: There is no one right way to manage a project. Everything depends on context--the company and its products, the technology employed, the people on your team, and you. If you can learn to keep everything in balance, you will have a successful project. Let something get out of whack and you can kiss all your hard work goodbye.

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.


We'll discuss ways to measure and steer your projects, to help you get to the end faster, including approaches such as rolling wave scheduling, continuous integration, using timeboxes to focus the work, and more. We'll discuss knowing what "done" means, so you can help the team get to "done" faster, and not go past it. You don't have to use all of these tips, but the more you do, the faster your project will run.

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.

In this hands-on session, we'll define the essential technical and non-technical skills for your position, identify your cultural issues, and practice interviewing so all your hires can be successful.

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.

There are many different schedule games, but they all have similar results: the project team is behind the eight ball. We?ll look at how to recognize the signs of schedule games, how to address the underlying problems, and how to change the rules.

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.

This talk will look at the ten most common traits needed for leadership and will look at how they can be applied to yourself or other technical leads in your team. The talk will cover such topics as communication, planning and working through people problems. We will also talk about how you as a technical leader can remain relevant in our fast-paced field.

By John Carnell
Waste is an insidious beast that drains the productivity of development teams and the organizations they work in. Many organizations are now realizing that by turning their gaze inward they can streamline their overall development processes, deliver higher quality products faster and save significant amounts of money.

This talk will look at how to use Lean and Toyota Production Systems manufacturing techniques to streamline how your team builds software.

Waste is an insidious beast that drains the productivity of development teams and the organizations they work in. Many organizations are now realizing that by turning their gaze inward they can streamline their overall development processes, deliver higher quality products faster and save significant amounts of money.

In this talk we will look at the "Lean" techniques first developed by companies like Toyota and how they can be applied to common software development practices. We will walk through such concepts as identifying the different types of waste you might encounter in a software development effort, using Value Stream Mapping (VSM) to help measure the impact of that waste and different techniques you can use to eliminate that waste.

You will see a real-world case study of how the Lean methodology helped one company realize a significant costs savings. By the time the talk is done you will be able to take the lessons learned and use them to build real-world, hard dollar business cases that you can show to your upper management.

Audience: This talk is geared towards new and existing technical leaders. This talk will include very little technology and non-leads might find this talk not directly useful to their day-to-day work.

By Ken Sipe
Thoughts lead to words, words lead to action, actions lead to habits. In this session we'll sharpen the development saw in the process of understanding what makes a hyper-productive programmer. The focus will consist of developer habits and development processes.


As described in the book "7 Habits for Highly Effective People", there are habits which are characteristic of highly effective people. Clearly there are hyper-productive developers which distinguish themselves from the development pack? what is it that makes the difference? What are the habits and practices of highly effective developers?

This session will focus on individual developer habits, as well as team practices and the processes which result in high quality running software.

By Ken Sipe
The success of an Agile / SCRUM project is a successful start. The first interaction is often referred to as iteration 0. Other iterations have a set of stories with clear acceptance certain which establishes the velocity of the team and its effort. What then is accomplished in iteration 0? How do we get an Agile process started.

This session will outline all the "pre" activity tasks which led into an agile development process. As well as the establishment of a tasklist of iteration 0, include the establishment of development environment, configuration management details. This will include several case histories examples of Iteration 0.

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.


In this session, we will explore the short and long term affects of continuous integration from initial adoption of a continuous integration strategy to leveraging the value of continuous integration throughout the software lifecycle. Tales from real world enterprise development CI experiences will be shared. Students will learn:

1. What is CI
2. How CI positively affects the entire software team - not just developers
3. The impact of CI on the software life cycle from requirements through delivery
4. Common CI impediments and how to overcome them
5. Steps to adopt and grow your CI strategy

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.

Students will learn how to set up and define an automated build system that includes running tests, inspections, and deploying software assets; moreover, students will learn how to setup a Continuous Integration server and configure it with an SCM. Students will also learn Agile techniques like developer testing.

Given the automated nature of continuous integration spawned builds, software teams can now start to look at their build process as something more useful than a simple compile and test process. Students will learn:

1.What is CI
2.How to configure a repeatable build system
3.How to build in quality through developer testing
4.How to configure a working CI system
5.How to interpret the results

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.



This presentation will cover some simple techniques for creating order of magnitude estimates. In addition, leveraging the cone of uncertainty the presentation will also cover techniques for managing management expectations.

By Mark Johnson
Once you leave academic "hello world" projects, software development is full of unknowns which result in the high rate of project failure we see too often in industry. Reasons for a project failure will vary based on the stakeholder interviewed.

This session will provide a software development risk framework and examples you can apply in your projects to reduce or at least soften the impact of failure.

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.

This session will explore useful metrics for managing distributed development teams and keeping the project on-time and on-budget.

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?

This session uses discussion to explore common pitfalls encountered by new Technical leads as well as possible solutions.

By Mark Johnson
How do you know when you are "DONE" and the assignment is complete? Well of course you are done when your requirements are complete. But it always happens that your interpretation differs from the customer/management's interpretation.

This session will explore the use of FitNesse to create "Business" readable test cases before development even begins so you can agree with your customer as to what "DONE" means and prove that you have actually completed the requirements to specifications.

By Matthew Bass
Pair programming. It's nasty. It's evil. The only people who actually do it are those Extreme Programming zealots, and we all know what they're like. Pair programming deserves to be condemned to the trash heap of practices that failed, destined to go down in history as the black sheep of agility. Right? Well, maybe not. Maybe pair programming does have some value after all. Maybe it can be redeemed if done the right way, the pragmatic way.

Let's re-examine pair programming in a spirit of discovery. Let's learn how to avoid the many pitfalls inherent in it, and carefully refactor it to yield tangible, measurable benefits. Let's make sure we're not doing pair programming for its own sake, but only because it makes us more productive, increases code quality, and boosts team cohesion.

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.



In this session, you will learn why the path to success begins with a failure-oriented mindset. I'll talk about numerous antipatterns that have caused and accelerated millions of dollars worth of system failures. I'll share some of my scars and war stories with you (don't worry, they're all suitable for polite company) in the hopes that you can avoid some of these costly disasters.

By Michael Nygard
What can we do about the dismal uptime of typical applications? We are asked to provide "five nines", but only reach 88%, on average. Come learn how to prevent the Stability Antipatterns from biting you. Apply these Stability Patterns to contain damage, recover from shocks, and survive disasters.

In part 1, we looked at common sources of system failure: those commonly created structures that exacerbate problems.

Now, we'll take on Stability Patterns that not only stop the antipatterns, but also add resilience to your system. Apply your new failure-oriented mindset to unchain yourself from the pager and save your company from embarrassing--and costly--disasters.

These patterns combat entire classes of failure modes, making your system robust against even unforeseen problems.



Books on design and architecture only tell you how to meet functional requirements. They help your software pass Quality Assurance. But painful experience has shown that "feature complete" is not even close to "production ready." After this talk, you'll be prepared to use your failure-oriented mindset to make your system a success.

By Michael Nygard
If your software fails in production, nobody will care how great the development project was, or how well the system passed QA. Production operations, the domain of your systems' least-appreciated stakeholders, is where the rubber meets the road. Come learn how to build your systems to thrive in Operations.




We will explore the most critical foundations for success in Operations: transparency, control, deployments, and configuration.

Along the way, we'll see some of the organizational dysfunction that prevents smooth, successful operations. You'll learn what you can do today to avoid these dysfunctions, even if you've inherited a legacy of distrust between Development and Operations.

If you don't want to wear a pager for the rest of your life, this session is for you.

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.



A day? Trivial you say? OK, we'll make it an hour and a half, with time for questions!

Come see if Michael can beat the clock!

By Neal Ford
There's the perfect world, and then there's the world you have to live in. Lots of organizations would like to reap the benefits of Agile development techniques but don't know how to get started. This session discusses the key benefits you can derive from Agile software development so that you can decide for yourself how many agile techniques will work within your organization.

I discuss project planning and estimation, how to benefit from pair programming when you aren't allowed to pair, how to measure your progress, and other project milestones. Agile software development isn't just an unrelated set of activities, it is a discipline. Once you understand the component parts of the discipline, you can apply them to your less-than-agile world.

By Neal Ford
TBD

TBD

By Neal Ford
This session demonstrates how stringent TDD improves the structure of your code.

I discuss TDD as a technique for vetting consumer calls, using mock objects to understand complex interactions between collaborators, and some discussions of improved code metrics yielded by TDD. This session shows that TDD is much more than testing: it fundamentally makes your code better at multiple levels.

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