The Agile Ball Point Game

 

This video demonstrates the Ball point game, a game to feel what it is to work in an Agile team. I facilitated this at PMI West Bengal chapter annual conference Aviskar.

Agile talk at PMI Mumbai Conclave 2011

At PMI Mumbai Conclave 2011, I gave a talk on “Mitigating Risks with Agile Project Management”. I am embedding videos for everyone’s reference.

My talk @ SPIN Meet on Structured Agile Project Management Processes

CSI SPIN – Mumbai
(Software Process Improvement Network)
When: Friday, May 6th 2011 
6:00pm to 8:30pm
Venue:
CSI  Mumbai Chapter
E- 217, 2nd Floor. Floral Deck Plaza, Near Seepz, MIDC, Andheri (E)  Mumbai 400093
Ph: +91 22 28235476 / 28235548
We request you to please register at info@csimumbai.orgcsimumbai@vsnl.com with cc to the underlined. 
For further details contact:

Mr. R C Goyal, Member IEEE Bombay Section
Member SPIN Coreteam CSI Mumbai Chapter, rcgoyal@gmail.comrcgoyal@avrms.com

Mob: 00919869463964; 00919820068417

Delivering features based on Business Value

Agile software development emphasizes on delivering functionality on highest business value. What this means is, to prioritize the product backlog based on features that are most valuable to the end customers.

I often give this example to new teams transitioning to Agile development. Taking “Microsoft Word” as an example, I ask the team if I consolidate overall functionality in Microsoft Word to 100 features what percentage of features do you think you use on daily basis? The poll within the team normally reveals 25 to 30 features. So, for all intense and purposes Microsoft could have released “Microsoft Word” to production with 30% of the functionality and satisfied the mass customers – thus delivering features based business value.

If Microsoft used the traditional waterfall (which they mostly did) or Spiral approach of generating all requirements upfront, designing, coding, testing, etc they would spent years working on the project before making the first release. In the Agile approach, keep delivering features in a time-boxed interval that the customers value most and once product is deemed feature-rich, release the same for general consumption.

There are several advantages of delivering features based on business value.

  1. To meet one of the 12 Agile principles from the Agile Manifesto, “Simplify: maximizing the amount of work NOT done”.
  2. To work only on features that adds most business value to the customers.
  3. To collect quick feedback from the customers to ensure functionality delivered to the customers meets their requirements to satisfaction.
  4. To release product with fewer or no defects to the customer as only minimum features with highest business value to the customer is coded and shipped to the customer.
  5. To beat the competition by getting to market first.

To summarize, product owner should prioritize the product backlog with features based on business value, and teams should only work on features that add value to the customers.

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

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.

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.

Test Driven Development (TDD) vs Non TDD approach

Recently I had a chat with one of my former colleagues on Test Driven Development (TDD), when he mentioned that writing test code prior to writing production code (TDD) vs writing test code after the code is written should fetch the same results. I disagreed with his statement and to prove my point I gave him following example which seemed to make sense to him and I thought might be worth sharing here.
TDD enforces developers to write just enough production code to meet customer requirement and code that adds value to business. TDD refrains developers from temptation of writing too little or too much of production code thus ensuring the release of quality software.
TDD works on the principle where you write the test code first and all tests should fail by default as there is no corresponding production code. The developer then starts writing production code against the test code to make each test successful incrementally.
Consider the following simple example: Customer want to add 2 numbers and return the result of the addition.
In the traditional approach, the developer might come up with code that take 2 numbers as input, add them and return the result. The developer would then write test code against the written production code. There’s nothing wrong with this approach, but the code is not full proof. Developer might have ventured and added additional frills to the production code that might not be needed. The developer might have also missed certain requirements in this approach that would result in error prone release of production code. The thought process here is write production code first and then test.
So how does TDD help?
Just like how Acceptance tests help validating the customer requirement, TDD helps set acceptance test criteria for the method being developed. In our example it’s the add method. What could potentially be the acceptance criteria for add method?
  • Can the method add 2 integers?
  • Can the method add 2 floats?
  • Can the method add 2 negative numbers?
  • Can the method handle 2 large numbers?
  • Can the method return error if only one number is passed to the method?
  • And more…
TDD helps developer write code that is test focused where testing happens at a very granular level to meet the correct functionality. Once the functionality is coded to the requirements any attempt to hack the code would result in test failures as test code will catch such anomaly. The thought process here is write tests to accept the requirement and then code.

Aligning Scrum Teams – Part 3: – Pulling it all together

In the last 2 blogs I discussed the challenges with component based distributed teams and how to overcome those challenges with solid pre-planning. This is the final of the 3 part blogs where I want to discuss how to pull everything together.

Once a solid pre-plan is done, it’s time to zero in on the iteration goal a.k.a. the ‘Macro’ goal (A common goal shared for the iteration by each scrum team) and execute to it.

Each Team should have a detailed planning meeting. I had covered the planning in one of my earlier blogs.

In addition to what I mentioned in the blog for multiple component teams, I would advocate the following suggestions be implemented during the detailed planning.

  • The goal of detailed planning meeting is to ensure everyone within the team understands the Macro Goal shared by each team.
  • Everyone in the team should clearly understand the stories for the Sprint and how they directly or indirectly help towards the Macro goal.
  • Have white board sessions for detailed design, identify granular tasks, and assign names and hours to the assigned tasks as per the team’s capacity.
  • One important aspect is to identify a plan to resolve dependencies between various teams. For instance, you might have a producer team that serves multiple consuming teams. It is very important to lay out exactly what will be delivered and when it would be delivered, so that consuming parties can plan their iteration properly.
    • Let’s take an example, Team ‘Infra’ is an infrastructure team and is planning to deliver stories S1 for Team ‘UI’, S2 for Team ‘Security’, S3 for Team ‘App’ in the given iteration. Team ‘Infra’, based on their resources, can work on S1, S2 and S3 in parallel or in serial fashion. Whatever approach Team ‘Infra’ takes, it’s their responsibility to inform the consuming teams on when they can expect the deliveries. This will help the other teams to put an accurate integration plan in place.

After each team is done with the detailed planning meeting, they should share the planning notes with the other teams. The notes should clearly identify risks and issues in achieving the ‘Macro’ goal. However, the notes itself are not enough in a large program with multiple scrum teams. There has to be an overseeing body a.k.a the “Scrum of Scrums” (SoS), where representatives from each team (Tech lead, Scrum Master) attend the meeting on a regular basis to provide their teams updates.

The goal of SoS is to understand what each team have achieved so far, what they are working on next, any issues/risks they might have, resolving dependencies, any new items identified after the planning meeting that might impact the Macro goal, etc. The frequency of how often the SoS should happen can be ironed out between teams, but I would recommend that teams meet at least 2 times a week.

The key for success in multiple geographically dispersed component teams is to have “Transparency” within and across teams and to create an environment of “Open Communication” for teams to self organize and start delivering Macro goal iteration after iteration.

    1 2 3 4 5 6
    ×
    ×