Tuesday, August 28, 2012

What are the rules of scrum?


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.

Some of the rules 

  1. The roles of Scrum
    Scrum Master - http://www.theagileschool.com/2012/03/scrummasters-checklist-roles.html
    Product Owner
    Feature Team
  2. The PDCA cycle (http://www.theagileschool.com/2012/05/pdca-scrum-or-agile-why-is-it-important.html )  frequent communication about risks (daily)
    Plan – Sprint planning
    Do – Actual engineering sprint – deliver a potential shippable code
    Check – Sprint review
    Act – Retrospective 

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

Some other Guidelines




Saturday, July 21, 2012

How scrum training can help an individual or team?



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.

What is the right combination of a scrum team with respect to Developer- test break up; Role of a tester/QA person in scrum team




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



Sunday, June 24, 2012

Scrum: How to estimate new/unknown areas?


Basic rule - “Never assume anything”.

Estimating something new is very difficult for all the teams. You can provide an estimate only if you have basic knowledge of the area.


Following are few guidelines

New Domain – New Product Owner

Ideally the Product Owners should have the required domain knowledge.


  • If you are planning to get a new PO for the project, ask him (or her) to work with the existing PO. Even after the transition the old PO (if possible) should be available to help.
  • Bring domain experts from other projects/department/companies for workshops/discussion/training.
  • Ask the new team members to start executing the regression test cases to understand the business domain.
  • Subscribe to articles, magazines related to the domain.



New Technology


  • Do time boxed spikes but organize frequent feedback/brain storming sessions to discuss the new knowledge.
  • Do a POC 
  • Bring the experts for short talks/training if required.




Saturday, May 26, 2012

PDCA & SCRUM (or Agile); Why is it important?


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.

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

DO
Team works together to achieve the objective set in the planning phase. Team works with the set of agreed process.

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

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

  • http://en.wikipedia.org/wiki/PDCA
  • http://www.lean.org/Common/LexiconTerm.aspx?termid=287&height=550&width=700


Thursday, May 10, 2012

Team ratings in Scrum environment – How to measure individual performances

Measuring the individual performance in a scrum world is a very difficult proposition; in fact it is a paradox. Last day I had an interesting discussion on this with few scrum masters. One of the scrum master had a rating sheet which was updated after every sprint. There were points for scrum master, product owner & team. It was something like the following table

Another scrum master questioned the need of such ratings. A rating of 2.5, 4.5 or 4 doesn’t have any significance. It looks like the GPA score. If I get 9+ I will be considered brilliant; if I get less than 5 then I am a dumb, second class person. A Scrum Master with a very high score & team with low score don’t make any sense. It creates un-necessary competition.


 
Scrum is all about team work. It is a well-oiled machine. There is no individual superstar. Everyone has a part to play. If everyone performs their part to perfection, the full team including the SM & PO will get full marks. But I am not against ratings. These ratings should help the team and individuals to improve.

 
The ABCD of performance ratings

 
Personally I prefer a grading system like the one below.

 

 
  • A = Extraordinary effort. Did more than what was expected with lot of innovations 
  • B= Good effort, Met all the objectives of sprint & individual role.
  • C=Satisfactory, all the objectives of the sprint were not met. There is lot of scope for improvement.
  • D=Total disaster. (Can we replace this person?)
 
Giving ABCD grades is better than the numeric ratings. All the A’s are the examples of best practices; definitely you should share this with other teams. Team should try to convert all B’s to A’s. Here we need some innovation or out of box thinking. A new team will have lot of C’s . Initially this is a good thing to have. Scrum masters (& all others who can) should facilitate the removal of the impediments so that C is transformed to B. D is a special case. Special attention should be given to such cases. If the D’s are repeated for couple of sprints then, we should take the help of managers or HR. If you need some sort of individual performance metrics, just add all the A’s, B’s & C’s. (All the D’s will be out of the team or even company)

 
The UP –DOWN rating

 
Even this ABCD rating seems complex to me.

 

Just like scrum this method doesn’t have many rules (only common sense). Up arrow indicates that an improvement was made with respect to the role or task taken. The improvement should be noted & process which led to this should be identified and shared across.

A horizontal arrow indicates that the person has achieved what was expected from him/her. This doesn’t means that there is no scope of improvement. If we see this arrow consistently across multiple columns in multiple sprints then it is a pointer that the team & environment has stabilized. This is the right time to brainstorm to find better ideas which can improve the team productivity.

A down arrow points to the need of an action item to improve the process (or skill). Almost all the down arrows become a point for retrospective discussion. Like the ABCD ratings we can count the number & type of arrows to indicate the health & performance of an individual or overall team.


 

Tuesday, May 1, 2012

Scrum release planning: How to involve Juniors & Seniors & people from different background


Doing release estimation for a team is always tricky especially if the team is new or has a mix of people with different skills or experiences. Traditionally project managers did the estimates and in most of the cases it was under-estimated. Usually the PM takes the help from some subject matter experts before arriving at these estimates. Team will burn the midnight oil (or lamps :D, I hope they didn’t really burn it , there were many occasions when I wanted my PM to be burnt instead. ) But with scrum the estimation is the team’s responsibility. When I talk about this concept I get a lot of questions like the below


  • How can a bunch of people with different technical & domain skills estimate?
  • How can we trust the estimates from team, they will always over-estimate.
  • It is a waste of time, with so many people involved; it will be a never ending exercise.
  • The senior folks will do the estimation & juniors will go along with it without asking any questions. 


The questions are endless.

Estimates from a group of people are far better than an individual. It is better to have the estimates from the people who are going to develop the product. They will do an estimate by considering their strengths and weakness. If there is a domain/technical knowledge gap then they will be able to discuss and bridge this gap. This looks rosy, a silver bullet for all the estimation problems. Such silver bullet is not produced from vacuum; lot of work has to be done to make this bullet. Many teams find this group estimation very difficult & time consuming especially when they have a sizeable number of new people or junior resources. (I have seen experienced people also failing in this) These teams fail because they were not prepared for such an exercise.

Following are some good practices to prepare your team for release planning 

Training Plan for new/junior resources

You should have a training plan for any new resources in team. I suggest that every new team member should execute the regression test cases at least once even if they are developers or testers. This will ensure a common playground when the application features are discussed.   Everyone will understand and will contribute positively to the discussions.

For any new feature do the release planning in the following fashion 


  • Before you start ask the Product Owner to provide a high level overview of the features which are to be estimated. 
  • Divide your team into sub teams with a mix of Sr. developers, Jr. Developers & QA.
  • Assign each sub team one story from the backlog.
  • Ask the sub team to breakdown the story into vertical slices. 
  • This should be done in a time box 
  • After the time box expires, exchange the notes with other team. 
  • Review the notes received from other team and add any slices missing from the card
  • After the cards are reviewed by all, you can proceed with story pointing. 
  • It is the job of the scrum master to ensure that everyone speaks up. If the story is really difficult or complex then separate meetings should be set up. 
  • In one of my team, we used to schedule weekly meetings to discuss the upcoming features. In the first part of the meeting we discussed the story; the later part was reserved for all the technical discussions for the story. We used to discuss about the design patterns, the functions to be changed, the need of database script etc.  Usually we identify a lot of unknown, which were duly noted down. Based on our capacity we used to do the spikes on these unknowns and provide the answers in our next design meetings. 


You may solve the lack of domain knowledge in this manner.

Technical Knowledge 

The technical part is more difficult. It depends on the quality of resources you have. If you have good engineering practices like TDD, BDD then the transition will be fast.
When a techie joins our team we give a session on the business domain & technical aspects of the projects. We do a walkthrough of all the major classes and functions.
In my team we have a buddy system; a junior resource is assigned to experienced person. It is the duty of the Sr. guy to mentor the new resource and bring them up to the speed. The pair is given the complete freedom to choose the methods to achieve this goal. Sometime it could be pair programming sometimes it could be a detailed discussion sessions or anything that works.

The less experienced people might work in a module which they are not familiar but if you have god plan of initiation, do a good release plan & have a good technical practices then the transitions will be easy & new people should pick up the knowledge very easily. They might ask few extra questions & may take few hours more but it will benefit the team. I like this level of discussions and noise; I will be worried if people don’t make much noise or don’t ask any questions.

Sunday, March 11, 2012

ScrumMaster’s Checklist - roles & responsibilities



Last few days many have asked me about the roles & duties of a Scrum Master ( and some even the need of an SM in organization ).

Following is one of the best checklist which I could find. I am willing to help anyone if they need further clarifications.

A ScrumMaster’s Checklist
Posted by Michael James on August 13, 2007


An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things you didn’t previously consider possible, within a transformed organization — consider being a great ScrumMaster.

A great ScrumMaster can handle one team at a time.

We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.
If you haven’t discovered all the work there is to do, tune in to your Product Owner, your team, your team’s engineering practices, and the organization outside your team. While there’s no single prescription, I’ve outlined some things I’ve seen ScrumMasters overlook.

A.     How is my Product Owner doing? You improve the Product Owner’s effectiveness by helping maintain the Product Backlog and release plan. (Note that only the Product Owner may prioritize the backlog.)

  • Is the Product Backlog prioritized according to his/her latest thinking?
  • Are all the requirements and desirements from all stakeholders for the product captured in the backlog? Remember the backlog is emergent
  • Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It’s counterproductive to overanalyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers.
  • Could any requirements (especially those near the top of the Product Backlog) be better expressed as independent, negotiable, valuable, estimable, small, and testable user stories?
  • Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be adding automated test and refactoring to the definition of “done” for each backlog item.
  • Is the backlog an information radiator, highly visible to all stakeholders?
  • If you’re using an automated tool for backlog management, does everyone know how to use it easily? Automated management tools introduce the danger of becoming information refrigerators without active radiation from the ScrumMaster.
  • Are you working with the tool supplier to use it to its fullest capacity, or to change it to serve you better?
  • Can you help radiate by showing everyone printouts?
  • Can you help radiate by creating big visible charts?
  • Have you helped your Product Owner organize backlog items into appropriate releases (or front burner, back burner, fridge)?
  • Do all stakeholders (including the team) know whether the release plan still matches reality, based on the current velocity (story points per Sprint)?
  • Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product Owners who ship adequately tested products on time replan the release every Sprint, usually deferring some work for future releases as more important work is discovered. You might try showing everyone the Mike Cohn-style Product/Release Burndown Charts after the items have been acknowledged as “done” during every Sprint Review Meeting. This allows early discovery of scope/schedule drift.


B.    How is my team doing?

  • Are team members spending some of their time in the state of flow? Some characteristics of this state (from Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi)
    • Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one’s skill set and abilities).
    • Concentrating and focusing, a high degree of concentration on a limited field of attention.
    • A loss of the feeling of self-consciousness, the merging of action and awareness.
    • Distorted sense of time – one’s subjective experience of time is altered.
    •  Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
    • Balance between ability level and challenge (the activity is neither too easy nor too difficult).
    • A sense of personal control over the situation or activity.
    • The activity is intrinsically rewarding, so there is an effortlessness of action.
  • Do team members seem to like each other, goof off together, and celebrate each other’s success?
  • Do team members hold each other accountable to high standards, and challenge each other to grow?
  • Are there issues/opportunities the team isn’t discussing because they’re too uncomfortable? See Crucial Conversations: Tools for Talking When Stakes are High. Or consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable
  • Have you tried a variety of formats and locations for Sprint Retrospective Meetings? See Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen) for some ideas.
  • Has the team kept focus on acceptance criteria? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the product backlog items committed for this Sprint. Will the current Sprint Task list satisfy the acceptance criteria of each committed product backlog item?
  • Does the Sprint Task list reflect what the team is actually doing?
  •  Are your team’s task estimates and/or your taskboard up to date?
  • Are the team self-management artifacts (taskboard, Sprint Burndown Chart, etc.) visible to the team, convenient for the team to use?
  • Are these artifacts adequately protected from micromanagers?
  • Do team members volunteer for tasks?
  • Are technical debt repayment items (sapping your team’s velocity) captured in the backlog, or otherwise communicated with the Product Owner?
  • Are team members checking their job titles at the door of the team room?
  • Does the entire team consider itself collectively responsible for testing, user documentation, etc.?
  • Is management measuring the team by collective success?


