Aligning Scrum Teams - Part 2: - The Pre-planning

The Part 1 blog discussed the challenges one might face with multiple component based scrum teams. In this blog let me discuss a solution to make these enterprise scrums deliver consistent results.

To start with, the team would need a solid pre-planning to put various dots in place before the actual planning happens. It's in fact more than that

1. Define goals - This is a big ticket item and you want to nail this accurately. Everyone should know where they are and where they are planning to go.
• The long term goal that defines the goal of the overall release.
• The short term goal, i.e. the incremental goal to all teams for the sprint. It should accurately define what teams will achieve in unison at the end of iteration.
2. Form a governing body that oversees the activities of each scrum team. The role of this governing body is to:
• Define short term and long term goals for the teams with help of stakeholders.
• Have regular weekly or bi-weekly meetings with participation of subject matter experts (SMEs) of various scrum teams. The function of this team is to discuss the short term goal and groom backlog for each team before the next planning session begins. All dependencies and exceptions should be clearly documented and monitored at regular intervals.
3. Make use of UI mocks where possible and educate the scrum teams on what you are trying to build. Knowing how the final product will look help teams put things into correct perspective. E.g. If the team knew how Amazon's website looks it would be easy to build the same.
4. Finally, each team should clearly understand objectives of the next iteration and ensure all stories planned directly or indirectly contribute ONLY to the above goals.

In the next blog, I will take this topic a step further and discuss how to gel this together and make certain teams are marching towards the common goal. 

Aligning Scrum Teams - Part 1: - The Challenges

Let me start this blog with an example - The goal of the next sprint is to deliver integrated functionality of features f1, f2, and f3 by scrum teams s1, s2 and s3.

If scrums teams are organized as Feature Teams (i.e. Scrum team formed with experienced members from UI, DB, Server, Testing components), it is very easy to divide the work as each team is contained and self sufficient to deliver the needed functionality. Each scrum team can be assigned one feature and they can accomplish end to end functionality independently. In the above example the possible assignment could be Scrum team s1 works on feature f1, Scrum team s2 works on feature f2 and Scrum team s3 works on feature f3.

However if organizations have large distributed teams, forming Feature Teams might not be practical due to lack of site affinity.  And most likely scrum teams will end up being Component Teams or specialized teams (e.g. UI team, Database team, Server team, etc.). In the above example the work division might look like this -

The UI team s1 works on UI components for feature f1, f2 and f3 i.e. f1.UI, f2.UI and f3.UI

Similarly, the Database team s2 = f1.Database, f2.Database and f3.Database

And the Server team s3 = f1.Server, f2.Server and f3.Server

Developing a product using Component Teams presents its own set of challenges. Some possible issues these teams might have if they aren't aligned correctly are:

1.            Interpreting the exact requirements for each features and prioritizing them correctly could be challenging. E.g. Team s3 must correctly interpret what is needed for feature f1, f2 and f3. They should also determine the priority order for each feature and deliver them accordingly.

2.            Coordinating delivery of functionality so dependent parties’ code is not broken. E.g. for Feature f1, teams s1, s2 and s3 have to coordinate well on their deliveries. If s3 misses on its f1.Server delivery it would miss on meeting end to end f1 functionality.

3.            Just in time development i.e. developing just enough to meet the needed functionality might not happen. E.g. Team s1 might develop too little or too much UI component for f1.

4.            There can be integration issues. E.g Feature f1, f2 and f3 are working independently without issues, but when they are integrated nothing works.

5.            End to end testing of the entire system can be challenging as QA engineers will test functionality within their Scrum only. E.g. QA engineers from Scrum s2 will only test DataBase functionality for f1, f2 and f3. QA engineers for other Scrums will do the same within their scrums.

6.            In the example I listed we are just considering 3 Component Scrum Teams developing 3 features. Most likely for an enterprise product there will be lot many more teams and features under development and thus the complexity increases exponentially.

7.            And Many more...

