Proposed (14)
Liked (46)
Commented (128)
Naresh Jain
Score 744
Naresh Jain

Tech-Startup Founder & Agile/Lean Expert

Agile FAQs

  India

Naresh Jain is an internationally recognized Technology & Process Expert. Over the last decade, he has helped many Fortune 500 companies like Google, Yahoo, Amazon, HP, Siemens Medical, GE Energy, Schlumberger, EMC, Alcatel Lucent, to name a few clients.

Naresh Jain's Startup Icons

Naresh is leading two tech-startups, which build tablet-based adaptive educational apps for kids, conference management softwaresocial-media search tool and a content curation and voting platform. His startups are trying to figure out the secret sauce for blending gamification and social learning using the latest gadgets.

As an independent consultant, Naresh worked with many fortune 500 software organizations and startups to deliver mission critical enterprise applications. Having played various roles of Founder, Agile Coach, Quality Evangelist, Technical Lead, Product Owner, Iteration Manager, Scrum Master, Developer, QA, Recruiter, Build Master, Mentor & Trainer, he is well equipped to help your entire organization to rapidly adapt Agile and Lean methods.

Agile Software Community of India

Naresh founded the Agile Software community of India, a registered non-profit society to evangelize Agile, Lean and other Light-weight Software Development methods in India. Naresh is responsible for conceptualizing, creating and organizing 50+ Software conferences worldwide.

Member since 1 year

Naresh Jain proposed:


Naresh Jain
Naresh Jain
SAMPLE PROPOSAL - Product Discovery Workshop
Naresh Jain
Naresh Jain

Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

During this workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

This 90 mins workshop teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

This is a sample proposal to demonstrate how your proposal can look on this submission system.

Duration: 90 mins
Type:  Tutorial
Level: Beginner
» »
90_mins  
×
tutorial  
×
beginner  
×

product-owner  
×
agileux  
×
workshop  
×
1 year ago by Naresh Jain

Naresh Jain
Naresh Jain
Techniques for Effectively Slicing User Stories
Naresh Jain
Naresh Jain

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.

Duration: 90 mins
Type:  Tutorial
Level: Intermediate

Ashish Parkhi
Ashish Parkhi
Techniques to Speed Up your Build Pipeline for Faster Feedback.
Ashish Parkhi
Ashish Parkhi

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.

Duration: 45 mins
Level: Intermediate
»
agile-tools  
×
»
45_mins  
×
intermediate  
×

jenkins  
×
build  
×
fast-feedback  
×
ssd  
×
4 months ago by Ashish Parkhi

Naresh Jain
Naresh Jain
Continuous Deployment for iOS Game Development
Naresh Jain
Naresh Jain

"Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).

Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.

Our main question was: As mobile app developers, how should we architect/design our apps for CD?

We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.

If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.

Duration: 45 mins
Level: Intermediate
1 year ago by Naresh Jain

Sachin Natu
Sachin Natu
Inverting Test Pyramid - A First Hand Experience Report
Sachin Natu
Sachin Natu

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.

Duration: 45 mins
Level: Intermediate
» »
45_mins  
×
intermediate  
×

testing  
×
test-pyramid  
×
4 months ago by Sachin Natu

Naresh Jain
Naresh Jain
Scaling XP Practices inside your organization using Train-the-Trainer Model
Naresh Jain
Naresh Jain

How do you effectively scale skill-based, quality training across your organization?

Over the years, I've experimented with different ideas/models to scaling skill-based training across an organization. In the last 4 years, I've pretty much settled down on the following model. Its very useful when mentoring teams on skills like Test-Drive-Development (TDD), Behavior-Driven Development (BDD), Product Discovery, Writing User Stories, Evolutionary Design, Design Patterns, Problem Solving, etc. I've successfully implemented this model at some very prominent fortune 500 enterprises.

The goal of this workshop is to explore what other successful models organized have used to scale skill-based training in their organization.

Duration: 90 mins
Type:  Workshop
Level: Advanced
1 year ago by Naresh Jain

