Being an Agile Coach & TDD Consultant, I have helped many product companies during their Agile transformation journey. I have observed many interesting good, bad and ugly practices followed in industry in the name of TDD. I would like to share my experience with the audience and guide them towards the correct direction and help them extract the true benefit of TDD.

To give a simple example, using code-coverage as a metrics to measure the effectiveness of the Unit Test Cases is one of the common mistakes committed by many companies. 

In my presentation, I would like to demonstrate hands-on and discuss, how to effectively follow TDD and what to watch out and avoid bad practices in TDD.

Consider an agile utopia executing scrum for software development. How would you feel if your biggest strength of receiving early feedback from your end-users turns out to be your Achilles heel? Recently I faced this dilemma where my end-users unfortunately were a group of introvert individuals. This led to Monger project’s MVP almost declared as a failure since it did not fulfill the end-user’s requirements. 

Many a times, projects transform their delivery mechanism from traditional models to agile with a myth that agile is a recipe for success. In reality many projects fail since agile is not well understood by the teams. A few times (like in this case) the agile process falters not due to incorrect implementation but due to incorrect participants responsible to execute a part of the process.

Experience with me what happens when your end-users falter your feedback loop just because of the nature of individuals. If you’ve ever been a part of a group (or may be in the future) where your end-users are introverts, learn from this experience report how we overcame this problem on the Monger project by strengthening our anemic reviews. At the same time, if you as a participant have been there and done that, I would love to hear about it. 

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.

When any organization plans to move to Agile methodology, it needs to plan multiple initiatives for successful transition. One of the important initiative would be building an Agile Center of Excellence, a team which would support for consistency of Agile implementation across the organization. The Agile CoE we built worked on multiple aspects such as:

• Defining organization-wide Agile methodology, tailoring it as per organization environment if required
• Build knowledge of Agile across the organization
• Supporting the team members with any ongoing queries
• Support in building required Tools and Templates required implementing Agile
• Assessing Agile implementation of different projects, identifying any gaps or improvement areas

This session would cover practical experience of how we built a successful Center of Excellence, which become a big enabler for successful Agile transformation.

This session will focus on what are the aspects organizations should consider when they want to scale agile implementation in organization.  There are several frameworks out there like SAFe, LeSS, Spotify, and so on. what is it that organization is trying to achieve and how a systematic approach of scaled agile implementation can help the organization.

Attendees will be able to understand what aspects should be considered before organization decides to scale agile.  How to scale agile and when to do it largely depends on what organization is trying to achieve. Each organization is operating it in different way so there is no defined formula or framework that will work for all. But guidelines from this session will help the members to identify their needs and then take further action.  These guidelines can help the organization to successfully scale agile irrespective of which framework is selected.

Areas covered in this session are:

• what are the driving principles while scaling agile

• Where to start

• Which Framework should I select?

• Organizational changes

• Role of managers?

• Scaling communication

• Scaling engineering practices

• Scaling Product Management role

• Roll out plan

• Implement the plan

• Grow and evolve

This session will be mix of talk, case study and experience report.

Effective "Code-branching" strategies are still one of the most ignored in Agile development world. In this talk, using case-studies, I would like to present what is wrong with traditional strategies, how it hinders teams to deliver continuously and why Trunk Based Development (TBD) is a durable solution. Furthermore, the talk aims to explore various strategies (code/dev and ops) that enable teams to attain TBD. Finally, the tealk ends with successful TBD case-studies of Facebook and Google.

Impediments are one of the major hurdles for successful agile adoption and implementation, and more so when scaling to multiple agile teams. While everyone acknowledge that impediments should be raised and resolved in a timely manner, the reality is far from what people say. Time and again, teams have not met their sprint commitments because of improper handling of impediments. It is my experience that organizations and agile teams don't realize the urgency of identifying, highlighting and escalating impediments while they focus a lot on following sprint cadence and other agile practices. Lack of effective management of impediments is one of the silent killers of running successful agile teams.

Video: https://youtu.be/CS9lHn3WHLo

“A little knowledge is a dangerous thing”

                                                -Alexander Pope (1688 - 1744)

 Session Objective: Clarify myths and misunderstandings about the Kanban Method.

