Agile : Self Aligned Team Are the Best Teams

Agile Software Methodology  Believes in Servant Leadership. This Leadership is from the Bible.:-

Jesus Christ mentions in the Bible, "For who is greater, the one who is at the table or the one who serves? Is it not the one who is at the table? But I am among you as one who serves" Luke 22:27.

It is key to follow this style in Agile. You cannot question the team often and micro-manage people. You need to serve the team and facilitate the team and the team are empowered to make various decisions. You provide the goals and ask them to achieve it and you observe and continuously check how to help them and continuously keep giving them options and ideas of they are running into problems and let the teams are empowered to  decide how to solve it. This way the teams will be self-aligned. The Best Teams are always Self Aligned Teams.

[Share this on your Facebook, Twitter, Linked, Google, etc -If if you like this]

Agile Principle of Servant Leadership Comes from Jesus Christ

Agile Software Methodology  Believes in Servant Leadership. This Leadership is from the Bible.:-

Jesus Christ mentions in the Bible, "For who is greater, the one who is at the table or the one who serves? Is it not the one who is at the table? But I am among you as one who serves" Luke 22:27.

It is key to follow this style in Agile. You cannot question the team often and micro-manage people. You need to serve the team and facilitate the team and the team are empowered to make various decisions. You provide the goals and ask them to achieve it and you observe and continuously check how to help them and continuously keep giving them options and ideas of they are running into problems and let the teams are empowered to  decide how to solve it. This way the teams will be self-aligned. The Best Teams are always Self Aligned Teams.

[Share this on your Facebook, Twitter, Linked, Google, etc -If if you like this]

Why People Dont LIke Agile? or Why are people Anti Agile? (How to Overcome it)

Why People Dont LIke Agile? or Why are people Anti Agile?

 Daily  Stand up Meetings : Have to have daily stand up meetings and need to be in office at a particular time. 

 Peer Pressure : Constant peer pressure to deliver  stories. 

 Less Design and often teams feel road-map to code is missing. 

Bigger Picture: Team does not feel they have the bigger picture and they work on assigned stories. 

Requirements Constantly Change  and teams that don't have flexibility starts to dislike it. 

Dislike Stories : New teams dislike stories and likes to see the requirements and functionality in a visible manner in the form of Functional Specification document, GUI,etc.

Customer needs Constant Demo: this leads to team to feel they have to deliver often and feel pressured. 

Micro Managed : Teams feel they are being micro managed. since the scrum master often run the meeting like a status meeting. 

[Most of the issues are since you are new to agile, once you understand the spirit of agile and change your mindset to agile mindset you will love agile. Scurm Masters, Managers, teams needs to have multiple training to understand their roles well before they play it. ]

Customers Love Agile

Customers Love Agile: Since they can see results faster since no upfront lot of time wasted on design.

 Customers Love Agile:  since they can take in new requirements often and across the release and no freeze to requirements most of the time. 

 Customers Love Agile since they can constantly see new sub-features working regularly and can               comment and change things in case they feel things needs to change for the sub-feature. 


[Please comment below and Post this article  in your Facebook, Twitter, Linked-In, Whats-app, Google Accounts, Forward to your Company allowed mailing list if applicable also   if you find this useful]

Agile Retrospective Make it Pro-active and not Reactive For Better Efficiency and Results.

Agile Retrospective Make it Pro-active and not Reactive For Better Efficiency and Results.

Agile retrospective team gets together end of every sprint/iteration to check what went right and what did not go right and what improvements needs to be done. In this phase please be aware that teams often take actions for things that did not go right. These actions have to be taken so that it does not just solve the problem with the actions but in future in all the upcoming iterations and releases these similar issues should never occur again. So a framework or mechanism has to be made in place so that this issue never occurs again and it will proactively solve this issue for all releases.  Let me give an example:-

Example:

Retrospective Issue: Defects did not have adequate impacting testing leading to more induced defects and defect testing field in the BugZilla tool did not have this field filled.

 Corrective Action: Ensure team fills the impacting testing column to the BugZilla tool (so that adequate impacting testing is done for the defect and constant audit is done).

Preventive Action: Ensure that the impacting testing column in the Bugzilla is a mandatory field to fill (so that team will do impacting testing for the defects) and start automating all the impacting test cases (if not automated).

[Please comment below and Post this article  in your Facebook, Twitter, Linked-In, Whats-app, Google Accounts, Forward to your Company allowed mailing list if applicable also   if you find this useful]

Agile Stand-up Meeting is Not a Full Fledged Status Meeting (No Micro Management is allowed)

 Agile Stand-up Meeting is Not a Full Fledged Status Meeting 

Agile Stand up is not a full-fledged status meeting. Often Scrum Masters ask many questions in the meeting to the team members of the status and they get frustrated and they often feel they are micro-managed and the short meeting becomes a long time. Even though stand up meetings turn out to be to some extend as a status meeting, it is not a full-fledged status meeting.  Agile Stand up meeting is done with the intention to know what he/she achieved yesterday,  what he/she will do today  and what help or obstacles are blocking them to achieve it and how the scrum master and management can help them to achieve it. The teams are empowered to make decisions and meeting is required to be short. Scrum Masters cannot become micro-managers in this meeting. 

[ Comment below and share this blog   in your Facebook, Twitter, Linked-In, Whats-app, Google Accounts, Forward to your Company allowed mailing list if applicable also   if you find this useful]

Velocity Increase (Marry Agile and Technical Management Strongly)

Velocity Increase (Marry Agile and Technical Management Strongly)

Often you find in-spite of doing everything done right in Agile, people-management, project management, process management and communication management. The velocity of team is not going high. This is because for technical folks you need strong technical management. Technical team’s needs technical directions and technical saviness build into them to increase the velocity. Technical Management includes:-

·         Identifying along with Architects who are the technical leads in the team.

·         Make Design and Architecture scores so that nothing is lost during it.

·         Identify clear review time for code review, etc and which lead will be handling it.

·         Identify technical trainings the team needs and propose to managers.

·         Identify latest technologies and tech talks to the teams.

·         Identify technical risks.

·         ,etc,etc,etc

If a developer has a strong road map in his mind before he codes due to good design and understanding, he will be able to code it faster and increase his velocity. This is one way a developer can increase velocity.