Stop telling your employees what to do

Stop Telling Your Employees What to Do http://blogs.hbr.org/cs/2013/04/stop_telling_your_employees_wh.html

Why big IT projects always go wrong

Role and responsibilities of QA/tester in scrum/Agile world; How Agile improves the testing of software.

In traditional software development model QA/testers were actively involved in only certain phases of the project. After development finishes the coding the entire project was handed over to QA. In many cases QA and developer wouldn’t even know each other. All the communication will be through email or bug tracking system. I remember one instance when my project manager relocated the entire QA team to another building!!! He didn’t want the QA and development team to communicate face to face. We had different competency centers for QA and development teams with different career objectives and career ladder.   The QA team had a separate identity, a feeling of ownership over an entire phase of product. They were called the gatekeepers of quality.

Don’t fear the change

But in scrum apart from the sprint cycles there are no definite phases. In scrum there is a big change in the way team operates and interacts. In scrum there is no differentiation between a QA and developer. Scrum just treats them as two separate individuals with specialized skills who work together to deliver a quality product after the sprint.

One team (mostly collocated)

In scrum QA and developer are part of the same team and collocated (mostly). This helps in a better communication and team bonding.  They learn from each other. More focus is given to communication and knowledge sharing.

Many say that in scrum there is no place for QA/testers. This is not reality. We still need QA; not the old QA but the smart agile QA. It’s not about the number of bugs anymore. It is all about the quality of application which is delivered to the customer.

A much bigger role

A tester in agile world has a much bigger role to play. He has to wear multiple hats and every day the old beliefs and practices will be challenged. Don’t oppose it, embrace the change, It is for good. A QA in no longer limited to writing test cases and creating bugs in bug tracking system.

Some Additional roles and responsibilities.

Requirements

Be an expert in the application domain. Testers should help the team and PO write COA’s for user stories. Testers should be able to challenge the existing COA’s and propose a better one. Help the team learn some industry standards like Gherkin for COA’s.

Pair Programming

Pair with other team members to discuss the PBI or bugs. Don’t expect the developers to fix a bug or finish a PBI and then provide a build to test. Don’t create a mini waterfall in sprints.

• Talk/discuss upfront about the possible impact of the change
• Create test cases & update your documentation
• Create test data or scripts

Developers are poor testers; help them to improve the testing skills. With the close interaction of testers, the unit testing will be improved. If the build is delayed, pair with the developer and test the fix in dev. machine. If you find any issues, later on it will save a lot of time in writing and explaining the new bug.

Test first approach

When team starts a new feature development, a tester can wear the customer hat and create acceptance test cases. I have seen in few projects where a new feature was introduced in release cycle and another PBI/bug was created to remove that on next release cycle!!!.  A proper understanding of the customer requirement would have prevented this situation (PO and other stakeholders should have handled this but that’s another level of discussion)

 

Design product suites

In big products multiple teams work on same products which are in turn linked to many other dependent products. I have seen few cases where the lack of cross product knowledge in teams has caused serious problems and issues. Testers can take this role of designing the features across the suite. If a feature was proposed for X product does it makes sense to move that to Y for a better customer satisfaction?

Improve metrics

Ask questions about the quality of the application. What is the test coverage of the features? Are there any performance issues? If the product has issues, then the QA engineers should always bring this to Product Owners and Scrum Masters attention. Work with them closely to reduce this technical debt.

Automation

The manual testing should be less than 10 % of the total testing.If the team is spending more than that then testers should learn any automation tools to automate the test cases. Without automation the life will be miserable. There is no value in doing the repeated work day after day. By automating the test cases the velocity of the team will increase drastically.

Exploratory testing

All the bugs cannot be found by automation tool. Always be ready to do exploratory testing with the new interfaces and products.  The unique skills of the QA will help the team to find and fix hidden bugs. If there is a pattern in these bugs, update the unit test cases or automation scripts.
In short a tester in an agile world is much powerful. A tester needs a change in identity – need a change in mindset to release software with a high quality each sprint. There is no glory in creating bugs in tracking system. Only thing which matters is zero defects with customer (if you can).There are no we testers and you developers.


Get in touch
Are you a tester /QA in agile world? Write to me about your challenges and your experience. I would love to hear from you. .

Read the following also

