Create Ground Rules for the Team

Suggested Time Box: 60 minutes

Concept

In the context of an Agile project, is a list of operating rules that address the team and not the product or project. It is a set of basic rules and behaviors agreed on by the team. The Charter can be very simple and focused and amended as needed. This should also be posted along with the High Performance Vision. Cultural and individual sensitivities should play into how your individual team create their charter. Define behaviors and communication habits that are acceptable and unacceptable to you.

Reasons

Use the Ground Rules as a guide during retrospectives, or when the team is getting off track, struggling through a problem, or morale is waning.

Some of Ideas for Team Charter

  • Single-thread meetings and conversations (don’t try to multi-task)
  • Keep computers closed during team meetings to make them concise, focused, and efficient
  • Respect email usage
  • Communicate openly
  • If uncomfortable with communicating directly to the team member, work with Scrum Master
  • Disagree in a constructive manner
  • Show respect to the other team members if you disagree on something
  • Keep a sense of humor
  • Turn off cell phones during key team meetings
  • Report all planned vacations for appropriate resource planning
  • Be on time for meetings
  • Call in for meetings if late
  • Report sicknesses and absences to the team in a timely manner

Action Plan

  • Brainstorm ideas of acceptable and unacceptable behaviors for your team
  • Capture and post the Team Charter in a public place next to the High Performance Team Vision

Define the High Performing Team

Suggested Time Box: 60 minutes

Concept

An Agile team is not just a team. It is a high-performing powerhouse. Or, at the very least, it should be staffed to become a high-performing powerhouse. In this section you will define what your team’s vision of high performance should be. When holding each other accountable as a team, or addressing low team morale, usually a characteristic that makes up this vision of high performance is lacking in some way. Lyssa Adkins in Coaching Agile Teams uses a Tree as a metaphor. You can use a building with a foundation as a metaphor. Whatever metaphor your team uses, the root or foundational characteristics are as follows:

  • Communication, Feedback, Commitment, Focus, Courage, Respect, Openness, Simplicity

After defining where your team is on the about foundational level (I mark them blank, red, yellow, or green as we mature on my teams), build out your high performance team vision.

Why?

This exercise uncovers team ideas of high performance. A team that self-defines high performance starts capturing habits of high performance and working to next levels. This High Performance Vision should be displayed prominently in the team room, on the team site, and on the various information radiators for high visibility. If the team is getting off track or struggling somewhere, this vision will often provide a seed of thought that helps the team self-correct and get back on track to their goal of high performance.

List of Ideas of High Performance

It is unnecessary to list all of these things as high performance. But, starting from a blank slate to create your team’s high performance team vision can be difficult. Below is a list of characteristics you may choose that you want to define your team or these can provide a seed of better ideas for your team.

Open to ideas, self-organizing (team decides who does what, define own tasks), industry reading, self-aware (strengths/weaknesses), pair programming, accountable to team, admit mistakes, ask for help, take initiative, new ideas, action plan for self, highly self-motivated, humor, honor, trust, honesty, kindness, humility, willingness to go extra mile, responsible, prioritizing, flexible, communication, autonomous, self-starting, independent, team player, ask questions, not a drain on other team members, able to mentor others on something, modest, humble, strong desire to contribute, strong work ethic

What do you think?

  • What does high performance mean to you?
  • What  characteristics define high performance?
  • Who do you want to be on this project?
  • How do you want to stretch yourself?
  • Are you willing to hold each other accountable to those ideals, yet still giving each other time to grow into the role?
  • Are you willing to be courageous?
  • Think of people whom you consider high performers: what characteristics do you admire and think make them higher performers?

Action Plan

  • Determine your team’s High Performance Metaphor (Tree with Roots, Building with Foundation, Circle with Core, etc.)
  • Add the Core Characteristics listed above
  • Identify team ideas of high performance
  • Take pictures or capture and post visibly around team room, information radiators and web

The Team

Suggested Time Box: 30 minutes

Concept

Concepts around the Scrum team are different than traditional projects. This chapter discusses the main differences.

Action Plan

  • Review questions
  • Identify areas for team to work on

Cross Functional

The team is a unit and cross-functional. The simplest way to look at it is there are three roles: Product Owner (gate-keeper for the product), Scrum Master (protector of the process), and team members. Every team member is expected to be accountable and contributes to the success or failure of the project. If the team is not cross-functional, this is an Agile ideal the team should strive to develop over time.

