Transitioning from Waterfall to Agile - Some tips

The day comes when suddenly somebody in the organization starts talking about Agile, and decides to implement Agile . This senior person who made this decision, would have heard somebody saying

Agile improves productivity !! and saves money Or the customer would have said, if you don't practice Agile I will not give the project to you(in an outsourced scenario)

Whatever the reason be, now the development team has to start practicing Agile. Note that moving from waterfall to Agile is not only needs the change in software development process but also the entire thought process surrounding the software development. Changing the thought process is not easy, as people practicing Waterfall would have reached some kind of comfort zone and immune to the pain and suffering from the consequences of practicing waterfall. So, it would take a lot more effort for them to unlearn the old way and learn the new way of doing software development.

In order to make the transition smooth here are some tips which could act as pain killers

1. First and foremost thing is to identify a good Agile coach.

2. Get all the team members to undergo training on Agile (XP, Scrum, etc)

3. Don't force all the Agile practices at once. Take one or two practices at a time and give sufficient time for the team to learn and practice.

- For ex: One can start with shorter iterations and scrum/daily stand up meetings.

4. Don't wait for the right day to start Agile. Start today. Go run to a shop and get hold of a Good Agile book(s).

Some good books for starters include,

• Agile and Iterative development a manager's guide by Craig Larman,
• Ken Schwaber's book on "Agile project management with Scrum",
• or any Extreme Programming book.

5. Start with 4-6 weeks iteration rather than 1 week iteration. Many new comers to Agile feel suffocated with 1 week iterations. Earlier the waterfall teams would have delivered softwares once in 6 months, and suddenly asking them to deliver in a short period makes them resist to Agile.

6. Take a simple and low risk project to try Agile. Also, with the help of Agile coach ensure that this project succeeds

7. Try to make use of visible tools like Flip Charts, Burn Down charts, Post-It notes, spreadsheet and encourage more interactions among developers. Make the developers to come out of their cubicles and start designing things on boards.

8. Ensure that management provides complete support to the Agile coach.

9. Even though having indepth understanding of Agile values and principles are key to succeed in an Agile environment, the team may not be able to grasp all of them at once. As and when each practice is introduced to the team, show them the relationship to the values and principles.

10. Don't bother if you would like to start with Scrum or XP. Instead, put all the Scrum and XP practices in a big basket, take the simplest one at a time and start practicing it. Over a period of time you would understand what is best for your team.

11. Scrum and XP advocates specific team structure like having Product Owner, Team, cross functional teams, no hierarchy, a team coach, scrum master, etc. This is a very sensitive issue. Suddenly informing the team that all of you are same, might heart the ego of senior people. I have heard stories where the seniors have quit teams as they were equated to the junior members by calling all of them as team and by dismantling the hierarchies . So, don't worry about dismantling the current team structure. Let the team learn slowly the importance of the values and decide what is best for them.

12. Let the project manager's slowly transition from their current responsibilities to become scrum masters.

Agile on a fixed bid project and Dr.Agile

Here is an article by Scott Ambler who explores the ethical implications of "fixed iron triangle". The article explores why many of business users insist on defining the price, scope, and schedule early in an IT project. It then overviews the overwhelming evidence for why this is an incredibly bad decision, and then describes an ethical approach to addressing this questionable desire.
Dr.Agile, a very good Agile readiness tool. I have not tested this personally, however one of my friend who tested has given very good reviews. Dr. Agile uses over 300 different indicators to determine which agile practices an organization is ready to adopt.

How to fail with Agile 20 Tips

Most of the time we talk about how to succeed in anything and give a lot of tips and best practices to others. How many of us do really remember those tips ?

What if somebody lists all the bad things one should do to fail ? Do you read it ?

Does this interests you ?

If so, then read this new article, How to fail with Agile, 20 Tips to avoid success by Client Keith and Mike Cohn

We don't have any resources available in resource pool

I am sure you would agree that we use the above statement atleast couple of times a day, especially if you are a project manager in one of the software companies. A few years ago, while I was interacting with Craig Larman, he mentioned that "human beings" are not fungible resources, they cannot be called as "resources". That was the first time I learnt that ugly side of calling programmers/software engineers as "resources".

The word resource, in the past was widely used to mean things that are "replaceable"/fungible. For ex: A broken chair can be replaced by another new chair. Another interesting feature of a resource is, you can start using it immediately. Ex: Once you buy a new chair, you can start using it from the next minute.