Kanban is often full of mystique for organizations. It is often talked about, frequently misunderstood, and usually incorrectly applied. The industry is rife with a lack of understand of the relevance, abilities and possibilities of the Kanban Method. This session will discuss how Kanban is becoming increasingly significant to software services as well as product organizations. We will then examine some of the common myths and misconceptions associated with Kanban and evaluate if they stand merit against the facts. We will conclude the discussion with a very brief overview of the fundamental principles, practices and values of the Kanban Method.

Cases like the Toyota’s Unintended Acceleration case of 2007 highlight the impact of bad engineering practices on the quality of the product. This eventually impacts the business and the organization’s reputation as well. There have been several such instances in recent history, yet business stakeholders get tempted to compromise on the sound engineering practices for having quick gains. This approach, most of the times, is due to lack of understanding of these practices and under-estimating their negative impact in the long run. The aim of this paper is to highlight this impact and present a strong case for paying enough focus on concept like technical debt to reduce and control it in software development context.

This fun group game is a simulation of Kanban methodology in the software delivery cycle. It shrinks the complete delivery cycle in this short game giving a real essence of how Kanban works.

The WIP limits in the kanban game, just as in real kanban, prevent work from being pushed to the next step and encourages the team to focus on the bottleneck before progressing.

It uniquely demonstrates the dependencies in the operations, or time constraints and deadlines.

• For instance, one should know the clear difference between hygienic practices vs context based practices - the first ones are not to be compromised at any cost, whereas the latter ones are to be applied based on the need, not because some framework prescribes it.

• For example, in the Execution Phase, doing pair programming and following TDD are hygienic practices for us. Having said that, it’s perfectly okay for a pair to split and work on a specific task on a case-to-case basis (we call this Pragmatic Programming) and the pair decides when and how long they would split and when to re-join.

• Started almost 3 years ago, on-going
• 10 quarterly planning workshops done so far
• 10+ teams, 7 timezones
• peak program size: 250+
• peak team size from my org.: 50+
• total no of systems: 10+
• geographical spread: plan: 100 countries, 132 locales launched so far: 53 countries, 56 locales
• 140 page-views / sec
• Av. response time: 1.3s
• Handling 100+K products in the catalog, 15+ K pages , 300+ K responsive images
• Blue-Green production deployment (zero downtime over 1.5 years)
• 3 weeks cycle of production releases

Will highlight the implementation of the Agile Practices in the mission critical software Projects (eg. Medical devices, Nuclear power projects, Safety Projects)  which are expected only to be executed using Waterfall or V-Model. The domain aspects of it and how to relate it to Mission and the goals of project. Will also touch upon the changes relating to Hardware, Firmware, and applications). Its relative coincidence with DAD.

However exhaustive and meticulous your current employee appraisal process is, chances are you aren't pleased with the outcome. The primary objective of a performance appraisal is performance improvement, starting with the individual and rolling up to the organizational level. But an individual who doesn't fare well in an appraisal feels demotivated, defeating the purpose of the exercise.

Agile owes its success and failure to its team.

A lot been discussed on different agile groups related to performing the appraisal of team members when success / failure belongs to team.

This is an Attempt to provide solution to appraising scrum team members remaining in agile framework and philosophy.

We would be discussing The Challenges of current appraising process along with the Challenges brought up with adopting agile process.

To address these challenges we would be sharing 'The proposed solution' and it's alignment with agile philosophy.

Agile coaching is an emerging field and frequently coaches struggle to find out the right answers for the following questions:

How to choose between the Waterfall and Agile methodology for the proposed project?

Which Agile methodology is better in the given scenario?

How to mix and match various Agile practices to get the best results?

What's the difference among training, mentoring, consulting, therapy and coaching?

What is the secret of becoming a great Agile coach?

This session is aimed to address these genuine questions in an interactive way.

While adopting the Agile methodology, one of the critical aspects of this change is the mindset change. As is said, Agile is more about the mindset than the process to be followed. If the mind adjusts the process then follows. As with other organizations adopting to Agile, and adapting to it, we too have been through this change management & transformation. The biggest transformation needed is  the agile mindset or agility in thinking & acting, and our experience has been that it takes a while to adjust to it. It needs a mindset and a cultural change in an organization to completely embrace and realize the full potential of Agile.

How does one achieve the mindset adjustment or get this cultural change in our teams & make it a habit? How does the leadership bring about this transformation in themselves and their teams, especially the teams with prior experience working on waterfall or iterative systems. The challenge to adapt is at all levels viz. at individual, team, and at the leadership level too.

