Sunday, 28 April 2013

Sprint Checklist

Article written by Sreenivas Mothukuru

After working for many years on projects developed using Agile (Scrum) I came up with below sprint checklist (3 week sprint). Please go over below items and help me fine tune the checklist. Thank you!



Before Sprint Starts
1
Book conference room for backlog grooming meeting
2
Review prioritized user stories in product backlog before attending backlog grooming meeting
3
Attend backlog grooming meeting
4
Book conference room for sprint planning meeting

Day 1
5
Review user stories in sprint backlog before planning meeting
6
Come up with Dev tasks for (already groomed) user stories
7
Come up with QA tasks for (already groomed) user stories
8
To come up with QA and Dev estimates
9
Identify (module/code) dependencies
10
Attend sprint planning meeting
11
Come up with testing scope document

Day 2
12
Review the priority of user stories
13
Everybody must have clear understanding about stories committed, otherwise get clarifications from Product Owners
14
Make sure all user stories have tracking bugs/tickets
15
Finalize testing scope document
16
Create and upload (unit) test cases
17
Arrange test case review meeting

Day 3 to 12
18
Update relevant information (i.e "Post Resources", modules touched, dependencies, CM/DBA tickets, Change Requests, etc.)
19
Verify the correctness of builds deployed onto QA environments
20
Work with CM team to resolve environment specific issues (if any)
21
Update test case document as per the feedback/suggestions received
22
Check Definition of done, details about WHAT and WHEN user stories will be DEV and QA complete, testing notes, etc.
23
Check whether roll-back plan is identified for all user stories?
24
Identify user stories which need Demos
25
Update QC/Rally/etc. with QA / Dev status
26
Test code changes on Dev boxes before pushing the changes to QA environment
27
Deploy code to QA after development and initial testing on DEV boxes is complete
28
Do Dovetails after every release
29
Update release wiki with dovetail information
30
Make sure all DB changes are committed to SVN with corresponding tracking ID
31
Create/Modify Hudson jobs every time the branch name changes
32
Run automation scripts in QA and Stage environments regularly
33
Coordinate with other dev teams (about release work distribution)
34
Coordinate with other QA teams (about release work distribution)
35
Communicate with Dev and Scrum master on sprint related issues (in any)
36
Ensure all user stories are in verified in QA environment
37
Ensure Performance testing is done for stories (if required) in QA
38
Ensure required hardware/software/applications/etc is set for Performance testing for stories (if required) in Stage
39
Complete Demos
40
Follow up with the user stories that needs to be verified and accepted by product Owners
41
Provide acceptance in QA environment
42
Send QA acceptance email communication to all scrum teams
43
Create release branches
43
Create release RPMs

Day 13 & 14
44
Ensure all user stories are verified in Stage environment
45
Ensure Performance testing in complete in Stage
46
Provide Stage team environment acceptance
47
Send stage acceptance email to all scrum teams

Day 15
48
Update Definition of done
49
Participate in the release
50
Verify user stories in Production
51
Provide Production environment acceptance
52
Send Production acceptance email to all scrum teams

Post Release Work
53
Follow up with the user stories which needs to be verified by Product Owners after release
54
Close all tracking tickets (bugs / user stories) which went to production
55
Arrange retrospective meeting, discuss with team and come up with retrospective notes
56
Share retrospective information with entire team

- Mothukuru Sreenivas

Friday, 12 April 2013

How to LEAD a team without actually being a BOSS?


Article written by Sreenivas Mothukuru



During college days most of the students spend lots and lots of time in reading, writing, understanding & memorizing tons of information to perform well in semester exams. For many, these efforts are just to get good percentages so as to come under corporate recruitment scanner. After completion of exams and once the person is recruited in any corporate office s(he) will experience the 
strange shift from college to professional life. I call it a unique once in a life time experience. During the initial days, s(he) will be asked to understand product and process to perform better as an individual contributor. Few years later the same person will be challenged with additional responsibilities w.r.t. the role.


A shift in role from ‘individual contributor’ to ‘boss’ has a lot to do with the responsibilities they handle.

In general individual contributors
a) are responsible for their own actions
b) they don’t have to manage people
c) they can easily become an “expert” in a particular area at workplace, etc.

Unlike individual contributor, boss can
a) focus on big picture
b) provide opportunities to subordinates
c) reviews performance appraisals
d) delegate tasks
e) work toward team member's development
f) get the things done, etc.

Eventually, individual contributor can become a boss (with proper training) and vice-verse. But, is it possible for a person to play dual role without compromising over quality? If yes, how is it possible?

Working expeditiously for multiple teams, with different roles and with no compromise over quality is highly challenging. It isn't possible when you take responsibility for granted. As we step up in career ladder, quite often we face similar situations where we need to work as an individual contributor and at the same time manage team(s).

Let me share my experience. A few years ago, I was asked to work as an individual contributed to an important project and at the same time asked to lead a team which most often does monotonous work (day in and day out team is supposed to test site functionality in Stage & Production environments ... that's it). After going over my role and responsibilities and after thoroughly analyzing me & my situation I anticipated below problems.
1) difficulty in managing time and resources
2) compromise on quality
3) monotonous work may break individual’s interest and eventually affect team morale
4) increase in attrition and
5) personally I may be de-motivated

Soon, I started to explore all possible ways to manage team and my work. Finally, I decided to LEAD without actually being a BOSS. Sound strange?!

Let me explain you in detail.
For me working as an individual contributor is not a new thing. Therefore, I concentrated more on exploring innovative ways to manage people & work.

Initially, I worked closely with my team and came up with a to-do list and defined the process. Later, I executed the task list items one by one and fine-tuned the process within a month. Finally, I fixed some guidelines and directed the team to follow them religiously. The guidelines helped me to manage and track teams progress in a systematic way. Although, I was able to get the things done, somehow I felt that team members are not taking ownership on what they are doing!

To make my team members feel responsible I created an 'Acting Lead' role and asked them to take up the role one after another. Acting lead means each person within team will act as a lead for 15 days and oversee all team activities (i.e. whether process is followed, work is distributed properly or not, email communication is happening with other teams, scheduling meetings, etc.). With this move I noticed positive change in the team performance which allowed me to look into other tasks. 

This continued for some period and then I realized that my team members are becoming sluggish with monotonous work. To help them recover I started injecting technology related information and allowed them to explore various tools (Web Inject, XSS testing, log verification, database testing, reporting testing, build & deployment, etc.)  This made them to enjoy the regular work without any complains

This continued for some time and at that stage they were good at managing themselves, domain, technology and process. When everything appeared right soon I realized the need to improve their communication skills.

To help them improve communication skills I gave them an assignment to come up with site (Classmates) architecture and asked them to communicate with appropriate teams to collect information. Slowly, team members divided the work within themselves, worked with respective teams to gather information, consolidated everything at one place and finally they have given a nice presentation to the entire teamAlso, I asked acting lead to send a consolidated email (comprising of work done in that week) to US counterparts. However, I closely monitored the way they are proceeding with the task and provided feedback at regular intervals.

After a year I spoke to all team members, everybody expressed happiness and showed willingness to work irrespective of the nature of work. After retrospection I understood that in most of the cases it is not the nature of work but lack of supplements that disappoint employees. Supplements -> Exposure to Technologies, Soft Skills and Personal Development, etc. rather than just hike, bonus or promotions

"When the approach is right weird problems often result in wonderful solutions" - Sreenivas Mothukuru