Agile Defect Fixing

I just read a posting on AgileBuddy about accounting for bugs in an Agile world. The post talked about accounting for bugs, team capacity, and whether bugs should count in team velocity.

It is very clear to me, both from the literature and from experience, that you should account for defect work done in the sprint. You must account for all the work done, otherwise you set false expectations for your business partners, for other stakeholders, and for the team itself (creating a tendency to over task and over commit). There is more than one kind of defect however and they don't all need to be treated the same.

Defects found during the sprint that are a result of coding done during the sprint (sprint defects) should be part of your normal code/fix work. We don't track hours or points for these because they are part of the original story point/task hour plan. This does mean that you have to think about that during sprint planning. We should be planning on code quality, requirements clarity, and the things that create less defects too of course.

Defects found that are not a result of the sprint or that are found during the sprint and the team/PO chooses not to fix them (based on time and priority), are put into the backlog for future sprints. These need to be prioritized by the PO and estimated just like any other backlog item.

If a defect is planned to be fixed during the sprint, we consider it part of the sprint backlog and it gets counted in the velocity. We typically add a "bug" story that gets x number of story point assigned to it, then we add defect tasks that approximate the story point estimation. This allows us to keep working on defects that are found at other times or by other stakeholders/customers.
I don't think that punishing the team by not including their defect work in the sprint is productive. We have a lot of legacy code that the teams are not the originators on and to make them accountable for previous years mistakes (before Agile) doesn't make sense. I do however believe it's important to keep the team accountable to their commitment of story points and to completing the sprint defect free. The basic point is that the team working on an issue, isn't necessarily the one that created it (which can cause mixed feelings and eventually a lack of productivity).

Agile and QA is an evolving process for us, but as we move toward more automation and more consistency in our Agile implementation, we're starting to see better and better results. There is much more to say about defect management in Agile to be sure, stay tuned.

Demo Scripting

Recently we've started a simple, but very effective, process to help our Agile Scrum demo's go smoothly. We write up a short document, called a Demo Script, that describes what we're going to demonstrate for the sprint, and pass it out to the stakeholders before the demo starts. It's very simple, but it has lots of benefits.

Benefits of a Demo Script

1. Start a demo script at sprint planning to begin to understand what will be shown to the Stakeholders. This helps get the creative juices flowing about how the functionality in the sprint is going to be deployed and demonstrated. Some deployments can be very complicated. Getting the team thinking about the end is a good way to mitigate risk and keep the team focused on the right goals. Clearly, the script will change as the sprint progresses, but it should roughly correspond to the commitment that the team makes to the Product Owner.
2. Allows the team some think-time to understand if a particular environment needs to be setup or updated to allow for final demonstration or production deployment.
3. Gives the team a way to write down and walk through the steps they intend to take during the demo (pre-demo demo). This should be more than just a list of stories. It could list specific pages in a website that are visited, usernames/SKUs to look up, particular emails that are sent, or whatever it is that the product is doing. Writing down the steps helps the team understand clearly what they are going to be showing.
4. Gives the stakeholders something they can look at before the demo so they know if they need to be there, be prepared, or pay more attention in particular sections. Provides them a reference for the new functionality to keep with them. Provides an instrument to discuss potential changes or impacts to future/other work/products.
   
5. Helps the team practice in a room if the demo is in a place that isn't dedicated for that or that needs to be changed for some reason.
   
6. Provides a simple release notes of sorts (in lieu of some other more rigorous form).
7. Provides a common point of reference for the team to drop or add an item quickly, before the demo (depending on how soon you send it out).
8. When the team successfully demonstrates all the done functionality on the script, it becomes a statement of their success. Since things that aren't done, aren't demonstrated, the stakeholders are left with a clear understanding of what was accomplished.
9. Provides a way to reference work that didn't have visible outcomes. We always try to link actual end user functionality to every story, however sometimes those stories produce work that is not really demonstrable without taking more time than necessary (like on a sprint where there is no deployment potentially). This hard work needs to be made visible and this provides a simple way to do that.
10. Provides a simple list that support functions in the organization can reference in other discussions to form more complete documentation.

Tips on building your Demo Script

