Building self-organizing teams is not a cake walk
Agile philosophy puts a lot of emphasis on self-organized teams that can build great quality products and services. Self-organization is one of the core attributes of agile teams or if I dare to say, is at the heart of agile project management. Self-organized teams are supposed to be self-contained and have required skills that works towards a shared vision. They don't need directions (read command and control) and can figure out on their how to best deliver results. A lot of literature can be found around self-organization.
In spite of wide knowledge and information around this topic, it would be interesting to know how many organizations have actually managed to create such teams. How many 'Spotify' case studies are around? In my opinion and experience, I think building self-organizing teams is easier said than done. While it’s a very good intent but there are lot of challenges that drags creation of such teams. For creating a mouthwatering dish, just like you will need right ingredients and in right quantity, same goes for creating a self-organized team. Unless you have all ingredients, such as, management commitment, an individual's willingness & attitude, infrastructure and operations, supporting groups, an organization's culture, etc. in place, it is difficult to have self-organized teams that can run like a well-oiled machine.
In this session, I will share some of my experiences with such teams, their behavior pattern, how such teams can be nurtured, some successful and some not so successful attempts.
Outline/structure of the Session
- Why it is difficult to have self-organized teams?
- What makes or breaks them?
- How to sustain self organized teams?
Following key takeaways can be expected:
1. Know the indicators of a self-organized teams
2. Distinguishing characters of a self-organized and not so self organized team
3. What is role of each stakeholder in such teams
Scrum Masters, Scrum teams, project managers
schedule Submitted 1 year ago
People who liked this proposal, also liked:
Why Businesses should not ignore Technical Debt - A Case StudyAshish Pathak
schedule 1 year agoSold Out!
Cases like the Toyota’s Unintended Acceleration case of 2007 highlight the impact of bad engineering practices on the quality of the product. This eventually impacts the business and the organization’s reputation as well. There have been several such instances in recent history, yet business stakeholders get tempted to compromise on the sound engineering practices for having quick gains. This approach, most of the times, is due to lack of understanding of these practices and under-estimating their negative impact in the long run. The aim of this paper is to highlight this impact and present a strong case for paying enough focus on concept like technical debt to reduce and control it in software development context.