Why Your Boss's Boss Should Also Go Agile

By Christine Crandell

Incremental software development methodologies can be traced all the way back to the 1950s, but it wasn’t until 2001 that “The Agile Manifesto” created a comprehensive and landmark account of agile development and why it’s a better, lighter approach to creating software faster.

Ever since then, developers have been using agile methodologies to improve the speed and flexibility of software development through operational improvements, but most other groups within the same company have not adopted a similar philosophy.

Conceptually we’ve bottled up agile as being for software developers, as if speed, flexibility, and complexity weren’t also issues held within every other departments of fast-paced software companies. When software developers are using agile methodologies, but nobody else is, developers become like the clique group of school kids who share a foreign language nobody else understands.

This has caused us to limit the potential for agile frameworks, because they're only implemented operationally, but not strategically. It’s like a wooden boat full of rowers. They might have seamless coordination and full visibility into the work of their colleagues, but they can’t see the captain’s orders up on deck.

Continue reading this article.

Agile Coaching Qualities, from A to Z

By Sunil Upadhye

Successful ScrumMasters and agile coaches share many positive qualities—listed here from A&A to Z&Z.

Attitude & Affirmations

Dress up your attitude and you can achieve 100 percent success. Affirmation is a self talk – whatever you say to yourself will be reflected in your behavior. Be kind to yourself and nice things will happen.

Balance & Benchmark

Create a balance in your mind. Be unshakable in the war against Naya – No Sayers. Create a benchmark of your work today. track the progress of your team through constant feedback mechanism.

Courage & Collaboration

Only courage can create highly collaborative team.

Determination & Desire

Have a strong determination to make others successful. Desire success. Look for the good in everyone. You will find excellent things in every human being.

Continue reading this article.

Ask the Coach

By Manoj Vadakkan

Recently I had an opportunity to speak with Alan Atlas, a Certified Scrum Trainer and Certified Scrum Coach who works for Rally Software. In this conversation Alan shares his insight on the state of Agile and Scrum. He also takes a stab at predicting what is to come in the future. This interview also includes some advice both for budding agile consultants and also for organizations that are trying to transform to an agile way of working.

Manoj: Agile has been here for a while; it is everywhere now – small and large organizations, distributed organizations, etc. What’s new in agile? Where is it going?
Alan: One thing I am glad of is that, in a certain sense, there is not a lot that is new. I think we understand it [agile]; I think it works and I really don’t want people messing with it a lot. Ken Schwaber is fond of saying that the whole thing that got us into trouble in the first place was our search for the perfect process. One reason that Scrum is so strong is that it is a process framework, not a process. It gives you all the important stuff and plenty of room to adapt.

It is true that agile does seem to be spreading everywhere. I saw a question in a trainer’s discussion group where someone was asking, "When is it going to be when the only option to do your project is agile? Then you don’t have to say you are doing agile or waterfall, you will just say we are doing a project." I think we will get to a state where that’s [agile] just the way to do things. Students will come out of school knowing agile, and they will know iterative and incremental makes sense; it will be just as logical to them as waterfall  was to us when we came out of school. When I came out of school, I thought, what possible other way there could be to do a project? It [waterfall] was so logical. You start by collecting things [requirements]; you go thru this orderly process; what could possibly go wrong? We discovered what it was – what could go wrong.

Continue reading this article

Why Go Agile—Why Should I Embrace Change?

By Bachan Anand

Has someone in your organization taken time to explain to you why you should embrace Agile? Ask yourself, why would "I" as a CIO/ Business Stakeholder / Developer/QA/BA implement Agile? Teamwork is very key in any organization; however, at the end of the day, we are all individuals, and it is very important for each person to understand how Agile practices add value to their work, to their goals, and to their life at large. The good news is you will discover it once you get started with Agile as the changes are organic and ingrained into the values Agile holds. This article will be beneficial for people who have yet to take the leap and are testing the waters, and also for people who have done it all and are continuing to learn, as they can add value by sharing their experiences.

So why go Agile? No matter who you are or your role within an organization, going Agile means different things and yields different value.

CEOs –less wasted work by your organization and improves value for your investors.

CIOs – sets a compelling vision for your team, makes your stakeholder meetings easier, and improves communication with business partners at every level. With Agile you will realize an organization with higher transparency and less political agenda.

Business Users – will make them well aware of work that is in progress, and gives them opportunity to give feedback and get what they want.

Business Stakeholders – promotes transparency for business stakeholders in IT matters, allows them to see results faster, gives them an understanding of why some things take the time they take, and helps them plan better for the future.

IT Senior Leadership – provides a very concise and accurate burndown chart at each release and each iteration level. It also helps senior leadership focus on the forward thinking strategic activities while the team is focused on the short term goals.

Team Leads – puts the focus on Leads to be mentors and share with the team knowledge they have assimilated in their career.

Project Managers – puts focus on the Team to come up with a plan, with a detailed task list and estimates for every iteration, which the Team commits to. Agile sets the stage for project managers to better understand the Team and the technology, and to support the Team by removing impediments.

Architects – Agile principles focus on precision and getting it done right, architects can focus more on strategies which will take the organization to the next level of success, instead of constantly worrying about whether the team will take shortcuts.

Developers – through clear acceptance criteria, test driven development and feedback from testers during the development cycle, developers can produce bug-free code and improve their morale.

Testers (QA) – sets the stage for testers to work closely with the Team and ensure the quality of what the Team has committed to, and not be just defect finders.

Business Analyst – helps to keep the BAs focused on asking powerful business questions, and encourages them to partner with the Team to identify the expected behavior of the system through user stories and acceptance criteria.

Organizations – Imagine the growth that you can expect when the whole organization has the opportunity to constantly review and take corrective action instead of waiting for the project end phase or the yearly performance review.

Families – will improve quality of life as you will see less burn out and long hours as wasted work is reduced and deadlines are met.

Everyone – Agile is something for everyone. These are principles you can incorporate in every area of your life. It encourages collaboration at home, at schools, and church, empowering the next generation, creating a vision for yourself, and setting goals for shorter duration.

The world – think about some of the challenges that we have in our world and how collaboration, empowerment, transparency and constant retrospective can bring about changes in our political system, governments, schools, and religious organizations.

I want to end this article with a quote by Martin Luther King Jr.,–"Take the first step in faith. You don't have to see the whole staircase. Just take the first step."

Take some action and you will discover the benefits Agile provides you. Let's do it, Let's go AGILE!!

Three Things I Wish I Knew Before Jumping

By Pat Guariglia

Like many people trying to implement a Scrum/Agile project for the first time in an organization, I encountered a number of obstacles that were almost project killers. As I write this article today, I keep thinking, “if I only knew that when I started.”

When I started managing my first Scrum pilot project in 2007, I was new to the concepts of Scrum and Agile development. For years, I led projects using traditional project management methodologies common to PMI, i.e. Waterfall. During this time, I was a consultant to a New York State Agency. It was a typical Waterfall shop, with no history of using Agile or Scrum.

Sometimes you can choose the project you want to pilot, but oftentimes the project chooses you. In my situation, the Agency had its back up against the wall and needed to expedite the delivery of a critical project. Agency funding was in jeopardy and critical business dates needed to be met. In my opinion, certain types of projects are good candidates for Scrum pilots, and others are not. The project I led had none of the characteristics ideal for a pilot project; it was not the perfect candidate for a first-time Scrum implementation.

After being assigned to manage this project, I quickly realized that the project would never meet the deadlines within the constricted structure of the organization. It was necessary to break away from the Agency’s normal project management and development methodologies. The project sponsors permitted us to use the methodology of our choosing as long as we met the deadlines. I explored Scrum and various Agile methodologies and made the decision to abandon the normal Waterfall project path.

After one year, the pilot project turned into a program of three projects. Two of the projects used Scrum and the third followed a Scrum hybrid approach for managing a vendor’s customization of a commercial software product. The program was mostly successful, and the projects were delivered on time for all critical dates. The organization was satisfied with the use of Scrum and looked for other project opportunities to leverage some of our Agile best practices.