C.    How are our engineering practices doing?

  •  Does your system in development have a “push to test” button so that anyone (same team or different team) can conveniently detect when they’ve broken it? Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).
  • Do you have an appropriate balance between automated end-to-end system tests (a.k.a. “functional tests”) and automated unit tests?
  • Is the team writing both system “functional” tests and unit tests in the same language as the system they’re developing (rather than using proprietary scripting languages or capture playback tools only a subset of the team knows how to maintain)? It’s possible.
  • Has your team discovered the useful gray area between system tests and unit tests?
  • Does a continuous integration server automatically sound an alarm within an hour (or minutes) of someone causing a regression failure? (“Daily builds are for wimps.” — Kent Beck)
  • Do all tests roll up into the continuous integration server result?
  • Have team members discovered the joy of continuous design and constant refactoring , as an alternative to Big Up Front Design? Refactoring has a strict definition: changing the internal structure of a system without changing its external behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling between objects, etc. Refactoring with confidence is only possible with automated test coverage. Holes in test coverage and deferred refactoring are cancers called technical debt.
  • Does your definition of “done” (acceptance criteria) for each functional Product Backlog Item include full automated test coverage and refactoring?  Youʼre unlikely to build a potentially-shippable products every Sprint without learning eXtreme Programming practices (as described by Kent Beck, Ron Jeffries, etc.).
  • Are team members pair programming most of the time? Pair programming dramatically increases code maintainability and reduces bug rates. But it challenges people’s boundaries and sometimes seems to take longer (if we put quantity over quality). Rather than force people to do this, lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way.