High Performing

Strong, high-performing teams exhibit behaviors of having a strong desire to contribute to the success of the team, humor, self-awareness of strengths and weaknesses, modesty, humility, willingness to admit mistakes and learn from them and correct them. This combination of characteristics contribute to team accountability and even if you don’t directly report to each other.

Self-Organizing

The goal of treating the team as accountable, high-performing, and self-managing can be an adjustment for all involved. Team members as well as management will need to adapt to this approach. The team has right to hold each other accountable. If someone is not pulling their weight in their role, the team has the right to hold them accountable and request a replacement if necessary. 

Committed vs. Involved

There is a cartoon strip circulated in the Agile community about a Pig and Chicken wanting to open a restaurant together. The pig declines “because he would be committed but the Chicken would only be involved.” The team is directly involved

This metaphor circulates in Agile circles because the people who are on the team producing the actual product are the Pigs (committed to the project) and are the only ones allowed to speak at Scrums and Retrospectives. The Chickens (any stakeholder with a vested interest in the outcome of the Product) has a voice with the Product Owner and Scrum Master. This focuses the communication on the leaders and protects the team’s development time and allows them to grow into a self-assessing high-performing team.

Team Size

The size of the team is critical. Agile idealists encourage small, focused, collocated teams of 6-8 people. When you get to 10 people you are teetering on the brink of too big. Additional people means additional communications overhead and some diminishing returns on productivity. Do not make the assumption that you can multiply the productivity of the team by adding people. The law of diminishing returns starts to wield it’s head at the 10-member mark. Key team members area pulled away to train new team members. When projecting the velocity a new person adds, remember reduce velocity for the first two sprints a new person joins. You need to reduce the velocity of the trainer and ramp up the velocity of the new person over a few Sprints. Team Size: critical and strategic. 7-10 total members. (10 is on the edge of too big).

Role Definitions

Everyone is important. Everyone is responsible for success or failure of the project. The Product Owner and Scrum Master roles will be singled out in Chapters 22 and 23. So, why do we highlight the Product Owner and Scrum Master? Just as a ship is manned with an entire crew and it takes many people to successfully run the ship, there is still one person that is ultimately responsible for the ship: the captain. The Scrum Team runs with an equivalent of a Ship’s Captain and First Mate. The Product Owner carries the final load of responsibility and the Scrum Master helps guide the team’s ship. Despite singling out these particular roles, it is still a collective, team effort to achieve success (or failure). So speak up! You are a valued member of the team and your contributions are equally important.

Even though you may have an organizationally defined role, or team-defined role, a truly high-performing team is cross-functional and will make the effort to cross train on various aspects of the team to fill gaps that may be temporary or chronic as necessary to accomplish a successful release of the product.

Cross Functional Teams in a Transitional Company

Scrum was developed in the 1990’s when systems engineers were able to take a story all the way from business analysis, development, through to testing. The reality of most transitional companies is there is a silo-ing of expertise. The minimum I’ve seen on my teams and Functional Analysts (business analyst and tester in the same role) and developers. Typical is BA, Developer, and Tester. Sometimes I’ve seen a further separation within the Developer group depending on the expertise of the team. I’ve addressed the problems encountered by having silo-ed expertise by including principles of Kanban such as Limit Work in Progress, Flow.

What Do You Think?

  • What will be the biggest adjustment your team will have to make regarding Scrum team concepts?
  • What areas does the team need to improve?

Section III: Team Foundations – Ready, Set, Go! 

Total Suggested Time Box: TBD

Starting up an Agile team can be very chaotic. The Sprints move fast and learning the rhythm of the fast pace is a big change. It will take some time to do everything “right”. Don’t worry. With each Sprint, you can make incremental improvements. That is the foundation of Agile: Plan-Do-Inspect-Adapt. The short cycles of Sprints let you inspect and adapt quickly. That is not only within the project itself, but with the process of implementing Agile Scrum. So, hold on and let’s dive in! We will start by defining the team, setting team ground rules, defining our team objectives, and most importantly, contributing to the Product Objective and Project Release.

 

 

Communication – the Heart of Agile

Suggested Time Box: 30 minutes

Concept

Agile will suddenly thrust your team and your project and product into an intense spotlight. You will be accountable in ways that are unfamiliar and scary. Communication is a key component of succeeding as an Agile team. The above factors will create tense situations and a need for communicating through tough times in a healthy, constructive manner. When you start your team, you will create a Team Charter, which is a set of operating rules for your team.

