Loading...
 
Location : AgileCoachCamp Wiki > SusanDavisPositionPaper SusanDavisPositionPaper

SusanDavisPositionPaper

What's your experience coaching teams toward being Agile?

I began in 2002, moving my team (part of a heavily (and heavily dysfunctional) Waterfall department) to agile methods out of self-defense. Afterwards, I spent three years doing client-facing XP development and helping to drive process improvement. Last year, I built an agile organization from scratch. Now I'm guiding a company through a transition from claiming-agile-but-not-really to real Scrum and xP@Scrum. Along the way, I've picked up my CSM, and learned a lot from a lot of sharp people.

What do you plan to learn /explore at this conference?

Much of the literature assumes a consulting or contract development model, doing services work for a specific customer to whom you demo, and who (if you're lucky) has a representative in the room with your team. How does this adjust to a product model where a product manager is present as an abstraction layer between the team and multiple real customers with conflicting priorities?

We rely heavily in both directions on teams that are non-agile or less agile. Our operations/platform/deployment team runs on a completely different process, and our client-facing BA types generate a lot of documentation up front due to our domain. How best can we work together?

Domain-driven design and the engineering practices from xP both seem like best practices. DDD builds out from a rich domain model commonly arrived at with the customer; xP incrementally arrives at just enough underlying structure. How do you sort out the resulting impedance mismatch?

As a manager, I have lots of management tasks that I sometimes need to work at what would be an unsustainable pace for a developer to complete. As a technical leader, I find that I need to keep to the same sustainable pace as the rest of the team to be effective. How to sort out the resulting impedance mismatch?

One school of estimating involves constantly normalizing to how much time things actually take, so that a story point is always a fixed amount of effort, and things take fewer points to complete as you improve. Another school fixes the scope of a story point early in the project, concentrates on estimating stories relative to one another (so that you can swap, say, a 2 for a 2), and shows measurable velocity increases as you improve. The second one seems easier to get right, but A) people still think in units of their own time, and B-) how do estimates of remaining time match up with estimated story points? More generally, what do people do to get estimating right?

What better reflects the state of your iteration: xP-style burndown where you only get credit for velocity when a story is done and accepted, or Scrum-style burndown where you add up the "time remaining" of the tasks in your sprint?

...and many more questions like that. And are there any more fundamental conclusions that the answers (or discussion process) to those questions point at?

How do you plan to contribute?

I have recent experiences to share from multiple companies and projects, questions to spark conversations, and I might even get my product owner to come along as well. I've also been learning about people management and how it can affect good process.
Created by debhart. Last Modification: Wednesday, 23 of April, 2008 16:11:29 CEST by futabachan.