D.    How is the organization doing?

  • Is the appropriate amount of inter-team communication happening? Scrum of Scrums is only one way to achieve this.
  • Are your ScrumMasters meeting with each other, working the organizational impediments list?
  • When appropriate, are the organizational impediments pasted to the wall of the development director’s office? Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But remember Ken Schwaber’s discovery: “A dead ScrumMaster is a useless ScrumMaster.”)
  • Is your organization one of the few with career paths compatible with the collective goals of your teams? Answer “no” if there’s a career incentive to do programming or architecture work at the expense of testing, test automation, or user documentation.
  • Has your organization been recognized by the trade press or other independent sources as one of the best places to work or a leader in your industry?
  • Are you helping to create a learning organization?


Conclusion
If you can check off most of these items and still have time left during the day, Iʼd like to hear from you. Thereʼs no canned formula for creating human ingenuity. This paper lists points which may, or may not, help in
your situation.
Once you start to realize what you could do to make a difference, you may find yourself afraid to do it. This is a sign you're on the right track.

–mj
Software Process Mentor

  1.  http://blogs.collab.net/agile/2007/08/13/a-scrummasters-checklist/?q=blog/michaeljames/a_scrummasters_checklist
  2. http://scrummasterchecklist.org/pdf/scrummaster_checklist09.pdf


