Why did the Stats dip in Agile India 2015 Conference?

Agile India 2014 Conference was happy to host 1236 Attendees from 28 different countries. The attendees belong to 226 different companies and play 342 different roles. More details

However in Agile India 2015 Conference we hosted 817 Attendees from 26 different countries. The attendees belong to 165 different companies and play 270 different rolesMore details

Also there was a proportionate drop in the number of sponsors. 14 sponsors in 2014 as opposed to 11 in 2015. So many people ask us why the numbers dipped? That’s a fair question. Following are the reasons why we think the numbers dipped:

  1. We moved from Four 1-day mini-conferences to Two 2-day mini-conferences. (So naturally the count will dip. In 2016, we are back to Five 1-day mini-conferences.)
  2. In 2015, we shrunk the program team size to 9 members from 29 members in 2014. Reason: we wanted to experiment and see what happens if we don’t decide the team upfront, but add members to the team only based on their contributions (esp. via the Submission System.) I guess that did not work out all that well. In 2016, we are back to a 26 member team that is decided upfront.
  3. Overall the planning for the 2015 conference was delayed. Only in Sep 2014 we started actively working on the conference. As opposed to starting in July 2013 for the 2014 conference. (For 2016, we started work in June 2015 itself.)
  4. Part of the reason for the delay was because, we were busy planning the Agile Pune 2014 Conference. Now planning 2 fairly large, international conferences on the same topic, 4 months apart, can lead to them competing with each other. Each year we do organise a bunch of smaller, regional conferences. However with the Pune conference we got bit ambitious. A good lesson learned.
  5. The themes selected for the 2015 conference was a repeat from the most popular themes from 2014 conference. In hindsight, that was a bad idea. Participants and Companies want something new every year. (For 2016, we have 5 brand new, relevant and trendy themes: Research Camp, Lean Startup, Enterprise Agile, Continuous Delivery & DevOps and Agile in the Trenches.)

I can go on…but you get the idea.

This does not mean we will stop experimenting. We’ve been successfully running this conference for 11 years and every year we try something new, something different.That’s what keeps the excitement & enthusiasm for us (a group of volunteers, with regular day-time jobs.)

Agile India 2015 Conference – Final Attendees Profile

Agile India 2015 Conference was happy to host 817 Attendees from 26 different countries. The attendees belong to 165 different companies and play 270 different roles.

Attendees Role – 270

