Agile FAQs
  About   Slides   Home  

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

Archive for the ‘Agile’ Category

Why attend an Agile India Conference?

Tuesday, February 7th, 2017

Did you know @agileindia has hosted 900+ inspiring speakers in the last 12 years.

Eclipse Summit India 2016 – by the community for the community!

Friday, August 5th, 2016

Year 2016 is special for Eclipse users and community in India – we have the first ever conference focused on Eclipse Technologies, Eclipse Summit India, scheduled for Aug 25th to 27th in Bangalore at the Hotel Chancery Pavilion. Eclipse Summit India is being organized in collaboration with the Eclipse Foundation and will feature some of the best speakers from the past EclipseCon conferences around the world.

In 2010, we organized the first “Eclipse Day” – a day for the Eclipse community in Bangalore to get together and share expertise. We still remember that day at a small but cozy hotel on Infantry Road in Bangalore, when we kicked off the very first “Eclipse Day” in India. We followed the tradition in 2011, when SAP came forward to organize it in their campus. There were two more Eclipse Day editions in Bangalore in subsequent years – one organized at IBM and the other one at BOSCH. Each year we raised the bar in terms of content as well as participation. Thus the idea of Eclipse Summit was born!

Eclipse Summit India 2016

The conference is spread across 3 days – Thursday, Friday and Saturday. Day-1, Thursday, is dedicated for pre-conference paid workshops. We have lined up 4 workshops by technical leaders in Eclipse space in some of the key Eclipse technologies – Eclipse IoT, Eclipse e4 Platform, Eclipse JDT and Eclipse Modeling Framework. The next two days are dedicated for conference tracks – we have two tracks each on Friday and Saturday. On each of the days, we kick off the proceedings with keynotes by thought leaders in the Industry.

On Friday, we are privileged to have Mike Milinkovich, Executive Director of Eclipse Foundation deliver the Keynote. On Saturday, we have two keynotes – Sumit Rao, VP of Engineering at Cerner Corporation, as the first keynote speaker and Viral Shah, co-creator of the Julia Language as the second keynote speaker. You can find the complete program here:

Friday Aug 26th, we have two tracks – one focusing on Language Runtime (Java, Node.js, Mobile) and the other on Eclipse IoT Technology. We are fortunate to have leaders from each of these areas – Srikanth Sankaran, whose talks at past EclipseCon were rated amongst the best, will take us through the evolution of Java beyond Java-9, while Benjamin Cabé, Eclipse IoT expert at Eclipse Foundation will unveil the power of Eclipse IoT technologies. These talks are followed by a variety of talks and demonstrations that will expose you to the latest developments and trends in these areas.

On Saturday, the event continues with the focus on language technologies in one of the tracks, while Eclipse Platform focus on the other track. In the language track, Stephan Hermann, Java language guru, will take you through the dynamism in Java language while in the platform track, we have Prouvost, an expert on Eclipse e4 Platform unraveling the mystery of e4. Don’t know what e4 is? Well, now you have a reason to not miss this!

Eclipse Summit India is a conference organized by the Eclipse community for the community. Organizers have done their bit in lining up some of the eminent speakers, who are experts in their own domains. Now it is your, Eclipse community’s – turn, to contribute to it by actively participating to make it a success. Eagerly looking forward to meet you all at the conference!

We’ve last few seats left, register here:

Agile India 2016 – 5 Conferences + 16 Pre/Post Conf Workshops (March, Bangalore)

Thursday, January 28th, 2016

Agile India 2016 Conference

Over the last 9 months, our program team of 26 volunteers from 8 different countries have worked together to put together a fantastic program for you.

We got a total of 333 proposals and have selected 108 proposals spread over 10 days.

Proposed vs. Accepted Proposals for Agile India 2016 Conference

Conference Speakers

We are happy to confirm that we’ve 86 Speakers from 18 countries presenting at this very conference.

Agile India 2016 Speakers

Conference Program

The team has worked very hard to make sure we’ve a nice balance of topics selected for you at the conference.

Agile India 2016 Proposal Type

Online Registration

Choose from 5 Conferences:

And 16 Pre/Post Conference Workshops:

Register here:

Agile India 2016 Sponsors

Big thanks to our sponsors for supporting the conference.

We’ve a couple of more sponsorship opportunities available.


Social Links:

A Bird in the Hand is Worth Two in the Bush

Saturday, August 1st, 2015

In software world we call this speculative generality or YAGNI or over engineering.

IMHO we should not be afraid to throw parts of your system out every 6-8 months and rebuild it. Speed and Simplicity trumps everything! Also in 6-8 months, new technology, your improved experience, better clarity, etc. will help you design a better solution than what you can design today.