Prafulla Girgaonkar
Prafulla Girgaonkar
The Art of SQL Database Refactoring
Prafulla Girgaonkar
Prafulla Girgaonkar

"We've tested this feature thoroughly and it worked really well. But for some weird reason, it's really slow in production today...must be a network issue...or may be the server is having a bad day..."

Do you often hear these kinds of comments in your development team? Let us guess, your application is very data-centric and churns big blocks of data on every user request. And under the hood, your application is most probably heavily dependent on long/complex queries with joins, temp-tables, case-statements, nested queries, etc.

These SQL queries probably started-out very simple. But as your requirements evolved, iteration after iterations, the queries also grew in complexity. And most often, even if you test-drove your newer stories, the performance of these complex queries is not evident until you run them in production. 

Given that our requirements will evolve and so will our database, how do you deal with the above problems?

There are TWO essential parts to evolutionary database design:

  1. The art of refactoring your SQL queries.
  2. Figuring out the right balance of what processing is done in SQL on the DB sides and what is done on your service side in your App/Web Server.

Join us as we take a tour of how we refactored our complex, non-performant queries and overall DB without hurting our time-to-market.

Duration: 45 mins
Level: Intermediate
» »
45_mins  
×
intermediate  
×

query  
×
data  
×
java  
×
sql  
×
long-queries  
×
slow-queries  
×
talk  
×
refactoring  
×
4 months ago by Prafulla Girgaonkar

Sachin Natu
Sachin Natu
Death of Inspection: Reincarnation of the Testing Community
Sachin Natu
Sachin Natu

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.  

Duration: 45 mins
Type:  Case Study
Level: Intermediate

Prasad Kunte
Prasad Kunte
Our Journey Down the Scary Legacy Code Land
Prasad Kunte
Prasad Kunte

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 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 exisiting 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. We started with 2 layers, workflow tests and business logic acceptance tests. And then, as we refactored the code, we wrote unit tests. The new code was entirely test driven, with 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.

Duration: 45 mins
Type:  Case Study
Level: Intermediate
» »
45_mins  
×
case-study  
×
intermediate  
×

legacy-code  
×
test-pyramid  
×
refactoring  
×
6 days ago by Prasad Kunte

Prafulla Girgaonkar
Prafulla Girgaonkar
eXtreme Programming for ETL and Data Analytics
Prafulla Girgaonkar
Prafulla Girgaonkar

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.

Duration: 45 mins
Level: Intermediate
» »
45_mins  
×
intermediate  
×

sas  
×
sas-language  
×
statistic  
×
etl  
×
analytics  
×
procedural  
×
ci  
×
testability  
×
4 months ago by Prafulla Girgaonkar


Naresh Jain liked:


Prasanna Vaste
Prasanna Vaste
Should we stop using Story Points and Velocity?
Prasanna Vaste
Prasanna Vaste

On Agile projects we estimate user stories in order to allow team to

  1. 1. Track velocity
  2. 2. Decide scope for the Iteration
  3. 3. Help Prioritize stories
  4. 4. Help Release planning

But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.

Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.

I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.

Duration: 20 mins
Level: Beginner

Bhasker Kode
Bhasker Kode
Writing and improving tail recursive functions
Bhasker Kode
Bhasker Kode

Brief history of recursion 

Snippets from a few languages

What is tail recursion?

Design choices around recursion

The importance of tail recursion in erlang

How do you profile such improvements?

 

 

 

Duration: 45 mins
Type:  Talk
Level: Beginner
» »
45_mins  
×
talk  
×
beginner  
×

recursion  
×
profiling  
×
6 months ago by Bhasker Kode

Ashish Parkhi
Ashish Parkhi
Techniques to Speed Up your Build Pipeline for Faster Feedback.
Ashish Parkhi
Ashish Parkhi

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.

Duration: 45 mins
Level: Intermediate
»
agile-tools  
×
»
45_mins  
×
intermediate  
×

jenkins  
×
build  
×
fast-feedback  
×
ssd  
×
4 months ago by Ashish Parkhi

