Product Backlog Priority vs. Calendar

Proper use of the backlog is vital if Agile is to give the benefits of delivering the right value, on time, and with high quality. Where Agile has failed I wonder of misuse of the Backlog is one(not the only) root cause of the failure and missed expectations.

Product Backlog
The product backlog (or “backlog”) is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog.

During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner’s priorities.

- From  The ScrumAlliance glossary of Scrum terms

I was just discussing with someone how they may apply Agile to a project that would include hardware device development. I was discussing with someone coming from a strong background in a waterfall approach, a natural approach to hardware development. The project manager has a desire to engage in the contract engineering work in smaller chunks, so Agile iterations sound like a good fit.

Discussing the product backlog was a key element as we discussed how:

• metrics of real performance could be captured to help predict future results
• the value of tasks and the definition of done for those tasks can be a collaborative effort with the customer
• priority for feedback and tangent requests can be set within the big picture, see Working Software over Comprehensive Documentation – Handling Review

Yet, there is a trap…You cannot take a waterfall activity list and turn it into a backlog with the activities that occur at the end of a waterfall approach appearing at the bottom of the backlog.

If you do this, you lose the value of priority. If you cannot make a decision to release the product without finishing stories (tasks) at the bottom of the backlog, then the backlog has failed. For example, in device development, certification at a national recognized test lab (e.g. U.L.) comes last in the schedule and it can be easy to simply put this at the bottom of a backlog. The problem is you cannot release a product without it.

Working Software over Comprehensive Documentation – Handling Review

As you perform your sprint review (for Scrum) do you catch yourself reviewing documentation rather than reviewing delivered features? Do you feel you are spending more time responding to review feedback than moving forward? Do you question if sprints are opening you up to too much review feedback? We did.

As we are developing medical device software we are including design documentation and review of that documentation as well as code review in our sprints. It is important for a successful submission to the FDA and without it we do not have a product. As we also do contract engineering work we want to efficiently deliver value to our customer and make waste visible.

The question: Is the documentation review waste or value? Is better documentation valued over more features? When the customer makes a comment on documentation in the review do they know the consequences? Was the reviewer thinking the comment was just a comment and not expecting work, were they expecting a few minutes of work, what if it becomes days of work? Are the comments opinion or do they represent real defects?

We value the early review that sprinting brings us, but is it injecting waste as we open the door to respond to too many opinions and too much tweaking that isn’t adding real value?

Our solution to this seems so obvious… We fall back on the tools and values of Scrum and Agile:

• the backlog.
• the principle of visibility.

Concrete changes we are making for documentation review:

1. We will enter the review issues into the product backlog. We are going to separate them into a review issue section. The issues will be prioritized with input from the customer and the team.
2. We will set a maximum percentage of our capacity to spend on review issues and schedule review issues into our sprint up to that limit. This limit may be adjusted with the customer as they see the review issue backlog grow or shrink.

With the goal of delivering a production quality feature within a sprint, we want to review and update code within the same sprint as it is written. Our code reviews include team members and independent reviewers. Our challenge is how to plan for the review feedback in our capacity?

Concrete changes we are making for code review within the sprint the code is written:

1. A code review task is planned during sprint planning.
2. Review by team members is time boxed.
3. True defects are fixed. Time for this is assumed as: (a)we plan up to only a percentage of total capacity, and (b)the team is committing to deliver quality. If the defects can not be fixed, the story will not be completed.
4. Effort for responding to suggestions or opinions is time boxed and planned as part of the code review task.
5. Suggestions or opinions which cannot be addressed within the time box are put in the review section of the product backlog mentioned above.

And YES this came out of our retrospectives! This feels good!

Customer Collaboration over Contract Negotiation

We do software work for contract product development. Our customers want predictability, while we need to limit our exposure to risk. We need to earn profit from our effort and don’t make profit on the product itself. An approach is to enter into a specification phase with an estimate for the remainder of the project. When the specification phase is complete a fixed cost quote may be requested for the rest of the project.

Realization: a lot of waste is created when writing the perfect requirements. The contract needs perfect requirements. The product needs collaboration. During any such project the requirements still change and the fixed cost quote is ammended with change orders. A contract can avoid a lawsuit, not keep a customer. You want to collaborate and develop a partnership, with both parties striving for a successful product not just a successful contract.