Just to be clear, I’m not suggesting that we do a sloppy job and rewrite the system because of sloppiness. I’m recommending, let’s solve today’s problem in the simplest, cleanest and most effective/efficient way. Let’s not pretend to know the future and build things based on that, because none of us know what the future looks like. Best we can do is guess the future, and we humans are not very good at it.

Agile India 2016 – Call for Proposals

Wednesday, July 29th, 2015

Agile India volunteers have started working on Agile India 2016 Conference. We are planning to host the conference at the same venue (Hotel Chancery Pavilion) in Bangalore from 14th – 21st Mar 2016 (8 Days.)

We are now open for proposals to following conference themes (and here are their theme chairs):

  • Research Camp (March 15th) – Jyothi Rangaiah and Ashay Saxena
  • Lean Startup (March 16th) – Nitin and Tathagat (ad interim)
  • Enterprise Agile (March 17th) – Evan Leybourn and Ravi Kumar
  • DevOps and Continuous Delivery (March 18th) – Joel Tosi and S Sivaguru
  • Agile in the Trenches (March 19th) – Ellen Grove and Leena S N

More details:

The conference will host 3 parallel tracks. The CFP Early Bird Submissions will close on Sep 10th.

Please submit your proposals at

Speaker Compensation:

Please speard the word:
Twitter: #AgileIndia2016 or @agileindia

What is Agile’s Biggest Shortcoming?

Saturday, April 11th, 2015

I’m surprised when people think Agile is perfect and if there are any shortcomings, its not the problem with Agile, instead, it is the person/team/org’s understanding or implementation issue. Some where along the way, the aspect that “We are uncovering better ways of developing software” was lost and agile became this static, rule-based prescriptive and dogmatic cargo-cult thing.

IMHO Agile has made a significant difference (some of it a a placebo effect as well) to the software industry however it has some serious limitations when you try to apply in beyond simple CRUD based applications:

  • Agile works well in linear or organised complexity domains where the problem is fairly well understood (static) and we need to find/evolve the solution iteratively and incrementally. But in domains, where:
    • the problem itself is unknown or constantly shifting,
    • the problem has a dozen or so variables that interact non-linearly. For ex:
      • in life sciences where we’re trying to understanding ageing/growth
      • in anti-terrorism where we have to deal with a crisis situation
      • when simulating chaotic systems like Indian traffic system
      • trying to predict outcomes in systems with distributed intelligence

applying agile values, principles and practices is not the best approach in these cases. We often find ourselves lacking the right kind of thought process and tools to be able to manage such project.

  • Event though the Agile luminaries claim that Agile treats software development as a Complex Adaptive System, they actually try to apply techniques that work in a Complicated Domain.
    • For example, given a problem, we analyse the problem, figure our a best-bet solution (set of practices), apply the solution, see what happens, do a retrospective and tweak the solution (inspect and adapt). This is how you work in a complicated domain. In a complex adaptive domain, we try a few independent safe-fail experiments to solve the problem, but most importantly we do all those experiments in parallel (set-based development approach), so we can really amplify good patterns and dampen bad patterns. We manage the emergence of beneficial patterns with attractors within boundaries. Its like running 5 parallel A/B tests and then coming up with a solution.
  • Agile folks seems to claim that distributed development is hard and you should always prefer collocation. But what about thousands of successful open source projects built by people who’ve never met each other? We seem to be missing something here. Open source project model seems to be way better at motivating people by giving them autonomy, master and sense of purpose. Most agile projects are not able to match this.
  • Today velocity and bunch of other vanity metric is killing agility. There seems to be so much focus on output and very little focus on outcome and learning. Agile has very little to offer in the space of customer development, business model validation, User experience and other important aspects required for a successful product launch. Which is what Lean-Startup movement is trying to address. This is clearly a limitation of Agile methods.

What’s your take?

Done with Definition of Done or Definition of Done Considered Harmful

Monday, January 26th, 2015

TL;DR: Definition of Done (DoD) is a checklist-driven project management practice which drives compliance and contract negotiation rather than collaboration and ownership. Its very easy for teams to go down rat-holes and start to gold-plate crap in the name of DoD. It encourages a downstream, service’s thinking mindset rather than a product engineering mindset (very output centric, rather than outcome/impact focused.) Also smells of lack of maturity and trust on the team. Bottom line: Its a wrong tool in the wrong people’s hand.

The Scrum Guide™ describes DoD as a tool for bringing transparency to the work a Scrum Team is performing. It is related more to the quality of a product, rather than its functionality. The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete.

