Proposed (4)
Liked (42)
Commented (106)
Naresh Jain
Score 612
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  
×
3 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  
×
3 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:


Arunraj R
Arunraj R
Applying Lean Concept in Agile: Lean-Agile Methodology
Arunraj R
Arunraj R

Applying Lean Concept in Agile: Lean-Agile Methodology

Lean Agile has been the hottest topic in town for a while. We are familiar with Agile, but what is Lean Agile?

Lean principles were first introduced by Toyota and it was followed only in the manufacturing sector, but it got attention from the software industry after Tom and Mary Poppendieck wrote a book named “Lean Software Development: An Agile Toolkit

Lean-Agile in Software development focuses on 7 key principles:

1. Eliminate Waste:

Nobody works to create waste, but some wastes are obvious that we fail to notice and which can be avoided. Toyota defines three types of waste ‘Muda‘ (meaning unproductive), ‘Mura‘(inconsistency, unevenness) and ‘Muri‘(unreasonableness, over-burden).

In software development the possible wastes are

  • Unnecessary code or functionality
  • Delay in the process
  • Unclear requirements
  • Constantly changing requirements
  • Slow or ineffective communication
  • Partially done work
  • Defects and quality issues
  • Task switching

2. Build Quality In:

Agile methodologies like Scrum, XP, TDD, Pair Programming etc. focuses more on Quality. Simple steps to bring in Quality process in software development include:

  • Constant feedback – Inspect and Adapt
  • Minimize time between stages
  • Frequent integration
  • Automation
  • Test cases, Test Script etc.

Quality is not an act, it is a habit. Quality is everyone’s responsibility and focusing on it reduces cost, time and effort significantly.

3. Create Knowledge:

Knowledge is key in software development. Some of the steps to create knowledge in our environment are

  • Pair programming
  • Code reviews
  • Documentation
  • Thoroughly commented code
  • Knowledge sharing sessions
  • Github
  • Training etc.

4. Defer Commitment:

The term “Defer Commitment” can be easily misunderstood. What it means is to “Decide as late as possible”
Decide as late as possible means to keep your options open for as long as possible and get inputs as much as possible. By the time you need to decide, you will have many possible paths to choose from. That’s the reason in Agile Scrum, sprint planning happens just before the start of Sprint.

But keep in mind, deciding too late will delay the team and project success will become difficult. In deciding too early there is the likely risk that the plan changes in between due to newer circumstances.

5. Deliver Fast:

Deliver as fast as possible – Speed to market/First mover advantage is undoubtedly a competitive advantage. Instead of over-engineering or enhancing the product in terms of software architecture, design or business requirements, launch a simple product to get feedback from real end users, which can in turn be used to enhance the product.

Simple steps to ensure fast delivery are

  • Have the right people
  • Have right and clear plan
  • Keep product simple
  • Work as a team
  • Eliminate waste
  • Build quality in

6. Empower People:

Empowering people in workplace include:

  • Assign ownership
  • Respond to people promptly
  • Listen attentively
  • Hear opinions
  • Empathy for other views

Empowering people doesn’t mean accepting whatever they say, but trying to discuss pros and cons as a team and make a decision. Important thing is to empower people without losing control of the outcome.

7. Optimize The Whole:

A lean organization seeks to optimize the whole value stream; not just individual people, teams or departments. A team which is organized in such a way that it has everything to deliver has distinct advantages like

  • Responsibility and accountability
  • Leading to better commitment
  • Quality and innovation
  • Team spirit and cooperation
  • Shared goals
  • Better team, Better product, Better organization

It’s good to follow Agile but let’s be better by following Lean Agile.

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

lean-agile  
×
1 month ago by Arunraj R

Praful
Praful
Agile Maturity Model - Scaling Agile.
Praful
Praful