If fixed cost is desired and you want to eliminate contract waste, try flipping the contracts on their sides. Fix cost groups of features rather than process phases (a.k.a. Scrum Sprints or Releases). The customer (a.k.a. Product Owner) is responsible for features. The contract engineering group (a.k.a. The Team) is responsible for efficiency.

The win?
I believe the customer gets more value as the focus is on delivering what is needed for the best product rather than for the best contract. An involved customer can better guide how the effort is spent on what they value. The contractor makes their efficiency visible and focuses on managing that efficiency. Over the duration of a large project efficiency may have one of the largest impacts on total cost and schedule.

Retrospective Examples

A look at things identified in our retrospectives. Discussion and change over five sprints, each two weeks in length.

Meetings

Customer involvement in our Sprint review meetings has been excellent. Collaboration is improved between engineers and the customer (both internal and external). We want to make sure review meetings have a high energy level and everyone’s engagement.

Adjustments include:

• Quickly address incomplete stories and reasons at the beginning of the review meeting. Then move on and keep the rest of the meeting focused on accomplishments.
• Encourage people to stand up and “walk-around” for the demo. This increases energy through motion and helps ensure engagement.
• Send review material in advance and time-box story discussions to help make the meetings effective and run on time.
• Continue to enforce the age old rule of no laptops.

Planning

We are encouraged by the effects of the team making a commitment for the sprint on attitude and effort. We are encouraged by our product owner’s work with the customer to prioritize the backlog and define just in time requirements.

We have recognized the power of time boxing tasks.

• We are emphasizing this with clear annotation of time boxed estimates in our sprint task backlog.

As we have exceeded and missed on expectations, we have discussed capacity planning and the percent of our bandwidth to plan tasks for. We have recognized two different types of stories or tasks:

• Tasks which divine knowledge upon which to make decisions. These tasks are better to time box and take to the review meetings to discuss if they should be taken further. For these tasks we can map one-to-one the estimates into our available capacity plan.
• Tasks which deliver features and may encounter defects or other development problems. For these tasks the estimates are not time boxed. For these tasks we map the estimates into our available capacity at a 1.4 multiplier (said another way, the roughly let us plan for only up to 70% of our capacity).

For a sprint we planned tasks requiring inputs from outside the software team. We believed the inputs would be received in the first couple of days of the sprint. That did not occur and sprint progress was destroyed. We worked around on other tasks, but efficiency was lost.

• We set a rule to not plan in tasks with unresolved impediments outside of the software team.

Several discussions have occurred regarding the efficiency of planning. I believe the process feels inefficient as we are not used to the detail. Planning in a waterfall process just doesn’t achieve the level of detail, but it also doesn’t reap the benefits. I think we require more time to get used to this. That said, we are making changes and refining sprint planning:

• We are changing the available fields, how we use the fields, and who inputs to the fields of our stories and tasks within our Agile planning tool. I believe a template is a standardized starting point and teams should be empowered to adapt.
• We have confirmed the Product Owner needs to be at the planning meetings to ensure they are effective and we hit the target in our Sprint. At least this is true based on the level of detail to which we chose to define our stories.
• We have experimented with the appropriate level of backlog grooming and task definition needed by the software team in advance of the planning meeting to make it effective. It went from nothing, to the full team, back to just the Product Owner and a software team leader. This latter level of preparation seems to work well for us, helping the planning meeting be efficient and effective without additional overhead during the Sprint.
• We have experimented with what to do with the “no man’s land” between review meetings and planning meetings. We chose not to hold them back to back, leaving some gap so we just don’t sit in a meeting that long, to hold our retrospective in between, and to allow the preparation by the Product Owner and software team lead to make the planning meeting the most effective. We have tried to work ahead and are now trying just free time for the software team to work on items they find important.

Feedback

We are receiving good feedback on our deliveries from both internal and external customers.

• We do filter the feedback through the Product Owner and the backlog to be prioritized properly rather than be too quick to respond.

Metrics

We are tracking velocity and using it to project future results for our release planning. We use just the raw average of past velocity as well as accounting for planned capacity changes to project a range. This is working well.