For global teams pre-planning becomes a must. A lot of details need to be ironed out upfront before the actual Sprint planning happens. Each team needs to work in proactive mode rather than reactive mode to build the right functionality. In the next blog I will list out some solid steps on how to align these distributed scrum teams. 

Adding new members to a scrum team -- does it Help or Hurt?

Consider a scrum team (component teams) operating in a producer-consumer model, catering to requests made by multiple consumers in each sprint. This team, based on their capacity and velocity, can deliver a fixed set of stories in each sprint. Which means that it is going to starve consumers if it cant keep up with their demands. In such circumstances there is a common perception that if more team members are added to this scrum team they will be able to satisfy requests from all consumers.

Adding new  members to the scrum team - does it help or hurt? Honestly, the answer is "it depends" - this situation needs to be weighed and evaluated correctly. I have come up with a list of questions based on my experience that could help  with decision making.  

• Is the current scrum team in an ideal range of 8 to 10 members?
• If it's already in ideal range, consider the impact of adding new members in terms of overhead on sprint planning and daily stand-ups.

• Are new members up to speed with the technology and scrum best practices to work in this scrum team?
• If the new team members are already hands-on with the technology and development environment (Build env, setups, hardware, tools, etc) they will be able to add value to the team much sooner.
• If new members need educational spike on new technology as well as setting up development environment then consider the overall impact on how much help/coaching  they will need from the existing team members.
• Also consider the effort needed to educate newer team members on scrum best practices which include coding practices, writing unit tests for code coverage, code reviews, etc.

• Does the addition of new team member disrupt the balance of Dev and QA ratio in the scrum team?
• If Dev/QA ratio is not managed correctly i.e. only developers are added to the team with no additional QA engineers, the existing QA engineers would have to take the load of extra testing, or team will have to cut down on new features being developed which would defeat the entire purpose of adding new members. 

• Are new members just added on temporary basis or is it a permanent move?
• The answer to the above question will vary depending on how the team is structured and organized.

• Are new members being added mid sprint or at the beginning of the sprint?
• Based on when the new members are added re-planning and re-assignment of tasks and stories might be needed.

It takes a while for scrum team to become self organized and execute to plan every sprint. Adding new members to the team can bring positive energy and help with the momentum of the scrum team or it can disrupt the team momentum. Careful evaluation should be done based on answers to the above questions. 

Sprint Burndown says a lot about your scrum team...

A Burndown chart is the graphical representation of amount of work left to do (y-axis) versus time (x-axis) and can help get a good heart-beat on how a scrum team is performing.

Some questions that Burndown can help us answer are:

1. How good is this team with the planning?
2. How well is this team executing against the planned stories in a Sprint?
3. Is this team self-organized and are they working in unison as a "team"?
4. What improvements can this team make?

Let us take few Burndown examples and try to answer the above questions.

Ex. 1: Line 1 – the Blue Line:

What does Line 1, the Blue line, tell us?

1.       How good is this team with the planning?  Not too good. This team's Burndown never reached zero. This might mean many things –

·         They might have planned for more stories then they could deliver in a Sprint.

·         They might have discovered unknowns after the planning meeting which translated in creation of new stories/tasks.

·         Sprint priorities changed after planning and that resulted in churn of stories.

·         The code quality of feature delivered might have been poor and that translated into defects, increased technical debt and eventually additional tasks/stories in the current Sprint.

2.       How well is this team executing against the planned stories in a Sprint?

·         Honestly, not too well. Their Sprint Burndown is all over the graph.

3.       Is this team self-organized and are they working in unison as a "team"?

·         It might be premature to deduce anything directly from this line. However, if this team has been in existence for a while, it would help to see their past Sprint Burndown and validate if similar trend occurred in the past.  If yes, this might be an indication that the team needs some extra coaching.

4.       What improvements can this team make?

·         Sprint Planning: This team definitely needs to improve in their planning. They should spend more time designing their stories upfront and might also consider breaking their stories into granular tasks.

    

