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.