I believe we should also project a range around our story point estimates.

Outside of that we have experimented with tracking planned versus actual capacity, tracking hours billed to tasks versus what was quoted, and other more detailed metrics but have not found ways to achieve good accuracy without too much overhead nor have we found real value.

This will be an area to explore further.

People and Teamwork

We are experiencing good work sharing of tasks amongst the team as the team works together to achieve team versus individual commitments. This is facilitated by the detail of the task breakdown that occurs as part of Sprint planning.

The physical task board is generating positive energy as people physically move and see tasks moved to doing and done.

We had some early struggles as team members started on our team, while having remaining commitments to previous work. What worked well was to discuss our Sprint schedule and capacity planning with project managers for the previous work. With communication we were able to synchronize expectation setting and the team members could achieve capacity planning goals set for each sprint.

Continuous Integration Generates Excitement

Everyone is excited about what continuous integration can do for us. Our customer is thrilled with how this will demonstrate a commitment to quality to the FDA.

• The team plans to make a commitment to the positive effects of continuous integration on the reduction of effort later in the project when the typical waterfall verification phase would occur.

Scrum roles allow room for leadership and mentoring

You try hard to set your project up for success with a great staffing plan. You assign an accomplished engineer as team lead. The lead has all the skills to work well with the customer, troll for and author great requirements, develop an awesome software architecture, and of course develop a complex feature. What is forgotten?

As we put the right person in place and they easily fall into many roles we can overlook: leadership, coaching, mentoring… When we see time spent on this, we see value in it. Yet, it remains difficult to dedicate the time in up front planning.

Initiating Scrum, we are embracing the standard starting point and implementing the roles of ScrumMaster, Product Owner, and the Team. For the team, we have maybe varied slightly from the definition of a self organizing team having designated a technical team lead. She steps up to represent the software team as a technical resource in system architecture meetings and the like. She “sets the bar” for quality. She understands the entire software product, can mentor new people to the team, mentor existing team members in challenging areas, and provide support and review.

We are seeing very positive results. There are less distractions on customer interaction, requirements, impediments.

By accepting the roles and trusting in the standard definitions, we have created sufficient and appropriate seperation of concerns. This provides needed bandwidth for technical team leadership. The Product Owner provides the bulk of customer interaction. Several of us work to keep impediments out of the way. As ScrumMaster, an experienced software engineer, I also have some flexible time to provide additional help on an as needed basis.

7 team building ideas

Team building is continuous, not a one time event.

Please read these posts first…

• 3 things to be mindful of for effective team building
• 5 “obvious” goals to aim for in team building

Please comment back with your own techniques and successes.

The Ideas (Ideas I’ve really used)

1. Question Backlog

I like to do this in extended team kickoff, training meetings and other long presentations.

Provide Post-it notes and pens around the table. Put a task backlog on the wall (to-do, doing, done). Participants may write questions and comments on the notes and stick them in the to-do column. Names aren’t necessary. Don’t force it. Model what you want, and prime it (like a tip jar) by periodically posting your own questions. Make your commitment to address everything that gets posted. Periodically review and find the time and place to fit in the questions.

This lets people ask a question at any time without interrupting and with assurance you will get to it. This helps keep focus on the topic at hand. It also allows for movement and energy.

see mindful (2): clear peoples minds so they can focus and listen
see goals (1): start building comfort to participate

2. Commitment to Trust

What is your commitment, so the team can trust you? Share it. Do not push this on others asking them to make a commitment or to do or not do certain things. Model it, then take it slow. This is very important for us in global development. People don’t sit next to each other, communication bandwidth is slower, giving greater opportunity for incorrect assumptions and expectations to eat away trust.

When taking on the ScrumMaster role and also planning to act as a technical mentor for a new team, I made my written and spoken commitment to:

• Take issues to the team.
• Communicate, Communicate, Communicate.
• NOT! escalate personnel issues without:
  • discussing with individual first and offering help.
  • discussing with team to support the individual.
• If necessary, escalate with the individual.
  It is done to seek help outside the team not to point fingers.
• NOT! do anonymous performance reviews.
  Rather, I will sit with the person I am reviewing. If something is new to them, it won’t go in their review. It is my responsibility to have communicated and offered help first.