1. Have a good title - Name of team/sprint
2. List the team members names, including the Product Owner
3. Include a list of stories for sprint that have been completed
4. Include a list of steps that will be taken during demo, and then stick to them.
5. Remember to include done and undone work (retain visibility for accountability)
6. Don't include anything that distracts from the work of the team for that sprint. Other documents can fully describe things that need more work, bug lists, future stories, retrospective reports, etc. Including too much can detract from what is being presented.

The Demo Script is, in a sense, both a working document and a marketing instrument for the team. It clearly shows what is done and provides a high level view of the status of the sprint for the stakeholders and user representatives. Use a Demo Script to bring visibility to the hard work completed by the team. <><

Agile Scrum Overview

Today I'm referencing an Agile Scrum overview that I present whenever I get the chance. Please check it out and give me some feedback. It's not designed to have everything, but be a good general overview.

Here are some important books that you need to read if you are going to be implementing Agile in your organization.

• Agile Project Management with Scrum by Ken Schwaber
• The Software Project Manager's Bridge to Agility by Michele Sliger and Stacia Broderick
• Agile Estimating and Planning by Mike Cohn
• User Stories Applied by Mike Cohn
• Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt
• Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen

Scrum and get it!

More about Barriers

Barriers between the team and the Product Owner can come in the form of the old “us vs them” mentality, a lack of following process (stories, conditions of satisfaction, poor tasking, lack of commitment, etc), a lack of understanding of what's being asked for, and good old fashioned lack of trust. The SM can help remove barriers by keeping some of the following in mind.

Ensure that the PO is part of the team. If the PO is treated or acts like someone not on the team, there won't be trust and willingness to interact in a positive and persistent way. The team (including the PO) needs to be able to check their egos at the door and be able to ask questions, challenge assumptions, accept ideas and differences, and at the end of the day remember that they are all shooting for the same thing - working software at the end of the sprint.

Emulate correct behavior. This applies to interpersonal behavior (being reasonable, inquisitive, respectful) as well as following team rules, culture, and accepted practice (except where that interferes with delivering working software at the end of the sprint).

