Starting with Startup - Agile Acceptance Challenges

When starting with the agile development (Scrum as base in our case) there are always some challenges that you will meet at the beginning and during the road.

I will try to explain structure of the team and acceptance of different agile parts.

Team

We have started with team of 6 (including me). Two of us already had experience with Scrum, one of us had experience with classical water-fall models and three had no experience with project management models. Few months later the team was extended with the tester.

The structure of the team was (is) following:

3 senior developers - 2 with agile experience and 1 with water-fall experience

1 intermediate developer - experience only with ad-hoc project management model

1 junior developer - no experience with any project management model

1 designer - no experience with any real project management model

1 tester (few months later) - experience with water-fall models

So let see how this team went through agile adoption.

For each part I will split acceptance into three parts:

- with agile experience - acceptance of the team members who had agile experience

- no experience -acceptance of the team members that had no experience with project management methodologies

- water-fall experience - acceptance of the team members that had experience with water-fall project management models.

Writing requirements (user stories)

With agile experience

Team members that already had agile experience had no issues in writing user stories.

No experience

Team members without experience with project management methodologies accepted user stories as the form of writing requirements. At the beginning there were some issues to write user story of the right size (sometimes they were too small or too big) but they got the right form very quickly.

Water-fall experience

In the case of developer user stories have never been really accepted. My feeling was that there was no even wish to understand what is advantage of user stories. User stories were constantly too big (e.g. As admin I can do anything). Actually this colleague have never accommodated to agile development and left the company later.

In the case of tester acceptance of user stories came much faster. For him it is much easier to understand what to expect when user story is implemented. It is obvious that tester prefers user stories than complex use cases or other functional specification.

Estimation

With agile experience

Surprisingly here we needed some time to accommodate. The reason was that I have decided to use story points as estimation method. But the team member with agile experience was used to ideal person days estimation. It was confusing for him for some time. But at the end estimation model with user stories was fully accepted

No experience and water-fall experience

After some turbulences at the beginning estimation model was accepted. The most issues were regarding over-estimation and under-estimation. But with help estimation became better and now is constant.

Meaning of DONE

Meaning of DONE in agile is very interesting. You should finish user story in the way that in the future you should not come back to that user story. User story should be ready for production.

With agile experience

Anybody with agile experience should not have problems to get meaning of DONE. At least that was the case with us.

No experience

At the beginning it was not so clear what DONE means. There were questions like: Is it already DONE? Can I improve this? I have such good idea, can I add it?

All the time I have insisted only on implementing user story and focusing on tasks. Very soon they realized what done means and actually realized why DONE is very helpful.

Water-fall experience

Here situation was much more interesting.

Developer with water-fall model experience had constant problems to get work DONE. There were always small tasks that can be easily finished later. There were always some missing features because they were not specified enough in the user story description. The "wrong" influence of the water-fall could be felt most of the time.

But tester was much happier. He read user story and had understanding what to expect from it. This way he can test and easily see if it is DONE. There are no answers like: I will do it later. It quite simple - if you sent user story for testing everything must work.

Testing

Under "testing" I mean writing unit and integration (as we use Grails) tests. Here situation differs from team member to team member. Some of them understand and know how to write good tests and some of the are still fighting to get the tests right. The most common issues are like:

- writing test that tests too much functionality and spread through number of classes or services.

- writing test that tests method not functionality

Conclusion

My feeling is that team accepted agile development very good. For team members without project methodology experience agile acceptance was easy and what is the most important natural. They have feeling that it is the right way to do the work. The most problems had a developer with water-fall experience. But the proof that having water-fall experience does not mean it is impossible to accommodate to agile is new team member that also came with water-fall experience but is accepting agile approach very good.

What is your experience in accepting agile?