• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Agile Buddha

Demystifying Agile, Getting to its Core

  • Our Blog – Agile Buddha
  • Agile Workshops and Certifications
  • Agile Commune – Join Here!
  • Webinars
  • Contact
  • About Us
  • Show Search
Hide Search

agile

Developer First Test Automation

by ShriKant Vashishtha 3 Comments

Waterfall made a clear demarcation between developers and testers. While moving from waterfall to Agile, both development and testing has to be grinded in a way that you can’t separate from testing activity from development.

People in Agile projects are moving away from “developers vs testers” (we vs they) culture and are collaborating in order to deliver the product at the end of sprint. Sprint success is major goal instead of developer or tester success.

That has been a great change in the recent years and which also means some more miles to go before reaching the state of true collaboration. Even today, quality is considered to be the major responsibility of testers which in reality shouldn’t be the case.

As developer is primarily involved in developing the functionality, (s)he needs to have tremendous commitment in building quality into source code and if bugs come, primary responsibility should be of developers. It doesn’t mean that testers don’t have any responsibility. They need to move away from their traditional role of just finding bugs and instead should be able to focus on creating infrastructure, frameworks for building quality within and also focus on exploratory testing, improving product etc.

In Automation testing, though automation test creation is the responsibility of the testers, developers lay the foundation of creating those test cases.

Sometimes this demarcation doesn’t work in a smooth way. While developing the automation tests, tester discovers many basic foundational pieces missing, which eventually hampers the tester in developing those tests.

In one of the teams I worked with, team came out with a norm which helped the testers a lot.

Developers suggested to write the first functional test of the user-story themselves, which laid the foundation and provided all required resources to build further tests. While developing those tests, developers identified many issues which otherwise would have blocked testers. As developers eventually fix these issues, it made much more sense that they themselves discover those issues.

Based on this basic foundation, testers further elaborate the test cases and create more automation tests. The norm worked pretty well for the team and also helped developers understanding the issues testers face on daily basis.

It’s step ahead towards ATDD. However this team was not using BDD or tools required for ATDD and was not planning to move towards them in near future. Developer-first norm worked quite well for them.

Agile is Genchi-Genbutsu: Go, See and Confirm

by Avienaash Shiralige 4 Comments

Genchi-Genbutsu is the Japanese expression for a practice of finding your answers right down at the source, rather than relying on second-hand reports or charts of data to achieve true understanding. This practice emphasizes going to a place(gemba) where you watch, observe and ask “WHY” five times. I shared few posts earlier on 5 Whys.

Most of the time we are hidden in our project plans and design documents to find root causes. Traditional methods assumed that having a great plan and good documentation is the secret to project success. They alienated themselves from implementation and real world.

Agile Go See and Confirm.

Agile, on the other hand, believes in delivering some thing early on to confirm our understanding. It inherits the expression Genchi-Genbutsu.

[Read more…] about Agile is Genchi-Genbutsu: Go, See and Confirm

Distributed Scrum Teams: Never End a Sprint on Friday

by Avienaash Shiralige 15 Comments

Scrum team members know that things get very busy near the end of an iteration. The coding and quality activities need to be wrapped up, demo preparation occurs, the sprint review is held, the sprint retrospective is held, and the next sprint planning meeting is held.

If the onsite team team prefers to end iterations on Friday, they might naturally assume they have all day Friday until evening for these activities.

However, look at what that would do to a remote sub-team in India – it would mean working until early hours on Saturday morning. A better practice is to split the end of sprint activities across two days, ideally during the overlap time dedicated for sub-team synchronization. This insures minimal impact to normal working hours at the end of each sprint.

[Read more…] about Distributed Scrum Teams: Never End a Sprint on Friday

Distributed Scrum: A Day In The Life Of A Distributed Team

by Avienaash Shiralige 4 Comments

In my earlier post on “How to Address People and Communication Challenges on Distributed Scrum Teams” we discussed about importance of communication in building trust. Quality and Quantity of communication needs get amplified as soon your team gets distributed.

Distributed teams I have worked with have organized their schedule and overlapping hours some thing like below.

distributed scrum team communication between offshore and onshore team

[Read more…] about Distributed Scrum: A Day In The Life Of A Distributed Team

100 Practices to Form Your Dream Scrum Team

by Avienaash Shiralige 12 Comments

Today I would like to share few practices that I have seen working wonders to teams following scrum. Not all the practices are followed by all the scrum teams. But by and large you see highly successful teams has many of them from this list.

Below is a mind map which you can download to see in it a bigger view or click zoom after you click on the image to see larger view.

I would like to hear from all of you regarding what else you would like to add to this list or modify any of them. Depending upon your feedback I will update this diagram and share updated version of this for everyone to use.

On purpose, I have not included XP practices just to keep focus only on Scrum.

What practices you would like to see or have experienced in your dream scrum team? Please write to me in the comments section.

Scrum Team Best Practices

  • « Go to Previous Page
  • Page 1
  • Page 2
  • Page 3
  • Page 4
  • Page 5
  • Go to Next Page »

Primary Sidebar

LikeBox

Tags

5 Whys Acceptance Criteria Adoption agile Agile Culture Agile Estimation Agile Offshore Agile Teams agile testing Agile Thinking Agile Transformation Agility Appraisals ATDD Automation Backlog Grooming BDD Big Picture business analyst Capacity Planning case-study code quality Collaboration Daily Scrum DevOps distributed agile Distributed Scrum Estimation Good Practices kanban kanban-mythbusters lean Metrics Planning Poker Prioritisation product owner Scrum ScrumMaster Sprint Sprint Demo Sprint Retrospective Story Point Story Points Sustainable Pace User Story

Categories

  • Agile
  • Agile Leadership
  • Agile Testing
  • Agile Transformation
  • ATDD
  • BDD
  • Continuous Inspection
  • Culture
  • DevOps
  • Distributed Agile
  • Estimation
  • In Conversation with Tim Ottinger
  • Java
  • Jira
  • Kanban
  • Lean
  • noprojects
  • Patterns
  • Presentation
  • Product Owner
  • Scaled Agile
  • Scrum
  • Software Metrics
  • Testing
  • Testing Practices
  • User Story

Copyright © 2025 · Malonus Consulting LLP

  • Email
  • LinkedIn
  • Twitter
  • Facebook
  • Privacy Policy