The first few months were difficult and outright painful as the team learned the practices of Scrum, the variations of Agile development, and the nuances of the customer’s business. Our team had little guidance and no one coaching us on Agile or Scrum methodologies. For months, we worked in the dark to avoid scrutiny and work out the details of our methodology, with only a few people aware of our voodoo methodologies. We had only one clear goal, to achieve the deadlines without failure.

Even though I had moderate success with the three projects, I discovered literally hundreds of things I wish I knew before setting off on my pilot journey. I want to focus on three critical topics for this article, which I believe anyone starting a Scrum pilot project should know. The three things I wish I knew most before jumping into my first Scrum project are: 1) select a project with medium criticality; 2) continuously communicate your chosen methodology; and 3) demystify the voodoo (this one needs some explaining).

These three topics are basic and straightforward, and should be universal to anyone attempting an Agile/Scrum pilot project for the first time. I chose three things that focus on the early stages of a project, but could also be valuable throughout the project’s lifespan.

Select a Project with Medium Criticality

In order to have a successful Agile or Scrum pilot project, it is important that the project chosen has enough importance or criticality to the organization. Projects with low levels of urgency will get brushed off and not given the resources, attention, and critical thinking needed to properly develop a Scrum project. Pilots with high criticality are not good for several reasons. The main reason is that there is little room for failure. If the pilot is not successful, it can be a huge black eye on the face of future Scrum efforts. Also consider that on a project with high criticality there will likely be many attitudes and influences on the project, which could steer it off the Scrum course.

Typically, good candidate projects have medium importance to the organization. It is important to understand this when choosing a pilot, if you are selecting one from your portfolio. An excellent resource on this topic is a book by a friend of mine, Greg Smith, titled Becoming Agile in an Imperfect World. He covers various aspects of a good pilot project in his chapter “Characteristics of a Good Pilot.”

Continuously Communicate Your Chosen Methodology

I cannot express the importance of this topic enough. In the years that I have been a project manager, I have never been able to communicate enough. Just when you think you have covered all bases, there is someone lurking in the shadows not paying attention. According to PMI¹, the amount of time a project manager spends communicating is 90%. This holds true for Agile project managers and ScrumMasters as well.

Since I have been using Scrum, I have been both a ScrumMaster and project manager on each project I manage. As a ScrumMaster, I have spent countless hours coaching and deflecting potential issues/problems away from my team. As a project manager, I have spent an inordinate but necessary amount of time reporting status, building relationships with stakeholders, and keeping the projects aligned with the organization’s standards, rules, and strategic goals.

When starting a Scrum pilot project of any type, it is of vital importance to communicate your chosen path (Scrum) to everyone you interface with. You should not communicate this path just once or twice. It will be necessary to continuously express, elaborate, and explain Scrum to every stakeholder and team member until they no longer look at you with confusion in their eyes.

After more than a year and a half into my pilot Scrum project, I was talking to a functional manager about our Scrum methodology and how we were using Scrum and Agile development. The manager appeared confused and disoriented by the conversation. This was not the first time discussing this methodology, but the manager reacted as if it were. This reaction is common in an organization heavily framed within a Waterfall methodology.

Typically, few people in traditional Waterfall organizations have been exposed to Scrum. I made the false assumption in the beginning and middle of my pilot project that stakeholders and the accidental support person were familiar with Scrum or Agile development, because I gave several overview presentations to them. This assumption was way off on my part. In order to understand Scrum, one needs to be involved in Scrum. Observing Scrum from the outside can be odd for some, and for others it can be confusing.

After many months of trial and error, our Scrum team finally reached a cadence and became better at estimating and delivering. The people who interfaced with us on a regular basis, who were outside the immediate Scrum team, including support units, infrastructure, and the PMO, began to better understand the Scrum process. If your pilot project is progressing successfully, it will become easier to communicate your process because everyone will want to know how you are doing it. On the contrary, if your project is lagging or plagued with issues, it will be hard for you to find an audience that you can convince that Scrum is the way to go.

Communication on any project is the most important part of a project manager or ScrumMaster’s job. The sooner and more frequently you communicate what you are doing the better off you and your project will be at surviving the first Scrum attempt.

Demystify the Voodoo

In my attempts to “demystify the voodoo” of Scrum to the outside observer, I have realized that this is not always an easy task, and is one that requires frequent attempts at demystification. When I first started using Scrum and Agile it was painfully obvious that others in the organization, including some stakeholders, were uncertain about my methodology and had a preconceived notion about Agile and Scrum. This misconception was something I continuously confronted throughout my project, as it was an impediment to my progress.

The reason voodoo becomes an impediment is mainly due to the reasons mentioned above in the communication section. It is important to communicate the methodology, which means define, describe, demonstrate and illustrate, thereby demystifying whenever possible. Most of the voodoo comes from not understanding the methodology or having the wrong information. Agile and Scrum are demystified every time one communicates or explains their pros and cons to the outside observer or reluctant stakeholder.

Unfortunately, as a project manager and ScrumMaster, it is possible to contribute to the voodoo perception. Performing Agile “in the dark” or “under the radar” can sometimes make the methodology even more taboo or misunderstood. Performing this style of clandestine Agile can be beneficial for a short period while the project team is getting up to speed and processes are being defined, but continuing too long in this mode will eventually be counterproductive. Stakeholders want to understand how the project is being managed. At some point, it is necessary to communicate the methodology before others begin forming their own opinions of what you are doing.

Using examples of public success stories also helps to demystify Scrum. After articulating various definitions of Scrum and Agile development processes to my stakeholders, I looked for examples of successful implementations of Scrum in both the private and public sectors. Illustrating how a CMMI²level 5 company can successfully put a Scrum project into place certainly got the attention of some of the stakeholders. I showed quantifiable results from Systematic, a CMMI 5 company who measured productivity and quality before and after they implemented Scrum. Their overwhelmingly positive results put many of my stakeholders finally at ease.

Wrapping Up

Though there are many things I learned along the way, the few that I have described here are the ones that would have been the most helpful at the start of my Scrum/Agile experience. If you have any choice in the matter, remember that when starting your first Scrum pilot project, it is important to pick the right project. Also, communicate your methodology, risks, and plans continuously. And finally, provide accurate and substantive information to support the use of Scrum and Agile in your organization, which in the long run will demystify the aura of Scrum.

Scrum is not a cookie-cutter mold that you can throw your project into. Scrum is adaptive and can be customized to some extent to fit the unique situations and conditions of your environment.

Scrum In A Nutshel

By Dan Rawsthorne and Douglas E. Shimp

Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe Scrum as a simple applied model so that a central understanding of Scrum can be built. Other complexities of applied Scrum such as scaling, distribution, etc. will be explored elsewhere.

The Team

The fundamental element of Scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of people that provides useful Results/Products for Stakeholders.

Arguably, the most important role involved in Scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special Stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the Team to form.

While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the first person held accountable for the Team’s success. The Product Owner must find a result that will satisfy the Stakeholders’ needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.

The Scrum Team Members, including the Product Owner, are the people who actually do the work that satisfies the goals and priorities the Product Owner has set for them. The Product Owner must work with the Team to find a rate and direction that the Team can go, to achieve a desirable result. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings; whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve; they work on the priorities the Product Owner has set. The Team Members commit to the amount of work they can do without undue influence from the Product Owner.

In order to aid the Team (Product Owner included) in doing its work, there is a role on the Team called the ScrumMaster (SM). The SM's responsibilities are to be a facilitator, moderator, and coach, with particular emphasis on helping the Team mature its self-organization and management. The ScrumMaster manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team, often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the Team and outside the Team. The ScrumMaster understands the Scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to. If the Team does not follow its process this becomes an impediment. Most impediments can be addressed by simply causing them to become a center of focus. The SM stimulates that center focus by calling attention to the impediment. Creating a smart center of focus is the art of being a SM.

The Backlog

A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs," "Backlog Items,” or simply "Items"). When the list is small it is just a straight list of things, but as it grows we add grouping mechanisms to organize many little things and help us keep track.

These Items represent the Stakeholder's needs and wants – each of them is a request for something of value from the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of Scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few Items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that Backlog and thus, creating a distinction between the Sprint Backlog and Product Backlog. From the Team’s perspective, the Product Backlog is work that we might do some day, and the Sprint Backlog is work we are committed to doing.

