The content has been bookmarked!
There was an error bookmarking this content! Please retry.
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.
Transforming Software Delivery: An IBM Rational Case Study
A Guide to Branching and Merging Patterns
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
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.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
6 comments
Watch Thread Reply