Ensure that the team and the Product Owner are on the same page. Do this by asking questions of both sides, by checking assumptions, and facilitating regular and adhoc communication. Ensure that the schedule is followed and be proactive in anticipating events that might impact it (certain stakeholder must be there but can't be, technical limitations such as development or UAT environment issues, etc).

Ensure that the Product Owner is involved closely with the team on a daily basis. The PO should be attending the daily Scrum so that he can hear if there are impediments that require his attention (clarification of conditions of satisfaction or a story, priority decisions, etc). If possible, the PO should be co-located with the team so that they are building a relationship and learn how to deal with one another on a daily basis. Also, the PO can pair with programmers to develop/understand/clarify requirements as questions arise, not later when it's too late.

The ScrumMaster should take personal responsibility to own the process and the interaction between team and the PO. Whether by title or personal charisma, the SM needs to take personal responsibility and ownership for how the team and the PO behave together. This may be demonstrated by orchestrating adhoc meetings, helping keep things on an even keel when tensions right high, or encouraging dependency on each other. It should be done “covertly” in the sense that the SM is just helping to facilitate the relationship, not necessarily be present at every connection.

The ScrumMaster can be an abstraction layer between the team and external forces that get in the way. In some cases the SM may act as a barrier between forces that tend to impede progress. Many times there are multiple competing priorities that the PO is having to sift through to make the best decision for the customer. The SM can help by facilitating organizational or social change, helping the team to understand why the backlog may look like it does, or simply being there as a resource for the PO to take advantage of for bouncing ideas around or getting technical feedback.

Publicize the success of the team. The SM needs to publicly praise the good efforts of the team and the PO. Since the PO is the “single-wringable-neck” they need the support of the team, just like the team needs the support of the PO when their scope has to be reduced or when they push back on a feature request and ask for more design review. When the SM tells the organization of the success of the team and PO, trust is built in this delivery mechanism, which helps all parties be more engergized, motivated, and empowered.

Preserve openness and transparency between team and the PO. One of the foundation aspects of Agile is transparency. Agile brings out the good and bad, so keeping a commitment to respect between all parties is essential. This doesn't come overnight, but the SM can help bridge the gap by working to build a relationship with the PO and their stakeholders as well as the team. When issues seem to be running under the surface, the SM can ask questions (at the right time) about what is going on? He can help parties save face, but at the same time accept responsibility. This takes a willingness to be on the edge of conflict sometimes, but done well, can enable the team to build an open relationship with themselves and the organization.

Inspect and adapt. This is also part of the core of the Agile framework. The SM can help remove barriers by ensuring that the Agile inspection and adaptation process is followed as intended. It is also where the SM needs to ensure that follow up happens with retrospectives, with impediments, and with team productivity.

Push for continuous improvement of the process. The SM needs to remember that in most organizations, not every aspect of Agile will be implemented all at once, or done to the vanilla optimum that may be needed. The SM needs to have patience and ask the team and PO to grow at the pace they can readily absorb change. This will be faster or slower depending on the people and organization.

Help the team and PO to deliver the most value possible. Keep the team and PO focused, not on positions, but on objectives and purpose and goals. The goal is to deliver as much value as possible. When the team or the PO gets focused elsewhere, it becomes an impediment, no matter how cool or nifty it may seem. Keep the simple dictum, “a little better than before.”

Removing barriers is the core of the ScrumMaster's role. Learning how to be an expert at this will enable the team to do more than they could have done on their own. <><

Some of this discussion was taken from my linkedin q&a. Thank you to all those that contributed to that discussion.

Removing Barriers between the Team and Product Owners

According to Ken Schwaber and his definition of the ScrumMaster's (SM) responsibilities, the SM is to remove barriers between the team and Product Owner (PO) to effectively enable the PO to drive development and achieve value.

I asked my LinkedIn, Certified ScrumMasters group, the following question.

What are specific ways you remove barriers between the team and Product Owner? What are some specific ways that you, as ScrumMaster, have removed barriers between the development team and the product owner, so that the product owner directly drives development?

I asked this question in an effort understand in a more realistic and "earthy" way, just what it means in practical terms to remove barriers - in this case, between the scrum team and their product owner. In summary, here are some highlights of that conversation that I believe to be significant.

The SM needs to remove barriers by:

• Ensuring that the team is concerned about delivering business value. It's easy for developers to seek excellence for their team and department, which is good; however the team exists to meet the needs of the business. If the team is not truly focused on the needs of the business through delivering value, it is not meeting it's fundamental purpose.
  
  
• Helping the PO trust and learn how to work with the team. Some examples include helping ensure accurate tasking, promoting flexibility in accepting change,and ensuring that everyone is working toward the same goals (sprint goal and an understanding of Agile itself).
  
  
• Ensuring that the team knows how to work with the PO (not take on adhoc work, redirecting the PO to the SM in case of conflict with the plan, etc)
  
  
• Asking tough questions of the team and the PO to ensure that quality is not sacrificed.
  
  
• Learning to address the problem and not the person. Many times there are issues - like a lack of communication, not following the basics of the framework, not adhering to agreed upon engineering standards and others. These issues should be identified and then targeted for removal by the SM, pulling in as many people as needed (with the right authority)to remove the barrier.
  
  
• Educating the PO and team on the process regularly. It seems clear from many comments here and elsewhere, that the SM is the one driving the agile education process - on a day to day level by consistently pushing for agile adherence and continual process improvement; as well as on a more formal basis by identifying training needs and facilitating those needs in formal and informal ways (again, working with those who are in the position of authority to enable that training).
  
  
• Owning the Agile process and facilitating regular communication between the team and PO. There is some discussion between the ideas of ownership vs. enablement. The SM should clearly be doing his best to enable the team toward growth and self direction. Because the Agile team is focused around collaboration, it seems that the the SM is typically the one helping to direct the growth and use of Agile within the organization. There are usually other partners involved as well.
  

A great article on ScrumAlliance mentions some other barriers that the ScrumMaster handles in support of the team:

• Work to remove impediments on a daily basis and communicate resolutions
• Protect the team from disruptive outside influences (support staff, managers, customers, even the PO if that becomes an issue).
• Unnecessary time wasters (inappropriate meetings, tasks that someone else could/should be doing)
  

There are other aspects of removing barriers that were not covered here and are the topic for future conversation. There are barriers:

• Between individual team members
  
• Between individual team member roles
  
• Between the team and the product owner

Of course these barriers address just a portion of the overall business communication context, however, they are the primary areas of interaction for the development teams and the SM. It is hoped that, as more is learned about what kind of barriers generally occur and good solid ways to deal with them are determined, that more targeted efforts can be made by the SM and the organization to avoid them. <><