Healthy Communication Habits

The foundation of your Team Charter should be a set of operating rules that are captured through healthy communication habits. You most likely have existing relationships and lines of communication with your management or stakeholders outside your new team.

Healthy communication has various aspects of accountability, honesty, and respect. All of these are very scary, especially if the team has been in protected silos or are new to each other. One-on-one’s can be held on an as-needed basis or weekly (depending on the team’s preference). One-on-one’s are especially helpful at the beginning of the project while the team is still going through “forming, storming, and norming” process for the Scrum Master and individual to understand concerns, risks, and pressures that may not feel comfortable to be expressed publicly.

How to Promote Healthy Communication

  • Pay your team members the respect and honor of addressing issues with them directly first before you take it outside the team.
  • Don’t expect to agree on everything. There is a healthy way to disagree and yet still be respectful and productive. You can define how your team wants to “agree to disagree” in your charter.
  • Hold each other accountable and have the courage to speak up to commitments we made in the various ceremonies.
  • Have the courage and humility to admit your mistakes publicly and suggest ideas for correcting the mistakes or ask for suggestions from the team about how you could improve in a certain area.
  • Recognize that change and discussions around the process and product can be contentious, hot, and messy at times. Expect that and put egos aside.
  • Redirect negative comments or actions into positive change.
  • Be ready to capitalize on unexpected opportunities for short term change as well as orchestrate deliberate longer term change.

Feedback

Be ready to give your team members feedback – both positive and negative.

Manager-Tools model:

“Hey, can I give you some feedback?” (You ask the question because the person may not have time, or may not be in the right frame of mind for feedback, even if positive.)

“When you [note the behavior], it does [note the positive or negative effect.]” By focusing on behavior (not motives or feelings) you are able to increase positive behaviors and contribute toward your team’s high performance.

One-on-One’s (O3’s)

As your team is forming, your Scrum Master/Coach may elect to hold One-on-One’s, another Manager-Tools.com recommendation, with individuals as necessary or on a weekly basis. When the team is new to each other and less comfortable with expressing all of their concerns publicly, this tool can be invaluable to the Scrum Master and team in overcoming communication hurdles. It will be the responsibility of the Scrum Master to express concerns in a healthy way as part of the retrospective paired with review of the High Performance Team, Team Charter, Retrospective (and associated data).

The High Performing Team

Define behaviors, attitudes, and activities that you want to achieve. You will be setting your goals to become a high performing team in this exercise in Chapter 19. It complements the Team Charter by taking the basic operating rules of the Charter and setting a higher bar for your team to modify behaviors based on what the team defines as high performance. This should be at a principle level. Setting ground rules in the higher performance tree and team charter for healthy communication, conflict, complaints, and debate.

Team Morale

The Scrum Master will have primary responsibility for keeping an eye on team morale and finding ways to help the team through various events. Each team member also should be accountable for noting areas where the team morale may be waning or impacted by various events and contribute to managing and improving team morale.

What Are Your Thoughts?

The questions below are for self-reflection and to help guide you in being self-aware of any detrimental communication habits you may have. It is not necessary to share these with the team (unless you want to so the team can help hold you accountable for improving your style), but you may want to formulate some of the ground rules in your team charter around improving some of the habits that happens under stress.

  • How do you communicate when you are stressed?
  • If pressured to make a decision different than one you prefer, how do you normally react? Are you open to changing your communication style to adapt to the team?
  • Do you change your communication style based on your audience?
  • How do you communicate when you are tired or sick?
  • How do you communicate when you are frustrated?
  • Do you gossip or communicate outside the team when something goes wrong?
  • What is your preferred form of communication? (IM, email, text, telephone, in person) Share this one with the team.

Don’t Just Accept Change – Embrace It!

Suggested Time Box: 30 minutes

The iron triangle of Scope, Schedule, and Budget are mitigated by unlocking Scope. Scope is the lever that floats around budget and schedule by focusing on producing the high-value, highest risk items that will be most used and valuable to the users. Manage the project around keeping the scope as simple and focused as possible. Think of Apple or websites that are built incrementally.

One of the key tenets of Agile is that the flexibility comes with managing scope tightly. Produce the highest value, most difficult, most unknown, and riskiest items first. If you are going to fail, fail early. By prioritizing in this manner, some stories fall to the bottom showing the potential for flexibility and the possibilities for simplification.