Agile / Lean Coach and Trainer Agile Business Analyst Agile Capability Lead
Agile Coach Agile Coach/Consultant Agile Consultant
Agile Consultant and Trainer Agile Development Consultant Agile Evanglisit
Agile Expert Agile Practitioner Agile Program Manager
Agilist Application Developer Application Engineer
Application Software Engineer.Senior Lead. Architect Architect test solutions
Assistant Manager Process & Quality ASSO Associate
Associate Consultant Associate Manager Associate Manager, Development
Associate Principal – Quality Programs Associate Product Manager Associate Technical Architect
Associate Vice President Author AVP – Agile Practice Head
BD manager BI Lead Business Analyst
Business Development Business Development Head Business Manager – HP SaaS
Business Manager – SaaS Business Systems Analyst CEO
Channel Manager – ASIA Chief Comic Book Scientist and Consultant Chief Consultant
Chief Technologist Chief Troublemaker Co-Founder
Co-founder & Director Consultant Consulting Coach
Consultnat COO Delivery Lead
Deputy Manager – Product and Process Excellence Group Developer Development & Release Manager
Development Coach Development Lead Devlopment Coach
Digital Analyst Dir SW Development Director
Director – Projects Director Engineering Director, IS
Director of Engineering Director of Platform Development Director of Software Enineering
DIRECTOR QUALITY Director-Project Delivery ED
Egnineering Manager Engineer Engineering Manager
Enginnering Manager Enterprise Agile Transformation Lead ENTERPRISE ARCHITECT
Enterprise Lean/Agile Coach, CTO, Partner Entreprenuer & Software Consultant Executive Director
Executive Manager Expert Quality Engineer Expert Software Engineer
Founder Founder & CEO Founder & Parter
General Manager Global Product Director GM : Head, Continuous Improvement
Group Manager – Product Development Group Program Manager Group Project Manager
Head – Agile CoE Head – AgileNext Head of Business Development – Application Delivery Management
Head of Development Head of Engineering Head of R&D
Head- Training Business Independent independent software engneer
Integration Manager IT Management Consultant Key Account Manager
Lead Consultant Lead Database Developer Lead- Dev CoE
Lead Developer Lead Engineer LEAD- QA ENGINEER
Lead Scrum Master Lead Software Development Lead Software Engineer
Lead Technical Architect Manager Manager – Development
MANAGER – ECOMMERCE Manager – PMO Manager – Sales
Manager – Service Delivery MANAGER – SOFTWARE ENGINEERING Manager, Engineering
Manager Software Development Managing Consultant Managing Director
Marketing Manager Member of Technical Staff Mgr Sw Development
Operations Head Partner partner/senior consultant
PRACTICE HEAD Practice Manager President
Pri Principal | Agile Coach and Trainer Principal Agile Coach
Principal Consultant Principal Development Engineer Principal Engineer
Principal Program Manager Principal Project Manager Principal Quality Programs
Principal Scrum Master Principal Software Architect Process Engineer
Product Development Manager Product Manager Product Marketing Manager – Agile Manager
Product Owner Product Quality Manager PROGRAM HEAD
Program Manager PROGRAM MANAGER – SEPG Project Analyst
Project Lead Project Manager Project Manager – ECommerce
QA Analyst QA Lead QA Manager
QA Technical Lead Quality Analyst Quality Expert
Quality Head Quality Manager Quality Specialist
Release Manager Research student Scrum Master
Scrum Master, Agile Coach Senior Agile Consultant Senior Application Engineer
SENIOR BUSINESS ANALYS Senior Business Analyst Senior Client Solution Manager
Senior Consultant Senior Delivery Lead Senior Dev. Manager
Senior Developer Senior Development Manager Senior Development Manager in Quality
Senior Director Senior Director, Software Engineering Senior Engineering Manager
Senior Engineering Project Manager Senior Executive Consultant Senior Lead Engineer
Senior Manager – Development Senior Manager – Product Development Senior Manager – Program management
Senior Manager – Project SENIOR MANAGER – SOFTWARE ENGINEERING Senior Manager Engineering
Senior Manager (SD) Senior Manager Software Development Senior Manager Technology
Senior Product Manager Senior Program Manager Senior Program Manager and Agile Coach
Senior Project Coordinator Senior Project Manager Senior Project Manager – IT
Senior QA Engineer Senior QA Lead Senior Research Engineer
Senior Scrum Master Senior SDET Senior Software Developer
Senior Software Development Engineer senior software eng Senior Software Engineer
Senior Solution Architect Senior System Analyst Senior Technical Analyst
Senior Test lead SENIOR VICE PRESIDENT Serion Offering Program Manager
Service Manager SMTS / Scrum Master Software Artisan
Software Consultant Software Delivery Manager Software Developer
Software Development Engineer Software Development Manager Software Engineer
Software Engineer 2 Software Engineer Senior Manager Software QA Engineer
Solution Architect Solution Consultant – Pre Sales Solutions Architect
SPECIALIST Specialist – Process Transformation Sr Business Analyst
Sr Director Sr Lead Engineer Sr Manager
SSE(Agile Coach) System Analyst Team Lead
Technical Analyst Technical Architect Technical Coach
Technical Fellow Technical Lead Technical Manager
Technical Program Manager Technical QA Lead Technical Specialist
Technical Team Lead Technologist Tehnical Manager
Test Lead Test Manager Test Practice Lead
UI Consultant UX Consultant UX consultant and trainer
Validation Test Engineer Vice President Vice President – Product and Process Excellence Group
VP VP of Product Development VP Solutions

Attendees Organization – 165

