Anzen. It helped a 100-year-old, 60,000-person aluminum manufacturer regain its greatness. It powers the culture, operations and massive growth of an online artisan marketplace. It's the common denominator of every great Lean and Agile principle and practice. Anzen is the Japanese word for safety.

Every day, your time, money, information, reputation, relationships and health are vulnerable. Anzeneers protect people from injuries, hazards or near-misses by establishing anzen in relationships, workspaces, codebases, contracts, processes, products and services.

When anzen is present in a software product, everything just works: people regularly use and recommend the product; engineers modify it without fear; it contains few defects; it can be deployed with ease; it is immune from threats; and it helps protect the organization's finances, reputation and investors. Anzen is a gateway to habitual excellence.

Anzeneers approach failure as an opportunity to introduce more anzen into their culture, practices, and tools.

In this talk you will learn what anzen is, how it promotes safe risk taking, how to identify faux safety, when it can be taken too far, challenges of growing an anzen culture and what it means to be an Anzeneer.

Improving Education and Learning in India and beyond

We are fortunate, software and technology provides us with choices, a relatively good income, and enables us to learn and discover virtually any topic or subject.

Agile software development practices enable us to do a better job, sooner than many other approaches to creating software. We can try things without waiting for 'everything' to be defined, adapt based on experiences and feedback, and get people involved who the software touches.

Two years ago, I visited some schools in Western Kenya to see some classrooms I'd sponsored. That visit and subsequent visits to Southern India, spurred me to apply lean & agile software development practices, to improving teaching, learning and education through appropriate technologies. Each pilot project needed to be adapted to the context of the schools, environment and region in order to function.

We have an opportunity, and perhaps an obligation, to apply our skills and expertise to helping others. In doing so, paradoxically we gain more than we realise. Sustainability and ultimately success will come from peers in India who choose to get involved, waiting for 'others' doesn't cut-it.

Smart people are logical and objective. They (we) look at the evidence to help make the best possible decisions. We are not influenced by hype or emotion and as a result our behavior reflects the best the world has to offer. Cognitive science now tells us that these beliefs about ourselves and others (especially scientists) are wrong. All of us tend to make decisions based on intuition or emotion and then justify those decisions later with logic, a process called rationalization. The most influential element in our environment is not scientific evidence but stories. We love stories. Research shows that we are more likely to buy a product or embrace a process because of a friend, colleague, or relative and ignore evidence that might go against that decision. Are these bad things? Is there anything we can do about it? We have a long history of being influenced by stories and it has helped us survive. Linda suggests that the real answer is we need both approaches -- stories and emotion + evidence and logic. Both approaches have flaws and benefits. Linda will share examples and tell her own stories to try to convince you and try to help us do a better job of making decisions.

Find out what testing works for your mobile app.

Agile Software Development means we want to maximise progress while minimising waste. Delays cause waste, for instance wasted time and efforts; ineffective work causes waste; poor quality causes waste; and bugs cause waste and delay progress, etc.

Mobile apps and the mobile app ecosystem help determine what sorts of testing will be more valuable for the project. This workshop introduces various key concepts and factors related to testing mobile apps effectively. You will have the opportunity to practice testing mobile apps during the workshop to help reinforce your learning and discovery.

We will cover both interactive and automated testing of mobile apps, and find ways to reduce the Time To Useful Feedback (TTUF) so the project team can make more progress while reducing project waste. We will also cover various ways to gather more and better information about the qualities of our mobile codebase and of the quality of the apps-in-use.

Bring your mobile apps and mobile devices and be prepared to get involved in testing!

A number of agile brands downplay the need for business analysis and requirements management on agile projects, putting large store in the role of the Product Owner.

This workshop tackles some of the problems this misconception can result in and shows how effective product ownership almost always requires a team with a variety of skills and backgrounds to be effective.

Product Ownership requires clarity of vision, alignment with organisational strategy, understanding of the development process and the ability to communicate with a wide variety of stakeholders across all levels both inside and outside the organization. The complexity of the role is most often more than a single person can (or should) cope with – effective product ownership requires a teamwork approach covering a variety of skills and knowledge.

Product ownership encompasses areas covering:

• Product Management
• Marketing
• Business Advocacy
• Customer Advocacy
• End User Advocacy
• Domain Subject Matter Knowledge
• Analysis
• User Experience and Graphic Design
• Innovation
• Communications
• Decision Making
• Legal and Compliance

