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

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 up

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 Team The 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

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