• Agile/Scrum Bug fixing: Myths & dysfunctions : http://www.theagileschool.com/2012/03/agilescrum-bug-fixing-myths.html
• Testing not complete during sprints - http://www.theagileschool.com/2012/02/scrum-quality-teams-not-delivering-high.html
• http://www.theagileschool.com/2012/02/importance-of-qulaity-in-agile-world.html
• Agile Testing: A Practical Guide for Testers and Agile Teams - http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468/

Pick of the day : Article - Boy Scout Rule Applied to Every Day Coding

this is a thought provoking article by  James Grenning

Boy Scout Rule Applied to Every Day Coding

http://www.renaissancesoftware.net/blog/archives/90

Whitepaper - Scrum : Agile innovation @ FedEx

Lighting Corporate Passion: Everything you need to know about FedEx Day

Introduction 

A FedEx Day is a 24-hour event in which employees deliver innovation to the company they work for.
It is called FedEx Day, because you have to deliver overnight, like the parcel delivery company. A FedEx Day is a fixed time box in which people are not disturbed for regular work. Within this time box, employees have total autonomy over the project they are enthusiastic about. They decide for themselves what they will be working on, who they are going to work with, and how they are going to do it.

Only one rule applies: 

People who sign up show the results to the company at the end of the FedEx Day. In short, a FedEx Day is about boosting motivation and creativity overnight by getting out of people’s way.

Business Model

The traditional business model regarding motivation is built around external motivators, the carrot and-stick motivation scheme. For simple, mechanical tasks, punishments prevent bad performance and higher incentives lead to higher performance. However, in more complex work, the majority of tasks in business require conceptual, creative thinking.

The traditional motivation scheme does not apply to these types of tasks. If you promise people higher rewards for better performance, scientific evidence shows that the results are worse. A FedEx Day can result in a boost of motivation and performance of your employees in only 24 hours (12 business hours).

Additionally many employees have great ideas for improving their work and the products of the company. Traditional management often does not provide the autonomy for employees to implement these ideas. Business is often hectic and the pressure on delivery is always there.
However, these employees often have the best innovative ideas, since they are the ones closest to the work. Organizing a FedEx Day provides a short time box of high-intensity work in which employees implement their ideas and present them to the company.

Read More  

Agile/Scrum - Continuous delivery - how to mange quality?

Scrum/Agile demands frequent delivery of software. Most of the companies develop software in a sprint of two weeks. (How to choose Sprint duration?) But many companies don’t release software that frequently. According to scrum principles software at the sprint end should be of shippable quality. But really is this the case?  Many teams who diligently deliver the software periodically complain that because of frequent release they are not able to fix all the bugs. Because of the number of bugs they have an affinity for longer sprint cycles. But in reality there is no co-relation between the sprint duration or release duration and the quality of the software produced after each sprint.

Slow down to move fast

If you or your team is in a vicious cycle of releasing software with bugs release after release – then stop what you are doing, review the process you are following

1. Review the definition of “done” – Schedule a meeting with all stakeholders, decide on a definition of done. Only thing you have to remember is that after the sprint cycle customer should be able to use the software
2. Too much content – If you deliver about average of 5 user stories per sprint cycle reduce it to 4 or 3. Then apply the definition of done. 
3. Responsible for quality - Ultimately it is the PO who is responsible for the quality of the application but then that don’t mean that others can’t question the bad practices. There is no value in delivering a software with low quality, be if bug or performance issues. If you allow such practices to continue one day you will realize that you have more than 100 bugs to fix or application is performing so badly that customers have stopped using it altogether. Such drastic results or consequences don’t happen in one day they occur because of the continuous negligence of the good practices day after day, sprint after sprint. 
4. Existing technical debts – There will be many cases when you inherit an old legacy application with lot of bugs and performance issues. You may be asked to deliver new features in every sprint. This is a very tricky situation which needs some careful analysis and thoughts. 

• Talk to the customers and stakeholders – identify the most important issues for them and create (& implement) a plan to solve them
• If a new feature is requested in the “problem” area inform the stakeholders about the dangers of making changes in those parts. Get a commitment from them to improve the areas. Try to convince them with figures. Few weeks back I produced an excel sheet with the hours spend in bug fixing one area of our application. The hours spend in bugs fixing was very high. It required only a fraction of that time to clean up the entire area. 

Some Additional links worth reading.

