The Power of Anonymous Retrospectives

The Scrum values – Openness, Commitment, Focus, Respect and Courage are the foundation for the behavior and practices in Scrum. It’s difficult for organizations to adhere to these values from the onset of their Agile journey. Agility is about behavior and cultural changes and the values listed can’t be demanded, they have to be earned by creating transparency and is a journey that never ends.

While coaching Agile teams over the years, I have learned that no matter how open and transparent the organization is, there will be some individuals that won’t openly speak up. They are mostly introverts and have a phobia of public speaking. They will limit their interaction to a bare minimum. In some organizations engineers carry the management fear. They feel like they are being observed and anything and everything they say will reflect in their yearly performance appraisal and they clamp up. In either of these situations or situations similar to these, the Anonymous Retrospective helps get the real pulse on the floor. It helps all the participants open up and talk about what they really feel deep within about the organization, the culture, the people, the leadership, the technology, the motivation factor, etc.

So what is Anonymous Retrospective? As the name suggests, all data collected is completely anonymous. The first rule of the Anonymous Retrospective is the data collected has to be truly anonymous and there should be no attempt to tie the same to any individual – either through the language used to describe it or with an handwriting match. What I normally do is I put an empty container in the middle of the room and  give each participant a bunch of Post-its. I ask them to jot down their thoughts on what is working well and the areas that need improvement. I emphasize to the participants that this is a Anonymous Retrospective and encourage them to share their thoughts without having an iota of worry. I then ask them to fold the post-its and put it in the empty container. I normally time box this to around 25 to 30 minutes.

Once everyone is done, I get the container with the post-its and give it a good mix. Then I appoint someone neutral to take notes on their laptop and help me with basic categorization. I pick each note and try to read it as verbatim as possible, except for certain cases where there are personal attacks. I read them one at a time in front of the entire room, the person taking the notes captures it, and then I tear the post-it in front of all the participants and put it in the trash can to maintain confidentiality. This is what I mean by “Anonymous”.

Anonymous Retrospective will generate plenty of data which has to be validated for its accuracy. Once all the data points are collected, work with the participants in the room to finalize the categorize the data, and generate information by connecting data in each category together.  Following this put an action plan together to address each category. Most likely you will need multiple sessions to do this… but remember you now have some solid facts with which you can incrementally introduce improvements. This is what the power of Anonymous Retrospective is!

I am happy to hear your thoughts.

Tesco’s Success Story with Agile Adoption



Over the past 2 years I have been helping Tesco’s Dotcom International Grocery Home Shopping (IGHS) group in the capacity of Agile Coach to build their eCommerce Platform. Tesco Dotcom’s challenge was to take the world’s largest grocery website international to multiple countries outside UK as quickly as possible and be the market leader. 

As the saying goes, “The proof is in the Pudding” …. By using Agile as a Software Development Methodology  with a  combination of Scrum, XP, Kanban and lean principles of choice, Tesco was able to launch their Dotcom operation to new countries regularly and is currently live in 5 countries within the span of just over 2.5 years. This group with several Agile teams distributed across 2 geographies was able to bag 4 major awards within the organization, including the “Tesco – IT project Cup” of the year.

It is my privilege and honor to be part of a journey with this passionate team that was constantly hungry to take the Agile adoption from one level to another tirelessly through continuous Inspection and Adaption and both the passion & Hunger continues….

Wrong influences on Scrum teams.

There is an inherent understanding in Agile implementation that Scrum is all about team and they have a final say on anything that impacts their productivity.  To a certain extent this is true especially if you have only handful of possibly co-located scrum teams. However, in enterprise wide software development where you have dozens of distributed scrum teams external influences will start hampering the teams final say.
One of the external influences could originate from senior management in large team environment. Most of the time, their decision is based on what they hear and see in the sprint review, the Scrum of Scrum meetings, from what others leads have to say, and there may be other factors influencing them too. So It’s quite natural for the management team to implement a particular solution based on gathered facts. Since the management team is not involved in the day to day life of a Scrum at times the analysis might not be complete and it might result in half baked solution thereby disrupting the team momentum.
An example of one situation from my experience –
A particular scrum team in multi team environment decided to work towards eliminating the accumulated technical debt with a conscious decision to abstain working on any new feature this sprint. However, certain new functionality was essential from this team to accomplish the sprint goal. The management had the option to honor teams decision and take a hit by allowing them to work on technical debt, or come up with alternative solution to meet the Sprint goal.
They choose the latter and came up with few options like –
Can half the team work on technical debt and the other half on new feature development?
Can we add additional members to the scrum team to develop new feature?
Both the approaches seems doable,  but the reality might be a little different. To list a few.
  • Are new engineers knowledgeable enough on the design and technology used in the scrum or they need to be trained? Training will take time off of the existing scrum team planned work.
  • Will the newly borrowed engineers maintain responsibility of code they wrote and delivered to production or the work will be transitioned to the existing scrum team.
  • What type of impact does it have on team dynamics – It does take few sprints (normally 4 to 5) for the team to gel together.  Adding new engineers might just disrupt the team momentum.
  • The existing team might be used to working in certain style – eg. coding, code review, TDD, Wiki, etc. It’s difficult for new engineers to follow these practices if they are not aware of it.
  • If half the team is working on technical debt and half on new development, can you eliminate the debt?
