Different Meeting in Agile (Scrum)

There are set of meetings which are conducted if you are practicing Scrum.  Each meeting have specific agenda, purpose and frequency and Scrum Master should ensure that each meeting sticks to its plan and achieves its intended purpose.

Here are the meetings which comes with practicing Scrum. 

Sprint Planning Meeting
Frequency: Once at the beginning of every Sprint cycle.
Duration: 4 to 8 hours depending on Sprint length.  As a rule of thumb, it is 2 hours per week of sprint.  So if you are having 2 weeks sprint then 4 hours for planning and so on.
Purpose: Determine what work to be done in the sprint, preparing backlog and communicate to everyone what will be completed in the sprint. Development Team commits to the plan and Sprint backlog. Also, In first half of the meeting entire team involving dev team, scrum master, product owner meets and they prioritize the Product Backlog.  In first half product manager identifies the user stories that team feels it can commit to completing in the sprint based on prior experience.  In Second half of the meeting development team and scrum master breaks the story down into tasks and they determines how they plan to develop and test agreed user stories. At the end of this meeting team creates the plan for the sprint and agrees on Sprint backlog.

Daily Stand-up Scrum Meetings
Frequency: Daily
Duration: 15 min
Purpose: Main purpose of this meeting is to collaborate with other team members and communicate Risks. In these meetings, each team member answers 3 questions:
- What I did since last call
- What am I going to do till next call
- Is there anything which is blocking me (impediments) from achieving my sprint goals. If there are any impediments than Scrum Master records that. Team doesn't try to resolve issues in this meeting and Scrum Master work outside this meeting to bring impediments to resolution.

Sprint-end Review Meetings
Frequency: Once at the end of the end of the sprint
Duration: 2 to 4 hours
Purpose: Show the work (demo) to the stakeholders and customers that team accomplished in the sprint and receive feedback.  Also, review the work that is planned but not completed.

Sprint-end Retrospective Meetings
Frequency: Once in the sprint. Usually on the last day of the sprint after Sprint Review Meetings
Duration: max 3 hours
Purpose: This meeting is facilitated by Scrum Master. Two main questions are answered in this meeting i.e., What went well during the sprint? and What could be improved in the next sprint?

Overall purpose of this meeting is to implement continuous improvement in processes.  Based on the brainstorming and analysis team decides to implement new processes, update existing processes and/or continue to follow good processes.

 Optionally some teams do have few other meetings like

Backlog Refining Meetings
Frequency: None
Duration: None
Purpose: This is not Standard Scrum practice but many team follows it to manage the quality of product backlog items better. This is an ongoing process where team and product owner reviews the product backlog and re-prioritized (if required).  If required large Product backlog items are broken into smaller items and more details about the items are added.  This helps team during the Sprint planning meeting to pick and complete the user stories in effective manner.

Scrum of Scrums Meetings
Frequency: Daily
Duration: None
Purpose: This is a technique which is very useful when there is large team working towards same goal.  This large team is divided into multiple scrum teams to focus on one particular area.  These individual scrum teams designates one member in their team to represent their work to other teams.  All teams discuss their work in Scrum of Scrums daily meeting with the agenda of focusing on areas of overlap and integration.This designated team member could be technical contributor in the team or Scrum master of the team.  As Jeff Sutherland commented, Scrum of Scrums is not meta scrum but its responsible for delivering the working software of all the teams to the Definition of Done at the end of the sprint.

The Agenda of Scrum of Scrums Daily meeting are to get answer to four questions:
- What has your team done since last call
- What will your team going to do till next call
- Is there any impediments for your team
- Is there any impediments your team going to put to other teams

Creativity by Rinku - Family/Apple tree

Creativity by Rinku - Best out of waste (Toy Train)

Toy train made up of match box

• Bogies are made up of Match box 
• Tyres are buttons
• Tracks are made up of sticks and matches

Creativity by Rinku - Best out of waste (House)

• Roof is made up of Pista shells
• Clouds are made up of Cotton
• Sun is Button
• Chimney borders are made up of sticks
• House black border is made of woolen threads
• Window's are made up of Aluminium foil
• Window's red border is made up of Red woolen threads
• Garden is made up of small chopped hand made paper
• Door handle and railings are made up of glitters

After Rinku's magical touch

Creativity by Rinku - Mural Name plate

Reading last few lines from a log file using perl

Hi,

Today I will explain you the program which will help you read whole log file or last given number of lines in a file.

use strict;

my $argc = scalar(@ARGV);

