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.

 

Pin It

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?
Pin It

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.

 

Pin It

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
Pin It

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

Pin It

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
Pin It

Staffing the Team

Staffing the team appropriately is critical to the success of the team.  The Agile process creates high visibility, transparency, and a constant pressure to produce. The most effective teams are individual experts in their realm. It is best to staff with all experts. The next preference is to provide strong leads augmented with intermediate level team members. The leads can mentor the intermediate level team members, but the mentoring time will need to be factored into the velocity.

Key Staff: If at all possible, staff the following three positions with senior employees: Product Owner, Development Lead, and Analyst Lead (Functional or Business). The company information is essential to the product and having team members with comfort in your company environment will aid team members that may not be employees.

Contractor staffing: staff with contractors judiciously. Support these senior employees with at least intermediate to senior contractors who are experts in their domain.

The Scrum Master: If you are learning Agile, staffing your team with a Certified Scrum Master contractor with experience on at least one project can be beneficial to the implementation. If you choose to staff your Scrum Master role with a contractor, it is beneficial to provide this person with some mentoring or access to employees who are versed in current company processes. If you choose to staff the Scrum Master role and convert one of your existing project managers/leaders into a Scrum Master, you can overcome some of the change management hurdles faster by supporting this person with a temporary Coach who has experience in Agile implementations. It’s not a requirement, but some of the change management can be more easily overcome with a seasoned Coach.

Staff Augmentation after Project Start: Team size is ideally 6-8 people total (or as Mike Cohn refers to it, “a two-pizza team…if you can feed your team with two pizzas, that team is the ideal size”). When you initially analyze velocity and find that estimates are slower and you can reduce cost and timeline by adding people, be very selective about augmenting the staff. There is occasional turnover on Agile teams and you can mitigate these team changes by keeping the following things in mind when staffing the team:

  1. Velocity is lost during ramp-up, even with an expert, while the new person learns the architecture and processes. It also reduces velocity on the existing team members because their time is diverted from productive activities into training. I start new team members at 40% capacity and ramp them up 10-15% each Sprint.
  2. Creating a team of over 10 people adds to the communication complexity and communication overhead and has an unquantifiable impact on velocity. It is very easy to underestimate this impact. Don’t assume that by doubling the staff you will double your velocity. The idea of diminishing returns applies in Agile teams that by adding more people, you are adding more communication channels and communication overhead, which creates more possibilities for communication errors.
  3. Introducing new team members also creates the need for the team to coalesce and go through the phases of form, storm, norm and perform. Selective augmentation can mitigate the impact of this cycle.

Staffing with Junior Team Members: The speed at which an Agile team moves and constant pressure created in the Agile environment makes it difficult for junior business people, developers, analysts, and testers to keep up and maintain the commitment and quality. If you must choose junior team members, make allowances in velocity and be open to replacing them if they are not ready for that environment. If you have no choice but to staff with junior members, you will need to make allowances for velocity or augment their knowledge with additional training or mentorship.

Pin It

How Management Can Support an Agile Transformation

Concept

Agile can take root in an organization from the top-down or at a grass roots level. It is most successful when it is adopted from both angles. When management levels get involved in Agile transformations, there are many things they can do to support the transition. If you have the opportunity to be involved from the beginning, there are some key points that can make your Agile transition more successful such as Staffing. Otherwise, the following suggestions apply at any point in the project.

  • Agile is not a Silver Bullet. One of the most important things to realize when implementing Agile for the first time is that it is not a Silver Bullet solution. Eventually, with proper preparation, it will increase success, it will produce high value products, and teams and organizations can produce software faster and with higher quality. However, some of the outstanding results that are mentioned in books like the original book on Scrum, Agile Software Development with Scrum (Ken Schwaber and Mike Beedle, 2001) were produced in teams of senior developers in a small company where change could be managed easily. In other cases that were mentioned the senior VP or CTO was instrumental in introducing Scrum and had an intimate knowledge of the nuances of the framework. For companies who are initially starting with Scrum, you should expect and grant trust to the team to become high-performing and expect to start changing your organization to effectively support Agile teams.
  • Staff the team appropriately. The Product Owner is the linchpin and a strong Product Owner is a key member of a successful implementation. An experienced Scrum Master or a Scrum Coach mentoring a new Scrum Master is also important. Expert developers, analysts and testers are keys to forming a high-performing team. The speed at which an Agile team moves can make it difficult for junior developers, analysts, and testers to keep up and can have a negative impact on the team dynamics.
  • Make allowances to teams implementing Agile for the first time. Allow extra margin for underestimating. The high level of transparency brings a new level of accountability to the team and that transparency can be scary and overwhelming to the team. It often takes a few months before estimating becomes more accurate. While a velocity gauge can be taken after the third or fourth Sprint, there are still undetermined factors that a brand new team may forget to take into account that may decrease velocity (such as estimating while in the same room and then dispersing into a distributed team, on-boarding and off-boarding team members, unexpected technical impediments, etc.).
  • Grant the team trust. Adopting a new process takes time and mistakes to integrate successfully into the organization. Grant your team trust from the beginning to give them time to adopt the process and allow space to make mistakes and recover from them. High performing teams are self-reflective and eager to do better.
  • Accountability and Transparency. If your organization is moving from a traditional methodology to an Agile methodology, you will suddenly be granted high visibility into a great number of details: the backlog, each Sprint Burndown, velocity of the team. This high level of transparency and accountability can be intimidating to the team. Provide support to the team during this transition. This transparency can be tempting to micromanage. The ways you can help the team manage through is with the next two points.
  • Do not micromanage. The level of transparency available in the project makes it easier for management to see the details of the project without having to maintain a handle on every single detail. Grant trust to the team to come up with great ideas. Because you, as management, have a bigger picture view of how the product fits into the overall company portfolio, provide discretionary corrections to the vision to assist the team if they are getting off track. High performing teams do appreciate feedback from those who have a vision of the bigger, organizational picture.
  • Be eager to remove impediments. This is a key role that Agile managers can take on. Often the impediments surfaced are organizational and systemic in nature: silos, communication habits, project-impeding processes, excessive documentation, unpleasant politics, and other company cultural issues that cannot be resolved at the team level. Agile Managers who take on this role of re-shaping the company culture around Agile values provide significant support to the team as they begin to tackle these systemic impediments.
  • Agile Managers provide KPI’s of Agile projects. Creating a dashboard of key Agile projects with the metrics that matter most in your organization is another valuable role management can offer to support the team. There is often great visibility and interest in the Agile team, especially if Agile is new in your environment. Providing a level of protection by supplying standard metrics to interested stakeholders helps protect the teams development time and focus.
  • Learn the Lingo. Although it may not be necessary to “speak Agile” immediately, eventually you will communicate more efficiently with your team once the Agile Scrum language becomes a regular part of their vocabulary. Your Agile teams will begin speaking a “new language” very soon. It is worth while to take some time to learn the various documents and catch phrases to increase your communication efficiencies with the team. Leverage your Coach or Scrum Master to develop a healthy exchange of Scrum language with the incumbent company language.
  • Support Your Team’s Accountability to Each Other. Before your team assembles, there are relationships and communication lines already in place. It will be the habit to continue these relationships and communication lines. However, once the Agile team is formed, team members are accountable to each other as a team first. The team is accountable to you, the management. Honor the team’s commitment and accountability to each other by encouraging your team members to address issues within the team first.
