How to adapt agile to different companies? An MBA thesis [closed]

Question

My master's thesis is to look at how to apply agile.

There is an awful lot of corporate selling of agile - lots of management consultants selling their brand as 'best'.

I'm not interested whether XP, Scrum, Crystal Clear, Agile-CMMI, Six Sigma or any other brand/variant is best. I'm interested in what real, active developers (i.e. you guys) actually apply as agile.

What I've investigated is how to tailor agile to different organisational requirements.

From research into how different organisations apply agile I've developed the following guidelines - a recipe for what agile variations should be applied in what situations:

• Larger and more distributed or more flexible teams need stricter coding and testing standards, small teams can (and should) use less.
• Process documentation should be minimal, real-time and current.
• Detailed statistical control indicators are an unnecessary overhead: early release of incomplete software is a better indication of progress.
• Ideally developers should be close to the customer with no specialised intermediate roles. Additional roles should only be used if customers are specialised in a way that stops developers from also being users.
• Iterations should be flexible unless it benefits coordination of releases with other departments or other processes.
• Developers should be able to easily and regularly communicate but meetings should be infrequent (monthly and weekly, rather than daily).
• Pair programming should only be used for training and investigational tasks.
• These guidelines are a starting point only: continuous improvement should be used to further tailor the agile variant to the exact circumstances.

These factors change when applied in an organisation with existing traditional (i.e. BDUF or waterfall) models, where agile teams must either coexist with or be adapted from teams using non-agile methods:

• Process documentation with sign off and structured steps will help other teams track the project.
• Statistical indicators (like velocity) can help reassure non-agile teams that the process is under control.
• Fixed iterations will help co-ordination across teams.

These additional guidelines will help agile co-exist with traditional models, but they provide additional overhead and restrictions.

What I want to know is what you - the people who write software, not agile consultants - think of this framework.

What do you think is accurate? What do you think is wrong? What would you change? What have I missed?

Most importantly: why?

---

I've added a bounty to this to offer an extra incentive to answer what is a rather long question. The bounty will go to whoever gets the most votes from the SO community - I realise that there's no single right answer, but I'm interested in what's closest to the community's consensus.

Answer 1

• Larger and more distributed or more flexible teams need stricter coding and testing standards, small teams can (and should) use less.
• Process documentation should be minimal, real-time and current.
• Detailed statistical control indicators are an unnecessary overhead: early release of incomplete software is a better indication of progress.
• Ideally developers should be close to the customer with no specialised intermediate roles. Additional roles should only be used if customers are specialised in a way that stops developers from also being users.
• Iterations should be flexible unless it benefits coordination of releases with other departments or other processes.
• Developers should be able to easily and regularly communicate but meetings should be infrequent (monthly and weekly, rather than daily).
• Pair programming should only be used for training and investigational tasks.
• These guidelines are a starting point only: continuous improvement should be used to further tailor the agile variant to the exact circumstances.

Coding / Testing standards IMO need to be implemented regardless of the size and distribution of the team. Having coding / testing standards leads to more managable / stable code.

I agree with documentation. By using some Clean Code practices such as meaningfull comments and intent revealing naming conventions in your code then you remove some of the need for documentation of the code itself. Documentation should be at the business level and I prefer it to be in the form of Acceptance Tests.

While having developers close to the customer improves with the iteration process, you need to protect the developer from the business circomventing the process by coming directly to the developer for additions/changes/scope creep. The Business still needs to follow the process through backlog grooming/prioritization etc.

By using release iterations along with development iterations you can maintain a flexible schedule of your iterations that works for the team. Currently we work on 1 week sprint iterations with a release sprint every 3 to 4 weeks.

The type of the meeting should dictate the frequency of the meeting. Daily standups need to be daily. They provide accountablity and transparency to the team which is vital in having a successful team. Retrospectives need to happen at the end of each iteration and that frequency is dictated by the size of your iteration. Other meetings such as code reviews, demo's should never be dictated on time but rather on need and completion.

Pair programming should never be nailed down to specific types. We do pair programming with our QA Testers, our BA team so that both sides have a better understanding of the UAT's and Stories. We also do pair programming for knowledge share, prototyping, investigational tasks etc. In our environment pair programming has become second nature.

Continuous improvement in Agile will become second hand nature as you learn to modify the practices of Agile to your business needs. So long as you don't stray from the Manifesto your Agile should be successful.

Answer 2

The last two points I have a small problem with. Daily stand up meetings are very beneficial. It lets us go over what we worked on the previous day, and what we intend to work on until the next meeting (tomorrow). It is important to note that daily standup meetings should be kept short and to the point. We got into a situation where some people enjoyed bringing up all sorts of questions about the project, so we decided that no questions can be asked, only productivity statements. If there are questions, a further meeting is scheduled with the person in charge of that component.

Also, pair programming should not be used JUST for training and investigational tasks. Pair programming has many benefits, such as knowledge sharing/transfer and code ownership. Two minds on one problem can bring out many interesting points of views and can help isolate potential design flaws. In my opinion, pair programming is underrated and most selfish programmers do not like pair programming. It is a benefit to the project and the team, not to one's self. Good software is written by collaborative teams, not one nerd.

Answer 3

As part of your PhD thesis, you should also consider how Agile is used across teams that are placed in different parts on the globe. So, if you have a product team on the east coast, development teams in India and Russia, QA team in Singapore and so on and so forth. This to me is a whole different ball game and needs completely different patterns.

For example, some of the patterns are:

1. Based on the time zone, pair the early risers in one part of the world with late nighters of the other part or vice-versa. This is not exactly pair programming but you can call this whatever pattern you want.

2. Emphasis must be to make the code as readable as possible as opposed to writable. What this means is we may have to put emphasis on uniform design patterns and fluent like naming.

3. Create teams in such a way that you have one of them and one of us. Which means you pair the Russsian developer with the Indian developer and they work together on a module.

Inventing your own patterns over time that make agile work is really fun and takes a lot of patience and hardwork.

Hope this new angle helps you in some way.