✄﹣﹣﹣﹣﹣﹣﹣﹣﹣
This article has been removed. An edited version appears in the book, The People’s Scrum, published by Dymaxicon, May 2013.
✄﹣﹣﹣﹣﹣﹣﹣﹣﹣
Read original comments…
Today, during a Scrum introduction workshop I came to a sudden realization that I didn’t want to use the word “meeting” when talking about Scrum. Meetings have such a bad rap in our industry, and rightly so. I recall hours-long, painful meetings where nothing moved forward, the louder people postured and argued, talked in circles and dug themselves in to ever-deepening trenches, while the quieter ones, stared at the table, or cowered from the conflict, wishing they could be back in their cubicle doing useful work.
Admittedly, Scrum has reduced this meeting overhead to a few key, timeboxed meetings but the legacy of “meeting culture” still hangs over us, heavily. “Scrum has too many meetings” is a common complaint… and then we discover daily meetings drag on for 40 minutes, retrospectives are unproductive, lack meaning or devolve into complaint sessions and planning meetings are controlled and directive, leaving team members sullen and brow- beaten.
It occurred to me in that moment that telling the workshop participants “these Scrum meetings are essential” was likely to deflate them rather than excite them about this new way of working. Meeting culture has penetrated Scrum, as it must. Something so heavy and oppressive, so entrenched in our way of being will crush anything that tries to challenge its power. The Scrum Alliance introduced the term “ceremony” to replace meeting, but that’s almost as bad, and to some people even worse, carrying with it images of cults and cloaked figures preforming strange rituals. And using that term in the same sentence with “ScrumMaster”… forget it!
So I used the term conversation. Scrum has people, I said, and it has conversations. There are conversations to plan, conversations to align, and conversations to reflect. We have these conversations at the appropriate times, and for the appropriate durations in order to inform our work. If we don’t have these conversations we won’t know what we are doing (planning), we won’t know where we are going (alignment), and we’ll keep repeating the same mistakes (reflection). Expressed this way I felt a lifting of interest, a lightening of the heart. I had essentially told this group of people “you never have to be in a meaningless meeting again”. And I believe that.
Let’s stop talking about meetings, and let’s stop having meetings. Nothing good ever came out of a business meeting. People in collaborative dialog though, now that’s exciting — that’s meaningful.
click to subscribe
Agile Anarchy 
I don’t remember where I read it, but the author called meetings “sharings”. In my opinion another term besides “conversation” which describes the essence of these come togethers(wow it is really hard to avoid the word meeting 😉
thanks for sharing
I agree, it is very hard to avoid the word meeting, but I think if we are serious about cultural change then we must. It is a challenge, but one I intend to rise to 🙂
It doesn’t matter whether you call it a meeting, a collaborative dialog, a sharing, a ceremony, or a spade. It is more productive to get the format and length of the meetings right, than to find new trendy names that confuse rather than delight. But you are completely right that we all think we waste too much time in meetings. I say ‘think’ because the right meetings with the right people, at the right time, are a vital method of communication. What Agile processes should do is keep meetings to a regular basis, for a minimum of time, and allow all the team to feel empowered at these meetings. The inclusive nature of the meetings in Agile are one of its strengths, and working for an organisation that has abandoned daily stand ups, I would not recommend this approach.
The solution to the problem of meetings should not be a change in terminology but a change in practice;
Have your stand up meetings facing a clock and stick to the 10 minute limit. If conversation needs to continue outside the stand up fine, but end the stand up and free up resources not needed for the continued discussion.
Retrospectives are often unproductive because they are repeating the same issues from previous meetings. The most successful I have attended always review the actions from the previous meeting to see if anything has changed, this should help to stop the same issues being discussed again and gives participants a greater sense on empowerment – that the discussion will lead to change they can believe in.
I am convinced that language matters. Our language often drives our behavior, and affects the way we think. If we invite people in for a conversation the energy will be very different to that which is created if we “schedule a meeting”. In essence we are beginning to act on our promise that Scrum will change the way you do your work. The message becomes palpable.
Of course, this is only a suggestion, and we each need to do what we find most helpful. You are right in saying the format of the event is more important than what we name it, but be cautious about dismissing the power of language, it may be having more of an impact than you realise.
Re facing the clock… I have seen the best results at daily meetings when the team group around the taskboard, actively moving items, asking for help and making offers. With experience the meetings will be kept short, but in the initial stage it is more important to get the spirit of collaboration going than to clock-watch, I reckon.
agree, language matters. but it is also important not only call them differently, but act differently
I am not. If you change the name without the nature, it is intellectually dishonest and stinks of cowardice– you’re throwing words in the way of problems rather than dealing with them.
Whatever new term you come up with will just inherit the connotations of the old, with an added degree of contempt for the transparent sham that is the act renaming. Ever since the rise of Whorfian theory, people have, in good conscience, attempted to rename problems away and it simply does not work.
Furthermore, an attempt to rename something by fiat is a petty act of oppression. It is a small step in the direction of Orwell’s Newspeak. The nobility of your intentions does not matter; what matters is that you’re trying to box in another human’s perceptions by language, without changing the situation they are in.
On the other hand, if you address the root of the problem, the connotation will shift, or a new term will arise from common use. That is when you know you’ve accomplished something. A name change rising from the bottom up in an excellent indication that you’ve dealt with the problem, a name change coming from the top down in a tacit admission that they don’t know how to deal with the problem.
—————
Response (by Tobias Mayer):
> If you change the name without the nature…
Why would you assume that is what’s happening?
> Whatever new term you come up with will just inherit the connotations of the old, with an added degree of contempt for the transparent sham that is the act renaming.
In one company we changed the name “war room” to “team room”. It did change the way people thought about their work, about how they collaborated with business units and other teams. The name change was an aha! moment for some. And when I challenge people’s use of the term “overhead” for Scrum meetings they begin to question their own attitude. Langauge does matter, but I fully agree, changing language to mask dysfunction is dishonest and likely to worsen the situation. Language is not independent of action: they are always linked.
The fact is, the use of the term conversation (and I introduced it again during a training this week) causes people to rethink how they (would like to) interact with others. I don’t care if they actually use the term conversation, continue using ‘meeting’, or come up with a new term of their own. That’s not the important thing. What is important is that we break out of our old patterns of thinking and acting when trying to embrace something like Scrum, which represents a major paradigm shift.
Pingback: links for 2011-03-25 » Wha'Happened?
Well said. I wouldn’t have articulated it better!
Good morning. I was with a group of new managers earlier this week. They are working in a start up environment experiencing rapid business growth. And they are struggling to make the most of the time they have. And meetings are a huge problem for this team. One of the group suggested running meetings standing up as a way of keeping things brief and to the point. I will point them to this discussion so they may continue to expand their learning. And if you or your readers are interested I scribble a short piece about meetings following the time spent with them. The link is here should you wish to take a look.
http://stopdoingdumbthingstocustomers.com/communication/stand-up/
Oh, and I found your article via Terrence Seamon’s Engaging Employees daily paper just in case you are interested.
Cheers – Doug
Thanks Doug, what is the url for the Engaging Employees daily paper? I’d be interested in reading it, and maybe others here would be too. Thanks.
Pingback: Attributes of a High Performing Agile Team « Keith Cerny's Blog
Excellent reframing and you are right about the essential conversations in Scrum – planning, review, (re)alignment and reflection. I also like the term conversation because a conversation can be held anywhere – not just at the office.
Perhaps the reality is that Scrum DOES have too many meetings?
That has certainly been my experience.
Scrum uses meetings filled with many people because it uses an (in my opinion) inefficient planning and other processes.
Instead of Solving the problem (too many meetings) you seem to want to paint over the problem by giving it a catchy name.
This seems intellectually dishonest — just like the Daily Scrum seems like a way of hiding that it is a “Daily Staff Meeting” just like so many others.
What is wrong with honesty in terms of the verbiage and an honest attempt to refine scrum or move on to better methodologies rather than simply putting lipstick on a pig?
Jordan
Hi Jordan,
I think you are misinterpreting my post. I am absolutely not saying keep things as they are and rename them. I agree that would be a band-aid solution. I am saying behave differently. Don’t have meetings have conversations means exactly that. Talk when it is necessary to talk to reach the goal you need to reach (essentially plan, align, reflect) at the appropriate time, with the appropriate people. Dialog and collaboration are essential for the building of innovative products. We need to foster environments where this happens. Scheduling meetings will keep us stuck where we are, while initiating context-appropriate, joyous dialog is likely to move us forward.
If your Scrum planning sessions are “inefficient” and your daily Scrums are “staff meetings” or management status updates, then change what you do. Removing these meetings (when it removes the opportunity for conversation) is actually much more like avoiding the problem. Have the meetings, call them want you want to, and make sure they are effective.
Hi Tobias
You suggest people behave differently. OK, and I think to have them behave differently you have to redefine what the meeting is about.
Take the paradoxical nature of the “Daily Staff Meeting” aka “Scrum”. In this meeting we are supposed to “communicate”, however it is time boxed to 15 minutes. Assume that each person (and we’ll assume 7 persons) speaks for 2 minutes each answering 3 basic questions, 2 of which could be answered simply by looking at the board. That is 14 minutes. That leaves a “whopping” 1 minute for “conversation”. This is a huge waste of time.
The planning sessions, similarly, should not require all team members to be present to spend all day estimating tasks. One person should be able to do that, or one or two people.
It goes on and on.
I think one has to look at the structure of the Scrum process as an imediment that leads to too many meetings attended by too many people. Glossing over it by calling these “conversations” is just that, in my opininon “gloss”.
If you’d like to share your concrete examples of how you’d like to see things be more effective we’d all like to hear that. But simply saying they should be “effective” is not a concrete suggestion.
Jordan, once again if the way you are working is ineffective, then change it. In essence, stop doing stupid stuff. Work smarter. It can be that simple. As to how you should change I have no idea. I am not you, I don’t know your colleagues, I’m not in your environment, I have no idea about your products and have really no knowledge of what you care about.
Your change will come about because you want it to, not because of anything I say or write.
Yes, we can agree on that 🙂
Trust me I don’t base my actions on what the “Pundits” have to say in any area, including this one.
I’m just asking you, since this is a common complaint amongst your clients, what modifications you would recommend in general be made in this area with scrum, or moving beyond scrum, and if you think in general whether Scrum indeed has too many meetings regardless of what they are labeled.
Jordan
Actually, it is not a common complaint amongst my clients, but among people I meet on training courses who are (i.e. claim to be) using Scrum. Clients I consult with tend to take the opportunity in these meetings to have meaningful conversation. I didn’t make this idea up, I see it happening.
I disagree that Scrum has “too many meetings” I think the recommendation of planning, daily check-in, review and retrospective is exactly the right balance. The only one with a hard time-rule is the daily meeting, which is no more than 15 minutes. And as Pauls Boos points out (below) this is simply to learn what further conversations (if any) we need to have to align with one another, and towards the goal, and get our work done effectively.
Re modifications… I generally advise clients that if they feel they are having “too many meetings” to examine the nature of the meetings, and make appropriate improvements, rather than removing the meetings. The latter course of action will quickly undermine any meaningful change. This advice comes from my experience.
Jordan,
The Daily Stand-up Conversation where each person is providing an update to his colleagues is actually a start to follow-up conversations where needed. Suppose I just reported I checked in a class I built last night and for what ever reason another team member had been also working on it. (Or better yet it was a pair of us reporting out and another pair informing us they were working on it….) We now know we need to talk to understand whether we may have impacted each other.
The overall conversation doesn’t have to be time-boxed, but the ceremonial conversation does so it doesn’t waste the entire team’s time.
Tobias, I love the rebrand to conversation and I agree that changing the words can have a powerful effect. Thanks for sharing your thoughts!
Paul
I just thought to share with you guys what we do at my company – and we are naive and new to Agile so we’re quite without any positive or negative feelings about Scrum. We’re just now sipping and getting the taste.
So what’s happened to us is spontaneously we don’t say “meetings,” but rather just say “we’re having a Scrum” or “we’re Scrumming” or “we’re in Solve” (as we use a second 15 minutes for those who wish/need to dive down the rabbit hole of issues to linger behind). Or we’ll say “we’re planning” or “having a retrospective.” We never say “a scrum meeting.”
No one has any real bias against meetings, really, so it just never came up. I am thinking it may be because we wouldn’t qualify the 15 minutes as a proper “meeting.” In talking about Scrum, I call the, um, “meetings” “ceremonies” instead.
The “ceremonies” is something I lifted from some training class I took, no doubt, and pretty much I’m the only one using even that term. The beauty of being new! 🙂
Hi Paul
That may well be true, but my personal feeling is that people should have their conversations as necessary, and not go through a time wasting 15 minute formality just so they can have a discussion afterwards.
Jordan
> a time wasting 15 minute formality…
If this is what happens you may want to look at why.
> people should have their conversations as necessary…
Yes, and this is better achieved if they identify what they need to talk about. Without a whole-team alignment this will be tough, and much may be missed. Remember, we don’t know what we don’t know. The daily team meeting will help us know what we don’t know, and then we can ask for help.
I fear you are falling into the same trap of so many with this “too many meetings” mindset. Which is why I wrote this blog 🙂
Hi Tobias
I feel you are responding with platitudes.Please tell me, what is essential about reporting status, which is 2 out of the 3 questions in this so called necessary “daily scrum?” Why cannot that be done in another fashion?
I am looking at why… that is the essense of my postings. You are merely responding with the status quo — that the scrum are essential in a way you can’t quantify but merely chalk up to your “experience”. This doesn’t seem like agile anarchy — it seems like agile formality with no justification.
What’s the point of ditching meaningless ceremonies like Waterfall and BFUD for new meaningless ceremonies like asking everyone what they did yesterday? Specifics please — not mere platitudes.
Bottom line — Scrum doesn’t trust anyone to do what they say, so they make people report progress like little children and “commit” every day to doing something banal.
Hey if you don’t trust them– fire them. Don’t put them through meaningless ceremonies that most adult and functional teams can easily dispense with or handle in more time efficient fashions.
Jordan: the essence of an empirical process is experience, so don’t be too quick to dismiss it.
The standup meetings are not about reporting status. You are caught up in an old mind-set and way of behaving if that is your experience. The purpose of the standup is for team members to align with one another towards the goal of the sprint (and ultimately towards the goal of the product they are building). The more frequently the alignment takes place, the sooner problems can be surfaced. And then we can act.
I am a believer in the power of circle ceremony to build community and surface difficulties. I see the standup this way. I wonder, do the teams you work on use a physical taskboard? Does the team convene in front of the taskboard daily, move tasks, ask for/offer help, celebrate the small successes? If not, that may be something to consider to change the nature of your standups.
I like the framework of Scrum. It is utterly minimalistic, yet has just enough framework to hold any process the team comes up with in such a way as to create visibility and build strong, collaborative teams. I have never heard a good reason to drop the daily standup, only excuses.
Last point: “Bottom line — Scrum doesn’t trust anyone to do what they say”. Can you see how silly this sentence is? Scrum is a framework, it doesn’t (it cannot) trust or mistrust. People do that. If people don’t trust you in your organization consider what you can do to change that. If you think having a less ceremonious approach will help build trust, then try it. The beauty of Scrum is you get to reflect every couple of weeks to see if the chosen way of doing things produces the desired results. Um, assuming you have retrospectives, of course 😉
The standup meetings are about reporting status; I don’t see how that can be debated.
2 of the 3 questions are about reporting status, and that takes up nearly all of the timeboxed time. Any real communication happens beyond that as outlined above.
By Scrum doesn’t trust anyone…clerly I mean the scrum framework and rituals are strongly geared with the assumption that the project is filled with slackers who need to be constantly monitored on a daily basis…
That’s obvious what I mean here….
I feel perhaps you need warm and fuzzy rituals to start your day — which is not a business function or a value producer. It has nothing to do with software development.
Saying that a room full of people needs to commit to a massive amount of time for essentially a “feel good” exercise that you happen to enjoy, does not seem to be a valid business case for such a meeting… 🙂
Jordan
> The standup meetings are about reporting status
Who is reporting to whom?
> warm and fuzzy rituals… “feel good” exercise…
Okay… when a person reveals this way of thinking, I don’t have anything much to say; it feels like an impasse. I shall let you be, and not try to influence you further.
The comments have drifted a bit from whether to call thistles by another name to a specific practice of Scrum, the Daily Scrum.
For me the main goal of the Daily Scrum is a realignment of how to reach the goal of the current sprint. In case you implement your sprint in a bit of a kanban fashion there isn’t much use for this realignment, you finish in the end what you have finished. That’s not how the original description of Scrum is, from which the Daily Scrum originates.
We have always used it to determine how we can still keep our commitment, and what we can or should do differently. For example, change the scope of the items we’re doing a bit, or team members would agree to do overtime.
I have seen many Daily Scrums that are just done because ‘you have to do them’. And yes, in many of those cases this becomes status reports that are barely interesting for other people. Also, the more people work in silos (each one has their own thing) the less interesting it becomes to listen to others babble about what they were doing. The more people are working as a team, as a group with a common goal, the more interesting it becomes for other members.
I have also seen that it depends a lot on the soft skills of a ScrumMaster – or whoever coaches the team. ScrumMasters who are just asking these questions don’t make the Daily Scrums usefull. Those who pick up subtle questions for help make it extremely usefull.
We have done Daily Scrums with more than 7 people and we always finished within the 15 minutes. For me the 15 minutes is the maximum timeframe before total boredom sets in. That didn’t mean that after the 15 minutes all was done. Whoever wanted to linger around and discuss things that were mentioned in the Dialy Scrum did so.
I have once met a member that felt the Daily Scrum was a status meeting showing distrust in what people were doing. He told me that he was used to do other – very usefull stuff for the organization – in between the lines and that with Scrum he didn’t have a place to hide anymore. That didn’t feel good for him. After a while he experienced that his team members didn’t mind his additional work at all and that changed his perception to one where he felt he was free to tell what he had done in reality.
To me Scrum, or the agile movement in general, puts a lot of trust in people being honest and motivated to do the best thing they are capable of. It is only human that if you are in an environment that is less trustfull it will not work out that way, the distrust is hidden below the communication. Again, a ScrumMaster or coach with good soft skills will sense that. Doesn’t mean that he’ll be able to change that if it is rooted deeply.
What if we think about the Daily Stand-up as our “resetting moment”? A co-located team is constantly having conversations with each other during the day. That dialog is powerful and a good part of moving forward (getting agreement on how you are coding, talking to your tester about tests they are writing, and so on). While the Daily Stand-up includes discussions focused on my activities yesterday, today, and anything slowing me down, the underlying tone is about resetting ourselves as a team. What am I doing that might impact you and is important for me to share with you?
As a former developer, and one that enjoyed working with my team members, I appreciate the rhythm of a daily Scrum/update/conversation, whatever you want to call it. I enjoyed hearing about what everyone else had done, and what they were doing; it was motivating. More importantly, it allowed everyone on the team to know how likely we were to meet our goal at the end of the Sprint.
The thing I haven’t heard anyone mention here is transparency. The most critical point for us about the daily [get-together] was complete transparency into what we had done and what still needed to be done. This allowed us to address problems as soon as they were identified, help people that were struggling with a piece of their work, and communicate with the [Product Owner] in cases where there were risks that might prevent us from achieving our goal.
In previous situations it was far too easy to stay heads-down in my code without paying attention to the world constantly changing around me.
I like communicating with my co-workers, but even I would sometimes get lost in the work and spend days going down a path that ended up being wrong. Having a daily check-in reduced the risk of that happening.
In the end, this isn’t just about software development. It is about the success of a team, of a product, of a company, of a mission. The transparency Scrum provides – partly through Daily Scrums – has benefits far beyond an individual or team. If people can achieve success without transparency, great. Unfortunately I am human, I am not completely transparent by nature, and I sometimes need the tiniest bit of structure to ensure my work is actually helping the team achieve its goal.
Maurice, jhrvy73 and Agile A, thanks for the additional thoughts on the daily Scrum. Some great insights there around transparency, resetting and alignment to goals, surfacing of impediments and discovering new ways of working as a team. When the daily conversation is used as you describe, a lot of interesting ideas and actions are likely to emerge.
I propose an experiment. There will be 4 Teams each of the following classifications:
Team A Holds Daily Scrums.
Team B rubs a lucky rabbits foot every morning.
Team C wears a Trionz arm band.
Team D uses Waterfall.
I would suspect an equal number of “successes” and “failures” for each of the above.
Does Waterfall work? Undoubtedly it does.
Will people holding Daily Scrums find success?
I’m sure they will.
Will the rabbits foot users find success? I’m sure some will.
What does it prove?
Anything can “work”. It doesn’t mean there isn’t a better way.
Additionally Correlation is not Causation (the principle behind this experiment).
Additionally, the fact that “the team” is reporting to “the team” does not change the fact that it’s a status update.
I appreciate everyone’s comments.
Jordan
My prediction is that all
This is where I have to disagree. Jordan, your experiment depends completely on the definition of success.
Often in waterfall success is defined as delivering on-time and on-budget with the defined scope. Success for the team could be an utter failure for the customer if the customer’s needs have changed during development.
An Agile approach allows teams to deal with that reality in a way that waterfall, rabbit’s feet, and even prayer don’t. Are there cases where a serial development approach works? Sure. Dictatorships “succeed” from time-to-time, depending on who you ask. But the industry has moved past thinking that waterfall is a legitimate way to develop most software.
Scrum isn’t the end-all solution for every software team. But it is a pretty good approach for most teams. Are there teams out there that function so well they don’t need even the minimal structure that Scrum offers? There probably are (though I haven’t seen one yet).
Finally, Daily Scrums by themselves won’t make a team succeed. Scrum is a lot like the Toyota Production System in that way. If you aren’t doing it all, you get very little benefit from any individual practices you do implement. Perhaps this is the cause of your discontent, Jordan?
Actually the source of my discontent is that while I view communication as valuable, I see more cohesive and fluid mechanisms of achieving this besides “Daily Scrums”.
Jordan
Jordan:
> I see more cohesive and fluid mechanisms of achieving this
That’s great then. You have found something that helps you. My usual suggestion to people/teams/organizations is this: continue doing what works for you, until it doesn’t… and inspect your practices at regular intervals so you’ll quickly realise when something can be improved. We don’t have to agree on this, nor all do the same thing. Learning from the experience of others is interesting, and sometimes useful, but in the end we have to discover for ourselves within our own context.
Agile A: those are create comments about the meaning of success, and the importance of keeping all the elements of a framework/process/way in balance.
Perhaps I’m missing Jordan’s point, but in my experience the scrum framework has little to do with success; rather it is a relatively efficient heuristic for surfacing opportunities for failure and organizational inefficiencies so that they can be addressed. Two of the most common are the (a) friction caused by even subtle misalignments between team and business and between the teammembers themselves, and (b) lack of communication between teammembers resulting in siloed knowledge and inefficient decisions and coordination.
The iteration demo provides clarity around the goal, the iteration planning meeting creates clarity around the steps to get there, and the daily standup fosters the habit of information hypersaturation through structured conversations. Our teams do one week iterations and still surface misalignment and misunderstandings on a daily basis that would not show up without the daily scrum.
There are certainly methodologies that are more efficient (fewer meetings) than the scrum framework. But once you scale past one, perhaps two developers, both reaseach and practical experience show that efficiency is not the prime driver of effectiveness and can in fact be a detriment.
If someone can provide counterexamples I’m very open to learning about them, however.
Nice Josh, and spot on with the notion that Scrum is about “surfacing opportunities for failure and organizational inefficiencies“. Also thanks for the important reminder that “efficiency is not the prime driver of effectiveness and can in fact be a detriment.” So true!
Personally I don’t see how “Scrum’s purpose about surfacing organizational inefficiencies” makes that much sense.
Any team must work inside the organization unless they have the empowerment to fix it.
Since Scrum has no mechanism to fix these organizational inefficiences, it makes little sense to surface and/or exacerbate them, unless they can also be addressed some how.
These sound more like slogans than practicalities.
If you have examples of how these inefficiences were surfaced and solved, that would be good to hear.
I’m sure Waterfall surfaces many defenciences, as well, and neither Waterfall nor Scrum have the innate power to solve them.
Of course, if the Waterfall teams were empowered as much as Scrum teams claim to want/need to be empowered (“Complete Buy in from Top Down”) any methodology could be successful.
A methodology, especially a development one, is something that should solve software development issues…. not psychoanalze the business process or the team members.
Although those things may be useful they are independent of and tertiary to, developing software.
Additionally, on the subject of Scrum’s necessity for “complete buy in”…. I really don’t think a 100,000 person company needs to change their entire culture just to suit the whims of a few web developers that want to use Scrum.
But hey, one can always dream 🙂
Jordan
Hi Jordan,
this conversation has gone rather beyond the intended scope of this blog post. You seem determined to prove Scrum is flawed, and all those that practice it are somehow deluded; there is not much to say in response to that. Maybe a post on your blog to describe the perceived inadequacies of Scrum and its practitioners would be appropriate at this point. Feel free to post the blog url here if you do that, and thanks for your comments over the past few days.
Tobias
A daily scrum is a “boot” of the day. It spawns lots of issues etc that fill the day with work. The team do it for themselves.
To boot, the team need to know where each other is, so they can respond to the issues as a team. The issues are dealt with outside the Scrum.
Jordan seems mightly confused about two things – One, it’s a 15 minute timebox maximum not minimum, and it is not the only form of conversation – Just the formalised, setting the stage of the day for the team by the team.
A very famous human pattern by the way – Scrum didn’t invent it.
BTW, it’s obvious the “Jordan” is trolling for effect. The Straw men arguments he is building are very obviously logically flawed from top to bottom.
His arguing that Scrum has no method for dealing with Obstacles? What about the ObstacleDealer, change agent themselves.. the ScrumMaster? Where in a Waterfall model do we handle obstacles? Does he understand that Scrum is NOT a methodology, but a framework, a Skeleton, where you add your own best practice? Does he appreciate all the work done in rolling out Scrum via a evolutionary model and the associated work drawn from Kotter – The lead expert on change? Thinking that the daily Scrum is the only time for a team to communicate? His comparison of the DS to a variety of childish insults, whilst not looking into Sutherlands work and his description of why the DS was chosen (The Borland Quattro Pro Team used it IIRC) for Scrum and the associated performance improvement he saw and measured. Also how the DS is one of the many parts of Scrum that can be called “Subtle Pressure Systems” that encourage a little intensity in a team to catalyze Self organization… but since Jordan doesn’t believe in the “human” parts of Scrum, I guess we should all pack our bags and start writing more coding standard documentation into Scrum…. Which of course you can do if you need to – As Scrum is a FRAMEWORK to allow YOU to what you NEED to do to deliver successfully.
Cliff Notes:
Jordan doesn’t understand the principles behind Scrum, the roles within Scrum, Scrum and change management, the metrics behind Scrum. Yet feels free to throw himself around in a conversation on Scrum.
Hi Nigel
1) You don’t seem to have read my postings all that much, try again
2) Whether it’s a “Framework” or not is the subject of much debate (scrumbuts). In any case one could say Waterfall is a framework
3) My arguments are not straw nor are they trolling
4) Quattro Pro? Something from the 80s is relevant to today?
Tobias:
Sorry that the thread went off topic, but I was commenting on the Daily Scrum as glorified daily status meeting, which as even Nigel points out, is not a new phonmenon.
But comments that “the daily scrum isn’t a status meetings, it’s a way of surfacing organizational dysfunction!” led me to my comments regarding that aspect of scrum.
Honestly, I’d really like to see even ONE concrete example of how a Scrum Master can solve impediments OUTSIDE of the team.
Any methodology can and does solve impediments within the team.
Scrum posits that they solve ORGANIZATIONAL dysfunction, not merely team dysfunction, and I think if people are going to say it they should have concrete proof of how that aspect works (solving “dysfunction” outside of the team).
Thanks
Jordan
Jordan, I have no interest in trying to prove anything to you. I am not in the business of selling Scrum. I simply practice it. I often find when a person is constantly asking “how” or saying “prove it” they are not in a learning space. If you truly want to learn about Scrum, do Scrum. If you feel you have done Scrum and it failed you, and you have no interest in trying again differently, or you are firmly convinced that Scum doesn’t work, then we have no topic of conversation here. You see?
I’m not saying that you have to prove anything and I’m glad you aren’t trying to sell Scrum. However, I assume that here there are people that do Scrum, and believe in this removing of organizational dysfunction thing, and so purely as part of my research, to be as fair as possible to the process without blasting it unnecessarily.
I find when people ask “how” or “prove it” they are in a scientific space. That is a space that we should all be in. People should also make claims without proof. Perhaps you never claimed that Scrum surfaces/solves “organizational dysfunction” and therefore feel no need to prove it.
I basically see Scrum as a reactionary emotional response that is not founded in science. However you and Mike Cohn, along with a handful of others tend to be more scientific minded so I thought you or some of your readers might have some insight into that area.
Jordan
> I basically see Scrum as a reactionary emotional response that is not founded in science.
Okay. Like I said I have no comment or opinion on this train of thought. If you can’t let it go then maybe you can write something on your own blog to advance this discussion. It clearly matters to you, but your continuing to press on with it here is beginning to feel like a hijacking. So please, stop now. Thanks.
I’m happy to advance the discussion in the appropriate forum.
I invite yourself and your readers to view my thoughts and make enlightening comments at http://jordanbortz.wordpress.com
Jordan
The team should choose its representative based on who will be in the best position to understand and comment on the issues most likely to arise at that time during a project. Ken Schwaber has suggested that these meetings should occur daily just like the daily standup or daily scrum.
Pingback: ITGIF – “IT-God” It’s Friday #23
Pingback: Stop Having Scrum Meetings? | Agile Scout
Pingback: Refactoring the Scrum Lexicon | Post Agilist