ABB Accenture Adobe Systems
Agile++ Engineering AgileFAQs Technology Agile For Growth
Agile For Growth LLC AgileSparks Akamai Technologies
Alliance Global Services Alliance University Allianz
Allscripts India Altisource Business Solutions Amadeus Software Labs India.
Amdocs India American Express A-Noir Consulting
ARICENT Baguette UX Bank Of America
Barclays BlackDot BMC Software India ltd.
Brillio Technologies Buildium Software Solutions. CA Technologies
Caterpillar India CGI Inc Channel Bridge Software Labs
Cisco Video Technologies Citrix Systems Cognizant Technology Solutions
Collaaj Inc Compro Altimetrik India
CSG International CresTech Software SystemsLtd. CSC
Cybrilla Technologies Cucumber D4i
DigiAds Technologies Directing the Agile Organisation Direction Software Solution
DSS DuraSoft Dell
eBay / CSC EMC Emergn
Enteleki Technology Solutions EPlan Services Epsilon Technologies
Equal Experts Errorception eBay
Exelplus Services Fidelity Business Services India. Fifty
Firmenich Firmenich Aromatics Fred George Consulting
FutureWorks Consulting LLC Gainsight GE Healthcare
GeekTrust GembaTech Globallogic
HCL Technologies HERE, a Nokia company Hewlett Packard India Sales
Hexagon Capability Center India. Honeywell Technology Solutions Lab Huawei
ICAgile Idyllic Software IDeaS a SAS Company
IG Infotech IHS Global IBM
IIT Bombay Impetus Independent
Infinera Infosys InMobi Technologies
Innovation Roots Softech LTD Intel Security Intuit
Intuit India Development Center Investment Bank Iron Mountain Services
ITS, Umeå University IVY Comptech Orbitz Worldwide
JDA Jeeves Information System Jeff Patton & Associates
Josh Software. JP Morgan and Chase India Services KH
L G Soft India. LeanPitch Levitum
Lyra Infosystems Mahindra Comviva Mastek
McKinsey Digital Labs Microsoft MISYS
M/s Altimetrik India Multunus Software NIIT Technologies.
Nokia Networks Odd-e (Thailand) Oikosofy
Philips India. PM Power Consulting Polycom R&D India
Pramata Knowledge Solutions Private Providence Health and Services
QAI Global Quanticate International Quintiles Technologies
Qwinix Technologies. Rally Software Development Corporation Singapore Pte Rotary International
Zensar Technologies Sabre Salesforce
Samsung SAP Labs India Sapient
Siemens Technology and Services Simpthings Societe Generale Global Solution Centre
SolutionsIQ India Somnoware Healthcare Systems Sunquest Information Systems
Suyati Technologies Symantec Tarams Software Technologies
Tata Consultancy Services TekTutor TestTriangle
Thought Leadership Solarwinds India pvt ltd ThoughtWorks Technologies
Tk20 Triple Point Technology Unisys
Unusual Concepts UST Global VeriSign Services India
Walmart Labs Waseel ASP Wildebeest Software
Wipro Technologies Xebia IT Architect Xerox Services

Countries – 26

Country Count
Australia 2
Bangladesh 5
Canada 2
China 7
Denmark 3
Egypt 2
France 5
Germany 6
India 639
Indonesia 9
Israel 5
Japan 4
Malaysia 15
New Zealand 4
Norway 3
Philippines 2
Russia 21
Singapore 14
South Africa 3
Saudi Arabia 2
Sri Lanka 28
Sweden 7
Thailand 2
Ukraine 3
United Kingdom 7
United States 17


Gender Count
Male 530
Female 287

Yuval Yeret Interview

Yuval Yeret is a senior enterprise Agile Coach at AgileSparks. He has substantial experience in coaching and leading the teams through Agile ways-of-working. He has led many long term strategic initiatives and one of the leading Kanban practitioners on the enterprise product development world.

He published ‘Holy land of Kanban’ and is the recipient of the Brickell Key Award for Lean Kanban community excellence. His experience in leadership/management along with his experience in  networking, security, storage in both Dev and Ops of IT/Product development gives him an edge in DevOps trend.

Yuval Yeret

Here is an excerpt from the conversations we had with him.

1. You received the Brickell Key Award for Lean Kanban community excellence, driving Kanban adoption in Israel. Tell us a bit about your experience popularising Kanban in Israel.

Well, It has certainly been an interesting journey so far. It is hard to popularise a disruptive innovation like Kanban under a strong incumbent like Scrum. I found that the best way to get traction for the ideas behind kanban was to focus on what job it could do better than scrum for people. Turns out Kanban is quite good at doing the job of educating leadership about Lean/Flow since its language is more explicitly connected to the Lean/Flow concepts. It is also quite good at helping organizations who like to “build their own agile” rather than following a methodology religiously. It is also a great “gateway drug” method to get you going towards a lean/agile way of doing things. The visibility and mindset you use catalyzes the right kinds of behaviors and structures. I’ve seen several cases of teams starting with Kanban on top of their waterfallish structures and processes and starting to use more agile structures and processes like Feature teams, User Stories, ATDD, CI as they learned about the potential value these changes might provide when considered through a flow perspective

2. You claim that Kanban is a match made in heaven with DevOps. Tell us why?