Where Are You on the Change Continuum?

It is useful to understand how willing you and your team are to embrace change. This is helpful in understanding how willing the team is to implement the Agile process and how willing they are to accept changes and feedback from the business customers and end users. Agile untethers the “lock-down process” where requirements are frozen and thrown over the wall. Your team may actually have different opinions when it comes to implementing a better project process (Scrum), but resistance to accepting changing requirements.

  • Cutting edge of change – innovative, creative, “out there”
  • Eager for change – fast follower of new ideas
  • Middle of the road – open to adopting change that makes sense
  • Cautious – not averse to change, but the value must be very evident
  • Resistant – does not like change

New Processes

Note where your team falls on the continuum of accepting new processes

Cutting Edge Eager Average Cautious Resistant

Requirements Change

Note where your team falls on the continuum of accepting change to requirements or architecture.

Cutting Edge Eager Average Cautious Resistant

The Agile Paradigm Shifts

Suggested Time Box: 60 minutes

The Concept

Get ready for some big changes in your traditional thinking! Agile introduces radical changes. It is important to understand these changes ahead of time begin to prepare for the mental shift required to successfully implement these new concepts. You do not need to dwell in depth on these concepts as  some will be discussed as training workshops later. The idea of this chapter is to introduce the major concept changes to get your mind prepared for the change. The following is a list of major paradigm shifts I have observed in my projects and talked over with other Agile Practitioners.

Change

The following statistic will undoubtedly create the most contentious discussions if you are new to Agile: the average Agile project experiences 20-40% change in scope (Source: Valtech).  My personal experience has been increases in the range of 30-40% on every project, after the backlog is stable. The following are real comments I heard when I undertook my first Agile project:

“Requirements should be complete and frozen, so we can build a complete and solid architecture that can handle whatever requirements are thrown at it.”

Reality check: in a traditional project, how often is your architecture the exact same as when you started? Have you ever looked back on your development and thought, “I should have done it this way.” Or have you learned as you went and improved your knowledge of the architecture and tweaked it as you went? Agile embraces these realities. Yes, it’s nice to have a big picture of the requirements (the Product Backlog) so you can create the seeds of good architecture and data structure. But, embrace the reality: users don’t know exactly what they want or how to communicate their picture accurately the first time. Also, as developers you often do not know how to best address the architecture and data structure until you are in the midst of development. Embrace the reality of creating a flexible and changeable architecture. Be willing to adapt the requirements and architecture and data structure as needed to meet the new realities revealed as the project progresses. You are either going to address these realities immediately (in an Agile project) or next year when you finish the project. Wouldn’t you rather delight your customers by being flexible and accepting this right now?

“It’s like building a plane while you are flying it.”

Well, kind of. In a literal sense, it is less risky than building a plane while you are flying it since you are still on the ground. However, in a sense, it feels a lot like that because it surfaces a lot of scary feelings: transparency, constant pressure to produce, high visibility into all the ugly problems of the project, constantly changing requirements, constant change to the data structure and architecture.

This is a key paradigm shift in Agile – change is not locked down and fixed. Agile is flexible and embraces, accepts, and bakes change into the process. And yes, that does feel like flying a plane while you are building it.

Transparency and Micromanagement

The visibility into progress of short one-, two-, three-, or four-week increments suddenly creates high accountability, transparency, and ability to see the details and the risks and issues of a project. This is very scary at first! Understanding that Agile is going to create some very scary visibility is important to acknowledge. The Product Owner and Scrum Master and an Agile Manager all have key roles in supporting and protecting the team when the problems of the project are exposed for all to see. The temptation will be for management to micromanage the details and the problems.

However, as everyone adjusts, this visibility actually creates a protection and builds comfort and confidence in the team by management. Management has visibility into real details and decisions that they can make instead of making decisions with carefully crafted, politically correct statements. Decisions can be made in real time against real data. They can offer visionary course corrections and make real trade-offs based on the details captured in the Product Backlog and the Scope and Capacity Planning. Strategically add a person? Reduce scope? More accurate predictions can be made on budget and timeline. The anchor of scope becomes the key lever that is exercised in an effort to manage to the budget and timeline originally projected. This is normal and good!

Surfacing Organizational and Systemic Impediments  

