Agile Training|Scrum|Distributed Scrum|Offshore Agile|Agile Estimation|

Metrics to Build Great Agile Teams: Measure Influence, Not Control

by Avienaash Shiralige

Couple of weeks back, I noticed an incident that triggered this post. Senior Management in a company applauded people for showing individual heroics on the project.

Some of them were:

Staying late in office to address a client request?
Responding to project emails at late night..
Rewarding testers on number of bugs found and more.

And then, managers shared this privately with rest of the organisation too. Treating this as accepted, rewarding behaviour invited more such incidents and frustrated many of those who don’t do this. Below comic strip summarises it well.

“You Will Get What You Measure(or Reward)!”

I recently heard an another incident of how testing team kept an very important bug under the carpet before bringing it up just a week before release, and then getting rewards for the same. Such behaviours more likely are the candidates for root cause analysis than rewards.

Hurry and Read the rest of this post!

{ 14 comments }

Story Points and Man Hours – When To Use Them and Why?

by Avienaash Shiralige

The debate about why story points why not time goes on wherever I go for conducting coaching workshops. Hence I thought of sharing few more thoughts today.

Previously we had sizing techniques like Function Point Analysis, but it was tough to understand/implement by everyone and hence was restricted to experts ONLY. But estimation is an activity to be done by people who are going to work on it. Hence a simpler sizing technique was needed so that everyone(developers, testers) can understand and use it easily.

Story points is a very powerful sizing technique. It has various advantages as I mentioned in my earlier articles.

Story points estimation using planning poker which is based on Wideband Delphi method helps to arrive at consensus based estimates using collective intelligence – Wisdom of the Crowds.

Hurry and Read the rest of this post!

{ 4 comments }

Story Mapping and/vs Process Maps

by Shrikant Vashishtha

One of the key philosophies of Agile software development is to have information radiators visible on the wall so that the progress of the team as well as what team currently is working on gets clearly visible to anybody who visits to the team area. That includes stakeholders, project managers, team or anybody from the organisation.

However, haven’t you observed that many times, as you look at the card-wall (Scrum Board), things are not very clear to you. Card wall may look like the mesh of user-stories with statuses in To Do, In Progress or Done. However some of the bigger questions are not clearly answered by just looking at user-stories.

Hurry and Read the rest of this post!

{ 9 comments }

Agile Offshore: Why Distributed Demo / Showcase is so Important?

by Shrikant Vashishtha

Demo is an integral and important part of Scrum ceremonies. Important because that’s the whole point of being Agile. You get early feedback from Product Owner and stakeholders and fine-tune the product if required. Also this is sometimes the only occasion for offshore team when sponsors and business actually get to see the real contribution of offshore team. There are valid reasons also when someone from onsite team gives the demo. They include:

Language problem. I worked with a French team in which stakeholders and business were more at ease to talk in French.
Completely opposite time-zones which may not allow a lot of collaboration.

The advantages of distributed demo far outweighs the ones of onsite demo.

Hurry and Read the rest of this post!

{ 1 comment }

Developer First Test Automation

by Shrikant Vashishtha

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.

{ 3 comments }

Agile is Genchi-Genbutsu: Go, See and Confirm

by Avienaash Shiralige

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, on the other hand, believes in delivering some thing early on to confirm our understanding. It inherits the expression Genchi-Genbutsu.

Hurry and Read the rest of this post!

{ 4 comments }

Dev Box Testing : Reduce Your Bug Life Cycle

by Shrikant Vashishtha

The idea of dev-box testing is simple but very effective. Let’s take an example of a development cycle:

Developer implements the functionality along with unit and integration tests and when she’s satisfied she commits the source code in the source code repository like svn or git.
Continuous Integration (CI) gets triggered by source code commit and CI tool like Jenkins performs the automated build which results in code compilation and execution of the test cases (unit, integration and automated functional tests).
After multiple builds when developer thinks that functionality is ready for functional testing, she asks the tester to take a specific build and test.
Tester starts testing. If tester finds bugs in the functionality, she informs the developer about the problem and developer again begins from step 1.
If everything is good, tester moves the user-story into DONE state.

Working through step 1-3 takes a lot of time and if testers has to move the story again in development, it results in a lot of time-waste and frustration.

How about this?

As developer sees everything working on his machine, he asks tester to test the functionality on his machine. While testing on dev-machine if everything works, only then developer commits the code which eventually triggers the build and auto-deployment. On the committed code available in testing environment tester performs further exploratory tests. Otherwise developer continue to fix the issues on his machine. This way, a lot of valuable time is saved.