DevOps talks about System Thinking, End to End Flow, Closing and amplifying feedback loops. All of those can be done with an iterative approach but in most real-world scenarios are a bit hard to fit into a sprint and are better managed as a flow using something like a Kanban pull-system. At the other end, the highly mature teams with Continuous Delivery capabilities balk at the “slowness/inflexibility” of the scrum iteration and prefer a fast-flow kanban system. In addition, DevOps is typically a journey for most organizations. The most popular description of that journey is found in “The Pheonix Project” by Gene Kim (which is highly recommended btw). And that journey’s steps – System Thinking, Amplify Feedback Loops, Continuously Experiment towards improvement map very well to Kanban’s principles of starting with where you are with respect to how things are done and by who as well as the practices of Visualization, Flow Management, Different levels of feedback loops

3. What is the biggest challenge in implementing Kanban on DevOps?

I would say the biggest challenge is having the discipline and resolve to get to an end to end visualization of the workflow (especially if this is only in your sphere of influence, not your sphere of control) not to mention move to Pull mode and WIP limits. You step into dangerous territory when you convey messages like “we will not pull this, we’ve reached our WIP limit”.

Another challenge that is even more extreme in DevOps compared to typical Agile situations is the need for end to end leadership looking at the performance of the entire value stream. (Agile only needs to bridge the Product/Dev/Test)

4. DevOps and Continuous Delivery is becoming pretty mainstream. At companies where these approaches are used, what metrics are they capturing to prove the ROI?

I wouldn’t necessarily say DevOps and/or Continuous Delivery is mainstream. I think there is a big chasm to cross. The Innovators who were typically web companies like NetFlix, Flickr, Etsy, Flickr, Amazon, Google. Then came early adopter companies which ranged from other web companies to companies with adventurous IT organizations with a real need to innovate faster in order to compete and/or a real sustainability crisis to deal with. Based on these problems/reasons for DevOps the typical metrics are deployment frequency, lead time for changes, and mean time to recover from failure.

Early adopters by their nature are less interested in metrics and ROI since they went into DevOps with an urgent business problem to solve. So initially data wasn’t readily available. But as DevOps is trying to cross this chasm it indeed needs to make a stronger business case as the mainstream market typically looks for this kind of proof as well as the validation that DevOps indeed works for a similar context to the one they are in. People like Gene Kim and some others in the DevOps community realized this some time ago and started issuing “State of DevOps” reports yearly. The 2014 report goes beyond reporting on the benefits for these operational metrics and is able to show a correlation between these leaner operational metrics and better IT performance overall as well as even better business results.

5. What is your favorite DevOps principles? Anything that changed the way you view software development?

I’m a Kanban guy. So I like Systems Thinking and Visualization of the end to end flow. Every time I help a group look end to end and see the light bulbs turn on just by seeing the initial kanban board view of their current situation it is a very satisfying moment. Asking them to play “what if” and simulate the future or a past scenario makes it even more realistic and drives the understanding of the lean/DevOps principles even deeper. I also like to help people understand the cost of the delayed feedback in the way they are currently doing things and use it to reduce the batch sizes in their processes and justify investment in various practices and even structural changes. This combines the “Amplify Feedback Loops” principle together with Don Reinertsen’s Cost of Delay/Flow principles.

6. What are some of the common problems, while applying DevOps concepts to Enterprise IT/ Product Development as compared to hosted-web apps?

Well the toughest problem is that Continuous Delivery is much harder and sometimes even an unrealistic goal. This makes it harder to close the feedback loop. It also makes it harder to justify tighter internal loops as people will tell you “why bother”. The way I deal with that is emphasize the cost of delayed feedback not just the cost of delayed time to market. I also insist the organization try to find creative ways to close the feedback loop like a cloud-based lab, early access programs, etc. I also emphasize that DevOps!=CD. You can benefit a lot from the DevOps thinking, principles and practices without going all the way to CD. I find Reinertsen’s principles of flow very useful in this context.

7. Is there any special advice you would provide to people applying WIP limits to DevOps projects?

Especially when talking about enterprise DevOps your end to end flow will probably NOT be at the user story level. It will probably more at the “MMF”/Feature”/”Epic” level, whatever you want to call that unit beyond the story that DOES make some sense at the business level to deploy and enable for users. In these cases people should make sure that their WIP limits and their flow visualization in general apply at this level. In fact, in several enterprise DevOps cases we started from agile teams using some process like Scrum/Kanban/Scrumban and DevOps was one of the triggers for starting to actively manage the end to end flow of Epics/Features. To learn more, come to my workshop at Agile India 2015 conference.

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2015#workshops

