Tuesday, November 24, 2015

Agile at Scale – What to Do When a Sprint is Cancelled?



At one of the lowest levels of Scrum development, you have Sprints. If you are combining Scrum with Kanban or have another iterative and incremental development, then you are likely to have iterations. In either case, with a small team and one Sprint backlog, it is easy to manage the dependencies, have the needed integration and deliver. When you have multiple sprints (iterations) running in multiple teams, the complexity increases in managing dependencies and delivery. 

In such case, synchronization of Sprints is a practice for Agile development at scale.  In place of overlapping Sprints, it is advisable to have synchronized Sprints for good collaboration, develop a cadence and have dependency management. Now, what happens when one of the Sprints - synchronized with same length or nested with different length – gets cancelled?

Sprint getting cancelled is rare, but it might happen, e.g., when the goal of the Sprint is no longer relevant.

Say there are Sprints of different lengths with a cancelled Sprint for one of the teams. The situation looks like this as shown below (Figure - 1). I have 3 teams – Team 1, Team 2, and Team 3 - running Sprints. The Sprint lengths are different. For Team 2 and Team 3, it is nested inside the Sprint for Team 1. But, Sprint 1 for Team 2 has been cancelled for certain reason.


Figure - 1
So, what can be done in such a case? Will the team immediately start the next Sprint? If not, will the team seat idly? 

Some suggest that add on the days leftover from the current Sprint to the next Sprint and start off, which is like the one shown below (Figure - 2). As shown below, Sprint 2 of Team 2 has been extended to start some days before. Note that I have shown first Sprint getting cancelled. It may be other Sprint in the development cycle.

Figure - 2
In my view, it is not a good idea. There are certain reasons which I will outline.

First, Sprint cancellation is not an easy thing to digest by the team members. Let the team find out what went wrong or if by external reasons, what could have been done better. That takes some time. Starting off immediately, does not help address this case. In fact, I would suggest to have a small retrospective of what went wrong and how it can be avoided. 

Second, the changes that you have made to the codebase while running the Sprints have to be commented out or removed or placed into separate classes or packages, as they may not used now. The branches that been created to have the code checked in and tested have to be tagged as such. If they have merged to the main branch (if there are dependencies with other team), have also to be addressed. These take time. 

Third, though I am saying that Sprints can be of different length in different teams, I am also suggesting for the same team keep the team length same. Going forward, for every Sprint, I would like to see improvement in terms of delivery, e.g., by checking on the velocity. This is not possible if we change the length for the same team. 

Fourth, Sprint length should be kept at same length (at least for 1 or 2 quarters) because it helps in reaching a high productive state. If you keep on changing the lengths, it breaks the rhythm or cadence.

Fifth, think of distributed environment where Sprints are running. How can the next Sprint immediately start off, if the previous Sprint is cancelled? It is just not practical.

After the cancelled Sprint, start the next Sprint as depicted below (Figure - 3). Have the next Sprint as scheduled earlier, which you would have done in your release planning. 


Figure - 3
So, what the team will do for the time left? There are many things that can be done, e.g., doing a small retrospective, Product Backlog refinement, technical debt payoff, making the changes to the branches etc.

You may also like:



Wednesday, November 11, 2015

PMP Success Story: Remove Your Mental Block, Open Up and Think in Terms of PMBOK’s Best Practices




Aswin Krishnan H is a proud PMP today. His success is not only due to sound preparation, but also handling stress during the exam. He names it as the “smile” factor, as he has told below so uniquely. 


Aswin was part of my class in May, 2015. He is a very lively person and participates fully. In fact, I remember few instances where his enthusiastic participation were bringing surprised looks on some faces. In my view, enthusiasm is a great quality in any team member. But, unfortunately, it is highly underrated. I believe, enthusiasm is contagious and brings many into the fold of discussion. He called me after he was certified and I asked – “How does it feel to be a PMP?” He had a sense of happiness, relief and immense satisfaction. 

Below, he has outlined his experience in preparing for it, going through the PMP program and finally cracking the exam. Go on and read his experience.

*******

Introductory – Why I decided on it and how I started?
I was motivated to do PMP as part of my job and wanted to understand properly the Best Practices and how to use them with confidence in day to day activities as far as possible.

Three of my friends were equally interested in doing Industry standard certification and when we began our search we had PRINCE 2 and PMP in our mind. Finally, we settled down with PMP which has huge demand in any industry. We then started our search for Training provider, found that it’s the Coach and his approach that help a lot in this kind of Certification, though online and word of mouth reviews.

