Ways to ensure you succeed with SRUCM

Recently i was asked a question about how we can successfully transform a team & become successful with using Scrum framework. Here is my experience & learning so for in transforming teams to scrum and also become successful in adapting scrum framework.

1. The Team tries to build a [potentially] shippable product every Sprint, starting with the first Sprint –  Scrum is all about delivering product each and every Sprint.  Any outcome offered by a Scrum Team that does not meet this objective should be considered a failure.  I tend to view this type failure more as a learning opportunity, or a challenge, for the Scrum Team (and the organization) to figure out how we can get one step closer to that objective, rather than the means to punish people.  In most cases, people are doing their best they can within the constraints of the business and it is the environment that gets in the way of this goal. Consistently I have found that Scrum tends to “stall out” when the business leaders are not committed to the process and fails to offer the Scrum Team what it needs to be successful. However, if we do not hold the Scrum Team (and the organization) accountable to deliver product at the end of each Sprint, even the very first Sprint, then lots of environmental factors that inhibits the delivery of potentially shippable product are allowed to remain.  Always deliver something of value that can demonstrated at a Sprint Review no matter how small.

2. The Product Owner prioritizes – this one is really obvious, but I am surprised how often this can be troublesome for organizations starting up with Scrum.  Scrum works best when the roles are fully inhabited and committed to by the participants and the business.  IME, when the roles are weak, Scrum is mediocre at best and is on its way to “stall out”.  The Product Owner role is the most important role in Scrum and the most difficult.  It requires a great deal of knowledge and experience about how the business operates, an understanding how the product benefits the business and an awareness of the overall business trends that shape the product direction.  In the beginning, it is unusual that one person will know all this information and the Product Owner should seek out Stakeholders for this input.  While anyone can give the Product Owner advice on the priorities, in the end the Product Owner must have the final say on the business priorities to support their accountability and focus on inhabiting their role in Scrum.  If someone else is allowed to have that final say, then in reality that person is the Product Owner, not the person doing the job or who has the title.  There is only one Product Owner for the Team – everyone else is a Stakeholder. 

3. Clear goals are set for each Sprint – a Scrum Team exists to deliver new value and capabilities to the business.  If a Scrum Team is not providing new value to the business, it should be disbanded and the staff assigned to other more valuable efforts.  The sad reality is that in many organizations, they do not have the courage to cancel a Team when the time is right and fail to offer clear goals and objectives.  The common result is that Scrum Teams just “do stuff” until they “stall out”.  For me the Sprint Goal – a concise, one to two sentence summary, in the language of the business, that unites all of the work the Team is doing – is absolutely essential for Scrum.  For Team members, the Sprint Goal explains why the work they are doing is valuable to the business and offers greater opportunities to contribute beyond their functional duties.  For Stakeholders, the Sprint Goal helps them understand how the Team contributes to the success of the organization and when the Team needs their feedback and participation.  If the Product Owner cannot define the Sprint Goal they either have not thought out what they are trying to accomplish with the product or we have reached the end of the life for the Scrum Team.  Do not begin Sprint Planning until the Product Owner has defined a clear, easy-to-understand Sprint Goal.

4. The Sprint timebox – again this is another really obvious constraint, but I find lots of mushy and\or porous boundaries between Sprints.  Just to reiterate, a timebox is a fixed increment of time that neither expands nor contracts.  In Scrum, it can be as short as a week and as long as 30 days.  A key breakthrough in the adoption of Scrum in an organization is when people start “to get real” about what can be accomplished with the resources available and time allotted.  This only happens when the Scrum Team finally has the courage to stop telling the business what they want to hear and ask them to make choices based on empirical data, i.e. the progress to date of the Scrum Team.  The timebox supports these new behaviors in two ways.  One, the Scrum Team and the Stakeholders get into a regular rhythm of communication, feedback and inspect-and-adapt.  While the outcomes of Scrum may not be predictable, the touch points and opportunities to make adjustments are predictable.  Two, the timebox asks the Scrum Team to make a commitments to deliver the Sprint Goal before the end of the timebox.  This commitment is not pushed onto the Team by the Stakeholders, but a commitment the Team makes based on the available information at the time of Sprint Planning.  At Sprint Planning, the Stakeholders review how close the Team came to meeting the Sprint Goal or not.  If we keep extending the timebox by “just another day or two”, the Team will never learn what is their true capability to deliver.  Never extend the timebox – when it is over, it is over.