The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: “ready” does not imply excessive detail but, instead refers to enough detail. The Team working with the PO will determine what “enough detail” is.

When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, and refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify Backlog Items. This process is called Backlog Grooming, and is a continuous process throughout the Project.

Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.

The Release

The goal of a Scrum Team is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).

Typically, before a project formally begins, there is a Visioning phase (this could also be the first phase in a project), when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.

The Scrum Team’s purpose is to create a result that satisfies the Stakeholders’ needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on Items. The Sprint length can vary, but this requires more discipline on the part of the Team and is not advisable for new, less mature teams. The steps of a Release are relatively simple, and I'll describe them here.

Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation considers the Product Vision and Roadmap, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and results in a set of Release Goals and a Release

Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.

Once we have a Backlog that supports the Release Goals and Strategy, the Team starts sprinting. The idea is for the Team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.

The Sprint

The fundamental process flow of Scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results.

The first thing to do in a Sprint is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of "Done," and collectively these Items are called the Team's Sprint Backlog. It is the ScrumMaster’s responsibility to ensure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the Team confidence that it can complete the Item, and thus commit to it. The tasking of Items can help the Team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the Team is working well.

Once Sprint Planning is over, the Team begins work in the Sprint. The Team self-organizes to do the work and self-manages as it does the work. The Team’s work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing Teams that looks like a swarm to an observer. While the Sprint is in progress, the Team will have Daily Scrums in order that each Team Member understands what the Team's status is. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the Daily Scrum.

During the Daily Scrum, and continuously throughout the day, the Team Members notify the ScrumMaster of any impediments they encounter. It is the ScrumMaster’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.

The ScrumMaster must also ensure that the Team does enough Backlog Grooming in order to be prepared for the next Sprint's planning meeting. The Backlog Grooming is a strategy to prepare enough work to begin next so that a rhythmic flow of work can happen.

When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the Team's Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so the Team can get feedback on what they've done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), considering the Review and any "business reality" changes the Stakeholders may have. When Teams are small they can rely on more intuitive reasoning to determine what the "right direction" is. As a Team grows they will see a need for more sophisticated techniques that use metrics to help them answer what the "right direction" is.

After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The Team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be "enforced" by the ScrumMaster in future Sprints. To enforce something the SM will need to shift the focus to the issue at hand and then let the Team react. Telling the Team what to do is not desirable. Shifting the Team focus and thereby enforcing change is an art of the SM.

At this point the Sprint is complete, and the Team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.

Quick Summary

Team of 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross-functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily Scrum detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance

Cargo Cult Agile

By Manoj Vadakkan

We have been saying "there are no silver bullets" over and over again. But do we really believe that? In some ways, it is like the disclaimer we add to the end our e-mails. Nobody reads it, but the legal department makes us put it there. Aren’t we (the IT industry) treating Agile like yet another silver bullet? Everyone wants to "adopt" it! Everyone wants to say that we are Agile! It is becoming more like a "Cargo Cult" (See Notes 1).

During World War II, materials such as food, clothing, and tents were airdropped to equip the soldiers and the natives in the Pacific Islands. At the end of the war, the soldiers went home and the air cargo stopped coming, but by then the natives were used to the airdropped materials. Soon, they dressed themselves as ground controllers, wearing carved wooden head sets and waving landing signals in the hopes that these activities would attract those cargo planes.

In some cases, it seems like we just have a need to say we’re using Agile practices, even if we’re really not. We don’t use those old school requirements documents anymore, instead we create user stories. We estimate in story points; Fibonacci series is fun, and so are poker cards! Sure, we do release planning. We also do a Daily Scrum; well, we cannot really do it daily because our team members already have too many projects and meetings, so we just meet twice a week. Regarding user stories, we have to write them down in the form of detail specification because our testing team is busy with other projects and not available for the first few months to really participate. Additionally, we are required to have those documents signed by all parties, scan them, and upload them to the document management system. Otherwise, how would we know what we agreed to?

So if we think adding a daily (or mostly daily) standup meeting, estimating in story points, and implementing a few other things we find in the Agile/Scrum books will save us, well, good luck! Like the Cargo Cult, we can keep wearing our wooden head sets, lighting those run ways, and hoping for the planes to land.

Like the Cargo Cult, we are getting some of those superficial elements correct. But can we really attract the cargo planes with those elements alone? Do we really know what problems we are trying to solve? Do we really understand what we are doing and why?

In order to solve problems in your organizations, you need to look inside, not outside, to adopt yet another practice, process, or tool. You need to look at what problems you need to solve and identify solutions to those problems. Certainly, Agile/Scrum practices are proven in the industry. So bring that knowledge to your organizations in the form of training, coaching, or hiring. They can seed some of the options to get to your solutions. However, the solutions need to come from within the organization. That should be what "adopting" Agile/Scrum means. These practices need to solve the problems and achieve your organization’s goals.

Here are some activities that will help you identify problems and move towards a solution.

1. Do some soul searching: One way of doing this is to have an open space meeting. (See Notes 2)
• This will help you identify some of the problems you are trying to solve. (e.g. concept to cash takes too long)
• Help identify some of the possible solutions. (e.g. remove some of the communication barriers)
• Bringing people together will help the team take ownership of these problems and solutions instead of yet another mandated process that comes from upper management
2. Create a Product Backlog of concepts that the organization wants to try to solve the problems.
• Break those into tasks and assign resources.
3. Get senior management sponsorship.
• There comes a time when you will have to rethink the organizational structure in order to solve some issues. You can remove some of the organizational barriers only if you have senior management/leadership support.
4. Consider getting a coach, advisor, or someone who has done this before.
• A good coach will be able to guide you to possible solutions for your issues. Instead of just "adopting" some of those silver bullets like daily meetings and iterations, they will be able to guide you to solutions to the problems. A good, experienced coach can reduce the costly expense of experimenting.

There are a lot of articles out there that will help you in this transition. A comprehensive analysis can be found in Succeeding with Agile, a new book by Mike Cohn.

Have you seen Cargo Cult Agile in action? Tell us about your experience with Cargo Cult Agile.

Notes

      1. About Cargo Cult: http://en.wikipedia.org/wiki/Cargo_cult
      2. More about open space: http://www.openspaceworld.org/cgi/wiki.cgi?AboutOpenSpace

Are you ready for Agile? A Checklist of Questions to Consider Before Starting a Large-Scale Agile Adoption

By Ramesh R. Donnipadu, Bala Kishore, Pete Deemer

Abstract

The ability to deliver business value earlier and more often, increase productivity, and improve employee morale is compelling many organizations to embrace Agile approaches to software development. There is a wide array of training courses, consultants, and books available to help teams learn the basics of agile development, but these often focus on the team-level challenges, and overlook some of the larger organizational issues that may either help or hinder the transition to this new way of thinking and working. This article attempts to outline areas where many organizations encounter difficulties in their embrace of Agile, in hopes that others can be better prepared to meet these challenges.

Checklist

Depending on the size of the organization and current processes followed, different organizations may face different challenges in their Agile adoption. This section lists the most common difficulties that your organization may encounter in the early days of embracing agile development. Some of these items are not even related to Agile per se; they‟re just sound Engineering or Management principles, which any smart organization normally follows. But, these are not so obvious until you get into the thick of the things. Regardless, not attending to these issues at the outset could lead to frustration for the organizations getting into agile development.

This Checklist is expected to help you evaluate the preparedness of your organization to these new challenges.

Management

1. Do you have Management’s support?

Among the challenges a team may face in the early stages of adopting Agile, the most important one is winning the confidence and support of top management. If you do not have a genuine commitment to change from your top executives, you are not likely to be successful. Win their confidence support before you set out your journey. Be upfront with them on the roadblocks you may face and lay out your plans on how you intend to overcome them.

In some cases, the senior executives and junior technical staff may be enthusiastic to “go Agile,” but there may be a lot of skeptics in middle management. This could be due to the fear of losing control over their teams or inability to distinguish Agile development from “cowboy coding” or apprehension on the quality of the product or lack of documentation. You need to allay their fears by showing concrete examples.

What if your leadership fails to agree with you? You can still go ahead with Agile, but you are on your own in dealing with the challenges.

2. Is Proper Training Provided to the Organization?

