Agile India - A Delegate's (and Speaker's) Review

by Evan Leybourn on      9 minutes read

Over the last week I have been in Bangalore, India to present at the 2014 Agile India conference. It was a facinating conference, and I've written up a few thoughts below from some of the sessions I attended for those of you who could not attend.

Software Development in the 21st Century (Essence and Fluency) - Martin Fowler

Martin (@martinfowler) gave a number of sub-talks within his keynote. The first was a fascinating, high-level presentation on the role of Agile, both historically and in the modern world. My main takeaway is that Agile has become mainstream; it is no longer the ne'er talked about, hippy, alternative.

Some other takeaway's on the essence of agile;

  • The concept of "on time and on budget" is based on the predictive model of software development. That is the assumption that the entire software development can depend on a "plan" which, in turn, depends on stable requirements. But can we actually get stable requirements.
  • Agile questions the underlying assumption that software development depends on software requirements.
  • When we have intelligent workers, why should be system overrule their expertise?
  • If you have a team of people who don't want to work in an agile fashion, then there is no point in trying to force them to work that way.

On Fluency; Martin raised the idea of an Agile fluency model (see his website for the details). Fluency is how teams operate when they are under pressure. Organisations need to decide where on this model they intend to end up, and start working at that level at the start.

  1. * - 1 star: Management practices (Kanban, Scrum, etc.)
    45% of companies demonstrate maturity at this level.
  2. ** - 2 stars: Technical practices (Continuous Integration, Continuous Delivery, TDD, etc.)
    35% of companies demonstrate maturity at this level. If you neglect these practices, your code base can't change quickly to meet changing customer needs. This requires a massive investment (up to 24 months)
  3. *** - 3 stars: This is a move from responsive practices to proactive practices
    Only 5% of companies demonstrate maturity at this level. This can take up to 5 years to reach this level.

Martin then finished off with a final talk on the role of the programming team. Traditionally, even in Agile, the role of the programming team is to receive requirements (or intents). But developers are intelligent, they understand how software works. In order to be more proactive in setting the direction of the software, developers need to understand the business domain as well. The extreme end of this is that programmers are morally responsible for (and should be legally responsible for) what they code, even if the specifications was given by someone else.

My final takeaway; “change your organisation or change your organisation”.

From Lean Startup to Enterprise Agile - Evan Leybourn

As always a brilliant presentation and such a handsome presenter. :-)

The Enterprise Experiment - Simon Reason / Michael Pollard

Using the scientific method (and a light-hearted performance), Simon and Michel discussed the capacity of agile in the enterprise.

Issues raised include:

  • Team fit (e.g. make sure the team makes the final choice)
  • Organisational idea-maze; the complex process (in the enterprise) to get an idea to done
  • Difficulty in transferring funds from income (from previously released iterations) to team expenditure (for additional iterations)
  • Should teams work to the most features per $, or the highest value per $

Solution: Large agile enterprises need to think small; small releases, small iterations, small products to maximise value.

Caramelising Bad Apples – Phil Abernathy

Phil Abernathy talks about the impact of negative/aggressive personalities or "bad apples" within agile teams.

Only when people are accountable, predictable, reliable, and deliver, can you can trust them. But these behaviours can be driven by the corporate culture and expectations. One study showed that 80% of behaviours are driven by the expectations of 5-8 people in the organisation. In another, 98% of people knew the corporate values, but only 3% followed them.

Some Agile misnomers used by bad apples:

  • Wisdom of the crowd = Majority rules
  • Collaboration means we can keep talking
  • We don't need leaders and nobody is accountable
  • Flexible so we can't give you an estimate or budget

It's also important to understand the difference between "bad apples" in the context of aptitude vs. attitude. Bad aptitude can be addressed with training and up-skilling, but attitude needs to be dealt with directly. Remember ICE;

  • Identify: Set clear expectations and goals / check and validate
  • Correct: Call behaviours out straight away, but with belittling them
  • Engage: Propose a way forward, and follow-up with them

To continue this, Phil proposed three mechanics to build team trust;

  1. The box of trust: define the characteristics for each of the following groups; bosses, partners, customers & peers
  2. Scale of expectations: Clearly define the expectations when confronting issues based on:
    1. Deviance/Wilful violation (2 strikes and you’re out)
    2. Inattention (Buy drinks for the team)
    3. Process Inadequacy
    4. Uncertainty (reward)
    5. Experimentation (bonus)
  3. Social contract: Define agreed behaviours for the team. For example:
    1. Be on time
    2. No shouting
    3. Two solutions for every problem
    4. Share information openly

