How we do things – Preamble and Contents
This content comes solely from my experience, study, and a lot of trial and error (mostly error). I make no claims stating that which works for me will work for you. As with all things, your mileage may vary, and you will need to apply all knowledge through the filter of your context in order to strain out the good parts for you. Also, feel free to call BS on anything I say. I write this as much for me to learn as for you.
So a bit ago I asked you, after getting a lot of questions at talks I give, if you thought there would be value in me laying out how our team gets things done.
After hearing a lot of positive feedback on the idea, it’s time to start getting the content out there.
I intend to “open the kimono” on how my team operates, from planning to production, and talk about how we got to where we are, lessons we’ve learned, mistakes we’ve made, and improvements we are pursuing.
I hope this series will provide two outcomes. The first is to illustrate ways to improve a team over time, and the second, and maybe more important, is to spawn conversations where you guys will us to improve even more.
I’ll be attaching the disclaimer above to every post. I want to make perfectly clear that this is all anecdotal, and is illustrative, not prescriptive. It is not my way or the highway, and at no point will my intent to be to tell anyone to do things exactly as I have done, so please don’t act like that’s the case.
I would absolutely love constructive debate on any of the items, because it will only help me solidify and hopefully improve the way I do things. I would love to hear how you guys do things too, because I think the cumulative content will be very helpful to the community.
I’d also like to take this opportunity to call on my fellow bloggers (both at Los Techies and elsewhere) to share what they can in the same vein. It’s great to spout off on this ideal or that, but I think we lack a lot of good information out there about what we are doing in the real world. Maybe I’m just being idealistic, but I think this sort of thing can add a lot of context to discussions about how to craft software.
I’m going to be calling on a couple of my teammates to do some guest posting here, and I can’t promise a new post every day, but I will complete the series.
Topics to be covered: (will serve as a table of contents)
- Introduction to our team, and where we came from.
- Evolving our Planning Practice
- How We Do Planning Today
- Evolving TDD/BDD Practice
- Testing Part 2
- Specification Part 1
- Specification Part 2 – Using Appropriate Tools
- Team Room
- Pair Programming
- Communication, Retrospectives, and Solving Problems
- Deciding what technology to use
- Building Quality In
- Kanban
- Roles, Responsibilities, and our “One Team” Philosophy
- Continued Learning and Personal Improvement
- Team Mentoring
- Demos
- Reducing Technical Debt and Cleaning up Messes
- How we define “done”
- My role on the team
Each section will talk about where we started, where we are, and the steps we took to get there. In addition, I will be providing information where I can about how we “sold” certain practices to management, and how we reconcile our practices with the sometimes opposing views of executive staff.
If you have any specific questions on any of the topics, or would like to propose others, please leave comments and I’ll see if I can work them in.
Hope you enjoy!
Technorati Tags: