In Agile development teams, your reputation is more important than ever.
In traditional development teams, your peers certainly had opinions about you They might love you or hate you or have no idea who you are. The formal process of traditional development protected you, and it limited the impact that your reputation had on your professional work product. For example, people from other groups may have approve test scripts you write. Or you might execute test scripts written by someone else. Your personal responsibility for your work was limited. As long as you mechanically performed your tasks, you were covered.
All that changes in agile. In the most agile of shops, agile teams are self organizing, and the agile tester has a lot of discretion. You are no longer protected by process. You can succeed or fail on your own.
The roles on agile teams are not clearly defined in a traditional sense -- everyone should work together to complete the task, regardless of a person’s formal role. Agile teams should be self organizing and figure out the best way to do things on their own. What is best depends on a lot of things: time, skills, interests, and trust. Trust is based on reputation, and reputation is based on the sum of your past work.
At my company, we adhere strongly to the principles of agile, and development teams make a lot of their own decisions. For example, the amount of coding that happens during a sprint ultimately depends on the feeling of the team. Of course, our teams are committed to delivering the most functionality they can each sprint, but the code has to be clean and the team has to have confidence in the work product.
We deliver develop and deliver code in a two-week sprints. In two weeks, there are only ten business days, and all our code is delivered into production at the end of the sprint. Whether programmers feel comfortable creating new code for seven days or nine days during a sprint depends on things like testing confidence. From the testing perspective, we need to provide good regression coverage (and share our results regularly with the team), and we must make everyone feel good about the sprint-level work we are doing. It is, of course, essential to keep up to date with testing (immediate feedback), but the perception of success is greatly influenced by our reputation. In this sense, a tester’s reputation has a real impact on the output of the development team.
In traditional development teams, your peers certainly had opinions about you They might love you or hate you or have no idea who you are. The formal process of traditional development protected you, and it limited the impact that your reputation had on your professional work product. For example, people from other groups may have approve test scripts you write. Or you might execute test scripts written by someone else. Your personal responsibility for your work was limited. As long as you mechanically performed your tasks, you were covered.
All that changes in agile. In the most agile of shops, agile teams are self organizing, and the agile tester has a lot of discretion. You are no longer protected by process. You can succeed or fail on your own.
The roles on agile teams are not clearly defined in a traditional sense -- everyone should work together to complete the task, regardless of a person’s formal role. Agile teams should be self organizing and figure out the best way to do things on their own. What is best depends on a lot of things: time, skills, interests, and trust. Trust is based on reputation, and reputation is based on the sum of your past work.
At my company, we adhere strongly to the principles of agile, and development teams make a lot of their own decisions. For example, the amount of coding that happens during a sprint ultimately depends on the feeling of the team. Of course, our teams are committed to delivering the most functionality they can each sprint, but the code has to be clean and the team has to have confidence in the work product.
We deliver develop and deliver code in a two-week sprints. In two weeks, there are only ten business days, and all our code is delivered into production at the end of the sprint. Whether programmers feel comfortable creating new code for seven days or nine days during a sprint depends on things like testing confidence. From the testing perspective, we need to provide good regression coverage (and share our results regularly with the team), and we must make everyone feel good about the sprint-level work we are doing. It is, of course, essential to keep up to date with testing (immediate feedback), but the perception of success is greatly influenced by our reputation. In this sense, a tester’s reputation has a real impact on the output of the development team.
Of my point of view I think most of professionals are afraid to fail in their jobs or their project tasks what is natural because all we try to do our best to find good results although sometimes we forget that failure is one of the best ways to improve ourself, our work and our performance as a member of agile team where teamwork is at the heart to how get succeed in an agile world.
ReplyDeletejust linked this article on my facebook account. it’s a very interesting article for all.
ReplyDeleteSoftware Testing Services Company
Good to know, I would like to share one of the software testing company. Indium software is one of the best Independent software testing company* established in 1999 | offshore QA Firm | Offshore & In-Housing Software Testing Services. Indium has its registered office in California, Georgia and also has multiple offshore delivery centers in India.
ReplyDeleteServices like Mobile application testing services, Game software testing services, Software Testing services, QA services, Software verification and validation, Offshore Software testing, QA Validation services, Test consulting services, automated software testing, quality assurance software, web based application testing .