This document summarizes an experience report on transitioning to an Agile development process. It discusses some of the challenges faced, including breaking down silos between development and testing teams, establishing the right team ratios, implementing automation, and changing organizational culture. It provides lessons learned, such as not following Agile practices by the book, not overselling the transition, and seeking outside help. Overall, the experience showed some success in improving collaboration and quality, but also ongoing challenges in fully implementing transparency and changing culture.
MeRolePerceptiveEveningWhat not to expect ?What is agile.Debate Agile principlesYou How many people are actively engaged in an Agile environment ?How many are planning to start their transition soon.How many non –traditional QA background ?
This is the most profound question you need to answerWhy are you doing this?The reason doesn’t matter- at least not to meBut you need to know that and understand it wellEverything that happens post this- will be driven by your reason to changeFor this will set in motion how you execute your transition and where do you end up
Transparency was very importantTransparency within the team- as to what your fellow team member is doing as well as within the organizationFor team to know what the organization needsAnd for the org to know what the team is uptoImagine being the toast in a toasterEvery minute or so- someone pokes you and takes you out to see if you are done.Now look at thisWouldn’t you love to be a toast in this toaster ?Everyone knows when you are ready – no more poking ?This is more or less what we had in our organization.And Agile holds lots of promises with respect to that
We all would like to be done quickly.So we can start the next big project.The total time needed to deliver a project can perhaps not be reduced, but Agile does offer a smarter way of managing the project- so that you can release faster and more frequently.
We have our share or problemsThis is one of the best things I like about AgileConstant Inspect and AdaptDon’t like something ? Try something different. Worked ? Carry on.Didn’t work ? Try something else.As simple as that
When I was in Hyderabad- one thing I noticed was all developers ate lunch together and all testers went for lunch together- at different times.I found this very disturbing.We are all one team. We are not two teams within one team.
This was one of the most disturbing this I observed when I first joined Perceptive.In my team- there were 3 developers and 4 testersAnd since I was the manager- and wouldn’t do anything- it effectively left 2 developersAnd at one time – one developer left and there was a single developer-who was able to churn enough work to keep 3 testers busyTo me this was a very unhealthy ratio to have in a team.
Probably somewhat related to the previous slide.We have awesome developers- and awesome testers.However…Developers are lacking in domain knowledge and testers in technical stuffAnd since we have those silos I talked about- this doesn’t get betterTesters and developers remain in their own respective silos – not getting any better.And because developers lack in domain knowledge, it comes in their way to make a quality productAnd since testers do not have the technical knowledge, we have little to none automation
Finally the dreaded QA phaseAt Perceptive- we have exceptionally QA heavy process.And this is in some ways related to everything else that I have said so farThis is what we want to changeSpend a healthy time in QA doing effective testing and not necessarily longer testing phase- which doesn’t automatically ensure quality
ConferencesRead booksWent to user groupsEngaged with people online- twitter, forums etc.Gave presentations
Very experimentalWith toolsProcessesIdeasSpend little time debating them
You cant successfully go Agile- unless you change your engineering practicesCont IntegrationTDDBDD
Co-location helpsSmall things like – eating lunch together
