My team at work is in the process of reading The Art of Agile Development by James Shore and Shane Warden. I gather initially it was brought to the team as a way to learn how to improve our writing of stories. We've decided to go further with it and try to rethink our development process.
We have seven developers that maintain several applications, with generally two or three of them getting focused attention (more than just fixing bugs) at any given time. These apps vary greatly in how much automated testing had been done for them and how much technical debt they've pulled up.
Our first step/attempt is going to involve one person trying to do any necessary maintenance work for all but one of the apps. Everyone else will be doing a release on the remaining one.
Some concerns we've got:
- How quickly can we minimize the maintenance role? Cause it's no fun being the only one on the outside.
- We don't have a coach. The book seems good, but experience is better.
- We've still got a bunch to learn/internalize. From TDD to visible charts to retrospectives. While it makes sense it's not second nature so we'll have to be mindful - not the worst thing to have to be. :)
- We can't just focus on one app and switching between them will be necessary to continue to deliver value for each of them.
- We've got a customer identified for our first product, but the other apps aren't as clear cut for who could serve that role.
I'm certain will have more concerns and challenges as we go along, but hopefully we'll keep moving forward.
No comments:
Post a Comment