• Scrum quality – Teams not delivering high quality stories; testing not complete during sprints
• Scrum Sprint duration – which is ideal; 4 weeks or 2 Weeks or 1 Week? Checklist - 
• The Benefits of Regular Deployment - https://www.simple-talk.com/opinion/opinion-pieces/the-benefits-of-regular-deployment/

What powers does a Scrum Master need to have

I have seen this conflict in many organizations which are new to Scrum/Agile. Most of them are transitioning to agile methodologies from the traditional methods. It’s very difficult for that management to let go the power hierarchy. They still want one single neck to catch. They never believed in collective thinking. Rather than motivation , their believe in pressure to get the work done.

Such dysfunctions exists in most of the organizations, scrum just exposes it.

ScrumMaster doesn’t run the scrum. He/She should help build a team, bring out the leaders in every member of your team. ScrumMaster helps the team to self-organize so that they can move forward without the classic “delay” of waiting for decisions. ScrumMaster is not a person who can be used as a single neck to catch or blame. Scrum is a collective team approach. If it succeeds everyone succeeds if it fails everyone fails.

ScrumMasters in such an environment have to do a critical job in the transition. You will have to use all your patience & wisdom to convince the management about the true power of collective thinking and working towards a common goal. Take them into confidence. Inform the stakeholders about the perils of not doing the things in scrum way. Show them the benefits of this lean thinking. Once the management observes the success, once that trust is established you will get more help from management and other stakeholders.


Advice based on my experience.

If the team is unable to meet the commitment, do a retrospective to find the root cause, once the root cause is identified make the necessary changes so that it is not repeated. Provide this analysis to the management also.
Keep the communication channel open to educate the PO, team & other stakeholders about the technical debts. Have discussions about the cost of not doing the right thing

Most important focus

• Create a self-organizing team 
• Remove the impediments of the team
• Teach the team & company the values & principles of scrum
• Work the stakeholders to reduce the technical debts
• Be a coach & mentor for your team, help them take the correct decision 

Check the following article for more 
ScrumMaster’s Checklist - roles & responsibilities - http://www.theagileschool.com/2012/03/scrummasters-checklist-roles.html

If you take a pro-active approach then sure management will support you.

To do all these , as a ScrumMaster you might need the three most important powers :)

1. Patience
2. Strength & courage to take tough decisions & convince others.
3. Scrum Process knowledge & passion to improve every day. ( remember learning never stops)
4. Passion & commitment to improve the team & deliver value to the customers.

The Benefits of Regular Deployment

When developing software, it makes sense to 'fail early, fail often'; to become aware of mistakes quickly and to learn from them. This means being able to deliver software as early in development as possible. This makes it easier to gather opinions and promote discussions with the people who would want to use the application; and then respond to the feedback.

A nice article by James Moore


Read the full article @
https://www.simple-talk.com/opinion/opinion-pieces/the-benefits-of-regular-deployment/

The Benefits of Regular Deployment

Can a Scrum master be a developer also in the team?

A ScrumMaster needs a different skills and mindset than a normal developer.

I have worked in teams where I was part time scrum master & developer.  In many other projects I was full time Scrum Master.  Both projects were a success. Based on my experiences if I have to answer this question I will say that it depends on the project but given a choice I want my ScrumMaster to be fulltime.

Being a technical person helps the ScrumMaster to understand the language spoken by the team. But if he/she is also working as a part time developer then the Scrum Master will be more interested in finishing the bugs/Product Backlog Items. Then who will protect the team from PO & other stake holders?  Who will coach them? Few months’ back one of my colleagues complained that his ScrumMaster is interested in only in finishing the work, there was no feeling of being part of a team because the ScrumMaster was busy finishing his bugs. He rarely motivated the team.

 I came from a strong technical background. When I became the ScrumMaster for the first time, I had strong urges to run the technical meetings. Being a senior person in the team, when I presented the solution people readily accepted it. They very rarely challenged me. Scrum puts the onus on collective thinking but in this case I was the only person thinking.  Initially many in my team asked me to use my technical skills to deliver the content but I was more interested in creating a self-sustaining team.  If team needs the ScrumMaster’s  technical expertise, then there is a problem & an opportunity to improve the team.  Many ignore this and try to cover up this by filling that Gap.

In this situation I will ask the following question

Why do you need ScrumMaster’s technical help?