• Ask for a performance review between the team and managers

see mindful(1), goals(5): trust
see goals(1): people need to be comfortable being wrong without being judged

3. Meeting Plan

Develop a plan of meetings, attendees, and agendas. Let all team members review the plan. This helps people understand they will be heard and their input respected without needing to be involved in every meeting. It also demonstrates respect for people’s time, giving purpose to the meetings.

see mindful(2): people help plan their involvement and don’t feel left out

4. Goal Setting

Take four steps to develop individual goals and a team goal for a project. The individual goals define how working on the project will benefit each individual.
Step:

1. Everyone writes their individual goal on a Post-it, then reads and posts it on the board in a circle. As the facilitator, go first. Don’t call on people, as they are comfortable they will step up and post their’s next. This may lead to some awkward silence, you don’t need to fill it.
2. Brainstorm how the project may benefit the company, the customer, and society. The brainstorming notes are input to step 3.
3. Use a facilitation technique called ’35′ to develop a project goal. The project goal is placed in the center of the circle of individual goals.
4. Discuss how goals reinforce or conflict with each other.

Individual goals let people focus on themselves and see they are important.

The project goal highlights the value in the work and hopefully is focused on continuous success.
Hopefully you’ve discussed this going into this process pointing out people will come and go and not just the people on at the end are successful.

’35′ get’s people moving and raises the energy and interaction levels. More importantly it will demonstrate the team result is stronger than the individual’s input.

see goals(3): results are stronger as a team
see goals(4): define continuous success for individuals and the team

5. Personality Assessment

Have the team participate in a personality assessment such as DiSC. The personal feedback and group discussion is a good ice breaker, way to get to know each other, and soft-skills learning opportunity.

I have then used the groupings of personalities within large teams as a facilitation technique. Divide a large group by personality. For a given topic, each group can individually discuss and then present. This gives hierarchy to the discussion allowing more people to be involved. By putting like personalities together, no one person (personality) takes over.

see goals(1): build individual comfort
see goals(2): how are you seen by others
see mindful(2): allows more people to be heard and limits dominate personalities

6. Team Cooked Meal
My personal favorite!

Rather than taking the team out to a restaurant, only having discussions between people sitting next to each other, having a sit down low energy event, and not challenging the team to work together… have the team cook their own meal. There are few rules for this. Simply provide a facility and a credit card. The team self organizes, plans the meal, buys groceries, prepares it, and enjoys the comradery.

see goals(3): the team makes easy work of a large task
see goals(4): the team conquers an early challenge

7. Role Playing in Design Meeting

When holding a collaborative design meeting, walk through scenarios and have each developer role play the object they are developing. Have them discuss how the requirements impact them, the interface they will provide and talk to those they will interface to. Work cooperatively at a large white board updating class diagrams, data structures, scenario diagrams, etc…

The opposite of this would be a strong technical performer presenting an architecture and the developers just nodding along.

This raises the energy level of the discussion, getting people out of their chairs. More importantly, developers gain confidence in each other as their knowledge is demonstrated.

see mindful(1), goals(5): trust
see goals(1): a forum to participate
see goals(3): team develops a better design

Sources

I’ve learned these techniques from several sources and experience. Here are a few highlights…

• Peopleware: Productive Projects and Teams, by Tom DeMarco and Timothy Lister
• Plexus course on Principles of Genuine Leadership
• SkillPath Seminar: Excelling as a Highly Effective Team Leader
• Coaching Agile Teams: A companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins
• Starting up Great Agile Teams – or Resetting Existing Ones, presented by Lyssa Adkins and Michael Spayd, Agile Coaching Institute at Agile Development Practices Conference West, 2011.
• Certified ScrumMaster Training, by lithespeed
• A lot of obervation of others… both good and bad.

No one cares how much you know, until they know how much you care.
-John C Maxwell

5 “obvious” goals to aim for in team building

I’m sure these will seem obvious. Sometimes, we need to pause and remind ourselves of the obvious. When coaching a team I have found success by focusing my team building efforts on these goals.

1. Build individual comfort

Individuals need to be comfortable to: speak up, step up, engage and lead. Everyone will have that point when they bring that extra knowledge, insight, talent to the team that needs to be shared.