Ex. 2 : Line 2 – the Purple Line

What does Line 2, the Purple line, tell us?  

How good is this team with the planning? 

·         From the first look one might get an impression that the team did well as their Burndown reached zero. But if looked at carefully, the story Burndown rate was way off the ideal Burndown line. Another thing to notice is the steep dive in the Burndown towards the middle. The steep dive can mean one of the following:

1.       The team did not proactively update daily data for the Burndown charts.

2.       Uncompleted stories were moved out of the current Sprint

The answer to rest of the questions is similar to questions from “Line 1”

Ex. 2 : Line 3 – the Green Line

What does Line 3, the Green line, tell us?  

1.       How good is this team with the planning?  

·         Good. They planned enough stories to keep them busy through out the iteration.

2.       How well is this team executing against the planned stories in a Sprint?

·         Good. This team executed to the plan – They inspected and adapted throughout the Sprint. 

3.       Is this team self-organized and are they working in unison as a "team"?

·         Yes, if this is the pattern they have achieved consistently in last few Sprints.

4.       What improvements can this team make?

·         Does not look like this team needs any help as they executed to the plan. However I  think there is always a scope for improvement in planning.

There are many other Burndown patterns that can be analyzed in a similar manner. An additional pattern I can think of for a Sprint is:

If team plans fewer stories than the available capacity, the Burndown will be under the ideal line and go to zero sooner than the end date.

When should QA be engaged in an iteration?

Someone going through my blog recently emailed me a question about when QA should be engaged in an iteration - should it be in the middle of the iteration or should it be at the end of the iteration? I believe the hidden question that the gentleman had was, what can QA accomplish in the very first few days of the iteration, while development is busy designing interfaces and coding to stories?

According to me the QA team should be engaged throughout the iteration. QA function is an integral part of the Scrum team. They are involved in planning meetings, they have stories just like development engineers and they have tasks to which they report everyday at the daily standup. The QA team brings a different perspective to the scrum team and plays a very important role in the scrum team. They help the scrum team meet the "Done" criteria for each story.

So what are the few activities that QA team members in a scrum team can help with?

• The QA team can work on design of integration and Acceptance tests that will help development ensure the stories are developed to Product Owners expectation. 
• The QA team can work with development on creating Mockups and generating dummy data to which they can start writing automated tests until the real interfaces are available.
• The QA team can help prepare hardware setups in advance, if needed. So when the code is ready there is no delay verifying the stories
• They can run the Performance and Scalability tests and ensure P&S guidelines are met.
• They can run manual tests on nightly builds to make certain new functionality is coded to requirements and no regressions are introduced.
• They can verify and close the defects fixed by the development team.
• They can open new ticket for all the issues encountered during their daily testing and help set high quality standards for the code under development.

In short, QA function is a very important function in the scrum team. I have heard comments like ‘Developers can play the role of QA engineers if there is shortage of QA resources’. But, honestly QA brings a different mindset to the scrum team - most of the developers think "How do I make this work" and QA brings the mindset of "How do I make this NOT work".

Making Release prediction on an Agile Project?

Let me show a very easy way of how a release can be predicted using an example.

Let's say, for a particular product under development, there are 5 scrum teams. Each team has special expertise and they contribute to a very specific area of the product i.e. UI, Infra, Security, etc. For this exercise also assume there are 20 epics that need to be developed before the product can be shipped to the customers. The management is trying to figure out a tentative schedule that can be published to the customers with enough confidence. How do we do it? The simple answer is using "Velocity".

And here are the steps to achieve it

Form a core team with subject matter experts from each of the 5 scrum teams, include the product owners and the Architects. This core team should breakdown each epic into sizeable stories that can be estimated.

These stories should then be assigned to respective teams. The output of this exercise might look like this.

Team A = 30 stories

Team B = 20 stories

Team C = 25 stories

Team D = 40 stories

Team E = 35 stories

