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?

What Have You Heard About Agile?

Suggested Time Box: 30 minutes

The Concept

If your company isn’t already implementing Agile practices in some form, you have probably at least heard of Agile project management and formed some kind of impression. Eager to get started? Heard enough good things? No tolerance for a long class or big books? This is a practical workbook to guide you through starting up your own Agile Scrum Team on a small project. If you have taken a traditional training program, you can use this as a companion guide to start your own project through the first two Sprints and use this a day-by-day checklist.

What do you think?

  • What are your impressions of Agile processes? What are the team’s impressions of Agile processes? Discuss as a team.
  • What have you heard that you don’t like? What has the team heard that they don’t like? Discuss as a team.
  • What have you heard that you like? What has the team heard that they like? Discuss as a team.

 

How It All Started – The Agile Manifesto

Suggested Time Box: 30 minutes

The Concept

The ideal started in 2001 with the Agile Manifesto. (http://agilemanifesto.org/)

“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 follow a plan

“While there is value in the items on the right, we value the items on the left more.”

(The original authors of the above Agile Manifesto are: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas)

History

The original authors of the Agile Manifesto got together during a ski trip in Utah to bat around ideas about how improve project success. The Manifesto was born out of this conversation. In the decade since the Manifesto was published, multiple processes have arisen from this basic Manifesto and follow the ideals to minimize wasted work and focus on the actual measurable result of functioning software. Most of the original signatories of the manifesto have gone on to write books and have consulting practices built around the Agile Manifesto. Their books are highly recommended reading for rounding out your Agile knowledge and expanding your ideas beyond the basics of this training document.

Agile Manifesto Ideals

  • What do you think could be a problem on the project?
  • What “won’t work here”?
  • What has potential to work well?

Section II: Agile Basics Boot Camp

Total Suggested Time Box: 5 hours

This section of the workbook is introducing you to the basic theories of Agile, the start of Agile and starts a team dialogue. It is good for the Scrum Master and Product Owner to note where the team is in their thinking and adoption of Agile Scrum so you can focus on how to coach the team through the changes. The primary role of coaching the team through change falls on the shoulders of the Scrum Master, but the Product Owner should also have a vested interest in the team personality as it will impact decisions made on prioritizing the backlog, release, and roadmap, as well as being prepared to raise and address risks and/or roadblocks. Every individual that comprises a team is in a different part of their journey, so no two teams will be exactly alike. Having this dialogue at the beginning will guide you, the Scrum Master, in what you need to do to prepare to coach your team through the changes of adopting a new process. Each team member can take a turn in leading each chapter to reinforce the equality of the team members.

 

Scrum Master Preparation

Important Note to the Scrum Master

The Scrum Master is the “Keeper of the Process” and your key deliverable is a high performing team. It will be your job to read the framework, implement the framework, and hold the team accountable to the framework. If you are an expert in something on the team, it will be a challenge for you not to get involved in the minutiae and details of the project. You will be more effective with supporting the process if you take a step back from the team, listening, keeping an eye on comments and feedback throughout the process, noting them and keeping them on the agenda for the retrospective (lessons learned) at the end of each Sprint. The trick is to trust the team and let the team do their job. You are not the team’s manager. The team is self-managing and you are a keeper of the process. Per the Scrum Alliance (scrumalliance.org), Scrum Masters progress from executing the Scrum Framework as a Scrum Master, to becoming an experienced Scrum Practitioner, to a Scrum Coach. Ask your team to hold you accountable to the process and not the product (the team is responsible for the product). The Scrum Master will hold the team accountable for the product.

By tracking the data (velocity, burndowns, feedback), dicey conversations can be had with less emotion when using facts. Facilitate the hard conversations for the team (for example, if they are not meeting their velocity commitments) by using the data as a starting point. Start the conversation, sometimes shepherd the conversation, but guide the team to work it out. Sometimes it means letting silence reign for a long time before someone has the courage to speak up.

Team Communication

This training plan was designed to engage your team in conversation about implementing the Agile Scrum process and allow you to note areas where you will need to spend extra time coaching your team in their specific location in their Agile Journey. A valuable tool for communicating, especially during the beginning of the team formation, during the “forming, storming, and norming” phase are One-on-One’s. Manager-Tools.com has a standard format that you can modify to your team’s project needs. These are valuable when the team is still uncomfortable expressing themselves openly at the beginning of the project.

Changing Your Mindset

If you are a classically trained project manager, you may be used to directing and controlling the process. That mindset is going to go through a transformation through the Agile process. The first time you start up a team, just focus on implementing the process. Lyssa Adkins book on Coaching Agile Teams is a critical must-read if you decide to continue as a Scrum Master and start up other teams. You might decide you like the decision making process better…if that is the case, the Product Owner role is a good option to consider. If you like process and enabling teams to achieve their best, you would like the Scrum Master role. You will eventually need to learn what it means to be a “Servant Leader.” This is one of the key transformations of the Scrum Master role. However, this is just information ahead of time. Don’t worry about doing much more than implementing the Scrum process well. In Lyssa’s book, she uses a parallel training approach in the martial arts where the student goes through three learning phases called Shu Ha Ri. The first stage (Shu) is learning the moves…no questions, no whys, just do. (I include some very minimal foundation information because software developers have a tendency to be “why” people…if you don’t at least give a minimal explanation, and address questions, it’s part of the intention to start preparing the mind for the transformation.) The next stage (Ha) is where the process is now a reflex action and you can release the team to begin experimenting and making adjustments that fit them while keeping the Agile principles behind the process in mind. This is also the stage where team members begin teaching other members the basic processes. The final stage (Ri) is when the process is ingrained and mastery of the process is achieved and the team or team member is ready to begin contributing to the advancement of Agile practices. First-time teams should stay in the Shu stage for a while. It will take all your effort to execute the process well and understand the fundamentals and principles behind the reasons for the specific steps.

Action Plan for the Scrum Master

  1. Read the workbook through to prepare yourself for leading the team through implementing the framework
  2. Read the slide deck
  3. Read the templates
  4. Obtain some of the reference library as a back-up to this workbook

Create a Behavioral Interview to Hire Key Lead Roles

Interview Form

Manager-Tools (www.manager-tools.com) has an outstanding behavioral interview generator. There are 64 questions in the interview generator and it generates a behavioral interview based on a rough bell curve of critical to unimportant skills. There are two pages of 32 questions per page and you must check the boxes for each page in the following rough count.

1-None (2-4 checks)

2-Below Normal (4-6)

3-Normal (8-16)

4-Important (4-6)

5-Critical (2-4)

 

The easiest way I found to complete this questionnaire is select the Critical and Important characteristics, then select the None and Below. Mark the rest as Normal. Below are the Critical and Important characteristics to mark for the three key lead positions, Product Owner, Scrum Master, and Development/Architect Lead.

The Critical and Important characteristics of the Product Owner, Scrum Master, and Development Lead/Architect are different but complementary roles. The Product Owner is the Visionary, the Scrum Master the Keeper of the Process, and the Development Lead is the mentor and guide on the technical vision of the team.

Product Owner Interview

Here are the Critical and Important characteristics for the Product Owner. Some room is left for individual characteristics that will fit your company culture.

5-Critical:

Page 1, #15: Create and share a clear vision

Page 1, #28: Help directs prioritize tasks and projects within time constraints

Page 1, #27: Effectively manage priorities to accomplish them within time constraints

Page 2, #41: Maintain as much simplicity as is reasonable and possible when deciding

Page 2, #47: Communicate strategy to align people and resources

Page 2, #48: Adapt to changing conditions with changes plans and priorities

 

4-Important:

Page 1, #9: Consider all relevant information when deciding

Page 1, #10: Reason clearly and be able to explain rationales when deciding

Page 1, #12: Persuade others effectively

Page 1, #14: Constantly look to improve standing systems

Page 1, #16: Work with others to plan strategy

Page 1, #26: Establish a broader network external to team/department/firm

Page 2, #38: Keep relationships strong after difficult situations

Page 2, #42: Maintain a rational approach even when decisions create emotional responses

Page 2, #57: Create and keep effective work relationships

Page 2, #58: Build trust by communicating openly and frequently

Page 2, #64: Ask for others input routinely

Scrum Master Interview

Here are the Critical and Important characteristics for the Scrum Master. Some room is left for individual characteristics that will fit your company culture.

5-Critical:

Page 1, #2: Create and maintain accurate data

Page 1, #5: See and communicate multiple side of conflict

Page 1, #18: Follow through consistently on projects and details

Page 1, #20: Ensure policies and standards are met

Page 2, #38: Keep relationships strong after difficult situations

Page 2, #49: Created and maintain detailed project plans and task lists

Page 2, #53: Develop others skills over long periods through coaching

 

4-Important:

Page 1, #17: Manage multiple projects simultaneously

Page 1, #22: Deliver effective positive and negative feedback

Page 1, #24: Establish metrics and reporting to support them

Page 1, #28: Help directs prioritize tasks and projects within time constraints

Page 1, #30: Effectively determine scope and parameters of problems

Page 2, #37: Find effective solutions for difficult disagreements

Page 2, #48: Adapt to changing conditions with changed plans and priorities

Page 2, #51: Adapt policies and processes to changing conditions

Page 2, #52: Improve processes and procedures by applying a continuous improvement mindset

Page 2, #54: Know your teams strengths and weaknesses

Page 2, #60: Effectively plan for changes in talent/human resources

 

Development/Architect Lead

Here are the Critical and Important characteristics for the Development/Architect Lead. Some room is left for individual characteristics that will fit your company culture.

5-Critical:

Page 1, #7: Deliver service to customers with respect and care

Page 1, #13: Analyze new technologies for existing applications

Page 1, #14: Constantly look to improve standing systems

Page 1, #23: Maintain quality standards in the face of time pressure

Page 2, #41: Maintain as much simplicity as is reasonable and possible when deciding

Page 2, #45: Generate new ideas which solve problems

Page 2, #46: Consider and present unconventional ideas

Page 2, #56: Complete quality work versus inspecting for errors

 

4-Important:

Page 1, #9: Consider all relevant information when deciding

Page 1, #19: Create effective policies and detailed procedures

Page 1, #20: Ensure policy and process standards are met

Page 1, #22: Deliver effective positive and negative feedback

Page 1, #28: Help directs prioritize tasks and projects within time constraints

Page 1, #30: Effectively determine scope and parameters of problems

Page 2, #33: Focus effectively on work processes

Page 2, #34: Notice details and communicate their importance to others

Page 2, #52: Improve processes and procedures by applying a continuous improvement mindset

Page 2, #53: Develop others skills over long periods through coaching

Page 2, #55: Communicate the importance of quality regularly

Page 2, #62: Consider larger systems interactions in solutions

Job Description Swipe File

he following are generic job descriptions for key roles that will help you when you start staffing your team. You can hire and staff internally with these descriptions. If you are going outside your company, you can wrap the job description with additional company-specific information that you feel is relevant to the role.

Product Owner

The Product Owner is the linchpin and needs to be a strong team player. Do not underestimate this role! It is important to have a person who has strong business process knowledge, comfort leading strong, high-performing teams, and the ability to articulate project status at any time. This person also has a vision of the product beyond the single project or release that may be the focus of the Agile implementation. They should be visionary and anticipatory of future customer needs and committed to the product well beyond any individual project.

Product Description: the product description will be key to hiring the right person to fulfill the Product Owner role. If you hire internally, a Product Manager with deep expertise in the business process is most ideal. If you hire externally, it is possible to find some Product Owners who may have domain experience in other companies that may support your company growth. If they are external, time (1-2 months) should be given to allow them to develop business expertise in your company. Another good Product Owner candidate is a senior Business or Functional Analyst with a strong knowledge of the business processes and strong knowledge of development teams. These team members can make great transitions into Product Owners.

Job Description: the Product Owner is the linchpin of the Product launch with each release and a vision of guiding the Product into the future. You will have overall responsibility for the starting the Vision, creating and managing the Product Backlog, prioritizing business value and sequencing user stories to deliver high value. You will need to develop a Release Roadmap with a focus on delivering incremental high value items. You will also have responsibility toward the budget and schedule of the project. Your role as a leader is to help make daily decisions with the team, remove impediments that fall into your field of influence, raise awareness of impediments to individuals who can influence those impediments. You will also be leading a high-performing, self-organizing team. As a leader, it will be critical to listen to the input from the team when making the decisions that guide the development of the product.

Responsibilities:

  • Create initial Product Vision, solicit input from the project team, keep an eye on the Vision and tweak as necessary to maintain focus
  • Create Product Backlog
  • Manage, prioritize, and sequence Product Backlog on a daily basis
  • Negotiate priorities and dependencies with the development team
  • Create and manage the Release Roadmap based on team velocity
  • Make decisions and trade-offs on most valuable features and items that could be deferred
  • Ability to present to multiple levels of management and articulate the value of the product produced and the status of the project
  • Articulate the status of the project in informal conversations and formal presentations
  • Write users stories as needed to support the development process
  • Answer business process questions
  • Test and approve or reject the features in alignment with your vision of the Product
  • Be open to accept suggestions from the team to make the product better, simpler, more efficient
  • Accountability to team for providing vision and keeping the development team stocked with enough requirements (user stories)
  • Prepare and participate in the key Scrum ceremonies (Daily Scrum, Sprint Planning, Retrospective, and Developer Demonstration).
  • Engage with the team daily or full-time (if possible).
  • Cultivate a Subject Matter Expert network
  • Cultivate and engage your customer network
  • Develop a deep understanding of customer needs and learn to anticipate and be ahead of their needs. Identify opportunities for process optimization and redesign or development of new process based on customer trends and prediction of future needs
  • Evangelize the product value within your Subject Matter Expert network and customer network to begin laying the foundation for the change management campaign.
  • Capture SME and customer feedback and prioritize in the Product Backlog and Release Roadmap

Experience:

  • 2-3 years subject matter expert in product domain on business processes
  • 2-3 years experience with previous product with a vision of producing a better product
  • 2-3 years providing vision and requirements to high-performing development teams
  • Subject matter expert network
  • Strong business acumen, strategic thinking, and analytical skills
  • Excellent spoken and written communication as well as receptive listening skills, with ability to present complex business ideas in a clear, concise fashion.
  • Outstanding organizational, communication, interpersonal, relationship building skills conducive to team development.
  • Good relationship-building skills; ability to grow and nurture relationships with stakeholders
  • High energy and passion for the job
  • Ability to adapt, to be flexible, and to learn quickly in a dynamic environment.
  • Familiarity with Agile processes a plus

 

Subject Matter Experts

Subject Matter Experts in the business processes are valuable resources to producing high-quality requirements (user stories) from the business point of view. Having an understanding of the current product and cultivating a vision for the future product is critical. Have a broad network of experience with customers and a vision for creating a better product.

Product Description: the product description will be important to filling the Subject Matter Expert roles. The Subject Matter Expert does not necessarily need broad knowledge in the full product, but deep knowledge in their domain.

Job Description: the Subject Matter Expert is responsible for deep knowledge in their knowledge area of the current product and will contribute to the vision of the future Product. You will participate in prioritizing the Product Backlog and providing input into the business value (how many users are affected and how often) of a feature. You will also support the Product Owner in laying out the Release Roadmap from a business value perspective. You will be engaging full-time with a high-performing, self-organizing development team.

Responsibilities:

  • Participate and provide input to the Product Vision with the Product Owner and development team
  • Help develop the Product Backlog with your expertise in your knowledge area
  • Provide input into business value and priorities as needed to the Product Owner
  • Write user stories from a business process perspective with sufficient attention to detail that the story can be passed along to analysts for review, testers for writing the test, and developers for development
  • Answer questions about your knowledge domain
  • Develop knowledge in other domains as needed
  • Provide information that influences priorities and dependencies with the development team
  • Provide input to the Product Owner for the Release Roadmap
  • Make decisions and trade-offs in collaboration with the Product Owner and development team during story development on simplification, process improvements, or items that could be deferred
  • Testing and approving or rejecting the features in alignment the Product vision
  • Open to accepting suggestions from the team to make the product better, simpler, more efficient
  • Accountability to team for providing high-quality user stories about the business processes
  • Prepare and participate in the key Scrum ceremonies (Daily Scrum, Sprint Planning, Retrospective, and Developer Demonstration). Engage with the team daily or full-time.
  • Cultivate and expand Subject Matter Expert network
  • Cultivate and expand customer network
  • Identify opportunities for process optimization and redesign or development of new process based on customer trends and prediction of future needs
  • Provide feedback to Product Owner regarding additional User Stories and information to help determine business value

Experience:

  • 2-3 years subject matter expert in product domain on business processes
  • Subject matter expert network
  • Strong business acumen in business process
  • Excellent collaborative skills in spoken and written communication as well as receptive listening skills
  • Ability to adapt, to be flexible, and to learn quickly in a dynamic environment.
  • Familiarity with Agile processes a plus

 

Scrum Master

The Scrum Master is the keeper of the process who role most closely relates to a Project Leader. However, this is NOT a management role. It is primarily a change management role by coaching the team through the process and the changes needed. It is also a pivotal role in helping the team and organization. This role should be given permission to be politically neutral to business and IT and with permission to report transparently to both lines of management. The person for this role should have strong facilitation skills to help the team through dicey communication issues and be able to manage the multiple facets related to keeping the team focused on achieving their commitments. This is a role that complements the Product Owner who has a heavy load of providing vision for the Product. The Scrum Master is focused on the team, the process, and individual projects and releases. The key deliverable of a Scrum Master is a high-performing team. The Product Owner has the broader vision of the whole product lifecycle beyond individual projects the Scrum Master may be involved in.

Product Description: the product description is beneficial for the Scrum Master, but deep domain experience is less critical than deep process experience in project leadership type roles. Facilitation skills, ensuring the process is followed, coaching the team through change, improving process are all key to this role.

Job Description: You will have overall responsibility for engaging the team in the implementation of the Agile Scrum process. Your role is as facilitator, instigator, and shepherd of the Agile Scrum Process. You will facilitate team discussions to discern where each unique team is on their Agile Journey and note areas of risk or resistance and develop actions to coach the team through these hurdles. You will be supporting the Product Owner with project/release status, documenting velocity, capacity, individual sprint burndowns, overall project Burndown, facilitating discussions for Sprint Planning and Retrospectives. As you are a servant leader, it is critical that you keep encouraging the team to express themselves openly and respectfully and develop accountability to each other and commitment to the project and facilitate rather than manage the team into a high-performing Agile Scrum team.

Responsibilities:

  • Facilitate team training and notate team’s maturity in the Agile Scrum process
  • Coach the Product Owner and team through creating the Product Backlog
  • Review and support the Product Owner with daily update of the Product Backlog
  • Review and update the daily Business and Development burndowns to measure velocity and predict release completion
  • Facilitate negotiations between the Product Owner team and development team on priorities and dependencies
  • Continue to update and analyze capacity, velocity, and scope and maintain a Project Burndown
  • If relevant, include budget information with the Project Burndown
  • Facilitate Daily Scrums, Sprint Planning sessions and Retrospectives to keep the team focused and on track with the objective and make the meetings efficient.
  • Tactfully know how to lead discussions and when to allow a deeper discussion to continue, when to cut the discussion off, or redirect the discussion to a parking lot for discussion with a smaller group.
  • Provide data to the Product Owner and relevant levels of management to help them engage in data-driven decision making
  • Ability to present to multiple levels of management and articulate the status of the project
  • Maintain an eye on the morale of the team
  • Coach the team through adoption of the Agile Scrum process with positive and negative feedback
  • Facilitate story development workshops
  • Facilitate test writing as requirements workshops
  • Engage with management as appropriate to assist in removing organizational and systemic impediments
  • Answer Agile Scrum process questions
  • Accountability to team for documenting progress and publishing the results with transparency in printed (Information Radiators in the team room) and electronic formats such as maintaining a team website
  • Determining communication plans and methods
  • Facilitate in the key Scrum ceremonies (Daily Scrum, Sprint Planning, Retrospective, and Developer Demonstration).
  • Cultivate a Scrum Master and Agile Scrum network

 

Experience:

  • 3-5 years as project leader or Scrum Master
  • Strong business acumen, strategic thinking, and analytical skills
  • Excellent spoken and written communication as well as receptive listening skills, with ability to present complex business ideas in a clear, concise fashion.
  • Outstanding organizational, communication, interpersonal, relationship building skills conducive to team development.
  • Good relationship-building skills; ability to grow and nurture relationships with stakeholders
  • High energy and passion for the job
  • Ability to adapt, to be flexible, and to learn quickly in a dynamic environment.

Architect / Development Lead

The Architect / Development Lead is responsible for the overall architecture and decisions regarding development standards, database standards, unit testing standards and mentoring or managing the development team to follow these processes.

Product Description: the product description is useful to hiring the right person to fulfill the Architect / Development Lead role. The programming languages, architecture, and development standards of your company are critical to hiring the right person.

Job Description: The Architect / Development Lead is responsible for the overall architecture and decisions regarding development standards, database standards, unit testing standards and mentoring or managing the development team to follow these processes.  Your responsibilities will include facilitating discussions with the development team on best practices, mentoring or coaching the team to follow best practices, and ensuring follow-through and accountability of the development processes. You will also be responsible for maintaining an eye on the productivity of your team and look for ways to continually improve efficiency of the team’s development time, efficiency in the architecture, efficiency in the product and propose areas for simplification.

Responsibilities:

  • Create Architectural design of product
  • Create Development and Unit testing standards for team
  • Mentor and coach development in following standards and ensure accountability to process
  • Propose areas for simplification of product to meet high business value
  • Peer review, write unit tests, and development standards and publish them on the team site
  • Accountability to team for providing architectural vision and accountability of development team
  • Prepare and participate in the key Scrum ceremonies (Daily Scrum, Sprint Planning, Retrospective, and Developer Demonstration).
  • Engage with the team daily
  • Responsible for overseeing Continuous Integration tools and ensuring all code checked in maintains a quality build.
  • Implement “stop-the-line” mentality when a build breaks either because of code check-in or when a tests indicates something has changed. Communication between development team and Analyst/Testers critical to ensuring Continuous Integration.
  • Cultivate a Subject Matter Expert network
  • Cultivate and engage your customer network

 

Experience:

  • “X” years development in “programming language”
  • Subject matter expert network
  • Strong business acumen, strategic thinking, and analytical skills
  • Excellent spoken and written communication as well as receptive listening skills, with ability to present complex business ideas in a clear, concise fashion.
  • Good relationship-building skills; ability to grow and nurture relationships with stakeholders
  • High energy and passion for the job
  • Ability to adapt, to be flexible, and to learn quickly in a dynamic environment.
  • Familiarity with Agile processes a plus

 

Analyst / Tester

There are a few different types of roles as defined by organizational processes. The ideal is a cross-functional business analyst and tester (functional analyst). If your organization has separated the business analyst and testing role into two different roles, it is best to cross-train to be an analyst and tester in the same role. Both skillsets bring value to the team. Business analysts are experts in translating the business process into language easier for the developers to build code against. Since the ideal process of Agile Scrum includes Test Driven Development, the writing of the requirements as an onerous Word document is eliminated by directly writing the requirements as a test. This will require the Functional Analyst to learn the test driven development tool that is chosen or the Tester will train the Business Analyst on the tool and the Business Analyst will train the Tester on converting requirements into tests.

Product Description: the product description will useful for hiring the right analyst/testers. Individuals with some experience in the subject matter are helpful. Even more critical, though, is their ability to elicit sound business requirements, understand them clearly and translate them into tests the developers easily understand.

Job Description: the Analyst/Tester translating User Stories into requirements in the form of writing tests as requirements. You will participate in prioritizing the Product Backlog, contributing to the Sprint Planning discussions by facilitating discussions from a “pure business” point of view to a “pure development” point of view. You will also contribute to the business and technical knowledge of the team as necessary. You will also provide support the Product Owner in laying out the Release Roadmap from a business value perspective. You will be engaging full-time with a high-performing, self-organizing development team.

Responsibilities:

  • Participate and provide input to the Product Vision with the Product Owner and development team
  • Help develop the Product Backlog with your expertise in your knowledge area
  • Convert User Stories into Requirements Written as Tests
  • Provide various technical and business input as needed
  • Answer questions about your knowledge domain
  • Provide information that influences priorities and dependencies with the development team
  • Provide input to the Product Owner for the Release Roadmap
  • Make decisions and trade-offs in collaboration with the Product Owner and development team during story development on simplification, process improvements, or items that could be deferred
  • Testing and approving or rejecting the features in alignment the Product vision
  • Provide suggestions to the Product Owner team to make the product better, simpler, more efficient
  • Accountability to team for providing high-quality tests and implementing tests as part of the Continuous Integration. Implement Stop-the-Line mentality when a build breaks because a test breaks. Communication critical to the development to determine the root cause (such as change in code) and either have the development team fix the code or change the test to accommodate the change.
  • Prepare and participate in the key Scrum ceremonies (Daily Scrum, Sprint Planning, Retrospective, and Developer Demonstration). Engage with the team daily.
  • Cultivate and expand Subject Matter Expert network
  • Provide feedback to Product Owner regarding additional User Stories and information to help determine business value

 

Experience:

  • 2-3 years subject matter expert in product domain on business processes
  • 2-3 years experience in testing tools
  • 2-3 years experience as senior analyst
  • Subject matter expert network
  • Strong business acumen in business process
  • Excellent collaborative skills in spoken and written communication as well as receptive listening skills
  • Ability to adapt, to be flexible, and to learn quickly in a dynamic environment.
  • Familiarity with Agile processes a plus

 

Developer

The individual developers are responsible for developing cross-functional skillsets in various programming languages as necessary for the product, providing suggestions on architectural and development to the team as necessary.

Product Description: The programming languages, architecture, and development standards of your company are critical to hiring the right person.

Job Description: The developer is responsible for being an expert in their programming language domain with supplementary skills as necessary in other languages and unit testing tools. Responsibilities include excellent communication to the team: asking questions for clarification, writing code against tests, unit testing. Must show high accountability to team and autonomy with self-development. Must follow architecture and best practices as defined by the Team Lead and organization. Contribute ideas toward architecture and best practices with an eye toward improving and making processes and product more efficient

Responsibilities:

  • Contribute to Architecture design of product
  • Follow Development and Unit testing standards and suggest improvements as needed
  • Personal accountability to team for commitments and being a high performing team
  • Propose areas for simplification of product to meet high business value
  • Peer review, write unit tests, and development standards and publish them on the team site as directed by Team Lead
  • Prepare and participate in the key Scrum ceremonies (Daily Scrum, Sprint Planning, Retrospective, and Developer Demonstration).
  • Engage with the team daily
  • Responsible for contributing Continuous Integration tools and ensuring all code checked in maintains a quality build.
  • Implement “stop-the-line” mentality when a build breaks either because of code check-in or when a tests indicates something has changed. Communication between development team and Analyst/Testers critical to ensuring Continuous Integration.
  • Cultivate a Subject Matter Expert network
  • Cultivate and engage your customer network

 

Experience:

  • “X” years development in “programming language”
  • Subject matter expert network
  • Strong business acumen, strategic thinking, and analytical skills
  • Excellent spoken and written communication as well as receptive listening skills, with ability to present complex business ideas in a clear, concise fashion.
  • Good relationship-building skills; ability to grow and nurture relationships with stakeholders
  • High energy and passion for the job
  • Ability to adapt, to be flexible, and to learn quickly in a dynamic environment.
  • Familiarity with Agile processes a plus