December 19, 2016 | Project, Program, Portfolio Management
As a seasoned Program & Project Manager with over 20 years of experience, I have managed all types of projects for Fortune 500 companies. When implementing large, complex software solutions, I follow the traditional Waterfall approach – Requirements, Design, Build, Test and Rollout. Some of you may have heard a little something about a new methodology called Agile. Well, it’s not a “little something” and it’s not “new”. But it is new for this veteran Project Manager. That is until now. I was recently thrust into the world of leading a portfolio of projects for a new client using Agile, which is very different than Waterfall. So I asked myself two questions. Can you teach an old dog new tricks? And is all the hype around Agile warranted?
Agile came about as a “solution” to fix the disadvantages of the Waterfall methodology. Instead of a sequential design process, the Agile methodology follows an incremental approach which allows for fluidity and changes throughout the development lifecycle. Despite these benefits, here are some of the challenges I faced as I transitioned to this new world:
Challenge #1 – Who’s Who?
The first step in understanding Agile is understanding the key players; the Product Owner and the Scrum Master.
The Product Owner (PO) owns the Product Backlog and is responsible for what is delivered. He or she accepts (or rejects) the results of a Sprint, which is defined as 2-4 weeks of development effort. In our Services world, the PO has to work with key business stakeholders to prioritize the various external customers’ software implementations and all the work required to configure and build their solution.
The Scrum Master (SM) prepares and facilitates the daily Scrum sessions where the development team talks about their past 24 hour accomplishments, upcoming 24 hour targeted work, and any blocking issues they are facing. More importantly, the SM owns the framework that the development team follows along with coaching every development member on the do’s and don’ts in an Agile world. The SM works closely with the PO in planning the sprints and providing air cover for the development team members from other parties (i.e. Project Managers like me!)
Challenge #2 – Tell me a Story
In an Agile world, a user story is a tool used to capture a description of a software feature from an end-user perspective. A user story helps to create a simplified description of a requirement. Learning to write stories and taking one project plan activity and breaking it down into numerous stories was a challenge. In a Waterfall world, I’m used to writing about requirements. In Agile, the focus shifts from writing about requirements to talking about them. For example:
In a Waterfall world, the requirements are captured in one large requirements document broken out by functional areas (e.g., Operations, Sales) and are worded as “the system must be able to forecast the number of associates required to work in the store based on historical data”. These requirements are then used by the development team to build the system to perform this function.
In an Agile world, there would be numerous stories broken out to a more distinct level. For each user story, there would be the What, the Why, and the Acceptance Criteria. In the above example, one story could be around the data load itself:
- What: Load Historical Store Traffic Data
- Why: Required as input to determine the forecasted number of associates
- Acceptance Criteria: For each customer store, the data is loaded correctly and is validated.
A second story would be:
- What: Determine the # of associate required for each store based on their opening and closing hours
- Why: This will be required to create the optimized schedules for the store manager
- Acceptance Criteria: Store manager is shown the number of associates required for each hourly time slot.
With the granular level of detail in stories, there is less ambiguity for the development team members in an Agile world which helps with the overall quality of the software solution.
Challenge #3 – Agile and MS Project Are Not Friends
In a traditional Waterfall development project, I can easily set start and end dates for each of the phases for my development. In an Agile world, I would similarly plan dates for our customers including pilot date and roll out date. Unfortunately, this concept of placing dates on user stories is not supported. In the early days of my new Agile engagement, I was placing dates on key user stories instead of correctly planning my user stories in the backlog to coincide with the sprint schedule already defined by the Product Owner and the Scrum Master. In essence, I have had to become a different Project Manager by adjusting priorities across my several projects since some were ready to progress quicker than others.
What I Love about Agile
After about a month in this new role, I could definitely see the value of an Agile approach and began to see activities that I liked over a traditional Waterfall approach:
Daily Standups (e.g., Scrum session): Having managed projects with large technical teams, I typically conduct weekly project meetings with the team leads (e.g., Dev Lead, Testing Lead, etc.). In an Agile world, I sit in the 15-minute daily standup meetings with the actual consultants who are working on the software solution. Blocking issues are voiced and brought to immediate resolution.
Peer Reviews: Although this practice has been associated with the Waterfall approach, the method of how this is implemented in an Agile world is very transparent. When development team members have worked on the User Story and have completed their work, they place the story in “Needs Peer Review” status in a tool called Jira. This allows visibility to all members of the scrum team and allows the scrum master to target these stories for completion during the daily standup. From a PM perspective, knowing that only a review is needed for that story to be completed, I am able to track progress more effectively and efficiently.
Acceptance Criteria: One of the key aspects for User Stories is not only identifying the What and the Why, but the Acceptance Criteria as well. In the world of Waterfall, test scripts are typically written for system and end-to-end testing scenarios. In an Agile world, each of the stories has the criteria for which the story or task was completed successfully. This allows for improved overall quality and a reduction in issues found.
Summary
Yes, you can teach an old dog new tricks, and the hype around Agile isn’t hype. There are plenty of advantages to using Agile or at least some of the elements of Agile. Agile allows for quicker development efforts and when used properly can improve the overall effectiveness and efficiency of a development team. In addition, Agile gives stakeholders visibility to progress over shorter timeframes (e.g., weeks vs. months) and allows for shifts in direction during the project.
Agile is not just about application development. There is a significant Organizational Change Management component that requires behaviors, decision-making and Business Sponsor protocol to change. According to CEB’s 2015 State of Agile survey, 78% of organizations say that Agile requires more business sponsor time than the more typical Waterfall processes. More than half of Agile teams interact with the business multiple times per week or more, leading to overwhelmed sponsors who delay development as delivery teams must wait to reprioritize requirements and make decisions.
For more information on how Lake Shore Associates can help you with your project management and organizational change management needs, visit www.lakeshore.is.