Pin It

Preliminary Activities and Introduction

Section I: Preliminary Activities

Before you start an Agile project, leaders and management should take some time to build good Agile framework foundations. Throwing the methodology at the team makes it harder in the long run. A little due diligence in preparation (hiring the right people, learning the lingo, and talking up Agile), can better prepare a committed team and any interested stakeholders with understanding the process and managing expectations.

 

Introduction

The Concept

Have you heard the Agile buzz and are now eager to throw your hat into the Agile ring and start implementing Agile projects? Do you want to try implementing Agile on your own before you hire a consultant so you can get the most out of the engagement? This is a workbook designed to take you through the practical steps of implementing a Scrum framework on your own, without a coach, on small projects. The idea behind this workbook is to implement the framework on medium risk, shorter projects (2-3 months) and surface the organizational and systemic impediments before you tackle a large project.

Reasons for This Approach

The reason for doing several small projects is to learn and refine your Scrum implementations before you take on a large project. Just like you need to work up to a marathon by running smaller runs like a 3k, 5-mile, 10k, maybe even a half marathon, you can work out the kinks of implementing Agile Scrum on your less risky (but still valuable) projects before you take on the bigger, riskier projects.

Agile has a tendency to surface major organizational issues such as communication, resource availability, silos, to name a few organizational barriers to Agile Done Well. Also, another reason for this recommendation is that there is a tendency to incur various deficits on large projects: testing, technical, architectural, training, organizational change management. If you are able to begin breaking down these barriers on smaller, less risky projects, you are better prepared to launch Agile on a large, risky project if you are in an organization with strongly entrenched processes and cultural habits. Let your lessons learned on several small projects lead you to fixing the organizational impediments or, at a minimum, raising awareness of organizational impediments before you launch a big project and factor these into velocity, your risks, Sprint estimations and start brainstorming contingency plans when these impediments arise on large projects. By the time you have incurred these significant debts, it is very difficult to fix them until the next release. Learn the painful lessons on small projects. Run small races to work up to your  marathon.

Pin It

Forward

The objective of this training manual is to provide an instant method of starting your project. I am the type of person that likes to read many books on the same subject to get as much information as possible so I can gain a rounded understanding on a subject. With that in mind, this is just one approach to starting up an Agile team. In the cost-conscious economy, I wanted to provide a format for small companies or teams to do a Do-It-Yourself Implementation while 1) starting a project 2) and training 3) and some basic information for effectively engaging management (especially if this is a “grass-roots” implementation). One final goal was was to 4) fill in a gap for teams who take traditional training and could use a daily step-by-step reminder.

This training also involves the entire team in a collaborative process in the initial sprint (Sprint Zero) for writing stories, writing tests as requirements, and development. When the whole team is more aware of each role, it opens dialogues increasing opportunities for higher performance.

Change management is a “squishy human resource thing” and it is hard to quantify results. Change is hard. Ingrained practices of working are like trying to till up a hard-packed dirt road…it takes a lot of work for the new practices to become second nature. Change management is the equivalent of tilling the fertile soil of the mind and questioning existing practices to prepare for the new way of doing things. For this reason, this DIY guide was designed to ask questions and open dialogue with the team. It is important to understand concerns, perceived risks, questions, and concepts that are liked, confusing, or disliked and share them with the rest of the team. Even if team members have participated in an Agile team before, like every individual, every team is at a unique place in their Agile journey. These questions can be used on a new team, a team that is mixed with Agile experience, or can be used for revisiting a process that may be a struggle for the team. It is important for the Scrum Master and Product Owner to note some of these concerns so they can prepare to address these throughout the duration of the project. The questions in this manual are designed to help the team start communicating with each other about their viewpoints on everything without judgment. This is the foundation of a high-performing self-organizing team.

For those who have already taken a class, you can still use this manual as a step-by-step implementation of each part of the project while you are starting up. The progression of the book covers the same material in the basic training classes, but lays out a day-by-day, step-by-step plan for executing your first Sprint, then stepping back and working on some Strategic planning, and then starting your second Sprint.

Pin It