2. Help people see how they are seen

People are of course comfortable with themselves, with their own habits, with their own style and manners. Others from different backgrounds, with different personalities may be uncomfortable or worse offended by those same habits and manners. Receiving feedback can help one smooth the rough edges, the edges abrasive to team work.

3. Help individuals see the team as stronger

Individuals need to see their ideas, while good, can be improved through collaboration. This can be the achilles heal for a team with high performing, routinely self sufficient individuals.

4. Define success in a way it can be achieved often

Success is a completed project, especially on time and under budget. Right? How often does that success occur? It can be a long way off. Many people will come and go during the project and never participate in that final milestone. It takes a high performing team to deliver that success. It takes success to develop a high performing team.
We need a series of successes that can be enjoyed often and built on. Small successes leading to larger ones.

5. Build TRUST

enough said…

Making Agile tool selection agile

If we are going to be agile for development, then why not be agile in our tool selection. Step away from the one-size fits all mentality. Being true to Agile values means that the team is empowered, they iterate, they learn from mistakes and correct, they try new things out in order to improve.

Instead of lengthy investigation, concensus building between many, purchasing many licenses, switching over of all projects, and lots of training… let each new project decide if they want to use a currently available tool or if they want to try a new tool.

Hold on just a minute! If we do that, how do we…

Pay for that?

A professional, well supported, commercial application set can certainly be expensive. Purchasing a license set for a large group is daunting and difficult to justify ROI. It will take significant time to transistion a large group to a new tool set and there will not be concensus in its selection. You might just want to stay with what you have.

View it differently. Set a budget per developer per year based on current spend and depreciation. For our company this came in at less than $1,000 per developer per year, and we felt that was conservative. While the budget needs to be managed, it shouldn’t be hard to justify.

Consider dropping maintenance as the tools age and new projects are no longer using them. At this point you can forgo upgrades, and they should be stable enough with backups as a recovery mechanism. Buy licenses for new tools as needed rather than in a large lump sum.

Train on the variety of tools?

Put it in perspective. As software engineers taking on new projects, the technology in our field is always changing. Every project for us encounters something new. The new product technology is typically far more complicated than an Agile tool. Yet it is expected, we manage, and it isn’t holding us back. It is a career development opportunity and a lot of fun!

Don’t let the tool drive your work. Tools have many features, many features you don’t need. Approach the tool knowing what you want to do and you will be fine. Let the feature set drive you and you’ll waste a lot of time on distractions, tangents, reading books and online help.

Manage IT maintenance?

Avoid excess requirements on historical data. At key points, generate a report and move on. Limit the desire to maintain a tool to access historical data. Limit the desire to carry historical data forward into new tools and revisions. Question any process requirements that demand this.

Use the available virtual server technology. Dedicate a resource.

Keep up on tool validation?

This is specific to use of tools for medical device development.

Again, dedicate a resource. Agin, put it in perspective. Often we will validate many tools seeing custom use on our projects. We validate off the shelf software that is used in a medical device. This is unavoidable and scoped to the project so we worry less about the effort, and the decision is kept within the local team. The justification of effort for tool validation gets more attention than it deserves.

Focus on getting value out of your validation efforts. Monitor defects from the vendor, the tool receives much more use through their customer base and testing than you can cover in your own reasonable test scope. Focus on your installation of the tool.

I won’t say we’ve mastered this. It is a work in progress. I’d enjoy hearing your comments. Common problem? Success stories? Other challenges? Other solutions?

Our 5 project criteria for use of Agile methods

When looking for initial projects to try Agile methods we are focused on the people and the business relationship more than the project technology. Agile is not a rigid process. It is based on a strong set of values which when embraced allow the team to adapt and improve. The values encourage working relationships and raise visibility within the team and with the customer. The values empower the team to make improvements. The values encourage and require trust.

To truly try Agile methods, we want to embrace the values and remain true to them. We want to avoid just “saying” we are doing Agile, yet slipping back to non-Agile methods. That wouldn’t be a fair evaluation.

We are looking for opportunities that include:

1. A customer that will engage with our team.

A customer who wants to engage in sprint reviews and to work closely with a product owner we provide to groom and prioritize the backlog of work on a regular basis. We provide a product owner as a “proxy” product owner as we are not co-located with our customers. We want our product owner to work closely with the customer and gain their confidence in order to fill the product owner role defined by Scrum.