{ 7 comments }

Agile Offshore : Business Analyst – Complementing the Role of Product Owner

by Shrikant Vashishtha

Let’s take a scenario.

You have a product owner at distributed location but somehow he is not able to provide sufficient time to distributed team. Because of that team doesn’t get enough understanding of user-story.

Does it sound familiar?

Mostly it’s about PO getting involved in too many other things. That results in not having user-stories READY, analysed or communicated properly.

That brings another question related to suitability of people assigned for PO role. Not everybody is good in analysing and writing good user-stories.
Hurry and Read the rest of this post!

{ 1 comment }

Agile Offshore: Create Effective and Decisive Product Owner Proxy to Offshore Team

by Avienaash Shiralige

Off-shoring in current market is a global economic and strategic need. Building Agile Offshore teams across boundaries and time zones is a different ball game. It has its fair share of challenges to work with. I shared few of those challenges and a possible approach to take in my earlier articles.

1. How to Address People and Communication Challenges
2.Distributed Agile:10 Best Practices of Successful Teams
3. Distributed Scrum: A Day In The Life Of A Distributed Team

You need to make few changes along your way to your normal routine to make it work. One challenge I often see is integration of offshore team with onshore team and to project/business vision.

Hurry and Read the rest of this post!

{ 6 comments }

Agile Principle: Simplicity – The Art of Maximising the Work Not Done

by Avienaash Shiralige

Simplicity at work – I h’ve always wondered what does this mean to me, to my team and to my organization. In my quest to know more, I asked this to many Agile Coaches and enthusiasts on various groups.

In this post, I like to share what I understood and gathered from my interaction with these people: Steve Ash, Charles Bradley, Lynn Shrewsbury, Ruud Rietveld, Philip Ledgerwood, John Hebley, Jeff McKenna, George Dinwiddie, Adam Sroka, Michael James, Matt Anderson and Cass Dalton.

Simplicity is the ultimate sophistication. ~ Leonardo da Vinci

Decluttering is a consequence of Simplicity. Simplicity leads to:

Decluttering of products.
Decluttering of your mind. Not being manipulative – being honest, open and trustworthy.
Decluttering your workspace, working in open spaces.

Scrum philosophy of working in small teams, small sprints, small stories imbibe simplicity thinking – Thoughtful reduction.

The desirability of simplicity is sometimes expressed as the KISS Principle.

Do today only what you absolutely need to do today. No ‘future-proofing’. No ‘gold-plating’.
Achieve Just Barely Good Enough (JBGE). JBGE is actually the most effective possible.

Thanks to Scott Ambler for sharing this term JBGE. You could read more about this in my earlier post Agility is About Identifying and Achieving “Good Enough”

There is a point in time when any additional effort put into work product will increase its cost without increasing its value. If not zero, the increase in value may be insignificant compared with the increase in cost. This is the point to stop! (Achieving JBGE).

Hurry and Read the rest of this post!

{ 9 comments }

Distributed Scrum Teams: Never End a Sprint on Friday

by Avienaash Shiralige October 21, 2012

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

15 comments Hurry up and read the full article →

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

by Avienaash Shiralige October 14, 2012

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

0 comments Hurry up and read the full article →

Distributed Agile: How to Address People and Communication Challenges

by Avienaash Shiralige September 26, 2012

The main challenges of Distributed Agile revolve around People, Information sharing / Communication, and Project Structure. Let’s talk about first 2 challenges and how to address them. I wrote an article couple of weeks before on “10 Best Practices of Distributed Agile“. You will find few more practices in that article to address below concerns. [...]

10 comments Hurry up and read the full article →

5 WHYs: Positive Root Cause Analysis To Find Good Practices

by Avienaash Shiralige September 11, 2012

In my earlier article I shared my opinion about using 5 WHYs to find root causes. What I really missed to point was, it is not just applied to find root cause to problems, but it can be used to find root cause to good things that are happening on the team. In sprint retrospectives [...]

3 comments Hurry up and read the full article →

Distributed Agile:10 Best Practices of Successful Teams

by Avienaash Shiralige August 29, 2012

Distributed agile teams can exist in different forms like. Product Owner is onshore, Team is offshore Team split between two or more locations A complex model like product owner not with onshore team and development team distributed across time zones I would like to share top 10 best practices that are implemented by successful distributed [...]

5 comments Hurry up and read the full article →

← Previous Entries