The next step is to ask teams to do some high level story point estimation using planning poker for their assigned stories. Note that these estimations might not be very accurate, as most of these stories might not be granular enough to start work on. Let the team take a stab using their judgment and come up with estimations for each stories. Add story points for all the stories for each team and come up with an aggregate number for the overall effort. The output of this exercise might look like this.

Team A = 30 stories, 200 story points

Team B = 20 stories, 300 story points

Team C = 25 stories, 350 story points

Team D = 40 stories, 150 story points

Team E = 35 stories, 400 story points

You also need to determine the average velocity at which each team delivers business value. It sounds simple, but based on my experience, it can take as many as 6 to 7 iterations to predict with confidence what an average velocity of a team is. Now let's say these teams have been together for a while and are self-organized and their average velocity might look like this.

Team A = 20

Team B = 30

Team C = 25

Team D = 10

Team E = 25

Based on these numbers, you can easily calculate how many sprints the team will take to deliver the stories in their backlog. Here's the output after calculation

Team A = 30 stories, 200 story points, 200/20 = 10 iterations

Team B = 20 stories, 300 story points, 300/30 = 10 iterations

Team C = 25 stories, 350 story points, 350/25 = 14 iterations

Team D = 40 stories, 150 story points, 150/10 = 15 iterations

Team E = 35 stories, 400 story points, 400/25 = 16 iterations

Based on this calculation, you can easily predict that it will most likely take 16 iterations to have a release candidate. And if each iteration is of 2 weeks, it will take approximately 8 months to have a potential release.

Agile Retrospectives...

Recently I conducted an iteration Retrospective for one of the Scrum teams which resulted in a good discussion. The feedback helped in making some specific decisions for the team. These decisions had to be communicated to management as this team decided to do things a bit differently than other teams.


One question raised by management was if the Retrospective notes could be shared with everyone in the organization? 


According to me, Retrospective is a private meeting that the team conducts within itself. If retrospectives are conducted correctly, the team will show you exactly "what went well" and should be continued and also "what did not go well" and needs improvements. The "what did not go well" session could result in some heated and healthy arguments at times even with good facilitation. The question is, should this be shared outside this team? I guess, not. But at the same time, the things going well should be shared with the outside forum. Firstly to encourage and praise the team, and secondly so other teams can benefit from their experiences. 


But, what about things not going well? Should they be shared? My advice is, anything that could impact the team's performance or demotivate them, should be avoided at any cost. The notes can be shared, but should be filtered if it's going to be public knowledge. At the same time, management should be informed about the challenges the teams are facing and improvements the team plans to put in place. This way, management can help remove any roadblocks or impediments.


Thoughts?

My inferences from Agilepalooza - A Question on Legacy code

Let's continue this blog on the theme of AgilePalooza discussions...


I had a question on what is the correct way to handle legacy code that is inherited by the team that has no unit and integration tests? How does the team confirm that any new feature being developed has not introduced regression into the legacy code base? Should the team spend time in developing integration tests for legacy code before new features are implemented? 


These questions generated lots of good discussion at the AgilePalooza session. I was surprised that there are no simple answers to these questions. Most of Agile projects, according to the speakers experiences, start fresh.  I tend to agree with the exception that, there will be instances where it would be easier to inherit ready made modules rather than develop from scratch.  


Here are some possible answers that came out of the discussion panel

• Don't worry about legacy code too much. Ensure all new development happens with Agile/Scrum practices i.e. proper unit tests and Integration tests, etc...
• Dedicate some time in every iteration for performing manual testing to catch regressions.
• If you are working on Legacy code during new feature development, take some time to organize that area of the code. Add unit and integration tests for that part of the code .With time the code can be re-factored and overall  test coverage can be improved.
• The most convincing answer according to me is - Encapsulate legacy code into end to end functional/integration tests before new feature development begins. For any new feature under development these tests would help determine if any functionality is broken. 

