Pros and Cons of Modification in Scrum Ceremonies...

Agility is not a new phenomenon. It has evolved with time, the sincere efforts of the Agile community, and its great proponents. Scrum, an Agile framework, achieved popularity with its high number of success results. Development teams started transforming as Scrum teams and a new servant-leader "ScrumMaster" emerged. For the past few years, Scrum has attained wide recognition, and even those organizations that initially overlooked its benefits are now transforming to adopt it. Due to the high success rate of Scrum-led projects and the increased requirements for ScrumMasters and Scrum product owners, many professionals have embraced these roles cheerfully. However, in the enthusiasm a few (wrongly) modified processes are being practiced in many organizations, which sometimes results in failure and stepping into non-Agile methods and myths. I appreciate the efforts people are making to adopt agility while molding some practices to better suit their organizations, but one should take a few preventive measures and inspect such modifications before implementation. This is important not only for new teams but also for matured teams that experiment with such practices and sometimes face adverse results. By saying this, I do not intend to say that we should not experiment! Scrum itself provides room for some calculated modifications. However, before applying such modifications, pros and cons must be considered. I have coached many teams and faced challenges of this type. I have had to implement good practices in some existing teams. The most common behaviors I observed that needed to be changed were as follows: Modifying the names of the ceremonies Not timeboxing ceremonies Treating programmers and testers differently Implementing Scrum without inspecting and understanding the current state of the existing project Modifying the names of ceremonies I found strange names given to a few ceremonies and observed ill effects. For example:

Daily Scrum -- Daily stand-up, daily Scrum meeting, daily status meeting (the worst name)
Sprint review -- Sprint demo meeting

There are two main disadvantages of such renaming. First, not having a common name across the globe leads to misunderstandings. 

"What's in a name? That which we call a rose by any other name would smell as sweet." Great lines by William Shakespeare (Romeo and Juliet)! But in software development, such renaming causes confusion. For example, we cannot call the sprint review a sprint demo or some other name. Even if renaming works within the organization, the rest of the world will be baffled. The second disadvantage is that most names have some significance; using other names ruins that. Calling the Daily Scrum a daily status meeting is certainly going to convert it into a status-reporting meeting. Many teams have experienced that, without their realizing it, the Daily Scrum has become a status meeting and lost its significance. In our teams, we made a rule to follow the proper name of the ceremonies to keep everyone synchronized. The same way the sprint review was named a sprint demo; the sole purpose of this ceremony was to demonstrate completed stories/tasks. The teammate who had coded the particular piece of function was responsible for demonstrating it to stakeholders, and other developers were not highly attentive during that demo. It was important to realize that the demo was not only for stakeholders; it was for the whole team. We guided the team to understand the significance of the sprint review and provide the transparent current status to stakeholders. It took time, but providing various examples rejuvenated the team. There are a few other names that need a common tag. For example, "acceptance criteria" and "condition of satisfaction" are the same. Scrum experts are making efforts at this. For example, "product backlog grooming" is now often called "product backlog refinement." Many more are yet to come. Not timeboxing ceremonies This can be challenging -- and linked to modified names. In working with one team, I found that the Daily Scrum was being called a status meeting, and it was not occurring daily. Due to different time zones among the distributed teams, it was held on alternate days and for longer durations. The team was providing the status of the past two days' activities. All teammates sat and provided their status, one by one. The activity descriptions were monotonous and the energy was very low. Further, I observed that the development team found this meeting time-consuming and of no use. We first timeboxed it and limited the questions/answers. (Two additional questions had crept in: "What did we do the day before yesterday?" and "What will we do the day after tomorrow?") We succeeded in convincing everyone that the Daily Scrum should indeed be held daily and that the three original questions would be discussed. The another problem, of answering these three questions while facing and essentially speaking only to the ScrumMaster in a status report, was solved by guiding the team toward the essence of this meeting and positioning the ScrumMaster behind the team, which stood in a half circle. To revitalize the team's energy and sense of cohesion, we introduced new Scrum games. One such game that I introduced is one that calls on everyone's imagination. Please refer my post 'A game of Imagination'.

Treating programmers and testers differently Treating programmers and testers differently is a very dangerous practice and definitely leads to failure. In such situations, programmers and testers do not focus on the target and instead try to find each others' mistakes. In our development team, we called everyone a developer and focused on achieving the goal on time. This helped us avoid unwanted slippage on tasks. For team bonding, I experimented with many varieties of the above-mentioned game and succeeded in achieving excellent team bonding. Implementing Scrum without inspecting and understanding the current state of the existing project This problem, which I observed strongly in a particular team, is certainly common among many new Scrum proponents. Scrum can be used with all projects but is not highly useful in certain situations. For one of the teams that had recently delivered a product with many critical defects, implementing Scrum was not a good idea. The requirement was to immediately provide needed solutions and keep to the task in hand (limit the Work In Progress). We finally got that situation under control by providing the immediate defect resolutions, and then we started following Kanban for support activities. 