One of my friend had a successful experience in securing his PMP within a month after training with the Coach Mr. Satya Narayan Dash, He was really impressed by his practical approach, knowledge and personal commitment. He has previously attended PMP trainings from various centers but never could understand the concepts clearly, and failed in the exam miserably. He came from Chennai to do the course in Bangalore, just for the Coach.

My PMP Training Experience:
The training was very precise and covered all Knowledge Areas from the 5 Process Groups: Initiating, Planning, Executing, Monitoring and Controlling and Closing. Satya was very kind and use to share his personal experiences with certain problems which helped to see insights of approaches and reason why or what suits best based on the PMBOK Guide. He always helped us think about all the process and why each Input is given and what is the output of each process and why it is important, often in many of the companies we don’t practically use all the process or tools but the Coach’s insight in all tools and approaches was very helpful in understanding the Input, Tools and Techniques and Output (ITTO) for each Processes.

We had classes on Weekends, the coach was very punctual and kept his timelines very strict. He was very happy to help even after the classes and he would stay back for us even if it was raining just to make sure that we get the idea of what is happening or why it is happening, He use to explain ‘Change Request’ or ‘Deliverable’ Flow by drawing pictures as it goes through each processes. These insights really helped in understanding the concept and the interrelationship between each process and ITTO.

In the entire class there was fun, all were active and were participating which the coach always managed to make it interactive. Lot of things we need an actual physical person to explain to us rather than just going through hours and hours of Videos. I understood that having a real person standing in front of us will build that physiological effect, which will help me learn more and get motivated easily.

My Own Study:
I really wanted to complete the exam within 2 months after completing the class, but due to personal commitments it got extended to 4 months. Every-day I use to spend at the least 2-3 hours reading PMBOK 5th Edition, Rita Mulchay. This really solidified my understanding that was gained in the Classroom training. 

In the last one or two months I use to keep on giving Mock Tests in the early mornings (4 -7 am) and then review them after coming back from work (7 - 8 pm), I kept on giving mock test from various places and was not be very subjective in selecting the source for exam. I felt that giving these mock tests really boosted my confidence and triggered to schedule the exam. While doing the mock tests most of the times I was in panic and I didn't read all options and selected the wrong one. Rita Mulcahy's recommendation helped. I read the options from D to A instead of A to D. This really increased my hit percentage.

My PMP Exam Experience:
I became a member, filled in my application, got my references and waited for a week to get it approved; luckily it was not selected for any audit. That was half way done, second challenge was to schedule the exam. I kept on giving mock tests until I had the confidence and was hitting 75-80% in mock tests. This triggered me to schedule an exam, at this time I just wanted it to get over at the earliest; luckily I found a date that was within 10 days and scheduled the exam on that day.

I had formulated this strategy of completing 70 questions in an hour so I will be done within 3 hours at the max (200 questions) this I kept on applying while taking the mock tests and this strategy was quiet successful for me.

On the Test day, I was faced with a flurry of Mathematical questions (20-25) from Question No#1 with all confusing stuffs and very wordy; I was very stressed, then I remember reading somewhere that even if you are stressed and if you manage to keep a smile on your face you can beat the stress. I applied the same and was able to get over the initial surprises in the exam. There were lots of situational questions, I was confused in lots of places; I marked them and kept on moving forward without worrying about the lengthy or wordy questions and kept on answering whichever I could. Finally, by the time I was done with 200 questions, it was like 2:30 hours; so I went back and selected all the unanswered and marked ones and slowly went through each one of them, now ‘smile’ factor worked and was able to easily and clearly read the questions and answer them. I completed all left outs within 45 minutes. Now I started reviewing again from beginning and just kept on speed reading questions and selected answers just to make sure that I did them correctly. The PMP really puts a toll on you with all sorts of Mathematical, Situational, and Tricky Questions, the initial impact of the questions is really intended to create stress, if you overcome that then you would be able to score very easily. During the exam I read the answers from D to A instead of A to D, I found this to be very helpful against panic answering due to stress.

Suggestions for PMP Aspirants:
- Dos
  • Please read PMBOK at the least twice, it is very helpful and answer to PMBOK and not to your personal experiences.
  • Please take any book like Rita or Andy Crowe or Head First and complete them once before kick starting the mock tests.
  • Please keep a smile on your face, even though you are stressed, this will help relieve stress and get back to your senses while taking test, if you are in panic answering mode read the answers from D to A than from A to D this will improve your hit rate, these helped me.
  • Please do take 10-15 mock tests before attempting the exam, this really helped me understand where I stand and what my weakness is and helped to motivate and improve.
  • Real life PM experience helps a lot while answering these questions during the exam.