The industry-standard training for Scrum teams is the Certified ScrumMaster (CSM) training course, conducted by a Scrum Alliance Certified Scrum Trainer, and we strongly recommend that this training be provided not only to ScrumMasters but also to team members, managers, and others in the organization that will be interacting with the Scrum teams. In addition, it's imperative that Product Owners complete Certified Scrum Product Owner training. If great results are to be achieved, everyone needs to understand how to “play the game” well.

This training in the fundamentals of Agile is just the foundation for success, though, and to be successful, there are other new skills that will have to be learned. First, Agile development quickly makes visible any deficiencies in teams‟ ability to work together closely and produce high quality functionality in the span of an iteration. Many teams require training to learn better coding and testing practices, whether in the basics of test automation, refactoring techniques, or in practices such as Test-Driven Development. In many organizations, team members have highly specialized skill sets, and often have difficulty working closely together as part of a cross-functional team; they may require coaching in how to do this successfully. Often, the most effective way to retrain the team in cross-functional behaviors is to “seed” the team with one or more members who are experienced in this way of working.

Another good way of accelerating learning is to start a study group that meets periodically to discuss various aspects of Agile development before the training takes place. During this period the team can read literature available on the Internet, starting with the Scrum Alliance website [www.scrumalliance.org]. We found these meetings are extremely helpful to come onboard quickly in terms of understanding the new practices and mindset, and adopt it to our environment.

In addition to new technical skills, teams may also require more education in their product domain. In Agile, developers are not “software robots,” blindly implementing software specifications; rather, we want them to be full partners in the development effort, helping the Product Owner achieve maximum business value. For this to occur, they need to have a working understanding of the business and technology context for the work they are doing.

Many organizations make a solid investment in training in Agile technical practices, but overlook training in the soft skills needed to really get the most from those practices. ScrumMasters, Product Owners, functional managers, and executives should receive training in facilitation skills, Agile retrospective techniques, dispute resolution, root cause analysis, and systems thinking. All of these are practical necessities for skillfully coping with the myriad dysfunctions that Agile development will quickly surface.

3. Did you train your Product Owners?

Strong product ownership is a key to the success of Agile development, since it is this group that bridges the gap between the end customers, management and IT. A very thorough understanding of the responsibilities of the Product Owner, how to work with customers, the team and stakeholders to achieve maximum ROI, and how to be effective with the essential practices are required.

When faced with large-scale development effort, it is often recommended that all teams work from a single, project-wide Product Backlog, as opposed to having multiple, team-specific Product Backlogs; this will help reduce the duplication, redundancies, and conflicting directions that can often result from the latter.

Unless your Product Owners are equipped with these skills, you are not going to see the big wins from Agile adoption.

4. Do you have enough space?

Agile principles emphasize face-to-face communication wherever possible. If the individual members of your Agile team sit at different locations, the overhead of communication reduces their effectiveness. It is mandatory to rearrange their seating so that it improves informal communication within the Scrum teams. Get the teams co-located into their individual team spaces even if you have to convince your facilities, HR, VP or CEO.

You also need to ensure that they have enough free space for informal gathering around a computer for a quick walk-through, their daily stand-up meetings etc. Also, ensure that the teams have adequate wall space, white boards, flip charts and writing material.

5. Are all your support teams on board?

Organizations make all efforts to train the teams that are adopting Scrum. But, often they ignore the need to familiarize other support teams. If the development team is going to be successful with Scrum, they need to have full support of any specialists who provide support but are not members of the team, for example, DBAs, Sys Admins, or the Configuration Management team. Unless they know the constraints and limitations of your Scrum teams, you are not likely to receive their deliverables and meet your Sprint commitments.

Get at least one representative from each of these departments enrolled in the Scrum training. Try to get these specialists included in your Scrum teams, ideally as full-time members of the team, or at least in the role of consultant.

6. How quickly to scale?

Often, large organizations attempt to roll out Scrum across several teams simultaneously; what some people call the “Big Bang” approach to change. Tempting though this may be, the risk of such an approach is that systemic or large-scale dysfunctions (which afflict many teams across the organization) will be surfaced by many teams simultaneously, and will have to be resolved quickly and for many teams at once. This is both very challenging and very chaotic. It may be easier to begin Scrum with a small number of teams, try different solutions to solving these baseline dysfunctions, and be able to provide best practices to later teams that follow in their adoption of Scrum. As the organization gains confidence and competence in Scrum, more teams can start practicing it.

7. Is an appropriate attrition strategy in place?

This may not be an important item in difficult economic times, but for organizations susceptible to high attrition, dealing with this problem could be very challenging. Unlike in traditional models, Scrum believes in tightly gelled teams of individuals with a core competency and multiple cross-functional skills. As Scrum teams are smaller, losing a single member could prove to be a significant setback for a team. Even if you find a quick, equivalent replacement, it will take some time for the new hire to get up to speed, bond with the team and start delivering.

Scrum provides the benefit of teams, but also makes more visible the disruption when teams are broken or changed.

Have a trained pool of engineers available, who could substitute an unexpected departure in your team.

8. Can your engineers appreciate the purpose behind a user story?

A competent technical team can convert a user story into database tables, Controllers, tags and Form elements fairly quickly. But some teams may have difficulties in comprehending the motivation or ROI behind a feature they are implementing. For Agile to be successful, it is critical that all members of the development team (developers, testers, etc.) “get into the Product Owner‟s head” and appreciate the rationale behind a user story. They should keep questioning the objective of major decisions and suggest alternative implementations where possible.

Otherwise, one risks ending up with brilliant technical implementations that fail to meet the business goals.

9. Module assignment to teams

If you are planning to assign different software modules to different Scrum teams and you expect them to have exclusive check in privileges on their modules, you need to be very cautious. While it is a good idea to let individual Scrum Teams master specific software components, if you implement a user story that requires multiple Scrum teams to work on it, all hell breaks loose. The interface design, hand off, and integration between multiple teams introduce a lot of waste.

Also, avoid restricting teams from touching other modules based on their ownership. You can better enforce the code ownership with good code reviews and refactoring policies.

Code

10. How tightly coupled is your system?

If your code base consists of tightly coupled modules, and you have a large number of Scrum teams, chances are that they will be stepping on each others‟ toes constantly. The problem will be more acute if the Sprint or release cadences of the teams don‟t align.

If possible, spend some time re-organizing your code base to minimize the inter-module dependencies. This exercise is well worth the effort as the code will be more modular and less tightly coupled, which in turn will create better „code‟ conditions for the Scrum Teams to do their job, and enable the teams to more quickly produce more business value.

11. Do you have good Unit/Automation test coverage?

At the heart of Scrum is the delivery of potentially shippable software at the end of each Sprint. For this to happen, test automation is a must. If you do not have a comprehensive set of automated unit tests that are tied to your build system, you are likely to spend more time in testing and debugging than necessary, and it will be difficult to end each Sprint with a fully tested (and fixed) system. In addition, automated tests give the team confidence in making changes; they know that if the change breaks other parts of the code, it will be immediately visible.

Strengthen the foundations of your code base by adding as many unit tests and automation tests as possible. Teach your developers the art of Refactoring, if they don't already know it. Tools like Emma, Jester and Cobertura will help you measure the coverage of unit tests.

Tools

12. Do you have good collaboration tools?

This item is critical for the geographically distributed teams. Agile requires a close interaction among team members, so you need to ensure your team has all it needs for effective communication. Use video conferencing, telephones, emails, instant messaging, and Skype as much as possible. VNC, WebEx, Sococo are other useful tools for the team collaboration. If you are planning to introduce a tool such a Rally, VersionOne, or ScrumWorks, make sure the teams themselves have an opportunity to evaluate them fully before making a decision.

13. Do you have a source code repository replication system?

This item is more relevant for multi-location teams. Nothing can be more frustrating for your remote teams than accessing the repository on a slower network. Due to shorter release cycles, your teams would be doing more frequent checkins, checkouts, branching, merging than they normally would if they were using traditional methodologies. Make sure you have a fast, reliable repository replication solution in place before you roll out Scrum.

14. Is your build and deployment system fully automated?