Mark Lines Interview

Mark Lines along with Scott Ambler, co-created the Disciplined Agile Delivery (DAD) which is a process decision framework designed to help organizations apply agile and lean for their unique contexts.  It provides guidance for “disciplined” application of agile across the enterprise.

Mark Lines

He show teams how to extend Scrum with other supplementary practices from a variety of methods such as Extreme programming, Kanban, Agile Modelling and the Unified Agile Process. He help teams apply DAD with its hybrid approach that is suitable to the unique needs of the organization. Mark has over twenty five years of experience in delivering software solutions.

Mark co-authored “Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise”. Also co-founded the Disciplined Agile Consortium, the certification body for Disciplined Agile.

Disciplined Agile Delivery

Here is an excerpt from the conversations we had with him.

1. What are the challenges in implementing Scrum for large complex projects?

Software development is hard.  Scrum is described by a 16 page guide.  Clearly that is not enough guidance to deliver enterprise, mission critical applications.  So in the past it has been left up to the practitioner to try and supplement Scrum with ideas from other methods such as Extreme Programming, Lean, Kanban, and others.  But even if one has the experience to piece together practices from these methods into something that makes sense, that is still only effective for individual, small project teams.  Once you are successful at the team level, scaling it across many teams, on projects of many different types can be very challenging.  Indeed, without a solid foundation that DAD provides it is very difficult to be successful applying agile across an organization.

2. How does DAD address the challenges highlighted above?

To address the challenges of being effective at the team level DAD is comprised of a hybrid of proven practices from the leading agile methods.  It provides a cohesive approach that addresses the complete lifecycle, not just the construction aspect that mainstream methods such as Scrum focus on.  Having applied the DAD framework properly, then we are ready to address scaling concerns such as distributed teams, compliance and regulatory situations, domain complexity, and large teams.

One of the flaws we see with other scaling approaches such as Large-Scale Scrum (LeSS) is that they rely on Scrum itself.  Although scaling based on Scrum makes sense in many cases DAD doesn’t prescribe Scrum.  In fact DAD has four different lifecycles which address other needs such as Lean, Exploratory (Lean startup) and Continuous Delivery.

One thing I would like to point out is that people often misinterpret DAD as being a scaling framework.  While it certainly is applicable for scaling, it is more often used for small and medium sized teams.  It is a “process decision framework”, providing guidance to customize your approach for the vast variety of contexts that organizations find themselves in.  One scaling framework will not be best in all situations.  Fortunately DAD is flexible.  We like to call it “pragmatic agile”.

To learn more, come to my workshop at Agile India 2015 conference.

3. Tell us a bit about what got you started with DAD?

That is an excellent question.  Both Scott and I have been using agile techniques long before the agile manifesto was written.  We had different names for things but we have been build software iteratively and incrementally for many years prior to 2001.  While Scott was at IBM he consolidated his own past work as well as harvested proven techniques from other methods into DAD.  It was during that time that we agreed to write a book on the framework.  Contrary to what many believe however, DAD is not IBM’s.  The Disciplined Agile Consortium is responsible for maintaining and evolving DAD.

4. Based on your experience coaching teams, how do they react to the hybrid approach suggested by DAD?

Without reservation I can tell you that teams that take time to understand what DAD really is and are very happy with DAD.  It bridges the gap between what project teams need to be effective with agile and lean and what the enterprises need for effective cross-team and program collaboration.

5. What is your take on certifications? How do they help the practitioners?

Scott and I have openly criticized agile certification schemes in the past so some people were surprised that we developed a certification program for DAD.  We decided that certification can be a valuable thing but the program needs to be credible.  As such, we have a multi-level Belt program that shows the progress of knowledge, experience, through to community involvement.  Lower level belts demonstrate experience on DAD projects while higher belts reflect coaching and organizational DAD transformations experience.

Regarding how certifications help practitioners, we have found that some organizations want to hire people that have demonstrated a commitment to learning what DAD is all about, and sometimes they want evidence that they have actually applied the DAD principles on projects.  In this regard it becomes a valuable thing for an agile practitioner to have on their CV.

Although not required, attending a DAD workshop is an excellent way to prepare for the Yellow Belt certification test.  Additionally, most DAD workshops include a free certification test.  More information on the certification program can be found at www.DisciplinedAgileConsortium.org

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2015#workshops

Fred George Interview