• Is there a lack of technical skills?
• Does the team lack application/domain expertize?
• Is there any attitude or team dynamics problem?
• Is the team balanced? Do they have sufficient number of people?

 Such questions will help the team to think & move forward. They may not like it initially but in the long run it will be the best decision. Treat the disease, not the symptoms.

Many think that ScrumMaster job is of an administrator but that is not true. Check the following article. Doing this with one team fulltime is nearly impossible and we are talking about appointing a single ScrumMaster for multiple teams or to save cost have a part-time ScrumMaster. By doing so, we will create more problems rather than solutions.

Are you against Scrum Master actively doing coding?


No. I am not against Scrum master doing coding or actively testing or creating the documentation for the software. I believe we should do everything under our capacity to give a quality output and satisfy our clients. If the scrum master is a good developer or architect then he should use his knowledge to teach his team. I was talking to one of my scrum master last day. He is a good developer. He used to fix the critical bugs in the application. Team was so used to him fixing the issues that, later on when a bug was reported from that area they refused to look into it asked the scrum master to fix it. Rather than enabler he became a bottleneck in teams development.

Remember the principle – “ Team them fishing, don’t give them fish”. As long as the scrum master uses his skills to team the team and he doesn’t becomes a bottleneck , do the coding.



When can we have a part time ScrumMaster/ScrumMaster with multiple teams?

• When the team ( PO & Scrum team ) is very matured 
• There is no change in Backlog. The team has a very steady backlog of Bugs or PBI which is written by a very good PO
• A very small team of 2-3 members which doesn’t have much work.
• R/D work which doesn’t involved outside party (this point is debatable) 

I have seen many debates on this. My only suggestion is to have a full-time Scrum Master if possible


Additional links

• ScrumMaster’s Checklist - roles & responsibilities -http://www.theagileschool.com/2012/03/scrummasters-checklist-roles.html
• Types of ScrumMaster - http://www.theagileschool.com/2012/02/types-of-scrum-master-do-we-need.html

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 

1. The roles of Scrum
   • Scrum Master - http://www.theagileschool.com/2012/03/scrummasters-checklist-roles.html
   • Product Owner
   • Feature Team
2. 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 the ceremonies and artifacts are there to help us improve the process. They are best practices. We can make changes in those to adapt to our needs. As we do scrum we will find problems, do a review and act on it, change the process and measure the success.

As your understanding of scrum improves,  you may changes few things. Check The agile manifesto http://agilemanifesto.org/ and see if the changes are in accordance with the principles. If yes go and make those changes, if the changes are against the principles discuss about that, talk to learned people (or contact me :D ). After the brainstorming session you may have a better idea. Implement it and measure the progress. Scrum is journey, you may have to adapt it according to your needs

Some other Guidelines

• Daily Scrum Meeting Rules - http://www.theagileschool.com/2012/03/daily-scrum-meeting-rules.html
• What is the right combination of a scrum team with respect to Developer- test break up- http://www.theagileschool.com/2012/07/what-is-right-combination-of-scrum-team.html
• How to estimate new/unknown areas?  http://www.theagileschool.com/2012/06/scrum-how-to-estimate-newunknown-areas.html
• Leveraging scrum for large projects (not large teams); number of scrum teams’ vs. team size http://www.theagileschool.com/2012/02/leveraging-scrum-for-large-projects-not.html

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.

What is the right combination of a scrum team with respect to Developer- test break up; Role of a tester/QA person in scrum team

Personally I feel that all in the team should understand all the stories which are going into the sprint. As soon as one task is finished he/she should take the next task in the backlog rather working on the “pet” or “my” areas. I usually hire developers who are willing to test also. If someone cannot understand the work done by the team even after repeated training then it is the job of HR and other functional managers to weed out such people.

Testers are intelligent people.  It doesn’t helps if they are doing monkey testing of application or writing long test cases which even they don’t refer. IMHO they should be the business domain experts. They should provide value to the customers and business with their domain knowledge. Many times I have seen testers asking the developers about the requirements.  They limit their testing to the knowledge acquired in such a way. More than just ensuring that the features developed is bug free the team should strive for excellence by providing value added services to the team, company and clients.

Ideal Role of testers in Scrum 