Project Retrospectives are an important part of any software development process. The Principles Behind the Agile Manifesto state that, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." How can this be done? By taking the time to reflect and learn and proactively determine what should be done differently in the next iteration, release, or project. Linda's presentation will introduce techniques for project retrospectives, whether they are agile or not. The techniques help teams discover what they’re doing well so that successful practices can continue and identify what should be done differently to improve performance. Retrospectives are not finger pointing or blaming sessions, but rather a highly effective process in which teams reflect on the past to become more productive in the future. Linda will share her experiences with leading retrospectives of several kinds for dozens of projects—successful and unsuccessful, small and large, in academia and industry. Her lessons learned can be applied to any project to enable teams and organizations to become learning organizations.

I would like to share my 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, I 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.

Being Agile developer, have tried & tested various flavors of pair programming over the years while working in highly motivated self-managed team. Some experiments worked while some worked better :)

This talk is about sharing the personal experience of practicing promiscuous pairing which allowed the team to be always in the beginner's mind state and being able to push the boundaries consistently.

Test automation is extremely crucial in adoption of an agile delivery. However, it can take one for a ride, if the approach is not correct. In this sensational, heart throbbing, experience report, we'll share our story of how we turned around an inefficient, expensive automation style to lean, efficient style. In addition to sharing a real-world example, we'll also share some of the key challenges we faced and how we solved them. If you are convinced about the Testing Pyramid, but are struggling to invert it, then this session is for you.

Business Impact:

  Earlier Defect Detection - Higher test coverage at Unit/Intermediate layers lead to earlier defect detection. Reduced number of issues found on higher test environments/Production. Reduced cost of defect fixing.

  Reduced maintenance cost - UI tests are fragile and costlier to maintain Vs backend tests. No of changes in services layer are comparatively less.

  Reduced test execution time - Backend tests are much faster. Almost 7-10  times faster than UI Tests - improved build certification time.

  Test feedbacks are naturally distributed across layers of application. Test feedbacks are more pin pointed/ granular.

"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.

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

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 order for these organizations to to understand the quality / health of their products at a quick glance, typically a team of people scramble to collate and collect the information manually needed to get a sense of quality about the products they support. All this is done manually.

So in the fast moving environment, where CI (Continuous Integration) and CD (Continuous Delivery) are now a necessity and not a luxury, how can teams take decisions if the product is ready to be deployed to the next environment or not?

Test Automation across all layers of the Test Pyramid is one of the first building blocks to ensure the team gets quick feedback into the health of the product-under-test.

The next set of questions are:
    •    How can you collate this information in a meaningful fashion to determine - yes, my code is ready to be promoted from one environment to the next?
    •    How can you know if the product is ready to go 'live'?
    •    What is the health of you product portfolio at any point in time?
    •    Can you identify patterns and do quick analysis of the test results to help in root-cause-analysis for issues that have happened over a period of time in making better decisions to better the quality of your product(s)?

The current set of tools are limited and fail to give the holistic picture of quality and health, across the life-cycle of the products.
The solution - TTA - Test Trend Analyzer

TTA is an open source product that becomes the source of information to give you real-time and visual insights into the health of the product portfolio using the Test Automation results, in form of Trends, Comparative Analysis, Failure Analysis and Functional Performance Benchmarking. This allows teams to take decisions on the product deployment to the next level using actual data points, instead of 'gut-feel' based decisions.

There are 2 sets of audience who will benefit from TTA:
1. Management - who want to know in real time what is the latest state of test execution trends across their product portfolios / projects. Also, they can use the data represented in the trend analysis views to make more informed decisions on which products / projects they need to focus more or less. Views like Test Pyramid View, Comparative Analysis help looking at results over a period of time, and using that as a data point to identify trends.

2. Team Members (developers / testers) - who want to do quick test failure analysis to get to the root cause analysis as quickly as possible. Some of the views - like Compare Runs, Failure Analysis, Test Execution Trend help the team on a day-to-day basis.

NOTE: TTA does not claim to give answers to the potential problems. It gives a visual representation of test execution results in different formats which allow team members / management to have more focussed conversations based on data points.

A common failure mode for organizations attempting to adopt an Agile style of software development occurs when an attempt is made to “Scale Agile”. Suddenly, the organization finds that there are scheduling problems between teams. Delivery team members suddenly find that they are required to serve on several teams at once. Dependencies surface, and teams find it difficult to come together in a common cadence to produce working software in a continuously delivered fashion. Many times, these issues become so grave that the organization reverts back to the Waterfall model that they came to hate, but at least understood.