Roy Nuriel
Roy Nuriel
The Quality Assurance Journey - From Waterfall to Continuous Delivery
Roy Nuriel
Roy Nuriel

In the past several years we have seen more and more organization taking the decision and moving their development divisions to adopt Agile methodology. In most cases the change starts with a POC of a new and – in most cases – small project that validates the ability of the organization to make the shift to Agile. In many cases the development team takes the lead: changing the process, moving to unified teams, selecting which Agile practice to adopt, etc.

In this session I will share how we made the shift, while focusing on the change in our quality process.

As an R&D group that develops an Agile solution (HP Agile Manager), we wanted to get it right. We changed the way in which we develop software from waterfall to Agile, and built a process to support the teams in a complex and large enterprise. While previously we were accustomed to delivering releases in 1-2 year cycles, we now operate within a SaaS model where we update our production environment on a weekly basis. 

We have experimented with the same process that our customers are going through and, as a result, we adapted the way our QA engineers work. In accordance with their new role, we gave them a new title – Dev Testers.

Here are some of the dilemmas we faced:

-          What are the differences between "Dev Tester" and "QA Engineer"?

-          How can we measure quality in 2-week sprints?

-          What needs to change when testing a SaaS solution that is delivered on a weekly basis?

-          When and how should load testing be performed?

-          Automated v. manual testing

-          What testing should be part of the CI process?

-          How do offshore Dev Testers take part in our Agile practices (e.g. daily meetings)?

We dealt with all of these questions, and I would like to share the lessons we learned, our conclusions, and some of the challenges that we still face.

Duration: 45 mins
Type:  Case Study
Level: Intermediate
»
beyond-agile  
×
»
45_mins  
×
case-study  
×
intermediate  
×

qa  
×
1 year ago by Roy Nuriel

Sachin Natu
Sachin Natu
Inverting Test Pyramid - A First Hand Experience Report
Sachin Natu
Sachin Natu

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.

Duration: 45 mins
Level: Intermediate
» »
45_mins  
×
intermediate  
×

testing  
×
test-pyramid  
×
4 months ago by Sachin Natu

Prafulla Girgaonkar
Prafulla Girgaonkar
The Art of SQL Database Refactoring
Prafulla Girgaonkar
Prafulla Girgaonkar

"We've tested this feature thoroughly and it worked really well. But for some weird reason, it's really slow in production today...must be a network issue...or may be the server is having a bad day..."

Do you often hear these kinds of comments in your development team? Let us guess, your application is very data-centric and churns big blocks of data on every user request. And under the hood, your application is most probably heavily dependent on long/complex queries with joins, temp-tables, case-statements, nested queries, etc.

These SQL queries probably started-out very simple. But as your requirements evolved, iteration after iterations, the queries also grew in complexity. And most often, even if you test-drove your newer stories, the performance of these complex queries is not evident until you run them in production. 

Given that our requirements will evolve and so will our database, how do you deal with the above problems?

There are TWO essential parts to evolutionary database design:

  1. The art of refactoring your SQL queries.
  2. Figuring out the right balance of what processing is done in SQL on the DB sides and what is done on your service side in your App/Web Server.

Join us as we take a tour of how we refactored our complex, non-performant queries and overall DB without hurting our time-to-market.

Duration: 45 mins
Level: Intermediate
» »
45_mins  
×
intermediate  
×

query  
×
data  
×
java  
×
sql  
×
long-queries  
×
slow-queries  
×
talk  
×
refactoring  
×
4 months ago by Prafulla Girgaonkar

Neil Killick
Neil Killick
The Guessing Game - Alternatives to Agile Estimation
Neil Killick
Neil Killick

Agile promotes empiricism and change, yet many practitioners continue to scope out and estimate delivery times and costs for software products and projects.

Defenders of the art of estimation claim that we need to estimate software projects in order to answer common business and customer questions such as:

  • Should we go ahead with this project? (go/no-go)
  • How much will it cost? (bottom line)
  • When will it be done? (predictability)
  • Should we do project B instead of A? (prioritisation)

