Proposed (4)
Liked (41)
Commented (87)
Naresh Jain
Score 613
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
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

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

Naresh Jain
Naresh Jain
Agile MythBusters
Naresh Jain
Naresh Jain

As the popularity of Agile methods have grown, so have the misconceptions or myths associated with Agile also grown. These myths get even more glorified when we talk about them in the offshore or distributed context. And to make matters worse, you can throw in a fixed-price contract spanner into the engine.

Worry not! In this fun-filled activity, we'll collect facts from the participants that they believe are true and then we'll declare them as confirmed or busted after an interactive (heated) discussion.

Duration: 45 mins
Type:  Workshop
Level: Advanced
8 months ago by Naresh Jain


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  
×
4 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  
×
2 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  
×
2 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  
×
2 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  
×
3 months ago by Venkat Subramaniam

Ellen Grove
Ellen Grove
Build Your Dreams: User Requirements Gathering with LEGO Serious Play
Ellen Grove
Ellen Grove

Let your hands be the search engine for your brain! LEGO® Serious Play® is a powerful thinking, communicating and problem solving technique that can help you and your team do serious work through structured play activities using a popular and playful 3D modeling toy. Through a facilitated process of building models that, storytelling and reflection, every person at the table is engaged and actively participating in the discussion, whether the topic is individual aspirations, team relationships, developing a new product or solving a wicked organizational problem. Everyone builds and everyone tells their story – all participants have equal opportunity to put their own points of view on the table, unlocking new perspectives and exposing the answers that are already in the room.  LEGO Serious Play has been used successfully for team-building and problem solving in a variety of organizations, from NASA to RBC to academic settings and public utilities.  

This presentation provides a hands-on introduction to LEGO Serious Play, so that you can experience firsthand how using LEGO to do real work unleashes creativity and enables meaningful conversations in a very short time. We will explore how to use this playful technique to collaboratively elicit information about user requirements and strategic design issues using the open source User Requirements with Lego methodology developed by a team at the University of Lugano, Switzerland.  This approach is particularly suited to Agile teams that want to get team members and stakeholders sharing their different perspectives on common goals in an open and light-weight manner.

Duration: 90 mins
Type:  Workshop
Level: Beginner
» »
90_mins  
×
workshop  
×
beginner  
×

requirements  
×
lego  
×
1 year ago by Ellen Grove


Naresh Jain commented:


vinaya muralidharan
vinaya muralidharan
ScrumBan Recipe – A pinch of this, a handful of that
vinaya muralidharan
vinaya muralidharan

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.

Duration: 20 mins
Level: Intermediate
2 months ago by vinaya muralidharan

Tushar Sharma
Tushar Sharma
Does your design smell?
Tushar Sharma
Tushar Sharma

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.

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

refactoring  
×
design-smells  
×
design-debt  
×
2 weeks ago by Tushar Sharma

Naveen Indusekhar
Naveen Indusekhar
9 Steps to Agile Adoption: a fail-safe experiment
Naveen Indusekhar
Naveen Indusekhar

While Agile adoption and practice is a complex model for mid/large sized Product companies to implement, we see a need for some sort of framework that can help drive it.

Why do you need to be Agile? Where do you start, when do you start, and also how do you start? These are questions that reside in most of us during early stages of adoption. Here is a 9-Step breakdown that will help companies and teams adopt multiple Agile methodologies in different situations and scenarios. Maturing it from a ‘Persona Perspective’ framework helps the ‘decision-maker’ have a case for investment, further evaluate if it works, and improve it all through!!

The discussion and idea is just my proposal that should help a team or an organization and is need not be the only way to implement Agile in an organization. Further detailing into these phases can form an overall Mindmap structure that is open to adopting from an organization and people standpoint.

Duration: 45 mins
Level: Advanced

Naveen Indusekhar
Naveen Indusekhar
Research paper on 'What happens to Engineering Manager in Agile world'
Naveen Indusekhar
Naveen Indusekhar

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.

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