2. An open minded project manager.

A project manager who will let the team make their own commitments and work to protect the team from impediments. A project manager who will help sell the use of Agile with the customer and avoid slipping into a “requirements as a contract” mode.

3. A team that wants to use Agile methods.

A team willing to let go of things they might have thought they always needed. A team willing to let changes play out to see if they really work. This is necessary to make changes during retrospectives and give them a chance to have an impact.

4. A ScrumMaster who understands and reinforces the values.

A ScrumMaster must understand how to coach and model the values rather than dictate.

5. A co-located team of reasonable size.

Scrum teams are typically 5-7 people. Some of our projects are smaller. So we are looking for a team of at least 3 people. We also want to start with a co-located team. While looking at techniques to allow global teams to work together, lets start with a reasonable challenge.

3 things to be mindful of for effective team building

Trust, Opportunity for People to be Heard, an a Genuine Leader are three things which if lacking will undermine any team building efforts you do.

1. Trust

I presume this is obvious. However, being obvious doesn’t mean it just happens. If you do nothing else here is one thing, the first thing, to start with to gain and maintain trust.

Communicate, Communicate, Communicate…

You need communication to overcome assumptions and emotion. Communication bandwidth is important, especially if your team is not co-located. Email has low bandwidth because it is slow to interact. People naturally make assumptions about your content, your intentions, your motivations. The longer these live without discussion the more trust is eroded. There is likely even discussion about those assumptions with other team members, making the problem worse.

Phone calls are ok. Video conference is better. Face-to-face is best. If not co-located, I’d strongly encourage managers and team leaders to travel at least every calendar quarter. When information is communicated, if you don’t get feedback, don’t be afraid to ask how the person receiving the information thinks they need to respond, or what the information means to them.

2. People need to be heard before they can be informed

When we facilitate a meeting we take care to ensure the visible distractions are limited. We ask for laptops to be closed and cell phones to be silenced. What about the distractions you can’t see, the distractions in a person’s head? People will come to a meeting with something to say or a question to ask. Rather than listening to content, they will be looking for a chance to speak. It is a fault we all need to work on. We need to work on it because it happens! As a facilitator you need to get this out of the way so people can listen and focus on others.

Meetings were an easy example to illustrate this. Keep this in mind in all of your communication. As a leader, make yourself available to listen. Just saying your “door is open” is not enough.

3. A team is built around genuine leadership

Ensure someone is setup for success as the leader of the team. The leader may not be assigned, they may assume the role.

Here are two things to think of. Maybe slight tangents, I think important observations of traps we fall into.

1. It may not be a good thing to have the team pin the leader title on the manager, or for the manager to assume the role.

• A leader needs to work with the team, be focused on the long-term interests of the team, be able and willing to do the work when help is needed, have time and abilities to mentor individuals, and generally serve the team.
• A manager is focused on business and customer needs, often on shorter term financial results, often needing to dictate action for short term results. Typically a manager does not work directly with the team on a day-to-day basis. A manager’s concerns may conflict with a leader’s concerns.

2. Your leader needs time to lead.

Be cautious of a leader taking on too many responsibilities of doing the work. Leading and interacting is intangible and difficult to quote, but leave time budgeted for the role.

Of course this isn’t a post on genuine leadership… that is a life long lesson, but here are a couple of references:

• The Mentor Leader: Secrets to Building People and Teams That Win Consistently, by Tony Dungy.
• I haven’t read, yet… but author Steve Farber was recommended to me from a participant in a course on Genuine Leadership. An extreme leader is:

One who cultivates love, generates energy, inspires audacity, and provides proof.

“The little things matter” & “Action counts more than words”

Yes we’ve heard these phrases before. Their important in team building and genuine leadership too.

Be mindful of your actions and how they reflect your words. The little things that occur daily will matter more than big events. Spend a lot of money on a one time team event, then forget to budget for a smaller item used daily by a team member and your motives for the big event will be questioned and its value lost. Take several small visible actions on a continuous basis to be seen offerring help rather than expressing in words the need for the team to help each other. Model the behaviour you desire.