Review the product backlog pro-actively.
Help the Product Owner to create better COA’s (Conditions of acceptance)
Provide value added suggestions for feature improvements which can add value to the company & clients.
Write efficient test cases before the actual coding starts
Verify the features at the dev. box itself. I have seen high quality of the deliverable because of this step.
Pair with new team member. Walkthrough of the application features especially the regression areas.
Write automated test suites to prevent manual testing. (This will help in increasing the velocity of the team)


So back to the question: How many testers should be there in scrum team?


I can facilitate a team without even a single tester /QA person. In one of my team the QA people were not available for one full week because of an external training. We had to release a patch to production and unfortunately this legacy application didn’t have an automated test regression suite. So the developers tested the application. The feedback I got after that exercise was great. The developers simply loved testing. The application had many performance issues which they never got in the isolated development box. It was an eye opener to them.
In most of companies we will have a QA division. Ensure that they are part of the same scrum team. They should be co-located at the same place if possible. Ideally QA strength in scrum team should be around 20%-30%.

Scrum: How to estimate new/unknown areas?

Basic rule - “Never assume anything”.

Estimating something new is very difficult for all the teams. You can provide an estimate only if you have basic knowledge of the area.


Following are few guidelines

New Domain – New Product Owner

Ideally the Product Owners should have the required domain knowledge.

• If you are planning to get a new PO for the project, ask him (or her) to work with the existing PO. Even after the transition the old PO (if possible) should be available to help.
• Bring domain experts from other projects/department/companies for workshops/discussion/training.
• Ask the new team members to start executing the regression test cases to understand the business domain.
• Subscribe to articles, magazines related to the domain.

New Technology

• Do time boxed spikes but organize frequent feedback/brain storming sessions to discuss the new knowledge.
• Do a POC 
• Bring the experts for short talks/training if required.

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 ideas/process changes (including the scope changes and measurement metrics) which can result in a better process/product in next cycle or iteration.

Anyone with a basic understanding of scrum can correlate the scrum terminologies to this scientific approach.

• Plan – Sprint planning
• Do – Actual engineering sprint
• Check – Sprint review
• Act – Retrospective 

The process starts with a clear set of aim and acceptance criteria. There is no vague or misunderstanding. This helps to minimize the waste. The group knows what to do and have proper guideline to achieve it. The verification of the planned tasks also happens against the known acceptance criteria. The process helps the team to make small changes get feedback and move ahead. The inspection and adaption helps the team to grow.  The end customer is happy because he can see the output quickly and can make the changes based on the market conditions.

• http://en.wikipedia.org/wiki/PDCA
• http://www.lean.org/Common/LexiconTerm.aspx?termid=287&height=550&width=700

Team ratings in Scrum environment – How to measure individual performances

Measuring the individual performance in a scrum world is a very difficult proposition; in fact it is a paradox. Last day I had an interesting discussion on this with few scrum masters. One of the scrum master had a rating sheet which was updated after every sprint. There were points for scrum master, product owner & team. It was something like the following table

Another scrum master questioned the need of such ratings. A rating of 2.5, 4.5 or 4 doesn’t have any significance. It looks like the GPA score. If I get 9+ I will be considered brilliant; if I get less than 5 then I am a dumb, second class person. A Scrum Master with a very high score & team with low score don’t make any sense. It creates un-necessary competition.

 

Scrum is all about team work. It is a well-oiled machine. There is no individual superstar. Everyone has a part to play. If everyone performs their part to perfection, the full team including the SM & PO will get full marks. But I am not against ratings. These ratings should help the team and individuals to improve.

 

The ABCD of performance ratings

 

Personally I prefer a grading system like the one below.

 

 

• A = Extraordinary effort. Did more than what was expected with lot of innovations 
• B= Good effort, Met all the objectives of sprint & individual role.
• C=Satisfactory, all the objectives of the sprint were not met. There is lot of scope for improvement.
• D=Total disaster. (Can we replace this person?)

 

Giving ABCD grades is better than the numeric ratings. All the A’s are the examples of best practices; definitely you should share this with other teams. Team should try to convert all B’s to A’s. Here we need some innovation or out of box thinking. A new team will have lot of C’s . Initially this is a good thing to have. Scrum masters (& all others who can) should facilitate the removal of the impediments so that C is transformed to B. D is a special case. Special attention should be given to such cases. If the D’s are repeated for couple of sprints then, we should take the help of managers or HR. If you need some sort of individual performance metrics, just add all the A’s, B’s & C’s. (All the D’s will be out of the team or even company)

 

