I moved to small-medium sized company from a large one. And have learnt some lessons in the past month or so. The company I joined was primarily water fall, but now we are moving to be more agile. The team that I work with, has been agile for a few years now, and well function as their own little unit.
At the big company, in my team things were already in place, well most of it. There were tweaks done to teams, for example, there was no formal walk through of the requirement with the QA, there was no code overview of the dev with the QA, the dev and QA mostly worked with, on demand. As in when the QA asked for information, it was provided.There were no test case reviews. What was definitely there was adherence to feature complete, code complete and site complete dates. The dates became stringent as the product evolved, that is code and site complete was important, even if it meant that the feature complete dates were missed.There was weight-age given to high priority bugs.
This team has around 5-6 developers including the manager, who is very hands on. Yes the manager codes, and manages. When I say manage- I mean manages the projects, assigns tasks. But I also see that he does not manage people- or maybe he does- but he treats them like adults, and the developers behave like adults. They finish up tasks assigned to them. If they need help, they raise up their hands and ask for help.I like the team, most of the communication flows through the manager- but, the product and the QA are free to communicate with them directly. But the manager is always informed when a fix has a problem, or if the dev is stumped for a solution. The manager is the most experienced dev on the team- hence he also behaves as the architect.
The product managers are by far the best ever I have worked with. The are on top of it. The tool followed here is Rally, which means each and every use case has been transformed to user stories, with presentations and images- for the QA to view. The QA is however not involved in the requirements, this comes from the product.marketing team. The test cases are written for each user story, sent for review – to the product manager and the developer who is coding the user story- not the lead, not the manager. I love it that the developer and mainly the product manager takes time to review it- it usually goes through several cycles before its perfected. So far since there are two qa’s on the team, its feels awesome that as the code is being developed, the test cases are being developed, and when the code is finished, the QA is aware what the functionality is, and is ready to start testing them.
The product manager gives the QA a list of user stories that the QA would need to write up at the start of the sprint, and is expected to finish up the testcases and test if possible at teh end of the sprints.
What I like about the team, and find it a challenge, is that the product manager is so knowledgeble, finding bugs before the QA does. It challenges me, to get really picky, and to watch out for bugs. In conclusion I think I would not be too wrong if I said that how a agile process works depends on how good a product/project manager is.
OK coming to what I don;t like- when we initially started testing, I was told that they prefer that we communicate the issues before converting them to bugs. I was not comfortabel with that, but now that I see how the team works, I think its nice- saves us time and the developers are very forth coming in telling us how much of coding is left, anf that ultimately its pointless fo rus to file those bugs. Miracle of miracles, they seem to be doing alot of unit testing and self testing- which makes it harder for us to find bugs.
I also dno’t liek it that the process is fluid, no one talks about feature complte dates. no one talked about code compelte. Its very fluid- I have not yeat released a product with this team, so I’ll hold on to my negativity and see how it flows.
LIke I mentioned earlier we use Rally, I think its a handy tool and gives a good overview of user story generation to progress in test executions, its also possible to file bugs via rally. We havent experimented with that yet.
Finally, I think I understadn what agile process means. its means fludity in the process, its about people on the team coming together, and expressing what works and doesn’t work for them, and each member of the team is a player- everyone has to be actively involved- it assumes your team is mature, and dedicated to the work they are into.
Also the daily scrum is really agile, we meet in a white walled room, with a glass wall- and a telephone hung on to the wall. No furniture what so ever, we stand around the room and tell people what we worked on. 10 minutes tops. No computer, no presentation – nothing. I like it- some hate it. They think its pointless. Coming from primarily an agile process, I love it- I know what the devs were up to- and plan on working- and I can voice by blocks – so everyone on the team is aware of it.