In our many discussions we hear the advice that we should use our common sense to tackle the problems, But how good is our common sense? Are we willing to change? Recently i had a discussion with a colleague on an agile practice. This person was not so willing to change because the common sense dictate otherwise. In this fast moving world and always change constraints change is inevitable, most of time we will have to challenge and change the age old common sense to bring the continuous change/improvement.
Taiichi Ohno, the father of the Toyota Production System, said, “[...] misconceptions easily turn into common sense. When that happens, the debate can become endless. Or, each side tried to be more outspoken than the other and things do not move ahead at all. That is why there was a time when I was constantly telling people to take a step outside of common sense and think by ‘going beyond common sense.’ Within common sense, there are things that we think are correct because of our misconceptions. Also, perhaps a big reason we do some of the general common sense things we do is that based on long years of experience, we see there are no big advantages to doing things a certain way but neither are there many disadvantages to it. ... we are all human so we’re like walking misconceptions believing that the way we do things now is the best way. Or perhaps you do not think it is the best way, but you are working within the common sense that ‘We can’t help it, this is how things are’”
We all know about definition of done. It defines a set of
conditions which should be satisfied by the feature team during the sprint
execution for each Product Backlog Item worked by them. Unless all the
conditions are met, the PBI’s won’t be marked as done. This can be called as
the exit criteria for each PBI or user story.
Usually apart from the team & PO, the organization and
other stakeholders also play a big part in creating them. A well-defined Definition
of Done ensures that all the PBI delivered meets the standards and if required
can be deployed. As team maturity improves this definition also evolves.
For every exit criteria there should be an entry criteria. I
have seen many lazy Product Owners (& scrum Teams) who don’t do a proper
job of backlog grooming. Because of this
there will be lot of ambiguity about the upcoming PBI’s. There will be constant
churn producing a lot of waste. Sprint planning
will end up in failure because team won’t know how to create tasks for the PBI.
A poorly planned PBI will force the team do all the investigation before they can
do the actual work, thus wasting their precious time. Sometimes the PO waits
till the demo to provide a comment that his intention was something else!!! In
this situation team will be forced to redo the PBI in the next sprint.
By having a well-defined definition of Begin a lot of confusion can be avoided.
Team will know that the PBIs meeting the Definition of Begin will contain all the necessary information.
ScrumMasters job will be easy. They will have a benchmark and can ensure that the team and PO works together to define the PBI.
Team can point this definition to their PO if they don’t do their job.
It will help a new Product Owner to get familiar with the exiting culture and backlog grooming familiar with the team.
This definition helps the organization a lot when they start scaling up
Each team and company will have to define their own Definition
of Begin. Like definition of done this should also evolve. But ensure that this doesn’t become an inflexible
document which could be used for auditing. The primary objective should be to eliminate
waste & promote discussion between feature team and Product Owner.
For my backlog I will like to have
A well defined User Story
Well defined Conditions of Acceptance (usually in GHERKIN
if required , UI screen
If required, any high level Architecture Diagram (from
Over a period of time retrospectives because a mundane task and teams starts skipping this, some of the patterns I have observed.
Do a retrospective for 2-3 sprints
Repeat the pattern of retrospectives without any value addition to the team
Not doing the retrospectives at all.
Before the question of skipping retrospectives (or not doing altogether) arises we have to understand what we are trying to accomplish with retrospectives. Agile methodology thrives on inspect and adapt process. We continuously observe and make changes in our process for continuous improvement. Retrospective is the key event which facilitates this. There is no benefit in doing retrospectives without understanding this core principle. There is no value in forcing this down the team if they don’t understand the core benefits. They should see some value for time they spend on this. It shouldn't be because the process dictates or because the scrum master wants it. If this is not happening then do a retrospective of the retrospective.
Create a visible backlog of the action items created from retrospective. I prefer it in a separate task board.
People should be able to see the progress. This will be the scrum masters backlog of impediments. One of the biggest complaint teams raise is that nothing happens to the action items in retrospectives.
Assign people to each action items and review the progress periodically.
Team might want to skip this because they might get bored with the same format and type of discussions.
Do infuse creativity
Put some new activities or discussions.
Change the venue or style.
This meeting is not only about finding impediments or feedback for continuous improvement. I have used this ceremony for improving people–people communication and building trust.
With some teams you don’t have to even do retrospectives after every sprint. They do it daily or after some major event. The feedback cycle for such teams is very short and they should be matured enough to understand this. I will recommend this only for matured team who are together for long
If you are not having retrospectives or are not doing it regularly then also you might deliver what is expected by you but you wont be delivering using Agile principles. You will not improve continuously and will fade away like dinosaurs.
Once Nokia were the number one company in their domain but now that space is occupied by Apple and Samsung. I don't even have to mention the problems faced by Black berry... to survive in this competition you will have to continuously improve.
My agile coach forwarded this picture to me. This one of the best picture which explains the agile principles
We believe that we are delivering great software. and we don’t have to change because
Our coding standards are great
We don’t have to improve our process
We don’t have to talk to other teams or people
Scrum Masters believe that they don't have to challenge the teams because they are delivering and they don't have to improve anything
We don’t have to bring issues to management
We don’t have to suggest improvement ideas to others because it doesn't affect us.
Some of these dialogues happen because we think that the equilibrium we see today will remain like that forever. Even if we don’t change anything inside the outside environment will change and it will affect us badly. When such change comes we will be like dinosaurs, it will wipe us out. The beauty of agile is continuous improvement, if we became stale or stop that then there is a high risk that we will be eliminated like dinosaurs
Standards help the people to work and communicate in time tested manner. This helps to reduce the noise and chaos. Standards help a newbie to learn the tips and tricks of trade.
But is it advisable to follow the standards always?
Change is the only thing which is constant. Any standard or best practice which doesn't evolve with the changing environment doesn't help anyone. Such obsolete standards prevents the team from improving continuously. In many cases thy prevent new thinking and innovation.
A standard/ guideline made for one company/project/person may not work for another because they have unique requirement. These guidelines will have to reviewed and adopted to the new project/person. Like everything ins scrum, even the standards will have to undergo the process of continuous improvement.
It is advisable to put the good practices on the team wall so that everyone can view them. Any standard hidden in some SharePoint site or any other repository might not get enough views. If these are pasted on common areas team will get to see them every day and can suggest any improvement.
If any automation can be made to verify the output against the standards then the necessary investment should be made .
Team identifies a problem and the necessary process/standard changes
Team discusses the new process & make the necessary changes. Team publishes the process change within the team and stakeholders
After a specified duration team revisits the standards to check the effectiveness
If the process/standard change has achieved the necessary outcome then it is circulated as a best practice guideline to other teams also.
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.
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 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?
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.
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.
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. .
Lighting Corporate Passion: Everything you need to know about FedEx Day
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.
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.
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
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
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.
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.
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.
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
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 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
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.
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
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.
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%.
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.
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.
Team works together to achieve the objective set in the planning phase. Team works with the set of agreed process.
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.
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.