It is difficult to imagine a modern software development organization not wanting to automate their build and deployment activities. Design your build and deployment processes to be completed in a short time, say, 30 minutes. This should include executing the test cases and certifying the build. It is even more preferred to have a continuous integration (CI) policy before you move to Scrum. The CI will highlight the build/integration issues and help the teams identify and fix the issues quickly. When the teams are working in short time-boxed iterations, any time gained in their iterations will be valuable.

Alternately, if you require a lot of manual intervention in the build and deployment, your teams‟ velocity is going to be affected.

Others

15. Do you have adequate Dev and Test environments?

If you would like to have dedicated Dev and QA environments for individual (or groups of) Scrum Teams, you need to plan them in advance. You also need to ensure you have enough hardware, software licenses, and IT support staff to build or maintain those environments. Since budgeting, getting approvals, ordering, hiring, and training take a while, you need to plan this well in advance.

16. Do you have enough monitoring/health-check systems in place?

If you are working with a large number of environments and each of these environments has multiple servers, databases, networks and other third party components, you need to have a robust monitoring system in place. Zabbix and Hobbit are a couple of good tools you could consider for monitoring the health of your systems.

Conclusion

Due to the wide philosophical differences between traditional and Agile methodologies, a few organizations are facing challenges and getting frustrated with their results while adopting Agile. A lot of these challenges can be met effectively with decent preparation. This article presented a checklist of items to be considered along with a mind map for the benefit of teams getting into Agile.

References

1. Scaling Lean & Agile Development, Thinking and Organizational tools for Large-scale Scrum,Craig Larman, Bas Vodde, Addison Wessley 2009
2. Scrum & XP from Trenches, Henrik Kniberg
3. 10 ways to screw up despite Agile and XP, Henrick Kniberg at Agile 2008, Toronto
4. Art of Agile Development, James Shore, Shane Warden, O‟Reilly Media 2008
5. Agile Testing: A practical guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory

How Effective is your Agile Team?

By Rowan McCann

Introduction

Back in the '90s, self-managed teams were gaining popularity, but they had a high rate of failure mainly because team members lacked people skills. These ideas of self-managed teams were borrowed by the Agile movement when, in 2001, they formulated a ‘new’ way of working, based on Agile principles. These principles value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

For these ideas to work in practice, Agile team members must know something about teamwork, and this means understanding a lot about human behavior and why people do the things they do!

Agile team members are usually composed of highly skilled and knowledgeable workers who strongly value their independence. Some are worth more to an organization than the people who manage them! Many software developers are quite introverted, preferring to interact with their computers rather than people. In my experience, organizations hardly spend any time on people skills and spend no time on the even more difficult concept of what people need to do to ‘self-manage’ into a high-performing team. I’ve had to learn this in the world of experience. I wonder how many readers find themselves in a similar position.

If you look at the Agile website, you’ll find that the emphasis is on ‘engineering best practice’ and tasks rather than team processes. Similarly, many project managers are used to old-school leadership where they are more comfortable with control and the power that goes with it. For Agile IT teams to become high-performing they should immediately spend time helping the team to initiate the process of adaptive learning. This requires a focus on behavioral skills.

The Nature of Work

A starting point for all teams is to understand the nature of their work. One of the best models describing this is the Types of Work Wheel developed by Team Management Systems. Through their research they were able to identify eight distinct ‘Types of Work’ that need to be undertaken by all teams, regardless of their industry. There are important lessons here for our industry of Agile Project Management. The eight work functions are listed below, with the approval of Team Management Systems.

The Advising function is associated with the gathering of information from all stakeholders and responding quickly to changing requirements. It involves keeping up-to-date with developments inside and outside the organization and sharing advice with others to help them in their work. It requires a transparent flow of knowledge of 'what' is going on and 'where,' and a focus on 'consulting skills' so information can be gathered quickly, accurately and effectively.

The Innovating function involves generating new ideas and new ways of doing things. This requires the development of creative problem-solving skills so the team remains one step ahead of its competitors. To do this well requires original thought, imagination and innovative thinking.

The Promoting function is concerned with the identification of opportunities and the 'selling' of these opportunities to others, both inside and outside the organization. It often involves the application of influencing skills and the making of presentations to others. It can also involve communicating the team or organizational 'vision.' High visibility throughout the organization may also be required.

The Developing function is associated with the turning of concepts into 'reality.' Ideas are worked on to produce practical products and services. In many cases it may also involve developing workable and practical solutions when problems arise. Agile teams need good analytical skills so that requirements can be quickly prioritized, enabling accurate estimates of iterations and burn down charts.

The Organizing function involves organizing people and resources efficiently by setting clear goals and objectives and making team members accountable for their actions. It is also associated with the implementation of quick, effective action when problems occur, so the planned outputs are always capable of being achieved. Essentially, that the organizing function ensures that the work of the team is structured and focused towards common objectives.

The Producing function focuses on outputs, ensuring that iterations are completed to high standards of effectiveness and efficiency. It is the function associated with the regular delivery of releases and other services. It requires a systematic approach to work and an emphasis on the delivery of products on time.

The Inspecting function requires an attention to detail and an emphasis on the monitoring of systems, contracts and outputs. It is also associated with a focus on accuracy, ensuring that work outputs are always delivered to the right quality. This function is the classic control function where procedures are regularly monitored for their efficiency. It’s often a core feature of the sprint review process.

The Maintaining function is a support function which ensures that proper standards of conduct and ethics are upheld and that quality is maintained. It is also associated with supporting others in the team so team processes follow agreed ground rules. Personal conviction and loyalty are often important to this function as is an interest in helping others.

Work Preferences

For teams to be high-performing it’s essential that these eight Types of Work are done well. But Team Management Systems has discovered that rarely does anyone actually enjoy doing all of these functions. People show distinct ‘work preferences’ for maybe just two or three of these activities.

Work Preferences are dimensions of individual differences in tendencies to show consistent patterns of relationships, thoughts, feelings and actions in the work environment. Work Preferences determine the conditions we all set up to allow our mental and psychic processes to flow freely. Preferences are usually transparent and are often the first thing we notice in others – ‘He’s rather quiet, isn’t he?’ or ‘She never stops talking.’ Some people prefer to think things through on their own whereas others need to talk out loud to clarify their ideas. Preferences are readily visible to others and are usually the basis of first impressions.

When we are working to our preferences we set up conditions where our psychic energy can flow freely. If we are more extroverted we like work where there are lots of interactions with others, both inside and outside the organization. If we are more introverted, then we like conditions where we can work on our own with few interruptions and meetings. Under these conditions our energy can flow freely with minimal resistance. Just as electrical energy generates heat when it meets resistance, our psychic energy generates tension and stress when it has to flow through areas that are not our preference.

My preference is to work in the Advising and Innovating areas on the Types of Work Wheel and I don’t really enjoy Promoting or Organizing activities, so wherever possible I’ll spend time thinking about new ideas or finding out as much as I can about the project.

What happens in an Agile team is that there’s likely to be an imbalance when you look at the work preferences of all the team members. If everyone is like me, then there’ll be a tendency to give priority to making changes and incorporating the latest ideas. Teams like this may have the weakness of never tracking their burn-down charts!

Other weaknesses occur if everyone enjoys just Organizing and Producing. Your team may be well organized and on-target, but is it really delivering what the stakeholders want or indeed need?

So, if your Agile Team is to be truly effective you must understand the work preferences of all team members and look at the preferences balance. It will give you an immediate picture of strengths and weaknesses, as far as teamwork is concerned. Information like this helps ensure that everyone’s work preferences are matched to the critical demand of the job they have to do. Where the match is high, our energy flows freely, we are more likely to enjoy our job, stress is lower and we feel happier at work. But all eight work functions must receive the priority they need and never be relegated to lower importance.

Linking

The center of the Wheel describes Linking. It’s an activity responsible for integrating and co-coordinating the work of the team. It’s not a preference but a set of important skills that applies individually to team members and collectively to the team. Ideal Agile teams have a low level of leadership control and a high level of autonomy. In these situations team effectiveness largely depends on six key skills of People Linking, Active Listening, Communication, Problem-solving and Counseling, Team Relationships, Participative Decision-Making and Interface Management.

