while people like Jeffrey Palermo are natural coach, personally I find it little difficult to work with beginner level people.
Looking back, here is quick highlight
- In first week, gave little presentation on what agile is and high level idea of how scrum works.
- Introduced unit test and integration test for the project. Started working in TDD way
- Change existing build process (Build = Compile) to include compile plus test execution (Which was later again changed to accommodate things like custom commonasseblyinfo, publishing coverage report and executable specification).
- Re-organized project structure to facilitate better support for loose coupling.
- Introduced boundary testing (or Scratch testing) to better integrate with external systems (and these systems where also under active development, using water-fall methodology, giving us hard time every time they give us new version).
- Introduced Dependency Injection technique to the team.
- Introduced pair programming (this was the hardest part, for me).
- Introduced using StructureMap for IoC.
- Introduced mocking technique to the team. Gave demo-cum-presentation on Rhino Mocks.
- Introduced MVP to work effectively in ASP.NET WebForm environment. (Second hardest part on this project, for me)
- Re-factored existing code to eliminate gigantic code behind files.
- Introduced CruiseControl.net for build monitoring as well as deploying to staging environment.
What did I got out of this
- Team realized power of TDD and could see the real value behind it as oppose to doing just test first programming.
- Pairing helped team, breaking the knowledge silo and promoted collective team ownership.
- We had better success rate with sprints as we proceed further.
What was still left out:
- Project owner team, never truly realized power of Agile/Scrum
- I always had hard time convincing them for shorter sprint as oppose to 1 Month sprint.
- Sprint velocity was never established properly.
- Effectiveness of Sprint Retrospective was very low. (it turned out to be mostly time wasting activity)
- Planning meeting were always mess. Product owner were never ready with new set of requirement which they want in next sprint.
- Story related pre-requisite work was always done during planning meeting by making calls to 5 different people and then deciding on the fly, what needs to be done for the story in hand.
- All product owner never bothered to come for planning meeting.
- During sprint, one representative from product owner team was choose to answer team's question and was rarely available.
- Cubical structure made it very difficult to communicate with team effectively and has resulted in duplication of effort.
- Testing team mind-set was fully water-fall oriented. They never bothered automatic tests and continued manual testing focusing on trivial issues which were never called out in story.
- And the list can go even further, but I think I covered top pain points.
With this kind of project, I am not sure whether I succeeded in doing my best for the team. One thing however is sure enough that while I could make positive changes and affect the overall direction for technical team, I had almost no control/influence on people who were higher in the hierarchy. (By the way, I was originally hired to help them with reliable messaging which never happen in the project).
That spawns nature question, what should I have done differently to help this project better. And more importantly how would you handle this kind of situation where you don't have direct or indirect influence on people who are driving the project. ( And I am looking for answer other than; "Hey, why don't you just update your resume and start surfing dice or monster.com)