# validate command line arguments
if ($argc eq 0)
{
    print "Error :: Log file not provided\n";
    print "\nUsage\n\n";
    print "$0 \n";
    print "where,\n";
    print "log file name = Fully qualified name of the log file\n";
    print "number of last records = Optional parameter.  Specify the number of last  records you want to read\n";
    exit;
}
my $log_file = $ARGV[0];
my $number_of_records = $ARGV[1];

if (not defined $number_of_records)
{
    $number_of_records = "";
}

unless (-e $log_file)
{
    die "Error :: $log_file doesn't exist\n";
}

# Define variables.

my $current_line = 0; # determine current position in file
my $seek_line = 0; # determines line number where we want to jump and start reading


# Get total number of lines from the file
open (FI, $log_file) or die $!;
while ()
{}
my $lines = $.;
close(FI);

print "\nTotal number of lines in file = $lines\n";

if ($number_of_records ne "")
{
    $seek_line = $lines - $number_of_records;
}

print "Seeking line number $seek_line\n";

open (LOG, $log_file) or die $!;
while ()
{
    my $str = $_;

    $current_line++;
    next if ($current_line <= $seek_line);

    chomp ($str);
    print "line number $current_line: $str\n";
}
close(LOG);

Common programming mistakes

Every programmer makes mistake and this is accepted globally as unwritten truth.  And most of the time developer doesn't know what mistakes they are making.  Here are my list of top mistakes to avoid.

Lack of security

There are two aspects programmers forget while coding the system.

1. Strategic aspects
Most programmers start coding the applications with the view of implementing the features from the default security perspective of "allowing all" the user to access and then will start to implement security for the elements (See Tactical aspects & suggestion on which elements to secure).
This happens across the board. Everything from operating systems to fat clients to web-based thin clients are constructed this way.

My strategic suggestion is to start coding from a default perspective of giving "deny all" access to every architectural element, every layer, every object, every method, every variable, etc., and construct them to be inaccessible to anything unless you expressly allow it. This will slow down your productivity a little (at least at first). However, once system is coded this way the delivered code and system will be vastly more secure.

Also, another rule for programmer is "Don't roll your own" or "Don't reinvent the wheel".   Unless you are yourself a security expert and/or cryptographer, always use a well-designed, well-tested, and mature security platform, framework, or library to do the work for you. These things have spent years being thought out, patched, updated, and examined by experts and hackers alike. You want to gain those advantages, not dismiss them by trying to reinvent the wheel.

Now, that's not to say you don't need to learn anything about security. You certainly need to know enough to understand what you're doing and make sure you're using the tools correctly. However, if you ever find yourself about to start writing your own cryptography algorithm, authentication system, input sanitizer, etc, stop, take a step back, and remember this rule.

2. Tactical aspects
In Tactical aspects, here are the common mistakes while coding security and things which every programmer should care about while coding the system.

• Not validating every bit of data from the client and user inputs
• Not considering filesystem permissions when working with files
• Not thinking about the database access permissions and keeping it too wide open for example, providing read-write access where only read is required
• Storing sensitive data in clear text like passwords, etc
• Not enforcing the strong passwords
• Thinking the user sees the system the programmer sees it
• Assuming system will never be attacked
• Thinking its Network Admin's responsibilities to provide security to the Network and applications
• Sending the sensitive data in query strings in websites
• Not taking care of hacking techniques like cross-scripting, SQL injections, etc
• Using third party libraries hastily without validating them
• Thinking login is the only page where security is needed.
• Creating backdoors for Administrative purposes

Improper Code Formatting

Easiest way to differentiate between experienced and inexperienced programmer is how they format their code.  Most of the programming languages doesn't give error because of bad formatting of the code like indentation, use of white space, etc but it makes code extremely unmanageable if its not formatted properly.  Programmers don't understand that indenting code makes one logical structure.  By indenting (using tabs and spaces) functions, loop, conditions, etc makes code readable and manageable not only for others but for ourselves as well. Bad formatted code becomes error prone and difficult to debug.

Another bad habit programmers have is to leave huge chunk of non-required commented code.  Almost everyone do this mistake thinking that we might need this in the future.  Its always good to remove the commented code if its not required.

Improper Variable and/or Function name

Sometimes its looks funny to us when some programmers use long function or variable names like fileForReading, but its actually good to have long meaningful name rather than short meaningless name.   If we give meaningful names to variables and functions then its intent becomes very clear not only while coding for the first time but also during the maintenance.  This will result in less errors as well because using non-meaningful name makes the probability of getting confused why this function and/or variable is created. Worst mistake developer can make is do the spelling mistakes while creating the variable names. It becomes difficult to remember the misspelt variable name and in high probability you will end up causing too many compiler errors. Its always better each developer makes its own naming convention as per their convenience as this will make them write the code faster and will reduce the compiler errors  as well.