In short, there's no textbook definition of how legacy code should be tackled in Agile development. Each project team has to analyse and make a decision for themselves on how much they want to invest upfront to tackle legacy code that would help them be more agile.

My inferences from AgilePalooza

It’s been a while that I have posted a blog and I had promised myself today to put my thoughts on events over the past week or so. First off, things are getting too busy at work with new assignment of Scrum Master Duties, in addition to a full plate of work I already had. But no complains there as I enjoy being a scrum master and eventually what matters is the satisfaction I get on the contribution I made to the success of a project.

Last week we had an entire day event “AgilePalooza – EMC Private day” organized by VersionOne  at EMC.  One would expect such sessions to be product centric and more of marketing and sales pitch about their product. Anyone coming to this event with that expectation would have been disappointed as that was indeed not the case. The entire event was filled with tons of good Agile/Scrum experience. There were really knowledgeable speakers like Mike Cottmeyer from Pillar Technologies and Giora Morein from Big Visible, sharing their experiences on enterprise Agile/Scaling. There were some good discussions on certain topics that I would start listing out in my upcoming blogs.

But here’s one...

I mentioned in one my earlier blog that Velocity of the teams can’t be compared and that’s still true. However, one of the speakers mentioned that Velocity metric can be used to compare teams and see which team is more efficient. I was taken aback a bit, but this makes sense…

Here’s an example – In this hypothetical example, consider both teams started at the same time, with the same expertise, with the same sprint duration and the same estimation skills. The table below tells us that Team A is improving with each iteration. Their velocity is going up with each sprint and seems like 30 is an average velocity this team will attain in future iterations.

Team A velocity over certain interval

Sprint 1	20
Sprint 2	25
Sprint 3	28
Sprint 4	30
Sprint 5	30

Team B velocity over certain interval

Sprint 1	15
Sprint 2	10
Sprint 3	14
Sprint 4	12
Sprint 5	10

Compare it to team B and it seems that they have been struggling. The velocity of team is in the range of 10 to 15 and at no point can you predict what can be realistically achieved by this team. So if comparison is done in this order there is no doubt Team A is far superior to another.

Any thoughts?

Challenges with Daily Stand-ups...

As a Scrum Master did you ever face these situations where

• The daily stand-ups ran for more than 15 minutes? 
• The Chickens interrupted the stand-ups or took it over? 
• The issues concerning only 2 parties were resolved at stand-ups rather than being discussed offline or after stand-ups?
• The team members gave scrum updates to the Scrum Master rather than the team 
• A team member gave one line updates or just mentioned “No updates today”?

As a scrum master, I have faced all the above mentioned situations and have resolved them successfully.

At times, I had to cut conversations and remind them that this is daily scrum stand-up of 15 minutes and NOT a status or a design meeting.

Sometimes chickens attend the scrum meeting and they might have something of real value to add to the conversations and I had stopped them from speaking up and asked them to take it after the scrum - this might seem unnecessary, but it’s needed to enforce scrum best practices.

During stand-ups, as team members go over their updates and bring up issues, I note them down. However, instead of trying to resolve the issues right there, after the stand-up I pair up team members to resolve these issues offline. For issues that concern the entire team, I ask them to resolve right after the stand-up.

Often I had noticed that some team members have a tendency to provide their updates to the Scrum Master. I had to educate them that stand-ups are for improving the communication and increasing the visibility and that the updates are for the entire team.

Sometimes it just happens that someone would give a one line update which just doesn’t make sense. In such a situation, I would randomly pick another person from the team and ask if he understood it. If that person can't explain, then the update was not good enough (Or maybe he just wasn't paying attention :-)). The team needs to be trained to provide balanced updates i.e. don’t give too many unnecessary details or give too little detail that others can’t make sense out of.

In short, running daily scrum takes a lot of discipline on part of the Scrum Master. However, once scrum best practices are adopted and followed by the team for a few iterations, the daily stand up becomes second nature for the team and everything runs like a well oiled machine.