They recommend that having a clear DoD helps Scrum Teams to:

  • Work together more collaboratively, increases transparency, and ultimately results in the development of consistently higher quality software.
    • Clarifies the responsibilities of story authors and implementors.
  • Enables the Development Team to know how much work to select for a given Sprint.
    • Encourages people to be clear about the scope of work.
  • Enable transparency within the Scrum Team and helps to baseline progress on work items
    • Helps visualize done on posters and/or electronic tools.
    • Aids in tracking how many stories are done or unfinished.
  • Expose work items that need attention
  • Determine when an Increment is ready for release

Also according to them, DoD is not changed during a Sprint, but should change periodically between Sprints to reflect improvements the Development Team has made in its processes and capabilities to deliver software.

According to the LeSS  website– DoD is an agreed list of criteria that the software will meet for each Product Backlog Item. Achieving this level of completeness requires the Team to perform a list of tasks. When all tasks are completed, the item is done. Don’t confuse DoD with acceptance criteria, which are specific conditions an individual item has to fulfil to be accepted. DoD applies uniformly to all Product Backlog items.


If you search online, you’ll find sample DoD for user stories more or less like this:

  1. Short Spec created
  2. Implemented/Unit Tests created
  3. Acceptance Tests created
  4. Code completed
  5. Unit tests run
  6. Code peer-reviewed or paired
  7. Code checked in
  8. Documentation updated
  9. 100% Acceptance tests passed
  10. Product Owner demo passed
  11. Known bugs fixed

Another example:

  1. Upgrade verified while keeping all user data intact.
  2. Potentially releasable build available for download
  3. Summary of changes updated to include newly implemented features
  4. Inactive/unimplemented features hidden or greyed out (not executable)
  5. Unit tests written and green
  6. Source code committed on server
  7. Jenkins built version and all tests green
  8. Code review completed (or pair-programmed)
  9. How to Demo verified before presentation to Product Owner
  10. Ok from Product Owner

Do you see the problem with DoD? If not, read on:


  • Checklist Driven: It feels like a hangover from checklist driven project management practices. It treats team members as dumb, checklist bots. Rather than treating them as smart individuals, who can work collaboratively to achieve a common goal.
  • Compliance OVER Ownership: It drives compliance rather than ownership and entrepreneurship (making smart, informed, contextual decisions.)
  • Wrong Focus: If you keep it simple, it sounds too basic or even lame to be written down. If you really focus on it, it feels very heavy handed and soaked in progress-talk. It seems like the problem DoD is trying to solve is lack of maturity and/or trust within a team. And if that’s your problem, then DoD is the wrong focus. For example, certain teams are not able to take end-to-end ownership of a feature. So instead of putting check-points (in the name of DoD) at each team’s level and being happy about some work being accomplished by each team, we should break down the barriers and enable the team to take end-to-end responsibility.
  • Contract Negotiation OVER Collaboration: We believe in collaboration over contract negotiation. However DoD feels more like a contract. Teams waste a lot of time arguing on what is a good DoD. You’ll often find teams gold plating crap and then debating with the PO about why the story should be accepted. (Thanks to Alistar Cockburn for highlighting this point.)
  • Output Centric: DoD is very output centric thought process, instead of focusing on the end-to-end value delivery (outcome/impact of what the team is working on.) It creates an illusion of “good progress”, while you could be driving off a cliff. It mismanages risks by delaying real validation from end users. We seem to focus more on Software creators (product owners, developers, etc.) rather than software users. Emphasis is more on improving the process (e.g. increasing story throughput) rather than improving the product. Ex: It helps with tracking done work rather than discovering and validating user’s needs. DoD is more concerned about “doing” rather than “learning”. (Thanks to Joshua Kerievsky for highlighting this point.)
  • Lacks Product Engineering Mindset: Encourages more of a downstream Service’s thinking  rather than a product engineering mindset. Unlike in the services business, in product engineering you are never done and the cycle does not stop at promoting code to high environment (staging environment). Studying whether the feature you just deployed has a real impact on the user community is more important than checking off a task from your sprint backlog.

What should we do instead?

Just get rid of DoD. Get the teams to collaborate with the Product Management team (and user community, if possible) to really understand the real needs and what is the least the team needs to do to solve the problem. I’ve coached several teams this way and we’ve really seen the team come up with creative ways to meet user’s need and take the ownership of end-to-end value delivery instead of gold-plating crap.

Self-Organised vs. Self-Managed vs. Self-Directed…What’s the Difference?

Wednesday, October 29th, 2014

Self-organised, self-managed and self-directed…do they mean the same thing or are they actually different concepts, where one might be more desirable over the other?

In the context of an “agile” team, people seemed to use these terms interchangeably. However, it’s important to note that there are subtle, yet worthwhile distinction between each.

Self-Managed Team