Case sensitivity
Some programming languages are case sensitive and some are not. But its always better to use the cases (upper or lower) of the variable and function name properly.  This is also true while creating the hyperlinks and referencing the files.  Windows is case insensitive so it doesn't matter if you use /program or /Program but it does matter in non-windows platforms.  And when you are writing platform independent code always be careful about cases of the objects you use.  Also, each programming language comes with its own convention like Java recommends to use camel case convention where starting letter of first word should be in lowercase and starting letter of remaining words should be in upper case.  Java doesn't throw error if this convention is not used but it looks odd when this is not followed.

Lack of commenting and/or overcommenting

Lack of commenting and doing over-commenting both are crime.  Everyone should self-document their code where programmer explains the use of the variable, function and class names, and overall architecture and communicate the meaning of the code to other programmers and your future self without the need for lengthy comments. Whereas, over-commenting is also not required for example for code $a = $b; developer writes the comment like assigning value of $b to $a.  Even layman programmer can understand what is being done here.  These kind of commenting is useless.  Instead programmers should write why this is done.  We don't need to teach programing language in our code instead we should document how this program works

Not taking backup of your work

How many times does it happen to you that you lost important and good piece of work because you forgot to take backup or saved your programs and your machine restarted or malfunctioned.  There are ample tools available in market now which gives you benefit like auto-saving, versioning control system, etc.  While working on the open source projects I keep checking-in my code into SVN repository or Github which are free to use softwares.

Not using debugging tools

Almost every programming language comes with powerful debugging tool which gives detail errors and help you identify the bugs in your code easily. Some programming languages doesn't comes with inbuilt debugging tools and in that case printing the statement on console or external debugging tools are quite useful.  For example, while doing the web programming, I found developer tools like firebug extremely useful in not only finding the code issues but also the performance issues also.

Start coding without understanding the programming language

Programming languages are no different than our languages which we speak.  Programming languages have vocabulary, grammar and recommendations on how to use it.  Major mistake newbies usually do is start coding the stuff without properly understanding the power of programming language and end up writing lengthy codes which in fact can be done in couple of lines and in no time.

Coding without concentrating on the design

Most programmers are eager to start the coding for the new exciting project at hand.  In this hurry they forget to understand the design of the program and end up creating something which is not customers wanted.  Customer is king for any market and even though you wrote fantastic program which is not useful for customer then it would be of no use.  Most programmers doesn't understand the users perspective and only think from the programmers perspective. Sometimes programmers codes features which are not asked by the customer.  This creates lots of problem. This new feature is useful for the customer or not is another debate but if customer has not asked for this feature then it might not be on his priority list.  Also, this features needs to be tested thoroughly so it consumes more time whereas this time was scheduled for something else.  Also, most important because of free features given to customers, companies might be loosing good revenue opportunity.  So, moral of the story is to stick to the design.

I hope you have enjoyed my list. Keep Coding and enjoy programming.

Development or Scrum team role in Scrum

As we discussed in previous post Everything you want to know about Agile Scrum Team, there are 3 core roles in Scrum. We will discuss Third and the last of these 3 roles in detail which is Development or Scrum Team. 

The Development team or Scrum team (now onwards called scrum team) is responsible for delivering potentially shippable increments (PSI) of the product (Sprint Goals) at the end of each Sprint.  The Scrum Team builds the product that the customer is going to consume like the software, website, etc.  High performing scrum teams are highly collaborative and self-organizing with a very high degree of autonomy and accountability.  The Scrum teams are "cross-functional" and it includes all the expertise necessary to deliver the PSI.

Effectively the Scrum teams are made up of 7 individuals plus or minus 2 with the cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.) but can scale up using scrum of scrums.  Also, see Agile Methodology Myths busted. Fewer team members and the team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead starts to get excessive.

The Scrum team have total authority over how the work gets done, which tools & techniques to use, and which team members will work on which tasks. The people who do the work are the highest authorities on how best to do it.  Similarly, if the business needs schedule estimates, it is the team members who should create these estimates.

The Scrum team should possess all of the skills required to create a potentially shippable product. Most often, this means we will have a team of specialists, each with their own skills to contribute to the team's success.

The Scrum Team has the following responsibilities:

• Is cross-functional, with seven (plus/minus two) individuals
• Selects the Sprint goal and specifies work results
• Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal
• Organizes itself and its work
• Demos work results to the Product Owner.
• responsible for completing user stories to incrementally increase the value of the product
• self-organizes to get all of the necessary work done
• creates and owns the estimates
• owns the “ how to do the work” decisions
• avoids siloed “not my job” thinking

 

