Feedback Loops in SCRUM

What is a "feedback loop"? Put simply, a process has a feedback loop when the results of running the process are allowed to influence how the process itself works in the future.

Following are a list of feedback loops:

• Pair programming
• Unit tests
• Continuous integration

• Daily Scrums
• Sprints

• Code reviews
• Static code analysis
• Automated integration tests
• Automated acceptance tests
• Having the customer and business experts work closely with you throughout the process
• Increasing the frequency of releases tenfold (at least to test environments)

The article I found below very nicely explains the importance of feedback loops in Agile projects:

http://www.infoq.com/news/2011/03/agile-feedback-loops

Metrics in Agile development

Interesting Read:

http://agileworld.blogspot.sg/2009/02/metrics-in-agile-development.html

Extract:

• Total number of new defects found in each iteration
• New features added to backlog in each iteration
• New tasks discovered in each iteration
• Number of resolved defects in iteration, etc

Automate if it adds value

"Automate if it adds value" is the driving force behind the creation if this short and simple shell script.

 

Though this script seems trivial but if we consider the task it is achieving, it is becomes important and its creation joyful. In our team we recently received hardware boxes to setup QA environment for testing. Usually the development environment and production releases something called release tool which is pretty much standard way of deployments. But for QA environment, since it is setup phase we have some constraints to setup the release tool. But we had decided in our retrospective that for every release from now on, we will complete QA testing using QA environment. Thus leading to QA environment setup gradually and leading to the requirement of QA deployments and this script. We plan for this with in our sprints. The DEV and QA, working on the story both take the ownership of setting up this QA environment bit for their release.

 

Now with this context, we had to make a temporary arrangement for deploying stuff to QA box. And I had already listed down a few sequential unix commands to achieve this. Eventually it became cumbersome, error prone and boring to repeat the same commands many times. So I thought of quickly writing a simple shell script to get this task done and make it interesting.

 

Three keywords:

 

1.       Simple

2.       Quick

3.       Interesting

 

I had seen many shell scripts in the past and executed them, opened them in VI and edited them but had never written them from scratch. So learning something new and of course achieving some automation makes it interesting. Initially when I started with the task, the simple requirements were; accept the application name, version and user details from command line and deploy to a standard path. As I progressed I added parameterization, error handling and positive and negative logging.

 

[Standard start of a shell script, shell and usage]

 

#!/bin/bash

if [ $# -lt 3 ];then

echo "Usage: ./qadeploy /appMainFolderName /appVersion userLogin";

exit

fi

 

[Printing some messages indicating the start and making clear the input values]

 

echo "Starting QA deployment for $1$2"

echo "App to be deployed is $1"

echo "App version to be deployed = $2"

echo "User = $3"

 

[Creating a temp directory because it is required to change the owner of files before final deployment]

 

echo "Creating temp directory /home/$3$1$2"

`mkdir -p /home/$3$1$2`

 

[Using the Secure Copy command for copying from remote location, it prompts for password]

 

echo "Starting to copy to temp location..."

`scp -r $3@dsos37a-0104.eu.hedani.net:/app/credit$1$2 /home/$3$1`

if [ $? -ne 0 ]; then

  echo "Error executing: scp"

  exit

fi

 

[Change the permissions of the copied contents so that the next copy or move command will change the owner of the files]

 

echo "Changing permission to 777"

`chmod -R 777 /home/$3$1`

if [ $? -ne 0 ]; then

  echo "Error executing: chmod"

  exit

fi

 

[Clear the already existing application contents]

 

echo "Removing previous entry for the app at location: /app/credit$1$2"

`rm -rf /app/credit$1$2`

if [ $? -ne 0 ]; then

  echo "Error executing: rm -rf /app/credit$1$2"

  exit

fi

 

[Make the final move towards the deployment and clearing the temporary contents]

 

echo "Moving the app from temp (/home/$3$1$2) to real location: /app/credit$1"

`mv /home/$3$1$2 /app/credit$1`

if [ $? -ne 0 ]; then

  echo "Error executing: mv /home/$3$1$2 /app/credit$1"

  exit

fi

 

[Deployment complete]

 

echo "Deployment complete for $1!"

Amazing Team Composition!

There are rare people in this world who get ideas.

It is rarer to find people in this world who get ideas and also are able to implement them.

It is still rarer to find people in this world who get ideas, able to implement them and remain organized to be efficient.

It is most rare to find people in this world who get ideas, able to implement them, remain organized to be efficient and continue to be like that for long.

So we need to be part of a team which has:

•        An entrepreneur –  who  has idea(s)
•       An implementer – with excellent implementation skills
•        An administrator – who is organized and add efficiency
•        An integrator – who keeps the team together

Most important thing: Mutual Respect amongst all the above. 

How? Read the book below:

http://www.amazon.com/Mastering-Change-Ichak-Adizes-Ph-D/dp/0937120049

Introducing Generic Fixture for FitNesse

http://anubhava.wordpress.com/2008/02/09/introducing-generic-fixture-for-fitnesse/

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 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.

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