Scrum is not enough to revolutionize workplaces
By Bachan Anand / Filed under Agile, Collaboration, Scrum, Self Organization, WORK is GOOD / January 31st, 2012
How many of you have come across the adage, “We cannot solve a problem with the mind that created it”? If we look at a team, everything that is working (or not working) is due to the system and process – way of working – that was created by the collective minds of the company: the team members and the minds needed to create a product (may include the customer). Very often, it is difficult for those involved to objectively determine WHAT in the system is not working and WHY it is not doing so (and thus the adage, “We cannot solve a problem with the mind that created it”). This is why new mindsets like Scrum are introduced: so that they can objectively identify the inherent problems and loopholes in the system and propose appropriate solutions.
Scrum provides a clear framework for people to identify and articulate problems so that they can be solved. It creates a new approach to team work, product development, and organizational interaction; facets that have their foundation in Empiricism, Focus, Self-Organization, Collaboration, and Rhythm. Once we introduce this mindset to the team and the organization, the existing problems in the company show up and they do so with greater clarity so that the very people who created the system can now change it. So, the power is not with Scrum, but with the people. What Scrum does is that it gives them a new set of foundations and practices to grow, learn, and change their work environment for the better. For me, THIS is the gift of Scrum!
And yet, along my Scrum journey, working with varied teams and using Scrum at home, I have started wondering whether we need a greater change in the workplace itself. This is because I find that some people-related problems are a major cause for apathy and inefficiency at the work place. Some of these problems are: Employees not having a share in the input of the company’s vision (thereby making them feel isolated from the decision-makers), staff feeling no responsibility for the growth of the company (“why should I bother when I have no stake in it?”), and individuals not having the liberty to choose whom they want to work with.
Here are the areas where I believe a new approach to work would be beneficial in creating a truly liberating and creative work environment:
- Each person in a team has input and ownership of the VISION, instead of the vision being owned by one person: COLLECTIVE VISION.
- Financial ownership is in proportion to the effort and the ownership each person has on a team: CO-OWNING.
- Team members choose whom they want to work with through a democratic process: SELF-FORMING.
Could this be the next step in the evolution of work from slavery, supervisors, managers, and micro-managers? Perhaps this is the next step to Interdependent Work Places, so that WORK is GOOD!
What would be a good name for such work-environments? “COLLABORATIVES”? “THE ART of WORKING”?
What if we leave it unnamed it so that it grows into whatever it wants to become…
The Season for Scrum
By Lisa / Filed under Agile, Scrum / December 31st, 2011
My father has been retired for 25 years, but he is always very interested in hearing about the professional challenges I face, and the way that some of these issues are finally resolved by organizations. One of the comments I make to him is that I learn from Bachan every time I am with him, which is a rich reward to get out of a professional partnership. Bachan has shared feedback with me that I sometimes tell to our internal team “how”, rather than allowing team members to find their own solutions. So I have been trying to keep quiet more often, allowing the team to self-organize. This year I had the opportunity to work with my neighbors on an event and continue my Scrum practice.
My neighborhood has been planning a “Progressive Dinner”, where four families each host a different course, and the rest of the neighbors bring something to their chosen course. My part in the planning was to send out the email communications to the neighbors (plus I made Eclairs for the dessert committee). It turned out that everyone started funneling all of their communications through me. We eventually adapted our communication practice, as a result of a suggestion from another neighbor that we “Reply to All”, and I was taken out of the center of the communications (thank goodness!).
My dad (also my neighbor) called me many times a day during the week preceding the dinner asking me to help “fix” some of the issues that had arisen. I think he would have liked to shake me a few times, because each time he called, I gave him a typical Bachan response, which was, “Have you talked to your committee? What does your team think?” My father worked his entire career based on “work orders”, was very accustomed to following instructions to the last detail, and enjoyed the recognition he received for completing orders. When I robbed him of the opportunity to follow through on an instruction, he was irritated, disappointed, and more than a little disoriented with my approach.
During one of these conversations when he was getting particularly annoyed, I asked him, “Well, do you want to practice Scrum or not?” Of course he had never agreed to practice Scrum, and his expression was priceless when he realized why I was being “difficult”; at that moment he began to appreciate the stories I tell him at the end of the day. When I saw my father’s reaction to what I was saying, I felt a pang of empathy for some of the people who have undertaken the task of implementing Scrum in the workplace. To commit to such an undertaking takes a lot of trust, courage, and commitment to keep trying again and again, until the new way of working delivers the results they have been hoping for since the beginning.
So we had the Progressive Dinner last weekend; we had more than 40 people, and everyone seemed to enjoy themselves. I will have to turn the screws just one more time, while our frustrations and celebration are still fresh, and do a virtual Retrospective with the “Perfection Game”, so we can remember what would have made our event Perfect, for next year!
The Micromanagement ‘Disease’
By Lalita / Filed under Agile, Scrum / December 6th, 2011
Definition:
Micromanagement is when a manager excessively monitors every little aspect of their subordinates’ work, thereby making those workers feel that the boss is ‘breathing down their necks’. The ‘control freak’ manager gets irritated when a subordinate makes decisions without consulting them even if those decisions are totally within that subordinate’s level of authority.1
“For software engineering, in particular, micromanagement is especially pathological, and can be devastating to the enterprise.” 2 Firstly, this is because programming involves solving problems and software engineers would prefer to choose the methodology for solving those problems. If they were instructed to just type out the code, their creativity and autonomy would be stifled, thereby encouraging them to seek employment elsewhere.2
Secondly, programming is a very complex and dynamic experience. Very often, a newer and better understanding of the problem renders modification to the code. “Managers don’t have time to internalize the amount of knowledge needed to execute on the engineering side in such a complex, changing environment.”2
Despite this, there is a tendency for managers of large software firms to micromanage, as the company code base becomes larger and the risk to the company grows.2
Symptoms observed in the subordinates:
- The employees have begun realizing that the manager is not listening to their feedback. So, they begin to shut down and they stop making suggestions or being straightforward with them.3
- Disengagement—They do the basic work and that’s about it; they are no longer willing to go the extra mile for the benefit of the company.3
-
Their apathy is contagious, thereby decreasing the overall productivity of other colleagues as well.3
Symptoms observed in the micromanagers:
- Micromanagers supervise or control every single task performed, regardless of its complexity or the workers’ familiarity with that task.
- They do not trust or believe in others’ capabilities.
- Micromanagers compulsively oversee the work of high-performing as well as poorly-performing employees.
Prognosis (what the future for those suffering from the micromanagement ‘disease’ looks like):
-
“Micromanagement stifles manager–employee:
-communication,
-creativity,
-productivity,
-problem-solving,
-flexibility,
-trust,
-feedback,
-interest, and
-openness.”3 -
It also adversely affects company growth and goal attainment.3
-
Due to excessive micromanagement, the company may lose many of its talented employees to other companies.
Treatment:
With the help of Scrum/Agile philosophy, the manager shifts from being a ‘controller’ to that of an ‘enabler’ who establishes priorities and eliminates impediments as they are identified.4
In contrast, the subordinates change from being ‘individuals reporting to bosses’ to ‘members of an accountable, self-organising team’ that works in short cycles without any managerial interference.4
“Scrum is an effective way for managers to:
-
iteratively evaluate features in development,
-
to prioritize the next batches of work, and
-
to manage the feature backlog.”2
However, there are some software professionals who feel that Scrum methodology like the Daily Stand-up, is actually synonymous with micromanagement. In defence of Scrum values, micromanagement refers to overly detailed management by the administration (and not the team). “While the team micromanages its every day actions on a daily basis, the administration micromanages the release content on the iteration level.”5
While writing software programs, bugs are often encountered and appropriate solutions to those bugs are devised. So, it makes immense sense that the team has a Daily Stand-up, thereby enabling it to discuss possible problems and improvements to the software program. Therefore, “when the team discusses their daily tasks, they are micromanaging for the benefit of the team and the organization as a whole.”5
Endnotes
1 “Self-Organisation and Transparency: Team Freedom or a Path to Micro-Management,” Give Thanks For Scrum 2011 Transparency and Micromanagement, accessed November 29, 2011, http://www.slideshare.net/dlefebvre1701/give-thanks-for-scrum-2011-transparency-and-micromanagement.
2 John Umbaugh, “Micromanagement in the Software Engineering Industry,” Yahoo Voices, accessed November 29, 2011, http://voices.yahoo.com/micromanagement-software-engineering-industry-6631104.html.
3 Kenneth E. Fracaro, “The Consequences of Micromanaging,” Contract Management July 2007: 4-8, accessed November 29, 2011, http://www.ncmahq.org/files/Articles/ECB0A_CM0707_C01.pdf.
4 Steve Denning, “Six Common Mistakes That Salesforce.com Didn’t Make,” Forbes, April 18, 2011, accessed December 01, 2011, http://www.forbes.com/sites/stevedenning/2011/04/18/six-common-mistakes-that-salesforce-com-didnt-make/.
5 Vikas Hazrati, “Agile is Micromanagement,” Info Q, November 10, 2009, accessed December 01, 2011, http://www.infoq.com/news/2009/11/agile-micromanagement.
10 challenges faced by distributed teams
By Jeena / Filed under Agile, Collaboration, Scrum, Self Organization / October 18th, 2011
A few weeks ago we posted a blog on how our team at Conscires manages to effectively synchronize between different people in different locations. We are constantly striving to improve the way we work, by understanding the challenges we face as a team, and trying to resolve them.
This post summarizes the issues faced by distributed teams when working towards a common goal.
1. Without regular (as far as possible, daily) communication, it is easy to misunderstand what another team member is doing and miss important things. This could lead to the team going out of sync and not discovering it in time.
2. For a distributed team, connectivity is of utmost importance. Issues like power supply failure, Internet connectivity problems, login failures etc. could lead to a lot of time being wasted during meetings / discussions.
3. When the team members are based in different timezones, the overlap may be very thin. Hence, some or the other team member may be required to make compromises on personal time.
4. When communication happens through email exchanges, the action items or discussion points may get lost if not properly maintained and recorded. This is true even with a local team, but is more pronounced in distributed teams. Without face-to-face interaction, the chances of vital information and/or creativity getting lost in translation is very high.
5. Establishing rapport with team members one has never ‘met’ could take time and may give rise to a feeling of distance between them. This could lead to hesitation in discussions, hindering open and free communication that is essential for the team to function well.
6. When working with or learning new tools, a person isolated from his team may hit roadblocks and find it difficult to get help. Similarly, it might not be as easy to provide training to a remote team member as it is to one sitting nearby, even with technologies like remote desktop access, screen sharing etc.
7. Pairing for a task over the Internet is not as easy as when two people are seated side by side.
8. Maintaining a remote team to work together could be expensive because of the technical & human resources required to keep them in sync, motivated and up-to-date. For example, without effective version control system, project/defect tracking tools, conference call/chat softwares, multiple team leads for different locations etc., the team could lose its way.
9. It’s difficult enough to try to carry on teamwork and business across oceans when all participants share the same language and cultural norms, but add language and cultural differences into the mix and there is potential for miscommunication and misunderstanding (and sometimes comic relief!) when teams work together virtually.
10. Distributed teams don’t get much face time with the leadership of the organization or team, and may feel left out and become unmotivated if leadership doesn’t continuously integrate offshore teams into core business culture, activities, and initiatives.
What other issues could arise in distributed teams? Do you have experiences with distributed teams that you would like to share with us?
(With inputs from Neeta Singh, Vanessa Brown, Lisa Montano, Indu Menon, Bachan Anand and Edith Alizadeh.)
How Agile & Scrum contribute to Team Morale
By Bachan Anand / Filed under Agile, Collaboration, Inspect & Adapt, Scrum, Self Organization, WORK is GOOD / September 28th, 2011
How has using Scrum and Agile as framework helped team work and morale of team members?
We asked this queston to other Agilists on Linkedin.com, and received some profound views and interesting perspectives. We think the readers of our blog could benefit from these insights.
Here are the extracts from the discussion.
1. Nothing helps morale and teamwork like success.
2. The Agile framework has unknown details that keep the team excited about the challenges ahead. The scrum meetings, prioritization and changes add a lot of dynamics to the discussions and keep the progress live and happening. Quick iterations of requirement-development- review-closure cycle and client involvement in each of them keep the adrenalin flow high all through.
3. Project Management team has no option but to share all the contract details of the project, so the team is bound to be highly motivated and involved both individually and as a team.
4. Agile approaches treat each team member with respect. This can be a really big positive change and has a wonderful effect on morale.
5. Some team members view the Agile approach with trepidation; there’s no longer a place to hide. Without the ‘respect’ aspect, that ‘nowhere to hide‘ can be disastrous to the team morale.
6. If things get done right, the effect is very positive. But it can all go bad for the want of a bit of real knowledge about Agile approaches.
7. The autonomy given to the team becomes a significant and ongoing reward for their efforts. Autonomy is something only more senior positions offer in many situations; having such choices and freedom is a major enhancement of morale, if the team members have the courage to use it.
8. Communication!
- Increased alignment and communication between customer and team members
- Transition in role of PM to running interference and reduction in unnecessary artifacts should increase productivity
- Daily information exchange between key players should cut down on expectation gaps and result in timely issue resolution or escalation
- Focus on objective/quantitative progress & velocity reporting metrics should create a “level-playing field”
- Retrospectives & regular refactoring of methods should translate into better productivity and less firefighting
9. Collaboration!
- The team is self-organizing! This help the morale.
- The team can see results quickly and have feedback from customers: that’s also a great benefit for developers
- Testers and developers work together, which usually, at least long term, reduces bugs and helps to spot problems earlier, which makes problems less painful to solve and reduces their impact.
- The full team delivers together, which increases team building and collaboration, and usually people are ready to help each other and share their knowledge.
- Finally, if scrum is well implemented, it allows to reduce the number of meetings (especially the useless ones).
10. The customer is engaged continually in what is being produced, which means that there are no surprises in that regard.
Can you add to this list, from your own experiences?
Contributions by Owen Jay Murphy, Praveen Kumar Kambhampati, Paul Oldfield, Gareth Blake-Coggins, Bernard Kahn, Kiron Bondale, Lorenzo Granai, Chris Browne. You can read the entire discussion here.