For People Linking to be effective it’s important for all Agile Teams to establish a set of ground rules. These are an agreed set of acceptable, individual behaviors that define how team members will interact. Usually they comprise 10-20 statements that are posted in the team meeting room or on the Agile Project Management Platform, agreed on at the start of the project and reviewed after each iteration. If a team member is unhappy with a particular team process then it’s easy to begin a discussion just by referring to the relevant ground rule that everyone has already agreed to. Conflict is often avoided by this simple process.

Global Delivery Model - Agile Practices in Defect Fix Phase

By Vetrivel Shanmugasundaram

Integration Testing Phase

I am sure most of us have gone through a rough development phase during which we would have considered implementing agile methodology. It is very disheartening to see our favorite project being trapped in the testing phase with a never ending loop of defect fixes and disrupting the whole idea of an agile delivery model.

The defects fix phase starts as the development team completes the coding and unit testing, and moves the code to the integration testing and/or system integration testing phase (Please refer to the figure below)

This phase is very crucial because the software is not yet stable and the test scenarios covered during integration / system integration are wider than the scope of unit testing. Once the defects are logged in large volume, the development team may point to a “lack of design time,” refer to an e-mail chain, or worst case, compromise on their software engineering practices to do a “quick-fix.” Traditionally, software development vendors may trim the size of the development team during the development support phase, which does not help either.

If that is the problem, then what is the solution? Frankly, there is no “one” solution to the problem. I have tried to present a set of best practices based on my experience that will help us address this issue. I’ve included a few example problems; each is paired with a best practice that can help address the problem. I have also included additional information to help you decide on the best course of action.

Note: If you are just entering the defect fix phase, you may want to adopt any / all of the below practices, but if you are already in the defect fix phase, I would recommend you start with the Defect Retrospective (practice no. 5) to better understand the trend and choose the right practice.

1. Defects (Fix) Showcase

Problem: Too many re-opened defects

Solution: This practice would enable the development team to demonstrate the defect fixes to an internal tester (can be another developer) using the developer test cases. The internal tester also runs through the developer test cases and validates the results. Therefore, the concern actually repeats the tests in the development environment independently.

1. Developer sends an e-mail to the development lead to review the code changes.

                          a. Development lead provides feedback (if any)

                          b. Development lead sends an approval e-mail on the code

         2. Development sends an e-mail to internal tester (another developer) for a defect fix demo.

         3. Internal tester reviews the defect fix and approves it.

         4. Developer checks in the code on continuous build server.

This practice initially appears to consume more time, but a defect re-opening could be due to an oversight in unit testing and a functional (mis)understanding. It will be worth the time and effort, and the development team will soon be accustomed to the practice.

Suggestion: Choose the best person with domain knowledge for the internal tester role.

2. Defects Stand-ups

Problem: Lack of prioritization on defects and defects fixes span across multiple vendors.

Solution: This is similar to the daily Scrum, with a specific focus on defects. The questions asked in the meeting could be:

• What defects have you fixed from yesterday to today? (defect – id and description)
• What defects are you planning to fix today? (validate the priority)
• Are there any issues that prevent you from fixing these defects?

During these discussions/meetings we could discover that more than one person is working on the same defect or that someone is working on a defect that is considered closed.

Suggestion: Update your defect- tracking tool after the stand-up.

3. Defect (Daily) Iteration

Problem: Too many defects to manage, and the development team is not making any progress. Team is not being very productive.

Solution: A worst case scenario involves a very busy testing team and a not-so-busy development team. It is absolutely important to work very closely with the development team if you are expecting a considerable amount (100, 200 or say 1000) of defects.

You may need to :

• Organize your development team in shifts (to enable 24-hour fixing)
• Have a daily progress review (preferably mid-day)
• Use a defect closure plan as defined below

• Date column: The latest date will be recorded as the first entry (insert a new row at the top)
• The ‘During the day’ section tracks the defects fix velocity as defects fixed per day. It can be used to measure the testing velocity as well
• The ‘Close of the Day’ section tracks the development team’s ability to maintain the velocity by tracking themselves towards planned and actual closure

It may look complex, but once implemented you can experience good and productive results.

Suggestion: Leverage the test manager to update and circulate the template

4. Defect Scrum

Problem: Too many design Issues or requirement gaps.

Solution: This is relevant while you deal with critical or “showstopper” defects, which are marked as ‘Design Issue’ or ‘Requirement Gap.’ You need to pay special attention and monitor the situation very closely (a Defect Retrospective can help here).

This scenario would require the development and design team to arrange a 30 minute meeting to understand the critical defects and agree on the implementation. The defects Scrum needs to include the Product/Business Owner to close the "Requirement Gap."

Suggestion: You need to establish a standard time for a regular Defects Scrum.

5. Defects (Fix) Retrospective

Problem: Unwanted closure codes.

Solution: Often, the defect root cause does not yield valid details due to the various invalid closure code, and sometimes the list of closure code exceeds the count of defects. This practice deals with consolidating defects of all kinds and generating a weekly report to review the spread of defects by closure code.

This will help you to ensure the following:

• All defects are closed with a valid closure code
• Logical grouping of closure codes – e.g. Invalid data, corrupt data, wrong data can be classified as invalid data
• Take corrective actions to avoid recurring defects – e.g. Identify the reasons why we have invalid data

Suggestion: See if this report can be automated.

Iterative vs. Agile

By Manoj Vadakkan

Recently, I happened to overhear and eventually involve myself in a conversation between two Project managers. They were discussing why Project managers have to define what "yes" and "no" means to the team – after all, people have understood these words since kindergarten. The story is very familiar to Project managers. Every week, team members report that their activities are on track; the project status is green, and everything is going as planned. Everyone is happy until the project is about three quarters complete, and suddenly one team member reports that he is not on track anymore. Suddenly, dates need to be changed and the schedule needs to be updated. The Project manager inevitably asks the important questions, "Why have you been telling me all along that you were on track?" "Have you been hiding something?" "Don't you know, 'yes' means 'yes?'" Obviously, the Project manager cannot go to the sponsor with the bad news, and the team has to work overtime to get the project back on schedule.

This reminded me of a story that Alistair Cockburn once told about a student trying to do his reading assignment. The student had to read a dozen stories and answer a few questions afterward. He had a week to finish this assignment. If I were the student, I would have spent every day just thinking about reading those books, and would have postponed reading each day until Sunday afternoon when I would cancel everything and start reading the first book. But this student was different; he was a good planner. Upon getting the assignment, he considered the size and difficulty level of each book and figured out he had to read a couple of books every day to have enough time to go through the questions and answer them. He spent three quarters of the week just reading those books. He was on track until he started looking at the questions. He then realized there were things he didn't pick up on or pay close attention to when he was reading them for the first time. This meant he would have to re-read many of those books. This also meant he would have to spend a lot more of his weekend on his homework than he had planned. Good thing he had some contingency built in to his schedule!

Could he have done better by scheduling the work in a different way? What if he had quickly read one book, and then immediately looked at the questions? Then re-read, but this time paid closer attention to where the answers were coming from. What if he had changed his approach a little further? What if he had not read the books first but considered the goal – answering those questions. Why not read the questions first and specifically look for the answers in the books? Does this sound like test driven development (TDD)?

Let’s think about how the student measured his progress. In the original plan, he was checking off activities as done (reading each book) each time he finished a book. He was on schedule during the reading phase. But the real goal wasn’t reading books. He wouldn’t get any credit from his teacher for just completing the reading. His success was measured against how many questions were answered and how well he answered them. So measuring progress against reading wasn’t realistic. On the other hand, if he had reviewed the questions first, then read those books to answer the questions, and measured his progress against answering questions, that would have been a better measure of progress. If you think about this in the software development world, this is similar to an iterative process. You complete (read) a set of stories and go through the tests for just those stories. But is this approach good enough? Is this agile?

Let’s take this a step further. I realize this may not work well with the homework example, but bear with me. Imagine that the student has the option of taking a set of answers from one book at a time to the teacher and getting feedback. The teacher might have said that a one-word answer was not good enough, and that she was expecting a paragraph, or that she was expecting correct spelling. In this case, the student could have made some changes to the way he produced these deliverables (answers) and could have scored better on each subsequent book.