A group of people working together in their own ways, toward a common goal, which is defined outside the team.

For example – the CEO of a company decides to launch a new product to address the needs of a specific target market. An initial team is assembled with a budget and high-level timelines. This team decides how they wanted to operate within the given budget. Team will do their own work scheduling, training, rewards and recognition, etc. They typically do a 360 review and rated other team members for salary appraisal. Also the team manages itself and its stake holders. They collectively play the manger’s role.

Self-Directed Team

A group of people working together in their own ways, toward a common goal, which the team defines.

Usually, the team comes together for a common cause. In addition to the characteristics highlighted under the self-managed teams, a self-directed team also handles the actual compensation, discipline, and acts as a profit centre by defining its own future. In some sense, you can think of open-source projects resembling these characteristics. There is a big element of self-selection and built-in synergy.

Self-managed and self-directed have a noticeable differences in terms of autonomy and how they actually operate because of it. Listed below are attributes to consider when deciding how to structure your teams in your organisation:

Attributes Self-Managed Team Self-Directed Team
Goals Receives goals from leadership and determines how to accomplish their goals Determines own goals and formulates a strategy to accomplish them
Commitment/Motivation Requires frequent open-communication from leadership on company goals and objectives to build employee commitment and increases morale Team itself creates an environment of high innovation, commitment, and motivation in team members
Required Skills Conducting effective meetings, problem solving, project planning, and team skills Decision making, entrepreneurship, resolving conflicts, and problem solving techniques
Supervision Requires little supervision to track team’s progress and direction Prefers to work without supervision
Customer satisfaction Can increase customer satisfaction through better response time in getting work done and resolving important customer problems Can delight customers by focusing on innovation, problem solving and reduced cycle time (local, informed decision making)
Time to get team up & running Is relatively faster to get the teams to start working together, if the goal is given to them. Once they get started, they might face challenges due to lack of focus & motivation, but at least they will get started quickly Forming teams of high-caliber people, who can quickly converge on a common goal is hard. It can be expensive and time consuming to keep the team together and resolve conflicts. But once the team gels and get started, their performance is unmatchable.
Supporting Functions Requires some help from supporting teams like Learning and Development, Human Resource, etc. Pretty much self-contained; can manage with very little external support.
Executive Leadership Involvement Requires them to guide, motivate and track team’s direction. Requires a system that provides two-way communication of corporate strategy between leaders and their teams.

Hopefully, this highlights the difference between self-managed and self-directed. What about self-organised?

First let’s understand what self-organisation, as a phenomenon means.


Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent. It is often triggered by random fluctuations that are amplified by positive/negative feedback. The resulting organisation is wholly decentralised or distributed over all the components of the system. As such it is typically very robust and able to survive and self-repair substantial damage or perturbations.

Self-organisation occurs in a variety of physical, chemical, biological, social and cognitive systems. Common examples are crystallisation, the emergence of convection patterns in a liquid heated from below, chemical oscillators, the invisible hand of the market, swarming in groups of animals, and the way neural networks learn to recognise complex patterns. Self-organisation is also relevant in chemistry, where it has often been taken as being synonymous with self-assembly.

Auklet Flock Shumagins 1986

Sometimes the notion of self-organisation is conflated with that of the related concept of emergence. Properly defined, however, there may be instances of self-organization without emergence and emergence without self-organization, and it is clear from the literature that the phenomena are not the same. The link between emergence and self-organisation remains an active research question.

Self-organisation usually relies on three basic ingredients:

  1. Strong dynamical non-linearity, often though not necessarily involving positive and negative feedback
  2. Balance of exploitation and exploration
  3. Multiple interactions

Self-organisation in biology

Birds flocking, an example of self-organisation in biology. According to Scott Camazine – “In biological systems self-organisation is a process in which pattern at the global level of a system emerges solely from numerous interactions among the lower-level components of the system. Moreover, the rules specifying interactions among the system’s components are executed using only local information, without reference to the global pattern.”

Real Question

Now let’s look at what is a self-organised team? Actually, the real question to ask is, what aspects of the team do they self-organise?

IMHO both self-managed and self-directed teams use self-organisation to achieve their objectives. Self-managed teams mostly self-organises to achieve their tasks, while self-directed team also uses self-organisation to form the team itself. It almost feels like self-managed/self-directed is one dimension (abstraction), while self-organised is a slightly different dimension (implementation.) While it feels like you cannot be self-managed or self-directed without self-organisation, I’m not 100% sure.

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

Super early bird registrations starts today. Register now at

To know more about the conference, please visit

Action Precedes Clarity

Thursday, June 19th, 2014

Remember the dot-com days of Webvan and 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”.

    Licensed under
Creative Commons License