2 weeks ago by Naveen Indusekhar

Lakshmi Narasimhan
Lakshmi Narasimhan
Functional languages as a major force in programming language design
Lakshmi Narasimhan
Lakshmi Narasimhan

 A lot of concepts are being adopted from functional programming languages into the mainstream.

Here's some evidence.

Garbage collection
Originally invented for Lisp. Adopted by mainstream languages recently.

Type inference
Automatic type deducing from an expression. Has been adopted in C#, D, Go and C++11.  Uses Hindley-Milner Algorithm, which has its roots in type theory and functional programming.

Algebraic data types
Creation of composite types from simpler ones, structs and enums on steroids. Originated in a functional language called Hope. Stock stuff in Haskell and ML family languages. Found recent adoption in Rust.

Nullification of null
null reference was termed a "billion dollar mistake" by its inventor. Haskell uses a Maybe instead. Scala uses the Option type. Rust also adopts this idea.

List comprehensions
very common in Lisp. Sugary for loops. Caught on in python and ruby. In fact, introducing lists as a part of the language core is not something mainstream languages like C had. Every time the programmer had to maintain a list of sorts, they had to implement their own and manage the memory. This is the reason why all programming tests have some variation of a linked list implementation question!

Lambdas
Yup, you guessed it. Borrowed from Lisp.

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

2 months ago by Lakshmi Narasimhan

Frans Overbeek
Frans Overbeek
Spotless Clean Frontend Development with BDD, DSL and Storyboards
Frans Overbeek
Frans Overbeek

After 3 years of improving our frontend development process we ended up with mixing BDD, DSL and Storyboards for developing spotless clean frontend code. Each approach is already powerful on his own but combining these will make them unbeatable. The characteristics are collaborate, communicate and visualize, BDD is the collaborating process between disciplines, DSL for enabling the communication and Storyboards for visualization.

Let me show you how this works by live coding a frontend application using this mixture of approaches. The process is supported by a homemade tool based on CasperJS and PhantomCSS. And all scripts are written in JavaScript. At the end of the session we can discuss if the created code is spotless clean.

Duration: 45 mins
Level: Beginner
»
agile-tools  
×
»
45_mins  
×
demonstration  
×
beginner  
×

bdd  
×
tdd  
×
frontend  
×
2 months ago by Frans Overbeek

Vineet
Vineet
Cook your Product better : story map and no estimate is the new recipe
Vineet
Vineet

I'll share my experience on how we shipped products faster using story maps and how team's focus on smaller goals than estimates / numbers / complexities helped us achieve it. 

The session would give an insight on:

  • Aligning team with product vision 
  • Shiping features fast / faster 
  • Better product backlog management 
  • Delivering without estimation 

 

Some of our challenges / questions were:

  • Are we delivering value ? 
  • How do we know we have delivered enough for our customers ? 
  • What is our priority right now ? 
  • Do we have a bigger picture ? 
  • Aligning team with product vision
  • Is tracking numbers the right thing to do ? 
  • How fast should we ship ? What are the related challenges ? 

We solved these questions / challenges first by using story maps and then removed estimation. Story map gave a clearer picture of what's planned and what's in the next customer release. Other ideas helped us easily identify when to ship and what to ship (I'll discuss more about these in the session). 

Story map is a great way to collaboratively identify the features, prioritize them and create milestones. We used story maps as our card wall also. It was an interesting experience :) 

No estimate helps the team focus more on goals and less on numbers. It helps the team to think more about the customers and how would they use the product and less about velocity, charts and commitment. It changes team's perspective and team starts shipping a usuable product for customers. 

 

Duration: 45 mins
Level: Intermediate
2 months ago by Vineet

Shweta Sharma
Shweta Sharma
Creating Business Relevance With Lean and Agile Practices
Shweta Sharma
Shweta Sharma

