Story Point Mapping with Hours – Key Ingredient to Burnouts?

This is based on a true story of a project I was involved in and that was also the first ever Agile projects I worked on. As I came from straight from waterfall background and didn’t have enough Agile experience, it made a lot of sense to us to map a story point with number of hours for obvious reasons. We mapped story point with ideal hours. Initially things went well. However after a few months, we started getting into difficult waters because of following problems:

We began to witness clashes among developers over estimations. As story point was mapped with number of hours, it directly mapped with the skill of a developer. For instance, a senior developer could finish a user-story in 2 hours. Another not-so-skilled developer or new-in-the-team developer could finish the same user-story in say 8 hours. That started causing planning meetings with clashes, disagreements and also spurts of indirect bullying from senior guys. As a result, not so experienced developers started spelling similar smaller estimates even though it caused them to work longer hours. As it was a distributed augmented team, we also started witnessing lack of trust within team because of those reasons.

Also customer didn’t see any significant change in team velocity even though productivity improved multi-fold. “YOU ARE NOT PRODUCTIVE GUYS…”
Read more ›

Posted in Agile, Estimation

When BDD (Behaviour Driven Development) may not work?

For quite some time there have been talks on using BDD in order to have:

  1. Better collaboration between Business Analysts (BAs), developers and testers.
  2. A common domain language for functional testing and for defining functional acceptance criteria, which everybody in the team understands.

Why BDD?

BDD offers following advantages:

  • Ability to write test cases (scenarios) and acceptance criteria before performing any development. This whole idea is termed as Acceptance Test Driven Development (ATDD).
  • Provides a common domain language, which everybody across the board (developer, tester, BA and business) understands. As at the end it’s plain English, it’s simplest to learn compared to other DSLs (domain specific languages).BDD example
    bdd-sample
  • Helps in eliminating waste by minimizing handshakes. If you take a look at the above-mentioned example, testers and BAs can write a test or acceptance scenario using a BDD template (highlighted in Yellow) with plane English

Developer/tester can then fill in the blanks, i.e. implement the test case using programming language or script.

Writing text doesn’t require any IDE like Visual Studio or Eclipse. The test/acceptance scenario can be written in a Notepad too and then pushed to Version Control System, which is then picked up by developers/testers to implement.

As BAs, developers and testers work only one single source of truth (BDD test), it minimizes the handshakes and reduces waste. Also it is well understood by everyone as test-scenario is in plain English.
Read more ›

Tagged with: , ,
Posted in Agile Testing, Testing

Story Mapping and/vs Process Maps

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.

Read more ›

Tagged with: , , , , , ,
Posted in Agile, Estimation, Scrum, User Story

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

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.

Read more ›

Tagged with: , ,
Posted in Agile, Distributed Agile, Scrum

Developer First Test Automation

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.

Tagged with: , , ,
Posted in Agile Testing

Dev Box Testing : Reduce Your Bug Life Cycle

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

  1. 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.
  2. 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).
  3. After multiple builds when developer thinks that functionality is ready for functional testing, she asks the tester to take a specific build and test.
  4. Tester starts testing. If tester finds bugs in the functionality, she informs the developer about the problem and developer again begins from step 1.
  5. 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.

Tagged with: , , ,
Posted in Agile Testing

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

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.
Read more ›

Tagged with: , , ,
Posted in Agile, Distributed Agile

Enterprise Agile – Are we trying to solve the right problem?

Implementing Agile in a big enterprise is not an easy task. The metaphor I sometimes use for big enterprise is to compare it with Elephant. It’s very easy for a small living being to move and maneuver. However when it comes to elephant, it requires time to build momentum and when it actually moves, it moves slowly. People involved in Agile transformation get frustrated because of all perceived delays. Frustration is understandable but not sure if much can be done other than understanding the simple reality that you are dealing with an elephant and not a tiger or mouse.

Now comes other bit. People are limited in their understanding of big elephant just because of their boundaries (silos) in the big environment. Agile transformation in big enterprises might get myopic as most of the people involved are not able to see problems in totality. That translates in focusing issues which require a lot of effort to solve but may not bring the business value you are looking for on board. Some important challenges to consider for Enterprise Agile transformation are as follows:

  • Ability to clearly define the problems in hand.
  • Are we focusing on the right problem?

The big picture could be something like this.

Based on the feedback of the customers or based on market trends, business comes out with an idea or a problem statement which needs to be solved. Now for many technical people, the obvious solution comes as technical solution but in reality solution can be completely non-technical (process improvement) or completely technical or mix of both. Most of the times software development is a part of bigger solution.

The business idea is explained to technology people and they start working on a software project. That’s the place where most of the Scrum, XP techniques are placed. Most of the times focus of optimization remains technology. People try to automate everything whatever is perceived as manual step.

However as you move further or before in the value chain, there are other very important steps of solution. For instance after software delivery, change management activities have very important role. For instance deployment to production, training, marketing of the new product etc.

From the inception of the business idea to its implementation and further using it, important components of the chain may not be knowing each other very well because of their implicit boundaries. People try to understand this whole bigger picture but at the end of it many times, they get something like this:

Here’s a real story of one big enterprise Agile project I worked with.

In this project Agile was instrumental in delivering the software product in a record time and with tight budget. People coming from waterfall background were very skeptical about it but at the end everybody was happy to see the project delivered within half time of what it could be delivered with waterfall methodology. People were happy and cheered. As project finished, people involved moved on and started working on other projects.

At one fine day I came to know from one of my peers that though software was delivered technically but it couldn’t go to production because training logistics will take additional 3 more months. Other than that there were other issues because of which the realistic time to put system live can be 3-5 months.

I was shocked and then wondered if optimizing technical work only should the right focus for Agile teams. Instead of looking at just one part (software delivery) of the whole solution, shouldn’t we be worried more on time to market. That actually translates to program management than just pure project management. In this case, if training could be considered earlier as part of solution (program) planning, intuitive UI could be the focus of software delivery. That could lead in the reduction of both training cost and time.

Conclusion

Optimization should be considered for whole value chain instead of just one isolated piece of the chain. Everybody in the team should get the visibility of the backlog required to implement the product in the market and not just technical tasks involved.

Posted in Agile

Custom maven plugin development – plugin execution not covered by lifecycle configuration

You are creating a custom maven plugin, everything works but when it comes to using it in a maven module inside Eclipse, m2eclipse plugin cries with message – “plugin execution not covered by lifecycle configuration”.

Now one could find a lot of documentation on how to get around with this error while using a third-party plugin, but what about if you yourself are creating a maven plugin. You would like to fix it before it comes in front of your custom-plugin users.

I was very confused with the existing documentation on how to fix it. So now as finally I fixed it, let me share it with you and come to the point.
Read more ›

Posted in Eclipse, Java, Maven, QuickTip

xml-utilities Library Available on Maven Central Repository

xml-utilities (High level XML Java Utilities APIs) library is now available at Maven Central repository.

Current stable version is 1.0.1. If you want to use these APIs in your project, use following dependency:

<dependency>
  <groupId>com.svashishtha</groupId>
  <artifactId>xml-utilities</artifactId>
  <version>1.0.1</version>
</dependency>

To know more about the library, please read the introductory blog xml-utilities : High Level XML Java Utility APIs.

Posted in github, Java, Maven, opensource
Welcome to Sampreshan
Technology Strategist, Speaker, Scrum/XP/Agile Trainer Coach and Trainer
Your interest areas
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: