Who practices sustainable pace?
Development is an art. Its a mental challenge (emotion if you pair). As a day goes by, an individuals definition of quality changes depending on their mood and energy.
Over short periods of time a team can keep up long hours; especially if there is positive momentum or results in sight.
But permanent hours to get more out the door? Does this really work with out sacrificing quality and practices?
How many times are corners cut to meet a deadline? Was it ever too much to write that test first? Was code copied without refactoring to remove duplication? Is there spike code in production cause it worked?
Is that our risk to take?
Can a person control burnout or realize the compromises they make? People have an amazing ability to adapt to any situation. In a bad situation, we forget, we lie (mostly to ourselves), we ignore and we accept things we shouldn't.
Subscribe to:
Post Comments (Atom)
7 comments:
Why do you always ask questions on your blog? Are we supposed to answer them, or are they rhetorical? ;)
My main project just got shut down and we're wrapping up a few features to last them for the next couple months until they turn off the switch.
Speaking of momentum, sustainability, and motivation: How's that for motivation, huh?
One way to look at it: I can sit and feel sorry and mumble and be bitter through it all, or I can take this time to 'experiment' and try the things I had been nervous about doing before with the code. Heck, if it's going to die anyhow, might as well try out that new refactoring or API I wanted to try.
I have a feeling that, in a few months, they WON'T scrap the project, it'll be back on and now I'll have my cool refactoring I was too chicken to do before. Hah!
If the project does get shut down for real, then I'll be off onto the next thing and I'll have that experience on my belt now.
Is there a name for this awkward time, working on a deadmeat project? If not, there should be. A snigglet, if you will... how 'bout "Coffin Building Time"
Great question. The team's responsibility is to deliver quality working software (highest value first) in a efficient AND predictable way. Sustainable pace is a practice that supports predictability and it supports quality.
Like most agile practices, how "well" you are doing sustainable pace requires reflection. What kinds of questions would be good for a team to ask each other about pace at retrospectives?
Oh gawd, I'm going to be so criticized since I am sooo non-agile; however, the very term "sprint" sounds unsustainable. A marathoner doesn't sprint for the entire race, right?
JoAnnP38 -- I feel that way too sometimes about the term sprint. In a different light it does make sense. The sprint is suppose to be about meeting short term goals and thinking about smaller milestones. Quicker results. At the end of each sprint you take time to retrospect and review with the client -- this gives you a chance to catch your breath for the next sprint.
How long are your timeboxes? Do you guys use Scrum for project management or some other agile variant like XP?
joannp38,
(late reaction) I've been using Scrum for a long time now and find it a great way to manage priorities and keep the development moving. XP focuses more on development practices like TDD, pair programming, sustainable pace and love that from a technical side. So, really I like to do both -- they are not exclusive. An agile team with go through the different practices and change them based on what works and what doesn't and can use a bit from everything.
-Wendy
We have many large projects that are rewriting legacy COBOL and VB apps to Java EE 5. Months in OO design before development proved ineffective, so we have moved toward agile with two to four week sprints. However, the resulting code is still largely procedural and full of duplication, conditional logic, very large methods within very large classes. I have seen that refactoring at this stage is time consuming, difficult work. The next step is to combine our agile process with TDD so refactoring is incorporated into the development. The challenge is how to make this happen with scores of project teams and hundreds of developers. Suggestions?
Post a Comment