Fred George is a developer and co-founder of Outspace system. He is a principle consultant at Fred George Consulting. Fred coined the term microservices. He coaches teams in Advance Agile concepts and in microservice architecture. Fred is one of the early adopters of Agile and OO. He has used over 70 programming languages and have worked across the globe. He started ThoughtWorks University in Bangalore, India, based on a training program he developed in the 90’s.

His specialities includes Software development; programmer anarchy; agile; lean; change agent; XP; software architecture; Ruby; Web HTML and CSS; Sinatra; Rails; 70+ languages

His contributions to the Agile community is remarkable and he continues to make an impact through his experience and domain expertise. 

Fred George

Here is an excerpt from the conversations we had with him.

1. What does it take to be an early adopter of any new language or technology?

Two thing: awareness and a bit of luck. First of all, you need to be aware of what new stuff is coming. There are an awful lot of blogs and announcements every day, so I find this channel useless. I tend to use conferences to expose myself to the latest thinking. And with so many conferences producing videos, a survey of the conference program and a few minutes of video can give you hints of what new is coming. Lately, MicroServices (which just had a dedicated conference in Berlin) and Docker seem hot.

The second thing is a bit of luck: Is this new idea worthy of attention, or is it one of the thousands of ideas that is seriously flawed? Fortunately, you can make your own luck. Find a handful of respected names in the industry that seem to be on top of the latest things, and watch what they do. Martin Fowler, (Pragmatic) Dave Thomas, and Neil Ford are some of my favorite guys to watch. They each have excellent track records of moving to better languages and technology platforms.

2. What is your advice to a novice polyglot programmer?

By polyglot, we are talking about a programmer who knows several different languages. My advice is to keep learning them, and strive for diversity of styles. Ruby and Python are very close; better to learn Clojure or Elixir if you already know Ruby. You should be trying to pick up at least one new language a year.

Everyone has their own style of learning. I am “hands-on”; I need to write a real program in the new language to really understand it. I know others that read a book and come away skilled (that’s just not me). So know your learning style. For me, I take some standard exercises (or code kata’s), and implement it in a language I know and a new language. What seems hard? Go look that up online.

3. Out of the 70, do you have any favourites programming languages? Why?

I think I had two profound languages that changed my programming style. The first was PL/C, an internal IBM language similar to C. Before that I was using assembly language, and I didn’t trust a program to write code better than I could. I was wrong. The early compilers didn’t get register assignments confused. I converted.

The second profound language was Smalltalk, a true object-oriented language. I read the book in 1987. It made great sense. I then started to write code, and realized I had no idea where to start: complete brain freeze. It took most of the next five years to understand it, and another five before I was really more productive.

So the short answer is Smalltalk because of how it helped me decompose real problems. I currently favor Ruby which is very close to Smalltalk in programming style.

4. These days microservices has become a buzzword. Personally I heard about microservices from you first in 2011 time frame. Tell us a bit about what created the need for a microservice architecture?

I coined the term originally to describe the ridiculously tiny programs I was writing at a client in 2005-6. As I was learning service-oriented architectures, I constantly hounded my colleagues to help me understand the appropriate granularity of services. I finally tried making them as small as possible, but still do something (an OO design technique). The idea of microservices really took off when we used the technique at a London startup in 2008.

Microservices is a natural result of simply going faster, measured from requirement through delivery. It has been facilitated by widely available cloud computing, better languages and platforms (Ruby, Python, Node.js), and high bandwidth communication between services (there is a 50GB backplane on high-end server racks). I know of at least 3 places that have independently arrived at the same design (microservices) for the same reasons.

In London, we were deploying new code into production every 3-4 minutes. That also drove organizational changes.

5. What are the advantages of microservice architecture?

There are two real business benefits: The ability to try ideas out efficiently without large time and resource expenditures, and robustness of systems that can detect and restore failures so quickly. I strive to design systems that survive failures, something much easier with microservices.

There is also an organizational benefit: Happier developers. We want to write and deliver code, and being able to do that everyday is very satisfying. Most of us exposed to the rapid processes that support microservices would not go back to the old processes.

6. Many companies are finding it hard to decide how micro should a microservice be. What is your advice to them?

First, realize there is a lot of diverse opinions on what microservices are. There are variations in size (from a few dozen lines of code to a few thousand) and interaction design (chains of service invoked via RESTful interfaces, or loosely couples, bus-attached services). So we (as an industry) are still exploring the possibilities.