The UP –DOWN rating

 

Even this ABCD rating seems complex to me.

 

Just like scrum this method doesn’t have many rules (only common sense). Up arrow indicates that an improvement was made with respect to the role or task taken. The improvement should be noted & process which led to this should be identified and shared across.

A horizontal arrow indicates that the person has achieved what was expected from him/her. This doesn’t means that there is no scope of improvement. If we see this arrow consistently across multiple columns in multiple sprints then it is a pointer that the team & environment has stabilized. This is the right time to brainstorm to find better ideas which can improve the team productivity.

A down arrow points to the need of an action item to improve the process (or skill). Almost all the down arrows become a point for retrospective discussion. Like the ABCD ratings we can count the number & type of arrows to indicate the health & performance of an individual or overall team.

 

Scrum release planning: How to involve Juniors & Seniors & people from different background

Doing release estimation for a team is always tricky especially if the team is new or has a mix of people with different skills or experiences. Traditionally project managers did the estimates and in most of the cases it was under-estimated. Usually the PM takes the help from some subject matter experts before arriving at these estimates. Team will burn the midnight oil (or lamps :D, I hope they didn’t really burn it , there were many occasions when I wanted my PM to be burnt instead. ) But with scrum the estimation is the team’s responsibility. When I talk about this concept I get a lot of questions like the below

• How can a bunch of people with different technical & domain skills estimate?
• How can we trust the estimates from team, they will always over-estimate.
• It is a waste of time, with so many people involved; it will be a never ending exercise.
• The senior folks will do the estimation & juniors will go along with it without asking any questions. 

The questions are endless.

Estimates from a group of people are far better than an individual. It is better to have the estimates from the people who are going to develop the product. They will do an estimate by considering their strengths and weakness. If there is a domain/technical knowledge gap then they will be able to discuss and bridge this gap. This looks rosy, a silver bullet for all the estimation problems. Such silver bullet is not produced from vacuum; lot of work has to be done to make this bullet. Many teams find this group estimation very difficult & time consuming especially when they have a sizeable number of new people or junior resources. (I have seen experienced people also failing in this) These teams fail because they were not prepared for such an exercise.

Following are some good practices to prepare your team for release planning 

Training Plan for new/junior resources

You should have a training plan for any new resources in team. I suggest that every new team member should execute the regression test cases at least once even if they are developers or testers. This will ensure a common playground when the application features are discussed.   Everyone will understand and will contribute positively to the discussions.

For any new feature do the release planning in the following fashion 

• Before you start ask the Product Owner to provide a high level overview of the features which are to be estimated. 
• Divide your team into sub teams with a mix of Sr. developers, Jr. Developers & QA.
• Assign each sub team one story from the backlog.
• Ask the sub team to breakdown the story into vertical slices. 
• This should be done in a time box 
• After the time box expires, exchange the notes with other team. 
• Review the notes received from other team and add any slices missing from the card
• After the cards are reviewed by all, you can proceed with story pointing. 
• It is the job of the scrum master to ensure that everyone speaks up. If the story is really difficult or complex then separate meetings should be set up. 
• In one of my team, we used to schedule weekly meetings to discuss the upcoming features. In the first part of the meeting we discussed the story; the later part was reserved for all the technical discussions for the story. We used to discuss about the design patterns, the functions to be changed, the need of database script etc.  Usually we identify a lot of unknown, which were duly noted down. Based on our capacity we used to do the spikes on these unknowns and provide the answers in our next design meetings. 

You may solve the lack of domain knowledge in this manner.

Technical Knowledge 

The technical part is more difficult. It depends on the quality of resources you have. If you have good engineering practices like TDD, BDD then the transition will be fast.
When a techie joins our team we give a session on the business domain & technical aspects of the projects. We do a walkthrough of all the major classes and functions.
In my team we have a buddy system; a junior resource is assigned to experienced person. It is the duty of the Sr. guy to mentor the new resource and bring them up to the speed. The pair is given the complete freedom to choose the methods to achieve this goal. Sometime it could be pair programming sometimes it could be a detailed discussion sessions or anything that works.

The less experienced people might work in a module which they are not familiar but if you have god plan of initiation, do a good release plan & have a good technical practices then the transitions will be easy & new people should pick up the knowledge very easily. They might ask few extra questions & may take few hours more but it will benefit the team. I like this level of discussions and noise; I will be worried if people don’t make much noise or don’t ask any questions.