I have experienced scenarios where the scrum team size have grown from 10 to 15 engineers where management felt they were helping everyone achieve the sprint goal, but in reality they were disrupting the team dynamics. In addition to the above facts, the team would also experience increase in duration of overall meetings including planning and daily standup due to increase in size of the team. The correct decision should have been  to stop the production line until the technical debt in order before continuing with new development. It’s either pay now or pay later with compound interest.

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.

Let’s talk iteration planning meeting.

The iteration planning meetings are the most important meetings for the iteration to be successful. These are the meetings where the team plans for the work to be done in the upcoming weeks. But somehow I have not heard or read much about how these meetings should be conducted. Most of the books and websites just mention to have two 4 hour sessions for planning meetings. What really happens in these planning meeting seems to be a mystery. I have been a ScrumMaster for a while and have helped teams with planning meetings using various approaches of which some are very effective and some are not.
I wore a traditional project management hat before I was assigned the role of ScrumMaster to one of the projects. The only formal training I had then was that I had read Ken’s black book “Agile Software Development with Scrum”. As a traditional Project Manager, transitioning into the ScrumMaster role, I sat in the middle of the room projecting and taking notes during the planning meeting. I honestly felt I was helping the team by adding stories, breaking down tasks, assigning hours, etc. The team felt good that they didn’t have to worry about entering stories, tasks and hours. However, soon I realized this approach is totally ineffective. This method of planning was very time consuming. The planning meeting took more than 2 sessions of 4hours. And worse of all, not everyone in the team were talking the same language. I could see team members tuning on and off of the conversation. They were only interested in the part that they planned to execute. So I looked back and thought about what was wrong. The problem was me. I was hand holding the team so much so that I became the bottleneck. If I am unavailable the meetings did not happen, the team mates provided scrum updates to me rather than the team. The team looked towards me for guidance and direction. I was still wearing my project management hat and not being an Agile Coach.
Luckily, I was able to get into Ken Schwaber’s “Certified ScrumMaster training” course and I was able to get some advice from him on planning meetings. With the new information I gathered from Ken, I worked on being a coach. I let the team do most of the talking and only got involved when team started getting off track. So what did I do different? My laptop was used for projecting, but only to display the prioritized list of stories from the product backlog. I asked the team to huddle in front of a whiteboard and draw the design on what was implemented so far. Soon it was realized that there were some discrepancies in the way they understood how the system worked. But after some more discussion and clarification everyone in the team was on same page. As a next step, I asked the team to update the old design on the whiteboard to accommodate the new set of stories the team planned to work on. The entire team got engrossed and focused on the design discussion. The development engineers as well as QE engineers were on the same page. The design came out much better. There was a sense of achievement by everyone and most of all, the meeting was productive. Once the design was finalized, I asked team members to select their preferred stories. I helped the team by jotting down stories and assigning stories to team members. I asked the team to work offline on decomposing their assigned stories into granular tasks along with hours needed to accomplish the needed work. The next day we got together for an hour and as a team reviewed every story and task. We made adjustments by adding/deleting and updating the tasks along with hours and we were good to start our sprint. This approach was so effective compared to the earlier approach. The team was self organizing, they were empowered to make decisions and more over it was fun!
I would like to hear other experiences on planning meetings.

Scrum team organization – Feature teams or Component teams – Part 2

Component Teams (CT) are specialized teams organized around the architecture of the product under development. Examples of such teams are UI / User experience teams, Database design and modeling teams, team of Architects, Security team, etc.

A typical component based scrum team is more or less similar to a feature team i.e. each CT will have 3 to 4 developers, 2 to 3 testers, a Product Owner & Scrum Master with Documentation and Architect representation as needed.