Finally . . .

Now each of our teams follows the Boy Scout rule (always leave the campground cleaner than you found it). Whenever we find a process derailing, we gather and discuss it and get it back in place. If you too have faced any such derailed processes, please share your experience, along with the resolution you and your team took.

Continuous Integration during Agile Development Practices

Continuation integration is necessary in software development, and especially so in Agile frameworks...

"Continuous integration," a term coined by Martin Fowler and Kent Beck, refers to one of the best ways to improve productivity through automating a few tasks during development. Examples include automated pulling of the latest version of code, automated build, and automated execution of unit tests with immediate feedback to the users about the result obtained. Why is continuous integration required? We've often experienced programmers writing code and the task working perfectly, but later, while we integrated that code with the rest of the application, we faced unexpected results. To overcome such situations, continuation integration is very much needed. It becomes more important with Agile frameworks, where the nature of delivery is incremental, iterative, and in short cycles (as in Scrum, XP, or in fact in any other Agile framework). Continuous integration is possible only through an automated process that builds, tests, analyzes, and deploys the application. This process runs with each source-code change and provides immediate feedback to the development team. Minimum human intervention in these processes results in saving time. Continuous integration also reduces the risk of delivery slippage as the development team performs testing and integration on a continuous basis. This helps us identify defects in time and take appropriate and necessary action. The integration may be daily, weekly, nightly, release based, or for testers as per requirement -- and it must be, of course, done in a continuous manner.

How will the process be changed?

Manual process: 

Good flow, with no exception of errors faced during any of the following actions: 

Check out the source files from your source code repository.

Make necessary changes to the code.

Build. Run unit tests.

Check the updated code into the source code repository.

Automated process:

An automated system keeps track of the source control system and, as soon as it finds any change, it takes the latest version of the code.

The system automatically builds the code.

The system automatically runs unit tests.

The system automatically sends build and test results to a feedback system so that team members can know the current status of the build.

Necessary tools

Here I have mentioned a few open-source tools for Java and .net. There are many other such tools that may be adopted by teams as per their preferences. 

Source control: Such as Subversion or Git; these both can be used for Java as well as for .net

Server for continuous integration: CruiseControl.NET (for .net), Jenkins (for Java)

Build Manager: MSBuild and NAnt (for.net), Ant (for Java)

Unit test frameworks: MSTest and NUnit (for.net), JUnit (for Java)

Code-analysis tools: FxCop, StyleCop (for.net), CheckStyle (for Java)

Testing tools: Selenium (for both .net and Java) 

If you have more suggestions, please share.

User Role Modeling..is this really required?

Any business requirement that needs to be formulated in user stories can be best justified if the writer knows the user roles for which the requirement will be mapped. To identify users, user role modeling is important. For example, if we want to develop a direct-sales website, we must keep our focus on buyers, sellers, admin, executives, etc. When the user roles have been identified, then the requirements can be mapped to user stories, keeping each identified user in view. More effectively, if we can associate a persona for each user, it helps broaden the thought process for that particular user, and it results in effective story writing. As the saying goes, "put yourself in someone else's shoes."

 

 Following is an example of a requirement and how to visualize it from different perspectives:

 

Requirement: To make a toy train for kids.

 

 What all are the user roles here?

• Kids (obviously)

 

. . . and. . . ?

 

• Parents
• Toy manufacturer (yes, sometimes we need to consider the manufacture also)
• Anyone else whom we can tie to this requirement (later users with the same requirements can be merged and one role can be chosen)

 Once the user roles have been identified, effective user stories can be written. Below I have provided role-specific sample user stories. These user role-specific stories not only help developers understand the requirements of the feature but also help QA identify the scope of testing.

 

Expectations related to different user roles:

 

• ·         As a child, I want to see the toy train in attractive colors so that I crave it.
• ·         As a child, I want to have fun using this toy with my friends so that I will enjoy it for a long time.
• ·         As a parent, I want to be excited by the look of the toy so that I will purchase it for my child.
• ·         As a child, I want to count the compartments of this train so that I can learn counting also.
• ·         As a manufacturer, I want to provide my information on the toy box so that customers can contact me to buy other toys from me.
• ·         As a parent, I want to be sure that the toy has no sharp edges that might hurt kids.
• ·         As a parent, I want to verify that this toy is appropriate for kids two to three years old (my kid's age group) so that they are able to understand it and like it.
• ·         As a parent, I want to buy a nontoxic, excellently made toy so that it will be safe for kids.
• ·         As a parent, I want to learn about the manufacturer of the toy so that I can buy more toys from them.

 

 More expectations (or user stories) can be added here. Also, a few can be merged, or "conditions of satisfaction" can be added to one user story. For example, "nontoxic, excellent grade of plastic" and "no sharp edges" can be taken up as conditions of satisfaction.

 

 Now tell me which user has the highest set of expectations for the toy. Children?  :-)