When you send  the email to MJ please keep me also in CC. I will also love to hear if you are able to check all the items and still have time :)

Agile/Scrum Bug fixing: Myths & dysfunctions


I can push bugs to backlog.
We can complete a story without fixing all the bugs
I have to finish all the stories first; the bugs can be fixed later.
Before the release I will have a maintenance sprint which will have only bug fixes.

The list is big. If you are doing anyone of the above please stop doing it before it is too late.
One of the fundamental requirements of scrum is to have a shippable product by the end of the sprint. There is no benefit in "finishing" maximum stories with lots of bugs. Scrum places high importance in the quality. With this approach of not fixing bugs will lead to accumulation of bugs & in few weeks you will have 100 + bug and you may spend couple of months fixing it. The cost of pushing bugs sprint after sprint will increase exponentially. The bug which could have been fixed in 30 minutes today will take couple of hours after 2 months!!! I have faced this problem in many teams I have worked with.

My simple advice is to slow down for higher velocity. For short term if try to ignore bugs, it will catch up with you in long term bringing the entire system to a standstill. Yes. I have seen this happening.

Go through the following article. It might help you.
http://www.theagileschool.com/2012/02/scrum-quality-teams-not-delivering-high.html

Tuesday, March 6, 2012

Commitment vs. Forecast : a small but important change to Scrum



This is a great article by Jose Luis Soria

One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of“forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it, and surely it will have great implications.

Read the full article @

http://www.scrum.org/commitment-vs-forecast

Sunday, March 4, 2012

Daily scrum misconception, scrum meeting objectives and different stages of meeting

I talk a lot about scrum. Many times when I speak I hear people saying that they are also doing scrum and they have daily scrum status updates. No other ceremony is so blatantly misused. It’s a misconception that scrum is only about stand ups. I have seen a project manager doing a scrum update with a big team, the status update itself took 1 hour, and the information passed was so huge that nobody remembers anything. By the time the last person updated his “status” the first person would be sleeping. Starting a daily meeting and asking for status update does not falls under Scrum. Many are thinking about “what are the scrum meetings rules” rather than thinking about “why do we need this meeting”. I prefer calling this as Scrum Planning meeting.

This is the planning meeting for the day. I can add the following objectives to the meeting
  • To see if the team is on the correct path, will they complete the committed task if not what changes should be made to accomplish the objective.
  •  Discuss and take actions on the risks faced by the team in meeting the commitments.
Apart from this status update mentality there are some dysfunctions also which should be avoided.

  1. Coming to meeting un-prepared - I have seen many occasions when team members come to meeting without any preparation. They are even unaware of the tasks which they are supposed to work on. 
  2. Big team - Having a meeting with teams bigger than 8-10 people is not effective. The complexity of communication will be huge & time consuming. There will be a high risk of meeting being derailed
  3. Status updates mentality - In many meeting team updates the status of work, there will not be any information about the task to be taken next. They end up updating this information to Scrum Master, Product Owner or other managers if they are present  
  4. The manager Product Owners Many managers are transitioned as Product Owners. They find this meeting as a forum for status update. They go around each one and ask the updates.

  
Even though daily scrum is time-boxed for 15 minutes, there are some pre & post actions which every team should consider.

Stages of a Scrum meeting

Pre – Planning
  • Before the Scrum meeting at least 15 minutes should be spend updating the task boards and other metrics if any. 
  • If any doubt regarding the types of tasks to be pulled then it should be cleared before the actual meeting.
  • If all the committed tasks are finished then team should plan to work on the next item from backlog. They can even do some research work on the items in the product backlog.  
