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. 

Due to the business benefits which accrue from Agile, clients are demanding their IT Departments/Partners to adopt Agile. It is quite common to find a situation where the client has adopted Agile, but its Partner/Vendor has not.

This talk is based on my consulting engagement with a client who had adopted Agile and their partner had not, and the client wanted the partner to Adopt Agile.

The talk will cover the critical challenges encountered in getting the partner to adopt Agile, especially given the wide difference in cultures of both organizations and also the organizations being located in different continents. The talk will also cover the key learnings from this journey.

Traditionally application security has involved upfront design and a big bang penetration test after development. This leads to the phenomenon of “bolt-on” security that translates into increased cost and complexity.

Drawing on our experience on real-world projects, we show how security can be baked-in on an agile project. Using case studies we demonstrate how security concerns are captured during project inceptions, how developers write secure code, security testing is automated and how configuration management can help achieve secure deployments. This talk introduces several new concepts like secure by design, secure design patterns and lightweight code reviews.

I talk about 10 lessons from Toyota Production System that are important but not talked about.

Lesson I: Getting the foundation right!

Lesson II: Be patient to get the foundation right!

Lesson III: 3S vs 2S

Lesson IV: Three stages of Seiso

Lesson V: Understanding Seiketsu

Lesson VI: Implementing Shitsuke

Lesson VII: Improvement initiatives are harder to sustain

Lesson VIII: Keep broadcasting your success

Lesson IX: Kaizen vs Sustenance

Lesson X: Lessons from 3MUs and Visual Management

The Agile Manifesto was formulated by 17 people in 2001. We know the principles of the Agile Manifesto … but do we really understand it?

Depending on the organisation culture, the team culture and various other factors, they reach varying levels of Agile adoption. Martin Fowler talks about the levels of adoption and the path to get better via his post on “Your Path through Agile Fluency”.

Not surprisingly, not all Agile project implementations are successful.

This session is going to take you through a journey to talk about some of the Myths of Agile and also behaviors that inhibit organisations and teams to reach great(er) heights in Agile Fluency to achieve Agile’s benefits.  As a result, the Agile Manifesto has remained on paper, but teams have come up with their own ‘workarounds’ - which are not truly solutions to solve a complex problem well.

We accept it because of our “chalta-hai (it’s ok)" attitude. At the end, what are we then left with? The Agile “Chalta-Hai (It's OK)” Manifesto.

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.

Pair-programming is a well-known practice, and it has been introduced by one of the thought leaders of Agile world, Kent Beck. I respect any technique that encourages collaboration and interaction among teams, and gets teams to communicate better.

However, if you want to establish understanding of mastery or a skill-set, and increase the shared knowledge across your team members, then you need to re-think & apply new techniques.

In this talk, I’ll share about What-Why-How of "Fibonacci Pairing" technique, which is yet another discovery from practice.

The main goal of that technique is to establish understanding and improve collaboration, without overcrowding by artificial ways like lecturing.

Fibonacci Pairing is simple yet very effective technique that can improve team work. This technique should be regarded as a complementary way to improve team culture effectively.

We will elaborate with practical examples, real life experiences, and applicable ways onto different contexts.

How many deliverables should we commit to our customers in, say, the next two weeks? An intriguing question asked by many Agile teams at the beginning of every iteration. The answer to this question depends largely on the team's thinking, philosophy, and skills -- which unfortunately cannot be measured. Then how do we forecast the deliverables?

How about a mathematical formula that provides an unbiased control based on the historical achievements of the team, which can be used for prediction? That's exactly what focus factor does.

MVP is defined as : "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."It doesn't say a thing about the product being valuable to the customers or market segment.

MVP is minimum viable product *NOT*  minimally marketable feature set / first release!  MVPs are the experiments we learned from on the way to our first release of the software.

To us the core of the difference between "Minimally Viable Product" and "Minimally Marketable Product" is in the purpose.  An MVP's purpose is to learn, an MMP's purpose is to serve.  Understand the problem vs address the problem.

• Have you been in a situation where everything gets prioritized as MUST HAVE?
• Have you been in a situation where you have find it difficult to get different stake holders to agree on relative priority of different features?
• Most of the time is spent in discussiing low value features?
• Whoever screams the loudest, gets their pet features prioritixed high?
• Do you want to learn some more prioritization games/techniques that can be used to start prioritizing at Feature level and subsequently refine it to story level?
• You feel the current technique(s) you use for prioritization are time consuming and ineffective?

