XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Presenting Agile Pune 2014 Conference – Nov 21st and 22nd at Hyatt Regency, Pune

Tuesday, June 24th, 2014

We are delighted to present Linda Rising and Joshua Kerievsky, as our keynote speakers for the upcoming Agile Pune 2014 Conference. The conference will be hosted at Hyatt Regency, Pune on Nov 21st and 22nd.

The Agile Pune 2014 is a volunteer-run, non-profit event organised by the Agile Software Community of India (ASCI). The goal of the conference is to bring together Agile enthusiasts from around the world to share ideas, socialise, and work together on advancing the state of Agile/Lean Software development.

Simplicity, quick feedback cycles, systems thinking, mistake proofing, transformational leadership, building quality in, relentless improvement via inspect and adapt, evolutionary design, cross-functional collaboration, sustainable pace, self-organisation and safe-fail experimentation are some of the core tenants of the Agile and Lean mindset. They help teams embrace uncertainty and make them more change resilient. This conference is dedicated to deep-dive on these topics.

Agile Pune 2014 is a two-day conference, starting on Nov 21st (Friday), where experts and practitioners from around the world will share their experience on topics related to our theme, “Action Precedes Clarity”. The conference will host 3 parallel tracks. We also plan to host pre-conference workshops to help you get world-class training directly from our international experts at affordable rates.

If you are interested in presenting at the Agile Pune 2014 conf, please submit your proposals at http://confengine.com/agile-pune-2014

Super early bird registrations starts today. Register now at http://booking.agilefaqs.com/agile-pune-2014

To know more about the conference, please visit http://pune.agileindia.org

Important Skills for Agile Team Members

Saturday, October 22nd, 2011

To be successful in an agile environment, IMHO team members need to learn the following skills:

  • Embracing uncertainty/change and finding effective ways to deal with it.
  • Tight collaboration and communication with everyone involved.
  • Collective Ownership, Drive and Discipline to getting things done.
  • Eliminating Wasting: Mercilessly looking for waste and trying to eradicate it.
  • Fail-fast: Breaking a large problem down into small safe-fail experiments and then willing to try & learn quickly.
  • Systems thinking: Understanding how things influence one another within a whole system and avoiding local optimizations.
  • Critical thinking: Reasonable reflective thinking focused on deciding what to believe or do. In other words; thinking about thinking.
  • Open to experimenting with radical ideas
It very important for people to understand that in an agile environment, “Action Precedes Clarity!

Measure Twice, Cut Once

Sunday, March 6th, 2011

Recently TV tweeted saying:

Is “measure twice, cut once” an #agile value? Why shouldn’t it be – it is more fundamental than agile.

To which I responded saying:

“measure twice, cut once” makes sense when cost of a mistake & rework is huge. In software that’s not the case if done in small, safe steps. A feedback centric method like #agile can help reduce the cost of rework. Helping you #FailFast and create opportunities for #SafeFailExperiements. (Extremely important for innovation.)

To step back a little, the proverb “measure twice and cut once” in carpentry literally mean:

“One should double-check one’s measurements for accuracy before cutting a piece of wood; otherwise it may be necessary to cut again, wasting time and material.”

Speaking more figuratively it means “Plan and prepare in a careful, thorough manner before taking action.”

Unfortunately many software teams literally take this advice as

“Let’s spend a few solid months carefully planning, estimating and designing software upfront, so we can avoid rework and last minute surprise.”

However after doing all that, they realize it was not worth it. Best case they delivered something useful to end users with about 40% rework. Worst case they never delivered or delivered something buggy that does not meet user’s needs. But what about the opportunity cost?

Why does this happen?

Humphrey’s law says: “Users will not know exactly what they want until they see it (may be not even then).

So how can we plan (measure twice) when its not clear what exactly our users want (even if we can pretend that we understand our user’s needs)?

How can we plan for uncertainty?

IMHO you can’t plan for uncertainty. You respond to uncertainty by inspecting and adapting. You learn by deliberately conducting many safe-fail experiments.

What is Safe-Fail Experimentation?

Safe-fail experimentation is a learning and problem solving technique which emphasizes on conducting many simultaneous, small, controlled experiments with small variations. Since these are small controlled experiments, failure is an expected & acceptable outcome.

In the software world, spiking, low-fi-prototypes, set-based design, continuous deploymentA/B Testing, etc. are all forms of safe-fail experiments.

Generally we like to start with something really small (but end-to-end) and rapidly build on it using user feedback and personal experience. Embracing Simplicity (“maximizing the amount of work not done”) is critical as well. You frequently cut small pieces, integrate the whole and see if its aligned with user’s needs. If not, the cost of rework is very small. Embrace small #SafeFail experiments to really innovate.

Or as Kerry says:

“Perhaps the fundamental point is that in software development the best way of measuring is to cut.”

Also strongly recommend you read the Basic principles of safe-fail experimentation.

    Licensed under
Creative Commons License