This session explores Agile scaling concerns, and places particular emphasis on an architecturally significant distinction in the software to be created, and the components produced to allow the software to be created. That distinction revolves around cross cutting platform concerns versus product feature creation concerns. We will examine the distinctions and explore solutions that should help your organization get past these issues when it comes to portfolio management, by paying attention to extrinsic versus intrinsic value metrics.

With the increasing number of Indo-Chinese collaborations in the technology space, it is important for us to identify new paradigms to coach cross-cultural teams. From a simple 'NiHao' to a more complex 'Chop-Sticks', everything comes our way when we coach these teams. It is important for us coaches, to be sensitive to the cultural needs of these teams and re-visit our coaching strategies accordingly. It's true that every team has a flavour and our strategies as coaches are almost always situational. However in this particular talk, I would like to highlight few salient cultural differences which we could harness positively for the team's benefit. I would also like to discuss few tools and practices, which the coaches could adopt while they coach their Chinese counter-parts.

Capers Jones conducted a study in 2012 across five large corporations and found that the number of software defects that can be traced back to errors in software design was as high as64%! Hence, ensuring a high quality of software design is critical for developing high-quality software. However, as Fred Brooks observes in his book “The Mythical Man Month”, software design is an inherently complex activity; the intangible nature of software makes it difficult for humans to envision, develop, and reason about its design. 

This talk proposes a unique approach towards developing high-quality software design. Borrowing a phrase from the healthcare domain “a good doctor is one who knows the medicines but a great doctor is one who knows the disease”, the proposed approach is grounded on the philosophy that “a good designer is one who knows about the design principles but a great designer is one who understands the problems (or smells) with the design, their cause, and how they can be addressed by applying proven and sound design principles”. This talk focuses on the “disease”, i.e. the design smells, its different types with the help of a comprehensive catalog, its impact on the software, and actionable suggestions to refactor them in real-world settings.

This is an extremly simple topic with a very complex answer. I have spent last 3 years experimenting and working with lot of people to understand what happens to the so called Manager role in Agile world. With a self organizing, empowered team, does Manager still have a role? Do you shelve these senior people who drove all your deliverables in the past for your company? Do you just let go the technical expertize these people bring along?

The research information around the experiment and results will be shared and am very positive that this will help lot of organizations move forward with great benefits. We will see how certain gaps that are created with introduction of Agile can be solved through these senior professionals. At the same time teams don't need to compromize or business doesn't need to compromize on new found agility by adopting any of the Agile practices.

The very next discussion that I will touch base as part of this presentation is the role of Project Leads. Many Leads resist movement to Agile because they feel their growth will now be stagnated. Is this true? It is again an interesting data set captured by talking to Leads in waterfall world and understanding what they really aspire for.

Looking forward to sharing my insights with real implementation and resulting data that I'm sure each of you will benefit from.

Over the last decade, eXtreme Programming practices like User Stories, Evolutionary Design, Test-Driven Development (TDD), Behavior Driven Developer (BDD), Refactoring, Continuous Integration and Automation have fundamentally changed software development processes and inherently how engineers work.

Having experienced various benefits from XP practices on our J2EE stack, our team started to apply these practices to extract, transform, and load (ETL) and Data Analytics side of our product. Unfortunately, there is very little guidance available in this context, esp. for the SAS Platform. Right from finding the unit testing framework to structuring the code to designing our modules and setting up a Continuous Integration builds, our team had to figure out everything, the hard way.

Join us to understand the challenges we faced during this process and how we resolved these challenges.

Our talk will focus on the evolution of the Agile implementation in Amdocs.

While Kanban is widely implemented in the Amdocs Delivery unit, recently we have started experimenting with Scrum in pockets.

Taking it a step further, not wanting to lose out on our learning from Kanban, we are trying ScrumBan in a large scale project.

We will share the approach, the challenges and what we have adopted from Scrum and Kanban in this implementation.

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.

In 2011, I worked for Qik, a startup that got aqcuired by Skype. At that time Skype was in the middle of an agile transition. Аfter aquisition, Qik team was told to adopt the Agile process used by Skype. I worked with the team as an agile coach. After adopting Skype's "agile" process, our ability to deliver was brought down to almost zero. In this talk, I'll tell you the story as it happened, analyze the key problems that we faced and describe how we finally solved them. Come to this talk, if you want to avoid similar mistakes. If you are already through with your transition, I would be interested to know if you see any patterns. 

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.