Actual Scrum planning meeting
This is the actual scrum planning meeting
Follow the rules @ http://thetechjungle.blogspot.com/2012/03/daily-scrum-meeting-rules.html

Post Planning actions.
During scrum team might bring something of importance to notice which needs further action/discussions. All such meetings and follow-ups should be taken as the post scrum meeting actions.

Saturday, March 3, 2012

Daily Scrum Meeting Rules

Following are some of the rules which I could think ( & found from other sources) regarding the daily Scrum planning meeting

  • Scrum meeting should be for a small team of 4-8 members. Having a meeting for a bigger team is not beneficial. There is a high risk that it will become a status update.
  • This should be a timeboxed meeting of around 15 minutes. 
  • Hold the Daily Scrum in the same place at the same time every work day. The best time for the meeting is first thing in the day so that Team members think about what they did the day before and what they plan to do today.
  • Stand up – Ensure that team members are standing for this meeting. This will ensure that meeting will not exceed the normal duration as people will be eager to sit down. This will also help to focus on the discussion  otherwise people may get distracted with email or other “tasks”. 
  • Team members should address the Team. This is not a "Reporting to the Scrum Master" meeting. 
  •  If Product Owners are attending the call, they should refrain from asking status. Scrum has a separate meeting for this purpose – Sprint Demo/Review. Status can be obtained from taskboard also.
  •  All Team members are required to attend. If for some reason a Team member can't attend in person, the absent member must either attend by telephone or by having another Team member report on their status.
  •  Team members must be prompt. Team should start the meeting at the appointed time, regardless of who is present. Any members who are late pay a fine that is donated to a worthy charity! 
  • Decide some order for update like start with the person immediately to Scrum Master's  left and proceeding counter clockwise around the room until everyone has spoken. 
  •  Even Scrum Master is not required to attend this meeting. In Scrum Master’s absence or non-availability team should start the meeting.
  •  All team members should be present physically and mentally.
    o Avoid using cell phones, laptops, tablets etc.
    o Team members shouldn’t leave the room after giving the updates. They should remain till the end. 
    o Team members should actively listen and participate in updates from others. 
  •  Each Team member should respond to the following questions:
    o What have you done since the last Daily Scrum regarding this project?
    o What will you do between now and the next Daily Scrum meeting to achieve the sprint goals?
    o What impedes you from performing your work as effectively as possible? 
  • During the meeting only one person talks at a time. Everyone else listens without any side conversations. 
  •  When a Team member reports something that is of interest to other Team members or needs assistance from other Team members, any Team member can immediately arrange for all interested parties to get together after the Daily Scrum Meeting.
  • Non - Team members are welcome to attend the Daily Scrum Meetings but they are not allowed to talk, make faces or otherwise make their presence in the meeting obtrusive.
  • Bring experienced scrummasters or agile coaches to these meetings who can notice the problems and provide a constructive feedback.
These rules are more for new teams who are just beginning to use Scrum. If your team is following scrum for more than one year then you should definitely look into the next version of scrum meeting (scrum 2.0 :D ) 


How Salesforce.com delivered Extraordinary Results through a “Big Bang” Enterprise Agile Revolution

A story of Agile transformation @ salesforce.com
94 % Increase in feature requests delivered - 2007 v. 2006

38 % Increase in feature requests delivered per developer - 2007 v. 2006
Read the following slide for some more staggering data!!!
http://www.slideshare.net/sgreene/scrum-gathering-2008-stockholm-salesforcecom-presentation

Wednesday, February 29, 2012

Scrum Log Jeff Sutherland: SCRUM: Keep Team Size Under 7!

Scrum Log Jeff Sutherland: SCRUM: Keep Team Size Under 7!: Today, I wrote up an experience report on using SCRUM in large development teams for a new book that Craig Larman is writing. I described...

Sunday, February 26, 2012

Scrum Log Jeff Sutherland: Story Points: Why are they better than hours?

Scrum Log Jeff Sutherland: Story Points: Why are they better than hours?: Time to update this blog item as interesting new research has become available. The Standish Group has updated their findings on project...

Scrum: In a large enterprise environment can the scrum sprint/iterations synchronized?

I have a simple guideline for this

Leave it to the teams - unsynchronized sprints
  • Simple products with single teams working on it
  • If you have a different independent products which rarely or doesn’t communicate with each other.
Team will be more creative and it gives more flexibility. Because of all these unsynchronized releases there will be lot of churn so the management & PMO should use a lot of common sense in dealing with such cycles.

