Riding the Agility Surfboard on the 3rd Wave of the Internet
By Tom Friend, FLEX Coach, CSP, ACP, AHF, PSM, CSM | Business Agility Consultant, IIL
Catch Tom’s presentation, “Collective Intelligence: Leveraging the ‘Swarm’ on your Teams,” at the virtual Agile and Scrum conference on May 4th.
Today, we are on the cusp of the third wave of the Internet. A vast ocean of opportunity lies before us.
The first wave was creating the cable and switches that became the backbone of the World Wide Web. The second wave was an increase of connections between people on social media and of business platforms. Now, this third wave will leverage business services in conjunction with distributed cloud solutions that we are only beginning to imagine.
As the future emerges, attention is moving from an internally based analytical view of planning and delivery to a more outward emphasis of identifying and responding to threats and opportunities. Meaning that traditional project management methodologies and waterfall mindsets will not be able to keep up with the valuable products and services that customers are looking for in this new wave. As companies move away from old methods it is vital to select the right Agile frameworks and practices.
However, keep in mind that it’s not only the framework and practices that need to be addressed but the organizational decision-making process.
Many times this process will retain its hierarchical structure which short circuits fast Agile feedback loops. This legacy from old processes has led to the rise of “Water-Scrum-Fall”, where Agile practices are adopted mechanically but culture, habits, and values of the organization have not changed, resulting in a lot of frustration of doing something new, but not seeing positive results. Paddling the surfboard out to the waves is quite different than riding it in.
Organizations that successfully integrate Agile typically do not only focus on a process-led approach, but focus on creating a shift in culture. Processes and teams are temporary, whereas culture creates the default habits that persist in an organization. A positive culture requires commitment, leadership, and a willingness to follow. These qualities mean something different for every organization.
In this third wave, predictability is no longer a competitive advantage—adaptability is. The value of Agile is not in its practices or processes, but in the mindset shift. This shift helps develop individual core competencies to be adaptive, transparent, collaborative, and responsive. There is a difference in doing Agile and being Agile. When you become Agile, you have gained the associated competitive advantage over your competitors.
Agile is turning the traditional way of developing software upside down. The framework and practices help an organizations’ team visualize a solution, engage the right people, and deliver the highest business value. This is supported by the collaboration between the team and the customer on contracts, requirements, and dialogue.
By focusing on the people within your organization and leading them to be Agile, you can free your teams from a complex process and structure-led response to disruption. Your organization can develop a culture that thrives in complex, unpredictable, and rapidly changing environments.
Catch the wave and enjoy the ride. Surf’s up!
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
Tom Friend is an Agile Coach and Trainer currently at Duke Energy in Charlotte, NC. Tom is a retired military pilot, small unit leader, and squadron commander. He is an accomplished Agile consultant, trainer, and coach with 23 years’ experience leading software development teams in various industries to include federal, banking, cable, telecommunications, and energy. He has 12 years of hands on Agile / XP / Scrum software development experience. He is a distinguished graduate from Air War College and has a BS in Aeronautics. [/trx_infobox]
In Scrum, Everything is 100% Complete. Really? Not So Fast!
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL
Catch LeRoy’s presentation, “Agile: The One Bandwagon You May Want to Jump On!,” at the virtual Agile and Scrum conference on May 4th.
Years ago I worked with a guy whose last name was Dunn. My boss used to call him “not Dunn” because he never seemed to be able to complete anything. That always made me laugh, but in the end, it’s not really that funny because if people can’t finish anything then chances are they get a pretty bad reputation in a company.
I thought of him while reading The Scrum Guide™, authored by Jeff Sutherland and Ken Schwaber. One of the three tenets of Scrum Theory is Transparency which the authors describe using two examples. One of them is as follows:
Those performing the work and those accepting the work product must share a common definition of ‘Done.’
The concept of percent complete has always been subject to a wide range of varying definitions and interpretations. What is 50% complete to one person, or group, may not be to another.
For example, the project manager may report that the project is 50% complete because half the resources and costs have been incurred and the deliverables are well on their way to being completed (even though nothing has been delivered yet).
The client, on the other hand, who may also be obligated to making progress payments based on percent complete, may think it’s a lesser percent because they haven’t received half the benefits or inspected or reviewed “half” of the deliverables. Without an adequate inspection system, or prior agreement as to what 50% complete means, it’s one person’s word against the other’s.
Let me present an interesting example.
I took this picture of the front window of the Metropolitan Transit Authority’s (MTA) Project Office on 2nd Avenue in Manhattan. The sign informs the neighborhood the progress made on this megaproject. As you can see, MTA reports the project is 82.3% complete.
What does that really mean? Does the .3% make you feel that they really know what they’re talking about because it conveys a sense of accuracy? Your guess is as good as mine.
As a consequence, it’s always been sort of a game, and a guessing game at that, to determine percent complete. It’s a lot more art than science. And, when you add the obligation of progress payments based on percent complete, disagreements are more the norm than the exception.
I don’t see this issue magically disappearing because of the concept of Done in Scrum. As far as I can tell, what is Done is the deliverable to be produced at the end of the Sprint. But what percent complete is the entire project based on one deliverable generated by one Sprint? It’s a rhetorical question, so if you have a rhetorical answer please speak up!
I have no issue with Done; in fact, I think it’s a great idea to have all parties agree as to what that means. But to avoid potential disagreements I think the lessons of the past can apply to Scrum projects as well.
For example, in the earned value method (EVM) a task was recorded 50% complete the day it started, and 100% complete the day the requirements were met. This took all the guesswork and differing interpretations out of the equation so that the project manager and client could at least agree, at a high level, just how far along the project was and how much the buyer had to pay the seller. Might this work for Scrum? Maybe, maybe not.
As for this post, I think I’m Done!
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs. [/trx_infobox]
Can Microsoft® Project Be Used for Agile Projects?
By Keith Wilson, B.Comm., PMP, MCT, MCTS | Senior Trainer and Consultant, IIL
Can Microsoft Project be used for Agile projects? Yes! Customizable fields and custom groups can be used effectively to create an Agile template. Custom fields allow you to add project-specific information, which can be used to filter or group tasks to provide different views into the Agile schedule. It is possible to create a schedule for planning, communicating, and tracking Agile projects, or with an Agile or a hybrid method.
Key characteristics of the Agile development method are Iterative, Incremental, Embraces change and Delivers a deployable product early for a quick ROI.
Agile teams deliver complete and functioning code within short iterations. During the iterations, all of the necessary work to take features from an idea to a working product is completed without artificial dependencies that prevent work from being done in parallel. The end result is that portions of the product are delivered on a regular and frequent basis. This gives stakeholders a much better idea of the state of the project, because they can see and use the end result as it becomes available.
The strengths of Agile development:
- Delivers minimum usable subset
- Delivers on time and to cost
- Iterative development for evolving solution
- Flexible processes
- Collaboration of whole team
So what project-specific data must be added to create an Agile schedule?
An Agile project starts with a backlog, which is a list of features to be implemented, and a number of iterations or sprints to implement those features, which are represented as tasks in the schedule.
In addition, each feature will have a priority and a size estimate represented in story points and will be mapped to a sprint. Story points (which can be numbers – e.g., 1, 2, 5, 8) are relative values based on the size or difficulty of a user story relative to other stories. When you estimate using story points, you estimate the “bigness” of a user story compared to other stories. Each feature and sprint will also require a status (e.g., not started, in progress, or done).
To create an Agile project schedule we need to know:
The duration of each sprint, the release date if there is a planned release including several sprints, the priority of each feature in the backlog, the feature complexity or story point value, user need or priority and state. In addition we will need to know the resources and the percentage of their time available per sprint and each resource loaded labor rate.
We will need to create custom fields for Agile-specific information including:
User Need Text Field
Lookup Table: Low, Medium, or High
State Text Field
Lookup Table: Not Started, In Progress, or Done
Story Points Number Field (Estimate of Story Points)
Set Calculation for task and group summary rows to Rollup: Sum
Sprint Text Field:
Lookup Table: Backlog and Sprint 1 through Sprint n
It will also be necessary to create two Groups:
Sprint Group by Sprint.
The Sprint group will list all features in each Sprint; story point totals roll up for each sprint. Features not assigned to a sprint will be grouped under Backlog.
Burndown Group by State, then by Sprint.
The Burndown group will provide story point summary by categories: Done, In Progress, and Not Started.
Story point totals roll up.
The Agile schedule will also require two summary tasks: Sprints and Features. Under Sprints, enter the expected number of sprints, including the name and duration of the sprint, and link them in sequential or finish to start order. Then list the features under Features summary task. Make each of the features a milestone, by indicating a zero duration. By default the features will all be in Backlog. To assign a feature to a specific sprint, select the sprint number in the Sprint dropdown. Also, when you assign a feature to a sprint, set a finish-to- start predecessor to that sprint so the expected finish date of each feature will be known. When tracking the project, if one or more features is not completed in a specific sprint, it is easy to just update the sprint number and the predecessor to move those features to another sprint.
Build a resource pool with real or generic resources. Be sure to include a rate per resource and other know attributes such as Calendar, Max Units, Group, and Rate. Once you have the resource sheet complete, assign the resources to each sprint and indicate the percentage of time that they will be working on the Sprint. Since there is a rate per resource, Microsoft Project will multiply the duration by the percentage allocation time for each resource and then by the resource rate. It will then summarize each resource cost per sprint to provide a total cost per sprint, which in turn can be rolled up to show the total cost of the project.
The following is an example of a schedule with sprints that have a duration of 15 and a dozen features and is using the custom Burndown group, grouped by state and sprint. It also displays the total number of story points for each of these states:
Custom fields are a powerful feature of Microsoft Project, and when used with custom groups, we can actually use Microsoft Project for an Agile project without knowing which features each sprint will be addressing. Given the duration of each sprint, the resources, resource rate, and percentage assigned it will be possible to calculate the cost per sprint; and if the sprints are rolled into one release, the total cost and duration for that release or project.
Leave a comment below if you’re interested in receiving a downloadable template.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
Keith Wilson is a Microsoft Project and Project Management Senior Consultant/Trainer for International Institute for Learning, Inc. His background includes over 25 years of successful management and consulting experience, with a focus that includes project management, training, and business planning. Well known for his public speaking skills and enthusiasm, he has been a welcomed facilitator at numerous Fortune 500 corporations, Universities and Associations worldwide.[/trx_infobox]