8. So really, why agile teams should be self organized… Agile software development teams need to respond to feedback quickly and deliver quality software in very short time intervals Self organization fosters: Adaptability Collective ownership Automatic course correction Quicker decision making Leading to: Quicker delivery of working software
Self organization is deemed to be a fundamental attribute of Agile teams. However, successful self organization needs a lot of support from not only the team members but also the management and the organizational environment. In order to help the team move towards self organization, the right level of management involvement is required.
Physicists have been studying the remarkable process of how a flock of birds moves flawlessly as an organized group, even if the individual birds make frequent misjudgments. If a bird in a flock makes an error in the direction it should travel, it will tend to swerve side-to-side rapidly. You might think this error in judgment would overwhelm the other birds, causing the flock to become disoriented and fly apart very quickly. But this process actually helps keep these misjudgments under control, by quickly spreading the error among many birds so that it becomes very diluted. At one instant the erring bird might be on the left side of the flock (1), and the error affects its neighbors that are on the left side. But the next instant, the bird may be in the middle of the flock (2) -(3), and the error influences its new neighbors over there. A moment later, and the bird is on the right hand side, and it spreads to its neighbors there. As a result, the error is quickly shared among many birds and it is diluted before it has a real chance to affect the direction of a flock. At the same time the bird looks to its neighbors, which are travelling in the correct direction, and has an opportunity to straighten itself out. Self-organization is a process of attraction and repulsion by whicha system, normally an open system, becomes more organized without being guided or managed by an outside source.Self-organization comes from complexity science and the theory of complex adaptive systems (CAS). A system is "self-organizing" if, left to its own devices, it tends to become more organized over time.
1.Less oversight allows teams to adapt quickly to the changing needs2. Lack of hierarchy helps the team to form the right subteams to tackle the problem at handAn "agile team" is (supposed to be) a self-organizing team that is guided by the agile values and agile principles (given by the agile manifesto) and is supported by a trusting and empowering style of management. With management supporting their agile values/principles, Agile teams "self-organize" to collectively decide and do what is needed in order to: make and meet commitmentsdevelop a quality productrespond to feedbackand adapt to changes
The project environment involved an extremely complex technology stack. The requirements were extremely high level, poorly understood even within the product owner group. A combination of hazy requirements and complex technology were a perfect recipe for anarchy!
The project environment involved an extremely complex technology stack. The requirements were extremely high level, poorly understood even within the product owner group. A combination of hazy requirements and complex technology were a perfect recipe for anarchy!
The business analysts are the gatekeepers for the team. They play a critical role in building respect for the team with the business. When the business analysts have no boundaries to work against, one of the first symptoms is gold plating. The requirements are padded with additional, unnecessary features. Delivering these features takes away valuable development and testing time, which can be used to deliver core features earlier.
When the business analysts have no boundaries to work against, another symptom is scope explosion. Every request from a product owner is entertained. More and more requirements get added to the backlog without any attention to the priority or the impact. This can have a devastating impact on the project schedule if unchecked
When the different roles do not work together, it manifests itself in the form of bottlenecks in the story pipeline. If the analysts are busy adding unnecessary features in stories, they won’t be able to keep pace with development. If developers are trying to develop the utopian codebase, they will slip on story development. If the testers don’t understand the features completely, or are spending too much time with testing unnecessary things, then QA will become a bottleneck
Each developer can write code that fits in their perspective of good design, and with their choices of technologies. When it all comes together, it would pretty much be like a bridge who’s two ends just don’t meet
Requirements might be too non developer friendly or too gold-plated to develop correctly. Alternately developers might write code which is technically great but functionally not so great. These factors produce a lot of defects in the resulting software
Explain the term hangover. Since everyone is the team is working on their version of utopia (or nothing at all), the committed stories in the iteration don’t get completed iteration after iteration resulting in persistent hangover
Everyone is pursuing their own agenda. Cliques form within the team. Relationship with external stakeholders often are adversarial and defensive
In a true self managed teams, meetings would be minimal because the team resolves most matters with adhoc conversations and regular communication. In an anarchical environment, there is more use of formal meetings. Meetings tend to have a large group of participants, long and unproductive.
If developers do not work closely with the testing team and throw things over the wall for testing, then the QA team often doesn’t know what to test and how much to test. Poorly written or hard to understand stories add to the problem. This results in poorly tested stories that will lead to a lot of defects later.
Since everyone does their bit around a story, there is no joint ownership
At the start of every iteration, the team reflects together on the successes and improvement areas of the last iteration in the retrospective. The team identifies pluses and minuses, and votes on the most important items to work on in the next iteration. This helps foster a common ownership of the project and prevents finger pointing. In iteration planning, the team looks at the prioritized backlog of work and picks the next set of stories to work on. Everyone can give their input, raise issues/concerns and sign up for the work they want to commit to.
Standups are a daily affair where the team members share what they are working on, their blockers and impediments if any. They help keep the team focused on stuff relevant to the project, and are an effective forum to foster better communication and shared responsibility in the team. Talk about some real examples of how standups help
Even the best run team will fail if not staffed with the right people
Metrics must be transparentShould be displayed publicly and easily accessible to allDemos/showcases should be conducted periodically so that the team can share their progress and collectively work on the feedback received
The Project Manager is not a coach/facilitator, but an integral part of the team and personally responsible for the team’s successHe removes barriers and impedimentsHe is a servant leader with direct authority who leads and serves the team to achieve their goalsHe shields the team from external disruptionsHe represents the team’s best interests to the outside world and promote the teamHe is not manipulative and maintains full transparency with both sidesHe define boundaries for decision making He tolerates mistakes and helps the team to learn from themHighlight the extent to which the responsibilities of the SM are different from those of a PMSM:Is responsible for making sure that all the pieces of the Scrum process come together and work as a wholeAuthority of SM is largely indirectEnsures the team follow the Scrum rules and practicesIs responsible for the success of the projectEarns no awards or medals bc SM is only a facilitatorExamples of SM:Remove the barriers/impedimentsImprove the lives and productivity of the team Improve the engineering practices PM: Not the coach/facilitator, is part of the teamServant leadership with direct authority – LEAD and serve their team to achieve their goalsHas the authority and powerLead/make the decisionsIf project fails, it is PM’s fault – first in the lineFocus on preventing problems, not to deal with problemsClearly define the boundaries – Without this the team is lost on how much they can manage themselves and when should they invoke management help. Without the definition of boundaries, teams err on side of caution and do not take any decision without seeking permission.Tolerate mistakes and allow time for learning – management should not jump in at the first problem. They should allow the team to learn from their mistakes and take corrective action on their own.Keep the team challenged, yet not frustrated- The manager should be aware of the team’s skill level and limitations. He should be able to provide the team with enough challenges to keep them in a state of learning and growthA study done a few years on the successful model of self managing teams, placed a lot of emphasis on the balanced involvement of management with the team. The right balance allowed the teams to flourish in their decision making and problem solving capabilities. -Absentee Managers – who would not step in at all irrespective of whether the team has all the necessary skills to tackle the problem.
![Agenda ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)