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

Action Precedes Clarity

Thursday, June 19th, 2014

Remember the dot-com days of Webvan and Pets.com? We took traditional businesses and gave then an online presence. Rapidly acquiring a large customer base was the sole goal of many dot-coms. “If we can get enough users, we can easily figure out how to monetize it.” And all of this made perfect sense expressed in dollars and cents. I know people who melted down Yahoo Finance’s servers by checking for their favourite stocks prices throughout the day, calculating their (paper) net worth in real time. If you were not part of this madness, you were certainly considered stupid.

But then on March 10, 2000, the perspective changed. Suddenly it became clear that this was really a bubble. Without having real profits (or even revenue/cash-flow), it was really just a house of cards. In hindsight, the entire dot-com burst made perfect sense. But why wasn’t this obvious to everyone (including me) to start with?

In complex adaptive system, the causality is retrospectively coherent. .i.e. hindsight does not lead to foresight. When we look back at the events, we can (relatively) easily construct a theory to explain the rationale behind the occurrence of these events. In fact, when we look back, the reasons are so obvious that one can easily be fooled into believing that “Only if we spend more time, carefully analysing and thinking through the situation at hand, we can completely avoid unwanted events in future.” Yet, time and again, we’ve always been caught by surprise and it almost appears to be impossible to predict such events ahead of time. Call it the Black Swan effect or whatever name you fancy.

This effect gives rise to a classic management dilemma – Predictability Paradox(pdf). In the zeal to improve the effectiveness and reliability of software development, managers institutionalise practices that unfortunately decrease, rather than increase, the predictability of the product’s success. Most companies spend an awful lot of effort and money to analyse the past, derive patterns and best practices, set targets and create processes to prevent past failure and produce ideal future goals. If software development was highly structured, if we had a stable environment and we had a good data points from million other projects, this approach might work. But for software development, which is a creative-problem solving domain, with high levels of uncertainty and each project having an unique context, these techniques (best practices) are rather dangerous.

In our domain,

  • We need to break the vague problem down into small safe-fail experiments.
  • Then execute each experiment in short iterative and incremental cycles.
  • We need to focus on tight feedback loops, which will help us adapt & co-evolve the system. (We cannot be stuck with analysis paralysis.)
  • We need to probe the system with experiments and find emergent practices.
  • And then apply these practices in a given context, for a short duration.
  • Speed and Sustainability are extremely important factors.

This is what I mean when I say “Action Precedes Clarity”.

How Much Should You Think about the Long-Term?

Tuesday, March 27th, 2012

Often people tell you that “You should think about the long-term.”

Sometimes people tell you, “Forget long-term, its too vague, but you should at least think beyond the near-term.”

Really?

Unfortunately, part of my brain (prefrontal cortex), which can see and analyze the future, has failed to develop compared to the other smart beings.

At times, I try to fool myself saying I can anticipate the future, but usually when I get there (future) its quite different. I realize that the way I think about the future is fundamentally flawed. I take the present and fill it with random guesses about something that might happen. But I always miss things that I’m not aware of or not exposed to.

In today’s world, when there are a lot of new ideas/stuff going around us, I’m amazed how others can project themselves into the future and plan their long-terms?

Imagine a tech-company planning their long-term plan, 5-years ago, when there were no iPads/tablets. They all must have guessed a tablet revolution and accounted that in their long-term plans. Or even if they did not, it would have been easy for them to embrace it right?

You could argue that the tablet revolution is a one-off phenomenon or an outlier. Generally things around here are very predictable and we can plan our long-term without an issue. Global economics, stability of government, rules and regulations, emergence of new technologies, new markets, movement of people, changes in their aspirations, environmental issues, none of these impact us in any way.

Good for you! Unfortunately I don’t live in a world like that (or at least don’t fool myself thinking about the world that way.)

By now, you must be aware that we live in a complex adaptive world and we humans ourselves are complex adaptive system. In complex adaptive system, the causality is retrospectively coherent. .i.e. hindsight does not lead to foresight.

10 years ago, when I first read about YAGNI and DTSTTCPW, I thought that was profound. It was against the common wisdom of how people designed software. Software development has come a long way since then. But is XP the best way to build software? Don’t know. Question is, people who used these principles did they build great systems? Answer is: Yes, quite a few of them.

In essence, I think one should certainly think about the future, make reasonable (quick) guesses and move on. Key is to always keep an open mind and listen to subtle changes around us.

One cannot solely rely on their “intuition” about long term. Arguing on things you’ve all only guessed seems like a huge waste of time and effort. Remember there is a point of diminishing returns and more time you spend thinking long-term, less your chances are of getting it right.

I’m a strong believer of “Action Precedes Clarity!”

Update: In response to many comments: When the Future is Uncertain, How Important is A Long-Term Plan?

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!
    Licensed under
Creative Commons License