If answer to any of the above questions is yes, this is the workshop for you to attend

Why Prioritization?

Customers are never thrilled to find out they can’t get all the features they want in release 1.0 of a new software product. In reality, customer expectations are high, timelines are short, and resources are limited. Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions. Thus, requirement prioritization is used in Software development for determining which requirements of the software product/application should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first.

Several methods for assessing a prioritization of software requirements exist. In this workshop we are going show some of techniques/games we have used for feature prioritization.

My talk will be highlighted on the currrent Education System and how Agile and Lean Mechanisms can help us refcator our education System . As we all proceed in this digital world its important to understand what extra can we do to make our children education more informative and creative . Using Agile and Lean from Gurukuls to Modern school- what do we think -Is the current education system is helping our students . Would like to give an insight on where are we going how we can improve it and how we all can contribute to make it better. We can talk on using Agile as Change Agent towards transforming the way our children precieve learning. 

Agile is based on crossfunctional and self organizing teams. Agile is based on the Plan, Do, Review and Adapt Feedback Loop. Feedback is the basis of Agile. Feedback can be amongst team members, between Scrum master and the team, Product owner and Scrum Master, Stakeholders and Product Owner and various combination of the same. We generally give a deficit based feedback. We point out to the short commings, mistakes, fix blames etc. This is a very emotionally chaged discussion which leads to a lose lose situation and a bad relationship. Contrary to this Giving feedback should be based on strengths. It is a planned approach which has to be rehearsed before hand. The main objective of giving the feedback is to find out solution instead of fixing the blame. Let us learn the techniques by which this can be made possible.

When Darwin said “fittest,” Darwin did not mean strongest or fastest or even smartest: he meant most adaptable, best at handling change.

Ants have existed close to more than 100 million years now and they can be considered as one of the most flourishing beings on our earth. They have colonized almost every landmass and they thrive in most ecosystems. Have you ever wondered what makes them so successful?

This success of theirs in so many environments has been attributed to their social organisation and their ability to modify habitats, tap resources, and defend themselves. Ants are one among the most agile creatures that we have seen till date.

This is a collection of real time case studies of failed projects. It is an autopsy of these failed projects studying why these projects failed and how application of agie principles could have saved them.

It is also a study into the organizational culture, behavioral attributes and the people issues and how agile addresses them.

And finally it is a study of why doing a few projects with agile is not sufficient. How complete organizational transformation into agile practices is necessary for long term success for projects, processes and people.

In this talk we will pick up various (5-7) business analysis anti-patterns, specially for Agile projects, that either we ourself have practiced at some point of our BA carrier or have seen other BA's doing. We will talk about the symptoms which act as a sign of presence of these anti patterns, why are the problems associated with them and what are the ways to get rid of them.

These anti-patterns may range from behavior with customers to behavior with the own team.

Some of the anti-patterns we are planning to discuss:

1) BA aka The Order takers
2) Task (UI/backend) based stories
3) Engrossed in too much detail to miss the view of bigger picture - story verus feature 
4) As a “user”...., where the user is either "system" or "product owner"
5) Leave the NFRs / CFRs to the Developers/Tech lead
6) Detail the hell out of stories
7) Focus on Happy Paths only
8) Focus on building a software over solving the real problem
9) Resist change in requirements

Going by the adage - "Without struggle, there can be no progress", we intend to share some extraordinary stories that have and can change the way we work and interact in the Agile space. Every team, whether Agile or not, goes through the forming, storming, norming and performing stage. The storming phase is when an Agile team can look inwards using some Agile best practices to tide over the storm. The pressing challenges that a team can face during the storming phase can be categorized into:
1. People
2. Process
3. Technology

Through our talk, we would like to share some specific challenges that we faced in each of the above categories and how we overcame them -

=================================================================================

Example for people:

Anti-Pattern / Challenge : In a distributed environment, code got overwritten in spite of an existing version control tool
Conclusion : Better self organization within the team
Resolution : Cross pollination, face to face communication, automated notifications
=================================================================================

Example for process :

Anti Pattern / Challenge : Team got together to solve a problem and very little got accomplished due to external dependencies
Conclusion : The need for more collaboration and the right problem solving protocol
Resolution : Adopted design thinking, created cross functional teams, applied 'Pareto' principle
=================================================================================
Example for technology :

