Wednesday, May 30, 2012
Monday, February 6, 2012
QA role in scrum team
The QA/Tester must definitely be part of the SCRUM Team. Given below are the reasons as to why I believe so:-
-QA in SCRUM is not an external entity. In traditional model, QA is someone who doesn't knows anything about the product, until he receives it for testing. And once he receives it for testing he is expected to read the (mostly incomplete) SRS/Requirements Document and then test the product against the same. In SCRUM, QA must breathe the stuff being developed along with the team. He is very much involved right from the requirement gathering, elicitation, and documentation. The programmers can walk up to him and clarify any of the doubts they might have, related to the current story/feature they are working on.
-QA helps developers in coming up with the list of Unit Test cases, which the developer can then automate. This relieves the QA from the burden of testing the routine or mundane test cases and instead concentrate on other forms of testing (Usability, Acceptance, Exploratory etc.), thereby ensuring the quality of the product.
-QA plays an active role in Product Backlog expansion and elaboration and is part of most of the meeting between ScrumMaster, and Product Owner.
SCRUM expects you to deliver potentially shippable code at the end of every sprint and this is primarily what is meant when the Team proclaims a story to be done. In other words, when the team proclaims the story to be done, then it means that story or feature is potentially shippable. IMHO, you can't achieve potentially shippable status unless and until its artifacts have been tested. I strongly believe that an external QA will never be able to keep pace with the speed of the SCRUM team. On the contrary, an external QA will negatively impact the velocity of the SCRUM team.
-QA participates in Daily SCRUM Meeting, Sprint Review, and Sprint Retrospective.
-QA in SCRUM is not an external entity. In traditional model, QA is someone who doesn't knows anything about the product, until he receives it for testing. And once he receives it for testing he is expected to read the (mostly incomplete) SRS/Requirements Document and then test the product against the same. In SCRUM, QA must breathe the stuff being developed along with the team. He is very much involved right from the requirement gathering, elicitation, and documentation. The programmers can walk up to him and clarify any of the doubts they might have, related to the current story/feature they are working on.
-QA helps developers in coming up with the list of Unit Test cases, which the developer can then automate. This relieves the QA from the burden of testing the routine or mundane test cases and instead concentrate on other forms of testing (Usability, Acceptance, Exploratory etc.), thereby ensuring the quality of the product.
-QA plays an active role in Product Backlog expansion and elaboration and is part of most of the meeting between ScrumMaster, and Product Owner.
SCRUM expects you to deliver potentially shippable code at the end of every sprint and this is primarily what is meant when the Team proclaims a story to be done. In other words, when the team proclaims the story to be done, then it means that story or feature is potentially shippable. IMHO, you can't achieve potentially shippable status unless and until its artifacts have been tested. I strongly believe that an external QA will never be able to keep pace with the speed of the SCRUM team. On the contrary, an external QA will negatively impact the velocity of the SCRUM team.
-QA participates in Daily SCRUM Meeting, Sprint Review, and Sprint Retrospective.
Thursday, February 2, 2012
QA role in Agile projects
Following are the principles that are important for an Agile Tester:-
-Provide Continuous Feedback.
-Deliver value to the customer.
-Enable face-to-face communication.
-Have courage.
-Keep it simple.
-Practice continuous improvement.
-Respond to change.
-Self-Organize.
-Focus on people.
-Enjoy.
-Provide Continuous Feedback.
-Deliver value to the customer.
-Enable face-to-face communication.
-Have courage.
-Keep it simple.
-Practice continuous improvement.
-Respond to change.
-Self-Organize.
-Focus on people.
-Enjoy.
Sunday, January 15, 2012
Thoughts on Employee Bonuses
I would like to solicit thoughts on bonuses (and thank everyone for so many great thoughts on tool usage).
We are a small (and growing) team with a year of ad-hoc development behind us.
Our bonus budget has previously been distributed as:
- 50% of budget for “Christmas bonus” (it’s a Vietnamese dev team so this is actually a Tet bonus, but is equivalent to the more commonly known “Christmas” bonus)
- 2 others @ 25% of the bonus budget.
A bonus at Tet is a very cultural norm, so I don’t want to change that, but the other 50% is up for discussion.
My initial though is to tie a first 25% bonus (2-5 months from now) to some metrics of agile acceptance:
1) A stable and predictable velocity
2) Successfully completing the work committed to in the sprints (perhaps take the best result of the average of all sprints or the last 4 sprints when it’s time to issue the bonus)
3) The incorporation of automated testing (this is virtually nill now and a primary priority in moving to Agile)
Thoughts on that? And comes after that?
?) Bonuses based on some metrics of each iteration? Dispersed per iteration? Twice a year?
?) Bonuses based on releases (on the order of 2-5 months between releases)
?) Other ideas?
///////////////////////////////////////
I guess there should be nothing wrong with trying to use financial incentive to motivate people or to get developers to deliver more throughput. But what may be not natural in this approach is, rather than motivating Agile team members by appealing to their pride and sincerely giving them all the empowerment and support they need, we are talking here about using money as a main motivating factor for productivity. As far as I remember, this is not what is at the foundation of the Agile manifesto. Far from it.
Going beyond the morality question, I guess the question next will be to know how much of this productivity would be to produce software of quality rather than eventually trying to game the system to produce the best metrics possible to make money.
Last but not least, should we really need to resort to money as an incentive, I guess there should be no need to get teams to use Agile since anything else could do, as soon as people are interested in working hard to make money.
Just some thought for food.
///////////////////////////////////////
Metrics never really measure what we want them to. Rewards based on metrics risk encouraging people to game the metrics instead of doing what we really want them to do, which is work together to make the project successful.
For agile teams, it is a good start to give everybody on the team the same bonus in order to encourage team work instead of individual "heroism".
Here is an article that makes the point well:
http://www.leanessays.com/2003/01/measure-up.html
///////////////////////////////////////
Money is definitely one of the key motivators to most of us... and we cannot discount this factor.
Probably the best way to structure bonuses for Agile teams is someway that can promote collective ownership in teams and consequent team collaboration for collectively ensuring "productivity" as you call it.
My suggestion (I have tried it with the teams I coach and it works, and works well): A variable pay of say 25% that will be calculated based on customer feedback after each iteration. (customer could be product owner for Scrum teams). The customer rates the value delivered by the team in each iteration on a 10 point scale. Each point is 10 percentage point. Say if the team gets a feedback score of 8 for an iteration, all members get 80% of the variable pay for that period. If they get a score of 5, they get 50% of the variable pay.
This kind of a team bonus, will motivate the team to innovatively and creatively find ways to get the best feedback from the customer, and this would be a good way of ensuring continuous improvement of the team in their ability to deliver their best value to their customers
Ideas and feedback from members here to improve this are welcome
///////////////////////////////////////
Money is definitely one of the key motivators to most of us... and we cannot discount this factor.
It is only to a certain extent. If you are making enough money on which to live relatively comfortably, then putting up more money as an incentive can actually have detrimental effects on individuals and quite detrimental effects on teams.
This classic TED video of Dan Pink explains is much better than I can: http://www.ted.com/talks/dan_pink_on_motivation.html
///////////////////////////////////////
That was an excellent article, and I’m onboard with the team based metrics, now to define those.
· Customer satisfaction was suggested in another email, I might further interpret that as ensuring we have working software at the end of each release as a little more actionable.
· I can also set some goals based on our agreed upon code-base improvements such as constantly improving coding/code structure standards (and following those); implementing automated testing, etc.
· I would also think to include some improvement goals that the team identifies in retrospectives (generally assuming that these will be meet).
///////////////////////////////////////
Why is it millionaires haggle for more money even when they are being paid well and are living quite comfortably? In some societies, "money" is the only way out. So while money may not be a good long term strategy or possible a bad decision, what's the best decision that can be made given societal factors? I would think a bonus shared by the team is a good start
We are a small (and growing) team with a year of ad-hoc development behind us.
Our bonus budget has previously been distributed as:
- 50% of budget for “Christmas bonus” (it’s a Vietnamese dev team so this is actually a Tet bonus, but is equivalent to the more commonly known “Christmas” bonus)
- 2 others @ 25% of the bonus budget.
A bonus at Tet is a very cultural norm, so I don’t want to change that, but the other 50% is up for discussion.
My initial though is to tie a first 25% bonus (2-5 months from now) to some metrics of agile acceptance:
1) A stable and predictable velocity
2) Successfully completing the work committed to in the sprints (perhaps take the best result of the average of all sprints or the last 4 sprints when it’s time to issue the bonus)
3) The incorporation of automated testing (this is virtually nill now and a primary priority in moving to Agile)
Thoughts on that? And comes after that?
?) Bonuses based on some metrics of each iteration? Dispersed per iteration? Twice a year?
?) Bonuses based on releases (on the order of 2-5 months between releases)
?) Other ideas?
///////////////////////////////////////
I guess there should be nothing wrong with trying to use financial incentive to motivate people or to get developers to deliver more throughput. But what may be not natural in this approach is, rather than motivating Agile team members by appealing to their pride and sincerely giving them all the empowerment and support they need, we are talking here about using money as a main motivating factor for productivity. As far as I remember, this is not what is at the foundation of the Agile manifesto. Far from it.
Going beyond the morality question, I guess the question next will be to know how much of this productivity would be to produce software of quality rather than eventually trying to game the system to produce the best metrics possible to make money.
Last but not least, should we really need to resort to money as an incentive, I guess there should be no need to get teams to use Agile since anything else could do, as soon as people are interested in working hard to make money.
Just some thought for food.
///////////////////////////////////////
Metrics never really measure what we want them to. Rewards based on metrics risk encouraging people to game the metrics instead of doing what we really want them to do, which is work together to make the project successful.
For agile teams, it is a good start to give everybody on the team the same bonus in order to encourage team work instead of individual "heroism".
Here is an article that makes the point well:
http://www.leanessays.com/2003/01/measure-up.html
///////////////////////////////////////
Money is definitely one of the key motivators to most of us... and we cannot discount this factor.
Probably the best way to structure bonuses for Agile teams is someway that can promote collective ownership in teams and consequent team collaboration for collectively ensuring "productivity" as you call it.
My suggestion (I have tried it with the teams I coach and it works, and works well): A variable pay of say 25% that will be calculated based on customer feedback after each iteration. (customer could be product owner for Scrum teams). The customer rates the value delivered by the team in each iteration on a 10 point scale. Each point is 10 percentage point. Say if the team gets a feedback score of 8 for an iteration, all members get 80% of the variable pay for that period. If they get a score of 5, they get 50% of the variable pay.
This kind of a team bonus, will motivate the team to innovatively and creatively find ways to get the best feedback from the customer, and this would be a good way of ensuring continuous improvement of the team in their ability to deliver their best value to their customers
Ideas and feedback from members here to improve this are welcome
///////////////////////////////////////
Money is definitely one of the key motivators to most of us... and we cannot discount this factor.
It is only to a certain extent. If you are making enough money on which to live relatively comfortably, then putting up more money as an incentive can actually have detrimental effects on individuals and quite detrimental effects on teams.
This classic TED video of Dan Pink explains is much better than I can: http://www.ted.com/talks/dan_pink_on_motivation.html
///////////////////////////////////////
That was an excellent article, and I’m onboard with the team based metrics, now to define those.
· Customer satisfaction was suggested in another email, I might further interpret that as ensuring we have working software at the end of each release as a little more actionable.
· I can also set some goals based on our agreed upon code-base improvements such as constantly improving coding/code structure standards (and following those); implementing automated testing, etc.
· I would also think to include some improvement goals that the team identifies in retrospectives (generally assuming that these will be meet).
///////////////////////////////////////
Why is it millionaires haggle for more money even when they are being paid well and are living quite comfortably? In some societies, "money" is the only way out. So while money may not be a good long term strategy or possible a bad decision, what's the best decision that can be made given societal factors? I would think a bonus shared by the team is a good start
Thursday, December 22, 2011
Responsibilities of the SM
The responsibilities of the SM are a long list:
PROCESS: Responsible for the entire Scrum process - Leader and
motivator about doing Scrum:
. ensures Artifact quality
. helps and coaches Roles to do their job: product owner, customer, developers
. ordering of activities, meetings, time-boxes
. sets up, conducts and facilitates ALL meetings
. ensures Engineering practices are followed
. Ensures the Team has a good social context, a good environment, and it is SWARMING!
. Enforces ALL rules
. Promotes ALL values: transparency, honesty, courage
. Insurance for "doing things right. Intervene only if necessary!
TEAM: Flips between Coach, a Watchdog, a Mentor and a Project Manager,Rep to Management
. Recommends or finds initial members of team
. Responsible for team balance: how many BAs, developers, testers, etc. of what kind?
. The Scrum Master is responsible for setting the team up for success
. Removing the barriers between development and the customer so the customer or the user directly drives development
. Ensuring team actually did what they said they would do: checking testing reports, etc.
. Balancing the team workload - e.g. pass work to early finishers
. Shielding the team from outside disturbances
. Removing Impediments and resolving issues
. Promoting creativity, collaboration and knowledge sharing
. Improving the lives of the development team e.g. flexible hours, flexible days, payback for heroics, etc.
. Improving the productivity of the development team in any way possible: training, tools, system-level things
. Improving the engineering practices and tools so each increment of functionality is potentially shippable
. Promote team pride
. Organizes Celebrations after releases or sometimes after Sprints
CUSTOMER: Teaches the customer how to maximize ROI and meet their objectives through Scrum
PO: Responsible for training and keeping ongoing communication with Product Owner (good PB!)
ADMIN: Maintaining the Sprint Backlog and producing Sprint Burndowns
. Posting the Sprint Burndown as Visible Status: Wall, Wiki, email, etc.
. Ensuring Scrum Board gets updated
MANAGEMENT: representative to team for management
MULTI-TEAM: Participating in the Scrum of Scrums such that both how their team affects other teams, and how other teams affects his team are understood, if no other team member is available
. Coordinating participation of their team in either the "big room" Sprint Planning Meeting, or in a staggered Sprint Planning Meeting understanding dependencies, or coordinating with architects when they exist
. Coordinating participation in the Sprint Review Meeting, both independently and with the rest of the multi-team, the latter is specially important in releases to production where many dependencies exist
. Coordinating with integration Sprints when they exist
. Coordinating integration issues with other Teams
. Working with their team or theme PO and with the CPO (chief product owner), to ensure their teams can choose portions of the Product
Backlog (usually though themes)
. Coordinating with their individual teams on dependencies or modified work found at the Scrum of Scrums
If you can do all of the above while "developing code".. More power to you, but don't compromise the above tasks for speed i.e. getting more code done, because you may compromise the work of everyone in the team instead.
This article is by Mike Beedle and borrowed from
http://www.enterprisescrum.com/blog/2011/12/20/responsibilities-of-the-scrummaster.html
This article is by Mike Beedle and borrowed from
http://www.enterprisescrum.com/blog/2011/12/20/responsibilities-of-the-scrummaster.html
Saturday, October 15, 2011
Agile Testing
I had an opportunity last week to present a session on agile testing to a group of QA teams.
It was a wonderful session, we had a group of people from different QA teams all part of some or other waterfall way of projects. Every one asked lot of questions and were quite inquisitive about how agile project progress.
I am attaching the presentation which is quite simple but lead to a lot of good discussion.
Wednesday, September 7, 2011
A ScrumMaster’s Checklist
An amazing checklist for being a genuine team scrum master:
http://blogs.collab.net/agile/2007/08/13/a-scrummasters-checklist/
Subscribe to:
Posts (Atom)