Every organization has it's own set of issues in scaling agile and there is no one size fits all models/framework. By far there are lot of framework like SAFe and supporting tools available to help scale agile. This presentation is more of an experience report on my journey with Agile and Scrum adoption program within yahoo bangalore and the kind of challenges around it and the ways those were dealt. I would be focusing more on the AMM (Agile Matruity Model) that I worked upon internally and the various stages/phases with in them which helped the Agile/Scrum teams to understand how well the progress is with them in agile adoption across the organization and what value in each phase it brings into the team and back to organization. I would describe the need for a model to be developed and what it is all about during the presentation. 

What to look or would be unique (I guess) in this talk would be the simplicity of the model and solving a complex problem. Simplicity in a way is to believe this model would be generic and most of the organizations would be able to relate to the real world problems while scaling agile.

Duration: 20 mins
Type:  Talk
Level: Intermediate
1 month ago by Praful

Gautam Rege
Gautam Rege
Don't test your code!
Gautam Rege
Gautam Rege

Testing is overated. Let's correct that statement - "Manual Testing is overrated". In this this talk, I plan to take you on whirlwind tour of why an Agile outfit does not need manual testing at all and how to get fantastic Quality Assurance without manual testing.

In this talk - I outline a agile process with a difference - everyone is a developer and a tester. However, there is no dedicated QA people. In fact, this process does not require anyone other than the developers and one process/product owner.

Development using a central repository like Github that is integrated with a Continuous Integration service (like Travis, CircleCI or Semaphore) and further integrated with a Code Quality checker like Code Climate or Pull Review is part of the automation trick. Then comes the development processes like pull request between branches (enabling peer code review) and Automated Deployment to a staging server.

Finally, the pixel perfection or meeting product specificaiton via Project Management tools (which are integrated with the Code repository) gives the product owner (or the client) complete confidence in not just the functionality but also the quality of the code. 

This approach can be applied to evolving products too and I discuss how to work in short sprints that always keep changing and guarantee that "The product owner gets the money's worth and the development team gets their works worth!".

 

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

processes  
×
testing  
×
3 weeks ago by Gautam Rege

Ritu
Ritu
Collaboration among Agile Scrums to Achieve X velocity
Ritu
Ritu

Once basic Agile rules and discipline framework is set then following is regularly required

- Freqent reflects to ensure feedback is taken and each step is improvised further

- Find imediments and work towards goal of achieving 2x, 4x velocity by optimizing the non performing steps in between

This can not be done just by a thought.

- Proper study of project/product and it's market required

- tools to be customized to suit the team

- Skill level required

- Team should work towards win-win in all 4 areas (professional, personal, self, community).

- Very open culture to allow small and frequent failures

- working towards a common goal

Will share a case study and what all best practices helped achieve this. Although there are still many non productive areas which need fine tuning and this would be a ongoing journey.

Duration: 45 mins
Level: Advanced
» »
45_mins  
×
advanced  
×

2 weeks ago by Ritu

Arvi Krishnaswamy
Arvi Krishnaswamy
Lean Startup in Practice - Lessons Learnt from an MVP
Arvi Krishnaswamy
Arvi Krishnaswamy

Rovio tried 51 games before hitting upon Angry Birds. We tend to hear a lot more about the chart busting numbers of Angry Birds than the struggles of the previous 51 games. In my opinion, their success was the journey of the 52 experiments, and not just the final one.

We at Levitum recently had learnings from an MVP that we put out, and experiments that we ran. In the spirit of openly sharing how I’ve tried to apply Lean Startup principles to a new venture, I’m going to outline how we went about things, and what I’ve learnt.

More details on the experiments are available in my blog post http://arg0s.in/what-we-learnt-from-a-failed-mvp.html. My blog post made page one of HackerNews, has had over 20,000 visitors, and has been cited by various practitioners as an example of how to apply lean startup in practice.

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

lean  
×
lean-agile  
×
startup  
×
2 weeks ago by Arvi Krishnaswamy

Sneha Kadam
Sneha Kadam
Lean Machine
Sneha Kadam
Sneha Kadam