Agile - An Australian Journey of Cultural Change - Fiona Mullen & Phil Abernathy

Phil and Fiona gave an experience report on the agile journey at Suncorp. In brief, this was a successful transformation, in large part, due to a strong focus on awareness and training (which need to be separate events).

The primary learnings on what didn't go well were;

  • Kiss of yes; people would say yes, but nothing would happen.
  • Change in funding model; coaches were originally free with high take-up. But a change in funding meant projects had to pay, and suddenly coach work dried up
  • Leadership style and capability; Issues with micromanagement were addressed with Agile leadership training. This was eventually made compulsory and should have done this first.
  • Teamwork struggles; the change towards a personal accountability model caused initial stress within new teams. This was generally overcome with training and coaching.

Engendering Justice: Women, War and Peace Keynote - Rae Abileah

  • 1 in 3 women will be raped in her lifetime.
  • Every 2 minutes a woman in the US is sexually assaulted.
  • 4 million women are trafficked every year.
  • Rape cases are on the rise. 873% rise since 1971 in India.
  • Women work 2/3's of worlds labour, but own less than 1/3 of the assets

How is this possible?

Code Pink is a social justice organisation that promotes peace and the breaking of the cycle of violence engendered by war. Beautiful Trouble is a book to show tactics and strategies in the activist community.

10 suggestions on how to support women and girls;

  1. Raise conscious children; children who understand their skills and capabilities
  2. Foster gender awareness; how many women are at this conference?
  3. Kill the alienating atmosphere; change the business practices that discriminate against women and minorities
  4. Honour and pay higher wages for traditional female work
  5. Educate women in technical skills without losing the local wisdom and skills
  6. Educate ourselves on powerful women
  7. Speak up on ending violence against women
  8. Expose the truth and make it visible
  9. Organise to support women's rights
  10. Be creative and have fun; use our strategic and creative thinking

Leveraging Global Talent for Effective Agility - Todd Little

Todd gives a light-hearted, but still sufficiently technical, case study on globally distributed teams with a specific focus on distributed testing. Todd's case study is in the context of a highly complex engineering model environment with a high number of defects and a significant amount of time spent testing (both in effort and run time). To compound this issue, at the time the company was facing a global shortage of petroleum engineers.

To address these issues, the proposed solution was to outsource much of the testing effort. Using two outsource centres (a domain specialist development centre in Romania and a test automation centre without domain knowledge in Vietnam). The final outcome from this approach was to reduce defects found in beta from 222 to 36, and a corresponding reduction in known defects at launch from 104 to 3.

This was ultimately successful because we;

  • Empowered our distributed teams through autonomy (leadership, domain, development, test), ownership, and trust
  • Aligned on the purpose
  • Identified and addressed the challenges of distributed teams such as time shift (change build times so build was finished by the time Vietnam was ready to test), xenophobia of local staff, and transparency & honesty of outsourced vendors

Some other thoughts;

  • When estimating defects, developers have 2x the uncertainty over estimating features
  • Individuals create software and there needs to be a move away from code monkeys to empowered Ewoks
  • The intersection between Passion / Ability / Organisational Fit is the ideal employee

The Girl with the Chisel Tip Marker - Lynne Cazaly

Lynne ran a great workshop on visual communication. That is the art of recording and communicating a message through simple drawings. You can see my notes of that workshop here: https://dl.dropboxusercontent.com/u/11125156/lynne%20cazaly%20-%20evans%20notes.jpg (JPG file)

How to Build Features People Will Want - Ash Maurya

Ash (@ashmaurya) gave a high-level presentation on some of practices, and associated rationale, within the lean startup movement. The key point raised was that "9/10 products fail is that we build the wrong product". Some reasons for this were:

  • We fall in love with the solutions
  • We spend time writing a complete business plan rather than a simple, 1 page, business model
  • We need to spend days not weeks experimenting on something that may never work
  • You can assess the viability of a product without code
  • Start with the complex, risky, ideas (test the demand first)
  • Define the unique value proposition for the product assessing design, pricing and MVP.
  • Start-ups need to be big on vision / small on solution
  • The goal is not to get features from your users, but to understand the need and design a solution for that

Ash also then talked about his experiences (Leanstack.com) and process with Lean Canvas and managing the flow of features through a startup cycle. His Kanban Board would look something like;

Backlog > Mockup > Demo (Customer Feedback) > Code > Rollout > Qualitative Validation (Customer Feedback) > Full Rollout > Quantitative Verification (Customer Feedback)

My favourite quote from the talk: "If I had asked people what they wanted they would have said faster horses" - Henry Ford