This session challenges participants to flip these questions on their heads and seek alternatives to estimation rituals. It covers the many risks inherent with an estimation culture and demonstrates real, practical alternatives, both at the portfolio and the sprint level.

Duration: 45 mins
Type:  Talk
Level: Intermediate
»
beyond-agile  
×
»
45_mins  
×
talk  
×
intermediate  
×

agile  
×
lean-startup  
×
lean  
×
scrum  
×
1 year ago by Neil Killick

Andrea Heck
Andrea Heck
Distributed Product Owner Team for an Agile Medical Development
Andrea Heck
Andrea Heck

We are developing medical imaging and workflow software in an agile way with development teams distributed to several countries. One of the major challenges is how to set up and communicate within the Product Owner team. There we have to deal with the distribution, e.g., have the Product Owner either onsite with her peers or with her Scrum team, travelling, or with proxy. We need people who are good in two different fields of knowledge: medical and software development. As a third issues, the environment of the customers may be different in different countries.

We have ramped up local Product Owners in different countries, have found local collaboration customers, and have developed a set of communication channels and workshops how to synchronize Product Owners in the team, share a common vision and backlog with their Scrum teams, and collaborate with customers locally and globally.

Duration: 45 mins
Type:  Case Study
Level: Advanced
» »
45_mins  
×
case-study  
×
advanced  
×

1 year ago by Andrea Heck

Venkat Subramaniam
Venkat Subramaniam
Haskell for Everyday Programmers
Venkat Subramaniam
Venkat Subramaniam

I learn different languages not to make use of them, but to program in my current languages in a better way. As we adapt functional style of programming in mainstream languages, like Java, C#, and C++, we can learn a great deal from a language that is touted as a purely functional language.

Haskell is statically typed, but not in a way like Java, C#, or C++. Its static typing does not get in the way of productivity. Haskell quietly does lazy evaluation and enforces functional purity for greater good. Everyday programmers, like your humble speaker, who predominantly code in mainstream languages, can greatly benefit from learning the idioms and style of this elegant language. The next time we sit down to crank out some code in just about any language, we can make use of some of those styles, within the confines of the languages, and move towards a better, functional style.

Duration: 90 mins
Type:  Talk
Level: Intermediate
» »
90_mins  
×
talk  
×
intermediate  
×

functional  
×
lazy  
×
static-typing  
×
haskell  
×
5 months ago by Venkat Subramaniam

Sachin Natu
Sachin Natu
Death of Inspection: Reincarnation of the Testing Community
Sachin Natu
Sachin Natu

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.  

Duration: 45 mins
Type:  Case Study
Level: Intermediate


Naresh Jain commented:


Niranjan N V
Niranjan N V
Mr.Agile Leader - “ Develop People or Solutions”
Niranjan N V
Niranjan N V

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

Duration: 20 mins
Level: Intermediate
» »
20_mins  
×
intermediate  
×

beginner  
×
agile-leader  
×
scrummaster  
×
lean-agile  
×
1 week ago by Niranjan N V

Vijay Bandaru
Vijay Bandaru
Lean and Kanban Implementation from Trenches
Vijay Bandaru
Vijay Bandaru

I was part of a Large Scale Agile transformation in my organization and I was one of the Agile coaches there. As part of transformation we have created LeanOps teams to manage the technical debt, production incidents with a focused concentration. This article covers the following:

 

- Why the trasnformation required?

- What are the structural changes implemented?

- LeanOps inception

- Lean Ops working Model

- Challenges with the LeanOps

- How we addressed those challenges?

- Goal oriented approach

- Q & A

Duration: 45 mins
Type:  Case Study
Level: Intermediate

Mikael Lundquist
Mikael Lundquist
10 times better quality with agile transformation. How we did it!!!
Mikael Lundquist
Mikael Lundquist

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. In the beginning of 2013 the whole section had transformed and currently the section now breeds and sleeps Scrum.

Since 2012 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 itself in an agile way, in the way we interpret scrum. The point is to not just talk of how we did, but also show it on stage.

This means that we are going to interact with the audience and we expect them to influence our presentation.

 

