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 deviations in future. Team also brainstorms idea…

SCRUM- Who should write a user story

Traditionally user stories (or requirements) were written by Business analysts. They used to prepare big documents after months of study. It was a herculean task. I used to get such UI/Functional specification documents. I have fixed a lot of bugs because I missed few text in such 1000 + pages document. This is not the only interesting part. Some of the requirements were so weird that I often wondered why I am creating the features which no one is going to use. If I had the option I would have recommended a better option. If the BA’s misunderstood some requirements & customers failed to correct those few words in the epic requirement then we will have a nice situation.
In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s... anyone can upd…

What are the rules of scrum?

A relatively new person to scrum asked me this question last day. My answer to that person was yes. But really does the scrum have any rules? Scrum is a framework which helps us in developing software. It has very few rules and apart from those basic rules rest of them are guidelines like best practices.

Some of the rules 

The roles of Scrum
•Scrum Master - http://www.theagileschool.com/2012/03/scrummasters-checklist-roles.html
•Product Owner
•Feature TeamThe PDCA cycle (http://www.theagileschool.com/2012/05/pdca-scrum-or-agile-why-is-it-important.html )  frequent communication about risks (daily)
•Plan – Sprint planning
•Do – Actual engineering sprint – deliver a potential shippable code
•Check – Sprint review
•Act – Retrospective 
The scrum guide @ http://www.scrum.org/Scrum-Guides will be a good guideline for teams/companies planning to start scrum. If you are following the recommendation in these then you are following scrum.
Apart from these rest of the ceremonies and artifacts are there…