This new transparency creates visibility into the problems the project is facing. The transparency of the impediments provides real data and areas for the management to uncover and provide substantive assistance in removing roadblocks. The Agile process often surfaces organizational (silos, communication barriers) and systemic (communication culture of the organization) impediments. Making these impediments clear can create some politics. These types of impediments are often beyond the purview of the team to overcome. These impediments are best handled by management who has greater influence and role power to effect changes surfaced by the Agile process.

Agile Speed 

The average encouraged Sprint is recommended to be two weeks. I suggest one-to-two week Sprints.  A team has the option of deciding the length of their own Sprint from one to four weeks, with one or two weeks being the ideal time box. At the beginning of an Agile implementation, overhead time spent in planning, administration, tasking, demo preparation is often forgotten. Also, there is a tendency to underestimate the actual complexity of a feature. The initial speed creates anxiety and will feel like a circus for a while until the habit becomes ingrained. The temptation will be to change the Sprint length. However, don’t worry about slow starts, underestimating tasks, forgetting about tasks and overhead or preparation. You will get used to this new rhythm. Eventually this will be part of your habit and you will get used to the speed and constant gentle pressure applied by the Agile Scrum process.

A note of caution: there is often a temptation to change the length of a Sprint because there were a lot of underestimates and forgetting of tasks. Resist the urge! You will catch on. Your estimating will improve with practice and you will begin planning the overhead time into your estimates. Just give it at least 3-4 Sprints.

Test Driven Development / Writing Tests as Requirements

Test Driven Development (TDD), in a nutshell, is when a developer takes the User Story and converts it into an automated test. The developer then takes the test, runs it and watches it fail. Then the developer writes code until the test passes. This test is automated to run with the Continuous Integration build (see below). If the test fails at any point, the team immediately knows that something changed in the code and Stops the Line (see below) to immediately fix anything that broke (or fix the test if the test needs to be changed as a result of code change) while the programming is still fresh in everyone’s memory. If you have ever had to trace a bug months after you developed code, you know how much less expensive it is in time (hence, money) to fix a bug when it happens, not after it happens.

This is the second biggest paradigm shift I have seen on the Agile. In the traditional environment, the testing takes place last and the window for testing usually shrinks as the development takes more time than originally planned. Also, testing tools are often designed to write tests after the code is developed. This habit carries over into Agile teams because the mindset behind TDD is such a significant shift. As the project progresses, and the team has time to digest why this is a best practice, more effort is made to move the team’s maturity level over by testing during the Sprint. Sometimes such a significant testing debt is developed that automated testing is relegated to be implemented during the next release and focus is only on manual testing. Often TDD is implemented in the next project while automating or doing manual tests on the first release. Don’t worry if your team doesn’t achieve perfection the first time.

One of the reasons I think this is the biggest shift, is that learning to write requirements as a test, and learning the automated software tool is very different from the traditional method of writing requirements as a document and doing manual testing later. However, it is well worth the effort to spend time up front with learning the tool, cross-training team members as necessary. This initial learning curve and paradigm shift will save you time and produce higher quality software and happier customers in the long term. In the words of one of my colleagues once he understood the concept of TDD, “Take some time, waste some time, spend time at the beginning of your project (however, your team interprets this concept at this point) and do TDD.” You will be happy you did.

Continuous Integration

Continuous Integration (CI) is another concept where the individual pieces of code are built continuously and fully integrated as they are developed and checked into the source code repository. The team can choose the increments of when the CI takes place (hourly, daily, as new code is checked in, twice a day, etc.). The point behind CI is similar to TDD, if the build breaks, it is evident that a piece of code introduced a bug or broke another piece of code or a test needs to be modified. The team then implements Stop the Line to immediately fix this issue.

This paradigm shift I find a little easier to adopt as developers can quickly see the value of continuous integration and have actually asked to turn on the Continuous Integration tool to catch any errors introduced in the code that weren’t caught through Unit Testing or Peer Review.

Stop the Line

TDD, CI, and Stop the Line are tightly integrated with each other.  When an Automated Test or Continuous Integration build fails, the team should implement Stop the Line mentality, similar to the Toyota’s “Pull the Red Handle” if there is a defect. This is the cheapest time to fix a defect, as soon as it is introduced into the environment.

The concept is relatively easy to understand. It takes a little more effort to develop the habit as it is a change from the traditional development practice.

User Stories – Writing Requirements from a User Point of View