Duration: 45 mins
Level: Beginner
1 month ago by Mikael Lundquist

Alexey Pikulev
Alexey Pikulev
“Help Me Do It Myself!” Growing a self-organization by using the Montessori Method
Alexey Pikulev
Alexey Pikulev

“Help Me Do It Myself!” Montessori is an innovative, child-centered approach to education, developed a century ago by Dr. Maria Montessori who was struck by how avidly the children absorbed knowledge from their surroundings. The goal of the Montessori method is to foster a child’s natural inclination to learn, where Montessori teachers guide rather than instruct, linking each student with activities that meet his interests, needs, and developmental level. But is this method only suitable for children?

In this talk, I will demonstrate how to apply the Montessori education method in growing self-organized teams. We’ll discuss what Leaders may find useful and how to adapt this methodology in the day to day work of your organization.

Duration: 45 mins
Type:  Talk
Level: Intermediate
» »
45_mins  
×
talk  
×
intermediate  
×

1 month ago by Alexey Pikulev

S R V Subrahmaniam
S R V Subrahmaniam
Imperatives for Scaling Agile
S R V Subrahmaniam
S R V Subrahmaniam

Implementing agile at scale is contextually different when compared to Agile at team level. In this session, I intend to delve into pre-requisites or undelying conditions needed for scaling - immaterial of the scaling methodology adopted. As they say, agile practices are not fractal, the principles are. 

This session is based on the scaling experiences I have had as a practitioner and a coach in Product Development and Enterprise Application development set-ups in Utilities, Building Technologies, Enterprise security and Automotive domains.

The context changes dramatically when it comes to Agile @ scale. Complexity in factors like platform, integration needs, domain complexity, departmental interactions all multiply manifold. This brings into the question of the base infrastructure that agile@scale needs in terms of technical, organizational and Project Governance set-ups. For large program teams, mostly distributed, the essentials for collaboration needs to be in place to transact work at different levels.

The ambient conditions (with typical real-life patterns) are required in the following areas:

1. Extent of departmentalisation

2. Flexibility of existing development processes

3. Usage of collaborative tools

4. Harmonization of tools and integration practices (like CI)

5. Project Funding and governance set-ups (metrics and reporting/tracking)

It would pertinent to note that many of these factors also discussed in the context of Enterprise transformation as well.

Duration: 45 mins
Type:  Talk
Level: Intermediate
» »
45_mins  
×
talk  
×
intermediate  
×

2 weeks ago by S R V Subrahmaniam

Patrick K Phillips
Patrick K Phillips
Understanding Lean and How it Can Scale Agile
Patrick K Phillips
Patrick K Phillips

Is business process improvement part of Lean IT? What about best practices and benchmarking? Is agile software development a Lean IT practice? What about IT operational excellence and the ITIL service management framework? How about performance management dashboards and scorecards? Is applying Lean techniques to project management considered a Lean IT practice? And is cloud computing relevant in a Lean IT world? The answer to all these questions is yes. But Lean IT is much more than just a set of tools and practices; it is a deep behavioral and cultural transformation that encourages everyone in the organization to think differently about the role of quality information in the creation and delivery of value to the customer.

Lean IT enables the IT organization to reach beyond alignment toward fundamental integration, cultivating an inseparable, collaborative partnership with the business. Whether you are new to Lean, or a seasoned veteran, in this book you will find new insights into the power of Lean and the critical impact of an integrated IT function. In this discussion Patrick Phillips will explore all aspects of Lean IT within two primary dimensions:

Outward-facing Lean IT: Engaging information, information systems, and the IT organization in partnership with the business to continuously improve and innovate business processes and management systems

Inward-facing Lean IT: Helping the IT organization achieve operational excellence, applying the principles and tools of continuous improvement to IT operations, services, software development, and projects These two dimensions are not separate but complementary.