Use synchronized sprints
  • If you have a big product, with multiple teams working on it
  •  If you a product portfolio of products/applications which communicates with each other
  •  If you want to synchronize the release because of billing, reporting or any other similar reasons
  
Synchronization helps in large organization where we have to worry about lot of complexities. They will have a common reporting tool which can provide the correct view across all the teams. This helps in billing and other administrative jobs also.
In my company we have multiple teams working in a multi-billion USD product suite. We have a two week sprints which is synchronized across the different teams. There are many teams who have a 1 week sprint also.
e.g. – Assume the organization is in Sprint 03, team A is in two week sprint & Team B has one week sprints
So for the sprint team A will have only one sprint - Sprint 03
Team B will have two sprints - Sprint 03(a) & sprint 03( b).
After the two weeks, both teams will jump to Sprint 04.
How about common resources (people/machines)?

When the teams are in the synchronized mode, they may need some common resources (people or machines). How can we make them available for all the teams when they are synchronized? I have heard this question few times. Usually the planning for the sprint happens during the release planning but what is preventing them from discussing the need for common resources ahead of that? During the current sprint itself team can set aside few hours to identify the resources required for next sprint. The Scrum master should ensure that he communicates the need with other managers and scrum masters and make them available to the team at the right time. If due to any reason the shared resources are not available then it should be informed to PO. The necessary priority changes should be made in the product backlog of the team so that team can work on the next item.

I believe companies shouldn't over synchronize to exact date & time also. There may be people who are in multiple teams - Product owners and scrum masters. Ideally a great PO & SM can serve only one team but still we can see them serving more than one teams. Such “shared” people would miss on important meetings.  When I was the scrum master of two teams, I changed the sprint review dates to the next day. So on one day I could attend the review of first team and the very next day the second teams. On Tuesday I had the review of my first team like other teams in company and on Thursday I had my second teams review. It worked perfectly. These small changes in date and time allowed the little flexibility needed to accommodate the important stakeholders.

Sunday, February 19, 2012

Types of Scrum Master; Do we need someone with IT background as a Scrum Master?


Generally there are 4 types of Scrum master

1.Technical - Battle hardened IT engineer who are promoted as SM

2.ProjectManager - SM : Traditional Project Manager who transitioned to SM ( really !!! ). This is a very tricky situation. The traditional PM has to do a lot of un-learning before he/she can become an SM. The PM shouldn’t be made an SM of the same team which he/she was managing.

3.Leader SM - The true leaders SM who love people and help them transform, They may or may not have technical or scrum knowledge. They help in the transition or improvement with their influence and leadership qualities. At any day I would like to work with such thought leaders

4.Scrum Process zealot - SM : Someone who has received a lot of SM training, who follows the rules very religiously to an extend that he/she never allows any innovation (Change) around these. We need such SM’s when the team is new or when going through a lot of volatility. I have personally seen one of my managers helping the team in chaos with his tough rules. Once the team stabilizes such zealots should be transitioned/influenced to exhibit other traits.

We need all these types of SM on different projects depending on their maturity. Over emphasizing any particular trait will not help. Generally I have seen that the best technical person in the team is promoted (transition will be a better word – in agile we cannot promote because all are at the same level ). I am personal example of this (Now you know that I am the best techie. I hate to break this news so openly). I have personally seen that initially it works but the team will still look upto these techie SM for solutions. It was very frustrating for me to hear the pleas for help for providing those simple solutions which anyone can find easily by googling ( or yahoo or bing – I am impartial). There was many ways I made my team think and self-organize. But I had to put additional efforts for this. My effort would have been much easier if I was not a techie SM. Even now sometimes I hear the SOS call for my technical skills. My technical skills made me understand many discussions which happened in the team &I was able to question/influence many decisions. The biggest challenge was to manage myself rather than the team. Whenever I hear the discussion about any technical topic which was dear to my heart, it starts pumping more blood & my brain emits the hormones to my tongue to produce the necessary noise with the information ( oops I have to learn my Bio again , which reminds me that I got 92 % in HSC for biology WOW). Like a project PM I also believe that a techie shouldn’t be made an SM of the same team (especially if he/she was a tech lead). Technical SM should be helping the team members with his suggestions only when they ask and not push his technical knowledge or ideas. Use your brain, don’t answer all the questions guide them so that they can find the answers themselves. Teach your team fishing; dont give them fish.

Wednesday, February 8, 2012

Scrum quality – Teams not delivering high quality stories; testing not complete during sprints


You had a sprint demo and it failed miserably. A lot of stories were not fully tested. QA team is complaining that they don’t have any work during the first part of the sprint and they are overloaded during the last few days of the sprint. This looks very familiar.