One could argue that the teacher should have defined all the success criteria (minimum number of words in the answer, no spelling mistakes, etc) at the beginning of the week so everyone would know what they were measured against. I agree; the teacher should have. Translating this to software development, one could argue for collecting all the requirements upfront and getting a sign-off from the user. Then again, we have seen so many times that requirements are a moving target. We can get sign offs and freeze those requirements, only to find that we have to make changes later. Sure, we can keep complaining about how changing requirements interferes with our plan. However, at the end of the project, we can call it a success only if we deliver what the customer really needs, not what we signed off to do in the beginning. We can do that only if we are open to change and if we are getting frequent feedback. Getting frequent feedback from the user and making changes accordingly is the heart of agile. It is not enough to iterate through user stories or components.

As for the developer in my first example who kept saying he was on track; he may not have been hiding anything or lying at all. He may have been just following the plan like the student reading the book and checking off activities on his schedule. Or he might have meant something that we hadn’t been paying attention to such as: "Yes, we are on track but I haven't tested this with the other components."

Sometimes the organizational structure and/or process do not lend itself to getting frequent feedback from the user. What do you do in that situation? Tell me a story about your project.

Those devilish actuals

By Henri Stegehuis

About a year ago, I had been struggling with an important "don’t" of Agile Scrum, actual hours. In the first phase of Sprint planning we take all of our actual hours based activities and transform them to ideal hours. The focus factor or productivity factor transforms the hours for these activities to the desired ideal hours. After this initial process actual hours are expelled from current Sprint.

It may take up to a couple of Sprints to get the team really used to the ideal hours way of thinking. Once they understand and have experienced that removing slack from the estimated hours is compensated by using the productivity factor and that the team has control over this productivity factor, this Agile Scrum concept is in place. During the first few weeks as a ScrumMaster you will find yourself pleased with how planning and estimating are addressed in Scrum.

Then reality is catching on

My company’s biggest assets are we, the employees. We offer software solutions; we offer knowledge and broad experience. It all comes down to selling hours and accounting for them. With fixed price projects this problem is easy to overcome by assigning invoice schemes to Sprint deliveries. However, with non-fixed price projects, the accounting is mostly hourly based.

Potentially, the accounting problem with our contractors could be solved by defining certain effort milestones. There is a third party that is really a tough nut to crack, and we need them instead of them needing us, the government. A lot of innovative projects are subject to subsidies. Every claim for a subsidy has to be accounted for based on actually spent hours. The Burndown chart gives no information, as it is intended to, about actual hours spent on a task. For Agile Scrum the past is not interesting but the future is, can we make it in time? Accountancy for contractors or subsidies though lies in the past.

How to integrate

This has kept me busy for a while. I need actual hours, but I don’t want to track them; it is just for accounting. Also, the team must never get the feeling of being micromanaged. Equally important, upper management may not see these hours; I just spent weeks getting them familiarized with ideal hours and the Burndown chart. I don’t want to give them a reason to return to using old methodologies.

The first approach we tried was having the team write down the actual hours once a week on a separate list. This was not working for two reasons. One, the relation with the real tasks became loosely coupled. If I ever had to explain myself on an audit I wouldn’t be able to do so. Two, there were two lists and the team members became irritated. They demanded a solution on the Scrum Board.

Because we would like to maintain a one-to-one relation between Scrum Tasks and actual tasks, we decided to use the Tasks cards. We used the back of the sticky notes to write down actuals information. At the end of the Sprint, I would take down the Scrum Board, and fill the role of Project Manager by administrating the actuals. The consistency was in place and the administrative actions for recording were relatively easy and outside scope of the team and upper management. The recording at the end of a Sprint, when the result was already in place, was so late that the actuals gave no up-to-date, controllable information.

Unfortunately this solution was not working for the team at all, again for two reasons. One, mixing ideal and actual hours in during the Daily Scrum was making people schizophrenic. Two, the other reason might seem over-sensitive, but turning over the sticky-notes was an annoyance, especially while we already had to tape down the sticky notes because they do not seem to really stick (we would always find a couple of them on the floor the next day).

The last approach though had given us valuable input. While we had to tape down the task cards any way, we didn’t have to use the sticky notes. We have decided to make task cards with a default layout. We still use different colors for non-default tasks. Three-fourths of the new task cards is reserved for the Sprint data and one-fourth with a background pattern is reserved for actual recording. In the morning Daily Scrum, we discuss ideal hours, and before we go home, we write down actual hours for that day.

Conclusion

In recent Agile Scrum projects the layout of the Task cards has changed mostly because of the team’s personal tastes. The concept has not changed and the team agrees with the current solution. We know actuals and ideals are conflicting, and it is not Agile Scrum. Now, we separate them by having a different background on the Task cards, and speaking ideal hours the entire day and accounting for actual hours at the end of the day.. We feel that we have found the best solution to secure our sources of income and still follow the Agile Scrum methodology.

Scrum in old fashioned software environments?

By Christoph Oberle

The “normal” Scrum project

When I look around in the Scrum community, I wonder whether Scrum is only suitable for modern software development. All these shiny, new ways of making really cute, web- based software, with modern source repositories, automated unit and regression testing tools, and other fancy stuff. If you look at typical job postings for Scrum specialists, you see the same situation: It's all about modern, web-based systems and applications.

How about legacy applications in an old-fashioned insurance company?

Because I was working in a “classical” software environment, I wondered why Scrum was not more frequently used in those environments.

Some excuses for not using Scrum include

• “We always do it like this; there is no need for change!”
• “I like the ideas, but I cannot imagine how we can deliver something in only three weeks time, even the regression test will take longer!
• Our processes prevent us from using the Scrum methods, we have to do X, Y and Z, otherwise we will not succeed.”

I think there is a fundamental reason for the reluctance to adopt Scrum in those software environments, and it is exactly the reason why Scrum was invented.

A typical example in a “classical” environment

Before we go into details let me tell you a short story about test automation of letter production. In an insurance company, the focus on regression testing of the software system was very high, because all the standard letters, which were sent to the customers, had to be tested manually. They had to be inspected manually and have been visually compared to the former versions. It was obvious that the effort to automate this process would realize its ROI even in the first project when it was applied. Nevertheless the automation was never implemented. It had been scheduled into each project, but because of time constraints it was always de-scoped in favor of some more “real” functionality.

How could this happen? Because the team who was able to implement the automation (the developers) did not get any benefit from it, and the team who was asking for the automation (the testers), was not able to implement it. Therefore it was delayed for years.

So what and who caused the effort to fail?

This question is not easy to answer. In every project the Project Manager made the right decision in de-scoping the automation task. It was always the right decision because it stabilized or even rescued his project. So if it was not the Project Manager's fault, who was to blame? Upper management should not be made responsible for the Project Manager’s decisions, which are real day-to-day work and should never be discussed at their level.

So, if nobody is guilty, then the process must be at fault. The established process leads to the situation where the automation task is always de-scoped. Also, it makes it less urgent than some other tasks in every project where it is included.. To summarize, there is no control in place that is able to monitor the effects of de-scoping the automation task in a global “cross project” view.

What rules must be changed to get the automation task done?

1. Obviously the testers must have the authority to request the development from the developers.
2. The Project Manager must not be able to de-scope the task in favor of new requirements.
3. At a minimum, upper management must be aware of any decision to delay the task

If we think about the probability that we can to achieve the above changes, I'm not too optimistic. How should I empower the testers to prioritize the developers' work? How should I limit the project manager, so that he is not allowed to de-scope the task? How should I make these tiny project decisions visible to upper management? All these changes are prohibited by the process. The process' rules prevent them.

And in a more “agile” environment?

Now let's have a look at a Scrum set-up. How would this situation be handled in a Scrum organization?

In a Scrum organization, the team would be cross functional, where all relevant parties participate. In this example the testers and the developers would be in one team. The team could not be successful if all tasks were not “done” at the end. And after the team has accepted a task it is responsible and stays responsible to get it done.

In a Scrum organization the product owner cannot change the contents of a Sprint. He cannot de- scope a task in favor of another task during a Sprint.

In a Scrum organization, if a task is part of a Sprint and it cannot be delivered, the managers are made aware at the end of the Sprint...
In a Scrum environment the problems in our example are resolved.

