Agile development methodology has been around for awhile but it is currently in vogue and many are talking about it and asking to implement it. This discussion will compare and contrast Agile with typical project management methods and provide some scaffolding for deciding if it is right for your organization.

Iterative and incremental development methods can be traced as far back as 1957 but the ball really got rolling on Agile methodology in the late 1990s and early 2000s (dotcom, anyone?). Typically, it was applied to software development and its rapid pace of change and time-to-market pressures. These days, it can be tailored to use in a large number of development applications where agility and iterative responsiveness to a shifting landscape is key to success.

Most agile methods will break work into small increments called sprints that are timeboxed into one to four week segments. A cross functional, self-organized team handles all functions including planning, analysis, design, coding, unit and acceptance testing. At the end of each sprint, a working product is demonstrated to stakeholders. The goal is not to have a finished or completely bug free product but rather to have a demonstrable iteration which has incorporated as many changes as possible into the current sprint. Requests that couldn't be integrated become part of the backlog and are prioritized into future sprints as necessary.

In addition to technical resources known as team members or Developers, every team should include a client facing Product Owner and a Scrum Master.

Developers

The development team consists of technical resources such as programmers, engineers, analysts, marketing and delivery experts, administrative and support resources, etc. The only official role recognized by the Scrum Guide is "Developer". It is up to the team to self organize and to deliver the sprint results. There is no hierarchy within the team. They are responsible for planning, design, development, testing and project delivery as a group.

The Product Owner

Also known as the On-Site Customer or Active Stakeholder, this person represents the voice of the customer and is responsible for documenting user stories and requirements for the project as well as maximizing ROI and prioritizing backlog.

The Scrum Master

Also known as the Team Lead, Team Coach or Project Lead, this person acts as coach and facilitates and guides the team. He or she is responsible for obtaining resources, removing obstacles and shielding the team from politics. Typically softer project management skills (team building, coaching, motivating, engaging) are emphasized over typical planning and technical skills usually associated with traditional project managers.

Now that the basics of the process have been laid out, let's zero in on the role of Scrum Master as it relates to Project Management.

You might be tempted to ask something like "if the Developers are responsible for planning and implementing their own development process, what role could a project manager have?" It's a fair and sometimes confusing question.

The Scrum Master does anything possible to encourage highest performance from the team. This might include such things as removing impediments to progress, facilitating meetings, working with product owner to prioritize backlog for future sprints, and so on. In addition, they may work with a person in a normal style project manager role as part of a larger project. Let's break some of these Scrum Master roles down and see what might typically fall under the Scrum Master's purview.

Meetings

• Preparing meetings, making sure all tools and resources are there, etc.
• Moderation of meetings
• Helping the team maintain its Story Board, Action Board, charts and backlogs
• Helping the team find a suitable definition of "Done" and "Ready"
• Post mortems and post processing of meetings to disseminate info

Team Dynamics

• Mediating general conflicts between Product Owner and Team
• Mediating developer conflicts
• Fostering the team's self-organization
• Coaching the team or individual members
• Helping facilitate the decision making process
• Making sure Agile and Scrum methodologies are followed
• Helping to continuously improve
• Asking open questions
• Delineating variances between models the team uses and the real world
• Suggesting new metrics for the team as catalysts for change

Product

• Helping to write or split user stories
• Write or adopt product visions
• Release planning

Learning

• Promote and educate all things Agile to the team
• Giving feedback
• Help team create information radiators
• Constantly exchanging with other Scrum Masters
• Doing Gemba Walks (much like Management by Walking Around also known as gemba kaizan, it is a Japanese technique to bring management to the production floor to gather data for improvement)
• Encouraging Agile Engineering Practices

That said, is a Scrum Master a full time job? Well, it certainly sounds like it! According to the Scrum Master Manifesto, "we believe the Scrum Master is a full-time position for one person on one Scrum team". Might it be possible to Master more than one Scrum at a time? Well, it depends - mostly on the complexity of the development effort and the size of the development team. Some experienced teams working on simple deliverables may be able to share a Scrum Master between them.

Now lets compare Agile methodology to a typical Project Management role using a real world example. Say you work for a Tier 2 defense or aerospace contractor and your company just won a contract to produce widgets that fit between part x and y for a Tier 1 prime contractor. You have been asked to lead the development team. What's the first thing you get as project manager? A detailed SOW (statement of work) including engineering interface drawings showing how your widget fits onto part x and must allow for the fitment of part y. You get a production time line, expected number of units for the first production run and a whole bunch of goobledegook federal mumbo jumbo terms and conditions that need to be complied with to meet the requirements. There may be stress and vibration testing, long term storage testing, extreme environment testing, etc. that all has to be documented and completed. Once you have a process that produces the widgets correctly according to ISO9000/1 standards, there may be an on site rep that has to sign off on even the smallest process change, and everything from individual engineering drawings to process instructions for shop floor personnel has to be revision controlled. Not very agile sounding is it?

So, this is our first key difference. In Agile Methodology, you are producing a constantly (iteratively) changing product that has to be produced once (software) and then can be reproduced trivially (digitally) as many times as necessary. But, in our widget example, all the R & D work (iterative research and development) was already completed by the prime contractor and sold to the government, and your company's job is to be able to reliably and reproducibly manufacture the part over time according to a preset schedule. In this case, Agile teams are not going to be necessary or appropriate. In this case, typical project management duties such as managing scope creep, producing work breakdown structures and critical path milestones and managing risk, integration, cost, time and stake holder expectations are more appropriate.

Let's put it into table form:

In summary, it is important to identify the needs of the project and choose a solution methodology which scaffolds (supports) the overall goal. If you have lots of detail up front and anticipate only incremental changes and a large team size, you can choose typical project management with confidence. If you have smaller teams with lots of iterative changes you will lean towards Agile approaches.

Call me today to learn how I can help you implement the best solution for your project needs.

"Project management is my life. I love what I do!" I will measurably enhance your project budgets and solve the biggest problems on your plate with real-world efficiency gains by empowering others and applying over 23 years of strategic and critical decision making experience.