I don't know from where it all started. However I have been hearing the usage of the word "resources" implying mostly "people/programmers" since several years in the software industry. When we hire a new programmer, we say that the new resource is being hired in place of the old one. We are aware that two human beings cannot be same, one "developer" cannot be replaced by another cloned "developer" with exact specifications. They are two different people coming from wide range of experiences, even though they have "similar" work experiences and designation.

So, let us consciously stop calling "human beings" as "resources".

Here are some more people who think on above lines

• Mark Gregory


• Aaron


• Bill Ryan

Is it a sin to use tools in Agile software projects ?

The first value of Agile Manifesto clearly says, "Individuals and Interactions over Process and tools". Does this mean that usage of processes and tools needs to be reduced ?

Many Agile evangelists prefer using just flipcharts to write their design diagrams rather than using rational rose/any other diagramming tools. These Agile designers are proud to say that they don't use any software tools. However Kent Beck one of the Agile signatories shares in his latest white paper on "Tools for Agility", that when he and others created the manifesto they never wanted to disregard the usage of tools. However they felt that tools are ideal "If" it helps them in certain areas of work and specifically in some of the transitioning activities. Kent is not negating the usage of tools, however the tools like flipcharts, post-its and white boards have their own limitations. They cannot be shared if used in a distributed environment, it might get lost, and things like that.

In the white paper mentioned above, Kent makes some powerful statements. Some of them are as follows

• Every quantitative change of an order of magnitude creates a qualitative change


• A transparent team can more cheaply and effectively coordinate their efforts towards shared goals


• It may be hard to unlearn habits and beliefs, but in a world of wide and
  free flowing information, keeping secrets is a position of weakness


• You never know when you are going to be found out. Transparency is the new strength

I personally beleive that tools are very much needed in any software development, however tools should consciously be choosen and introduced into the project environment. Also a constant inspection and upgradation is essential to ensure that the tools are not becoming bottlenecks and hampering productivity & creativity.

Retrospective smells

Retrospective is the heart of Scrum life cycle. Many Scrum Masters who are new in facilitating Retrospectives find it hard to handle it. Keeping the sensitive nature of this exercise and keeping the emotional aspect in mind, one needs to be really creative, courageous while managing the team doing retrospective.


More info. about the image

George Dinwiddie shares the following retrospective smells.

1. Retrospectives that limit themselves to the three questions, "What worked? What didn't work so well? What are we going to change?"
2. Retrospectives that don't ensure that all the participants are represented. It takes care to get the thoughts and feelings of the introverts.
3. Retrospectives that don't establish safety, or at least acknowledge the level of safety felt by the participants.
4. Retrospectives that are designed to lead to a particular conclusion.
5. It's not a retrospective if you've got "the answer" before you start.
6. It's not a retrospective if the answers come from the leader instead of the participants.

It is very clear that retrospective as a tool can fix things or break things if not done properly. Knowledge and experience of the scrum master plays a key role in facilitating retrospective. Here is a good web resource that has been created by Agilists to share their retrospective experience and in turn help others.

Best time to do performance testing in an Agile environment

In the traditional model of software development major release/milestone dates are fixed, and performance testing is done just before such milestones, and it occurs mostly after the completion of coding, integration and system testing for a chunk of requirements. In an Agile environment too, release and milestones dates are planned, however, between the start date and the major release date, multiple iterations keeps happening and developers keep churning the code.

So, the next logical question to ask is,

In an Agile environment, is it still advisable to do
performance/scalability kind of testing before the major release date Or is there a better way to handle this ?

My personal view is, the non-functional requirements(the -ilities, scalability, availability, performance, etc) cannot be separated from the implementation of functional requirements. It is not a good idea to say that we would implement the functional requirements first and then look at non-functional requirements. According to me, one cannot write a piece of code implementing functional requirement without affecting the non-functional requirements. Even the simplest If-Else statements, for() loops we write affect the -ilities in a big way. It is always advisable to have the non-functional requirement related SLAs in mind all the time
and, after writing each piece of code, ask yourself does this line of code
meet the SLAs ?

Moral of the story is, in an Agile environment, performance, scalability, Availability testing is done all the time right from Iteration 1.

Best Practice: It is better to write unit tests to check the conformance of your code against the SLAs, and automate them. Creation of such unit tests and, automating them is the key to success in implementing non-functional requirements in an Agile environment.