5. Full time participation - in order to achieve the higher levels of productivity and quality many organizations are seeking with Scrum, businesses need to stop splitting people up across multiple projects at the same time.  While it is easy to say someone is working on multiple projects simultaneously, the reality is there are probably just working on one or two (normally the ones they like the best) and waiting around for something to happen on the remaining efforts.  If you are OK with your technical people deciding priorities, then go ahead and let them be on multiple efforts simultaneously.  The rule in Scrum is that you are 100% dedicated to one Scrum Team.  When I share this in class, the more courageous participants tell me, “That will never work in my organization.  We have people on two or three projects at once.”  My response, “Great – then don’t do Scrum.  Clearly, whatever way things are organized in your business gives your the outcomes you desire.  If are you are not satisfied with the way things are working out, then you might want to look at this idea later because this helps improve quality, productivity and throughput.”  When confronted by this same issue when working with clients, I tell them there is no point in starting a Scrum Team unless at least 80% of the Team members are 100% dedicated.  If we cannot get 80% of the people at 100%, then clearly there are other priorities in the business more important than Scrum.

6. A team small enough that everyone can keep track of each other - in textbook Scrum, your team size can range in size from 6 to 10 plus\minus 2 or from 4 to 12 people.  In both cases, we do not count the ScrumMaster and the Product Owner.  The best Scrum Teams I have ever worked with had five to six people.People gain a great deal of satisfaction and comfort by mastering a skill or technology and that is good.  However, specialization often brings a lot of jargon which can inhibit communication which is normally not our goal with Scrum Teams.  I find when the Team is smaller, their is less specialization and people tend to comprehend what all the other members of the Team are doing since the work is accessible to everyone.  Sometimes they can give each other advice or offer help if they have free cycles.

7. No “my work” vs. “your work”, its our work -  an important evolution with Scrum Teams is an understanding that members are evaluated and judged based on their performance as a Team. Yes – we want people to deliver technical excellence and make an impactful contribution, but not at the expense of the greater Team performance.  The idea is not to reduce everyone’s contribution to the level of the lowest performer(s), but to raise EVERYONE’S contribution through peer-to-peer mentoring and cross-training.  When some members of Team consistently kick ass, but other members are regularly struggling, which causes the Team to miss their deliveries, we have a real problem.   If members of the Team are struggling, the entire Team has the responsibility to figure out how to help that person.  Just because one person does all the work they signed-up for is not enough anymore.  This is why we ask entire Team to commit to the Sprint Goal in Sprint Planning – the work of a Team member is not done until the Sprint Goal is complete.   At Sprint Planning, the Team commits to delivering the Sprint Goal, not the tasks nor the estimates.

8. We work together in a Team room – when I start working with a client, I like to walk around the office space, met the Team members, observe their environment and ask them what they would like to achieve with our time together.  For this one client, I noticed I was walking from here-to-there and then there-to-here and so on.  I was walking a lot!  When I sat down with my client at the end of the day, the very first thing I said was, “The number one thing you can do to ensure this project delivers on time is to have everyone sit together.”  The next day, the entire Team were all sitting next to one another.  Ideally, we would like a specially designed Team space and I can make Scrum work well in cube farms.  Teams that are distributed just suck and are a fact of life in the 21st century.

9. Resolve Team internal issues within the Team - when I teach Scrum, I make the distinction that the Team is self-organzing and owns the solution and within the Team they are self-managing.  Self-organzining means that within the boundaries and the constraints of the business, the Team can has the most freedom and latitude to create a solution that they feel meets the customer’s needs best.  In their day-to-day interactions with one another, figuring out who does what and when, making decisions and how they resolve conflict, the Team is self-managing.  In other words, it is up to the Team to decide all of the day-to-day decisions that affect the creation of the product.  As a leader in the process, the ScrumMaster helps the Team in the early stages of self-management by facilitating, encouraging dialogue and assisting in conflict resolution.  Over time, the ScrumMaster should transfer most of these responsibilities to the Team by teaching them practices to improve dialogue, techniques for group-decision making and tools to deal with conflict.

QA Accepted

I subscribe to how Cem Kaner clarified the difference between testing and quality assurance.

Testing is a technical investigation of a product, done to expose quality-related information.

Testers dig up useful information. This is good. But it doesn’t ensure quality.

…

