Agile Essentials

Agile is a process framework most typically used in software development projects ideally suited for projects with high uncertainty. However the basic principles of Agile can apply to just about any type of context. The founders of Agile have developed a "Manifesto" that describes the basic tenets of Agile.

The four tenets are as follows*:

1. Individuals and interactions over processes and tools
2. Delivery of value over comprehensive documentation
3. Customer collaboration over rigid contracts
4. Responding to change over a detailed plan

Some other aspects of Agile are:

1. Early and continuous delivery of value
2. Adaptive insted of predictive to give maximum flexibility
3. Visibility for good and bad
4. Inspect and Adapt frequently
5. Become iteratively better
6. Result driven tasks
7. Face to face communication
8. Cross disciplined, motivated, empowered teams
9. Sustainable pace
10. Continuous attention to Quality

Agile Scrum (a particular flavor of Agile) arose from proceses that were designed to increase speed and flexiblity in the delivery of business or social value. It is a collaborative and change embracing method that cross-functional teams use to produce high quality deliverables through iterations of work time.

Scrum itself is specifically a lightweight process framework that is designed to focus the teams on delivering the highest priority items first. The fact is, that most projects or programs spend much of their time attempting to deliver some less-than-well-defined artifact, only to find that by the time it's done it's no longer relevant or needed. Scrum defies this by demanding that the highest priority items are addressed first, exposing issues, forcing the understanding of risk and dependencies, and in general bringing visibility to the team and the rest of the organization it lives in.

Read more information about the details of scrum. How would Scrum apply to your context?
<><

References:

1. http://www.agilemanifesto.org/
2. http://www.scrumalliance.org/articles/22-scrum-delivers
3. http://www.mountaingoatsoftware.com/scrum

*For the purposes of abstracting Agile out of the software world I have changed the wording slightly from the original, but it carries the same connotations (1).
* The focus on the first half of the statement doesn't mean that we don't care about the second half and need to consider them.

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.