Dance with Diana Larsen along the path to Agile Fluency for your team. In 2012, Diana Larsen and James Shore refiined the Agile Fluency Modeland Martin Fowler published it, "Your Path Through Agile Fluency." (http://agilefluency.com) The model describes how teams grow in their understanding and skillful ease with Agile over time. The model reflects what Diana and Jim, and many others, have seen in real teams in the real world, and it inspires organizations to learn how to invest in teams. In this keynote, Diana will share stories of real teams as they dance along the path and energize you to find your teams' best dance.

While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?

Dhaval Dalal introduced me to Prof. Kevin Werbach’s definition of Gamification – “The use of game elements and game design techniques in non-game contexts.”

For our 4th ShipIt Day, organized on 25th/26th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention, from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.

The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.

Update -

1. Deducting points seems to be bothering the individuals. Now we are experimenting with getting rid of negative points and introducing short lived badeges instead e.g. "Build Breaker".
2. We have now added more badges to recognize individual efforts in various categories.
3. Working on open sourcing the core app at https://github.com/IDeaSCo/rockstar

Scaling Agile is now proven in a multitude of Fortune 500 companies. From the case studies and presentations, it could look easy -- just follow what everyone else is doing, right?

But just as the anti-patterns of Scrum can maim the team, false starts at scale can paralyze the enterprise. Which six appear most often?  In this session, Francis discusses how to be proactive in these unSAFe situations:

• Managers not thinking Lean and teams believing in chickens and pigs
• Alignment as lip service
• Prioritization as a game
• Building a portfolio practice without strong program execution
• Using Agile to build bad code faster
• Never looking back

We know that bullets may not be silver and fixes may not be quick... but knowledge is key to enterprise safety!

How do we provide Product Owners, Scrum Masters, Team Members and others who are applying agile practices with a safe environment in which they can experience and “have a go” with Scrum?

Scrum simulation with Lego’s is a tried and tested technique that has been successfully applied to help teams build up their understanding of the ceremonies and rigors of Scrum.

In this highly interactive workshop session we will take participants through how they can customize, build and facilitate an agile lego simulation that addresses their particular learning points. We will also show you how you can use this approach to help distributed Feature teams who share a common backlog understand how they work as one to deliver their Product. Participants in this workshop will leave with the confidence to apply the power of play.

A successful agile transformation is a challenge - so how to ensure that these gains will be resilient and sustain over time? How can one be sure that the agile values and principles will be passed on to future generations? What charactaristics differentiate the agile organization that is successful today and the one that will continue to be successful well into the future? 

This lecture leverages Sean's 13 years of military experience to explore how leaders deliberately build great self-sustaining organizations.  Leaning on first-hand case studies from coaching dozens of agile teams, learn about the leadership behaviours that build self-sustaining cultures, and those which fail to see beyond just the methologies. 

In fall 2014 there is no question that business agility is required. You will also be hard pressed to find anyone arguing against the core principles of lean/agility or against most of the practices. But most enterprise organizations have not yet reached the levels of agility you read about in books or hear about at conferences. Lean/Agile is now trying to cross the chasm into the mainstream enterprises where effective change management for today’s context is the name of the game. Through stories from the trenches of enterprise change management we will discuss different approaches to change and when each is appropriate. We will see how a combination of the Kanban evolutionary approach to change combined with "free market / pull based change management" helps accelerate the journey towards agility without risking its stickiness, and share some hard-learned lessons that resulted in patterns like “Manager’s first”, “Document/Methodology later”, “Market & wait for Pull”, “Case Study”, “Opt-in vs Mandate”, “Guidebooks OVER guided tours”. 

In 2003, we had a major problem to solve - our products had far too many open field defects, and the bug arrival rate was moe than the closure rate. We tried to fix using our process which involved shipping quarterly service packs, but that was not only elongating the lead time, it was also not very amenable to changes. The process for customer specials (specific features, etc.) was not any better, and invariably it led to exec-level escalations just to get some deal-blocking customer escalations into the service packs mid-way in the quarter.

In 2004-05, we experimented with a pull system that limited the work in progress and created a more smoother flow of value. The result of this system was that we were able to significantly reduce the defect backlog, and were able to bring down cadence of features and bugs to a weekly cadence. The experiment was so successful that in about 6 quarters, we had fixed most of the field defects (brought down individual product's defect backlog to single digit) and we had to disband the team as there was no work left for them!

We were inspired by Tom Gilb's "Evo" method and experimented with it to create a weekly cadence. However, we found that the nature of field defects and customer specials was stochastic in nature and didn't lend itself very well to a timeboxed framework like scrum. However, there were no off-the-shelf methods available back then that were a viable alternative. Hence, we experimented with various methods and blended-in elements form various methods to create out our very first kanban by limiting work in progress.

In this talk, I will explain our first kanban experiment, and also compare and contrast with the later-day Lean Kanban by David Anderson.

An all-encompassing effort such as a full-scale agile transformation goes to the very roots of an organization and tends to shake things up quite dramatically. Indeed, it’s very much like undergoing heart surgery AND brain surgery – simultaneously.

Imagine the damage caused from a failed organization-wide change:

• Loss of credibility
• Loss of trust
• Loss of face and reputation
• Strong demotivation and loss of commitment and faith on the part of employees
• Clinging even tighter to the old (safe!) ways of doing things
• Diminished success of future attempts by leaving behind a wary and highly skeptical audience

After the storm passes, where things have settled often determines how and where the organization goes from that point onwards. Ensure your transformation plan succeeds and the pieces fall into place according to the set goals and plans -- and not according to someone’s whims and fancies; politics; cultural and attitude issues; or naysayers.

Core Agile practices establish visibility, remove impediments, and promote collaboration at the team level. Standup meetings, physical task boards, and focus on clearing impediments are well known practices to keep a team focused on the work, and establish a sense of flow towards frequent, tangible, and sustainable results.

What about an entire program, when a large number of teams are involved? How can a large organization exploit the same core practices when there is highly interdependent work, and when there may be hundreds of people involved? How can Scrum be used to improve delivery times, increase quality, and promote sustainable development at a program level? How the can practices provide executive leadership the visibility they need into program progress?

This workshop will introduce valuable, proven Scrum practices for large programs. Among the topics that will be discussed are:

• What program management challenges are ripe for improvement through Agile practices?

• The Program Impediment Board: Visible impediments, dependencies and milestones at a program level

• The Program Stand-up: Lightweight activities to promote visibility, clear impediments and collaboration across the program

• What does it look like when it’s working?: Improve delivery time, increase quality, and establish collaboration across the organization.

Most Agile teams learn the ceremonies and other Agile jargons sooner than we could imagine.They add few meetings to their project execution and talk in a fancy language that would make us believe in Agile utopia. Everything seems fine and happy, until one day their happy bubble bursts and they realize that they are just 'doing' Agile and not 'being' Agile. One primary culprit here is that the teams often neglect their core technical practices and don't challenge their status quo. Which means they don't change anything about the way they design, code or test but just modify their management processes and await a miracle. There are three primary reason why we observe this Agile smell in most teams. It is believed that there are no immediate results in modifying these practices, its is hard to change the existing practice because of umpteen man-made reasons and finally no one knows where to begin their journey.

Here in this talk I would like to address the third challenge and explain how a (non-technical) coach could pair with the team members on their day-to-day activities and help them initiate this journey. The focus of this presentation is on the do's and don'ts while pairing with the team members. It will also explain the benefits of this exercise.

In my previous role as the leader of the of a products group, leading one-of-its kind agile transformation initiative, we tried to fundamentally change how value is delivered to customers in legacy technologies. In this experience report, I would like to share my insights about the agile transformation journey by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. To complicate things further, implementing agile in a mainframe technology stack is extremely challenging because people working with legacy technology/code-base, have a mindset that it is not possible to introduce modern tools/technologies or a different way of developing software in this environment. Specifically I would like to touch upon the following areas to drive agility across the organization:

1. The need for Agile transformation initiative
   1. Time to market - Long release cycles; Impact on release feature relevance;  - Need for reducing release cycle as well as the need to build what is relevant
   2. Rapid changes in Data Center requirements as well change in direction for technology stack – Heterogeneous platforms, On Premise to Cloud, Web and Mobility driving different usage patterns – driving the need for more and faster innovation
   3. Lack of customer involvement in product roadmap and release plans – Need for early feedback and validation
   4. R&D - Lack of understanding of customer environment; Siloed functional groups inhibiting collaboration;  - De-risk knowledge levels within the organization; Improve cross functional team behaviors; improve engineering practices and usage of productivity tools
2. Challenges faced during the journey – Communication; Expectation Management; Changing culture and behaviors; HR – role of HR, systems, processes, performance management, job titles/description, Rewards and Recognition; Skills – Technology as well as softer skills; Engineering practices and tools;
3. Organizational changes introduced to make the transformation successful
   1. Communication and expectation Management
   2. Culture and behaviors – soft skills workshops, move from an I to a WE, emphasize on team thru team goals and team success, team based rewards and recognition; changed job description of managers to get effective participation and right behaviors as well as how they can contribute to the team success; Enabled cross functional skills (T skills / Generalists)
   3. HR – Systems/processes, introduction of new job titles and changes to job description, Team based quarterly performance goals and reviews, multi-rater feedback;   Moved from Individual performance reviews to team based quarterly performance reviews
   4. Engineering excellence – enabling skills and tools for continuous integration, build and deployment to provide faster feedback as well as shorter release cycles; improve quality;   Moved from waterfall to a daily integration and build model;  
   5. Value Delivery – Requirements voted to understand high priority needs; reduce release cycle; customer involvement during roadmap and release planning, sprint review feedback;   Release cycle reduce from 18 months to quarterly incremental releases

Due to the nature and complexity of the change, the impact and touch points involved in this transformation, it is very critical to have an active and deeper participation from the leadership team to effectively plan change management to make the transformation successful.   Since it was a multi-year transformation initiative as well as continuous improvement journey, we had taken a phased approach to implement the overall transformation plan so as to take benefit out of learning coming out from each of the phases.

Slide Deck used in the conference:  http://www.slideshare.net/RathinaKumar2/edward-de-bono-agile

Building 'happy' teams is one of the cherished goals for Agile Coaches and Scrum Masters. In my coaching experience, all the high-performance agile teams have joy and happiness as the core to their performance. 

I have taken Edward De Bono as my support and his work on creative thinking as my guide for this purpose. Edward De Bono's crative thinking patterns include several aspects like curiosity, provocation, synergy, fun, hypotheis etc. Edward De Bono's work can be applied in every field where we look for creative outcomes. 

These creative thinking patterns can be adopted by agile coaches/scrum masters to improve their effectiveness in building high-performance teams.  

This session has exercises that are derived from Edward De Bono's work on creative thinking patterns. These exercises can be used by agile coaches/scrum masters with appropriate modifications in their real world contexts.

Join me in building "happy" teams with the help of Edward De Bono.

Traditionally, in software development, user experience (UX) wasn't valued as much as developing of the software itself. But this has changed rather radically. However, creating an enriching user experience in an agile fashion is still challenging. Most of the agile engineering practices in use are around building software but seldom address UX. When building a product in an agile fashion, UX in an incremental fashion becomes important.

In this talk, we will present our experience of creating UX in an incremental fashion for a virtual wallet. We will also talk about the different challenges we faced such as, educating various stakeholders on the value of incremental UX, building collaboration between developers and experience designers and abstracting design components, along with the solutions we devised to tackle these challenges.

As agile practitioners, we’ve learned to love highly cohesive, cross-functional on-site teams. These teams, much like monolithic applications; succeed due to the proximity of useful knowledge. Distributed, asynchronous teams must rely on different strategies and tactics in order to be effective while still adhering to the principles laid out in the Agile manifesto. 

This talk is an experience report from working for the past two years on a variety of distributed, synchronous and asynchronous agile software delivery teams.

Good engineering practices and fail-fast, iterative, low-ceremony processes help achieve team level agility. They are necessary but not sufficient to scale agility across the IT organization. In this talk, I'll address what else is needed and why. In particular, I'll address:

1. Why plan-driven IT projects are a bad idea why we need value-driven projects instead
2. Why a matrix org is a bad idea for IT and why we need cross-functional teams instead
3. Why IT budgeting needs to change from being project-based to being team-capacity based

The objective of sharing this experience report is to showcase how disruptive changes in the market place have driven the execution strategy for transforming a traditional waterfall organization to Agile. 

It also contains a narration of our transformation journey so far and challenges we faced to understand the Key word "Value" across the business value chain.

However for embedded systems & solutions many believe that Agile is not going to work, "our product is so complicated and distributed" (Is this supposed to be a quote?), their nature of business is so unique etc.. and if you ask about scaling then "Forget it".

Hence my session is going to share the practical challenges we encounter and interesting stories of the transformation journey.

"To know, is good. To live, is better. To be, that is perfect." - The Mother

During the Agile adoption, its a common complain that many team in many organizations get caught up in the ceremonies or mechanics of Agile and fail to understand/appreciate the true value and spirit of Agile. And because of this, the original intent of the Agile movement itself is lost. This is a serious issue!

This workshop will highlight, a well-proven approach to transformation (not adoption) and show the distinct steps in this journey that an individual or a collective goes through when learning anything new. Activities, serving as examples, in the workshop, will focus to show the journey - that is, how to begin with rituals, then gradually move to practices, arriving at principles and eventually internalizing the values. Witnessing this gradual process of transformation will help participants discover for themselves their current progression. We hope this will serve as a guiding light during their Agile journey.

Finally, we will leave the participants to ponder upon and discover for themselves their ideals in life and work as this is not only applicable to software development, but also to any discipline where humans are involved, including life itself.

Leadership is a dance of stepping up to provide guidance and then stepping back to let the team deliver.  This is easier said than done.  As one of the co-authors of the book “Stand Back and Deliver,” Todd will demonstrate some of the tools that he has used to help with this leadership dance.  These tools include:

• Purpose Alignment Model
• Context Leadership Model
• Business Value Model
• Trust Ownership Model

Every organization has it's own set of issues in scaling agile and there is no one size fits all models/framework. By far there are lot of framework like SAFe and supporting tools available to help scale agile. This presentation is more of an experience report on my journey with Agile and Scrum adoption program with an Internet company in consumer space and the kind of challenges around it and the ways those were dealt. I would be focusing more on the AMM (Agile Matruity Model) that I worked upon internally and the various stages/phases with in them which helped the Agile/Scrum teams to understand how well the progress is with them in agile adoption across the organization and what value in each phase it brings into the team and back to organization. I would describe the need for a model to be developed and what it is all about during the presentation. 

What to look or would be unique (I guess) in this talk would be the simplicity of the model and solving a complex problem. Simplicity in a way is to believe this model would be generic and most of the organizations would be able to relate to the real world problems while scaling agile.

2 major errors across 6 agile planning events give us 12. Learning “what not to do”, can sometimes help us identify risks early in the cycle so that, as a team, we can effectively respond to these risks.

Agile planning happens at multiple levels. In scaled agile delivery model, effective outcome of one planning event can influence the other significantly either positively or negatively.

Come and learn top 12 experiential insights. These will help you alert your teams on “what not to do” during Scaled Agile Planning events. I tried capturing top 12 errors across 6 planning events namely Strategy Planning, Portfolio Planning, Product Planning, Release Planning, Iteration Planning and Daily Planning.

About two years ago, we embarked on our journey towards Agility and Kanban was our vehicle.

But Kanban had people worried.

How can we not have detailed plans?! How can we limit WIP when we have so many things to work on?!

We have due dates to meet! And so on.

We would like to share one of the approaches that we adopted to help move the change along.

In addition to focusing on the Kanban implementation at the project levels, we adopted another route – to work through the individuals and the teams – a grounds up approach. We encouraged people and teams to use Kanban boards to manage their daily tasks.

You have difficulty in managing personal stuff? We’ll help you manage better!

You have issues in managing team level priority? Look what we did within our team- we have a Team Kanban and we are now much better organized!

One by one we saw people getting interested. The movement gathered steam - we worked directly with a handful of people and they in turn got their peers onboard. And we saw various flavors like Personal Kanban, Team Kanban cropping up all over the place – even in our Travel Office and Corporate Office. What this did was give people a safe, controlled environment to experiment and learn in.

As they got used to the ideas of limiting WIP, pulling work, visualizing work and “stop starting, start finishing”, it gave them the confidence to work this way at the project level too. And it made our lives as change agents just a wee-bit easier!

We welcome you to come hear our story about nurturing the change towards Agility by making it a grass roots movement.

A brief introduction to Amdocs - Amdocs is a leading provider of Customer Experience systems and services in the telecommunications domain, typically doing large scale transformation projects.

On Reddit, IAmA stands for "I am a" and AMA stands for "ask me anything".

In an IAmA post, a person will post what they are, and other people will ask the original poster some questions to gain insights about the experience the person has had.
 
Ex: I'm Jeff Patton, creator of Story Mapping, Ask Me Anything... OR I'm Diana Larsen, co-creator of the Fluency Model and co-author of Agile Retrospectives, Ask Me Anything...

We plan to take this concept and apply it to the Agile context. We've few luminaries at the conference and we plan to do an live interview with them using this format.

How organizations are learning to value learning and not just velocity!

We all hate wasting time and money.  In the pursuit of cutting out waste, we've learned to systemically fool ourselves – to convince ourselves with very little evidence that the activities we're engaged in add value.  And, further, activities that don't result in a product we can deliver are waste.  But, the biggest leap of faith I continue to see most companies make is in believing that people want their new product, feature, or idea.  They likely don't.

This talk is about the rise of learning as a valuable activity.  I'll give examples of organizations that invest in experiments that take the cooperation of developers, testers, product mangers, infrastructure, sales, and marketing.  At the end of these experiments organizations are left with no deliverable product and only the knowledge that the product they're thinking of should or shouldn't be built at all. 

Adopting agile development practices and continuous delivery is becoming a norm in the software industry. Time to market and frequent releases have drastically reduced time available for regression testing. Inspection is considered wasteful. Faster feedback cycles during development is crucial. These have created lot of challenges for testing community, which traditionally relies on manual testing assisted by UI based test automation.

This is an experience report of transforming testing practices across organization, which decided to embrace Agile. Today our testers are not trying to find defects, instead they collaborate with product management and developers to prevent them in the first place. In fact, during the appraisal process, the defects found by them is ignored, instead we focus on how much time they are able to dedicate to collaboration and exploratory testing. The boundaries between developers and testers have faded away and today quality is whole team's responsibility.

We started with less than 20% of our testers with automation skills (mostly UI automation) and rest of them relying on manual testing. However, today, all our testers practice BDD. They have picked up Java & Groovy programming skills. They are able to contribute Workflow tests, Integration tests and Business Logic Acceptance Tests. Early collaboration and pairing is the norm. By the time developers are done with their tasks, all checks are already automated and hence we are able to deploy software every fortnight to production.

Are your testers finding it hard to make this transition to an Agile mindset? This session will give you some concrete ideas based on our transition at IDeaS.  

You’ve started on Agile project. You've probably got IT management on board. You've read the manifesto. You've got a wall covered in post-its. You’re probably not using pair programming but you’re following most other Scrum and XP practices. But now you have a problem. Operations, HR and finance can’t keep up. Ops is having problems (or just refusing to) deploy each iteration. HR won’t let you form self-organising teams and don't know how to write KPI’s to support collaborative work practices. And finance wants a 3 year budget with fully costed initiatives.

Like many cultural problems, change comes from understanding. This presentation will explain how non-IT business functions operate and why they have legitimate problems with Agile delivery.

We won’t stop there however.

By understanding your business, this presentation will provide you with the tools you need to align your corporate business functions to your agile development approach. From improved communication integrated sales, rolling budgets, agile KPI’s and aligning to revenue drivers. You will learn how to build a truly agile organization.

Organizations invest energy, effort and real dollars to stay in trend. Here's one of the trend: Agile is no longer a buzz word, Scaling Agile is. Terms like Enterprise Agile, Scaled Agile, SAFe, LESS, DAD, Agility Path are conveniently thrown around in meetings and speeches as organizations line up to get on the bandwagon of 'Scaling Agile'. Scaling Agile - from the team and product level to the organizational level has it's own benefits and challenges. Is scaling Agile right for you? Are you ready for it? If you've been thinking of scaling, you might be in luck. In this session, we will discuss grounds up approach of how to analyze and evaluate if an organization (or a business unit) is ready for scaling Agile. You'll create your own set of evaluation criteria specific to your organization's situation and learn steps your organization can take to be more prepared for scaling Agile and reap organization-wide benefits. The focus will remain on your context and not on promoting any particular scaling framework.

        "Scaling. Its about the context not the process." - Jeff Sutherland

PS: This will be a no slides, hands-on workshop. Be prepared to actively participate throughout the session.

Kanban is one of the fastest-growing development methodologies today.  Teams increasingly turn to Kanban to simplify and streamline their agile development, but few people know the inside story of how and why Kanban was created.  The Secret History of Kanban pulls back the curtain and gives you a first-hand account of how Kanban went from being a colossal failure to a startling success, presented by one of the original team leaders.  Learn how a team turned theory into practice, what it means for the future of Agile, and how you can apply those lessons in your own organization.

We are living through a winter of discontent in the Enterprise IT space serviced by IT services organizations.

Agile is no longer new; Agile projects which are running effectively are being asked to be efficient; at the same time, cost efficient projects are being asked to be more Agile (with Agile meaning different things to different stakeholders). In the minds of clients, the words Agile and Lean have become synonymous with effective and efficient IT services delivery. Long seen as two parallel ways of work, we are now being asked to do both. Does ‘Lean Agile’ – which is becoming fashionable with some clients - exist, and what does it look like?

The authors of this session come at the problem from opposite directions. Avinash’s starting point is a tightly managed traditional project burned by a (past) failed Agile implementation, that nonetheless needs to deliver the value Business is demanding; Jay runs a large successful Agile program that the customer is now demanding efficiencies from. We came together to create the Double Helix, a model to implement Lean Agile.

Before the implementation of Double Helix, our structures existed in traditional forms - a Hierarchy in case of projects that thought themselves efficient. and for agile, a Scrum structure within a deeply entrenched structure based on designations and seniority. By implementing the Double Helix, we overlaid this structure with Planning teams that cut across designations (from the program manager to entry level trainees) and Execution teams that are mainly peer-level (all managers, all leads, for example). Power shifts from a experience and role basis to the basis of contribution to the respective planning and execution teams. As we will show, this is very similar to the Lean organizations that Japanese manfacturers have adopted. 

Our measurements reflect this change. Our efficiency measures indicate the progress made in reducing waste (57% of the project work was non-value add, in the example presented, reduced to 20%) and effectiveness measures show the RFT (Right First Time) and also use feedback from the end-users (defects / fresh Function Point delivered) to measure how effectively the program is delivering value. 

We will share how tooling was used to idiot-proof (Poka Yoke) development, especially during steep ramp ups - reducing the time for a new entrant to be productive in a mission critical development project from 45 to 30 days.

When people learn about agile they usually learn about Scrum (since it is the most popular flavor of agile). While Scrum is beneficial, it does not have answers to all the challenges of software development. One of the common challenges teams face is that of having an effective Product Owner. From experience, it is not about who is fulfilling the role of the Product owner in your organization but about the definition of the role itself. We have played with many different variations of the PO role, till we ended up with the concept and structure of the Value Team. To keep it simple, the Value Team is responsible for making sure the product is (1) Feasible, (2) Valuable, (3) Useable.  After using Value Teams in many corporations (the session will have many real-life examples of this) they seems to be a practical solution to many problems about how agile can work in complex environments where there is no ONE product owner, but rather multiple organizations and people that have a say in what needs to get build and how. This session will present the idea of Value teams and answer questions on how to create them, how they operate, who is in charge, and why they are so critical to the success of the agile delivery team.

Afraid of legacy code? Don't be!!!

Most successful product companies are confronted with the problem of legacy code.

What is a legacy code?

• A code which is in production for several years.
• A super-complex, hard to understand code base, written by different set of developers. 
• Outdated Technology stack.

But the most hurting reality is:

Lack of confidence in the code due to zero or poor test coverage.

Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."

Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.

As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.

One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little. 

Today we all know this is a BAD option!!!

Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.

How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.

What do we do?

Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:

1. Re-structuring the Project code-base
2. Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
3. Creating/fixing the build script 
   1. Setting up an auto DB deploy tool and integrating it with build scripts
4. Set up basic CI pipeline
5. Write a few work-flow tests to capture the system's flow from user's point of view
   
   1. Find the inception point in the code from where we can exercise the code
   2. Restify the application at the inception point (one service at a time)
   3. Setup authorization for production and test environment
   4. Build minimal test-data set for different environment 
   5. Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
6. Write business logic acceptance test to capture various complicated business rules
7. Test drive the new enhancement or bug fixes
8. Every time we touch legacy code, refactor the code and improve test coverage at unit level

This really helped us test driven the new code and implement all the layers of the test pyramid.

If you've a similar situation, join us, as we share our experience on how to confront legacy code.

Agile Teams' self-design is very important (though not very common) exercise in a large-scale agile transformation. In teams’ self design, team members choose their own teams in a collaborative way. This concept here is that the teams will gel quickly and excel when they are self-designed.

In this session I am going to present my experience with such exercise. I facilitated at least 4 such sessions to help an organization as part of a large-scale transformation. The session is going to explain

1. Benefits of Feature teams over Component teams
2. Self-design of feature teams
3. Pilot exercise of self-design of 2 feature teams.
4. Large scale self-design of 4 product groups with 30 to 50 members per group.

This workshop will help participants to understand how the Kanban method really works.

We will learn how to use the Kanban method to visualize your current process ("start where you are"). Will figure out how to limit work in progress (WiP); define and make process policies explicit; measure and manage flow.

Also we will figure out what does it mean to search for opportunities for continuous improvement. We will learn how to increase your team speed and at the same time decrease pressure at work.

All of these we will touch through extremely hands-on step-by-step simulation using LEGO bricks.

We all know the importance of validating a feature before committing to getting it built. Validating assumptions help in avoiding the most frustrating and common problem – building something that nobody wants. However, validation is easier said than done. Building the right feature before we think of building the feature right is the key.

Being Agile, we always try to leverage the quick feedback loop and adapt based on the end-user feedback. That’s good but it should not be used to validate the assumptions and that too after implementing a feature based on that assumption. It’s very expensive 

A more powerful and productive technique is to leverage Specification-by-example in defining and discovering requirements collaboratively with end-user, even before start working on the feature.

This talk will focus on highlighting key aspects of effectively adopting SBE technique based on my own experience leveraging it successfully over and over again. It not only helps in grooming the feature requirement to tell a clear , simple and compelling story but it also helps in removing what is not needed.

Agile transformation in any organization will go through myriad of challenges that involves people, existing organization culture, technology/domain etc. Instead of seeing these challenges as obstacles, if you view them as opportunities to grow and improve, transformation will be more impactful and long-lasting. If neglected, the very same obstacles would severely damage the motivation and trust of employees.

In this experience report we would like to walk you through the agile transformation journey in a Mainframe product development enterprise by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. Specifically we would like to touch upon 

1. Self-organizing teams
• Resistance to change
• Culture shift
2. HR
• Lack of role clarity and
• Effective R&R in agile space
3. Agile Engineering Practices adopted in Mainframe product development
• Unit test automation
• Continuous Integration

Along the presentation we’ll highlight few anti-patterns and the effects of ignoring them.

Product Management for agile projects is still in the 1970’s era or is it really?

Organizations today face tough challenges in overall agile delivery, with the product management teams still catching up and coming to terms with the new agile beast, which churns out functionality every 2 weeks. The product managers do not have a clue as to what exactly they need to do next with these 2 week deliverables! OK at least some do have an idea, but most product management teams struggle to keep pace both with their internal product owner needs on one end and the external customer /market facing demands on the other.

This talk focuses on our experiences of building product management capabilities at large scale, to overcome these challenges, and provide some insight with practical tips implemented. Join this session to learn from our experience and grow your own product management tree house.

We represent the Agile Center of Excellence at our Organization and are chartered to drive the change management initiative to imbibe Agile adoption across the enterprise.

We plan to share our experience on the Organization Change Management initiative that we took up to drive Agility across the organization.  Our journey towards the derived vision and strategy to increase Agility in the system to thereby achieve:

• Nimble simplified processes.
• Ability to respond faster to change.
• And most critical: delivering increased customer value.

This is a continuous improvement journey and we initiated:

• Structured multilevel communications of CHANGE to the teams.
• Learning + Unlearning:  Structured Training and Development plans (Behavioral and Technical).
• Bringing in Gamification as a tool to get millennial team members to learn quicker.
• Approach to move from “Pyramid” to “Hour Glass” structure to align with the flat team structure.
• Pilot: Career Development Framework Aligned to Agile structure and roles.
• Bringing in change of G&O to align with Agile delivery
• Enabling Talent Fulfilment to align to the Agile roles and structure
• Pilot: Performance change management- Holistic approach to drive appropriate behavior
• Brining in systemic changes to ease Agile adoption

Technology has blurred the lines between the digital and traditional methods of dealing with a consumer of any Global Enterprises. The Business Process and IT is no more separate, in most of the industry verticals the Business is driven by IT.   Constant Innovation around IT has become the new normal to the Enterprises to meet rapidly changing consumer expectations and behavior dynamics.

More connected consumers, automated processes, and sophisticated analytics place unprecedented demands on IT functions. Many Enterprises are struggling to cope, and they seek to deliver on new demands by adding piecemeal elements to their existing operations. This is easier said than done. Reinventing the IT function at Global Enterprise requires far-reaching changes, from talent to infrastructure, tools, delivery models, partnership model.

This experience report  brings strategy of 2 speed IT, through which Infosys helped its Global top 10 clients to 'renew' its IT related to Digital & Mobility space using Agile as a key lever.

This session gives you experiences, practical on the ground challenges, stakeholder and vendor complexity and approach and journey towards Speed 2 value. Also I am pairing with Alok Uniyal who is senior leader at Infosys and a CIO coach who helped 50 plus clients to transform their IT organization in last 20 years.

This one-day workshop will help your team in improving their trust relationships and gaining a deep understanding of trustworthiness.

Learn to use the Team Trust Canvas methodology to strengthen your team performance. During the workshop, participants will learn which factors are essential for trust and how to use this new capacity to create an environment that brings the best of people.  The content is very practical. Most time of the day participants will do hands-on step-by-step exercises with the differents tools and games.  You’ll be able to use those right away when you go back to work.

The sales process is hard. As a business owner, you spend your entire time doing it. Often wishing you were back, cutting code. If you are successful you might have a raft of sales people closing deals under their own process while your product people deliver under Agile. Your worlds are split and often, it breaks.

Change that. Apply Agile and Kanban to supercharge your sales team. Get your developers and scrum master in on the action. Unify your company.

Kavita has spent the last two years changing the global process of a leading Ad Agency while based in Delhi. Now at Fifty based in London and Barcelona she has created a unified Product and Sales team from scratch. Turning her work over the last 6 months into a case study, get a fresh of the presss step by step break down of hacking the sales process from both the CEO, developer and copy writer perspective. Kavita will be transparent about mistakes and the open about the recipe for success.

One of the many great things about working in Agile teams is the lack of bureaucracy. Agility and bureaucracy do not and cannot coexist. In general, bureaucracy is a system of government in which most of the important decisions are made by state officials rather than by elected representatives.  

Management guru Gary Hamel says,

“Strategy gets set at the top. Power trickles down. Big leaders appoint little leaders. Individuals compete for promotion. Compensation correlates with rank. Tasks are assigned. Managers assess performance. Rules tightly circumscribe discretion. This is the recipe for “bureaucracy,” the 150-year old mashup of military command structures and industrial engineering that constitutes the operating system for virtually every large-scale organization on the planet. It is the unchallenged tenets of bureaucracy that disable our organizations—that make them inertial, incremental and uninspiring.”

In our context, bureaucracy is with reference to geographically distributed teams working together to run Agile projects. When there is bureaucracy in geographically distributed teams, you will find powerful forces setting the rules, defining practices and mandating criteria. And there will be several followers who are ready succumb to the pressure. When this happens one may witness specialized definitions, measurement criteria, and rituals that define the software lifecycle to be followed by distributed teams. Decision making will move up in the hierarchy. Teams will practice practices just for the sake of practicing. Many of the team members will eventually forget the purpose, essence and sprit of processes. That is a slippery slope! In geographically distributed teams – especially when multiple organizations and powerful leaders come together, it is very difficult and challenging to guard against bureaucracy.   When that happens, we cannot have true Agile enablement.

This session will present the ground realities seen in distributed Agile projects and techniques to overcome bureaucracy in geographically distributed teams.

Education is a critical component in a sustainable agile transformation. Sustainable agile is realized when people have truly change the way they think – that needs education. If we truly understand that we need to change the mindset of everyone in the organization, including its leaders, then we need a combination of education, coaching and mentoring to successfully equip people with the knowledge and skills they need to develop and execute agile habits. If we think of agile as a process, not a mindset, then we default to training instead of education.

While we acknowledge our bias towards the learning roadmap published by the International Consortium of Agile (ICAgile.com), we truly believe that it is the most comprehensive roadmap in the agile community that focuses on a common education roadmap for agile and agility and not training on a particular agile methodology. ICAgile has gathered experts from around the world and they have collaborated to define an education roadmap for every discipline needed to change how the organization as a whole works, and provides education as a foundation for sustainable organizational agility. (Focus on people not process, education not training)

Certifications are a way to give people confidence in the learning and competency of others. Agile certifications should be no different. ICAgile has developed a set of competency based certifications to ensure we keep the focus on Education. 

In order to successful scale any method or practice, it has to have some basis in theory. This presentation will use insights from complex adaptive systems theory and the cognitive sciences to lay a foundation for that theory. Seeing software development as a problem of knowledge management, the theory will elaborate a understanding of applications as the emergent property of a co-evolutionary interactions between technology capability and unarticulated user requirements.

Having established a basic theory a range of methods and tools will be elaborated. These include:

- Narrative based approaches to requirements capture (not to be confused with Story telling or story boarding) which gather thousands of fragmented self-signified anecdotes relating to real and imagined needs within a user community and allow interpretation and integration into project planning.

- Approaches to project planning and implementation that focus on the creation of self-organising teams of specialists and users to create novel approaches, supported by evidence to previously intractable problems. This is particularly relevant to the 5-10% of any major project which creates 95-90% of the grief.

- The integration of tools such as blogs, wiki's etc into the development environment. Too often corporate environments over-constrain those tools into over rigid structures which destroy their utility.

Before you write any code, make sure you have a failing test." This was a revolutionary idea, when it was first pitched in the late 90’s. Many successful entrepreneurs have been practicing a similar approach - "Before you build a product/service, make sure you have paying customers." In this talk, Naresh Jain shares his approach of finding effective MVPs to validate his Educational Product and why Agile Methods simply fail to do so. If you are interested in finding out how to maximise your validated learning for minimum investment, then this session is for you. Recently Naresh's article on this topic was published by InfoQ.

The key objectives of Organizations is to provide / derive value from the products / services they offer. To achieve this, they need to be able to deliver their offerings in the quickest time possible, and of good quality!
In such a fast moving environment, CI (Continuous Integration) and CD (Continuous Delivery) are now a necessity and not a luxury!

There are various practices that Organizations and Enterprises need to implement to enable CD. Testing (automation) is one of the important practices that needs to be setup correctly for CD to be successful.

Testing in Organizations on the CD journey is tricky and requires a lot of discipline, rigor and hard work. In Enterprises, the Testing complexity and challenges increase exponentially.

In this session, I am sharing my vision of the Test Strategy required to make successful the journey of an Enterprise on the path of implementing CD.

After revolutionizing the automobile industry, Lean principles have been successfully applied to different knowledge areas including software development. This workshop is intended to master Lean concepts like Waste, Push&Pull systems, systems thinking, Kaizen etc. & practicing cross-functional collaboration, self-organisation and safe-fail experimentation! In this interactive game, the participants will work in a small production lines, experiencing problems and applying Lean practices to overcome them.

Rovio tried 51 games before hitting upon Angry Birds. We tend to hear a lot more about the chart busting numbers of Angry Birds than the struggles of the previous 51 games. In my opinion, their success was the journey of the 52 experiments, and not just the final one.

We at Levitum recently had learnings from an MVP that we put out, and experiments that we ran. In the spirit of openly sharing how I’ve tried to apply Lean Startup principles to a new venture, I’m going to outline how we went about things, and what I’ve learnt.

More details on the experiments are available in my blog post http://arg0s.in/what-we-learnt-from-a-failed-mvp.html. My blog post made page one of HackerNews, has had over 20,000 visitors, and has been cited by various practitioners as an example of how to apply lean startup in practice.

In agile teams, three critical aspects of how individuals and interactions shape up are:

1. Individual role / title

2. Group / peer pressure

3. Self Organization

In this session, we shall simply play games to highlight the dysfunctions caused by traditional team structures, and facilitate the attendees into 'discovering' how agile practices help mitigate them

Considering today’s dynamic business environment, where solutions are expected as quickly as possible, adopting only few Agile practices may not help the business in a significant way. This situation becomes further complicated where user experience matters most. From software service Organization perspective, it is further complicated where one has to consider few more parameters like Customer Collaboration (& time), Contracting approach, Domain level standards, Development maturity Standards, etc. Also as usual, productivity loss in transitioning work product from one resource to another. 

A small step in resolving these pain areas and strike a balance between various needs & constraints, at Altimetrik, we have devised a SDLC framework – based on the concept Unified Resource and various best practices from Agile, Waterfall, Prototype driven development, Assembly approach etc.

We have been using this approach for our various customer projects and have seen significant benefits.

In this experience report, we will discuss about the various pain areas of existing development models and how they are overcomed through this customised SDLC framework for some of our clients. 

In the context of continuous and periodic delivery of same day, monthly and agile incremental delivery in both established and startup contexts there is a possibility of teams missing key elements of protecting their IP. Some simple elements such as making your work public prior to protecting it can cause loss of business. Additionally in short sprints filing IP may not be the most important focus within teams (especially in startups or smaller companies where budgets might also be a constraint). In this session it will demonstrate (a) Some key elements of how to keep IP in mind in Agile sprints (b) Some general best practices of how IP can be used as a bond/glue for teaming (c) Some process changes possible to ensure IP becomes a key element of agile delivery. These is based on experience of over 6 years submitting IP self and also having 6 people having approved IP, 20+ people encouraged to submit and 75+ submissions. (d) As a influencer will provide some best practices to Leaders and Product owners to encourage IP. (e) Additionally IP can be a great occassion for team building and bonding and a retention tool.  Note: The session will be generic and will not cover any specific IP process of any company but a general set of practices via experiences

In order to achieve my goals, as a buyer of your product, I want awesome feature.

AT: make sure your users stories don't get in the way.

Users Stories, the tool teams use to break big ideas into small demonstrable deliverable, are easy to describe and challenging to write effectively. In this hands-on workshop you'll learn how to write great user stories that adhere to the INVEST principle. We'll learn various techniques to slice your stories using the vertical-slicing approach. We will discuss what elements should be included in the stories, what criteria you should keep in mind while slicing stories; why the size of your user story is important and how to make them smaller and efficient.

So you’ve heard about this Kanban thing and want to know where to start, or maybe you’ve been using it for a while and you want to know where to go. In this hands-on workshop, we'll start at the very beginning and teach you how to build a Value Stream Map and use that to define your inital Kanban and WIP limits.

If these terms don’t make sense to you, then you need to come along for a fun interactive workshop.

In agile teams, it’s inevitable that team members are expected to be more cross-functional and produce high quality products for their customers. How can agile team members become more cross-functional and take ownership of quality? Often times there seems to be a scarcity of testing talents in agile teams. How can agile teams create high quality products when working with very few or no testing talents?

For agile team members to take ownership of quality, Pradeepa Narayanaswamy exposes the power of “Pair Testing”, a technique that promotes rapid feedback to produce high quality products. For the scarce testing talents, an effective way to become more cross-functional, one approach is for team members to pair up on various (unit, integration, exploratory and several others) testing efforts that emphasize the shared eye on quality and learning. Pradeepa talks about several options for pairing opportunities between various specialties on an agile team. She also talks about some new opportunities to pair with DevOps, Operations, Sales, Marketing and Support members to name a few.

As a new or an experienced agile team member, learn how to spearhead this technique in your team at various levels to generate buzz on other teams. As a tester, learn how to get the non-testing talents excited and experience the value of pair testing. 

This session includes a fun Pairing activity and a Group discussion. 

Estimating software projects has proven to be particularly challenging.  Over-running schedules happens frequently in our industry.  As a result software estimation is often viewed as a black art.  In this session Todd will look into some of the reasons for these challenges by exploring a number of myths of software estimation and then setting out to validate or bust these myths.

Some of the myths that will be explored include:

• Historical Estimation Accuracy
• Relative Estimation
• The Cone of Uncertainty
• Velocity
• Scope Creep
• Estimation Tools
• Wisdom of Crowds

DevOps is a higher form of agility. It is a blueprint for a great culture and and process between the different groups involved in the delivery pipeline. The big question is how to achieve it. If you are founding a startup today, it can be quite easy to take that blueprint and use it to create your process, hire the right versatile flexible people, and start delivering without any technical/automation debt or friction. But most of us are not founding new startups. Most of us already have a running operation with people, culture, process that matured over the years and despite its flaws is currently the way we do things. Changing that is non-trivial. For things to change people need to understand WHY change, what we are changing, and we need an effective process for managing the change itself (HOW to change). So what ARE we changing to? DevOps is highly focused on looking at the whole value stream from idea to value and ensuring effective flow through this pipeline. Kanban is ONE way of HOW to change. It starts by visualizing all the work flowing in the pipeline, then managing the flow focusing on finishing things end to end rather than starting in order to stay busy. It continues to what we call the “Work in process Diet” – Straining the flow more and more in order to identify obstacles to tighter and tighter DevOps culture/operation and faster feedback cycles. You can expect to come out of this session with ideas how to take your current operation and DevOpsify it in a safe evolutionary way using the Kanban method.

Over the past ten years, software development teams using Agile approaches to work have adopted retrospective meetings as a critical practice for learning and continuous improvement. To the extent that practitioners say, “If you’re not holding iteration retrospectives, you’re not doing Agile.”

 Agile retrospectives at the end of each iteration or work increment set aside time for the team to examine feedback from current conditions and develop targeted tactics to keep the project on track. Many practitioners experience retrospectives as great means for detecting good, poor, and missing practices; as a handle to make tacit knowledge about effective practices explicit; and to define improvement actions in order to deal with ineffective or inefficient technical, process, and teamwork practices.

However, too many teams and practitioners don’t reap the benefits that effective retrospective meetings can provide. Too many retrospective meetings receive cursory or inadequate facilitation. Too many retrospective meetings are held to  “check the box” on the project management template, rather than to focus on real improvements. For too many teams, the action plans coming out of retrospectives are never implemented or revisited. Too many teams seek to shift blame and responsibility for action through the retrospective.

In too many organizations, retrospective meetings don’t deliver the promised return on time invested (ROTI).

In this session, you’ll learn how to get the most from your retrospective practices. Diana Larsen, co-author of Agile Retrospectives: Making Good Teams Great, will introduce you to a simple framework for getting better outcomes from retrospective meetings, suggest ways to maintain the relevance of improvement to the work of your team, and provide tips and pointers to get great returns from the time your teams devote to every meeting. 

What is coaching?

“It is helping to identify the skills and capabilities that are within the person, and enabling them to use them to the best of their ability” — wikipedia

"Individuals and Interactions over Process and Tools"

The above is first of the 4 values espoused in the manifesto but yet it is common to see many agile coaches engage with teams and organisations advocating more and more processes. This is a common sight with new teams and also with teams on the path of agile transition from few months to few years irrespective of the competency, skills and maturity of the teams. Agile Fluency model created by Diana Larse and James Shore highlights the focus on value over compliance and practices at any given level

“ Team fluency depends on more than just the capability of the individuals on the team. It also depends on management structures, relationships, organizational culture, and more. Don’t make the mistake of blaming individuals for low team fluency, or assuming that one highly-skilled individual will guarantee high team fluency ”

An agile coach responsible for building high performing teams will need right set of powerful tools and techniques to leverage while working with teams and also to set the right expectations to both management and teams. This talk will draw from experience using few such powerful tools mentioned below while coaching teams attain fluency.

1. Deliberate Practice
2. Driving Empowerment & Self Organisation: Working Agreements
3. Scaling Agile Transformation: Creating a Learning Org 
4. Driving Commitment: Key Measures Highlighting Self Organisation

This is not a beginner level talk and assumes participants having experience in leading agile teams and transformation initiatives in your respective organisations.

The role of "Architect" is sometimes frowned upon in the Agile community as a central command-and-control authority who bottlenecks decisions and limits team empowerment. Or at least, that is what we thought. Follow the real-life journey of our teams as we discovered how the role of an architect is compatible with Agile principles. We will explore our failures, and eventual discovery on how the role brings can bring an immense amount of value to the organization and the teams, especially on large, multi-team projects. 

Agile delivery at the speed of business requires a seamless integration of Application Development, Delivery, and Operations.

We would like to present a fresh perspective of DevOps initiative and how it integrates with agile based development of mobile and web based applications.

In today's world of Application Economy, enterprises are rapidly developing mobile and web applications to stay competitive.

In this process, they are required to interact with the backend "system of record".

Large enterprises utilize mainframe at the heart of the dynamic data center as backend system of record.

This integration of agile-based mobile app development dependent on mission-critical mainframe-based operations is driving the importance of DevOps initiatives within the application development organizations.

What could be more important for leaders than increasing their teams’ productivity? Conventional thinking would rank “increased motivation” as one of the most important tools for increasing productivity of teams.

   Motivation --> increases Progress --> increases Productivity

This interactive session will disrupt and challenge the above notion, and will provide an alternative view:

   Progress --> increases Motivation --> increases Productivity

Dipesh will be drawing upon more than a decade of research including 26 project teams, 7 companies and a deep analysis of nearly 12,000 daily diaries kept by team members, and use real case studies and examples to illustrate the following key elements:

   Catalysts – events and actions that help a team move forward

   Inhibitors – events and actions that can induce setbacks

   Nourishers – interpersonal interactions that lift team’s spirits

   Toxins – interpersonal interactions that undermine team’s spirits

Awareness of the above principle is important and may sound simple; however turning the awareness of these elements into the inner workings of our daily routine takes discipline. With that in mind, all attendees will be given 'The Progress Enablement Checklist' that will assist them in making such behaviours habitual.

If you are a leader or an aspiring leader of an Agile team, this session will provide clear implications for where to focus your efforts so that you do not worry about the wrong things. You will be inspired by knowing what serves to catalyse and nourish progress – and what does the opposite.

Abstract

In 2011 the Ladok section at ITS had serious quality issues, resulting in dissatisfied customers. At the beginning of 2012 the section started an agile transformation, in steps, throughout the whole section. One year later the whole section had transformed and currently the section now eats, sleeps and breathes Agile. The quality has improved remarkably and our customers are understandably much more satisfied. Besides satisfied customers, our employees are happier.

The ideas to try agile came from the people working in the project and we think that was an important factor for the success.

We are going to talk about our experiences of this transformation and how the transformation contributed to the remarkable increase of the quality. The talk will cover the background, our roadmap, the result of the transformation and the factors of success.

We have identified two key factors of our success that we will promote a little extra during our talk.

Presentation technique

We are going to perform this presentation in an agile way, in the way we interpret scrum. This means that we are going to interact with the audience and we expect them to influence our presentation.

The point is to not just talk of how we did, but also show it on stage. We also think that this is a good way for the audience to really get the most out of the presentation.

We want you to prioritize the presentation parts

We consider the different parts of the presentation as the presentation backlog. We want the audience to prioritize the parts of our presentation, in advance. Prioritize here.

         Retrospectives are the primary learning, reflection and readjustment techniques on agile projects. A good Agile team is always striving to become better than before. And an effective retrospective enables the team to sieze its opportunity to improve! 

Retrospectives enable whole-team learning, act as catalysts for change, and generate action.

R-> Realize where you are and where you want to be

E-> Engage the teams in fruitful discussions

T-> Team work to build “We over I” attitude

R-> Relish the power of Inspect and Adapt cycles

O->Openness and Transparency to make retrospectives efficient and effective

In my view, this is not any new concept or a jargon the team needs to really master, but yes in reality sometimes it becomes challenging to keep the momentum lively all times! Over a period of time, we see these symptoms in a retrospective. 

R-> Repeated issues pop-up

E-> Engrossing & Engaging discussions are missing

T-> Team present virtually, loses trust.

R-> Routine stuff, nothing interests the teams.

O->Observably gets boring over time.

To catalyse conversations among team members, retrospectives need to be viewed from a different perspective. This presentaion talks about why the retrospectives efficacy fades off over a period of time and then talks about some very interesting techniques that I used with the teams to make these meetings lively!  Teams need to do out-of-box thinking and appreciate that these short gatherings need not  be done only by using the techniques or methods prescribed in the book but could be done by quoting some situational specific examples that would make the teams really think and speak!

As lead developer of Cucumber and author of The Cucumber Book, Aslak gets asked to consult with organisations who want to introduce Behaviour-Driven Development (BDD). Time after time, he meets teams who are trapped doing half-arsed agile. They do the easy, obvious, visible agile practices, and none of the powerful, hard-to-master, hard-to-see ones.

When these teams ask for help learning BDD, we get a chance to remind them how important conversations and collaboration are in software development. We teach them to write tests before they write code, as a way to explore and discover the hidden details of a requirement just before they dive in and start building it. This talk will make you wince with recognition, laugh with despair, and finally inspire you with stories of teams that have finally, after years of flaccid scrumming, discovered the true collaborative heart of agile software development. You’ll see patterns you recognise from your own teams, and gain insights about how to fix them.

User Experience design is a product design discipline which sits throughout a product's lifecycle, from inception to development to maintenance and all the way to retirement. Waterfall enabled the discipline to have ample time and produce extensive design, in a "big design upfront" approach which rarely involved technical capabilities, and resulted in difficulties in build. The adoption of agile by product development team has offered UX a unique opportunity to work in a much more joined-up manner, and expend the design into the development, enabling the entire team to react to change.

As a UX designer, I have over the last 7 years developped a solid appreciation of working embedded in an agile development team, and would like to share my experiences through 3 specific projects, sharing my learnings to help development team on-board the UX practitioner, their tools, practices and skills.

This session will be a case study over 3 projects, highlighting the learnings and steps of the integration of UX into the development cycle. I'm taking Alistair Cockburn's sequence of SHU-HA-RI to detail the progress of my practice and will pay great attention to sharing sufficient context that my experiences and outcomes can be translated to your own projects and team setups.

We’ve all been there. We’ve had this lovely, monolithic application purring happily away on some platform-as-a-service. However, the application and team are growing and we need to separate out functionality into independent services to keep moving forward without stepping on one anothers’ toes.

This talk deconstructs the “perceived simplicity” of platform-as-a-services and answers some critical questions:

• What are the essential components of a Platform as a Service?
• When is building our own PaaS worthwhile?
• How and where should we leverage docker in the provision/build/release/deploy/un-provision application life-cycle?

This talk stems from a 6 month engagement building a platform as a service for a micro-service based architecture.

Often we hear that estimating a project is a must. "We can't make decisions without them" we hear often. In this session I'll present examples of how we can predict a release date of a project without any estimates, only relying on easily available data.
I'll show how we can follow progress on a project at all times without having to rely on guesswork, and we will review how large, very large and small projects have already benefited from this in the past. At the end of the session you will be ready to start your own #NoEstimates journey.

Way back in 2008, when I started working in Agile, there was enough material available on Scrum and. However when it came to distributed aspect of it, people were still struggling with it. Based on working for years in this fashion, I realised that communication, trust, transparency and innovation are the core fundamental values towards successful distributed Agile implementation.

In other words, as most of the problems were caused by softer aspects of skills (misunderstanding, miscommunication, non-availability of people, mistrust etc), humanizing the distributed team experience looked like the key for successful distributed Agile implementation.

Based on working with distributed teams over the years, we discovered some distributed Agile patterns. Some of them got blogged from time to time. Those already available in form of blogs are as follows:

• Distributed Pair Programming
• Local Retrospective
• Agile way of documentation
• One Team Multiple Projects
• The nut/bolt pattern for distributed Scrum development
• Chain-Link Pattern
• Virtual One Room

The session is to share the these patterns and more (when to go for distributed Agile and when not etc)

Chef is a popular Infrastructure Automation framework based in Ruby. It comes with a host of testing tools bundled with it like ChefSpec for unit testing, ServerSpec for system testing and TestKitchen for integration testing. This session is a demo of how to use these frameworks to test drive cookbook development.

We would like to share our experience and journey on how we brought down our Jenkins build pipeline time down from over 90 minutes to under 12 minutes. In the process, we would share specific techniques which helped and also some, which logically made sense, but actually did not help. If your team is trying to optimize their build times, then this session might give you some ideas on how to approach the problem.

Development Impact - For one of our build job, below graph shows how the number of builds in a day have increased over a period of time as the build time has reduced. Frequency of code check-in has increased; Wait time has reduced; failed test case faster to isolate and fix.

Business Impact - More builds leading to quicker feedback and faster story acceptance and less story spill over.

Since the late nineties, the Agile books in the non-fiction aisle have steadily increased in number. It's common to see a book or three about Agile on a colleague's desk. It's also common to see such a book look practically new, the book spin showing no sign of having been opened. Non-fiction books are great at providing bullet points of things to do and reasons why. But non-fiction books are poor at:

• inspiring,
• creating emotional attachement (so the reader finishes the book), 
• creating a full sensory environment for the reader,
• describing a holostic environment, or
• 'intriguing' a reader who is un-interested in the topic. 

(This bullet list above is a good example of how non-fiction can excite thoughts who already know the story behind the bullets, but doesn't inspire much if the reader hasn't any context or background.)

Fiction is well positioned to do the above because its number one job is to give pleasure and entertainment.  It can't be successful if it can't do this. The oral tradition of fiction has been part of human culture for millions of years, since a Cro-Magnon passed on a story to another, and upon re-telling some details were forgotten and the storyteller had to make them up.  Fiction is in fact is the most successful format for culture change as this is the format of the world's religious works and is responsible for guiding or changing the behaviors of billions of people.  The CIA and the Pentagon use fiction to develop scenarios which are used to create simulations to test preparedness.

What force could be stronger than fiction for giving an individual the courage to initiate an organizational change in the face of uncertain co-workers and often antagonistic corporate environment?  What tester, developer, PM, director could not use the courage of knowing a "David verses the Goliath," "Legend of the IpMan," or "V for Vendetta" to not only understand the bullet points, but to have the stedfast to sustain in the face of resistance because they believe in the change as if they've lived that life, due to reading stories which placed them in one or many virtual versions of that world.

Do you fancy playing the first Scrum Master of a startup?

Do you want to live the challenges faced by the first Scrum Master of a startup?  Do you feel that your organization is dramatically different from the 'ideal' organizations, which the Agile workshops project as a basic requirement for doing Agile development?  Do you wish to deliver predictable results while your management is on-the-way to make your organization 'Agile-ready'?  This tutorial is just what you want.

In this tutorial, you will experience the life of a first Scrum Master of a twenty member startup, which has expansion plans.  Each of the audience will put themselves in the Scrum Master's shoes and try to solve the challenges posed by the ever-changing environment, while the company's management is putting its best efforts to make the organization 'Agile-ready'.  In this interactive tutorial, a gripping story-line will drag you into the world of uncertainties where you would be challenged to take life-changing decisions regarding your product team's daily work.

Even if you are not in a startup, this tutorial would benefit you because everyone still comes across ad-hoc situations which go against the ideal expectations of Agile world.

Welcome to the crazy world of Dev-Ops, where the tales span the spectrum from gruesome, grizzly to the heavenly and flowery bliss!

The silo’d structures, the agonizing buy v/s build debates, the departmental handoffs, tooling and of course the cultural barriers, which all add fuel to the story unfolding in our brave new dev-ops world. But sometimes there are silver linings and the heavens part way for the shining stars to reveal their true glory.

Join our session to listen to the tales of our (not so) successful dev-ops, and learn the lessons from our experiences.

Based on my experience of coaching/ training agile teams for 5 years, one of the important reasons for agile teams are impacted, is the personal leadership style of Agile Leaders(Scrum Master, Senior Managers etc) . I have summarized following, factors or impediments for creating effective agile teams

• The agile teams effectiveness depends on personal leadership style of agile leaders(Scrum Masters, Senior Management etc)
• Often Agile leaders focus more on “delivering solutions” than “developing people”.
• Agile leader need not specify work requirements, all that team needs is - empowerment, autonomy to work.
• The agile team needs more support through mentoring, coaching from agile leaders to exhibit the culture “Being Agile” than “Doing Agile”.
• Agile leaders need not be an Expert to coach agile teams.
• Agile teams needs to be taught on Identifying Problem, Problem solving skills and corrective actions and demonstrate steady, small and continuous improvement.

My inspiration to write here, is derived from the book “ Managing Excellence” by David Bradford and Allan Cohen, and reading blogs, articles along with my own experience.

The entire presentation will be done in “Pecha Kucha Style” with less words and more background pictures, in each slide. The most of the message is conveyed through pictures. The presenter will talk maximum 30 secs on each slide. The slides keep changing automatically after 30 secs, so that presenter continues the discussion in the next slide automatically

How can teams that have to deal with large, complex legacy systems get through planning and get to work? The title character of the classic American horror film, "The Exorcist" was a master at this..

Pecha Kucha Talk Summary:

• Introduction: Creating understanding through conversation can be very difficult for teams dealing with complex, legacy systems.
  
  
• Introducing Regan McNeil: Poor Regan McNeil was starting go insane, but a team of doctors and specialists in close, face-to-face collaboration, couldn't solve her problem.
  
  
• The Exorcist: The Exorcist knew how to have just enough conversation to get to work, so his team could deliver the value everyone had been working and praying for.
  
  
• Summary: "In life, understanding is the booby prize". Sometimes the quest for understanding can be an impediment to delivering value. Having faith in self-organization, sometimes its best just to get to work.

Testing is overated. Let's correct that statement - "Manual Testing is overrated". In this this talk, I plan to take you on whirlwind tour of why an Agile outfit does not need manual testing at all and how to get fantastic Quality Assurance without manual testing.

In this talk - I outline a agile process with a difference - everyone is a developer and a tester. However, there is no dedicated QA people. In fact, this process does not require anyone other than the developers and one process/product owner.

Development using a central reposito