For months we will work casually and during the last two months of the release there will be lots of last minute changes and bug fixes. It will be a virtual hell with late night hours. People will be coming early and going late (Many don’t even go home, they stay at office). Now this looks familiar. We have seen this in many projects. Scrum promised that such thing won’t happen again but still we can see such mini waterfall in our sprints. If you are seeing such issues, you should have a retrospective immediately.

A scrum team should be cross-functional. I will start with the following questions

• Why can’t the developer’s cross verify each other’s work?

• If testing is the bottleneck why can’t everyone help by testing few stories?

• Why does the QA team have to wait till the last week for testing?

• What is preventing the team from generating the build early?

• Why is the number of bugs increasing - are the unit test cases weak, are the acceptance criteria for the story weak?

• Is this a skill problem? Does the team require technical training?



Based on the answers you will get a nice perspective of the problem.

There are some suggestions also from my side to prevent this

• Implement XP practices like pair-programming, TDD etc. this will improve the quality (less number of bugs).

• No hands-off between dev. & QA (in fact there shouldn’t be such division itself).

• Make testers (dev. or QA) test the code in dev. machine itself before the build is generated. I have done this successful in my team. The feedback cycle was very small. No more time wasted in creating a bug in bug tracking system, assigning it, explaining it, providing the test data etc.

• Slice down the story to lesser size so that it can be managed & finished early.

• Create a continuous integration/nightly build. If build goes out every night then sure nobody can complain that there isn’t any task for testing.

• Team should swarm over the highest priority story first and only after its completion they should move to the second story.

• There is no dev task & QA task. Everyone should do whatever it takes to accomplish the sprint goals. Developers should test. QA should help dev. create code (they can create test data, set up the environment, automate the test case etc.)

Leveraging scrum for large projects (not large teams); number of scrum teams’ vs. team size



The idea of working in iterations producing potentially shippable software is very powerful. Scrum has some very simple rules to help achieve this. Scrum advocates that team size should be 7 (+/- 2). This works most of cases; almost all the software’s can be developed by teams of this size.

One + One = Two Scrum Team = One Big product team

What if I have to increase the team size? My project is complex and I need at least 12 people to deliver the product. Now this becomes interesting. In some cases I have seen such one big scrum team. Historical data has shown that productivity decreases as the team size increase from the optimum number of 7.

So what should I do?

Split the team into two.

On what basis can I split the team?

You can divide the teams into feature, service or subsystem teams; empower these teams to do their jobs. There could be some additional attributes to PBI to identify this linking. Team can work on such PBI from the common PBI list. So there could be teams working on one single area of the product exclusively. But ensure that they don’t become silos. There should be frequent communication, discussions or meetings with the other team.



What about the Scrum Master & Product Owner?

It’s good if the teams have separate scrum masters & Product owners. But the since the teams are working on the same product; the same scrum master & product owner for the two teams will work. If you have separate scrum masters and product owners; ensure that you have a periodic scrum of scrum for scrum masters and product owners. Scrum masters should work together to remove the impediments. The product owners should work together to groom the product backlog

Can I add more teams?

If your product is more complex, you can add more teams to scale up. But there are certain preconditions for these. As the number of teams increase there will be the need of better communication, coding standards, technical reviews, shared builds, code & document versioning, better application servers etc. For any team to succeed such pre conditions or non-functional requirements are very critical. These non-functional requirements should be given more priority than the function requirements. Tomorrow if you are going to start a project which requires 300 people; according to scrum you will need around 42 teams!!! Imagine the type of noise this number of teams can produce if the proper infrastructure is not set up beforehand. Initially you should start with one or two teams only. This team can work on the non-functional requirements like setting up servers, database, build etc. Ensure that some small function requirement is also done in the initial sprints so as to demonstrate the functionality of non-functional PBI’s. For example if you are setting up Continuous integration & nightly build in the first sprint; you can add a small functionality like creation of login page to the sprint. The sprint demo will be a success if the build can install the application and shows the functionality of the login page thus effectively verifying the build tasks.

How will I coordinate the work?

You can start some of the meetings like

Daily scrum of scrums – to discuss the impediments and risks. This is a scrum meeting where the team members ( or scrum masters of the respective team members )

Tech review meeting between the different team’s tech leads or team members. Based on the requirement you can decide on the schedule. These meeting can occur before every sprint to discuss the technical challenges faced by the teams & share the best technical practices.

Scrum of scrum for product owners to groom the backlog

Release plan review - the product management team should meet periodically to review the status of the product development & delivery. These discussions can be centered on the release Burndown.

Which product backlog to use? A common product backlog or different backlogs for different teams?

This is a very tricky question. I will list down few scenarios which I am aware of. Experiment and find the best method which works for you.



1. Common main backlog and sub-backlogs for each individual team

