The Agile School

Agile teams work in iterations. During this period, they are supposed to work on product increments which can be “delivered” at the end of iteration. But how you know that the correct product was delivered? Many teams have different kinds of acceptance criteria and Definition of Done (DoD). But in many cases, this “done” is not the real “done” there might be some testing pending, some integration or review pending or anything else which prevents the actual use of the product increment. Many of these teams will need additional iterations to finish hardening their products. Many teams will implement different types of “gates” or approval steps to move to next stage. The free flow of product will be interrupted. They might end up doing mini waterfall within their agile process. Many don’t even realize this. This results in poor quality and requires additional effort to “harden” the product. Potentially Shippable Product increment The acceptance criteria and DoD should be modified...

I like user stories a lot. They help everyone talk the same language and results in a better product. User story alone does not constitute product requirement. User story is supposed to be a place holder for discussion which should happen between the team, Product Owner and the customer. This discussion result in a common understanding which along with the user story content is the product requirement. This format captures the essence of requirement without confusing the readers User Story is only one of the many different ways in which requirements can be represented. This is not mandatory in any Agile “process”. But many have made this mandatory. I have seen many spending countless hours trying to write the requirements in user story format when they could have easily written that in simple one-line sentence in few minutes.   I have seen team members refusing to even discuss the requirement until product owner rewrote the requirement in user story format. ...

Daily stand up meeting serves a very important role in agile teams. In a way they are the risk mitigation meeting. Team members talk about the risk for the iteration and overall product delivery. The need of a daily stand up for a new team and a matured team is different and hence the need for different rules for different teams. Teams who are starting the agile/scrum journey needs a lot of help. They might be new to agile or might be working together with each other for the first time. A structured well-defined set of rules will help them grow. For such teams the following rules are more than enough Daily Scrum Meeting Rules - http://www.theagileschool.com/2012/03/daily-scrum-meeting-rules.html   Daily scrum misconception, scrum meeting objectives and different stages of meeting http://www.theagileschool.com/2012/03/daily-scrum-misconception-scrum-meeting.html Only team members are “allowed” to speak and scrum master should be present to help the team. This rule im...

I have done that !!!! Many years ago i inherited a team which had lot of issues . The PO and team didn't trust each other. I had my first retrospective with Product Owner (PO) alone and my second retrospective with team but without PO. Usually followed by a third retro meeting with PO and team . During the first two meetings PO and team talked about the issues they had with each other. I shared the feedback to each other along with my coaching and mentoring. During the third meeting we focused on the product and common issues which we could solve together. The focus was to create trust and transparency.  I have seen this in many other teams also because of many reasons. Team members were not willing to talk about all the issues in front of PO because they don't trust the PO. In my case after lot of coaching and mentoring both groups agreed to have a common retrospective. Soon we became one of the best teams in our group. Retrospective is the meeting where everyone...

I have seen this conflict in many organizations which are new to Scrum/Agile. Most of them are transitioning to agile methodologies from the traditional methods. It’s very difficult for that management to let go the power hierarchy. They still want one single neck to catch. They never believed in collective thinking. Rather than motivation , their believe in pressure to get the work done. Such dysfunctions exists in most of the organizations, scrum just exposes it. ScrumMaster doesn’t run the scrum. He/She should help build a team, bring out the leaders in every member of your team. ScrumMaster helps the team to self-organize so that they can move forward without the classic “delay” of waiting for decisions. ScrumMaster is not a person who can be used as a single neck to catch or blame. Scrum is a collective team approach. If it succeeds everyone succeeds if it fails everyone fails. ScrumMasters in such an environment have to do a critical job in the transition. You will have ...

A ScrumMaster needs a different skills and mindset than a normal developer. I have worked in teams where I was part time scrum master & developer.  In many other projects I was full time Scrum Master.  Both projects were a success. Based on my experiences if I have to answer this question I will say that it depends on the project but given a choice I want my ScrumMaster to be fulltime. Being a technical person helps the ScrumMaster to understand the language spoken by the team. But if he/she is also working as a part time developer then the Scrum Master will be more interested in finishing the bugs/Product Backlog Items. Then who will protect the team from PO & other stake holders?  Who will coach them? Few months’ back one of my colleagues complained that his ScrumMaster is interested in only in finishing the work, there was no feeling of being part of a team because the ScrumMaster was busy finishing his bugs. He rarely motivated the team.  I came f...

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  The roles of Scrum • Scrum Master -  http://www.theagileschool.com/2012/03/scrummasters-checklist-roles.html • Product Owner • Feature Team 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. A...

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

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

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

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

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

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

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

Anu is a new scrum master. After the project kick off meeting on further discussion she realized that for a successful delivery as a pre-requisite the team needs a lot of infrastructure work to be completed. PO wanted the feature development work to start as soon as possible. Team had serious concerns about the delivery if they start the actual work without the required infrastructure. What can be done in this situation? I met with Anu and we agreed on the following Identify the most critical requirements required for the team to start work. Do a casual analysis with the subject matter expert and the team and find the cost (duration + software + hardware costs) of doing (and not doing) Anu held meetings with the team, PO & other stakeholders. This teamwork produced a wonderful infrastructure backlog and was presented to PO. She also added the dependency to this backlog. Nice to have infrastructure were at lower priority. This infrastructure work was added to the first two s...

Traditionally user stories (or requirements) were written by Business analysts. They used to prepare big documents after months of study. It was a herculean task. I used to get such UI/Functional specification documents. I have fixed a lot of bugs because I missed few text in such 1000 + pages document. This is not the only interesting part. Some of the requirements were so weird that I often wondered why I am creating the features which no one is going to use. If I had the option I would have recommended a better option. If the BA’s misunderstood some requirements & customers failed to correct those few words in the epic requirement then we will have a nice situation. In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s... anyone can up...