My first introduction to Agile was in 2003 when I joined Thoughtworks. The processes adopted by Thoughtworks was adopted bottom-up (if you consider management on a higher branch of a corporate tree). Developers chose to adopt a set of processes to deliver software effectively implementing the ideas Kent Beck espoused in eXtreme Programming explained. This had some important implications:
Two people to a machine. Pair programming was fairly strictly adopted. I was told that production code had to have two pairs of eyes on it. This led to some very interesting debates. Is code per developer halved because of this? which is equivalent to Is the customer paying double?
There was a heavy emphasis on automation. Unit tests, acceptance tests,
Continuous Integration and automated build deployment. For the first time in my career I sensed a strong confidence in the quality of the system being built.
The chances of a bug that missed the unit tests, manual QA tests, automated regression tests, acceptance tests became very low.
Test Driven Development was adopted. Developers would write their tests first (which is very different by the way from going back and increasing test coverage). This I was told is a way of software design – sadly I wasn’t coding at this point to corroborate the fact. So I don’t speak from direct experience.
There was a certain flatness to the structure of the team that to an extent extended to the organization. Everything was for the team; there was a “we” culture. Mistakes were openly admitted, discussed and accepted.
QA was included in the team. This might seem fairly standard when you read this now but keep in mind that I had come from a culture where Qa was a step performed late in the game by people who had signed off test plans.
The hiring process was fairly arduous which meant the people in the team were genuine, talented and hard working.
The client (Product Owner, stakeholder – call the person what you may) was heavily involved in the process. Again elementary you might call it in 2014.
Now Thoughtworks was a technologists consultancy. It was primarily an institution for excellent programmers. It attracted the best for many years – perhaps it does even now. It was so developer-centric that it took a lot for non-developers to stand up to them. I say all this in a positive way. But there are very few such organizations in the world. Without in anyway disparaging the others, typically IT departments in large organizations are less effective. They are also typically laggers in terms of adopting new technologies or processes.
Here also lies room for improvement.
Scrum is top-down. This is when managers want to make change happen. They believe in productivity increases from the adoption of iterative processes. Scrum at least in its original form doesn’t mention any of the engineering practices. What does Scrum say:
One month sprints
User stories (XP says requirements ought to be in an index card with just the title and the rest is verbal communication)
Scrum is so popular and mainstream that even PMI has adopted it and included certification for it. I do not believe there is certification for XP.
Regardless of the process you adopt the principles hardly differ. The goal remains the same. You do not have a choice but to improve constantly.
You might choose to avoid pairing all the time. But at some point you will find that pairing makes sense:
you have a complex piece of logic that needs to be solved
you need to bring a new team member up to speed
you need to share knowledge across the team
WIP, Pick up stuff from the top of the list, similar sized stories. I have found Kanban hard except on mature teams.