Traditional project development has developed a very document-heavy, system-centric point of view with writing requirements. Agile embraces including business people as Product Owners and Subject Matter Experts as part of the development team, sitting in the same room (if at all possible) and communicating back and forth with direct conversation. (It is possible to implement the Scrum methodology with a distributed team, but with time lags, special concessions regarding velocity should be estimated and accounted for when planning. More on Distributed Teams later.) Because the business is part of the Agile Scrum team, one major change is learning to write requirements as a User Story. Instead of writing “the system shall”, the story will be written from the point of view of a user. It will be necessary to identify the types of roles a user will have: administrator, shopper, customer, you  can write the stories from the point of view of the actual performer of the operation: “As a customer, I would like to check out using a Visa credit card.”

Another shift in this thinking is that the stories should be simple. The overall concept of Agile is to keep things as simple and functional as possible. User stories will contain a simple statement of functionality with a simple set of User Acceptance Criteria. A single story should not contain an exhaustive of “should” and “should not” criteria. A very general rule of thumb (that can be broken as needed) is to write the function on the front of a 3” x 5” index card and the details of the acceptance criteria on the back of the card. When you run out of room, it means you need to write a new story. This keeps simplicity and signals when stories should be simplified.

There are a number of techniques and ideas for story writing workshops. Some of the specific techniques will be addressed later. The key idea is to keep things as simple as possible.

Agile Maturity

Your mind might be swimming with these paradigm shifts. Don’t worry about implementing everything successfully the first time you go through this process. Even the Agile process itself can be implemented incrementally with each release. For example: TDD is one of the difficult concepts to implement right the first time around (although I highly recommend giving reasonable effort to doing this.)

There are three phases of Agile Maturity as the team adopts various practices. Don’t worry as you go through implementing this framework. Practices are implemented incrementally and change is incremental. Accept that your team will go through a process of achieving Agile maturity. Lyssa Adkins highlights these phases in her book Coaching Agile Teams. In short, the phases of maturity you will go through are:

  1. Learn the framework (learn the basics)
  2. Break the framework (make adjustments that fit your team and environment)
  3. Live the framework (internalize the core principles and pass these principles with your key lessons along to others who follow you in the Agile path)

 

Okay, we discussed the Big, Scary Changes that happen on an Agile Project. So, why should you do Agile? Here is the main reason to keep you motivated about the benefits of Agile and go ahead and dive in and start.

The Best Agile Project

The best thing that can happen on a good Agile Project is you produce a piece of high-quality software that your customers not only love, it creates high demand from your other customers. The challenge, then, is meeting demand because you have delighted your customers so much. In my first project, I had the opportunity to observe this phenomenon: while everyone watched the first rollout with anxiety, once they saw the product in action, they were begging for the product. In fact, the problem then became the politics because everyone wanted it now because it was changing their business process, doing away with home-grown, half-developed tools and creating opportunities to grow the business. That’s a good problem to have!

Why is Agile Better? 

Suggested Time Box: 30 minutes

Agile makes no claim to be a “silver bullet” solution to all project problems. Agile done badly is just another bad project management approach. Transitional companies have a tendency to partially adopt Agile and modify to the environment. This approach usually doesn’t offer the significant improvements that implementing a full Agile framework can offer. If the company takes a transitional approach, make a conscious effort to continue to become “more Agile.”

However, if your organization can make the effort to implement an Agile framework fully, it can offer the follow benefits:

Uncovering Systemic, Company Culture, and Organizational Impediments

Agile done well starts highlighting systemic problems that plague all projects: it uncovers the “throw-it-over-the-wall” process which inhibits communication and tends to miss the mark widely of producing software the customer actually wants. Agile reveals organizational silos that hamper communication,  and exposes organizational hierarchies and politics that restrict projects rather than empower projects. Agile frameworks also expose systemic and organizational communication patterns that are impediments to any project (Agile or traditional).

Complementary Lead Roles

A Product Owner is a key component to a strong and successful Agile project. A single source that communicates vision inside and outside the team creates a conduit that protects the team and keeps management informed. Their viewpoints spans the entire lifecycle of the Product and includes multiple projects.

A Scrum Master/Coach is a servant to the team and not a manager. This person focuses more on helping the team become a high performance team through useful application of Agile processes. The Scrum Master has a narrower project viewpoint. Although this person may span multiple projects in support of the Product Owner, the primary focus is the Process and an High Performing Team over the Product.