Scrum Master role in Scrum

As we discussed in previous post Everything you want to know about Agile Scrum Team, there are 3 core roles in Scrum. We will discuss second of these 3 roles in detail which is Scrum Master.

The Scrum Master is the facilitator for the development team which uses Scrum.   The Scrum Master is responsible for making sure a Scrum team lives by the values and practices of Scrum. The Scrum Master is accountable for removing impediments (obstacles) so that team is able to deliver the committed product goals and deliverables. The Scrum Master makes sure that team do not over-commit or under-commit on the stories during a sprint.

The Scrum Master is not a traditional Team Lead or Project Manager role.  The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of the rules of the Scrum, Chairs meetings, and challenges the team to improve.  The Scrum master role excludes any people management responsibilities.  There is no role of project manager in Scrum at all and their responsibilities are divided up among the three Scrum roles.

The Scrum Master facilitates the daily standup meeting also called scrum meeting and becomes responsible for removing impediments that are brought up by the team during scrum meeting. The Scrum Master is not the project leader and cannot be not held accountable for outcomes.  The team as a whole is responsible for outcomes.

The Scrum Master has the following responsibilities:

• Helps team to reach consensus for what can be achieved during the sprint
• Represents management to the project
• Is responsible for enforcing the rules of the scrum
• Runs the Daily stand-up Scrum meetings
• Removes impediments
• Shields the team from external interferences and distractions
• Ensures that the team is fully functional and productive
• Enables close cooperation across all roles and functions
• Helps team to stay focused

Product Owner role in Scrum

As we discussed in previous post Everything you want to know about Agile Scrum Team, there are 3 core roles in Scrum. We will discuss first of these 3 roles in detail which is Product Owner.

Scrum Product Owner is a Project's key stakeholder.  The Product Owner represents the stakeholders and is the voice of the customers.  The Product Owner have a vision of what he/she wishes to build and convey that vision to the scrum team.  This is most important for the successful starting of any Agile software development project.  He/She is accountable for ensuring that the team delivers value to the business. The Product Owner does this by writing or having team write customer-centric features called user stories.  The Product Owner then ranks and prioritizes these user stories and creates/adds them to the list of product features which is called product backlog. 

Scrum teams should have only one Product Owner and this role should never be combined with that of Scrum Master. Product Owner is often combined with the role of Project Manager as they have the best visibility regarding the scope of work.  The Product Owner is the person having solid understanding of the users, the market place, competition, etc


The Product Owner has the following responsibilities:

• Holds the vision for the product;
• Represents the customers
• Owns product backlog
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every 30 days, as needed
• Accept or reject work results
• remains available to answer developers questions

The product owner is responsible for the first of the three Scrum ceremonies : Sprint Planning
The Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog.

In return for the Scrum team's commitment to completing the selected tasks, the Product Owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.

The best product owners show commitment by doing whatever is necessary to build the best product possible – and that means being actively engaged with their teams. Business savvy is important trait for the agile product owner because he or she is the decision maker regarding what features the product will have. That means, the agile Product Owner should understand the market, the customer and the business in order to make sound decisions.

Finally, communication is a large part of the product owner responsibilities. The product owner role requires working closely with key stakeholders throughout the organization and beyond, so he or she must be able to communicate different messages to different people about the project at any given time.

Taking backup of Filezilla FTP client settings

Hi Friends,

I use FileZilla FTP client to transfer files using FTP.  I found it amazing and got it for free from https://wiki.filezilla-project.org/Main_Page

I have stored many sites in site manager with various kinds of settings so that I can quickly connect to these FTP sites and reach the desired location as soon as I connect to those FTP sites. Many times I wanted to transfer these site's and other settings onto some other machines due to change of machines, machine reformatting, etc.

Here are the easy techniques to take backup and restore the FileZilla client settings.

Option-1:  Export one particular site only
If you want to export only one site from the list of sites then follow simple steps below:

1. Open site Manager either by clicking ctrl+s or from File->Site Manager menu






2. Right click and select export.




3. Save it by giving some meaningful name.  It will create xml file

4. Copy this xml file to new machine and import it from File->Import menu



Option-2:  Export all the site only
If you want to export only one site from the list of sites then follow simple steps below:

1. From File->Export menu



2. Select the categories you want to export. It gives 3 categories to export as shown in screenshot below.





3. Save it by giving some meaningful name.  It will create xml file

4. Copy this xml file to new machine and import it from File->Import menu