All too often, companies set out with the mission to “go agile” before truly understanding what that means. Business managers are quick to jump on the agile bandwagon, believing that “going agile” will magically make projects happen faster. Teams are getting certified in Scrum as if it’s a silver bullet that will suddenly make everyone more productive. Inevitably, cracks begin to show, and expectations are missed--leaving everyone involved questioning the value of “going agile” altogether.

There is a better way! The truth is that going agile will result in more productive teams and faster delivery of projects--but only if everyone can agree on the rules of the game.

Come hear Heather Fleming and Justin Riservato from Gilt discuss why gaining consensus on the principles of Agile is more important than implementing a process, and learn how having these three conversations can save you from an agile disaster:

• “But when will you be done?”  Why getting rid of the concept of deadlines is the most important (and most difficult) conversation when going agile.
• “This is my top priority, but I can’t meet with you until next week.”  What to do when your business partner can’t (or won’t) be a full member of the team.
• “I just want to code. Why do I have to be in all these meetings?”  Why implementing Scrum is not the first step to going agile.

Scrum is by far the dominant Agile methodology and has been put to good use to positively change many software development groups. Some have found that even when they follow all the Scrum practices, they are still having some challenges, and they have turned to Kanban for help. Kanban is often framed as an alternative to Scrum, but it need not be so. Organizations using Scrum can augment their process with the Kanban Method to become more agile and delivery-oriented.

Jonathan Hansen will use real-world examples, both from product and consulting companies, to show you some of the ways Kanban can work together with Scrum to help you manage the work inside Sprints, manage work that doesn’t fit in Sprints well, and provide a means to continuously improve your work.

The transition of Waterfall to Agile methodologies is never easy. The Waterfall approach consisted of these documents as a way to analyze the User needs: BRD (Business Requirement Documents), FRSs (Functional Requirement Specifications), SRS (Software Requirement Specifications), PRDs (Product Requirement Documents), etc. After the initial agreements, the development starts. In Scrum, the most important artifact to map User needs is the User Story. However, sometimes, the User Story is too big or too small or too abstract or never ending. This often lands the teams in difficult situations. So, it is vey crucial to Identify the Ideal Bite Size -- to identify the ideal size of our User Stories, yet keeping these Effective!