Tuesday, December 24, 2013

The importance of having regular retrospectives

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. 
  • Get a copy of Agile Retrospectives: Making Good Teams Great http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649 
  • 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.

Why should i change



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 

Thursday, June 6, 2013

Are there any standards (Best practices) in Agile/scrum world? How important are they?

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.

Some Thoughts 

  • 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 .


Improvement process

  • 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. 


Saturday, April 27, 2013

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

Sunday, March 31, 2013

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

Wednesday, March 20, 2013

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  

Monday, March 18, 2013

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.



Sunday, March 17, 2013

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.



Wednesday, March 13, 2013

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

Wednesday, February 13, 2013

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