Quality Assistance–that’s what testers do. We help. We investigate. We learn things. We report them clearly. We make sure that people understand what we have found and what its significance means. We provide the good data that is so important for understanding and improving the quality of the product.

That’s important, but it’s not “quality assurance.” (emphasis mine)

- Cem Kaner, The Ongoing Revolution in Software Testing (2004), p. 6-7

Couple of months back, I designed a proposed user story and bug workflows in our internal tool to use in our organization. A couple of days after I submitted it for review, I realized I marked the statuses for testing as “QA”, “Testing in Progress(QA)”, and “QA Accepted” consistent with how our development teams referred to what we do.

Big mess. I could have potentially institutionalize roles I never wanted us to play:

• Every user story needs to be ‘signed off’ or ‘QA Accepted’ by my (Test) team (IMO should be the role of the product owner or project manager or by the Agile Team)
• My Team becomes ‘gatekeepers’, where stories or issues needed “QA” sign-off before being released
• So we’re now supposed to do more checking rather than testing?

I immediately raised this issue to my new boss to propose the change from “QA” to “Testing”, where workflow transitions end with “Testing completed”. This should communicate clearly that:

1. Everyone‘owns’ quality;
2. The Test team cannot and does not assure quality; and that
3. We test, not perform quality assurance

What did I get?

I agree. “Quality” starts with the gathering of requirements and should be part of everything we do from then on.

Great boss.

What’s your thoughts on testing vs. quality assurance?

Wow.. I have become Certified Scrum Professional (CSP)

I have decided to upgrade my present Certified Scrum Master certification to the Certified Scrum Professional level – the highest level offered. Fortunately enough, my company is in the Agile transition journey and i got a chance to read & learn many agile scrum practices which kind of helped me to pass by Certified Scrum Professional (CSP) exam.

I have started preparing 4 weeks before the online test. With $300 at stake, there is no way I want to fail. The CSP handbook gives you a list of reference books. The list being so big, it's sure that Scrum Alliance want to ensure that people just don't prepare only for the exam.

First & foremost thing i did was going through online scrum training material provided by Michael James which also has some interesting quiz questions along the way.

Here's the preparation work:

SIX INTERACTIVE E-LEARNING MODULES:

http://www.ScrumTrainingSeries.com

READING:

a. The six-page overview of Scrum at http://ScrumReferenceCard.com 

b. The four values of the Agile Manifesto at http://AgileManifesto.org 

c. The twelve principles of the Agile Manifesto at http://AgileManifesto.org/principles.html

Second thing i was checking my knowledge by writing scrum open assessment test as many times as possible. http://scrum.org/Assessments/Scrum-Open-Assessment

The following are the books I focused.

1. Succeeding with Agile: Software Development Using Scrum - Must read
2. Agile Estimating and Planning - Must read
3. Agile Software Development with Scrum - Must read
4. Agile Product Management with Scrum
5. Agile Retrospectives
6. Refactoring: Improving the Design of Existing Code
7. Test Driven Development By Example

The next big milestone is to become an Certified Scrum Coach (CSC) by 2013.

Thanks

Attributes of a Good Scrum Master

I have completed reading 2 parts of "Succeeding with Agile: Software Development Using Scrum - By Mike Cohn" and its explaining some of the fantastic attributes of Scrum Master. I am pretty impressed with the attributes of scrum master explained by Mike Cohn.

Responsible

A good ScrumMaster is able and willing to assume responsibility. That is not to say that ScrumMasters are responsible for the success of the project; that is shared by the team as a whole. However, the ScrumMaster is responsible for maximizing the throughput of the team and for assisting team members in adopting and using Scrum. As noted earlier, the ScrumMaster takes on this responsibility without assuming any of the authority that might be useful in achieving it.

Humble

A good ScrumMaster is not in it for her ego. She may take pride (often immense pride) in her achievements, but the feeling will be “look what I helped accomplish” rather than the more self-centered “look what I accomplished.” A humble ScrumMaster is one who realizes the job does not come with a company car or parking spot near the building entrance. Rather than putting her own needs first, a humble ScrumMaster is willing to do whatever is necessary to help the team achieve its goal. Humble ScrumMasters recognize the value in all team members and by example lead others to the same opinion.

Collaborative

A good ScrumMaster works to ensure a collaborative culture exists within the team. The ScrumMaster needs to make sure team members feel able to raise issues for open discussion and that they feel supported in doing so. The right ScrumMaster helps create a collaborative atmosphere for the team through words and actions. When disputes arise, collaborative ScrumMasters encourage teams to think in terms of solutions that benefit all involved rather than in terms of winners and losers.