Regardless, some of the early steps are the same: Break the single, cohesive database fiction most enterprises hold dear. One recent successful CTO cited his first step as “killing the JOINs” as a means of breaking the database down.

There are several representative projects to model yourself after. Netflix (which tends toward larger services) has open source most of their infrastructure, and other major companies are picking that up with great success. On the smaller side, the rewrite of uSwitch (of London) is a great example, as is the recent rewrite of Wunderlist (of Berlin); both are talked about publicly.

I’m hoping that we can have a much deeper discussion on this during my workshop at Agile India 2015 Conference. Join us, if you are interested in being part of the discussion.

This workshop has limited seats. Book early to avoid disappointments: http://booking.agilefaqs.com/agile-india-2015#workshops

Diana Larsen Interview

Diana Larsen founder of FutureWorks Consulting has many years of experience working for products in Software Industry. Besides coaching the teams in Agile ways-of-working she also leads teams/projects based on collaborative thinking and planning. Her skills as a facilitator for open space sessions and retrospectives requires no introduction. Her ability to solve critical problems in tough situations has given her an edge in her work.

Diana Larsen

She has co-authored three books including ‘Agile Retrospectives: Making Good Teams Great’. Her work with James Shores on Agile FluencyTM model is quite a hit and its been applied across teams all over the world. She has served as a chair for Agile Alliance and have joined as a board member for Organisation Design Forum.

Agile Retrospectives

We had a short chat with her about her work and also about her workshop at the Agile India 2015 conference.

1. What is the biggest bottleneck for collaborative work culture?

In most organization that find a bottleneck (not all do), I’ve seen a bottleneck caused by shifting expectations. The change in expectations influences bottlenecks in information flows, communication channels, product decisions, opportunities to learn from experience, and many more aspects of software development and product delivery. Transitioning from a hierarchical way of working to a more collaborative work culture creates changes in role definitions and role requirements. It requires letting go of habitual behaviors that may have worked well in the hierarchy, but no longer serves anyone when collaboration becomes a critical part of the work process.

For example, a QA or Engineering manager may have been rewarded for managing a number of people in a narrow functional area, for getting information from direct reports and transmitting it to the manager’s boss, for following conventional wisdom for keeping costs low and productivity high. In short, for working well within their functional silo. Now we know that for knowledge work like software development, none of these activities deliver the desired result…though they did protect opportunities for promotion. As many have said, “what gets rewarded gets done” And no one was being rewarded for taking the kind of risks that lead to innovation or other breakthroughs in performance which thrive in a climate of collaboration.

Visionaries are designing organizations for collaboration. These firms remove the bottlenecks imposed by the strict hierarchies of the past.

2. What are the typical challenges you’ve seen with Agile implementation in large organisations?

The biggest challenge I see is the belief that an Agile implementation begins and ends with making changes in how front line delivery teams do their work. Another, more insidious, challenge is a fundamental misunderstanding of the nature of knowledge work and how it is best accomplished. This misunderstanding seems to expand with the size of the organization. I rarely encounter it in startups or small companies.

Knowledge work differs from other work by its emphasis on “non-routine” problem solving. Tim Ottinger and I have shared conversations about whether software development is more about the ability to learn quickly or make high quality decisions quickly. In truth, it’s both. Knowledge workers spend a large proportion of their time seeking information, much of the rest making sense of what they’ve found, and relatively little time in applying what they now know. As some have said, they “think for a living.” This stands in stark contrast to managers who believe that software development can be measured by the amount of time a person spends typing on the keyboard.

Shifting people’s beliefs about what constitutes work poses a huge challenge.

3. Over the next few years, what does the future of Agile look like?

I have a standard answer. In my view, Agile is in its adolescence. We don’t know what it’s capable of yet. Every month or so, I read or hear about a new model or approach that adds to the body of knowledge we have about “Agile” and what it looks like. The future of Agile is one of continued evolution and increasing efficacy in ways we can’t imagine today. Like all complex ideas, it’s usefulness will continue to emerge. It may even become known by a different name. Look for its hallmarks: humanized work with an emphasis on mastery of our craft, a focus on rapid learning and feedback, delivery of business value (sooner not faster), and close connection to customer needs (even ones the customers’ haven’t noticed yet).

4. What is your view on ‘prescriptive’ retrospectives?

