Skip to main content

How scrum training can help an individual or team?



We hear all the good things about agile and scrum.  With all these trainings a gradual mindset change happens. Recently a friend of mine asked why I am so passionate about scrum and what is the change I observe in myself because of this over the years.

The certification training (and other scrum trainings) I received were a major eye opener for me.
One of the key changes was the accountability aspect.  Previously team members were accountable to the work they do, work assignments was happening directly from Project manager. They usually don’t worry about the other areas in project. The change from my work to team work was wonderful. Many times Product Owner is tempted to assign work directly but since I knew the dangers of this allocation I can oppose it strongly. This helped the team to decide and assign work themselves. Now whenever I hear “my work” or “my bug” I used to have crucial conversations with team and direct them towards “our work” philosophy.  We shifted our focus from individual brilliance to team brilliance. This forced the team to work together. This shift helped me promoting the paired programming in team. This also helped us bridge the divide between development and test engineers. The focus shifted from reporting number of bugs or closing number of bugs to preventing the occurrence of bugs. Entire team was made responsible for the sprint success. Previously the appraisal metrics were based on the number bugs opened or closed now we are in the process of complete revamp of this appraisal policy.

Scrum fosters the idea of team. With more face to face communication and task ownership I find working in a scrum team more enjoyable.

Another important change was with respect to vertical slicing and continuous refactoring. This helped to focus on small tasks doing only what is required. Tracking these small tasks becomes much easier.  Previously if I had to create a data access layer I will create all the functions required in one single stretch. Many such functions were rarely used. It used to take a lot of time also to create such rarely used functions.  These continuous refactoring and focus on small important tasks helped to minimize the waste.  Now when I have to create software I will think of using a robust design pattern and adding only the functions which is required for the functionality in the sprint. This helped me to challenge the big architectures & big estimates.  This is helping me and the team to minimize a lot of waste and concentrate on only the most important functions.

Another major shift/change I observe is in the release planning. Scrum helped me to create a proper release plan based on the realities. I was able to show the capacity of the team and risks involved. Before we adopted scrum my team used to spend couple of months in office adding new features and fixing the issues just before the release. The pressure on the team was huge. With the knowledge I gained in training I was able to able to organize the product backlog based on the priority and team’s velocity. Everyone knew much before what can be achieved with the current team.  We were able to have fruitful conversation with customers. It was a win-win situation for all. Based on the projection customers can reprioritize the features. They had more options. Team members were happy because there was no un-necessary pressure on them.

I can write pages about the benefits but for the time being I believe this is sufficient.

Comments

Popular posts from this blog

PDCA & SCRUM (or Agile); Why is it important?

The PDCA (Plan DO Check Act) cycle was made popular by Dr. W. Edwards Deming. This is a scientific cyclic process which can be used to improve the process (or product). This is cyclic in nature and usually time boxed. Plan  This is the first stage of the process. During this step the team discusses the objectives, the process and the clear conditions of exit (conditions of acceptance). This stage sets the measurable and achievable goals for the team. DO Team works together to achieve the objective set in the planning phase. Team works with the set of agreed process. Check Once the implantation is done team regroups and verifies the output and compares it to the agreed conditions of acceptance decided during the planning phase. The deviation, if any, is noted down. ACT If any deviation in planned tasks is observed during the Check stage, a root cause analysis is conducted. Team brainstorms and identifies the changes required to prevent such deviatio...

SQL Server: GETDATE() & GETUTCDATE() & different time zones

Most of us will use GetDate() function for providing default value in SQL server columns. This function Returns the current database system timestamp as a   datetime   value without the database time zone offset. This value is derived from the operating system of the computer on which the instance of SQL Server is running. This works perfectly if you don’t have to show reports and such stuffs for users from different time zones. In case you want to store time independent of time zones in some universal format; what will do? Well there is GetUtcDate() function for you. This function will return then UTC date based on the setting of the server on which SQL server is installed. I executed the following function & I got the two different date output values. SELECT  GETDATE() AS Expr1, GETUTCDATE () AS Expr2 2/28/2010 1:27:17 PM ,  2/28/2010 7:57:17 AM SQL Server 2008 SQL Server 2008 has two new DataTypes: date & time You can use them to ret...

Product Backlog: Should you write everything in user story format?

I like user stories a lot. They help everyone talk the same language and results in a better product. User story alone does not constitute product requirement. User story is supposed to be a place holder for discussion which should happen between the team, Product Owner and the customer. This discussion result in a common understanding which along with the user story content is the product requirement. This format captures the essence of requirement without confusing the readers User Story is only one of the many different ways in which requirements can be represented. This is not mandatory in any Agile “process”. But many have made this mandatory. I have seen many spending countless hours trying to write the requirements in user story format when they could have easily written that in simple one-line sentence in few minutes.   I have seen team members refusing to even discuss the requirement until product owner rewrote the requirement in user story format. ...