Committed

Although being a ScrumMaster is not always a full-time job, it does require someone who is fully committed to doing it. The ScrumMaster must feel the same high level of commitment to the project and the goals of the current sprint as the team members do. As part of that commitment, a good ScrumMaster does not end very many days with impediments left unaddressed. There will, of course, be times when this is inevitable, as not all impediments can be removed in a day.

Influential

A successful ScrumMaster influences others, both on the team and outside it. Initially, team members might need to be persuaded to give Scrum a fair trial or to behave more collaboratively; later, a ScrumMaster may need to convince a team to try a new technical practice, such as test-driven development or pair programming. A ScrumMaster should know how to exert influence without resorting to a dictatorial “because I say so” style.

Knowledgeable

Beyond having a solid understanding of and experience with Scrum, the best ScrumMasters also have the technical, market, or other specialized knowledge to help the team pursue its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed” (2001, 133). Although ScrumMasters do not necessarily need to be marketing gurus or programming experts, they should know enough about both to be effective in leading the team.

TEN TIPS FOR AGILE TESTING

We have learned a great deal about Agile testing. This article presents ten tips for Agile testing based on our experience. However, don’t expect to find the perfect test approach for your company or software project in this article. That is still something you will have to find out yourself!

1. Integrate the testers in the development teams

Teams are responsible for delivering software that meets expected requirements and quality. However, if we want teams to test the software, we must give them the knowledge to do it right. Testers have that knowledge. By integrating testers into the development teams, teams obtain the skills they need to test their software. When you try this, make sure you choose the right mix: one tester for three programmers is a fair but minimal number.

2. Use risk based testing

You can never test everything with the same (extensive) depth; even in a waterfall project you have to make choices. In an Agile project all the activities are time boxed so you have to make choices about how extensively you want to test each feature. We use a risk based approach to determine which test activities we are going to carry out for a feature during the iteration. The risk level of every feature is determined by the customer and the teams. It is a very transparent process so the customer knows exactly which test activities are executed for every feature.

3. Have testers review unit tests

In our organization the developers are responsible for creating and maintaining the unit tests. Unit tests are a very important part of our test harness. Developers often have a different way of thinking; for example, they tend to test only the success scenario.

To create unit tests that are as good as possible, our testers review the unit tests for all our high-risk items. The review has two advantages. First, the unit tests are improved because testers and developers supplement each other: the developer knows where the weak places in the source are, and the tester can use his knowledge of testing to give tips to improve the unit tests. Second, the testers know exactly which test cases are executed in the unit tests and can concentrate on executing other (e.g. higher-level) test cases.

4. Create a test automation framework and appoint a toolsmith

Automated testing is very important because new features and refactoring can introduce problems that can be difficult to find. By using an automated test framework, we can maintain quality levels during the iteration. Our testers are able to create new tests easily and quickly in the framework. We have a dedicated test engineer (we call him a tool smith) that maintains and optimizes the test automation framework, reviews the new automated tests of the testers and analyzes the daily test results. Testers in the teams can spend more time creating and extending automated tests because the toolsmith supports them.

5. Display quality metrics in a public location

Almost every software project has a problem registration system, automated test results, and in some cases nightly or continuous build results. But how often do team members look at the results or count the open problems? We installed a monitor in the coffee room that displays the actual metrics of the currently open problems, the percentage of successful unit tests, the percentage of successful nightly builds, and the current state of the continuous build. By displaying the metrics in public the teams are confronted with the information. The information is no longer just a number in a system or a record with some other information in a metrics database.

6. Add a test scrum

One advantage of having a separate test team in one room is that the communication between the testers is improved. When you have a project like ours where the testers are distributed across several teams, the communication becomes more difficult. To solve this problem, we use a test scrum to align the test activities. Our test scrum is held twice a week and every team is represented by one tester. The test scrum is a scrum like the daily team scrum but focused on test activities. The test manager is the ScrumMaster of the test scrum.

7. Implement test retrospectives

Every team in our project holds a retrospective meeting at the end of the iteration. In the retrospective, the team discusses the process: what went well and what went wrong. The testers in the team learn and discover new ways to improve their tests. The sharing of knowledge with testers from the other teams helps everyone.