DatabaseFactory.CreateDatabase error- Object synchronization method was called from an unsynchronized block of code.

http://thenetschool.blogspot.in/2012/06/databasefactorycreatedatabase-error.html

ScrumMaster’s Checklist - roles & responsibilities

Last few days many have asked me about the roles & duties of a Scrum Master ( and some even the need of an SM in organization ).

Following is one of the best checklist which I could find. I am willing to help anyone if they need further clarifications.

A ScrumMaster’s Checklist
Posted by Michael James on August 13, 2007


An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things you didn’t previously consider possible, within a transformed organization — consider being a great ScrumMaster.

A great ScrumMaster can handle one team at a time.

We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.
If you haven’t discovered all the work there is to do, tune in to your Product Owner, your team, your team’s engineering practices, and the organization outside your team. While there’s no single prescription, I’ve outlined some things I’ve seen ScrumMasters overlook.

A.     How is my Product Owner doing? You improve the Product Owner’s effectiveness by helping maintain the Product Backlog and release plan. (Note that only the Product Owner may prioritize the backlog.)

• Is the Product Backlog prioritized according to his/her latest thinking?
• Are all the requirements and desirements from all stakeholders for the product captured in the backlog? Remember the backlog is emergent
• Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It’s counterproductive to overanalyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers.
• Could any requirements (especially those near the top of the Product Backlog) be better expressed as independent, negotiable, valuable, estimable, small, and testable user stories?
• Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be adding automated test and refactoring to the definition of “done” for each backlog item.
• Is the backlog an information radiator, highly visible to all stakeholders?
• If you’re using an automated tool for backlog management, does everyone know how to use it easily? Automated management tools introduce the danger of becoming information refrigerators without active radiation from the ScrumMaster.
• Are you working with the tool supplier to use it to its fullest capacity, or to change it to serve you better?
• Can you help radiate by showing everyone printouts?
• Can you help radiate by creating big visible charts?
• Have you helped your Product Owner organize backlog items into appropriate releases (or front burner, back burner, fridge)?
• Do all stakeholders (including the team) know whether the release plan still matches reality, based on the current velocity (story points per Sprint)?
• Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product Owners who ship adequately tested products on time replan the release every Sprint, usually deferring some work for future releases as more important work is discovered. You might try showing everyone the Mike Cohn-style Product/Release Burndown Charts after the items have been acknowledged as “done” during every Sprint Review Meeting. This allows early discovery of scope/schedule drift.

B.    How is my team doing?

• Are team members spending some of their time in the state of flow? Some characteristics of this state (from Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi)
  • Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one’s skill set and abilities).
  • Concentrating and focusing, a high degree of concentration on a limited field of attention.
  • A loss of the feeling of self-consciousness, the merging of action and awareness.
  • Distorted sense of time – one’s subjective experience of time is altered.
  •  Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
  • Balance between ability level and challenge (the activity is neither too easy nor too difficult).
  • A sense of personal control over the situation or activity.
  • The activity is intrinsically rewarding, so there is an effortlessness of action.
• Do team members seem to like each other, goof off together, and celebrate each other’s success?
• Do team members hold each other accountable to high standards, and challenge each other to grow?
• Are there issues/opportunities the team isn’t discussing because they’re too uncomfortable? See Crucial Conversations: Tools for Talking When Stakes are High. Or consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable
• Have you tried a variety of formats and locations for Sprint Retrospective Meetings? See Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen) for some ideas.
• Has the team kept focus on acceptance criteria? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the product backlog items committed for this Sprint. Will the current Sprint Task list satisfy the acceptance criteria of each committed product backlog item?
• Does the Sprint Task list reflect what the team is actually doing?
•  Are your team’s task estimates and/or your taskboard up to date?
• Are the team self-management artifacts (taskboard, Sprint Burndown Chart, etc.) visible to the team, convenient for the team to use?
• Are these artifacts adequately protected from micromanagers?
• Do team members volunteer for tasks?
• Are technical debt repayment items (sapping your team’s velocity) captured in the backlog, or otherwise communicated with the Product Owner?
• Are team members checking their job titles at the door of the team room?
• Does the entire team consider itself collectively responsible for testing, user documentation, etc.?
• Is management measuring the team by collective success?

