Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Vikas Hazrati on May 06, 2009
The daily scrum is an important meeting within the Agile team. During this 15 minute session, the team members share their commitments along with the impediments blocking them from moving forward. According to Scrum, only the committed team members (pigs) are allowed to speak during these meetings. Other interested people (chickens) can join in, but they should just listen. Is there a limit on the maximum number of chickens, who could attend the daily scrums? An interesting discussion on the Scrum Development group tries to answer this question.
Jason Plante started the discussion when he mentioned that during his daily scrum with a typical team of 5-6 members, there are 4-5 managers attending the meeting. According to him, this causes concern and discomfort within the team.
Peter Stevens shared the concern and added,
The purpose of the Daily Scrum is for the teams to self organize, not to inform Stakeholders. If the chickens are making the team uncomfortable, I would politely un-invite the managers. Probably that's an all or none proposition, and the diplomatic skills of the ScrumMaster must rise to the occasion!
Roy Morien suggested that the team should try to explain the situation to the managers. If the managers still do not understand then the team might try to stage a scrum meeting for the managers and have the real one later, as a survival tactic. To this Ron Jeffries replied that though staging the meeting is a possibility, however usually he found survival tactics as a poor refuge. It further deteriorates the trust between the manager and the team.
Majkic Sensei also reiterated the need to have an open and honest communication. According to him,
I would make one meeting for managers, and would frankly say: "Developers are feeling uncomfortable with such a big number of chickens on daily scrum. They feel being micromanaged and this ruins agile spirit and agile benefits. This will harm the project." I would invite them to Scrum Demo meetings, where they could stay in touch with developers.
Some members on the group suggested getting to the facts. Questions were mainly grouped into two categories. The reasons for the managers to be a part of the daily scrum and the reasons for the team to feel uncomfortable in their presence.
Luke Visser replied with the perspective from the manager’s end. According to him, the ratio of managers to team members can range from 1:2 to 1:5. Further, he highlighted the stake that the managers have on the project.
You'd be surprised how much a CEO/MD actually has a stake in your project. Especially if the money for the project is coming directly from his/her pocket. Kind of makes the chicken/pig analogy mute.
According to him, most of the times, managers come to know about the project status by hearsay. Attending the daily standup gives them an opportunity to come up to speed faster with facts. They can also be instrumental in removing the impediments as soon as they hear them thus making the job of a scrum master much easier.
Roy Morien added his opinion from the perspective of the team. According to him, having the chickens as a part of the daily scrum boils down to the managerial culture of the organization irrespective of the number of chickens.
If the managerial culture is a supportive, encouraging, mentoring type culture, then having the managers there can be beneficial. Part of this culture is a feeling of freedom to admit mistakes, shortcomings, and seek team assistance to overcome this.
The opposite situation is one that is unfortunately more prevalent, and that is a management culture of control, discipline, blame, where it is just not a good idea to admit mistakes or problems in front of the managers - especially if some of those problems arise because of the actions and decisions of those same managers. I have experienced this 'toxic' environment and learned quite soon to shut up when a particular manager was there mainly to note the shortcomings of everyone, rather than to become aware of their successes.
Thus majority of the group agreed that, more than the number of chickens in the daily scrum, it was the culture which was important. The key lies in building a culture of trust and positive energy where the team can easily conduct the daily scrum without feeling unduly intimidated or controlled.
Learning to be a Good Product Owner: Foundation Skills
Technical Debt and Design Death
All this rhetoric about the culture and the benefits of managers at the scrum meeting misses the crucial aspect of the opening issue, The manager dev ration is almost 1:1. Do that many managers need daily updates? If so, perhaps they could do the work themselves. That would give them even more up to date info!
Jeff
While I get the metaphor, are people really using this with managers?
Quote:
I would make one meeting for managers, and would frankly say: "Developers are feeling uncomfortable with such a big number of chickens on daily scrum.
It just seems so silly to take a metaphor that far.
Actually yes. I've seen it used in many, many situations.
This meeting is about communication. Sure the primary focus is the team and the ScrumMaster / Agile Facilitator MUST keep it on track and guard the team's time. However I have often seen critical issues be raised as a result of the conversation. Are we doing the right thing today? Did you consider the <fill in the persona>? That won't work because ...
It is all about learning. Learning about the problem, the users and the proposed solution.
Rod Claar
twitter.com/agile_coach
rod-claar.net
www.EffectiveAgileDev.com</fill>
If it's a mere issue of project visibility then perhaps having the right communications strategy (e.g. once a week project status reporting) or even having a tool for project management would address it significantly.
As was mentioned in the thread, I think attending the scrum meetings is already a level too low (not hierarchy-wise but functional-wise) for managers that it might appear to be a case of micro-managing. It might be more counter-productive than it was intended to be.
Perhaps, time-to-time visits can be accomodated but not regular attendance.
At one large organization where I coached/trained 5 Scrum teams over many months, the "too many chickens at the daily Scrum" was handled by having the Scrummasters meet with next level (or two) of management for ~1/2 hour after the morning Scrums. Their they reported the overall status on Story progress and raised impediments to management that they felt rtequired work/support outside the teams.
This seemed to keep management satisfied that they knew what was going on and actually made them feel the time was better spent than had they tried to listen to all the "reporting" at the Scrums. Also, it mean they all heard about the status of all the teams since the Scrums all happened about the same time each morning, making it impossible for managers to attend all the Scrums anyway.
This was not a true Scrum of Scrums. The Scrummasters and team members could be in close contact all day as, in this particular company, their team rooms were all within ~30' of one another in a special section of the building.
The Scrummasters and I also had a 1:30pm time slot of ~30 minutes allocated each day for us to talk about general Scrummastering/team/management issues. We did not always use the time (probably 3 out of 5 days) and not all 5 Scrummasters always attended). But it was accounted for and they knew they could make use of it.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
6 comments
Watch Thread Reply