I’m not sure what that term means. When I looked it up, the first url was a Christian History blog. And I didn’t find much that was useful after that. So, I’m going to take a guess. The definition of prescriptive leads to a sense of “rule-based” “right and wrong” as opposed to descriptive which is more focused on the current situation and its needs. I’m not a big fan of the focus on right and wrong. One of my favorite quotations comes from Rumi, “Out beyond ideas of wrong-doing and right-doing, there is a field. I’ll meet you there. When the soul lies down in that grass, the world is too full to talk about.”

I want my retrospectives, and everyone’s, to provide a useful focus on continuous learning and improvement for the team, its product, and the organization and customers it serves. If kaizen (incremental improvement) or kaikaku (transformative improvement) are the result, you’re doing fine, in my opinion. If your retrospectives give you no benefit, stop! Or rethink how you’re approaching improvement.

The framework for retrospectives that Esther Derby and I described in our book has worked well for me as an organizing principle for designing the meeting. Every retrospective I lead is custom-designed for that team at that time with those conditions. it describes their current state and looks for ways to make it better.

What gets taught in too many Scrum and Agile training courses, “make lists of what worked well and what we want to do differently,” doesn’t work for me. Maybe there’s some team somewhere for whom that’s effective. Not me, not mine. That truncated retrospective form is a way of pandering to organizations who want their retrospectives short (half hour) more than they want them to be useful.

5. What are the fundamental principles for any retrospective?

First, prepare in advance. Come to the meeting with a designed flow of group process activities. (Sounds more daunting than it is.)

During the meeting:
Bring people together in a way that helps them focus on the work of improvement. Esther and I called this, “Set the Stage.” Pay attention to the setting and the mindsets.
As a group, describe the situation so that every team members can view the iteration (or other period of work) from all perspectives, not just their own. We called this, “Gather Data.” My colleagues at the Human Systems Dynamics Institute and the Institute for Cultural Affairs call this “What?”-answering the question, what is the current state? what have we just experienced? I have also called this the learning aspect of the retrospective. Everyone learns what everyone else knows, has experienced, and how it impacted their work.
Spend time making sense of the “what”. In the Agile Retrospectives framework, we called it, “Generated Insights.” Others describe it as the “So What?” step. Now that we know what we know, what meaning do we make of it? This is the group thinking/analysis part–discovering implications, interpretations, significance, and evaluation.
If we’ve done a great job of #2 and #3, the next step is to choose our next improvement action or experiment or , to “Decide What to Do” or frame the “Now What?” which includes the small increment of action and how we’ll track and assess its effectiveness.
Finally, “Close the Retrospective.” End the meeting in a way that respects and honors the people and the work they’ve done, reinforces the action they chose, and helps to give feedback to the facilitator, so they can improve the way they serve the team.

Beyond that, the fundamental principle is: find a way to continuously learn and improve that actually works for the team. I don’t care whether you use our framework, the Toyota Improvement kata, Quality Circles and A3 reports, or some other process…find one that works. That’s my only prescription.

6. How important are open space sessions for Agile community?

Open Space Technology as proposed by Harrison Owen nearly 40 years ago makes a great match with the principles of Agile. Both foster empowered action and self-organization. My most recent Open Space experience ended just two days ago – Agile Open Northwest 2015 – and it was another delightful instance of community members coming together to discuss what’s most important to them right now. I find people understand Agile better after they’ve spent time in an Open Space.

We often find companies confuse Agile Fluency Model with an Agile Maturity Model? Using it as a yardstick to measure their teams. What advice do you have for them?

Agile has a problem. When we started out with Agile, people used it because it made their lives and products better. Now people complain that Agile is about meetings, top-down mandates, and wasting time. We can do better. It’s time for a change.
In response, James Shore and I developed The Agile Fluency™ Model and Martin Fowler published it, “Your Path Through Agile Fluency”. The model describes how teams grow in their understanding of Agile over time. It’s a descriptive model, because it reflects what happens in the real world, and in it’s an aspirational model, because you can use it to understand how to invest in improving your teams.
We’ve found the model very useful for helping teams, managers, and executives understand what they can get from Agile and what they need to invest in order to get those results. The model’s emphasis on concrete outcomes means executives are open—even eager—to devote the effort needed. Leaders appreciate being able to see the tradeoffs and make a strategic decision, and teams thrive when given meaningful goals and the time and resources needed to achieve them.
We hope the model is used in this spirit and not as an Agile Maturity Model. If this sounds interesting, come to my session at Agile India 2015 to find out how the fluency model can help you and your teams.

This workshop has limited seats. Book early to avoid disappointments: hhttp://booking.agilefaqs.com/agile-india-2015#workshops