Businesses are still struggling today to align their IT goals with their business ones. More often than not, IT projects are so focussed on budgets and timelines that they often miss the whole value proposition of the undertaking. 

It is important therefore that along with keeping an eye on the timeline and cost, IT partners with the business and create a product roadmap which meets the business needs. For this to happen, the backlog needs to be in conotnuous evolution and business stakeholders need to be questioned on their prioirties and often rigid requirements sets.

This is where agile and lean practices help: in getting working prototypes / products out at the earliest and failing fast if at they have to. 

The talk will seek to walk through some real life examples from self experience, of how some IT projects failed succeeded by keeping business relevance at the forefront of their priorities, the practices these projects followed and the kind of client / business enagegment they demanded and obtained.

Duration: 20 mins
Type:  Talk
Level: Intermediate
»
agile-tools  
×
»
20_mins  
×
talk  
×
intermediate  
×

  
×
2 months ago by Shweta Sharma

Yashasree Barve
Yashasree Barve
Decoding Portfolio Management in Agile Scrum Enterprise
Yashasree Barve
Yashasree Barve

Being agile enables the software development groups in Enterprises to deliver high value and high quality software with speed. However legacy applications along with the overall Enterprise landscape pose their own challenges that are outside of the scrum framework to solve.

Multiple small scrum teams though working on separate applications need to be cohesive with a big picture. As a portfolio lead, who owns multiple applications and teams related to a portfolio within an Enterprise is a Chicken in scrum terminology. The expectation from the role is that of leader, scrum master as well as an Architect providing technical and functional oversight to the teams within the portfolio. This session is about a retrospective of our work life as a Portfolio Lead who takes care of multiple scrum teams, and applications. We would like to speak about the top 3 challenges faced such as Scaling Production Support / Knowledge Retention for applications delivered through Scrum, Impact of Organizational Transformation initiatives on the scrum teams, People challenges in scrum teams and Multiple Stakeholder Expectations / Conflict Management through real life examples of our work. We would retrospect what we did, and discuss and debate what worked well, and what did not.

Duration: 45 mins
Type:  Case Study
Level: Beginner
2 months ago by Yashasree Barve

Unnat Gupta
Unnat Gupta
Calculating RoI on Agile Enablement
Unnat Gupta
Unnat Gupta

"We want to be Agile!!...

Why?

Because its cool, and its becoming a norm, it will help us to cope with changing requirements, help us deliver faster etc etc."

Isn't this a common sentiment in organizations struggling with the ever changing user/customer taste?

 

With Agile going main-stream with most organizations looking to have at least a few business critical projects run in an Agile way, the question of ROI comes up. Shifting from a traditional way of building software to an Agile way, requires change and as any good business leader would know; change is not free. Business leaders would like to understand and justify the return on Investment to make this shift. In our talk, we will be talking about how to look at the Agile process holistically and how this process affects budgeting and how early value realization can help offset the cost of change. We will also discuss stories of other in house IT shops and product houses who have made this shift and the journey they have undertaken

From our experience of working with such organizations, we have found that for these process-focused Agile adopters, much of their measurements include:

 

- how long is our stand-up?

- how long is our build?

- how many stories do we have?

- how many points can we fit into a sprint? etc.

 

From their perspective, they already have plenty of metrics. Often it's also the case that they're getting benefit, just because common sense does kick in behind the scenes, and because they're delivering more frequently as a result in the reduction of documentation, so they don't always run out of money either. That leads to bad habits, possibly, rewarding wrong practices. In this talk we want to discuss metrics we have used on the projects and have found useful. Metrics like: Cycle Time, Time to market (also called Lead Time), Collaboration, Quality (in terms of code complexity , code coverage, test pyramid) and bus factor. One thing to note is that any of these metrics alone would not provide holistic way of measuring benefit, and hence a combination of them is required.

 

Duration: 45 mins
Type:  Talk
Level: Advanced
» »
45_mins  
×
talk  
×
advanced  
×

2 months ago by Unnat Gupta