- Don’ts
  • Don’t waste time prolonging the exam, use your time wisely and complete it at the earliest.
  • Having too many materials won’t help as you will be confused when to complete them, don’t get overburdened.

Conclusion:
After earning PMP I am much relived, I can see the fruits of hard work getting paid off. Whenever you say that you are PMP, there is a peer respect, because all of them know how much committed you need to be to earn this prestigious qualification. I now see what things at work do work and what not and how they are interrelated. PMP is not just a one-time process, you can apply this leanings in each every aspect of your life which you are doing unconsciously. Finally If I CAN DO IT ANY ONE CAN. You just need to remove the mental block and open up and think more in terms with best practices put forward by PMBOK, and your personal commitment.

Brief Profile: 
I am Aswin Krishnan H and am a Project Manager with Hewlett-Packard, India. I have 9 years of experience in Telecom, Retail and Security Domain with .NET Platform. 

*******

Aswin’s online PMP credential is available at PMI’s online credential registry.


I am thankful to Aswin for sharing his journey in achieving the PMP certification. I believe it will help you – the PMP aspirant – to have your own. 


Book Available for PMP Exam:
You may also like:

Saturday, November 07, 2015

PMI-ACP Prep: Agile Scrum - Sprint I/O (Inputs and Outputs)


[NEW: Latest Sprint Inputs and Outputs 2021 (Sprint I/O)" (Link)]

Takeaway: At the heart of Scrum is Sprint, but the heartbeat of Scrum development is the Cadence. Cadence is developed when you have regular Scrum Planning meetings, Sprint retrospectives, Daily Scrums, Sprint reviews and you keep on delivering releasable and usable versions of the product. Key here is delivering working product of highest value to the customer – one of the cornerstones of Agile Manifesto, i.e., Working Software or Product. As cadence is important, so are the ceremonies (or events) of Scrum, as they build the cadence.

Hence it is important to know the events of Sprint and what are the inputs and outputs (I/O) of those events. In this post, I have not taken the various tools - such as task board, online spreadsheet, electronic tools and estimation techniques – such as planning poker, T-shirt size estimation. They tend to vary a lot from team to team.

There are 4 events (or ceremonies) in Scrum.
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
The inputs and outputs, for the events, are as follows. 

Event – 1: Sprint Planning


Sprint Planning I/O
When? Happens after the Sprint review of the previous sprint, but before the first Daily Scrum of the current Sprint.
Who? The participants are: Product Owner, Development Team and Scrum Master
Others, e.g., subject matter experts or domain specialists can be invited into this meeting.
How Long? Timeboxed to a maximum of 8 hours for 4 weeks Sprint. Length will be less for shorter Sprints, e.g., 4 hours for 2 weeks Sprint.
What For? Sprint planning, as the name tells, plans for the work and forecasts the functionality to be developed during the Sprint.

Sprint Planning Inputs:
  • Refined product backlog: Product backlog, before presented in the Scrum planning, has to be refined (also referred as backlog grooming) by the Product Owner. Refining means having fine grained items ordered on top of the Product Backlog with ID, description, estimation, and value.  
  • Projected Team Capacity: It is a simple calculation considering the length of the Sprint, number of development members (and sometimes availability of the team members)
  • Projected Velocity: It is the past performance of the team. It is kind of the yesterday’s weather. It may or may not be available, e.g., for the 1st Sprint, it won’t be available.
  • Definition of Ready: I am taking this term "Ready" from the Scrum Guide, 2013. Ready means the story that can be done by Development Team in one Sprint are pulled from the Product Backlog to Sprint Backlog.
  • Key Stakeholders: Subject matter experts or domain specialists can be invited into this meeting among others (as needed).
Sprint Planning Outputs:
  • Updated Product Backlog: As the items are pulled into the Sprint backlog, there will be discussion on the product backlog items – some of the product backlog items are likely to be updated.
  • Sprint Goal: It has the objective that will be met in the current Sprint. Should be in terms of business value to be delivered.
  • Sprint Backlog: It has the forecasted product backlog items that will be delivered in the current Sprint. It also has the plan for delivering the work items, in decomposed form, to have the product increment.
  • Sprint Review Date: This is the demo date. Sprint gives the potentially releasable version of the product. On the demo date, the product increment is demonstrated.
  • Estimated Velocity: After development team takes up the product items that can be done in this Sprint, the estimated velocity is known.
  • Development Activities: The product backlog items are broken down (or decomposed) into development tasks (or activities) by team members. They can take help of technical specialists or SMEs who are invited to the meeting. 
  • Definition of Done: A checklist of items when the product backlog items selected into the Sprint Backlog will be considered complete.

Event – 2: Daily Scrum

Daily Scrum I/O
When? Happens daily after the Sprint planning. 
Who? The participants are: Development Team and Scrum Master, Product Owner 
How Long? Timeboxed to 15 minutes a day. 
What For? Inspect progress towards the Sprint goal; Inspect progress towards work being completed from the Sprint backlog; Synchronization; Communication

Daily Scrum Inputs:
  • Sprint Backlog: See Scrum Planning I/O. Sprint backlog is a plan which has enough details that helps team to understand the progress during the Daily Scrums. 
  • Spring Goal: The 3 questions (yesterday’s work, today’s work, and impediments) that are asked in Daily Scrum have to be aligned towards the Sprint Goal. 
  • Development Activities: See Development Activities input in Sprint Planning.
  • Impediments: Issues which are preventing the team members from executing their work.
Daily Scrum Outputs:
  • Updated Sprint Backlog: Daily scrum helps in inspection, planning, adaption for the next 24 hours. If any new work is needed, the Sprint Backlog is updated. Sprint backlog is also updated when work is completed.
  • Development Activities: The development activities are updated. Estimation for them may also change. 
  • Impediment Backlog: Not all issues can be resolved immediately, after the Daily Scrum. Impediment Backlog helps here to keep track of the issues when raised in Daily Scrum. It has to be tracked and resolved by the Scrum Master.
To have proper utilization of time (remember - 15 mins!) revised estimations or updating of tasks can be done immediately after the Daily Scrum. 


Event – 3: Sprint Review

Sprint Review I/O

When? Happens at the end of the Sprint, and before the next Sprint Planning.
Who? The participants are: Product Owner, Development Team, Scrum Master and also Key Stakeholders
How Long? Timeboxed to 4 hours for 4 weeks of Sprint. Length will be less for shorter Sprints, e.g., 2 hours for 2 weeks Sprint 
What For? To inspect the product increment and adapt the product backlog. 

Sprint Review Inputs:
  • Product Backlog: Product backlog items which are “Done” and “Not Done” in this Sprint are explained by the Product Owner
  • Product Increment: A potentially releasable version of the product developed by the Development team. It is the combination of all product backlog items completed in the current Sprint and value of increment of all previous Sprints. 
  • Sprint Goal: See Sprint Planning I/O.
  • Sprint Backlog: See Sprint Planning I/O.
  • Definition of Done: See Sprint Planning I/O. 
  • Business Conditions: I am taking this as an umbrella area - for market conditions, environmental conditions, new or changed business condition, new opportunities etc. - based on which the Product Backlog is revised.
Sprint Review Outputs:
  • Revised Product Backlog: It will have probable product backlog items for the next Sprint.
  • Inspected Product Increment: The product increment demonstrated by the Development to the key stakeholders. 
  • Completion Date Forecast: Product Owner gives the likely completion date based on progress done to date. This is mostly done for the upcoming release.
  • Actual Velocity: Shows the actual velocity of the Scrum team, i.e., taking up the items actually done in this Sprint. Estimated Velocity and Actual Velocity help in final updates to the Burn-down chart.

Event – 4: Sprint Retrospective

Sprint Retrospective I/O
When? Happens at the end of the Sprint, but before the next Sprint Planning.
Who? The participants are: Product Owner, Development Team and Scrum Master
How Long? Timeboxed to 3 hours for 4 weeks Sprint. Length will be less for shorter Sprints, e.g., 90 minutes for 2 weeks Sprint.
What For? For the Scrum team to inspect itself. A plan is created for improvements that can be undertaken in the next Sprint. 

Sprint Retrospective Inputs:
  • Definition of Done: See Sprint Review I/O
  • Sprint Backlog: See Sprint Planning I/O
  • Spring Goal: See Sprint Planning I/O
Sprint Retrospective Inputs:
  • Updated Definition of Done: Scrum team can plan ways to update the Definition of Done, e.g., stronger criteria for quality. 
  • Improvement Plan: Improvements are identified in the retrospective and a plan is created to implement those improvements.