I was one of the first members of an IT services company in India in the mid-nineties. We did a lot of work in software testing. Like other companies, after a few years, a senior manager/executive brought up the idea of getting a quality process certification like ISO 9000. Many engineers weren’t really sure how that would help (they also weren’t sure why they shoudn’t get the certification). Eventually the company did get the certification. At some point during the process, a smart and outspoken engineer would remark, ‘Microsoft isn’t ISO certified.’ This would result in some lengthy and confused discussions. Microsoft didn’t get certified since they were a product company and probably never felt the need to demonstrate a certification. However, I don’t think they followed any similar alternate process. Following what Microsoft did/didn’t, might have saved us a lot of time and money.
In the last few years I have seen teams struggle with agile. The main issues that cause problems are time-boxed sprints, creating user stories and the concept of ‘done’. In addition, I have seen testers struggle with testing in agile teams. Just like Microsoft and ISO certification, many large US software product companies don’t follow agile and never will. Their development process hasn’t changed much despite the widespread adoption of agile. If you are a small company or you are generally struggling with agile or you don’t have management buy-in, you can follow a similar process, instead of being forced to blindly adopt agile.
These are some practices that are important and that large companies do follow:
- Continuous integration
- Test automation and coverage (Note this doesn’t have much to do with testing).
- Strong specifications. At this point in time, it’s mainly UI specifications.
- Strong product designers. Microsoft traditionally had a program manager in a similar role.
- Very strong developers which is a result of strong recruiting.
- A/B testing, focus groups and various others ways for designers to get user feedback.
These are agile practices that silicon valley style large companies don’t follow:
- Don’t write user stories. Instead they do create detailed UI specs.
- They don’t always write unit tests
- Don’t use TDD or BDD
- There is no soul searching about ‘done’.
- No daily standup, retrospective or sprint planning.
- No scrum master or product owner.
These are some additional characteristics of such teams (these are mostly from the writing of Joel Spolsky):
- Developers provide estimates for their own work
- Managers need to pull their weight. In most cases, managers are developers/engineers.
- On the face of it, testers/SDETs are respected as much as developers. In reality, salaries and opportunity to showcase achievements may vary to the disadvantage of testers/SDETs.
- Work life balance is probably not discussed too often (In contrast, agile does have a focus on sustainable pace).
Notes
- This isn’t an anti-agile blog post. I strongly feel that scrum done right is a great approach to software development.
- Despite my support for agile, I disagree with the concept of testing which is popular in agile.
- It is important to understand the difference between software product development and enterprise software. These groups have adopted agile very differently.
- Similar to the previous point, the stakes are different for smaller products (less than $5 million annual revenue) compared to really large products and the adoption of agile will differ in smaller companies.
- The analogy to ISO certification is only partial. The concept of process based certification is problematic. In contrast, I think agile is fundamentally strong (except the ideas related to testing). In contrast to agile, in many cases services companies get ISO certification as a checkbox for bidding on projects.
- In the last few years, articles have been published claiming that companies like Microsoft and Google are agile. I will analyze that in a later post. In the meantime, feel free to let me know what you think.
