Updates on Scrum Developer Training

10 Oct 2013

Tesco.com uses agile development offshore to roll out internationally

This article ties to the ongoing work I have been doing with the International Teams in TESCO as an Agile Coach in Bangalore since January 2011.

https://www.computerweekly.com/news/2240206944/Tescocom-uses-agile-development-offshore-to-roll-out-internationally

Overall, Computer Weekly covered the article well just with a minor correction: “Deliver the Beer” was a first internal release to validate Agile Software Development was the correct approach. Czech Republic had a first fully functional grocery website.

28 Dec 2012

Agile Coaching: Are your retrospectives effective?

Are you in a situation where your team(s) has been practicing Agile for a while and teams are following ceremonies meticulously, but still there are no significant improvements sprint over sprint or release after release? If yes, I have some antidotes that I will share through series of blogs that you can experiment with.

One of the Agile principle is, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. This in a nutshell is Continuous Improvement (CI) and one of the ceremonies that assists you in implementing CI is Retrospectives.

Start with Retrospectives: Ask these questions.

Are the retrospectives effective?
Are the team members open & honest?
Is there a good flow and exchange of information that is fact based that the team can relate to?
Is enough flavor added to each retrospective to ensure that they don’t become monotonous?
Is the facilitator neutral?
Did the team put the action plan for the improvement areas after root causing the problems?
Is the team taking at least one improvement idea that they are in total control of instead of relying on parties outside their team?
Is someone within the team held accountable to ensure the improvements are put in action?
Did the team reflect back on the improvements implemented in the retrospective that follows?

My observation as a Agile Coach has been that teams are generally very enthusiastic to begin new work as soon as current work is completed and they cut corners or miss on Retrospective entirely thereby missing on a important Agile Principle – “Inspect and Adapt”

27 Dec 2012

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

03 Oct 2010

Diminishing ROI with NO Automation in Agile development

My interaction with various clients that are in process of transitioning to Agile often ask this question – Is it ok to skip automated Unit and Acceptance testing and only perform manual testing? The reservation normally arises due to old school of thought where manual testing was tolerated and where CLIs and API needed for testing are normally an after thought. Sometimes it is also because QA engineers are manual testers and have no needed programming skills. And at times people tell me Automation takes time off from active feature development and is an overhead.

No matter what is the reasoning, I always preach to these teams, “Automation is a rule and not an exception” and I try to justify my statement using the example below.

The diagram below, “Agile with No Automation” helps illustrate the impact of skipping automation totally, causing diminishing ROI. The goal of each sprint should be a running software that is fully tested, integrated and potentially ready to ship. To meet this goal all features have to be regression tested at end of each sprint.

For the purpose of this example let’s assume Scrum team is able to do the same amount of work each Sprint and each feature is of same size.

In Sprint 1, the scrum team completed 3 new features without any automated tests. All testing is done manually to meet the sprint goal.
In Sprint 2, the team is only able to complete 2 features as the time needed to develop the third feature has to be used to perform manual regression testing of 3 features developed in Sprint 1.
In Sprint 3, the team will be able to complete only one new feature as the time available for remaining features will be used for manual regression testing of 3 features from Sprint 1 and 2 features of Sprint 2 in addition to performing manual testing the new feature delivered in the current sprint, i.e. sprint 3.

As you see in the above example, every new sprint team is spinning wasted cycles doing manual regression testing the old features which could have been totally eliminated if all tests are automated.

Now, let’s consider this scenario where all tests Unit and Acceptance tests are automated each sprint with illustration in the diagram below, “Agile with Automation”.

In sprint 1, the scrum team completed 3 features and all test are automated. When the team says done, they are indeed done – everything coded, tested, integrated and working software.
In the following sprint, i.e. sprint 2, the scrum team will be able to complete additional 3 new features as regression testing is automated. Remember, it is machine time as opposed to laborious human time spent running manual regression tests.
In sprint 3, the team develops 3 additional new features without worrying about regression testing the old features.

Automation gives developers and quality assurance engineers enough confidence to make the necessary changes in the code base thereby generating a potentially shippable product every sprint.

The above example shows that ROI without automation is 6 features and in the same time frame the ROI is 9 features with automation.

Remember, to reap benefits of Agile Software development, “Automation is the rule and not an exception”.

31 Aug 2010 - 9

Template of task breakdown for a user story

In a few Agile/Scrum training and coaching engagements that I have been involved with, I shared the template of ‘task breakdown for a user story‘ and found that teams find it very useful. This task list also defines ‘done’ criteria for the story. I am sharing the same template with everyone in this forum for your reference.

As a rule of thumb, I recommend scrum teams to define a user story that can be completed in 5 Scrum working days by one or more members. Also, as a rule, the task should be granular enough to be completed in 5 hours max (1 Scrum day). Defining granular tasks enforces discipline among team members to develop and deliver small chunks of functionality everyday to mainline source repository instead of delivering a large chunk of code together which is more error prone.

Here is a list of task breakdown for a user story. Please note, this is a reference list and all tasks listed below might not be applicable to each story.

Design for the story – This task is specifically for white boarding or group discussion on how story will be implemented.
Implementation of the story – This task could include defining the interface and methods needed to fulfill the story. There can be multiple tasks for this type.
Write unit tests (TDD) – I encourage and enforce teams to write code using Test Driven Development (TDD). For any coding story this task is mandatory.
Write Acceptance tests – This task is used to write the automated acceptance tests that will help with the story acceptance.
Non functional requirements (NFR’s) – For each story, quality attributes like security, performance, usability, testability, maintainability, extensibility and scalability must be considered.
Code Review – As a rule, every piece of code delivered to mainline repository should be peer reviewed.
Code Re-factor – Beautifying the code by restructuring. This task should be included for each story to avoid a complex mesh of code later.
Mock interfaces – At times, development can take a while to produce real implementations of the interface. In such cases, mock interfaces must be provided to help QA engineers with a head start.
Exploratory testing -Perform Ad-hoc testing for the story. This could include performance testing, scalability testing, etc.
Bug fixes – Depending on the story, appropriate time should be devoted for bug fixes
Bug verification – Depending on the story, appropriate time should be devoted for bug verification
Demo – Internal demo of the story within the team. I like to add this task as it helps Scrum team members to be on the same page. After the daily standup, if a story is complete members can take few minutes and educate others on the implementation of the story.
Update Wiki or document repository with the design and findings of the story
End user documentation – This is for updating the reference guide, Install document, etc, if applicable.

There could be other tasks for building on the CI server, Integration testing, etc that might have to be included based on your environment. If you can think of any additional tasks that I am missing from the above list please share the same so I can update the above template.

29 Jul 2009 - 3

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

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

Blog