After revolutionizing the automobile industry, Lean principles have been successfully applied to different knowledge areas including software development. This workshop is intended to master Lean concepts like Waste, Push&Pull systems, systems thinking, Kaizen etc. & practicing cross-functional collaboration, self-organisation and safe-fail experimentation! In this interactive game, the participants will work in a small production lines, experiencing problems and applying Lean practices to overcome them.

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

lean-agile  
×
1 week ago by Sneha Kadam

Vinod Kumaar R
Vinod Kumaar R
Build it like sports teams
Vinod Kumaar R
Vinod Kumaar R

Is it easy to get a crash course in football by Pele or Maradona for a week and produce a world cup winning football team?

Answer is NO. Then why do lots of people in the corporate world think of hiring scrum trainers & expert developers to train their team for a week and then expect their team to undergo a transformation at a magical scale?

German football team made it a point to transform their team and it took them a lots of years before they were able to reach the pinnacle. A quick side by side comparison of what is causing agile transformation to fail.

Vision

Football: Someone was there owning this entire transformation, the German football association spent a lot of time identifying talent in their teens and groomed them.

Office: In the corporate world switching jobs every few years have become common, but there is no passing on of the context, resulting in the new person taking charge, starting from all over again, as well as frustrating existing good performers who have to rebuild the perception.

Infrastructure

Football: Players expecting state of the art training facilities, fitness programs and new shoes are not a luxury, it is a necessity.

Office: Computers have become so cheap compared to the salaries, yet the policy of providing the best tools and good work environment are archaic.

Coach vs Management

Football: Coaches are given their due powers to help the team achieve the goal. It is very easy for anyone to comment on how professionals should play their game, there would be no use adhering to the metrics if the team cannot win. Winning is the only measure for management.

Office: Often coaches are seen as part of the management or management tries to heavily influence coaching which results in a team which will work either for metrics or to please higher ups without the actual result that it had aimed for.

Training

Football: Just the ability to kick the ball does not make a footballer. Training will be introduced to increase physical strength & stamina, better mental wellness, injury prevention, tactics and strategy.  A heavy investment is made in the training facilities.

Office: In the software industry a generation is about 2-3 years. Computer science degrees are nowhere near what is state of the art in the industry. At many places the on boarding process is either very shallow or not up to date with the recent developments, leaving people to learn most of the things hard way. Given too many things to learn and the information overload, this results in inefficient learning and application of knowledge on the job. We need to prepare people to find answers that are not available on Google.

Team composition

Football: Rookies don’t learn by watching greats from the bench, instead they play along with the veterans. Every sports team makes sure to have the right composition with a mix of rookies, emerging players and veterans. That is how they sustain a winning team.

Office: Architects and Leads often do not code or are not part of the team every day, this means that most of the time the team just looks up to for advice or waits for reviews. There should be a good mix of people at all experience level so that there are enough people to try new things, enough people who have mastered few things and enough people who challenge change.

Above all – Persistence

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

1 week ago by Vinod Kumaar R

Deepak Dhananjaya
Deepak Dhananjaya
Exploring dynamics of Manager - Agile Coach Relationship
Deepak Dhananjaya
Deepak Dhananjaya

There is often a situation between managers and the coaches where the Managers think the coaches intervene in the delivery, while the coaches argue the managers do 'command and control'. Often, these two parts of system are seen on opposing sides. We at AgileSattva, believe that every component in the system has a role and there is a relationship between all the stakeholders. [updated] The key important stake holders are "Coaches" and "Managers".[/updated] This relationship has important contrbituion and impact towards transforming the teams/systems.

[updated] In our experiences working with Agile Coaches (as part of supervision of their work to resolve their stuckness), we find a pattern in the way they relate to Leadership and Management group of the teams. In bringing our observation to the awareness of coaches, their thinking pattern changes and are able to move towards effective transformations. [/updated]

In this workshop, we would invite the participants to explore the dynamics of this relationship and its impact on the team/ system through activities, reflective exercises and discussions. 