C.    How are our engineering practices doing?

•  Does your system in development have a “push to test” button so that anyone (same team or different team) can conveniently detect when they’ve broken it? Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).
• Do you have an appropriate balance between automated end-to-end system tests (a.k.a. “functional tests”) and automated unit tests?
• Is the team writing both system “functional” tests and unit tests in the same language as the system they’re developing (rather than using proprietary scripting languages or capture playback tools only a subset of the team knows how to maintain)? It’s possible.
• Has your team discovered the useful gray area between system tests and unit tests?
• Does a continuous integration server automatically sound an alarm within an hour (or minutes) of someone causing a regression failure? (“Daily builds are for wimps.” — Kent Beck)
• Do all tests roll up into the continuous integration server result?
• Have team members discovered the joy of continuous design and constant refactoring , as an alternative to Big Up Front Design? Refactoring has a strict definition: changing the internal structure of a system without changing its external behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling between objects, etc. Refactoring with confidence is only possible with automated test coverage. Holes in test coverage and deferred refactoring are cancers called technical debt.
• Does your definition of “done” (acceptance criteria) for each functional Product Backlog Item include full automated test coverage and refactoring?  Youʼre unlikely to build a potentially-shippable products every Sprint without learning eXtreme Programming practices (as described by Kent Beck, Ron Jeffries, etc.).
• Are team members pair programming most of the time? Pair programming dramatically increases code maintainability and reduces bug rates. But it challenges people’s boundaries and sometimes seems to take longer (if we put quantity over quality). Rather than force people to do this, lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way.

D.    How is the organization doing?

• Is the appropriate amount of inter-team communication happening? Scrum of Scrums is only one way to achieve this.
• Are your ScrumMasters meeting with each other, working the organizational impediments list?
• When appropriate, are the organizational impediments pasted to the wall of the development director’s office? Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But remember Ken Schwaber’s discovery: “A dead ScrumMaster is a useless ScrumMaster.”)
• Is your organization one of the few with career paths compatible with the collective goals of your teams? Answer “no” if there’s a career incentive to do programming or architecture work at the expense of testing, test automation, or user documentation.
• Has your organization been recognized by the trade press or other independent sources as one of the best places to work or a leader in your industry?
• Are you helping to create a learning organization?

Conclusion
If you can check off most of these items and still have time left during the day, Iʼd like to hear from you. Thereʼs no canned formula for creating human ingenuity. This paper lists points which may, or may not, help in
your situation.
Once you start to realize what you could do to make a difference, you may find yourself afraid to do it. This is a sign you're on the right track.

–mj
Software Process Mentor

1.  http://blogs.collab.net/agile/2007/08/13/a-scrummasters-checklist/?q=blog/michaeljames/a_scrummasters_checklist
2. http://scrummasterchecklist.org/pdf/scrummaster_checklist09.pdf

When you send  the email to MJ please keep me also in CC. I will also love to hear if you are able to check all the items and still have time :)

Agile/Scrum Bug fixing: Myths & dysfunctions

• I can push bugs to backlog.
• We can complete a story without fixing all the bugs
• I have to finish all the stories first; the bugs can be fixed later.
• Before the release I will have a maintenance sprint which will have only bug fixes.

The list is big. If you are doing anyone of the above please stop doing it before it is too late.
One of the fundamental requirements of scrum is to have a shippable product by the end of the sprint. There is no benefit in "finishing" maximum stories with lots of bugs. Scrum places high importance in the quality. With this approach of not fixing bugs will lead to accumulation of bugs & in few weeks you will have 100 + bug and you may spend couple of months fixing it. The cost of pushing bugs sprint after sprint will increase exponentially. The bug which could have been fixed in 30 minutes today will take couple of hours after 2 months!!! I have faced this problem in many teams I have worked with.

My simple advice is to slow down for higher velocity. For short term if try to ignore bugs, it will catch up with you in long term bringing the entire system to a standstill. Yes. I have seen this happening.

Go through the following article. It might help you.
http://www.theagileschool.com/2012/02/scrum-quality-teams-not-delivering-high.html

Commitment vs. Forecast : a small but important change to Scrum

This is a great article by Jose Luis Soria

One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of“forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it, and surely it will have great implications.

Read the full article @

http://www.scrum.org/commitment-vs-forecast