The Misinterpreted Developer!

The term "developer" is not meant only for programmers. However the term developer became so popular in the last decade that it became a synonym for programmer. That's no surprise, given the way programmers welcomed the tag. However, developer has a broader sense in Scrum teams. Not only programmers but also testers focus equally to develop and deliver a quality product that provides some business value. This is the reason that in Scrum that there is only a "development team," regardless of programmers or testers. Organizations may have a separate team of testers or QAs, but the role defined in Scrum is "developer" only. Here I am only concentrating on programmers and testers. In reality, combinations of other roles, including designers, content writers, and business analysts, constitute the Scrum development team. This development team is formed with cross-functional developers with t-shaped skill sets.

 In Waterfall (command and control), it is a general practice to have different teams of programmers and testers. The higher the number of bugs found during testing, the more it is a sign of effective testing. The cubicles of testers are purposely kept at a distance from those of programmers. No casual discussions during features-functions implementation!

 Programmers used to send their tentative plan of providing builds to testers, and testers used to provide the test results as per their schedule. A cold war could be felt during this phase. Even simple bugs that could be fixed in a negligible amount of time lasted for a significant duration. This was a dark side of command and control!

 In Agile practices, the developers (programmers and testers) work toward development of a product/service and deliver some business value in a shorter duration, resulting in increased return on investment. Now, how does Scrum work to make that happen? On a Scrum team, developers work with one aim, and that is to deliver quality chunks during the timeboxed sprints. On the Scrum team, the tester is not the one who tests the tasks; the programmers or other development teammates also help in testing. Recently on one Scrum team I found tasks named "QA <task> by developer." The word developer was odd here, but the idea of sharing the load of testing was precise, and this is the only way of completing quality tasks in the timeboxed sprint.

 The role of testers becomes more interesting and challenging in Agile teams. Testers help other members of the development team understand the requirements and the different angles for testing the functionality/tasks. This helps other teammates broaden their testing skills. The same happens when programmers share some tidbits of programming.

 This is best achieved through pair testing. As pair programming is generally meant to mean two programmers working at one workstation, pair testing is carried out with one programmer sitting with one tester. The tester continuously tests the completed task with the programmer, and if any fixing needs to be done, it is done then. Again, there is not a rule that only a tester will be paired with a programmer during pair testing; in fact, any teammate can perform this role.

 So the next time we use the term developer, will we only have programmers in our minds?

Very soon we will go through CI (Continuous Integration), a very important aspect during sprints.

Stay tuned!

Whiteboard during Meetings…

  In Scrum meetings, participation of team members, and specifically participating together, is important. At times, however, participation is not balanced in a meeting. A few members actively speak, while others only listen. (Highlighting this point does not mean that listening is not good.)

 There are several reasons why some team members do not participate in meetings, but one of the main reasons for new Scrum team members is that they are shy to speak. This discussion pertains only to these situations.

 ScrumMasters use spreadsheets, electronic tools, or sometimes whiteboards for recording the ideas presented by members at meetings. I prefer the whiteboard because it is not only a good way to record the ideas but also everyone can see these ideas easily. This method of visualization also increases active speaking and participation of members, because when the ideas are visible on the whiteboard it spreads the message, "Your idea is valuable." When members see that their ideas are valued, not only do they feel valued but others also get motivated.

Second, we retain clear, visual ideas longer in our minds, and we avoid redundancy. You can use symbols, signs, or whatever else works.

Despite other means of capturing meeting notes and ideas, the significance of the whiteboard remains. However sometimes it becomes necessary to use other means apart of whiteboard for example, if team is distributed at different places use of electronic means becomes inevitable. Still for local discussions whiteboard may be used.

Here are some do’s and don’ts for the uses of whiteboard.

Do's:

Use block letters, as they accelerate reading speed.

Use alternate-colored markers.

Use black, green, blue, brown, or purple for easy-to-read text.

Use red, orange, or pink as highlighting colors.

Use only standard abbreviations.

Don'ts:

Avoid color coding, as in the flow of discussion it becomes difficult to manage.

Avoid small fonts that may be difficult to see by the members sitting farther away.

Finally:

When you need to erase the ideas/notes from the whiteboard, capture a snap on your   mobile phone so that you can refer it later. Encourage team members to do the same for their own future reference. This will give them freedom from taking notes during the meeting, so they can concentrate only on the discussion.

