Product Backlog Flows

There are plenty of discussions in the agile community about how agile teams work and develop over time. Often neglected or poorly understood is how that work makes its way from the customer to the team. Below is a blueprint for creating an effective and efficient flow of work. I’ve included details but also left it flexible enough to be customized for your company’s specific circumstances.

- See more at: http://pragmaticmarketing.com/resources/product-backlog-flows#sthash.7ZvUkYFt.dpuf

Tweet

Self-Organizing Development Team

Definitions

·        Self-organizing teams are composed of individuals who manage their own work, pick up work based on need, and participate in team decision making.

·        Self-organizing teams must have a common focus, mutual trust, and respect.

By being self-organizing and self-managing, the team brings decision making to the level of the problem. This increases the speed and accuracy of problem solving.

Self-organizing and the Scrum Framework

The Scrum Guide gives the Scrum Master the role of coaching the Development Team in self-organization but doesn't provide insight or guide as how this is accomplished. So …

Tips For Management, Agile Coach, and Scrum Master to organize a team toward self-organization

·       Management (yes, management) must establish any parameters that the scrum team is required to work within. For example, usually only managers can hire and fire people. Otherwise, management should ensure they don’t get in the team’s way. Managers need to support the scrum teams rather than be a distraction.

·       Give a scrum team room enough to fail in order to allow them to succeed. Managers must not ‘step in’ every time they perceive the team is on the wrong track. The team may very well be on the wrong track but there are several inspect & adapt opportunities for the scrum team to correct itself. This is the big reason sprints are short, no more than 30 days, and most often 1 or 2-weeks long. I've seen a development team start a sprint, go down the wrong architectural path, discover it, do a re-design, re-do work they had already done, and still meet the sprint goal. True story. However, the chief architect had chewed his nails down to the knuckle while not saying anything. How proud was the development team after this? Extremely – they were trusted to get the job done and done right.

·       From the start, guide the team to do scrum (scrum guide). Shape the mindset and expectations from the start as this will be harder to influence and change later. Doing scrum by-the-book will not make you good at doing scrum but it will be easier for the team to later learn and adopt the nuances and spirit of scrum. 

·       Help the team become confident in their use of scrum early on. Use examples of how each inspect & adapt meeting can help improve the team’s work and their environment.

·       Remove any misconceptions the team has of scrum. Most teams will perceive that scrum is easy to do but it is actually hard to do scrum right day after day. Anticipate the development team’s reaction to this truth.

·       Use positive reinforcement and build a sense of achievement in the team by helping guide the team to successfully completing their sprints. Do not allow a team to over-commit in their sprint planning meeting based on hope alone. Guide the team to select a sprint goal that is achievable and don’t let ‘hope we’ll get it done’ be the team’s strategy. Hope is not a strategy.

·       Encourage ongoing adherence to scrum and agile practices. Watch for danger signs the team is reverting to older, non-agile ways of thinking and doing. For example, do they want to skip the daily scrum or sprint retrospective. Do they think only one person can do work in a specific area. Are they not forthcoming at meetings.

·       Get the customers and users involved in the process. Customers and users need to be engaged during requirement gathering but most importantly, must be engaged with the scrum team during the sprint review. If the customers or users are consistent no-shows at the sprint review or not showing interest at the sprint results, the development team will more likely lose their sense of purpose and possibly blame agile for their lowered self-worth.

·       Inspect & Adapt over blame. When someone on the team messes up, don’t say “Jane screwed up” or anything like this. I would try and restate it along the lines, “how was it the team allowed this thing to happen and what can the team do to prevent this from happening again?” Encourage the team to re-examine their team processes to see if something needs to change to avoid repetition.  Every effort should be made to make the team, as an entity, the focal point during inspect & adapt meetings and discussions rather than specific individuals. This will help reinforce that the everyone on the team is equally responsible and accountable for the results and outcomes of the team. This is along the “all for one and one for all” philosophy. While it’s important to know someone forgot to get their code, document, etc. reviewed, it’s more important to understand how the team allowed this to happen and to see if there’s something the team can do in the future to prevent it from happening again.

·       Identify team members who hamper or slow down the team’s productivity because of their personal characteristics and practices. Individual personality of team members can be considered more important than skill sets when selecting people for a development team. Work with the team and management to remove people who have difficulties adjusting to agile. This is a hard decision but one that needs to happen quickly; these are not ‘bad’ people but are people who can’t adjust to agile and scrum ways of thinking. Many believe the most productive scrum teams are open, honest, willing to change, and can see the team being greater than the sum of the individual team members. If a person doesn’t have or can’t quickly acquire these characteristics, then they may be an obstacle to self-organization and pose a threat to productivity necessitating their removal.

Tweet