Following is the profile of the registered participants:

@ Asia’s Premier Agile and Lean Conference

A refreshing yet intense 3-day conference where you can:

• Learn from over 135 expert practitioners and 120 hand-picked sessions.
• Network & share your knowledge and experience with over 700 eager international delegates from literally every software company practicing or exploring Agile & Lean.
• Explore diverse and interesting solutions and contribute to the future of Agile software development.

AGILE INDIA 2012 (http://agile2012.in/)
17, 18 & 19 February 2012
Le Meridien, Bengaluru.

REGISTER:  http://agile2012.in/registration (register before 12 Jan & save Rs. 1000)

——————————————–

LEARN

Over 120 hand picked sessions by expert practitioners on Agile, Lean and Lean-Startup covering:

• Agile Development Practices
• Enterprise Agile
• Leadership and Organizational Transformation
• Agile & Outsourcing
• DevOps
• Culture, People & Teams
• Lean Principles & Practices
• Agile Product Management
• Coaching & Mentoring and
• Lean Startups.

Catch up on the latest Research on Agile and Lean practices presented by top international researchers.

Also get a unique opportunity to interact with our 10 specially invited Thought Leaders from our Industry.

Check out the full conference program.
Don’t forget to see the detailed stats about the program.

NETWORK

• Interact with 135 expert practitioners & speakers from 18 Countries.
• Meet all the thought leaders, who put together this wonderful 3-day program (over the last 6 months).
• Exchange ideas with 700 international delegates from literally every successful software company practicing Agile & Lean.

See profile of registered participants.

EXPLORE

Come explore the diverse, interesting solutions Agile & Lean practitioners have discovered to make software development enjoyable. Discover a gamut of problems and solutions practitioners are tackling with their agile adoption.

In the last 10 years, Agile & Lean has fundamentally changed the way successful software companies built software solutions. We’ve solved many core problems, but there are more, interesting problems that need to be solved. Share your thoughts and explore the future of software development.

Participate in an exclusive Open Space, which is part of the Research Cafe.

SPONSOR

Showcase your brand to Asia’s largest Agile and Lean software development conferences delegates. Sponsorship details: http://agile2012.in/sponsors/

Come, be part of the new generation of Agile & Lean Thought Leaders.

SPREAD THE WORD!

Blog: http://blog.agile2012.in/
Facebook: https://www.facebook.com/agileindia
Twitter: #AgileIndai2012

They believe that enduring organizational change is possible only if individuals alter their attitudes and behaviors first. But they’ve come to understand that it’s not possible to generate lasting cultural change without deeply involving the whole organization and its senior leadership.

To achieve better Productivity, they encouraged organizations to make two fundamental shifts in the way it manages employees:

1. Stop expecting people to operate like computers—at high speeds, continuously, running multiple programs at the same time—and to recognize that human beings perform best and are most productive when they alternate between periods of intense focus and intermittent renewal.
2. Move from trying to get more out of employees and instead to invest in systematically meeting their four core needs, so they’re fueled and inspired to bring more of themselves to work every day.

Four core needs are:

1. Physical health: achieved through nutrition, sleep, daytime renewal, and exercise
2. Emotional well-being: which grows out of feeling appreciated and valued
3. Mental clarity: the ability to focus intensely, prioritize, and think creatively and
4. Spiritual significance : which comes from the feeling of serving a mission beyond generating a profit.

Several companywide initiatives can help employees boost their energy in the four core areas. For example companies can subsidize healthy meals and a salad bar at their on-site restaurant that’s open to all employees. Hire a dietician on staff and employees can get free consultations. Build new, fully equipped gym and created a large open, grassy commons area where people can hang out and relax. To help employees recharge themselves on a spiritual level, companies can offers its employees paid time off each month to volunteer their services to nonprofits and organizes specific volunteer opportunities for them.

Original Article: The Productivity Paradox: How Sony Pictures Gets More Out of People by Demanding Less

Benjamin Bloom, a pioneer who broke this myth found out that:

“All the superb performers, he investigated, had practiced intensively, had studied with devoted teachers, and had been supported enthusiastically by their families throughout their developing years.”

Later research, building on Bloom’s study revealed that the amount and quality of practice were key factors in the level of expertise people achieved.

Consistently and overwhelmingly, the evidence showed that:

“Experts are always made, not born.”

The journey to truly superior performance is neither for the faint hearted nor for the impatient. The development of genuine expertise requires struggle, sacrifice, and honest, often painful self-assessment. There are no shortcuts. It will take many years if not decades to achieve expertise, and you will need to invest that time wisely, by engaging in “deliberate” practice; practice that focuses on tasks beyond your current level of competence and comfort. You will need a well-informed coach not only to guide you through deliberate practice but also to help you learn how to coach yourself.

One study showed that psychotherapists with advanced degrees and decades of experience aren’t reliably more successful in their treatment of randomly assigned patients than novice therapists with just three months of training are. There are even examples of expertise seeming to decline with experience. The longer physicians have been out of training, for example, the less able they are to identify unusual diseases of the lungs or heart. Because they encounter these illnesses so rarely, doctors quickly forget their characteristic features and have difficulty diagnosing them.

Practice Deliberately: Not all practice makes you perfect. You need a particular kind of practice – “deliberate practice” – to develop expertise. When most people practice, they focus on the things they already know how to do. Deliberate practice is different. It entails considerable, specific, and sustained efforts to do something you can’t do well – or even at all.

Let’s imagine you are learning to play golf for the first time. In the early phases, you try to understand the basic strokes and focus on avoiding gross mistakes (like driving the ball into another player). You practice on the putting green, hit balls at a driving range, and play rounds with others who are most likely novices like you. In a surprisingly short time (perhaps 50 hours), you will develop better control and your game will improve. From then on, you will work on your skills by driving and putting more balls and engaging in more games, until your strokes become automatic: You’ll think less about each shot and play more from intuition. Your golf game now is a social outing, in which you occasionally concentrate on your shot. From this point on, additional time on the course will not substantially improve your performance, which may remain at the same level for decades.

Why does this happen?

You don’t improve because when you are playing a game, you get only a single chance to make a shot from any given location. You don’t get to figure out how you can correct mistakes. If you were allowed to take five to ten shots from the exact same location on the course, you would get more feedback on your technique and start to adjust your playing style to improve your control. In fact, professionals often take multiple shots from the same location when they train and when they check out a course before a tournament.

Computer gaming is an excellent example where I’ve seen people practice deliberately to get better. They focus on what they can do well, but they also focus on what they can’t do well. Most importantly, when practicing, the gamer is not just mindlessly playing. It’s a very thoughtful, deep, dedicated practice session.

War games serve a similar training function at military academies. So do flight simulators for pilots. Unfortunately in software development, very few people practice deliberately.

Genuine experts not only practice deliberately but also think deliberately. The golfer Ben Hogan once explained, “While I am practicing I am also trying to develop my powers of concentration. I never just walk up and hit the ball.”

Deliberate practice involves two kinds of learning:

1. Improving the skills you already have
2. Extending the reach and range of your skills.

“Practice puts brains in your muscles” – Golf champion Sam Snead

The enormous concentration required undertaking these twin tasks limits the amount of time you can spend doing them.

How long should you do deliberate practice each day?

“It really doesn’t matter how long. If you practice with your fingers, no amount is enough. If you practice with your head, two hours is plenty.”

It’s very easy to neglect deliberate practice. Experts who reach a high level of performance often find themselves responding automatically to specific situations and may come to rely exclusively on their intuition. This leads to difficulties when they deal with atypical or rare cases, because they’ve lost the ability to analyze a situation and work through the right response. Experts may not recognize this creeping intuition bias, of course, because there is no penalty until they encounter a situation in which a habitual response fails and maybe even causes damage.

Many research show the importance of a coach/mentor in deliberate practice. Some strongly favor an apprenticeship model. However one needs to be aware of the limitation of just following a coach or working alongside an “expert.”

Statistics show that radiologists correctly diagnose breast cancer from X-rays about 70% of the time. Typically, young radiologists learn the skill of interpreting X-rays by working alongside an “expert.” So it’s hardly surprising that the success rate has stuck at 70% for a long time. Imagine how much better radiology might get if radiologists practiced instead by making diagnostic judgments using X-rays in a library of old verified cases, where they could immediately determine their accuracy.

All an all, “Living in a cave does not make you a geologist” .i.e. without deliberate practice you go no where.

Original Article: The Making of an Expert

Original Article: 11 Who Died in 2011 (And Were Not Named Steve)

Details: Nine Things Successful People Do Differently

Details: Six Keys to Being Excellent at Anything

We’ll be hosting total of 12 Stages, 120 Sessions, 125 Speakers from 18 Countries. Detailed stats below:

With a wide variety of session types:

63% of session targeted at practitioners:

Large number of 60 and 90 mins sessions:

We’ve 120 speakers selected through the submissions system and 5+ invited speakers:

We had an extremely good team of 111 program committee members from 21 Countries who reviewed all the submission and selected the conference program:

That’s right! We have over 100 members from 21 countries.

Early-bird registration has started in full swing.

Sponsorship detail are published for interested companies.

We are reviewing all the awesome proposals submitted by experts from around the world. We should have the program live by end of Nov.

Most of these conferences were small to medium scale conferences in the range of  50 to 375 delegates.

Why we never organized larger conferences? Was it because we were not capable of organizing them? Or was there something stopping us from doing so?

Personally I prefer organizing small scale conference over large scale conference for the following reasons:

• In my experience the quality of interaction and experience speakers & participants have is inversely proportional to the size of the conference.
• Cost to run the conference exponentially increases with size. As the size increases:
• we need a bigger venue, which does impose a significant cost.
• overall logistics becomes lot more complex. Need extra planning and coordination. Again increasing cost and making the overall plan less adaptive.
• the participant price has to be increased – which means, most participants won’t be able to self fund their registration. They’ll depend on their companies to sponsor them. This leads to many people who actually do get sponsored by their companies are the ones less inclined to learn at the conference. Which again impacts the overall quality experience of others participants.
• we become more dependent on the sponsors. The more we are dependent on sponsors, more their demands. Inevitably leading to compromising the conference. Sometimes sponsors want speaker slots (esp. keynotes) for sponsorship. Also they further complicate the logistics.
• Are less inclusive from smaller companies and individual’s point of view. Cost is one aspect, but also because there would be a larger number of participants from big companies, the interactions at the conference take a very different dynamics.
• Right from the beginning, large conference have a fear of not attracting enough delegate and sponsors. To mitigate that risk, most large conference programs are filled with Big names. Who mostly present the same old topics which have been beaten to death over a decade. We like it or not, the overall program tends to be more focused on basics (least common denominator) and seems to attract mostly beginners who are willing to pay that kind of money. Innovative and disruptive ideas are mostly neglected. Because they would really be disruptive for the audience.
• Because of the previous point, the real practitioners, doing really meaningful work, tend to shy away from such conferences. Again leading to poorer quality conference.
• Marketing and Branding effort: Large conferences need huge effort and funds to market and brand themselves. Smaller conferences are mostly marketing and branded through word of mouth and these days with social media.
• The effort and time it takes to organize one large, centrally located conference, in that much time, we could easily organizer 3-4 smaller, more local conferences. Smaller conferences surely reduce the costs for participants. Smaller conferences encourages more of a distributed, sustainable, local community.

I could spend rest of my sunday afternoon thinking about this and I’m sure I’ll come up with 10 more points against large conference. Having said that, large conference do have some clear advantages that smaller conference cannot achieve. the splash, the penetration, cross pollination, etc. etc.

However I think its clear, at least to me, why I prefer smaller conference.

It cool to have thought thru the issues and to have the points flushed out. But to avoid dogmatism, its always important to reevaluate your points every few years. Which is one of the reasons, I decided to help organize Agile India 2012 Conference.

http { 
    ....
    server {
        listen          80;
        server_name     www.agilefaqs.com agilefaqs.com;
        server_name_in_redirect on;
        port_in_redirect        on; 
 
        location ^~ /training {
            rewrite ^ http://agilefaqs.com/a/long/url/$uri permanent;  
        }
 
        location ^~ /coaching {
            rewrite ^ http://agilecoach.in$uri permanent;  
        }
 
        location = /blog {
            rewrite ^ http://blogs.agilefaqs.com/show?action=posts permanent;  
        }
 
        location / {
            root   /path/to/static/web/pages;
            index   index.html; 
        }
 
        location ~* ^.+\.(gif|jpg|jpeg|png|css|js)$ {
            add_header Cache-Control public;
            expires max;
            root   /path/to/static/content;
        }
    } 
}

I’ve been using this feature of Nginx for over 2 years, but never actually fully understood the different prefixes for the location directive.

If you check Nginx’s documentation for the syntax of the location directive, you’ll see:

location [=|~|~*|^~|@] /uri/ { ... }

The URI can be a literal string or a regular expression (regexp).

For regexps, there are two prefixes:

• “~” for case sensitive matching
• “~*” for case insensitive matching

If we have a list of locations using regexps, Nginx checks each location in the order its defined in the configuration file. The first regexp to match the requested url will stop the search. If no regexp matches are found, then it uses the longest matching literal string.

For example, if we have the following locations:

location ~* /.*php$ {
   rewrite ^ http://content.agilefaqs.com$uri permanent; 
}
 
location ~ /.*blogs.* {
    rewrite ^ http://blogs.agilefaqs.com$uri permanent;    
}  
 
location /blogsin {
    rewrite ^ http://agilecoach.in/blog$uri permanent;    
} 
 
location /blogsinphp {
    root   /path/to/static/web/pages;
    index   index.html; 
}

If the requested URL is http://agilefaqs.com/blogs/index.php, Nginx will permanently redirect the request to http://content.agilefaqs.com/blogs/index.php. Even though both regexps (/.*php$ and /.*blogs.*) match the requested URL, the first satisfying regexp (/.*php$) is picked and the search is terminated.

However let’s say the requested URL was http://agilefaqs.com/blogsinphp, Nginx will first consider /blogsin location and then /blogsinphp location. If there were more literal string locations, it would consider them as well. In this case, regexp locations would be skipped since /blogsinphp is the longest matching literal string.

If you want to slightly speed up this process, you should use the “=” prefix. .i.e.

location = /blogsinphp {
    root   /path/to/static/web/pages;
    index   index.html; 
}

and move this location right at the top of other locations. By doing so, Nginx will first look at this location, if its an exact literal string match, it would stop right there without looking at any other location directives.

However note that if http://agilefaqs.com/my/blogsinphp is requested, none of the literal strings will match and hence the first regexp (/.*php$) would be picked up instead of the string literal.

And if http://agilefaqs.com/blogsinphp/my is requested, again, none of the literal strings will match and hence the first matching regexp (/.*blogs.*) is selected.

What if you don’t know the exact string literal, but you want to avoid checking all the regexps?

We can achieve this by using the “^~” prefix as follows:

location = /blogsin {
    rewrite ^ http://agilecoach.in/blog$uri permanent;    
}
 
location ^~ /blogsinphp {
    root   /path/to/static/web/pages;
    index   index.html; 
}
 
location ~* /.*php$ {
   rewrite ^ http://content.agilefaqs.com$uri permanent; 
}
 
location ~ /.*blogs.* {
    rewrite ^ http://blogs.agilefaqs.com$uri permanent;    
}

Now when we request http://agilefaqs.com/blogsinphp/my, Nginx checks the first location (= /blogsin), /blogsinphp/my is not an exact match. It then looks at (^~ /blogsinphp), its not an exact match, however since we’ve used ^~ prefix, this location is selected by discarding all the remaining regexp locations.

However if http://agilefaqs.com/blogsin is requested, Nginx will permanently redirect the request to http://agilecoach.in/blog/blogsin even without considering any other locations.

To summarize:

1. Search stops if location with “=” prefix has an exact matching literal string.
2. All remaining literal string locations are matched. If the location uses “^~” prefix, then regexp locations are not searched. The longest matching location with “^~” prefix is used.
3. Regexp locations are matched in the order they are defined in the configuration file. Search stops on first matching regexp.
4. If none of the regexp matches, the longest matching literal string location is used.

Even though the order of the literal string locations don’t matter, its generally a good practice to declare the locations in the following order:

1. start with all the “=” prefix,
2. followed by “^~” prefix,
3. then all the literal string locations
4. finally all the regexp locations (since the order matters, place them with the most likely ones first)

BTW adding a break directive inside any of the location directives has not effect.

Totally we’ve received 231 submissions.

Following is the stage wise breakup of the proposals:

Following is the breakup according to the levels (very happy to see a large number of sessions in the practicing space):

Following is the breakup according to the session types: (again not surprised to see a large number of talks):

Lastly, the duration wise breakup of the sessions:

Also we’ve received 22 research papers from the following countries.
Selected papers will be published by IEEE Publications.

Also, we are happy to have totally 184 unique presenters (159 primary presenters and 38 secondary presenters.)

Currently we are reviewing all these proposals. You should see the final list by end of November.

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

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

This 180 mins tutorial 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.

Detailed Activity Breakup

1. PART 1: UNDERSTAND PRODUCT CONTEXT
• Introduction
• Define Product Vision
• Identify Users That Matter
• Create User Personas
• Define User Goals
• A Day-In-Life Of Each Persona
2. PART 2: BUILD INITIAL STORY MAP FROM ACTIVITY MODEL
• Prioritize Personas
• Break Down Activities And Tasks From User Goals
• Lay Out Goals Activities And Tasks
• Walk Through And Refine Activity Model
3. PART 3: CREATE FIRST-CUT PRODUCT ROAD MAP
• Prioritize High Level Tasks
• Define Themes
• Refine Tasks
• Define Minimum Viable Product
• Identify Internal And External Release Milestones
4. PART 4: WRITE USER STORIES FOR THE FIRST RELEASE
• Define User Task Level Acceptance Criteria
• Break Down User Tasks To User Stories Based On Acceptance Criteria
• Refine Acceptance Criteria For Each Story
• Find Ways To Further Thin-Slice User Stories
• Capture Assumptions And Non-Functional Requirements
5. PART 5: REFINE FIRST INTERNAL RELEASE BASED ON ESTIMATES
• Define Relative Size Of User Stories
• Refine Internal Release Milestones For First-Release Based On Estimates
• Define Goals For Each Release
• Refine Product And Project Risks
• Present And Commit To The Plan
6. PART 6: RETROSPECTIVE
• Each part will take roughly 30 mins.

I’ve facilitated this workshop for many organizations (small-startups to large enterprises.)

More details: Product Discovery Workshop from Industrial Logic

Techniques

Focused Break-Out Sessions, Group Activities, Interactive Dialogues, Presentations, Heated Debates/Discussions and Some Fun Games

Target Audience

• Product Owner
• Release/Project Manager
• Subject Matter Expert, Domain Expert, or Business Analyst
• User Experience team
• Architect/Tech Lead
• Core Development Team (including developers, testers, DBAs, etc.)

This tutorial can take max 30 people. (3 teams of 10 people each.)

Workshop Prerequisites

Required: working knowledge of Agile (iterative and incremental software delivery models) Required: working knowledge of personas, users stories, backlogs, acceptance criteria, etc.

Testimonials

“I come away from this workshop having learned a great deal about the process and equally about many strategies and nuances of facilitating it. Invaluable!

Naresh Jain clearly has extensive experience with the Product Discovery Workshop. He conveyed the principles and practices underlying the process very well, with examples from past experience and application to the actual project addressed in the workshop. His ability to quickly relate to the project and team members, and to focus on the specific details for the decomposition of this project at the various levels (goals/roles, activities, tasks), is remarkable and a good example for those learning to facilitate the workshop.

Key take-aways for me include the technique of acceptance criteria driven decomposition, and the point that it is useful to map existing software to provide a baseline framework for future additions.”

Doug Brophy, Agile Expert, GE Energy

Learning outcomes

• Understand the thought process and steps involved during a typical product discovery and release planning session
• Using various User-Centered Design techniques, learn how to create a User Story Map to help you visualize your product
• Understand various prioritization techniques that work at the Business-Goal and User-Persona Level
• Learn how to decompose User Activities into User Tasks and then into User Stories
• Apply an Acceptance Criteria-Driven Discovery approach to flush out thin slices of functionality that cut across the system
• Identify various techniques to narrow the scope of your releases, without reducing the value delivered to the users
• Improve confidence and collaboration between the business and engineering teams
• Practice key techniques to work in short cycles to get rapid feedback and reduce risk