Final Schedule is now available...   |   Attend the World's First Agile Job Fair   |   Join us for Agile Art!
Naresh Jain
Score 29
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 8 months

Naresh Jain proposed:


SAMPLE PROPOSAL - Product Discovery Workshop
36
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  
×
8 months ago by Naresh Jain

Continuous Deployment for iOS Game Development
14
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
8 months ago by Naresh Jain

Scaling XP Practices inside your organization using Train-the-Trainer Model
13
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
8 months ago by Naresh Jain

Agile MythBusters
1
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
1 month ago by Naresh Jain


Naresh Jain liked:


Should we stop using Story Points and Velocity?
24
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

The Quality Assurance Journey - From Waterfall to Continuous Delivery
14
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  
×
7 months ago by Roy Nuriel

The Guessing Game - Alternatives to Agile Estimation
10
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  
×
8 months ago by Neil Killick

Distributed Product Owner Team for an Agile Medical Development
10
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  
×

8 months ago by Andrea Heck

Build Your Dreams: User Requirements Gathering with LEGO Serious Play
7
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  
×
8 months ago by Ellen Grove

Agile Coaching? Sure thing! What about Life Coaching in Agile Thinking?
7
Victoria Schiffer
Victoria Schiffer

I love being around awesome people, who build great products customers desire. 
I love learning from and together with these amazing minds. 
I love creating the right environment for teams to flourish. 
I love change, and learning from new experiences. 
I love working in Agile environments.

How about you? 
I bet there are some elements of this list why you're in Agile, too. And you can probably add even more elements to it.

The Agile Manifesto states amongst others individuals and interactions, customer collaboration and responding to change.

In our everyday life doing Agile we already respect these aspects in many ways. 
But do we practice what we preach as best we can?

I'd like to challenge your current way of thinking about people and processes. 
I'd like to challenge you to focus on you, before you focus on others. 
I'd like to challenge your current way of reflecting. 
I'd like to inspire you to go different ways. 
I'd like to inspire you to inspire others.

In Agile we're already good in improving our processes and creating well performing teams and hence building the right things in the right way. And in the Agile Manifesto's communication and collaboration piece we can even get better.
"You have not yet reached the limit of what you're capable of!" means we can always further improve. And we do follow this idea in our Agile processes, too, through continuous feedback (Retrospectives) and improvement.

And why not take it even further? Why not go "Beyond Agile"?!

Here's where aspects of Life Coaching come in handy: through also understanding and improving ourselves (how do we interact with people due to how we perceive our environment) we will even further improve communication and collaboration.

Life Coaches believe our clients know the answer. And even if Agile Coaching is slightly different than Life Coaching, I see it as very relevant in Agile Coaching, too. If we apply this in Agile, instead of giving our clients (team, colleagues) the answers, asking them powerful questions to help them be more aware of what's happening at the moment, they will find their answer for it and will have a much better commitment to making the change for themselves, their teams and the company. It's not for us to TELL them what to do, but to ASK them what's going on for themselves. Here's where I see a huge chance for improvement.

In my session I give lots of examples on how to link Life Coaching ideas to our Agile work environments. I've given the session at LAST Conference Melbourne and at the Agile Coaching Circles Meetup Melbourne. The audience was engaged and the attendees were very happy about having some new ideas on how to improve their daily work life.

Come along to be inspired by Life Coaching and thus to benefit our Agile Thinking!

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

coaching  
×
learning  
×
inspire  
×
reflection  
×
7 months ago by Victoria Schiffer

Think Like an Agilist: Deliberate practice for Agile culture
6
Jason Yip
Jason Yip

If I say, culture is important to adopting Agile, most people will just agree without even thinking too much about it.  But what is meant by "culture"?  Why is it important?

