Home > Archive > Extreme Programming > August 2006 > agile/Agile/losely managed chaos?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
agile/Agile/losely managed chaos?
|
|
| slippymississippi@yahoo.com 2006-08-24, 6:58 pm |
|
We're implementing pieces of extreme where I work. The first piece
we've implemented is the Collective Code Ownership (tm):
http://www.extremeprogramming.org/map/code.html
This is new to us, but it's working great. The problem is, we've added
a developer who has actually done extreme in toto and he's aghast at
what is passing for an iteration here. Basically, we're taking a chunk
of defined requirements, and producing working software on a regular
basis. The problem being ... our concept of an iteration is still
fuzzy. We're just taking however long we need to produce the
requirements.
Is this so wrong? We're really rocking right now. I agree that we
need to improve on our processes, but he acts like the world is going
to end over this.
| |
|
| slippymississippi wrote:
> We're implementing pieces of extreme where I work. The first piece
> we've implemented is the Collective Code Ownership (tm):
>
> http://www.extremeprogramming.org/map/code.html
>
> This is new to us, but it's working great. The problem is, we've added
> a developer who has actually done extreme in toto and he's aghast at
> what is passing for an iteration here. Basically, we're taking a chunk
> of defined requirements, and producing working software on a regular
> basis. The problem being ... our concept of an iteration is still
> fuzzy. We're just taking however long we need to produce the
> requirements.
>
> Is this so wrong? We're really rocking right now. I agree that we
> need to improve on our processes, but he acts like the world is going
> to end over this.
Sometimes the world ends without first giving warning signs.
Sometimes we adopt a process that hides the warning signs. And sometimes we
ignore the signs as they come.
Are there any warning signs?
Shared Code Ownership only works with Continuous Integration, and unit
tests, and a test server. I fear you have simply relaxed some rules, and the
programmers are now having too much fun, while sowing the seeds of
destruction.
What's your bug rate? As you adopt Agile, it should drop. If it doesn't, you
are doing something wrong. The current rate could itself be a warning sign.
You could promote your XP veteran to coach, and simply do what he says. The
main problem with XP adoption is lack of experience, so you are ahead of
that problem already.
Would strict w ly iterations, with a short feature list in each one, kill
you??
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Laurent Bossavit 2006-08-24, 6:58 pm |
| Hi Slippy,
> Is this so wrong? We're really rocking right now. I agree that we
> need to improve on our processes but he acts like the world is going
> to end over this.
I'd recommend having a conversation with the guy about the why and how
of improving your processes. You'll probably find he agrees that process
improvement takes work, takes time, and comes with some risks.
Ergo, you can treat process improvement as yet another kind of project.
If so, you'll probably benefit from applying some agile principles to
the improvement project:
- take an inventory of which things you might change or improve, which
practices you might adopt, and so on.
- implement the plan one well-defined chunk at a time
- have well-defined "tests" (measurements or observables) to tell
if each chunk is working
- involve your customers in the planning process and get their feedback
on implementation
- prioritize these improvements based on expected value *to the
business*
That last is crucial. The zillion things you could change about your
process will have different cost/benefit profiles. You want to start
with the things that deliver the biggest "bang for the buck". Among
these, you want to start with the things that don't take a lot of
"buck" - because if you show success with a relatively small change, you
will gather support from the business for larger changes.
Ask your XP guy if this "length of the iteration" issue is the smallest
thing you can fix that will give you a measurable, significant
improvement in performance; or if maybe he can think of other things
first.
Remind him of the difference between the roles of "consultant" and "team
member". While his experience with XP makes him a great resource to have
in the process of raising your game, the "agile" way is to have process
decisions taken by the team, with the approval of the business.
Laurent
| |
| slippymississippi@yahoo.com 2006-08-24, 6:58 pm |
|
Phlip wrote:
> slippymississippi wrote:
>
>
> Sometimes the world ends without first giving warning signs.
>
> Sometimes we adopt a process that hides the warning signs. And sometimes we
> ignore the signs as they come.
>
> Are there any warning signs?
Not really. Our velocity is insane, and our defects are ridiculously
low.
But what this has done is to really turn the screws on QA, because they
don't have a regular timetable on which they can rely.
> Would strict wly iterations, with a short feature list in each one, kill
> you??
Not at all, but I think it's going to take some work to get to that
point. I have offered to let him take over the coach role, but I'm not
sure he's ready to assume that much work. And in some instances, we
have little control over what is demanded and in what time frame,
because we are a development shop servicing a global set of
consultants, and we never know who's going to have his/her handle on
the steering wheel.
My suggested solution was this: since we can't literally sit face to
face with our customers, we designate QA as the customer and sit
face-to-face with a dedicated QA resource throughout the life of the
project. They tell us what features are most important and when they
want the features deployed. In this way, QA serves as our quality
enforcement and our risk mitigation.
| |
|
| slippymississippi wrote:
> Not really. Our velocity is insane, and our defects are ridiculously
> low.
Please check how much of each you are doing:
[ ] Test-Driven Development
[ ] Customer Acceptance Tests
[ ] Pair Programming
[ ] Continuous Integration
[ ] Onsite Customer
[ ] Planning Game
[ ] Common Coding Style
[ ] Energetic Work
[ ] Common Workspace
[ ] Continuous Deployment
[ ] Frequent Releases
> But what this has done is to really turn the screws on QA, because they
> don't have a regular timetable on which they can rely.
Another problem with warning signs is identifying the signs that are indeed
warnings.
And why isn't QA part of the Customer Team? Why aren't their needs being
met?
> My suggested solution was this: since we can't literally sit face to
> face with our customers, we designate QA as the customer and sit
> face-to-face with a dedicated QA resource throughout the life of the
> project. They tell us what features are most important and when they
> want the features deployed. In this way, QA serves as our quality
> enforcement and our risk mitigation.
Okay, QA _is_ the Onsite Customer role. And you are making their job
easier - rapid turnaround on feature requests (right?) - and also harder.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| slippymississippi@yahoo.com 2006-08-24, 6:58 pm |
|
Phlip wrote:
> slippymississippi wrote:
>
>
> Please check how much of each you are doing:
>
> [X] Test-Driven Development
> [X] Customer Acceptance Tests
> [X] Pair Programming
> [X] Continuous Integration
> [X] Common Coding Style
> [X] Energetic Work
> [X] Common Workspace
> [X] Frequent Releases
> [X] Continuous Deployment
> [ ] Onsite Customer
> [ ] Planning Game
This last one is the sticking point, iteration planning. We obviously
need some coaching on this. I'm just not sure that he wants to
obligate himself to coach us.
>
>
> Another problem with warning signs is identifying the signs that are indeed
> warnings.
>
> And why isn't QA part of the Customer Team? Why aren't their needs being
> met?
I think because QA wasn't part of the original buildout ... this shop
is a proof-of-concept: bring in senior developers who love to mentor,
recruit the local schools, and turn the new kids into professional
developers within a short time frame. QA didn't exist as a department
until a couple of months before the kickoff of our first project, and
then did not have an assigned lead. The thing that's driving our XP
coach's chagrin is that he has also been tasked with leading QA until
we land an actual QA lead.
:)
That's why I like the idea of having a dedicated QA person sitting with
us on every project ... because it gives him more incentive to coach us
on how we need to change our iterations to more facilitate that end of
XP.
> Okay, QA _is_ the Onsite Customer role. And you are making their job
> easier - rapid turnaround on feature requests (right?) - and also harder.
Here is where I'm failing, I believe. When QA comes to me and says
"this test failed, and I cannot proceed unless it's fixed" then we
immediately push up a fix and allow them to proceed. The problem with
that is the regression tests then need to be done against the fix. If
our iterations were short enough (one w), we could simply work that
bug fix into the next iteration, and QA as a distributed resource could
move on to the next release in their queue of things to test. As it
is, QA is having trouble planning their allocation of resources.
| |
|
| slippymississippi wrote:
The TDD is rocking your world, and is destabilizing your QA department.
[color=darkred]
And yet you claim you have no onsite customer. You do - the QA department.
[color=darkred]
>
> This last one is the sticking point, iteration planning. We obviously
> need some coaching on this.
Each Friday morning, perform a release ceremony, and build an install CD or
whatever with your finished product on it. Burn another CD with source.
Each Friday afternoon, demo the code to yourself and check off each feature
that got done. Then make a list of the features to do next w.
> I'm just not sure that he wants to
> obligate himself to coach us.
I didn't think that would be hard.
I expect some coach will now flame me. ;-)
You now seem to understand the situation with QA better...
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Ron Jeffries 2006-08-25, 6:58 pm |
| On 24 Aug 2006 10:15:59 -0700, slippymississippi@yahoo.com wrote:
>We're implementing pieces of extreme where I work. The first piece
>we've implemented is the Collective Code Ownership (tm):
>
>http://www.extremeprogramming.org/map/code.html
>
>This is new to us, but it's working great. The problem is, we've added
>a developer who has actually done extreme in toto and he's aghast at
>what is passing for an iteration here. Basically, we're taking a chunk
>of defined requirements, and producing working software on a regular
>basis. The problem being ... our concept of an iteration is still
>fuzzy. We're just taking however long we need to produce the
>requirements.
>
>Is this so wrong? We're really rocking right now. I agree that we
>need to improve on our processes, but he acts like the world is going
>to end over this.
The world won't end, but there are some important advantages to fixed length
iterations. These include better predictability, and a general tightening up of
loose areas in the team process, since at the end of each iteration everything
has to work all at the same time.
So I'd suggest that at some convenient time, you might start working in one- or
two-w iterations for a while and see what happens.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
|
| Ron Jeffries wrote:
> So I'd suggest that at some convenient time, you might start working in
> one- or
> two-w iterations for a while and see what happens.
I'd suggest you ask QA how long the iterations should be, what their
wdays are, what their ceremonies are, etc.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
|
|
|
|
|