Introducing Good Habits

Agile introduces habits like User Stories, Test Driven Development, Continuous Integration, and Stop the Line concepts. All of these increase quality and customer satisfaction and produce higher quality and highly demanded products. Functional software is the measure of success.

The High Performing Team

Another benefit is that the high transparency and accountability have a habit of encouraging and producing high-performance teams and individuals that eventually pervade the organization. There is a consistent pressure created by the short time boxes of a Sprint/Iteration that don’t allow for time lags. Junior members benefit from senior team members work ethic. Much cross training takes place to make the entire team productive. Accountability as a team produces high quality results and a number of high performance traits: accountability, willingness to examine and correct mistakes, constant learning, less wasted time, creativity fostering new innovations. Time is precious to an Agile team and it is used well and productively. Management has been craving ways to measure productivity in a knowledge-worker environment. Although high accountability and transparency is scary at first, if you want to change accountability of your organization, look at adopting Agile habits!

Useful Documentation

No more documentation for the sake of documentation! How cool is that? If you have a heavy-duty PM process embedded in your organization, the Agile process may appear at odds with the traditional process. However, when you can adequately produce equivalent documentation that meets the same needs as the original process, you should be okay. The Scrum Master may have to work with the PM organization to demonstrate how the documentation being used meets the requirements of the incumbent process. One example is writing tests as requirements: if you have the right tools, the test can produce a written document that looks like a requirement document. In the meantime, you are saving a significant amount of time by directly writing the automated test as a requirement.

Potential Organizational Efficiencies Maximized

If you have a separate Business Analyst and Quality Assurance team, this role has the potential to be merged into a single role where the analyst directly writes requirements as a test. The Business Analyst will need to learn to write tests and use testing software, but can now eliminate the requirements document. The Quality Assurance Tester can help the Business Analyst learn the testing software and evaluate new software that better supports test-driven development and learn from the Business Analyst how to elicit and interpret requirements into a test. There is great cross-training and collaboration afforded by combining these roles. If you adopted only one single practice out of all Agile practices, Test Driven Development and combining the Business Analyst and Test Analyst roles into a single role is something I would highly recommend.

Improved Communication

Communication overhead is reduced when the team can co-locate in the same team room. It is still possible to work with a distributed team, but additional communication overhead and time lags need to be factored into velocity. Communication improves during Sprint planning because the entire team is present during the discussion to elaborate on quality and clarity of the User Story. When tests are written as requirements, developers (who are notoriously introverted) can develop specifically against the test. Short Sprints allow quicker turnaround of working software and a shorter feedback loop to allow the users to make instant course corrections of the “picture in their head” versus what was actually produced. (Even when you work in the same room, it is amazing how the differences in perception between what was written and what was developed can happen…therefore, the benefit of small timeboxes of work and demonstrating the results so feedback can be immediately incorporated.)

Reduced risk

By doing the highest risk, highest value stories first, risk is reduced. It is determined whether the project is technically and financially feasible. If it is determined unfeasible, this is determined early in the project before too much money is lost. Also, risk is reduced by surfacing impediments immediately and resolving them quickly.

What do you think?

  • Do you think these benefits are realistic in your environment? Why or why not?
  • Which ones create high expectations that concern you the most?

What is the Agile Methodology?

What is the Agile Methodology?

Suggested Time Box: 30 minutes

The Concept

Agile is not a single methodology. Agile is a collection of practices that institute a framework for implementing a project.  Some key Agile practices are: Scrum, Continuous Integration, Co-Located Workspace (business and development working in the same room), Automated Testing, Test Driven Development, XP, Small Frequent Releases, Customer Team Member Acceptance Testing, Sustainable Pace, ScrumBan, Kanban.

You will be learning the Scrum framework with Continuous Integration and Test Driven Development.

What do you think?

  1. What Agile practices have you heard of?
  2. Which sound most practical in your environment?
  3. Which ones do you want to try?
  4. Which ones do you think are impractical and do not want to try? Why?
  5. What worries you about the process? Why?
  6. What worries you about the project? Why? (This is actually an initial risk list.)

Why Should We Use Agile processes?

Suggested Time Box: 60 minutes

The Concept