there will be a common product backlog, the master backlog of the product. Teams can create the sub PBI’s from the main product story and develop the story further. Each team can individually give story points to their PBI. The mother PBI’s story point will be the sum of all the child story points. If any parent story is dropped all the child stories will be dropped.

A hierarchy of product owners working together and slicing the main backlog


If a new main story is added & prioritized all the sub teams (or the teams required) will start working on the new story. The initial break-up of the story will be done by the product owners of the respective teams. After the initial breakup the product owner, the feature development team (& customers) further develops the story, adding the missing links, estimating etc. Each team will have an idea of their velocity. The team will continue adding the stories from the main backlog until their capacity for the release is used fully. There will be a lot of churn as the development goes on. It will be responsibility of the product owners and scrum masters to ensure that the team backlog reflects the actual priority of the main product backlog. In many cases teams will have to plan their stories based on the delivery of the dependent stories from other teams. Such a separation ensures that the team works on the stories which they have developed.



2. Separate backlog for each team; no centralized backlog

This can be implemented for small projects but for very large projects such an arrangement can be disaster. Product owners will have to ensure that each backlog reflects the priority of the customer. Such an arrangement needs a very extensive communication plan between the product owners, teams & customers.



3. One centralized backlog with PBI in different sprints

This is an ideal case. Stories will be prioritized. Each team will pick they stories from the main backlog and develop it. It will very common for one team to work on the stories story pointed by other teams. Personally I don’t like this idea. This leads to a lot of confusion and last minute knowledge sharing. But in case you cannot avoid there are some good technical practices which can minimize the pain.

a. Ensure that you are following the XP practices like pair programming, Continues integration build, nightly build, Test Driver Development (TDD) & Behavior Driven Development (BDD).

b. Apart from the INVEST principles of user story ensure that you add the High Level Design & Low Level Design document to the stories. This will help a third person to understand the stories in a much better fashion.


If we have separate backlogs for different teams, who will add items (or select items) for each team.
Based on the team skill set or knowledge of tools/application feature area expertise, Product Owner should add items to each teams backlog. He is the right person to make this decision because he has the correct vision about the product & is responsible for prioritizing the backlog to generate the maximum ROI. Anyone (including the dev. manager, team) can suggest new features but final decision should be made by PO.


A better definition form scrum guide

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Ensuring the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.





Thursday, February 2, 2012

Importance of qulaity in Agile world

Software which doesn’t works or which is full of bugs is of no value, whether you develop your code using waterfall or agile it doesn’t matter. One of the fundamental principles of agile world confirms this “Working software over comprehensive documentation”. Agile follows the principle of satisfying the customer through early and continuous delivery of valuable software. This fundamental guideline/principle itself emphasizes the importance of the quality. If I talk in scrum terms all the stakeholders are responsible of quality. The Product Owner creates the story, gets the necessary feedback from customers and discusses the acceptance criteria with the team. When the team starts working on these stories, all these quality/acceptance criteria are verified within the sprint (and after the sprint by the customer). Any deviation is noted at the earliest and necessary actions taken.

Sunday, January 8, 2012

Accomodate Bug fixing in a scrum sprint- (Scrum or Kanban)

A scrum sprint entirely devoted to bug fixing is very bad. But such situations are not very rare.

Scrum works perfectly with known feature deployment. Bug fixing works better with kanban. Bugs are unknown entity; unless team do some sort of exploration/spike work, they cannot commit on it.

http://www.agileweboperations.com/scrum-vs-kanban.

http://en.wikipedia.org/wiki/Kanban_(development)  

We have adopted a mix of Scrum/Kanban model for fixing bugs.
One of my team is in maintenance. During sprint planning we decide on the priority of the bugs and timebox all the issues based on the teams capacity. During the daily scrum meeting we discuss about the progress made. If the issue is critical, an update is send to the entire team every four hours. If any new issues are reported in between, PO prioritizes that and if it is the highest priority, team stops the work on the current bug and starts fixing the new issue. We encourage multiple people to work on the bugs. Once the top priority bugs are fixed, team moves to the next item in the backlog. If we take more time to fix than the anticipated timebox we inform the PO. Based on the discussion team will continue working on the exiting bug or work on a new higher prioritized bug.

Read the following also

Scrum : Non functional requirements testing in scrum sprint

The NFR’s and technical requirements should be part of the user story. These can be added as constraints to the story or along with the definition of “done”. Most of these NFR’s can be tested with unit test framework or automated test scripts. Sometimes the process cannot be tested directly. Suppose software requires triple encryption of bank transactions or such things then it will be very difficult to check the state in between. You will have to test the results to verify the process. The ticket generation or the account balance after the transaction will give a correct picture. Performance testing can be integrated with Continuous integrations build or nightly builds.