The adoption of the term Lean software development is more than a name change. While agile is a set of development and life cycle management tools and methods focused on the just-in-time development of quality software, Lean software development addresses a larger context: the environment within which the software operates, the value streams of the enterprise. For example, in a business application, properly functioning software is viewed as a supporting element of the business process. In an embedded software application (such as the operating system of a smartphone or the control systems of a jet aircraft), the software is part of the overall product design and value proposition to the customer. Lean emphasizes seeing the whole through the eyes of the customer, not its component parts through the eyes of the designer or developer. “Lean software development views all Agile methods as valid, proven applications of Lean thinking to software,” says Jeff Sutherland, a signer of the Agile Manifesto. “It goes beyond Agile, providing a broader perspective that enables Agile methods to thrive.”

In the words of Mary and Tom Poppendieck, “A Lean organization optimizes the whole value stream, from the time it receives an order to address a customer need until software is deployed and the need is addressed. If an organization focuses on optimizing something less than the entire value stream, we can just about guarantee that the overall value stream will suffer.” We have witnessed many skilled agile practitioners fall into the common Lean trap: focusing on tools and techniques rather than solving problems and eliminating waste. Lean software development expands agile’s focus from optimizing the software development process toward improving entire value streams. Thus, Lean software development must integrate and synchronize with all business processes, management systems, and kaizen activity, supporting the Lean transformation of the overall enterprise.  This session will take you into a discussion with a practitioner who is one of the industry's leading figures in understanding and utilizing lean. 

 

 

 

Duration: 60 mins
Type:  Keynote
Level: Intermediate
» »
60_mins  
×
keynote  
×
intermediate  
×

lean-agile  
×
frameworks  
×
scaling-agile  
×
lean  
×
2 months ago by Patrick K Phillips

Madhavi Ledalla
Madhavi Ledalla
Deep dive into RETROSPECTIVES- how do we break the usual norms so that these reflections could be made thought-provoking ones!
Madhavi Ledalla
Madhavi Ledalla

         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!

 

Duration: 60 mins
Type:  Workshop
Level: Intermediate
2 weeks ago by Madhavi Ledalla

Sophie Freiermuth
Sophie Freiermuth
"Agile this" - applying Agile outside Development
Sophie Freiermuth
Sophie Freiermuth

Agility is proving very seductive to teams and leaders beyond development teams and rooms, and we are seeing it applied to all parts of businesses and to non-digital products. Whether a coach or a Scrum Master is deployed, various approaches attest to the interest in Agile and the willingness to appropriate a process that has proven its value.

Using my 6+ years experience of designing products with agile development teams, and my current experience of coaching a team of Scrum masters tasked with "agiling" processes of book (print) teams, I will explain approaches that can be taken to support or implement Agile outside development, and illustrate in particular:

  • working with design teams and the tricky part of fitting a product exploration phase into an Agile cadence such as Scrum - the most commonly seen process.
  • applying agile to the transition to agile, with the example of book publishing.

Following often-heard requests, I have designed this session for agile practitioners (coaches, scrum masters, product owners) who are looking at being ready to deploy agility beyond development teams, in order to give them a peak into the life of agility outsode the development room and digital products, and the tools to approach it with non-developers.

Duration: 60 mins
Type:  Talk
Level: Beginner
» »
60_mins  
×
talk  
×
beginner  
×

1 week ago by Sophie Freiermuth

Jeff Lopez-Stuit
Jeff Lopez-Stuit
The Exorcist Was a Lean Planning Master
Jeff Lopez-Stuit
Jeff Lopez-Stuit

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

Lightning 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.
Duration: 5 mins
Level: Beginner
» »
5_mins  
×
pecha-kucha  
×
beginner  
×

1 week ago by Jeff Lopez-Stuit

Shiwangi Prasad
Shiwangi Prasad
Get up and running with Teamcity
Shiwangi Prasad
Shiwangi Prasad

As a tester in an agile model of software development team, I felt the need to have an automated mechanism of getting fast feedback on my growing application. This talk is to share my learnings on the set up, configuration and various processes followed in this automation. The benefits of having a CI and automated test runs, their set ups will be shown through a demo.

 

Duration: 45 mins
Type:  Tutorial
Level: Beginner