The Agile framework was born out of frustration for constant failure on projects. It is true that Agile done badly does not help a project and can sour an individual on the process itself. However, Agile done well, produces amazing results. Yet Agile Done Well does not happen overnight. It takes time to ingrain the habits of Agile into a team and even longer into an organization. In a nutshell – you adopt Agile incrementally just as you deliver the product incrementally. In other words, it helps to adopt the mindset that your team and organization will be Agile about becoming Agile.

Project Failure Statistics – Why Agile Was Born

The Bull Survey (1998)

Source: http://www.it-cortex.com/Stat_Failure_Cause.htm

  • Bad communications between relevant parties 57%
  • Lack of planning and scheduling resources and activities 39%
  • No quality control 35%
  • Milestones not being met 34%
  • Inadequate coordination of resources 29%
  • Costs getting out of hand 25%
  • Mismanagement of progress 20%
  • Overall poor management 17%
  • Insufficient measurable outputs 11%

The Key Statistics for Doing Agile Well

One key to planning is to include a 30-40% margin in your planning. My personal experience is that projects increase 35-40% in scope after the backlog is well defined and stable. For emergent backlogs where “you don’t know what you don’t know,” it has been a whole different story.

This is the basic principle behind short timeframes where you produce working software and demonstrate it to the business—in short, people don’t know what they want until they see it, or they find it difficult to explicitly express their thought process in a document. The only reliable statistic of “done” is working software that works the way the Product Owner and business team intended it to work. Once the demonstration is shown, immediate feedback can be given to correct any communication gaps. The team then learns from these gaps and is able to make instant course corrections: the business team can write stories with greater clarity and the development team becomes more clear in their understanding of what the business really needs.

The above statistics will be addressed later in the training course. As a Product Owner and Scrum Master these are important to understand while planning and projecting the project, budget, and schedule.

What Are Your Experiences?

  • What problems have you encountered on your projects?
  • What was your worst project ever? Why?
  • What was your best project ever? Why?
  • Have you found most of your projects being late and over budget?
  • Do you know how many of the features you write are actually used?
  • Are you aware of the ROI of the project?
  • How was communication on your project?
  • What kind of politics existed in your best projects?
  • What kind of politics existed in your worst projects?
  • What would you do differently to make your projects better?

The Agile framework was born out of frustration for constant failure on projects. It is true that Agile done badly does not help a project and can sour an individual on the process itself. However, Agile done well, produces amazing results. Yet Agile Done Well does not happen overnight. It takes time to ingrain the habits of Agile into a team and even longer into an organization. In a nutshell – you adopt Agile incrementally just as you deliver the product incrementally. In other words, it helps to adopt the mindset that your team and organization will be Agile about becoming Agile.

Project Failure Statistics – Why Agile Was Born

The Bull Survey (1998)

Source: http://www.it-cortex.com/Stat_Failure_Cause.htm

  • Bad communications between relevant parties 57%
  • Lack of planning and scheduling resources and activities 39%
  • No quality control 35%
  • Milestones not being met 34%
  • Inadequate coordination of resources 29%
  • Costs getting out of hand 25%
  • Mismanagement of progress 20%
  • Overall poor management 17%
  • Insufficient measurable outputs 11%

The Key Statistics for Doing Agile Well

One key to planning is to include a 30-40% margin in your planning. My personal experience is that projects increase 35-40% in scope after the backlog is well defined and stable. For emergent backlogs where “you don’t know what you don’t know,” it has been a whole different story.

This is the basic principle behind short timeframes where you produce working software and demonstrate it to the business—in short, people don’t know what they want until they see it, or they find it difficult to explicitly express their thought process in a document. The only reliable statistic of “done” is working software that works the way the Product Owner and business team intended it to work. Once the demonstration is shown, immediate feedback can be given to correct any communication gaps. The team then learns from these gaps and is able to make instant course corrections: the business team can write stories with greater clarity and the development team becomes more clear in their understanding of what the business really needs.

The above statistics will be addressed later in the training course. As a Product Owner and Scrum Master these are important to understand while planning and projecting the project, budget, and schedule.

What Are Your Experiences?

  • What problems have you encountered on your projects?
  • What was your worst project ever? Why?
  • What was your best project ever? Why?
  • Have you found most of your projects being late and over budget?
  • Do you know how many of the features you write are actually used?
  • Are you aware of the ROI of the project?
  • How was communication on your project?
  • What kind of politics existed in your best projects?
  • What kind of politics existed in your worst projects?
  • What would you do differently to make your projects better?