The top node of the diagram “Theme/Epic”depicts customers value add features (Features that customer value). Think of this as some high level requirement that marketing will use in their presentation to advertise a product. This value add feature might not be small enough to finish in one sprint and gets decomposed in to multiple smaller features i.e. Feature 1, Feature 2, Feature 3, and Feature 4. What this essentially means is, once Feature 1 through 4 are done in its entierty, the top level Theme/Epic is “Done”.

The stories for component based teams are fed by these decomposed features Feature 1, Feature 2, Feature 3, and Feature 4. As the diagram shows, Feature 1 is dependent on Component Teams C1, C2 and C3. Similarly, Feature 2 is dependent on component team C1 and C2, Feature 2 is dependendent on CT C1 and C3 and so on. Component teams in general provide functionality and serve multiple Features. Component teams generally don’t generate products that get shipped to the customer. But they develop functionality that is consumed by feature teams and indirectly helps add value to the features being delivered to customers.

If organizations are structured in a way that specialized teams are spread globally then forming component based teams might make sense. Component based teams are great to keep site affinity, work across different timezones and also to keeping team culture intact. But it also comes at an expense of management overhead.

Few challenges with component teams based on my experience

  1. There is overhead of integrating component team’s delivery with the top level features. In the example above, when C1, C2 and C3 finishes the deliveries for Feature 1 they have to be integrated together in Feature 1.
  2. To ensure all scrums are aligned well to deliver end-to-end customer functionality, it will take lot of upfront planning as well as tracking during the entire sprint.
  3. In my experience, with component based teams it’s very difficult to deliver thin slice of end-to-end functionality at end of each iteration because feature team needs time to harden (stabilize code base + write integration tests) their code with component team code delivery.
  4. Since component team serves multiple features teams, negotiation needs to happen between Feature Team and Component teams to avoid starvation. For Ex. In the diagram above Component Team C1 gets requirements from Feature 1, Feature 2, and Feature 3. In the upcoming iteration let’s say C1 can only serve Feature 1. In this case Feature 2 and Feature 3 teams will have to wait until next iteration before their needed functionality is delivered and will be starved.

Thus, for component teams to succeed open communication channel should be established throughout the organization.

Please share your experiences.

Scrum team organization – Feature teams or Component teams – Part 1

There is a big ongoing debate within Agile/Scrum community on whether Scrum teams should be Feature based or Component based. I am currently experiencing this dilemma in my organization and would like to share my thoughts on this.

Feature teams are long lived, cross-functional, co-located teams with 7 to 8 members in a scrum team that completes many end-to-end customer features, one by one. These comprise of subject matter experts from various component areas e.g. UI, Middleware, Database designer, Architects, Business Analyst, Testers, Documentation etc. In short, a self sufficient team with no dependencies. By organizing teams in this fashion, feature teams can develop a thin slice (enough for one iteration) of customer valuable, end-to-end features at the end of each iteration.

The pitcure on the left is a over-simplified diagram of how a scrum based feature team will start executing priortized stories from overall product backlog. Each story, i.e. User Story f1.1, f1,2, … represents a thin vertical slice i.e. end-to-end incremental functionality delivered at end of each iteration. The picture shows that at end of iteration 2 feature f1 and f2 are complete.At end of iteration 3 feature f3 is complete and most likely this product can be shipped to customer. In most cases, your organization will have multiple feature teams and in that case, work allocation can be handled in many different ways. Ex. FT A can work on developing feature 1, FT B can work on developing feature 2 and so on. Other way would be in iteration 1, FT A works on story f1.1 and f1.2 as that’s their capacity and FT B can work on User Story F1.3 and other stories from feature 2. With this approach you can have customer shippable feature f1 at end of iteration 1.

Feature based teams can deliver thin slice of customer visible functionality one after the other at end of each iteration. This is possible because there is no dependency, delay or hand-off issues between teams.

Forming feature teams for an organization where everyone is co-located or at least in the same timezone seems practical. However for global teams, where expertise is spread throughout the globe, forming feature teams that develop thin slice of end to end functionality is a challenge. Forming a FT which spans multiple timezones violates most of scrum principles – as this team will have a difficult time self organizing for various reasons like culture, timezone differences, etc. This will have a negative impact on team’s velocity and their performance will suffer. In short, FT can’t scale in geographically dispersed large teams which is more or less a reality for all organizations.

In the next post, I will discuss component teams and present my view on how we can use hybrid approach that will allow scaling Agile software development in global teams.

1 2