[updated]We use Transactional Analysis (Eric Berne, 1961) as a framework to understand this relationship. We may use Psychodrama (Jacob L Moreno) activities with the group to explore the dynamics. [/updated]

[updated 30.10.14] 

Group Imago is defined by Berne in 1966 as ‘‘a mental image of the dynamic relationships between the people in the group, including the therapist; idiosyncratic for each individual patient". This is used in organizations where the group refers to the teams, therapist could be consultant/manager/coach and individual patient are member of that team. 

The important part of using this model in Agile coaching is to bring out the "unconscious thinking" of how Coaches/Managers see the team and themselves in relation to the team (system). 

The mode of activity could be through drawings/arrangement of their mental image of the team and self on paper or a field (where we could use floor or tables).  More details here may set people be conscious, hence would be happy to share it over the call/mail. 

Psychodrama is a school of group therapy also used for Organizational Development to build cohesive teams, analyze difficult situations, setting up value system in the organization etc. sociometry is the study of social relations between individuals—interpersonal relationships. The activity is 'setting up scene' with a situation (difficult situation) a person (coach/manager) is facing at their work place. The setup could be again using toys/real people representing people from their situation. This is also to explore the way the interaction is happening in that situation. This gives a wholistic picture of the system (unconscious thinking of people in the system). sociometry involves techniques for identifying, organizing, and giving feedback on specific interpersonal preferences an individual has. For example, in a psychodrama sociometry session, we may want to explore the cold war between team members that has been unseen or ignored from long time.  [reference in wikipedia]

Like I mentioned, both the activities are tools to bring out the unconscious thinking to the conscious, so the activity evolves as we are facilitating. 

[/updated 30.10.14]

 

Duration: 60 mins
Type:  Workshop
Level: Beginner

Howard Deiner
Howard Deiner
Agile/Lean Startup IT Portfolio Management - No Longer Oxymorphic!
Howard Deiner
Howard Deiner

Centralized development resources are commonplace in many of the late adopter organizations that struggle with Agile transformations.  These centralized development resources tend to be doubly damming on the organization trying to become Agile: they lead to project thinking and management (rather than product thinking and leadership), and they lead to small incremental product development optimizations (rather than broad scale new and disruptive product breakouts).

This session focuses on the mechanics of a portfolio management technique intended to guide the organization into the use of Lean Startup thinking to challenge Product Managers with, paired with the right type of fiscal rigor to make CFOs happy.  Examples of how a Lean Startup Business Model Canvas can be paired with lightweight cost projections and revenue forecasts will be presented, with encouragement for organizations to specialize the artifact to suit their particular needs. 

Duration: 45 mins
Type:  Talk
Level: Intermediate

Howard Deiner
Howard Deiner
Getting Past the 50+70=120 Calculator in Cucumber: 12 Things to Work On
Howard Deiner
Howard Deiner

With the best of intentions, people have flocked to Behavior Driven Development by way of Cucumber over the past few years, and that’s a great thing!  But just like dieting, where great things can fall to the wayside from the temptation to indulge in wonderful desserts, BDD can fall to the wayside due to pressure to deliver more and more functionality Sprint over Sprint.  Many times, Cucumber becomes just a way to automate a bunch of tests, which isn’t bad by itself, even if it doesn’t get to the core of how Product Owners and the Delivery Team should start to communicate.  But without constant attention, that great garden of creeping Cucumber vines becomes a tangled mess that slowly withers away under massive technical debt.

Howard will guide you through 12 of the most important issues to work on in your garden of executable requirements.  We’ll discuss and explore topics ranging from the easy to comprehend (such as imperative versus declarative style) to the difficult to deliver (such as how to keep Gherkin driven Selenium WebDriver tests working dependably through the use of advanced ExpectedCondition techniques).  By the end of the session, you should have plenty to indulge in on a healthy diet of BDD!

Duration: 45 mins
Type:  Talk
Level: Intermediate
1 week ago by Howard Deiner