Chairman: I’d like to call this meeting to some sort of order, if that is at all possible.
Ford: Look! C’mon please! I mean everybody! There is some important news: we’ve made a discovery.
Management Consultant: Is it on the agenda?
Ford: Oh don't give me that!
Management Consultant: Well I’m sorry, but speaking as a fully trained management consultant, I must insist on the importance of observing the committee structure...
Chairman: Listen! I would like to call to order the five-hundred-and-seventy-third meeting of the colonization committee of the planet of Fintlewoodlewix. And furthermore...
Ford: Oh this is futile! Five-hundred-and-seventy-three committee meetings and you haven’t even discovered fire yet!
Management Consultant: If you would care to look at the agenda sheet ... you will see that we are about to have a report from the hairdressers fire development subcommittee today.
Hairdresser: That's me.
Ford: Yeah, well you know what they’ve done don’t you? You gave them a couple of sticks and they’ve gone and developed them into a pair of bloody scissors!
Marketing girl: When you have been in marketing as long as I have, you’ll know that before any new product can be developed, it has to be properly researched. I mean yes, yes we’ve got to find out what people want from fire, I mean how do they relate to it, the image...
Ford: Oh, stick it up your nose.
Marketing girl: Yes, which is precisely the sort of thing we need to know, I mean do people want fire that can be fitted nasally?
Chairman: Yes, and, and, and the wheel. What about this wheel thingy? Sounds a terribly interesting project to me.
Marketing Girl: Er, yeah, well we’re having a little, er, difficulty here...
Ford: Difficulty?! It’s the single simplest machine in the entire universe!
Marketing Girl: Well alright mister wise guy, if you’re so clever you tell us what colour it should be!
-- from Hitchhikers's Guide to the Galaxy (Prehistoric planet, scene 7)
Meetings. Bloody meetings. There's no avoiding them.
I've attended all sorts of meetings over the years.
Some good, some bad.
Many companies decree that an agenda be circulated to all attendees well in advance of any meeting
and that minutes be sent to all partipicants promptly following the meeting.
Others are less strict.
How does your company do meetings?
The Scrum Daily Meeting
Scrum prescribes a fifteen minute daily meeting.
The rules for my first Scrum daily meeting seemed simple enough:
- The meeting happens at the same location and the same time every day.
- The meeting must start precisely on time.
- The meeting is timeboxed to 15 minutes.
- Anyone is welcome to attend, but only "pigs" may speak.
The (strict) meeting agenda is for each team member to speak in turn, answering three questions only:
- What did you do yesterday?
- What do you plan to do today?
- Do you have any impediments?
The ScrumMaster ensures the meeting runs according to the above rules, and is further responsible for ensuring that impediments are removed.
Sounded simple enough.
However, I soon discovered that running an effective daily meeting is surprisingly tricky,
there being many "subtleties" to consider.
Subtlety No. 1: When to hold the Daily Meeting?
The first subtlety was that my team was instructed to hold their daily meeting at
an allotted (early) time slot, so as "to start the day with an energizing meeting"
and not clash with the daily meetings of other teams, thus allowing high level managers
to attend all the daily meetings.
We were less than thrilled with our "early bird" time slot, most of us
being "night owls".
On principle, I felt we should schedule
our daily meeting at a time and place that suited us.
After all, the daily meeting is primarily for the (empowered, self-organizing) team, not the managers.
Good Stress, Bad Stress
As you might expect, the early meeting time slot was causing some unwelcome stress within my team.
Sometimes a train was late or cancelled.
On other occasions, family duties, such as taking a child to school,
caused team members to be late or even to miss the daily meeting.
And this stress was not reduced when agile coaches proposed the imposition of
humiliating punishments or fines for being late to the daily meeting.
On one occasion, an overweight team member (let's call him Taffy) with a family history of heart disease just made it to
our daily meeting in the nick of time -- but only by sprinting from the train station.
Taffy was red in the face, puffing excessively, and looked quite unwell to me.
I thought he might even suffer a heart attack.
Now he's a lovely guy and a first-rate programmer and it upset me to see him
being subjected to such unnecessary stress. Like cholesterol, there is good stress and bad stress.
This was definitely bad stress.
This is an office job, not the army.
After seeing my good friend suffering like this after his train was delayed,
I got pretty worked up. This was insane! It's not worth endangering your health to arrive at work five minutes earlier.
I lost the plot a bit at the daily meeting and our team was
thereafter allowed to choose our own time slot.
We chose just before lunch.
This worked very well; it eliminated the bad stress,
and it became very rare for anyone to be late to our daily meeting again.
Moreover, holding the meeting just before lunch minimized harmful context switching
because we broke for lunch as soon as it ended.
Subtlety No. 2: Is it a Meeting or a Ceremony?
The second "subtlety" arises when senior managers, with the power both to fire and
grant generous pay rises, attend the daily meeting.
When that happens, in my experience, instead of honest and direct team communication,
you get a surreal form of theatre, with each performer on
the stand-up stage trying to look good (or at least not foolish) in front
of the (intimidating) bigwig audience.
To mitigate this less than totally honest communication, most of our teams
took to holding a second "team only" daily meeting
where they could communicate more openly and without fear.
Dogmatic Pigs and Chickens
I'm reluctant to assert this was anyone's fault.
After all, it's only natural to want to look good in front of someone powerful enough
to fire you or grant you a pay rise.
All the senior managers behaved admirably, following
the standard Scrum daily meeting rules, namely:
Team members should address the Team. This is not a "Reporting to the ScrumMaster" meeting...
Chickens (non Team members) are welcome to attend the Daily Scrum Meetings but they are not allowed to talk, make observations,
make faces or otherwise make their presence in the meeting obtrusive.
-- from Daily Scrum Meeting Rules
Very rarely, a manager "chicken" couldn't stand those damned rules any longer
and spoke up, offering well-intentioned (and often helpful) advice to the team.
Generally, I feel that Scrum contains too much dogma --
which often leads to heated and divisive argument, in my experience.
Accordingly, I doubt any great harm would come from relaxing the dogmatic "pigs and chickens" rules.
Certainly, I didn't mind when "chickens" had something to say at our daily meetings.
On the contrary, it was often useful and insightful, helping more than harming, IMHO.
It's advised by Scrum that during the Daily Stand-up (or "Daily Scrum") only pigs are allowed to speak,
chickens can listen in but can't speak.
While I understand, and even support, the intention of this - I really despise it.
Unfortunately, what commonly happens in many instances is that the team sees themselves as the "pig"
and all of management as their "chickens".
The team "goes scrum" and all of a sudden Chicken/Pig cards are flying left and right.
"You can't speak at our stand-up!"..."You can't come to our retrospective!"..."You can't tell us how to organize our cards!"
..."You can't... go away... you can't...leave us alone...you can't you can't you can't...".
Essentially, the team tells their managers to take a hike.
Now, while a renegade team shunning their manager may in the luckiest cases represent an improvement
over Command and Control, it's a far cry from what we mean by Empower and Support.
In a nutshell, a "chickens & pigs" attitude ultimately begets nothing more than an
"Us versus Them" culture. Uggg. What we really want is simply an "Us" culture, no "Them".
Remember "People & Interactions"?
-- Don't like Green Eggs and Ham Mike Bria blog
Update: The Scrum Update (July 2011)
has removed all references to Pigs and Chickens.
The reasons behind this decision are discussed
in the "Chickens and Pigs" section of the
Scrum Guide Updates
where Steve Porter further elaborated that:
The labels were being used to create barriers between the Scrum team
and individuals in the organization who potentially could assist the
team in meeting its goals.
Subtlety No. 3: The Importance of a Good ScrumMaster
You will have, if you use Scrum, someone on each team whose name is,
it's called the ScrumMaster, also known as "The Prick".
And this person's job is to make sure that you don't cut quality. D'oh.
And they have no authority but they, what they can do is if we've defined
that an increment has a certain level of quality for it to be demonstrated
to our product management, their job is to make sure that quality's there.
And if the quality isn't, not to let you demonstrate it, but instead to say
to the product manager, "Hmph, we lost our heads, we're not done, it's gonna
take us another month to finish this".
This person is probably the least loved person in the world because they stand
right at the nexus between product management believing that any amount of stuff
can be done and our willingness to help them cut quality to support that belief.
The burnout rate on these people is usually, like, 13 to 14 months. Throw 'em away.
We often get them from hopeless, professional areas like QA.
People in QA are used to doing incredible things with no authority, no respect,
and no hope of success, so that's where we take these people.
-- Ken Schwaber, Google tech talk on Scrum, Sep 5, 2006 (46:34)
As indicated above, the ScrumMaster is a tough role.
Some ScrumMasters are good. Others clueless.
Yet they all attend the same two-day course to become a "certified ScrumMaster".
I see the ScrumMaster role as a chronic weakness of Scrum;
you either get effective ScrumMasters who burn out in "13 to 14 months" (Schwaber)
or ineffective ones who just go with the flow and never push back on quality.
It's a great marketing and money-making device though, with certified
ScrumMaster courses that can only be run by certified ScrumMasters.
Rather than a dedicated specialist ScrumMaster, I suggest that the daily meeting
be run by the team, with each team member, in turn, running the daily meeting.
This mitigates the (single point of failure) risk of an incompetent ScrumMaster
while creating a vibe of inclusiveness and making it less likely for an individual personality
to dominate.
Subtlety No. 4: Using the Daily Meeting as a Control Mechanism
What made the meetings most painful was my boss (I'll call him Wally) ...
For Wally, the stand-up meeting
(like the 7 a.m. Monday meeting and the 5 p.m. Friday meeting)
was a loyalty test designed to reinforce the employer-employee relationship.
Restricting team interaction to 10- to 15-minute snippets is artificial and suggests disconnection and coldness.
The 15-minute meeting conveys an explicit message: “Let’s keep it short and to the point”.
But there is another, more subtle, message: “We can’t waste time socializing; just deliver the facts.”
I think there is something wrong with a meeting held standing up.
Standing is inherently onerous.
It is used for punishment in schools and in the military: “Stand in the corner,” “Stand at attention,” etc.
Standing has an implicit element of authoritarianism and theory X control
(which asserts that people will respond only to threats).
The point is, in the hands of an authoritarian manager or in a hierarchical,
command-and-control environment, the stand-up meeting can become a weapon.
-- Why I Hate Stand-up Meetings by Phillip A Laplante, Penn University
Three simple rules can help alleviate Laplante's authoritarian concerns:
- Call it a daily meeting, not a "standup" meeting. By all means, time-box it, but don't demand that everyone stand. Apart from the undesirable authoritarian overtones pointed out by Laplante, demanding that everyone stand discriminates against those with specific medical conditions. Moreover, strictly demanding a process in which "all people must stand" violates the agile principle of "individuals and interactions over processes and tools".
- The time and place of the daily meeting should be decided (without coercion) by the whole team, not by a command-and-control manager (see "Subtlety No. 1" above).
- The daily meeting should be run by each team member in turn (see "Subtlety No. 3" above).
Daily Meetings: "Add Value" or "Coordination Cost"?
I have discovered that many people have trouble identifying wasteful activities.
I have seen, for example, Agile advocates argue that daily standup meetings are value-added.
I do not subscribe to this view.
I cannot fathom that a customer cares whether a team holds standup meetings or not.
What the customer wants is functionality that enables their goals, delivered in a timely manner with high quality.
Whether or not a team needs to hold daily standup meetings to enable such delivery is neither
here nor there from their perspective.
When you ask Scrum advocates who vehemently argue that daily meetings are value-added,
whether they would hold the standup twice daily or whether they would lengthen it
from 15 minutes to 30 minutes, they will surely reply, "No!".
"Well, if standup meetings are truly value-added", I reply, "then surely doing more of them would be a good thing!".
This is really the acid test that demonstrates the difference between a truly value-added
activity and a transaction or coordination cost.
Developing more customer requirements is clearly value-adding.
You would do more of it if you could and the customer would gladly pay for it.
Planning is clearly not value-added.
The customer would not pay for more planning if he could avoid doing so.
-- Kanban book by David Anderson (p.215)
At the risk of taking this to a pointless Room 12A battle between Agile and Lean advocates,
I agree with Anderson that daily meetings are indeed a "coordination cost".
Accordingly, following Lean principles,
each team should reflect on how to minimize the time and energy spent on them and how they might make them more effective.
While I personally feel that team daily meetings are well worth the cost for most teams,
there are many pitfalls for the unwary, as indicated above.
Other Articles in This Series
References
|
Re: Nobody Expects the Agile Imposition (Part V): Meetings
by mr_mischief (Monsignor) on Dec 12, 2010 at 19:44 UTC
|
The more I read about Scrum, especially in your fine nodes here at Perlmonks, the more I find an odd and funny disparity between the "agile" ideal and the rigid enforcement of pomp and false tradition. I say "false tradition" because it's being enforced from on high and hasn't really had a chance to become an organic observance of the people involved. Does all of this rigidity in the coordination points really add to the fluidity and adaptability of the team in completing projects? Would a daily group chat log achieve all of the benefits of an in-person meeting in this context? There are many questions raised by these rules imposed on the process.
I understand the importance of frequent status updates. If someone has a task estimated at a month, you don't want to find at 27 days that the task is off-course and will take two months to complete. These daily meetings are useful as articulation points. Up to a point, the more rapidly you can get information about the accuracy of your estimates the more you can adjust.I'm not certain the fixed schedule, place, and format of the meetings is necessary to make the team members accountable for their estimates and to adjust the implementation schedule, though. Reporting to the whole team rather than just the project manager is good, and for some people a face-to-face meeting will make them feel more accountable perhaps. I think reporting to the team is the bigger feature, though, compared to doing so face-to-face.
The importance of always having the meeting at the exact same time and in the exact same place are clear. However, they are only important for a face-to-face group meeting. Keeping the group waiting in person or having half the team in the wrong room is bad for getting the information shared.
However, there are other ways to share information. Imagine a scenario with me. Have each team member answer the three core questions of Scrum every day. Have them do so into a log (minutes are just the transcription into a log anyway) readable by the whole team. Make sure they make their entries by a certain time. Have the whole team actually read it every day, before they start on their own entry for the next day. This scenario and its contrast to the prescribed ritual of Scrum for me leads to several questions. First and foremost, in what way does this detract from the quality of the information or its effective use? Do questions have to be raised interactively during a face-to-face meeting? Can a team member not ask another about his answers to the three main questions on a bulletin board or forum? Is the main problem with using technology to facilitate the transfer of information in this way that it violates the time box? Is the time box actually as important as getting full answers to the questions that are important enough to ask in a meeting? Isn't the time box important mainly because group in-person ties up all the resources of the team at the same time in the first place? Is there actually a concern that the team members will waste so much time communicating about the project that the implementation will fall behind from that one factor?
The frequent exchange of information is the goal here. That much is clear. However, the rest of the meeting information in Scrum seems to be just potentially useful tips for how to conduct the meetings in an orderly way. It almost feels like the authors of the method felt they were short some material after stating all the other rules to Scrum. The added detail beyond which questions are to be answered daily and which parties are to be actively involved in the discourse and which are to be observers (which are excellent ideas) seem to me to be filler for the books. At best they are reasonable defaults, and in no way do they seem to be absolute necessities for every team.
| [reply] |
|
|
I understand the importance of frequent status updates. If someone has a task estimated at a month, you don't want to find at 27 days that the task is off-course and will take two months to complete. These daily meetings are useful as articulation points.
But that's not the point of daily standups. In an "out-of-the-book" sprint, the team has at the beginning of the sprint split the project into small tasks without deciding who is going to do what. Tasks can be in a small number of states: "not worked on", "being worked on", "blocked" (or impeded), "done". Many teams use a board with columns for the states, and sticky notes for the tasks. During the standup, people move sticky notes from one column to the other. The standup is important to avoid having the same people work on the same task, and to know which tasks can now be worked on because they first need other tasks to be finished. (For instance, if a project involves installing an OS and a database, the task for installing a database cannot be done before the task of installing the OS has finished (which needs to be done after taking the machine out of the box and into the racks (which can only be done after ordering the box (which depends on the task of securing funding, etc)))).
Note also that in out-of-the-box scrum, you don't estimate how long a project will last, then adjust the estimate during the development. It's the other way around. "We have a month (or 2 weeks, or 2 months, usually nothing longer), what can we do in that period". Traditional project management is usually "We want X, we have Y developers, hence we estimate it's going to take Z days", or "We want X, the deadline is in Z days, hence we estimate we need Y developers". Scrum is "We have Y developers, we have Z days. Product owner, split X into smaller X' features, and we'll estimate how many X's we can do". (Note I'm not giving any judgement whether this is a good idea, and I'm sure everyone can come up with at least one scenario where it isn't going to work - I'm just telling what the reasoning behind scrum is).
| [reply] |
|
|
Bah.
If you have actually succeeded in “breaking the work down into small tasks,” it doesn’t really matter “who does what.” The real issue, neatly avoided by all this quasi-sports talk, comes down to exactly two things:
-
Are you correct in your breakdown of the tasks?
-
Will the target ever change position, or otherwise change in any way at all?
Imagine, if you will, the task of shooting arrows at a target in a tornado. Most of the arrows that you shoot are going to fly off course: it doesn’t matter at all if, or how, you “track” those arrows. Either the arrows were mis-aimed, or the target moved, or you somehow just wound-up with an arrow in your butt (but don’t quite know just how it got there...), or some combination of the three.
Or maybe you have a “magic arrow” that will zip this way and that, gradually “homing in” on that moving-target. But, how long was the course taken by that arrow, and how many trees and other obstacles did it have to blast its way through on its magical, determined effort to “finally hit the target?”
An experienced marksman would wait for the tornado to pass. She would size up the situation carefully, place herself at the position she had chosen, and fire one shot. Only one. And she would not walk up to the target to see if her arrow had done its job.
I say (and not without experience to back me up...) that, when you are actually ready to write software code, writing the code is easy. After all, “the code” is simply an expression of the design ... the most-rigid and inflexible expression, but comprehensible to a digital computer. This should be the last incarnation that your completed design will take, and you should delay putting it into that form as long as possible.
But of course, people who are paying a dreadful amount of money for something want to see “progress.” And people who are working on that something, want to “progress.” Building meticulous blueprints doesn’t feel like “building a house.” And, Home Depot didn’t get to be a big, fat company by selling materials to people who draw blueprints.
(I don’t say this to be persnickety. I say this as someone who has written more than three quarters of a million lines of source-code in about twenty programming languages... while silver-bullets came and went, and were in their turn discarded.)
| |
|
|
So they wrote a book on managing a to-do list?
There's nothing that can be done with overpriced slightly tacky paper squares that can't be done in software more reliably. If you must meet in person, at least get a projector and use scheduling software. In/out status of the team members, completed/incomplete/not started status of a subproject, Gantt modeling, dependency tracking, and more are very simple software tasks. If your team can't find software to do those things and can't knock that together in a week then they have no business writing projects that need it.
| [reply] |
|
|
|
|
Re: Nobody Expects the Agile Imposition (Part V): Meetings
by JavaFan (Canon) on Dec 12, 2010 at 15:06 UTC
|
We do daily "standups" as well. Typically, people sit down. Most teams will have at least one member that phones in. In our team, some people work from home (they always phone in), some from the office. But they aren't always in the office yet - so they phone from home, then come to the office. And one guy even has the tendency to phone during his commute.
In the beginning, we did have some product owners who'd join the standup, but that quickly petered down. It's probably over a year ago anyone but a team member was present during the standup. Some times, a product owner asks when the standup meeting is, and promises to join, but that typically doesn't happen.
We do stray a bit from the official rules: sometimes we do discuss how to implement something. But that's partially because some people work from home most of the time, and our stories often are quite short (lots of stories take a single developer three days or less). I've some times stories that come up after the daily standup, and which I've rolled out before the next days' standup. (Our team no longer does fixed time "sprints", we continuously add stories to our backlog). | [reply] |
Re: Nobody Expects the Agile Imposition (Part V): Meetings
by sundialsvc4 (Abbot) on Dec 13, 2010 at 20:52 UTC
|
Fifteen years ago, the “magic bullet” was, well, something else. Twenty-five years ago, something different. Thirty-five years ago, someone wrote The Mythical Man-Month. (It was a great deal easier to read than Programmer’s Death March, or maybe that’s just me...)
I am pleased to see, however, that the wheels of commerce are still turning: whether or not software development actually bears any resemblance at all to the game of rugby, you can still make money selling the idea to fat, overweight managers whose only actual tangential involvement with the game of rugby consists of ESPN and beer... and getting them to pay for “certifications” from you on their way to ensuring continuous employee turnover.
Pardon me for being cynical. Naw, strike that. Maybe I’m old enough by now to say that I don’t particularly care if you find my words to be cynical or not. There is no silver bullet. “Silver bullets” always devolve into pathetic rituals that only make matters worse, as people obligingly pay lip-service to them but no more than that. (Go ahead... fire them if you want to.)
Software development is no more strange an undertaking, and no more intrinsically complicated, than “building a house, starting with a blueprint the creation of an original blueprint.” Which is, by the way, an immensely more complicated task than it may initially appear to be. And, “aye, there’s the rub scrum.” Making people’s live miserable and demanding that they hand over their days, nights, weekends and (!)-life if they still have one to you, won’t make your software any better: it will just make it take longer as the really good people that you want most won’t put up with that (!) will leave.
Pretend that the thing that you are building is not intangible. Give up on the notion that it plays by different rules from anything that has ever gone before.
Emphatically, what fails the most in a software project is internal communication. Things get dropped and overlooked because there is no mechanism in place for keeping track of them. Software goes into production un-tested because there is no actual mechanism in place to test it, and no time in the schedule to deal with it when problems surface. Silver-bullet “solutions,” and the expectations that go with them, merely exacerbate this problem.
| |
|
|
While I mostly agree with you, there is one important aspect of what Scrum is:
Most of the scrum BS is targetted at the developers morale, I mean, it looks like theater because it is meant to be. The idea is that the young developers, eager to be part of a cool project, take part of entertaining project events, such as the poker play or other theatrical parts of the scrum methodology.
Of course more experienced developers know this is bullshit and they usually want to skip it, the ScrumMaster (a good one) should know this is bullshit but he should also know that the bullshit is important to keep the developers motivated -- often it is also helpful to look cool for a customer that is a tech wannabe, so he also needs the "cool" stuff.
In terms of methodologies, there is, in fact, one aspect of the agile methodologies (be it scrum, xp or whatever) that should be taken into account. They share the idea that the risk of the project as a whole (in the sense of the actual value added to the customer) is shared between the devel team and the customer. That meaning, if some prioritization is done wrong and the software misses one important feature, it's not the "requirements analisys" fault, but "bad judgment by the customer" -- even if it is something the customer is not experienced enough to know but the devel team is supposed to know.
The good part is that it cuts down most of the coordination cost, the bad part is that if the customer is not fully aware of the risks he is taking, it could lead to very dangerous places.
| [reply] |
Re: Nobody Expects the Agile Imposition (Part V): Meetings
by talexb (Chancellor) on Dec 14, 2010 at 14:01 UTC
|
Our stand-up meetings really are stand-up meetings, and they're near the scrum wall (currently still holding details from a scrum that started six weeks ago, that's no longer active. Read into that what you will.)
If there's committee business (how are you going to do task X, because I have an idea about that), it gets taken off-line. Apart from that, it's a quick five minute get-together to make sure everyone's aware of what everyone else is working on.
We also have a longer weekly meeting to discuss long-term goals, vacation, future assignments, upcoming projects. The team lead takes notes about all that, and it goes onto the Redmine wiki so that higher-ups don't need to get sent a weekly E-Mail -- they can just check the Intranet whenever they feel like they need to get up to date on the team.
Works for us!
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds
| [reply] |
Re: Nobody Expects the Agile Imposition (Part V): Meetings
by raybies (Chaplain) on Dec 14, 2010 at 13:27 UTC
|
Having someone to report to daily helps me as a developer to remain more engaged in whatever tasks I'm working. I find that if I am given a week to do a task, then at the beginning of the week, I am pretty relaxed and not as engaged as I am as I head towards the end of the week. Then generally speaking I am garanteed not to make that deadline, and I'm given another week. Lather. Rinse. Repeat.
If I'm given a month. Same thing.
The blowout over-schedule can go multiple months on this plan.
With daily accountability, I may be over a few days, but it's still only a few days--rather than a few weeks or worse a few months.
I also like the idea of keeping management out of developer meetings. Currently I have weekly meetings with a team upon which I am more or less my own boss. I find that most of the reasons I go there is to report to management that I'm still alive and should still get a paycheck. Yet, I get to sit there and listen to bloviations galore by the program manager who doesn't know how to do internal dialog and thinks "outloud", repeating topics we've been discussing for the past few years, without resolution. It's really fun. Anyone wanna take my place?
The only good thing to come out of the meetings is generally a sense of comraderie that we survived another meeting without slipping into a coma.
| [reply] |
Re: Nobody Expects the Agile Imposition (Part V): Meetings
by iguanodon (Priest) on Dec 14, 2010 at 16:46 UTC
|
Thanks for a very informative (and entertaining) series of posts. This hits
close to home for me because I'm currently experiencing the Agile Imposition.
It's been a very demotivational experience (no posters yet though :) for me
because in the five years at my current job I've worked with a great team that
has never failed to deliver on time and on budget. We have always been able to
deliver quickly and respond to changing requirements. We have never had a
problem communicating with each other. But now we're told that in spite of our
record of success we have to change the way we deliver software because managers
get gold stars for "embracing Agile". I don't have a problem with the Agile
methodology per se, but in our case it's fixing something that ain't broke.
When your life resembles Dilbert so closely that you start to suspect Scott Adams
is spying on you from a nearby cube, is it time to look elsewhere?
| [reply] |
Re: Nobody Expects the Agile Imposition (Part V): Meetings
by Anonymous Monk on Dec 12, 2010 at 14:29 UTC
|
Anyone is welcome to attend, but only "pigs" may speak.WOW, pig clowns, scary :) | [reply] |
|
|