Anti Pattern / Challenge : Different deployment scenarios and technology choices
Conclusion : The need for continuous and collaborative integration
Resolution : Created an inhouse one click seamless deployment tool named 'Deployer'
=================================================================================

Today as a team we have expanded beyond the bookshelf, matured as agile practitioners. And now we’re working hard on a creating a visionary path. Improving the Agile world around us is part of our mission of learning, sharing and growing. The talk will re-emphasize our journey through agility and constant evolution.

The matrix organization of yore relied on maximizing returns on each skillset. This lead to having line managers and practice horizontals.
Engineering managers looking after developers and practice managers looking after the respective practices of BA, QA and PMO. This lead to having multiple lines of reporting for team member whilst on the project.
In Agile teams, focus is on the self organising teams of empowered employees working towards common success criteria (project success is team success). Not everyone can be a PO or a Scrum Master. So is the role of so called line managers or practice managers become redundant?
Whats their role in the agile teams?
How their role needs to transform

In this talk I will be addressing these questions. Bring out how some of their responsibilities are now taken up by the team or Product Owner or Scrum Master. I will also be suggesting how line managers can take this as an opportunity to morph into more meaningful roles that help the organization and teams. 

We (Jyoti and I) believe Agility is the mindset that makes you successful by doing what makes sense at any given point. Success in IT projects comes from not only following the mechanics but also applying your skills to people dynamics.

We plan to talk about our experience where agility has helped us fight back in difficult situations than take a flight back. 

Key topics

People dynamics - 

1. Flexing our styles
2. UX at the center - Personas, Euro/Rs/Dollar test, MoSCow
3. Workcell
4. Big picture
5. Customer shoes

Agile Mechanics -

6. Quantify priority
7. Deliver in sprint 0 too
8. Risk burndown

Experience sharing

9. Varied experiences 

Often than not, project management is perceived to be an administrative activity giving rise to lengthy documentation and clear “to do” instructions to the team. On the contrary, Agile is proclaimed to be the new, trendy Avatar proclaiming less or sometimes nil processes to follow and having a “Do it yourself (DIY)” team culture! What the untrained eye misses to see is a fine balance that connects project management philosophy with agile values. This talk will focus on demystifying the art of Agile project management by raising common questions relating “Agile” & “Project Management” and by providing answers that result in a successful marriage of the two.

The talk is delivered based on the experience gained by working with Singapore clients embarking on agile and also as a result of experimenting agile ideas in the Master of Technology class with Software Engineering students.

I would like to share my experience in consulting and managing a distributed team - Identification of strategies for a transformation of "a lifeless program to a Successful Program " and journey from "Collective Inception to Collective delivery" 

This becomes challenging especially with a complicated -distributed engagement model for our client which is a reputed and huge enterprise with presence in every corner of the world.

In a complete globalized world, the major bottleneck for a huge enterprise is the effective functioning of globally distributed teams despite using Agile,lean.

In my presentation, I am going to share the approaches that we tried to address the pain points including the following:

1. Not even able to plan the Iteration planning meeting - Iteration planning not producing the outcome despite hours of planning meeting
2. Manage dependencies between teams for a collective delivery
3. Communication channel between teams  (Change how you communicate/coordinate)
4. To bring the organic coherence between teams despite the cultural difference
5. To also worry about the unknown interfaces & disastrous scenarios
6. Different team communities with different process and practices impacting the other team’s delivery
7. To sustain the work ecosystem for all the teams
8. Inoffensive collective Retrospective for a constructive learning
9. Major Natural pain point – “its not the distance, it’s the time zones”
10. Above all, Conflict Resolution

Eg: one part of approach which we tried was "Mountaineer-Diver Model". 

Impacts of above are listed below:

• Dynamic Dependecy resolution between teams ( instead of long hours of call for each dependency)
• Collective , Objective planning for all the teams by matching the dependencies so that the delivery is not affected and also "All teams walking in same speed"
• More common understanding and project focus in all teams (Frustration with the team members reduced)
• All members from different teams directly interact and work even they are distributed ( as they spend some time physically working together as "integration teams")
• As a result of above -> 2 key metrics improved :
  • Velocity of all teams improved
  • Development and Testing complete even before the deadline -> Delivery before the scheduled date
  • Very less time spent in meetings for conflict & dependency resolutions, planning , etc.. 

 "Project execution was the key success". 

This will help in approaching the issues pragmatically , dynamically and also help understand how its better to make a hybrid out of multiple tools rather than using only one single process tool.