One of the popular culture change tool and now a philosophy and training is the “FISH PHILOSOHY-Catch the Energy and Release the Potential”. In our experiments on the cultural change, we see this addressing certain aspects of ushering in the agile culture or the mindset within the teams. This is an attempt to bridge this transformation with the techniques of the Fish philosophy. The energy seen due the FISH philosophy at the work place is used as navigate this transformation and bring about the culture of Agile in thinking, then doing would follow easily.  

Agile Principles are more Software Development focused. There is need for Organizations to look for Software Development Agility nothing but DevOps. In order to achieve Organization operational efficiency the complete Organization needs to be DevOps complaint.

Take away for orgnizations on What is that they need to do?

At present, DevOps has got several buzz words associated with it. Standards in terminology by bringing in concepts such that everybody speaks same language.

As an Agile Coach, I would like to participate and be a part of ART coach the teams who are new to Scrum, SAFe so that they are empowered to move Scrum to SAFe zone.

Transformation Journey started with the readiness assessment of the teams. Charting of Road map with milestones to fill gaps, formation of teams, assigning certified SM and team building activities were performed for distributed teams including SM, PO. Tele-presence was used to have F2F connect between the teams. Activities were assigned to onsite and offshore teams which saw more interaction and problem solving among them. Teams were coached, educated on Scrum and SAFe lifecycle, assertive communication, agile metrics awareness and tracking of the projects.

To make them empowered in terms of domain, technical niche skills, training sessions were conducted and mentors were assigned.

Regular Internal trainings and certifications keeps the pool ready and up skills existing resources on regular basis.

To have right features to go in SAFe releases, PO’s were trained on identifying the MVS (Minimum Viable Solution), Story splitting, writing good acceptance criteria’s.

Being a program, we created weekly forum for architects, PO and SM to have their priorities finalized and funneling happening before features being taken for release planning. 

Zensar’s best agile practices (DoD, DoR, Hardening Sprint, Grooming Sessions, Exploratory testing, Test Automation, peer reviews) helped the team make decisions on release, sprint commitments. User story sizing, task level estimates were prepared by team members without influence from PO, SM, business. We created an environment of trust ensuring the teams work on predictable commitments. We also assess the program health with the in-house Agile Maturity Assessment Tool on a regular basis.

“Silent hour concept” was introduced to ensure the teams work without any disturbance.

Sprint retrospectives were conducted under guidance from Agile Coach to make CI. Innovation games, what if, 5-W techniques were used towards it. 10 minute build was made possible with help from support infra, for Agile projects deployment windows increased, SLA’s redefined for agile projects. DevOps was made part of Scrum to smoothly transition to production support.

Management executives were also trained on various views of ALM tool to track portfolios.

With SAFe, Scrum methodology we could reap benefits of over 23 percent time saving over waterfall project; reduced UAT time, reduction in post-production defects. All this has led greater customer satisfaction.

Agile design or emergent design relies heavily on timely refactoring efforts that aim to improve existing design. Yet often, when the code base grows or when someone else's code is handed over to us, there is a reluctance to refactor existing code - despite an obvious design smell. While the reasons to avoid refactoring may be well-grounded – lack of time, lack of understanding or fear of breaking it – in the long term, delaying code refactoring makes the code rot further. And, as a result, technical debt continues to pile up.

This session begins by reviewing common design smells, discusses five key features of good code and then discusses a common yet often overlooked design smell in detail – big methods. Using an example of a big method, it proposes a refactoring strategy that will ensure that a refactoring effort does not cause any negative side effects. During the session, participants are walked through a real code refactoring example – step by step.

Though the session focuses on one particular design smell (big methods), the proposed refactoring strategy should apply equally well to other design smells too.

A deep-dive session about story point, and why its gaining acceptance over traditional estimation methods.

In our Agile journey, while it is great we focus on mastering various Agile practices, understanding Agile principles and internalizing Agile values at times small yet an  important aspect like Visualization does not get the required attention.   

My presentation will be about various Visualization examples for teams to improve collaboration and communication.  It is going to be an interactive session stuffed with a lot of discussions around the various practical Visualization techniques an Agile coach / Scrum Master / Agile team member should have in his toolbox.

These techniques enable communication and aid knowledge sharing by making information visible to the team members. There is no prescription but the suggestions that one can experiment, evaluate and evolve as per team's need.