Diversity among the speakers was fantastic. (148 expert practitioners from 18 Countries)
Speakers from various parts of the world made the conference very rich and most of them were hands on people. discussions were very productive.
Good mix of presenters – experienced vs. practicing, Indian vs. International, etc.
Speakers mix (national and international both). Great variety of speakers
Great agile spirit presented in Naresh’ welcome speak 🙂
None of the talks were marketing oriented.
Majority of the time, folks with Hands-on experience (and not academicians) were speaking
More participation from Agile practitioners than Agile Sellers
Calibre of local Bangalore speakers was excellent. I had no idea we had such high-quality speakers in India
High quality and moving key note session from Freeset.
Good setup for the review of speakers and the fact that speakers were chosen months before the conference started. It could have been better, but it was a good experience for me.
Mix of people from start ups and great organizations(This helps us understand the people with core knowledge and also the people who define the trend).
Good to interact with quality speakers from all over the world
Large number of non-Indian / non-US speakers that speaks about the diversity of Agile implementations.
Most of the speakers were fantastic. Frankly best technical conference I have attended in Bangalore.
International quality speakers (people invited from around the world)
Program/Content
The proper amalgamation of workshop, practice talk, introductory talk and expert talk
Variety of experienced topics and amount to practitioner topics where people shared real experience rather than how it should have been textbook gyaan.
It covered most of the Agile aspects & most of the sessions were interesting.
Spoiled for choice. Had a difficult time choosing which session to attend.
Workshops were very effective and engaging
No frills – No ceremonial processes such as introduction, session chair, summery etc.
Lightning talks gave a forum where young speakers could also get a chance to talk
Research Presentations and experience reports were very good
Conference consisting of Various tracks (Leadership, Experience..).
Great to hear the individual experiences(Experience report)
Three streams going in parallel (introductory, practicing & expert)
Mix of various topics from leadership to programming practices.
Having workshops where people could “feel” the topic and learn quickly
Audience
Participants across multiple cultures, countries, companies.. (750 participants from 21 countries working for 230 odd companies..wow!)
Quality of Audience (attracted the right mix of people – hard-core techies, managers, company owners, etc)
Opportunity to see what is happening outside India not having to travel outside India.
Lots of smart people. I was learning constantly, whether I was in a session or networking outside.
The volume of discussions, it’s a choice within a choice. A must have going forward.
Excellent selection of tracks and organization by stages
Excellent networking opportunities
Almost all the attendees were very collaborative
I was blown away by the passion of the organizers and participants
Looking at the crowd, I could not believe this was being held for the first time
Wide spectrum of participants brought good cultural mix
Excellent and very knowledgeable and participative attendees who added value to the talks
The crowd – amazing global audience
Opportunity to meet & interact with people from different organizations
Good Q&A
The speakers to delegate ratio was fantastic.
Logistics
Personal attention given to take care of every need of the speakers by the organizers from the beginning was something I’ve never seen in any other conferences and logistics were up to standard.
Great turnout – the conference is eventually known by the enthusiasm and feedback from its attendees, even more than the lineup of speakers.
And off-course the enthusiasm of volunteers and the punctuality was superb
Organizing the whole program, guess no single Talk/Session was changed, cancelled or rescheduled.
Attention to details – best organized conference attended so far
Excellent Event Management
Keep up the good location!! That means a lot for a conference:-)
Good event handling, lot’s of information everywhere. Nice location (although a little pricy for non-speakers).
Good website with lots of relevant information (especially the program). Good use of social media (blogs, twitter) before the conference.
Meticulous arrangements. Began and ended on the dot for most part.
Detailed Schedule Was provided to each participants, so that they could clearly schedule their time !!
Several tracks –so we had the chance to opt out of Non interesting sessions.
Thank you! I really enjoyed be part of the conference. I really appreciate: Good speakers, Friendly people around and Tasty food
Information flow – right from pre conference mails, to the finish. Hence, there was no confusion.
Simplicity of it all – the participants, the organizers, the content.
Choice of venue – centrally located, easy to access, spaces that were created within…be it the coffee shop, boardroom, open space etc
By and large, the whole event management was extremely smooth. I didn’t come across any major issues.
Three days was actually a good length of the conference. Agile 2011 at Salt Lake City felt long, but this was the right size. My personal opinion is to retain the format.
Organization – Right from the submissions till the agile program guide sent a day ahead
Time management – On dot start and ending of sessions.
Timeliness – All sessions were held as per the schedule
Display of Topic Info on each conference room entrance.
Greatly appreciate all the hard-work and passion of organizers
Collaboration with the vendors. The booth space could use improvement, but the ability to talk in-depth with them was helpful.
What could be improved:
Speakers
The star speakers with big names and titles did not offer much – they were regurgitating old stuff; whereas I found the young practitioners had more to say….
Time Management from some Speakers were not proper. Most of the time, because of shortage of time, the crux of the session was expedited or never discussed.
Some of the sessions had very open ended discussions & workshops which could be more informative & address some agile related issues.
Better panel discussion ( they got the right members but the discussion was not good enough)
Workshops conducted in the limited time were very superficial, they should be made more effective in the available time or dropped
There were 3-4 talks which I attended where the speaker had to rush through the slides as the initial slides took more time than anticipated.
Couple of speakers did not have appropriate presentation skills
Quality of some sessions (some sessions were particularly under-prepared, even though the topic itself could deserve more attention; pay attention to speaker quality)
The way some workshops were conducted. Some speakers just presented what the audience came up with suggestions without correcting those suggestions. There were totally wrong suggestions came from audience but speakers never corrected them. The bad thing about this is that rest of the audience accepted those suggestions as correct.
Some of the stage producers should not disturb the presenter while they are doing the presentation(this doesn’t mean that they cant share there ideas)
Expert speakers should talk in the beginning and in the end to hold the crowd.
Program/Content
Too many streams…it was very difficult to choose what to select.
Problem of Plenty ! It was not possible to attend all the interesting talks.
Too many good sessions in same slots..I could not be everywhere 🙂
Number of tracks – every track was interesting and it was really hard to choose one for a specific slot
7 tracks was not a good thing. At least not when the 7 tracks had kind of the same audience. If a conference has a track for .NET, one for Java, one for managers and one for testers it’s a different story.
Reduce number of parallel tracks
We had 6-7 parallel sessions. This made the choice of picking up the most relevant sessions a bit difficult for attendees. We need to re-look at how many sessions we should have in future conferences
Too many tracks; to be precise 7 tracks running at the same time. Ideally 4 would have been a good number.
2 days of conference would be plenty – but perhaps 1 day extra for workshops/certifications?
Experience sharing sessions were boring
Scheduling interesting talks in the same time(although i agree about the value proposition)
Session duration should not be more that 45-60mins
Scheduling – Not having time to get between sessions
Some sessions could have more content & concrete experiences related to retro, planning, review etc
Would love to have more keynote sessions
Speakers and hence the contents should go several reviews. There were few sessions that were totally cumbersome.
Not much take-aways. Most of us are agile practitioners,so it did not help much when a few speakers just explained stuffs on Agile. Some best approaches with real-life results/some kind of workshops should be better. Research approach was good, but yet, it was more explaining again on Agile. Everyone knows a successful agile implementation needs Self-organized teams. These things should have been reviewed before are taken up in conference agenda.
Too many introductory talks, we would expect a large number of people already practicing agile and lean so we could cut down on that and focus on extended research on improvement and experiences with both.
The open space wasn’t well utilized
Lightning talks should have been more prominent
Some of the Sessions were repetitive (Ex: Track 7 – Using Lean practice in Agile Fixed Bid Project, Implementation of Lean Concepts….. An Industrial Case Study, they was just the same)
Not many hands-on development workshops, more talks.
Back to back sessions resulted in a few presenters getting less time ( a major problem for half hour sessions)
Selection of papers needs improvement. Some presentations were not engaging enough.
Lot of repetition. May be this is good for new comers. But someone like me who has been attending AgileIndia meets, found the same story being repeated for the past 6+ years
Coaches Corner and Open Space were a good idea, but were a little too free form which prevented consistent benefit from the forums
Audience
Maybe this is trivial. Maybe the Veg food was more to balance out the expenses uniformly. But i heard someone remark on only veggie food…people perceptions.
Audience was too noisy sometimes in most the sessions. (Specially when it comes to a workshop), I was wondering whether they understood the difference between a ‘discussion’ and ‘just talking’. This made me bit difficult to get the maximum of some workshops.
Maybe trim down the numbers to 600, so that sessions are not so crowded
Some folks from sponsor stall where quite reluctant to talk to people who might not look like their potential customers.
Movement of attendees from one room to another (shopping around syndrome!) – Were the speakers not doing good? or were the participants restless? Don’t know.
Some rooms are fully packed and found it difficult to follow what was happening
Logistics
Every other room than Coronet was almost always overflowing (can we view this as tremendous success for the conference??)
Some sessions we had to stand and couldn’t participate as much as we would like to have.
A small thing was the bad internet connection on the Wi-Fi. But as you said, it was arranged in the last minute. Perhaps it should have been a focus area early on.
Venue had multiple floors that just made things confusing
Bigger conference rooms
There were no chairs sometime and had to stand throughout the session. Seating arrangement could have been more dynamic seeing attendees.
It would be good to keep the conference on weekdays, leaving weekends for family time
The tea coupons were not even asked for. Probably, we can save printing those
3 days was bit long…..
First day registration (tag at one place, kit bag in another place far away…) could be improved
Room sizes (one of the room I was speaking ‘Utsav’ was very small. People were standing for most past)
Some rooms ware small to accommodate the people due to the popularity of the topic (e.g. Utsav room)
Share presentations from the talks sooner after the talk completes
Conference Material in the form of url/cd will be good to have
Not enough breakout sessions in between the presentations to interact with other speakers or attendees
5-10 mins break between sessions would help the transition.
Distribution of tasks for organizing – some people were overloaded with most of the efforts
Book stall did not have too many books on Agile. Moreover it was not there on Day 2 and Day 3
No time between the sessions (it can be 5 mins at-least, had to literally run)
I was looking for notepad, could have given with the bag
There was no proper common meeting space between the talks. One room was far away from the rest of the rooms forcing people to choose between the two places
Registration process was not at efficient, why should I register, then collect conference bag somewhere else? Then I also had to get schedule separately. It should all be in one place. First impressions last 🙂
I had no idea where or who the stage producers or organizers, lack of visibility
Found that many a sessions had a lot of people (beyond the capacity of the room), I know its quite difficult to control that, but something that we can try to improve upon.
More Parallelization during registration of participants
Some people had to stand, some interesting sessions were given smaller rooms.
The seating arrangements was different in different rooms – will have preferred the table with 10 seats layout across all rooms to foster better interactivity between the attendees
Lack of immediate feedback forms for the attendees to assess whether they got value from the session they attended
The signage at the conference needs to be improved and in place prior to attendees arriving.
I want black, strong, coffee and tea without milk.
Internet connectivity. Wi-Fi worked well Friday PM, Saturday AM, and again Sunday PM, but I couldn’t use it most of the remaining time.
While everyone agrees with the value of eating your dog food, some people claim that this principle cannot be applied to all software industries.
Let’s take the Medical Health Care Industry. Who should build software for Doctors and Nurses to be used in the hospital? Its very unlikely that Doctors will start building software in the side. How do apply this principle here?
What we have today is a bunch of people trying to build software for the hospitals (most of them have not clue on how a hospital operates, those who know a little become Subject Matter Experts and take charge). Similarly there are lot of other industries.
You ask their users how they like the software and you would know. Its not that the development team did not do a good job of building the features right or the business did not do a good job of articulating what they want well. Its just that this model is setup for failure.
The Agile community realized that, they need to bring the users in and collaborate with them much more.
The Scrum community identifies one person or a group, call them Product Owner. They are part of the planning meeting, daily scrum and even the retrospectives & demos. Some (0.1%) of teams are able to get actual users during their demo. Are they confused about the PO being their User?
The XP community demands an onsite customer who can guide the team not just during planning, but also during execution. Again the same confusion exists. But the situation is slightly better.
Having said that, I really appreciate XP for pushing the knob on automated testing. Automated Testing (esp. Developer testing) is a great way to eat your own dog food. Remember how useful your API tests have proved to be. Tests are clients to your code and they consume your code by acting as client.
The Design (UX) Community are lot more User focused and tend to spend more time with the actual Users, but that’s very sporadic
The Lean community have realized that they need to have the development team sit with the business in their work area. They have realized that there are a lot of important lessons to learn from the context of the work place.
Personally I think we need to go way beyond this. If you look at some organizations (esp. Web 2.0 companies and Open Source Projects) they are their own Users. We can certainly learn something from them.
How can we do this? Here are some ideas:
At least to start with, have the team members take a formal education in the domain they are building the software. Do some case studies and then, spend quality time with the Users (actual Users). Not just interviewing them, but actually working with them (at least shadowing them or being their apprentice).
Educate the Users more about Software development process and have them work with the team for at least a week or two to under it.
May be hire people who have actually worked in the field. (You want to make sure their knowledge is up-to-date and they actually know the business really well). Also very important to maintain a good ratio. 1 member for a 10 people team is scary.
Build tools that can help the actual end users build/configure their software. As developers we build tools which we use on our own projects. Same tools (which were driven by eating their own dog food) can now be used by others to build their software. For years, creating a web presence for a company was a specialist’s job. Today with Google Apps and others, anyone can set up a website, add a bunch of forms, set up email accounts and all that Jazz. The line between a specialist’ role and a business user is blurring. Coz we have the tools to help. Esp. tools built by people for their personal use.
Again all of this can get you one step closer. But nothing like eating your own dog food.
With TDD, I’m a lot more confident about my solutions. If I spot a design improvement, I can quickly jump in and fix it with confidence. When given feedback, I’m able to respond to it quickly. I feel I’m in control.
It really helps me keep my design and code minimalistic and clean. No bells and whistles. No buy one get one free combo offers. <Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away>
Turns out that my code is lot more easier to test. Because its designed to be testable. Lots of people argue that they will write tests after writing the code and it would be more efficient. The biggest problem I find with this approach is that the code ends up being something not readily testable. Then either I’ve to spend time making it testable or I skip testing saying its not possible or not required.
It helps me build a safety net of executable, living, up-to-date specification for my classes and features. Its a great starting point for new team members to understand my software. Tests are a great reference point for someone who wants to use my code.
TDD is a great teacher. It helps me listen to my code and learn from it. It forces me to pay close attention to what is happening. Its easy to spot bad things faster. Its all about feedback and visibility.
TDD forces me to slow down and think. It encourages me to take baby-steps. Sometimes I find people are in such a hurry that they spill mess all over the place. It takes soo much more time and effort to clean up the mess they leave behind.
My tests tend to communicate my design choices much longer after I’m gone.
I massively reduce the amount of time I spend in the debugger or trying to manually test (monkey test) from the UI. When something breaks, I no longer need to crawl through the logs to figure out where things are going wrong. I get pin-pointed feedback.
TDD helps me maintain focus on measurable outcome (producing software that accomplishes a concrete objective). I’m not longer drifting down ratholes.
TDD also helps me reduce the hand-overs between developers and tests and hence the wastage introduced because of all that overhead and context switching.
And so on…
Having said that, TDD alone is not sufficient to achieve the above. At times you need to spike/prototype things. One needs to have (or at least start focusing on building) a good knowledge of Design Principles and Patterns. Its easy to get lost, having a pair can really help.
Again I don’t want to sound dogmatic. I don’t think TDD is the only way to build great software. There are lots of great developers out there, building amazing software without TDD. However I think TDD is a much easier approach to achieve the same.
Eating your dog food is one of the most important principle (or philosophy if you will) to effectively build software.
Following is a quick list of advantages:
Feedback is a core value of eXtreme Programming and Agile in general. What better way to get feedback other than using your own product?
Number of bugs, eps. show stoppers can be drastically reduced, without huge investment on testing (army of Testers)
You can relate to the product much more, which in turn helps in
Prioritization (features, tech-debt, other activities)
Ability to ask meaningful questions
Find creative ways to thin-slice the system (release frequently),
Great risk reduction strategy
n-fold better UX
From the User’s point of view, chances are the time it takes for them to complete some task would be drastically reduced (including set up time)
High chances of innovation
High chances of finding new feature ideas (while using the product)
Ability to maintain a clear focus
Development process becomes really lean, no threshold to take crap as far as process and tools goes
Motivation and Drive never dries up (unless you are building something that you don’t believe in)
Last but not the least, such projects never fail, coz they at least have one active user
Eat your own dog food principle can be applied at various levels:
Product/Tool level: Using a product to help during its development. On the FitNesse project, we use FitNesse to run acceptance tests for FitNesse with every build. On ProTest project, we use protest to prioritize and execute our tests
User level: Building a product to scratch your personal itch. Most open source projects are a great examples of this.
Organization level: Using products built by the company internally, before releasing it to outside world. At Directi, we use most of the products we build. At Industrial Logic, we use our eLearning platform during our in-person training and coaching.
Community level: Using one’s own philosophy in their work. For example the open source community using open source projects. The Agile community (esp. the coaches) follow their own advice.
I’m thrilled to be back in Bangalore. One thing I really missed in US was the craziness of driving on Bangalore roads. Everything was so systematic, there was no thrill, no excitement, no fun, I would be bored to death. The other day I started to think what did I really like about driving on Indian roads? There was something about driving here, that strikes a chord with the way I work [you would have guess by know, .i.e. develop software]. I concluded that, driving on Indian roads have a lot to do with the way I build/develop software .i.e. using Agile methods. Here are my initial thoughts why I think so…
Chaos from outside : If you are not driving on Indian roads, it looks like the epicenter of chaos and noise. It will take a while for you to figure out why the traffic on the roads are oriented in 360 degrees. Everyone seems to be honking at each other. If you talk to someone who has watched an Agile team work for a week, they can share similar thoughts about chaos and noise. Companies where I have tried to introduce Agile, chaos and noise seems to be one of their top concerns. Once you are part of the system, life is wonderful. Trust me, you will never look back again.
Embrace change : If you drive though a street and come back to it a week later, there is a high probability that the direction in which the traffic flows would be reversed. Changing the directions of one-ways is very common here. Driving 2 wheels with helmets on is another rule that has changed at least 10 times in the last few years. There is a constant evolution. The good thing is folks embrace change and continue with it. Strikes a chord with what happened yesterday during your planning meeting?
Heavy emphasis on open communication and continuous feedback : If you watch people in India drive, you might wonder why they honk continuously and sometimes flash their headlights? Well, that’s our way of communication and feedback. If you watch carefully, the intensity of honking and the frequency of flashing lights varies depending on what one driver is trying to communicate to the other. A gentle honk, means, I’m about to overtake you, watch out. Continuous honking means, move out of my way, you are wasting my time. A gentle flash of light means watch out, I’m behind out. All of us know the importance of open communication and continuous feedback on software projects.
Self organized : If you look at the traffic rules in India, we are not so rigid about the rules. You will find people overtaking from left and right. Sometimes you’ll find group of vehicles jumping the lights when the opposite side is empty. We don’t even have cops standing everywhere with Speed guns. A lot of busy junctions, don’t have cops. People nicely self organize and move on. I believe in self organized teams and I think that is the most effective and scalable way to build software.
Adaptive planning : Its quite common to find one of the roads in your route blocked due to some maintenance work or accident. It very rare you’ll find people waiting for it to clear up. Immediately people find another route and move on. We plan to deliver and not deliver to a plan. Its very rare to find that everything on a software project going according to the plan. Things change, we always have surprises and we learn to adapt and move one. Also note that let it be heavy rains, floods or heavy winds, none of these seem to bring the traffic to a standstill. People adapt and move on.
Stressful and Intense : No doubt driving is a lot of fun, but driving on Indian roads is stressful and can be intense. This is the same feedback I get from people who work on Agile projects. Pair programming session can be quite stressful and intense. Trust me, you’ll feel much more exhausted in 4 hours of pair programming session compared to 10 hours of working on your own. Both of these activities needs a lot of attention and can drain you out soon.
Mitigate risk : From outside, it might feel like driving on Indian roads is very risky. But if you look at the number of deaths caused due to accidents in India, its far less than that caused in US. Please note that number of deaths includes humans and animals. For those who live in suburbs in US, can tell you how many deers they find dead everyday. The trick is with people traveling so close to each other, there are very little chances to be caught by surprise. With constant feedback and continuous collaboration on Agile projects we try to mitigate a lot of project risks. Pair programming and collective ownership is another great way of mitigating the risk of one person being the bottlenecks.
Maximize the throughput : If you notice the number of people that travel through these roads each day, its amazing. Look at the roads, every inch of the road is occupied and sometimes we don’t even spare the footpaths. We like to maximize the usage of the available resources (capacity utilization). But at the same time we focus on making sure we reach home/office fast. (throughput). Every software project tries to maximize its throughput and Agile gives me a great platform to do so.
Minimize the operating cost : I’m not too sure, but my gut feel says the amount of money and effort invested in maintaining and building roads in India is far less than what they do in other countries like US. Also consider the ratio of number of cops to the number of people traveling through these roads; it is very very small. We believe in reducing any form of overhead 😉 This is the harsh reality of software projects. But Agile helps me strike a good balance.
Agility [the verb] : With the short distance between the vehicles, one needs to have really good reflexes to survive on Indian roads. Its amazing to see everyone jamming their brakes when something unexpected happens. They recover and move on. Being Agile [verb] is the key to success on a software project.
Having said all this, its always easy to find things that are done quite different in these 2 scenarios. Taking any analogy to an extreme causes more harm than good.