We have a test retrospective every iteration so the testers can exchange knowledge and experience and discuss problems they have. It is important that the retrospective is only related to test issues; you shouldn’t discuss team issues (they should be discussed in the team retrospective). As with the test scrum, the test manager is the ScrumMaster of the test retrospective.

8. Plan for open problems

We try to fix all the problems that we find during the iteration in that same iteration, but sometimes we end the iteration with open problems. The best way to handle open problems is to add them to the sprint backlog for the next iteration. By explicitly planning the management of the open problems, the chance that they are “forgotten” and pile up is very small.

9. Remember: Testing is still testing

When you test in an Agile software project you can still use the “traditional” test techniques. We use exploratory testing but also apply test techniques such as boundary value analysis, equivalence partitioning, cause/effect diagram, and pair-wise testing. Which test technique we choose for a feature depends on its risk category. Exploratory testing is used in every category; but if the risk is higher we also apply more formal test techniques. The challenge for the tester is to use a formal test technique without delivering extensive test documentation.

10. Start doing it!

The last but most important tip is start doing it! Don’t talk too much about how you are going to introduce testers, or which test approach is perfect for your organization. You are going to make mistakes or discover that the chosen approach doesn’t fit your organization. That’s a given. But, the sooner you start, the sooner you can begin learning and improving your test approach. With the retrospective meetings, you have the opportunity to adapt your test approach every month.

Source: Ralph van Roosmalen article on Logigear Magazine

Agile Scrum Training Modules

Online training modules with built in quizzes that have been shown to improve scores on exams CSM/CSP/CSPO

SEVERAL ENJOYABLE ANIMATED E-LEARNING MODULES:

Introduction to Scrum: https://training.csfe.collab.net/sf-images/training/agile/intro/Intro_to_scrum.htm

Backlog Refinement Meeting: https://training.csfe.collab.net/sf-images/training/agile/BacklogRefinementMeeting/BacklogRefinementMeeting.htm

Sprint Planning Meeting: https://training.csfe.collab.net/sf-images/training/agile/SprintPlanningMeeting/SprintPlanningMeeting.htm

Daily Scrum Meeting: https://training.csfe.collab.net/sf-images/training/agile/DailyScrumMeeting/DailyScrumMeeting.htm

READING:

a. The six-page overview of Scrum at http://ScrumReferenceCard.com

b. The four values of the Agile Manifesto at http://AgileManifesto.org

c. The twelve principles of the Agile Manifesto at http://AgileManifesto.org/principles.html

Handling common issues in Scrum Testing

I would like to point out some of the common issues/challenges which we have faced while following the agile/scrum testing. We have learned a lot over a period of time and we are trying to find right approach which would eventually help us to improve our scrum testing practices.

Challenge1: Most of the time QA finds quite a lot of regression issues during final stages (stabilization weeks) which leads unpredictability on the product release. What is the best way to do the regression testing to capture defects in the early stages?

Solution: You need to do incremental regression testing along the way, probably every sprint.  This takes careful collaboration with the developers to figure out what to release to the test lab every sprint so that it can be regression tested.

Challenge2: What would be best way QA can work with development to understand the complete test scenarios / cases?

Solution: QA needs to talk to the Dev. team constantly. Be in their grooming sessions. Act as one team. Work as one Team. Be SMEs for them during development, so that the testing is done on their box as part of their work before it ever gets to you.

Challenge3: Most of the times QA has been pointed out as a root cause of delay in release (which is a trend all over the world), even though they do get better every release but we are not their yet to show our class. What is the best way to improve QA process here?

Solution: Integrate it into the development process. Make sure QA & Dev works together as one team.

Challenge4: What are all the QA best practices we can follow (as per scrum)?

• Don’t separate verification testing from development. By the time QA gets to the code, it must be known to work, the only question should be validation that it does the right thing.
• Do validations constantly, either intermingled with development, or as a separate thread. Think of the code as leapfrogging from Dev to QA.
• Every sprint a new build is dropped on QA, it does validations (not verification, that’s done in dev, but possibly by testers on the team) to find new stories that are dropped back on the backlog. The PO prioritizes them alongside everything else, and it keeps going.
• Always remember that it’s about the product, not the code. The product is not finished until it’s been validated and defects have been corrected. Therefore, the developers are not finished until that happens, either.
• Last but not the least…”It must be thought of as one big team, not two teams… “

This is exactly what i am proposing to my management to get the ball rolling in the right direction but it has its own challenge:-)