Culture is not typical behaviour; it is not what we say we value (but don't actually do).  Culture is our basic assumptions of how things work.  Culture is the logic we use to think through and respond to any particular situation.

If you imagine a pyramid, Agile practice and any other visible behaviour is on the top, stated or written Agile values and principles are in the middle, fundamental assumptions (aka culture) is at the base.

My session is intended to expose people to the base of that pyramid.

If culture is assumptions, then to understand Agile culture, we need to understand the basic assumptions of Agile.  To do this, I have created an approach called "Think Like an Agilist" that both exposes how we think through an "Agile situation" and allows us to deliberately practice "Agile culture".

The general idea is that I won't just talk about Agile culture and values, what I'll call "culture theatre", but rather expose people, who nominally consider themselves part of the Agile culture, to their underlying thought processes and assumptions, given a relatively difficult scenario.  Those thought processes and assumptions are the essence of culture (reference Edgar H. Schein).  What is interesting is noting when the thought processes and assumptions are different which indicates that there is a different culture at play.  What I've noticed is that this difference is common between novice vs expert Agilists.

Note that it isn't even about analyzing vs doing it mechanically but more about exposing what assumptions are being used to respond.

NOTE: I will be updating the attached slides as when I created them, I was framing it more as "doctrine" rather than "culture", defined as fundamental assumptions"

Duration:90 mins
Type: Workshop
Level:Intermediate
» »
90_mins  
×
workshop  
×
intermediate  
×

8 months ago by Jason Yip

Creating a Great Engineering Culture in an Agile workplace.
6
Ted Tencza
Ted Tencza

Company culture, or its DNA, is one of the most important factors to determing if a company succeeds.  Many companies claim to have great company culture.  But what does this mean, how can you know if your company has a great culture, and how can you go about improving the culture?  This talk will explore what great companies have in common, and share experiences I have had in helping to develop engineering culture during my career.    

Will also explore how Agile principles help to foster creating the best possible culture for your organization.

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

culture  
×
dna  
×
8 months ago by Ted Tencza

Agile - An Australian Journey of Cultural Change
5
Fiona Mullen
Fiona Mullen

How did one of Australia's leading financial services organisation become the biggest Agile transformation story in the Southern hemisphere and what did we learn?

The Suncorp Group leads in general insurance, banking, life insurance, superannuation and investment brands within Australia and New Zealand. The Group has 16,000 employees and relationships with nine million customers. It is a Top 20 ASX listed company with over $93 billion in assets.

In 2007, we embarked on our Agile journey of cultural change. In this talk we will cover the strategy taken, the roadblocks we came across, the mistakes we made and the achievements along the way.

You will learn how to tackle an Agile transformation, what to do and what NOT to do, where to start and what to expect and most of all what impact it will have, both negative and positive.

Today Suncorp are seen as market leaders in Agile and are known globally for the Agile Academy http://www.agileacademy.com.au/agile/ which was designed for both staff and also the external market.

The role of the Agile PMO, how to get infrastructure to work Agile, what about all those legal challenges, the cultural differences and the resistance to change? These are some of the learning we will share.

There were challenges and successes and in this honest Aussie presentation will share with you both the highs and the lows.

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

8 months ago by Fiona Mullen

Pushing a Rope: Lessons learned from implementing innovation programs at Bigcommerce and Atlassian
4
Ted Tencza
Ted Tencza

You cannot effectively push a rope, similarly you cannot force innovation to happen. You can only set up an environment where it is fostered and allowed to thrive. This is even more relevant in an Agile environment, where there is freedom to explore innovation. This talk will be a review of the lessons learned while implementing innovation programs in Agile environments at Atlassian and Bigcommerce. This session covers programs that worked (like FedEx/ShipIt/Hackathons, 20% time) and programs that failed (dedicated Innovation Team). Most importantly it will explore why certain types of programs are more successful that others.

It will also explore how Agile methodolgies and practices can help to improve the results of innovation programs. The talk will also detail some strategies for setting up a culture of innovation, and discuss the pre-requistes to creating and fostering an environment where innovation is celebrated.

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

innovation  
×
hackathons  
×
8 months ago by Ted Tencza


Naresh Jain commented:


Introducing Agile Knowledge Transfer
Vinod Sankaranarayanan
Vinod Sankaranarayanan

After more than 5 years of supporting the thetrainline.com platform, ThoughtWorks worked with The Trainline teams to transfer knowledge and context  back to the Trainline Teams.

This methodology was co-created by ThoughtWorks and Trainline as a healthy sustainable and mature way to transfer knowledge. The transition itself was about a year long and involved multiple agile concepts around remote pairing, program MVP and above all, continuous delivery and non-disruption to business through the process.

This presentation would take the audience through the experiences and learnings of the process. This session is co-presented by ThoughtWorks and Trainline (vendor and customer) and will provide an insight across multiple spectrums of delivery and business.

Duration:20 mins
Level:Beginner
» »
20_mins  
×
beginner  
×

agile  
×
build  
×
transfer  
×
transition  
×
operate  
×
8 months ago by Vinod Sankaranarayanan

Retrospectives with large projects and (or) multiple teams
15
Abhilash Chandran
Abhilash Chandran

Retrospectives are the one of the most integral components of any agile methodology.  In scrum a retrospective is typically done after each sprint. This process is simple if team is small or only one team is working on a product. The problem starts increasing exponentially when many teams work on a single product. All the teams have ideas to improve the process and production.  One team may have an entire opposite idea of another. How to bridge this gap?

Last project executed across different teams (onsite & offshore) and different departments was not a great success. How to learn from the past failures and apply it to future projects?

In this discussion, I will be talking about some the points which can be easily followed in such scenarios. 

Why did we did this?

Normally in a scrum environment we have a single team with Product Owner; they do the retrospectives within team. Team identifies the issues and work on them. Many team falls into this category. It is pretty simple

Let’s complicate this further.

  • A big product with 10 scrum team
  • Each Team has different PO

Apart from these main stake holders there are many others who are interested in the success of this application

  • Sales team
  • Documentation team
  • UI design team
  • Architecture and performance team

In such a scenario, a retrospective at team level will be effective only at granular level. But it leaves a gap in few areas; it helps to bring all the teams together for one big retrospective

  • Apply the improvements made at each team level to the whole program
  • A team's retro action item against the process followed by another team can be discussed at a higher level to find an optimal solution
  • Sometimes two team's retrospective action items may be contradictory. This gathering may point a third solution
  • Sr Product owners and manager will get all the teams together. A common focus and improvement plan can be shared across teams.
  •  All team gets to know about the key concerns at the program level and with other teams.
  • Ultimately it gave a feeling of one big family.

My experience

Last large retro organized in our group was a big success. The sales team & architecture team had many ley lessons to take back from this meeting.  Many issues were bought out which could have been solved with better co-ordination across team.  Concrete action plans were made by team for the subsequent release.  Some of the key findings were shared across other program teams also.

Duration:20 mins
Level:Intermediate

Agile metrix: How do you measure the success of your agile implementation?
12
Tania van Wyk de Vries
Tania van Wyk de Vries

Humans are creatures of habit and agile is really challenging that part of our existence everyday. I have seen many teams thinking they now get agile and they take what they learned and just practice it everyday without really reflecting on where they are at or the fact that they are not really moving forward. So in order to say your teams and organisation are really becoming more and more agile everyday you need some metrix to measure against.

 

The collection of the metrix are 2 fold:

  1. Metrix are tracked through the agile project management tools teams use. We have defined the below set of metrix to interrogate our data to tell us how we doing.
  2. Some of the metrixs are done by getting feedback from teams and clients through surveys.

 

Some of the metrix include:

  1. Measurement of quality
  2. Measuring customer satisfaction
  3. Measuring team happiness
  4. Measuring continuous improvement in process and technical practices
  5. Measuring time to market
  6. Measuring ROI
  7. Measuring productivity
  8. Measuring overall project progress
  9. Measuring change and improvement

 

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

agile  
×
agile-metrix  
×
8 months ago by Tania van Wyk de Vries

Automate across Platform, OS, Technologies with TaaS
1
Anand Bagmar
Anand Bagmar

"TaaS" is an open-source product that allows you do achieve the "correct" way of doing integration testing across a variety of products via Test Automation.

Typically in organizations, there are multiple projects / products. Many organizations like to have a common Test Automation solution across these products in an effort to standardize the framework.

However, this is not a good idea! Each product should be tested using the tools and technologies that are "right" for it. Yet - these different products talk with each other and you need to test the integration between them in an automated way.

Duration:45 mins
Level:Advanced
»
beyond-agile  
×
»
45_mins  
×
demonstration  
×
advanced  
×

taas  
×
8 months ago by Anand Bagmar

Transformation Vs Adoption
Ebin John
Ebin John

This is a talk about how to identify and differentiate between Transformation and Adoption. Many change agents and companies are using this term interchangeably. This talk is a sincere effort to bring out the subtle difference between the two.

We will also discuss about some advantages and disadvantageous of Adoption and Transformation. We will also look at some criteria to select a suitable model that can work for you. The discussion will be mainly based on Schneider model and impact of organization culture on change management.

I would like to share the way we have changed our transformation pattern after learning about the impact of the culture. Will discuss about the best practices as well as challenges we face now.

Duration:20 mins
Level:Intermediate

When Agile becomes Fr-agile..learn your lessons the fun way!
Karthik Sirasanagandla
Karthik Sirasanagandla
So you have heard of "Code Smells". Did you hear of "Agile Smells"? Yes or No; then this session is for you (us).
 
In this session, Karthik intends to talk about the very many things that go wrong in companies that attempt to be or become Agile.
But fault-finding is the easiest thing. Can Karthik provide concrete solutions? Yepp, he intends to share the solutions as well for most if not all the problems.
And in same breadth seeks to know what others has to offer from their experience.
 
Piquing your interest? Are you wanting to get a taste of some of the Agile smells? Below are some of them:
* Belated Stand-ups
* Non-participative stand-ups
* War-zone Retrospectives 
* Unfruitful Sprint planning meeting
* Zero-Test development
* Inverted Test Pyramid development
* Gate-keeper QAs
* Hierarchical Roles
* Velocity Driven Development
 
Duration:45 mins
Type: Talk
Level:Intermediate
» »
45_mins  
×
talk  
×
intermediate  
×

code-smells  
×
design-smells  
×
anti-patterns  
×
7 months ago by Karthik Sirasanagandla

From Practitioner to Coach
Aman King
Aman King

Are you an Agile Practitioner? Or are you responsible for Agile transformation?

Organizations that have begun their Agile journey welcome the guidance of an experienced Agile Coach. But external guidance cannot continue indefinitely as the only way to scale Agile.

If you are in an Agile team, are you prepared to take on the coaching role for other teams once your Agile Coach moves on?

If you are a manager, are you looking at grooming in-house coaches to scale and self-sustain transformation?

The transitioning of practitioners into coaches can be key to your Agile journey. Individuals get to build on their potential, while the organization becomes more self-reliant.

This session explores my personal journey from practitioner to coach. It should help you too in taking that first jump into the role of a coach. I will share real-world examples of dealing with on-the-fly situations, and of preparing upfront where possible. I will recommend resources, and mention handy techniques that should be in a coach's toolkit. The session essentially provides a kick-start for first-time coaches.

Duration:20 mins
Level:Beginner
8 months ago by Aman King

Build - Measure - Learn : Without spending a fortune
Nikhil Joshi
Nikhil Joshi

At times we have great product ideas but the biggest barrier to entry lies in answering few questions such as:

- How do I define and validate Problem hypothesis, Solution hypothesis and Underlying assumptions?

- How do I quickly setup a platform for people to register their interest?

- What will keep the potential customers engaged, excited until the first release (or beta) is out?

- How do I get feedback from the early adopters?

- And eventually when I have answers to some of these questions, how do I make a decision to persevere or pivot?

If you've faced a challenge while answering any of these questions while building/validating your product idea, this session is for you. We'll look at tools and techniques to validate the product hypothesis early-on without spending months or fortunes. We'll also look at a case study to highlight how some of these tools, techniques helped us validate our product idea.

Duration:20 mins
Level:Beginner
»
beyond-agile  
×
»
20_mins  
×
beginner  
×

lean-startup  
×
mvp  
×
bml  
×
8 months ago by Nikhil Joshi

Using a modern web framework for big enterprise agile project
2
Mushtaq Ahmed
Mushtaq Ahmed

At ThoughtWorks, a 50-people team is building a marketing website backend for one of the largest consumer electronics brands in the world. We are Play-Scala as our web framework which allows us to design the application in a very different but powerful ways. This experience based talk will talk about these differences, emphasizing on two of them: "Dealing with concurrency without threads" and "Dependency resolution with constructor injection".

Dealing with concurrency without threads
- The backend is end to end non-blocking with highly concurrent architecture
- Each page consists of 20+ reusable snippets, so each page request translates into 20+ outbound web service calls to get data for the snippet data in parallel
- Posting data involves download/upload of large images from/to remote services, also done in parallel
- We will show you how Scala Futures, Play and ReactiveMongo functional programming paradigm allows us to do all this without blocking any thread or managing thread-pools by hand

Dependency resolution with constructor injection
- Dependency injection is considered essential for designing applications that are easy to test. Usaully, dependencies are specified as constructors parameters
- Scala traits allow us to get rid of constructors by wrapping classes and their factories inside components that in turn can depend on other components, this enables a compile time mechanism for dependency resolution which is very flexible
- We will show examples of this pattern, its effects testing without external DI frameworks

We will briefly talk on how functional programming style in general helps with testing and software delivery on agile projects. Finally, we will also cover the pain-points these approaches bring out, and argue if it is worth to pay that cost.

 

 

Duration:20 mins
Level:Advanced
» »
20_mins  
×
demonstration  
×
advanced  
×

play  
×
scala  
×
concurrent  
×
non-blocking  
×
parallel  
×
traits  
×
7 months ago by Mushtaq Ahmed

Changing our Rhythm: Our Ongoing Journey towards Continuous Delivery
13
Sreerupa Sen
Sreerupa Sen

Annual software release cycles cramping the agility of the team? Too many hot fixes reducing the efficiency of your organization? Customers waiting impatientlyfor  the next cool features hot off the press? These are some of the painful and common problems faced by development teams worldwide. In today's world, most things get outdated or out-of-fashion very fast - and software is no different. Users cannot afford to wait for the next cool set of features for a year. They want a steady stream of cool new features that they can adopt and use immediately.

My team follows a development model that we like to call Open Commercial Development - where we're always connected to our stakeholders, our plans are out in the open, and we're always gathering feedback and reprioritizing. We used to have yearly releases of our product - a sort of big bang release with a host of new featres. Based on our stakeholder interactions, however, we figured that our software delivery wasn't agile enough for our customers. Users wanted new features incrementally throughout the year. They especially didn't want to wait a year for a feature that they'd requested that was critical for their business.

So began our journey to Continuous Delivery - an interesting one for sure. It's not easy to deliver new features, manage technical debt, collaborate with users and incorporate their feedback into the new features - once every quarter. To do it consistently, with quality and on time, you need to have a framework in place - a combination of planning, process, automation and team organization - that lets teams focus on the right things to get to DONE DONE for their new features, and at the same time manage their quality and tecnical debt. Over the past year, we like to think that we've put that framework in place, and that is what I'd like to talk about in this session.

Duration:20 mins
Level:Beginner
» »
20_mins  
×
beginner  
×

7 months ago by Sreerupa Sen