Quality test procedure in two week Sprints? Don’t you play Cricket?

     Two week Sprints. Why not? I compare it with Cricket. When ODIs wrapped the show of five day test matches and then came the 20-20 with more excitement, didn’t we welcome? Quick ROI (return on investment), result oriented and happy stakeholders. :-) 

To ensure delivery of shippable increment with each iteration, programmers look at each story and related tasks to identify the most necessary tasks of the functionality. Those tasks are completed first and then subsequently the rest tasks of the functionality are taken up. The idea here is that instead of delivering nothing of that functionality at the end of the sprint, at least deliver something which works.

Agile testers take the same approach and identify the happy path of the functionality first and start by making sure the happy path works.  And this statement does not indicate to leave the negative tests. Negative testing is vital for quality product. A good approach is to automate the happy testing and once found fine then go ahead with negative testing. However this is very necessary to identify the criticality of the product.

If any defect which is not observed in normal circumstances i.e. to produce a defect it takes various tricky steps which are almost unusual, then it is worth to leave fixing those. To stop the delivery may impact on ROI (return on investment) and one of the good things in agility is early ROI. But yes, this defect needs to be indicated to Product owner. It can be considered as a technical debt and may be re-paid later, if felt necessary. This practice is acceptable in short sprints.

In scrum teams, programmers work using TDD (test driven development) and ensure positive scenarios are working fine. Testers write regression test scripts. The development team which comprises of programmers, testers, designers and sometimes business analysts also, execute these test scripts during the last two days of sprint. Certainly the teamwork during sprints plays a major role in delivering quality chunks in such a short period. And this all get possible with the help of automated tools and continuous integration.

In my future articles we will be exploring such tools used in scrum teams and the continuous integration.

So stay tuned…

Game of Imagination!

     We all know that Scrum games are helpful in building team cohesion, energizing everyone, and breaking the ice for shy teammates.

Here is a game that I found very interesting and easy to play. I got the idea for it from the thematic apperception test (TAT).

Necessary materials:

1. One large blurred image, which should show one person doing some activity. This image should be blurry enough that the team can imagine any human presence but cannot definitely identify who the person is and what exactly he or she is doing. For example:

That image may be shown:

• Through a projector.
• On a big screen in a conference hall connected to a laptop or PC.
• On a flip chart, pasted or drawn on.
• On a whiteboard, again pasted or drawn on (drawing a blurred image may be a tough job!).

2. Writing pads/papers for teammates

3. Pencils/pens for teammates

How to play:

1. The facilitator will ask each development teammate, "What would you be if you were not IT personnel?"

There will be different answers given, such as:

• Doctor
• Air force pilot
• Police officer
• Businessman
• Professor
• News reporter
• Poet/singer/guitarist
• . . . And you can add some unusual, imaginary roles as well.

 

2. The facilitator then shows the image and asks each team member to write a story about that image, related to the role each chose for himself or herself. The story should be five to seven lines long only. (Give a time limit of six minutes: one minute to think and five to write.)

3. Once everyone has finished writing their stories, the facilitator will ask each team member to narrate the story he or she has written.

4. After finishing the story-telling round, the facilitator will disclose the "real" role of the person in the image. This role will be the choice of the facilitator, preferably a role that was not among those the teammates listed in the beginning.

5. The facilitator will now ask the team to collaborate on writing a single story about the image, bearing in mind the role the facilitator named. It should contain ideas from each team member and be 10 to 12 lines only. (Time limit: 20 minutes, 5 minutes for discussion and 15 for writing)

6. The team will select the narrator of this story. The narrator may be the last one who entered the meeting, or decided through a draw, or whatever the team decides.

No conclusion will be given for any story. The image contents and theme used in one game may be modified for games in the future.

This exercise will not only be refreshing but it will also give wings to the imagination of team members.

A few explanations:

• Why individuals need to narrate the story?

 Narrating story will work as an ice-breaker for shy team-members.

• Why writing story two times, one individual and one group story?

First story will be individuals thought and will solely intended as an ice-breaker. The second story will be the result of team-work and team-cohesion.

• Why the image needs to be blurry?

If the image will be clear then it will stop the imagination from the team-mates. For example, if we see a person in army uniform then it will be tough to write a story on a doctor, at least as an active actor of the story. Same will apply when the second story will be discussed and written.

• What does ‘story’ imply here?

Story here means a few sentences on the role. For example- Harry is a teacher. He goes to nearby village over weekends and spread literacy. He does this free of cost ….continue with your imaginations.

• Why the facilitator will select a different role that was not listed in the beginning.

If the role is among the roles listed in the beginning then the story is already there.   The idea for a common story here is to ignite the team-work and cohesion, in action!

Please feel free to ask for any further explanation needed for this game.