If it is this easy, why don’t all organizations just switch to Scrum?

It's all about agility

The problem is the transition to Scrum.

First, you need to have one team which is representing all aspects of product development and is capable to fulfill all the needed tasks.

To achieve this, the established walls between the different roles in the software creation process have to be torn down. And those walls have been so comfortable for all participants. (it is much easier to blame process as opposed to at a colleague). And if a development is not yet ready, a tester has no problem complaining about delays in his plan..

In my project experience I once tried to establish Scrum practices in a kind of a “silent roll-out”. I wanted the team to work together across departments and roles, but I realized that this was not possible. You cannot build a “real” team without letting the team define its rules themselves. And you cannot change the rules that have been used by the established processes, without explicitly changing the processes.

Second, you need to establish the Scrum roles. You need a “real” product owner, who knows how to play his role. You need a ScrumMaster who fights for his team and protects it from outside influences.

Third, you need to transition to a time-boxed approach as soon as you start with Scrum. The time box is the most revolutionary change to the classical environment imaginable. Once, when I wanted to establish some Scrum-like practices in a project, I convinced the IT line manager and the project manager to have fixed development intervals of 3 weeks. We had a pipeline from development to testing and finally to user acceptance testing. But as soon as we got a delay in development, the project manager wanted to have the dates shifted to get more results as soon as possible. The benefit of having a time-boxed approach and agreed handover dates from team to team, was sacrificed for a potentially “more complete” next code drop.

You need all of this to start with Scrum. And don't be overly optimistic. It will require discussion, training and good leadership to transition.

What did we learn?

As I stated earlier, I think there is a fundamental reason for the reluctance to adopt Scrum in “classical” software environments, and it is exactly the reason why Scrum was invented.

In some organizations, the established processes are stabilizing themselves even if they are not helpful. There is no culture for changing the established processes.

In some cases, the established roles in a “classical” environment do not take responsibility for the whole. There are situations where team members make excuses because something isn’t their responsibility. Also, individuals are not empowered to make decisions.

In “classical” environments, time and cost are less important than quality. Because of this approach, delays are widely accepted and at the end of the project de-scoping of less prioritized tasks is typical. This leads to projects whose status cannot be measured continuously.

In other words: with Scrum you constantly measure your performance, empower your team, and constantly improve your processes. These elements of Scrum are crucial for an organization to improve its processes and to accelerate the release cycles and the features delivered in each release. Unfortunately the inability of the processes in “classical” environments to support these improvements leads to the difficulty in implementing Scrum in those environments.

Implementing Scrum is hard work, but it's worth the effort.

Yin Yang & Project Management

By Jann P. Thomas

The Chinese philosophy of yin yang is based on four laws.

1. Yin and Yang are opposing. Yin and yang describe the polar effects of phenomena.  For instance, winter and summer would be the yin and yang for the year.  
2. Yin and Yang are mutually rooted. They are complementary qualities that make up the whole phenomena, just as daylight and night together make up a single day.
3. Yin and Yang mutually transform. That is, a change in one quality causes change in the other.  For example, snow melting in the spring cause a rise in the river.
4. Yin and Yang mutually wax and wane. There is a dynamic equilibrium between Yin and Yang; even as winter days grow shorter, the night grows longer.

Agile and traditional management methodologies have a yin yang relationship that is felt quite keenly by many project managers charged with moving a software team toward agile practices. Handed an edict from on high or a mandate from the software team’s own grassroots effort, the manager must figure out how to function in his new reality. Will the developers now have free reign to do whatever they want to do?  Who will be in control?  What is the job of the manager on an agile development team?  How can I move from command and control to cooperation?  Learning agile’s guiding principles and how their inherent balance translates to concrete actions is the first step to a truly productive conversion to Agile.

Balanced Principles

Like the yin yang philosophy, agile also has four guiding principles—principles that are also opposing, mutually rooted, mutually transforming, and mutually wax and wane. These principles are captured in the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Let’s examine the yin and yang of these guiding principles and see how it can help guide a project manager in converting to agile.

Individuals and Interactions & Process and Tools

This principle lends itself to several concrete actions. If possible, remove cubicles and have the team together in one shared workspace. Schedule daily stand-up meetings for each team member to discuss what they did yesterday, what they are doing today and what blockers stand in the way of completing work. Remove any blockers or impediments to delivery, whether that means buying tools or putting a process in place to encourage productivity.  

A process? Yes. Agile is not anti-process. For example, take the familiar case of bringing in an enhancement to a product in mid-iteration rather than completing the work originally scheduled for that iteration. To do this effectively and transparently, the agile project manager must create a process for bringing in new, unplanned work. This process must also include recording what tasks were moved out of the iteration to make room for the new work so that the whole team, including the customer, can see and understand not only what changes occurred, but what the costs of those changes were.

To be an agile project manager is to be introspective. A good agile project manager should review and question all of the organization’s existing and developing processes. Is the process appropriate in an agile environment? Does this process help or hinder the team’s efforts to deliver working software? In addition, iteration reviews (retrospectives) give the entire team the opportunity to evaluate any changes they have made to their processes; the team keeps the ones that work and drops the ones that don’t.

Working Software & Documentation

Working software is the goal of every software project. Traditional approaches, such as waterfall and spiral methodologies, rely on the concept that the requirements of the product can be precisely defined before implementation begins. Agile development practices differ in that all software project activities, from requirements to installing production-ready code, are delivered in small time chunks called iterations. An iteration can range from one week to four weeks. The only fully defined requirements are the ones that the development team is working on in a particular iteration.

Agile teams and agile project managers are not opposed to documentation; rather, agile is focused on just enough documentation, just in time to create working software. On agile teams, requirements are developed only when they are ready to be used (just in time), which often results in a smaller set of architectural diagrams, use cases, and functional specifications. The documents that are created and maintained are only those that are necessary for development (just enough). If a document has outlived its usefulness, it is jettisoned by the team. Producing documentation is appropriate as long as it supports the working software.

Collaboration & Contract Negotiation

All software projects have some type of contract, whether implied or explicit.  Implied contracts are used most often for internal software teams; explicit contracts are used for things like hiring an outside software team for a temporary project. The one thing that both of these contract types have in common is a date.  Most project managers are familiar with the three sides of the constraint triangle: scope, time, and quality. If time (completion date) is fixed and high quality a priority, the only area for compromise is scope. Negotiating with the customer or product owner on scope is a key component of agile project management. Only the product owner knows the importance of a feature. Only the product owner can make decisions on the relative position of features and which features must be delivered first. Only the product owner can decide that rework of an existing feature is more important than new feature development. The fact that the product owner is part of the team and can see the work as it is completed allows agile teams deliver value earlier than they could using traditional software methodologies.

Responding to Change & Following a Plan

As anyone who has built a house can attest, having a detailed set of blueprints is only the beginning. Compromises and changes are expected and inevitable prior to final delivery. The same holds true in software. Just as a homeowner would not give the blueprints to a builder and never visit the construction site, product owners for software projects shouldn’t just hand the development team a list of requirements and then never see the interim product.

Agile projects allow the product owner to visualize the progress on his project as code begins to work. The product owner is empowered in agile projects to finalize details as work progresses. Returning to our building analogy, during construction, the homeowners pick out fixtures, choose cabinet colors, and sometimes move walls as they begin to see their home emerge. Similarly, the agile product owner fills in the details of his own requirements (or changes his mind about his requirements) as he begins to glimpse the working software. If the product owner decides there needs to be a change in something already developed and that change is more important than new undeveloped features, the project team makes that change. Agile teams, like home builders, respond to change.

An Agile Coexistence

Just as yin cannot exist without yang, the elements that agile practitioners value (working software, collaboration, change, and interactions) do not exist without their corresponding yang (documentation, contracts, plans, and process). These mutually inclusive agile principles also follow the laws of yin and yang. Agile principles are opposing: there must be a plan but the plan will change. Agile principles are mutually rooted: the contract, whether implied or explicit, will require negotiation, so invite the customer to collaborate with the team. Agile principles mutually transform: the team needs some sort of blueprint of what to build but only as much as makes sense and is reasonable to maintain. Finally, Agile principles wax and wane: all software teams need processes and tools to know their boundaries but individuals interacting daily build the best software.