Author: Andy Makar

Andy Makar

About Andy Makar

Dr. Andrew Makar is an IT program manager and is the author of Project Management Interview Questions Made Easy. For more project management advice, visit the website Tactical Project Management.

Five Ways to Thank Your Team without Breaking the Bank

| Comment
Featured Teams

With Thanksgiving in a couple of days and the December holidays approaching, I’m reminded of the importance of taking the time to recognize the team. As managers, we should recognize teams frequently, but the end of the year usually provides us with the formal opportunity. Project teams work long hours to deliver seemingly never-ending projects, and it can be exhausting tackling issue after issue. When the project finally ends (and they all do), it is important to recognize the team’s contributions.

Of course, everyone would like more money, but a raise is only a temporary motivator and usually occurs annually. Team celebrations and end-of-year parties always help, but when the budget is tight, managers sometimes need to get creative in finding cost-effective ways to thank their teams for a job well done without having to get CFO approval, even if it means funding them yourself.

Here are five ways to thank your team without breaking the bank or your personal budget.

Team Thank You #1—Grab a Pizza

In Detroit, we’ve got Buddy’s Pizza—a Metro Detroit icon since 1946 with fantastic pizza. I’m sure you have a similar old school pizza establishment in your town. If you’re stuck for a fantastic pizza location, just go to eater.com and search your city for the best pizza. Pizza works great because it appeases the vegetarians and the meat eaters as you can split a couple of pizza pies, salads, and breadsticks. At $20 a pie, the most you’re going to spend on a ten-person team is about $200 for lunch.

In a recent project, our discretionary budget was low, so I split the $200 lunch tab with the other manager. In other projects, I’ve just paid for lunch out of pocket. Spending a Ben Franklin or two and bringing the team together is well worth the team building and relationships forged over a slice.

Team Thank You #2—Buy the First Round of Drinks

It may not be HR approved or politically correct, but team building over a glass of wine or a local craft beer is a good idea! Even if you don’t drink, getting outside the office and socializing with your team members and coworkers helps to improve team relationships.

If you want to reward the team informally, without appearing as “the boss,” simply schedule a happy hour after work and offer to buy the first round of drinks. It is a socially acceptable way to say thanks, let’s relax, and have a beverage.

I recently went to a happy hour with my team and other peers, and we realized that we need to get out more often and simply socialize. We spend so much time in meetings and exchanging emails, texts, and instant messages that we don’t invest time in getting to know one another. Offering to meet up at a local watering hole after work and buying the first round is a nice way to get everyone together.

What if people don’t drink?

I’ll also buy a couple of appetizers, and soft drinks are a low-cost addition to the bar bill.

Team Thank You #3—Get Vendor Swag

If you don’t have the budget to reward your team, chances are your software vendor does! Sales representatives and marketing departments often have discretionary budgets to take team members out to lunch as well as pallets of notebooks, mouse pads, T-shirts, and pens. If your team has accomplished a significant milestone using a vendor’s software solution, simply ask your sales representative if they have any promotional materials.

I’ve done this multiple times and have found vendors are always willing to get their branded material onto people’s desks. That is why they have a marketing budget!

Team Thank You #4—Give a Book

A fun way to reward an individual or a group is with a book! I’m a fan of personal productivity and books that help team members accomplish their goals. Each book is $10–$15 and are excellent ways to thank a team with some knowledge bombs! Below are my top five recommendations.

GRIT: The Power of Passion and Perseverance by Angela Duckworth

GRIT is an inspirational read that cultivates and grows the drive for results and perseverance to deliver despite business challenges.

The Miracle Morning by Hal Elrod

The Miracle Morning provides best practices and sound advice on how to be more productive even though getting up before 5 a.m. can be difficult to do!

The One Thing by Gary Keller

The One Thing help you solve the feeling of being overwhelmed by providing a clear way of prioritizing tasks and to actually make progress towards goals in less time.

Getting to Yes by Fisher and Ury

I read Getting to Yes over 15 years ago, and the importance of a BATNA (best alternative to a negotiated agreement) still stands out and is useful in contract negotiations.

The Adventures of Johnny Bunko: The Last Career Guide You’ll Ever Need by Daniel Pink

The Adventures of Johnny Bunko is an easy and fun career book disguised as a graphic novel.  A perfect gift that reinforces solid career planning principles.

Books make great gifts and last a lot longer than a lunch does.

Team Thank You #5—Pen a Handwritten Note

In the days of Google Docs, Facebook wedding invitations, and pre-preprinted thank you notes, the handwritten note on good ol’ stationary is still a welcome and thoughtful thank you. One year I received a personal thank you note from our IT director written on her own personal stationery. I was impressed she had her own monogrammed stationery but was even more impressed she had taken the time to write a few thoughtful words recognizing the accomplishments.

It only took her a few minutes to put meaningful words to paper, yet it is a thank you I still remember!

Thanking your team doesn’t have to break the bank. It always helps when the company can fund a nice evening out for the team or a lunch that goes beyond $8 per person. However, budgets are tight, and if you can’t get your company to fund team recognition, hopefully, these ideas will help!

How do you thank your team? Let us know in the comments below.

 


Michael Myers—Performance Review

| Comment
Featured

In the workforce, everyone receives an annual performance review—even horror icons like Michael Myers. Since 1978, Michael Myers has demonstrated his perseverance in pursuing his sister, Laurie Strode, nearly a dozen times!

The Horror Icons of America Guild (HIAG) recently completed Michael’s latest performance review, and this lucky reporter was able to secure a copy to share with you!

Horror Icons of America
Performance Review
Employee Info
Employee Name Michael Myers Department Horror
Employee ID 10312018 Reviewer Name Jason Voorhees
Position Held Horror Legend Reviewer Title Supervisor
Last Review Date August 28, 2009 Today’s Date October 19, 2018
Current Responsibilities
●     Eliminate the family tree including Laurie Strode and any other siblings or relatives.
●     Avoid capture by Dr. Loomis and any related psychology and law enforcement staff.
●     Successfully escape from mental hospitals or secure police transportation.
Performance Assessment
Evaluate performance and achieved goals.
Mr. Myers displays a tremendous drive for results as observed in 10 different attempts to eliminate his family bloodline.
He has consistently displayed perseverance and dedication to his work by working extremely late hours and overcoming obstacles (usually in the form of teenage miscreants).
He demonstrates a commitment to the work by overcoming gunshots, fiery explosions, and multiple stab wounds in his efforts to remain alive. This commitment goes above and beyond the expectation for our employees.
Despite these strong leadership behaviors, Mr. Myers has failed to successfully capture and eliminate Laurie Strode numerous times, despite the opportunity being presented to him every few years.
Discuss areas of improvement.
Improve communication. Though he is fully capable of speech, Mr. Myers rarely communicates verbally. Establishing better communication as he interacts with others will help him achieve his goals. Pursuing a local Toastmasters International club is encouraged.
Avoid distractions. Mr. Myers should avoid distractions, such as approaching college students in compromising situations. Doctors, nurses, police officers, security guards, and any other people should be avoided. This will enable Mr. Myers to focus clearly on his main goals.
Apply critical thinking. At nearly 62 years of age, Mr. Myers should have a lifetime of experience to learn from and apply to problems and challenges. He would benefit from better decision making and learn to avoid gunshots or taking on knife attacks head on. Although he pursues work at his own pace, he could achieve his goals faster by running versus his slow mechanical walk.
Improve teamwork. Given Mr. Myers has failed to achieve his goals multiple times over the past four decades, he should look to leverage a team of movie monsters rather than pursue his target alone. He is encouraged to speak with Vlad the Impaler, the entire Aliens department, and the cast of the Wrong Turn franchise on how to build a team for effective execution. He should also note the failures from Frederick Krueger, Charles Lee Ray, and Norman Bates for future lessons learned.
Develop future goals with set expectations.
For 40 years, Mr. Myers has been trying to eliminate his sister, Laurie Strode. Through his previous 10 attempts, Mr. Myers has only been successful once in attaining his goal; however, multiple reboots have resulted in him having to start from scratch. Our hope is that, with the next installment of the Halloween series, Mr. Myers will exceed expectations.
Comments and Approval
Provide any additional feedback.
●     Employee declined to provide feedback or acknowledge the review.
Employee Signature Reviewer Signature

Happy Halloween!


Three Real Agile Team Challenges and How to Solve Them

| Comment
Advice Collaboration Featured LiquidPlanner Tips

Agile means a lot of different things to different project teams.  Many teams I meet describe themselves as “Agilish” or use “Scrumerfall”.  These teams struggle with Agile practices as business analysts author reams of business requirements only to have a development team write the user stories.  Business representatives assume the product owner role but only check in with their team at the sprint review.  My personal favorite is adding more scope to an active sprint and the team wonders why they can’t meet their velocity goal.

Many of these issues stem from getting the Agile roles and processes right at the start of the project.  According to the Scrum Guide, a scrum team has only a few roles by design – Scrum Master, Product Owner, and the Team.  In Dean Leffingwell’s book, Scaling Software Agility, he favors eight or fewer team members including product owner, developers and testers.   If you have recently obtained your 2 day Certified Scrum Master (CSM) certification, you are likely excited to transform you team with renewed enthusiasm.

Then you take this newly acquired knowledge and real life hits.

Real World Agile Challenges

How many of you have experienced these real-life scenarios?

  1. The development team is distributed
  2. The development team is a 3rd party vendor contracted for a fixed scope with their own software practices optimized for their organization
  3. The product owner has the title but doesn’t perform the product owner role.  The team then typically struggles with identifying and prioritizing business needs, receiving timely feedback and managing change.

Even though the Agile ceremonies aren’t hard to understand or follow, Agile implementations still struggle if the roles are not correctly understood.  Fortunately, there are some Agile approaches to overcome these real-world challenges.

#1 Agile with distributed teams

Co-location is helpful but it isn’t always realistic as organizations scale their Agile implementations.  Finding competent local talent isn’t always possible and organizations often select firms located across the country.  If the development team is located in different regions, the Agile practices can still be delivered using Skype, WebEx, GoToMeeting or your favorite video conferencing tool.  The key is ensuring there is enough communication between the team members including the product owner.

In one of my global programs, we ran two Agile teams distributed in the United States and Europe.  The team conducted the Agile ceremonies supported by WebEx and also traveled quarterly to the global headquarters.  The team was effective at delivering the backlog but also recognized the value in co-locating for important periods of time.

The key takeaway is to co-locate for a short period of time and communicate daily across multiple channels.

#2 Managing the outsourced vendor with their own software methodology

In an outsourced relationship, the company is entirely dependent upon the vendor’s ability to deliver according to the vendor’s methodology.  I’ve seen wonderful Agile presentations from vendors claiming Agile expertise only to see it fall down due to their own internal development process.  If you can’t influence or control the vendor’s software delivery process, Agile techniques can still be applied to define user stories and prioritize the most important features.

In a mobile software development project, the vendor claimed to be Agile but delivered in a Scrummerfall manner with two weeks of development followed by a week of testing.  The team struggled with changes as requirements were elaborated.  The business viewed changes to requirements as defects in the software and the vendor insisted the requirements were not provided accurately nor part of the original contract.  Meanwhile, the timeline kept ticking by with a launch date approaching.

The best the team could do was to ensure bi-weekly feedback while they spent an enormous amount of time defining the product backlog.   It wasn’t an ideal Agile approach but the team delivered after 6 weeks of system and user acceptance testing.

In hindsight, it would have been better to contract with the vendor on a resource based model allowing the project team to drive scope and determine how the project would be implemented.  The scope would be jointly managed rather than contractually managed.  This approach puts more risk on the project team but also ensures both the vendor and the project team can function as one team.

#3 Product owner by name only

In traditional IT, the business customer provides high-level requirements to an IT team and accepts or rejects the solution after reams of process flows and requirement documentation.  With Agile, the business customer has a new title – product owner – and is expected to collaborate with the team to define needs, refine the product backlog and prioritize features for each sprint.

This doesn’t happen as easily as anointing a business customer with a new title.  The reality is the business customer already has a job running the business.  It becomes difficult for a business customer to run the business and engage in all the Agile processes.  I’ve seen product owners disappear for a week because they were pulled into a crisis or had to resolve a business problem.  Consequently, the team struggled with prioritization and feedback.

One approach is to allocate a “product owner by proxy”—an empowered business analyst or additional resource who is not running the day to day business but can help define the product needs while getting appropriate feedback between the product owner and the team.  The product owner still needs to engage the team by attending sprint reviews, however, the proxy product owner engages in the day to day sprint execution.  This model, although not ideal, still provided enough feedback to the team to develop the right product.

 

Agile isn’t as easy as it seems

Agile in a textbook and in implementation are two different stories.  Teams just don’t become Agile by reading a book or taking a certification course.  It takes time putting the Agile theory into practice and optimizing the Agile processes within the team.  Executing the Agile ceremonies help identify pain points within the team and the retrospective helps to make improvements frequently.

Adopting agile techniques appears easy but challenges quickly appear if the organization doesn’t solve for solutions to distributed teams, fixed-price contracts or insufficient resources and roles.  The challenges previously mentioned are just a few of the roadblocks teams will encounter as they adopt Agile practices.  If the team focuses on developing software incrementally with quick feedback loops that enable teams to embrace change, then challenges can be addressed head-on.


Top-Down vs. Bottom-Up Project Management Strategies

| Comment
Featured Project Management Teams Tips

“How long is that going to take?”

As project managers, we’re driven by dates. Customers, senior managers and stakeholders all want to know how long it will take to complete a project. And as project management professionals, we’re also measured by our ability to predict the future and be right about our predictions—despite the many unknowns. To answer the “how long” question, we have to plan the project, define tasks and gather estimates from the team.

When planning a project, the two most common questions, I ask up front are:
  1. What are the tasks?
  2. How long will the tasks take?

These are relatively simple questions, yet the project management field has developed many different techniques to answering these questions. For example:

When you define the tasks, do you:
  • Follow a prescribed template or formal “standard” to plan the project?
  • Do you look at past projects for similarities and reuse their project schedules as a starting point for project planning?
  • How do you use top-down or bottom-up approaches to plan your project?
When you estimate each task’s duration and cost, do you:
  • Ask a bunch of experts
  • Use a similar project’s estimates
  • Apply top-down planning
  • Spend more time building a bottom-up estimate?

When you look at the various techniques, there are a lot ways to answer those original two simple questions I pose at the top of this article.

Here’s a look at how to use top-down and bottom-up planning to identify and estimate your project tasks.

Question #1: What are the tasks?

Using the top-down approach

The top-down approach to defining project tasks involves starting with the project goal or final deliverable, and breaking it down into smaller planning chunks. We call them work packages. Each of these work packages or “chunks” is further refined into greater detail, and then work items are assigned to team members.

The top-down approach works well when there’s clear insight into the details of a project, and the leading project manager has a big-picture of how the project contributes to the organization.

The benefit of top-down is that the major tasks are quickly identified, and the details are later refined by the project team. However, the downside is that details might be missed without a detailed review by the project team.

A top-down example

Let’s say you’re responsible for upgrading your application’s hardware and software layers. Based on past experience, you know you’ll need to install a new server, install the upgraded operating system, and then install the latest version of the application software. These are all top-down tasks that can be assigned to a project team to implement. The risk is that the application software doesn’t work on an upgraded software layer due to a conflicting API or compiled library. The challenge is in all those pesky details that impact your project.

Using the bottom-up approach

The bottom-up approach to answering “what are the tasks” relies on project team members identifying the tasks and then organizing them into specific groups or work packages. If you applied a bottom-up approach to identify tasks for the software upgrade mentioned above, the entire project team would brainstorm all the tasks required to correctly upgrade the system. There’s also a greater chance that a team member will identify an operating system conflict or at least include a step to test that feature than in top-down planning. Ideas get flowing and tasks can be written down on sticky note pads or index cards. All these tasks can then be logically grouped into categories that make up each work package.

The bottom-up approach results in a more detailed schedule, but it’s also a time-consuming approach compared with the top-down task planning approach. The schedule you create is based on direct input from experts who will be implementing the project; it’s also a useful technique to build teamwork.

If your organization doesn’t have previous experience with the type of project you’re trying to plan, this approach helps identify unknown tasks.

Question #2: How long will the tasks take?

Once you have the tasks, the top-down or bottom-up estimation approach can be applied.

Using the top-down approach

The top-down approach to “how long” is usually done by managers for budget planning, portfolio planning or for conducting feasibility studies. In these cases, a great level of detail isn’t known and there are many assumptions made with potential inaccuracies.

I’ve used this approach when planning the next year’s project portfolio, and estimating the number of resources required while developing a rough project timeline and cost estimate. At this stage, I don’t know the full detailed scope, but I know I need people and a budget to complete the project. During the project planning phase, I’ll detail the specifics and refine the actual costs.

Using the top-down approach, the project timeline and cost accuracy isn’t very precise, as detailed planning hasn’t begun. The cost and timeline can be used as a range or a guideline, but formal budget and date commitments should wait until detailed planning has completed. The benefit of using the top-down approach here is that funding and resource planning can be done quickly through consensus. The trade-off is that project cost and schedule dates aren’t as accurate.

Using the bottom-up approach

The bottom-up approach to “how long” is my preferred project estimation method—but it takes a lot more time than top-down planning. In the bottom-up approach, the project team has defined the tasks and can make accurate estimates at a detailed level. Then, the sum of these estimates and task dependencies within each work package determine the total cost and timeline for the project schedule.

This technique is useful for developing detailed project budgets, schedules and monthly forecasts. And, it helps define the specific resource skills needed during key phases of the project in order to get a more accurate schedule. The tradeoff of using a bottom-up approach is that it requires more time.

Investing in the right approach

Project managers and stakeholders all want an accurate accounting of time and project costs. However, this level of accuracy costs money and time to produce—which means project managers and stakeholders need to balance project accuracy with project delivery.

I’ve been on some projects where the team had the luxury of spending several months to plan a project. More often than not, I’ve found that the project team is asked to meet a committed date in the future based on a top-down planning exercise. In these situations, I’ve conducted the bottom-up planning, identified the potential unknowns, and use time to further detail those unknowns and mitigate potential risks.

A bit of both

Project planning can rely on both top-down and bottom-up planning techniques. The technique you choose depends on your specific planning goal. If you’re pursuing a portfolio planning goal, you’ll likely do a lot of top-down planning and let the project team work out the details.

If you’re the project manager implementing the current year’s plan, you’ll apply a bottom-up approach to validate the timeline and your initial budget assumptions. You can apply both of these techniques to answer “How long is that going to take?” The real project challenge is in predicting the future and being right!

Being able to accurately estimate project work is one of the best tools you can have to answer the”how long” question. To master your project estimation skills–and learn about some methods–download our eBook, “6 Best Practices for Accurate Project Estimates.”


Import Your Work Breakdown Structure Into LP with Zapier

| Comment
Featured LiquidPlanner Productivity Tips

In my previous article, I demonstrated how to take project requirements and integrate them with LiquidPlanner using Zapier, a web-based application integration tool. Leveraging technology to automate administrative tasks is an excellent way to reduce a project manager’s administrative burden. Zapier makes this even easier with LiquidPlanner.

In this article, I demonstrate how project managers can import work breakdown structures into LiquidPlanner using Zapier.

Work Breakdown Structure Tools

There are a lot of different ways to develop a work breakdown structure including sticky notes, outlines, Visio, and scheduling tools. One of my favorite methods for brainstorming scope and developing a work breakdown structure is with mind mapping software. For this exercise, I am using Mindjet MindManager to develop the work breakdown structure. The latest MindManager release has built-in support for Zapier integration!

In this work breakdown structure, I’m developing the scope and task list to develop Grandpa’s Cabinets, a custom display case business. Grandpa’s Cabinets is a small business that develops acrylic display cases for model ship, airplane, and other scale modelers who want to protect their models and display their artwork attractively.

Using MindManager, I created the following work breakdown structure.

For each major section of the website, I defined several key tasks. For the Request a Quote page, I’ll need to do the following:

  1. Develop the Request Form
  2. Email Submission Results
  3. Store the data in the database

Instead of copying all these tasks from MindManager into LiquidPlanner, I will use the Zapier integration feature to send them to LiquidPlanner. Before I can send the zap, I need to configure the integration using the following steps.

Step 1: Login to Zapier and Make a Zap

Login to your Zapier account (http://www.zapier) and click the Make A Zap button. The Choose A Trigger App screen appears and you will need to search for the MindManager application.

Since I’ve configured zaps with MindManager and other applications before, the selection appears in the dashboard automatically.

Step 2: Select MindManager Trigger

With this Zap, there is only one option for the MindManager Trigger. A MindManager topic will be sent to Zapier when it is zapped within the mind map.

Step 3: Connect MindManager to Zapier

Sign in to your MindManager account within the Zapier environment to make the connection. You’ll only need to do this once as each connection is reusable when you create different zaps.

Step 4: Test the MindManager Connection

Clicking Continue will connect your MindManager account with Zapier and pull in a sample topic. The sample topic is used to configure the Zapier to LiquidPlanner integration in further steps.

Step 5: Select the LiquidPlanner App for the Action

The next step is to specify the LiquidPlanner application for the Zapier action. Multiple applications can be triggered from one Zap. If you wanted to integrate with LiquidPlanner and send the same work breakdown topic to a Slack channel, you can add additional actions. For now, just select the LiquidPlanner app to configure the first zap.

Step 6: Specify the Action

Similar to the previous tutorial, you will create a new task in LiquidPlanner with each Zap. You can also create a separate Zap to update existing tasks in LiquidPlanner. I’ve found once the WBS is in LiquidPlanner, you’ll want to manage the work in LiquidPlanner because the scheduling engine provides a useful forecast.

As in the screen shot below, just select Create a Task.

Step 7: Connect Zapier to the LiquidPlanner Account

If you followed my previous tutorial, your LiquidPlanner account will already be connected to Zapier. If you need to connect to a new account or modify the LiquidPlanner account, connect and test the access to the LiquidPlanner in this step.

Step 8: Setup the LiquidPlanner Task

In this step, you will configure the integration between MindManager and LiquidPlanner. For this integration, I keep it simple and map the task name to the node in the mind mapping file. By clicking on the Insert a Field icon on the right, you can select from a variety of mind mapping file attributes.

Step 9: Send a Test Task to LiquidPlanner

The Test this Step process will send a test transaction to LiquidPlanner. Ensure the integration works correctly and check your LiquidPlanner account to see if the sample task was successfully sent.

Step 10: Turn on the Zap

Enable the Zap by clicking on the toggle icon.

Step 11: Zap Your Mind Map

In Mindjet MindManager, select Advanced – Zapier and confirm the account is connected to Zapier. Then select multiple nodes in the map, right click and select Send Topics To, and select the Zapier option.

With a couple of clicks, you’ve sent the WBS package to LiquidPlanner for further schedule development.

Step 12: Build the Schedule in LiquidPlanner

Go into LiquidPlanner and check the Inbox. You will see all the nodes that were sent from the mind map in your LiquidPlanner account.

MindManager + LiquidPlanner + Zapier = Easy Scheduling

Combining a mind mapping tool like Mindjet MindManager with LiquidPlanner makes it easier to schedule tasks and build an overall project schedule. Defining work often results from a brainstorming session as teams figure out their project scope and assign action items.

A mind map is an excellent tool to gather requirements, organize scope, and communicate with visual thinking.

By integrating the tasks with LiquidPlanner, the project manager saves time and the team can start collaborating on tasks easier. Compared to traditional single person desktop tools, this solution enables team to work faster without a ton of administrative overhead.

As web-based management tools continue to grow, project managers can leverage Zapier and LiquidPlanner for more project management automation.

New to LiquidPlanner? Start your free 14-day trial today!


Zapier Integration: How to Go from Requirements to Project Schedule in a Zap

| Comment
Featured LiquidPlanner Tips

As a project manager, how often have you experienced these scenarios:

  1. You just walked out of a requirement gathering session and have an Excel list of new project requirements that need to be organized into a schedule
  2. Your team has developed a user story backlog in JIRA but you need to represent the sprints and key dependencies in a project timeline
  3. You realize several key meeting minutes are actually project tasks that need to be incorporated into the project schedule

All of these scenarios happen daily to project managers. Project managers also use a variety of tools to develop scope, gather requirements, track action items, and organize for delivery. When these individual items need to be organized into a project schedule, the project manager has to synthesize the requirements, organize the actions and to-do list, and reformat them into a project schedule.

All of this increases the project manager’s administrative burden which is counter-productive to leading the team and driving for delivery.

Fortunately, LiquidPlanner can help reduce this burden with its nifty Zapier integration.

What is Zapier?

Zapier is web-based application integration and automation solution that allows online applications to interact with each other. There are hundreds of automations and integrations available on the Zapier.com platform. A quick review of the prebuilt connections (also called Zaps) are available for LiquidPlanner, JIRA, Trello, Salesforce, Google Docs, and Gmail.

What is a Zap?

A Zap is an integration between two applications. A zap is configured within a few minutes by configuring a trigger and an action between two applications. Creating a Zap uses a simple process where you define a trigger in one application and then an action in the receiving application.

In the scenarios above, I configured Google Sheets to send a new task to LiquidPlanner for new requirements and user stories. It is very easy to configure the Zap integration as the Zap editor walks you through triggers and actions across both applications. Zaps can be customized to work on specific data filters and default specific values in the Zap action. Below are a few Zaps I created to address the aforementioned project management scenarios.

In the tutorial below, I’ll show you how to send requirements in Google Sheets to LiquidPlanner. By following the simple configuration process, you’ll be building integration between your favorite web-based applications quickly.

Google Sheets to LiquidPlanner Zapier Integration

Step 1. Choose a Trigger App

The first step is to choose the source or “trigger” application. Zapier has hundreds of applications to choose from and the platform continues to grow. Because we’re integrating Google Sheets, search for Google Sheets in the Choose a Trigger App search box.

Once you configure an application, it is always available to you in the dashboard.

Step 2. Specify the Trigger

The next step is to select the specific trigger within Google Sheets that initiates the event. In this example, I want to send any new rows or updated rows in Google Sheets to LiquidPlanner.

Step 3. Connect Google Sheets to Zapier

You will need to sign into your Google account within the Zapier environment to make the connection. Once you sign in, the account will be reuses for any new Zap you create.

Step 4. Setup Google Sheets Options

Once the account is connected, you need to specify the Google Sheets options. In this Zap, I include the Google spreadsheet name, the specific sheet, and any column options. In this Zap, the Google spreadsheet only has one sheet called “Scope”.

Step 5. Test Google Sheets Connection

Zapier will test the Google Sheets connection as it attempts to retrieve a row based on the criteria specified in Step 4.

Step 6. Select an application for the Action

The next step is to specify the target application for the Zapier action. Now that Google Sheets is configured as the source, the next step is to select LiquidPlanner as the target application for the action.

Step 7. Specify the Action

With each target applications, there are many different actions that can be taken within the selected application. LiquidPlanner provides many different actions including creating tasks, updating tasks or adding comments. Zapier maintains a list of common target actions and less common actions depending on your integration needs.

Step 8. Connect Zapier to the LiquidPlanner Account

Once the target application is defined, you need to connect the application to your LiquidPlanner account similar to Step 3 when you connected Google Sheets.

Step 9. Setup the LiquidPlanner Task

Once the account is authenticated, LiquidPlanner needs to be mapped to the data coming from Google Sheets. If Task A was the sample task in Google Sheets, it will appear in the LiquidPlanner mapping. In this example, I sent Task A with an low estimate of 4 hours and a high estimate of 8 hours. These are just a few of the basic fields that can be configured. Depending on the business needs, different mappings can be created based on the trigger.

Step 10. Send a Test Task to LiquidPlanner

Once the integration is configured, send a test task to LiquidPlanner. Once the integration is a success, you’re just a few clicks away from enabling the Zap.

Step 11. Turn on the Zap

Once the Zap is confirmed to work, enable the Zap and it will run every 15 minutes integrating Google Sheets with LiquidPlanner.

Step 12. Add tasks to Google Sheets

Go ahead and open the connected spreadsheet in Google Sheets and add some tasks.

In this example, I documented several user stories and tasks needed to launch a small website.

Step 13. Wait 15 minutes or run the Zap from the dashboard

If you want immediate gratification, go ahead and run the Zap from your Zapier dashboard.

Otherwise, you can continue to update the sheet and go to lunch. When you get back, the tasks will be submitted to LiquidPlanner.

Step 14. Continue Planning in LiquidPlanner

Once the tasks are in LiquidPlanner, you can plan the tasks as you normally would in LiquidPlanner. The tasks show up in the Inbox much like the tasks you email into LiquidPlanner.

Go ahead and re-assign the appropriate resources, make any estimation tweaks and recalculate the Gantt chart.

It may seem like 14 steps is a lot to configure the integration but it is very quick and easy to setup the two applications.

Benefits

As more companies adopt web-enabled project management tools, the role of “middleware” connecting robust applications will only continue to grow. The Zapier integration helps the project manager save time, reduce the administrative burden, and share project data across project management and collaboration tools. It’s actually “fun” to use. Well, as much “fun” as a project manager can have on a project.

More LiquidPlanner Zaps

There are many different Zap configuration available for LiquidPlanner. If your team is using JIRA to build a product backlog but needs a meaningful Gantt Chart, the LiquidPlanner Zapier integration will build a useful project timeline.

If you are managing operations using the Kanban board in Trello, a Zapier integration will update the task status within LiquidPlanner. Agile and Kanban approaches are excellent ways to build software yet stakeholders still want to know when their specific feature will be delivered. Integrating with LiquidPlanner will help answer the timeline question as well as enable to team to remain Agile.

For a complete list of ways to automate LiquidPlanner in Zapier, check out https://zapier.com/apps/liquid-planner/integrations. In a future tutorial, I’ll show you how to convert a work breakdown structure into LiquidPlanner with an on-demand Zap.


Using Agile Practices to Improve Business Customer Relationships

| Comment
Featured Methodology Project Management Teams

The relationship between IT and Business teams has rarely been heralded as a model for organizations to follow. The relationship is typically strained with IT being too slow to respond, expecting business teams to “define ALL of their requirements upfront” and long lead times before a product can even launch.

Business teams struggled with understanding their role in a software project while trying to sort through all the technical jargon used to build a website. Add external consultants promising to do the job faster in an environment they don’t control and internal security and PMOs adding their processes, it isn’t a wonder the Business-IT relationship is challenged.

Related: Adopting Agile is an Exercise in Change Management

Given these challenges, how does applying Agile practices improve the relationship? IT and business teams speak entirely different languages and the recommendation is to introduce terms like scrum, product owner, sprints, backlog, user stories and story points?

Yep.

Adopting Agile practices introduces new terms and new ways to work as a team. As a result, the relationship is improved and trust is developed through frequent and demonstrable results. Below are two examples from past projects.

Example #1 : Failing to Deliver

The global marketing team had spent the past 18 months working with product, engineering and supply chain teams to develop a “best in class” website for online ordering, integration with ERP systems and marketing and sales functions. The project followed a waterfall methodology with 25-page documents describing each major feature and required scope.

The project scope continued to grow and the 18-month project became a 24-month project riddled with software defects. In order to make the mandated launch date, the team cut scope and launched a solution that only met the online ordering need.

Related: Agile Team Transitions are Not Always Textbook

Even though the project was outsourced to a 3rd party vendor, the business teams blamed IT for failing to deliver. Marketing was frustrated that none of the customer relationship management or marketing features were included in the launch. IT leadership changed and the software vendor ramped down their outsourced army of developers. The business was left with half developed features that no one really wanted.

Second Chance

With the following year’s budget cycle, additional funding was provided and a new business and IT team applied an Agile approach to add new features to meet marketing’s needs. The team included the business acting as a product owner, internal IT managing the project and a 3rd party development team who had expertise in Agile delivery. It took several sprints to establish a rhythm but the Agile process provided the transparency, demonstrated working software and provided flexibility for the business to change requirements.

Previously, the business team defended their position that they “provided all the requirements 9 months ago” and were quick to criticize. Using the Agile processes with a 2-week sprint, the business shifted to being more collaborative as their requirements evolved and changes were implemented. The key differentiators that improved the relationship included:

  1. Transparency – All team members understood the work in progress and each product’s status
  2. Metrics – Adopting user stories allowed the team to track individual features across sprints and software releases
  3. Demonstrate working software – The team saw working software every two weeks instead of 25-page documents promising features in the future
  4. Embracing change – The team had the flexibility to re-prioritize the work and the product owner knew they could get what they want in 2-week chunks

The end result was a successful project delivering features the business wanted while improving the trust and collaboration between the two teams.

Example #2: Struggling Software Project

This example occurred in a different company, yet shared the familiar story of a complex struggling software project. Project teams attempted rolling planning every quarter only to have the launch date continue to move with each quarter.

Teams tried the Big Design Up Front approach with management expecting the teams should know all the requirements after spending the past 12 months in analysis.

The core application team struggled with delivery as half the team worked off-shore and only had six overlapping hours of collaboration. The application team had a project schedule yet the project manager and the development team were not aligned on task status. The business was also frustrated and doubted the team’s competency and ability to deliver.   

Adding Agile

 A new project consultant joined the team and reintroduced the good Agile practices with a daily standup, prioritizing the product backlog and implementing in 2-week sprints. The project team collaboration with developers and the business improved due to: 

  1. Reviewing the sprint board in the daily stand up
  2. Holding team members accountable to their user stories in the sprint and in the daily stand up
  3. Providing transparency, accountability and communication to the team
  4. Confidence in the team increased by sharing burn down charts and demonstrating working software at the end of each sprint.

The end result was the project improved through the daily and bi-weekly feedback loops. Working with an offshore team presents time and communication challenges, but the Agile process improved the way the team worked to deliver the release.

The project manager still tracked the major features, sprints and releases in a project schedule, but the Agile process helped improve the team communication. Previously, the business had no visibility into the team’s progress and with Agile, the business had more transparency into the day to day activities.

Remember Agile Isn’t a Cure-All

Keep in mind incorporating Agile practices with your business partner and a delivery organization isn’t a magic cure-all or a silver bullet for project challenges. In the example above, the marketing customer was pleased with the result.

However, the executive marketing stakeholder was frustrated the team didn’t deliver everything. I was on a phone call when the leadership team expected a large feature to be delivered and it was the first time I had heard about it.

Related: 7 Ways to Sell Agile Project Management

Agile won’t fix stakeholder management and properly managing expectations. You still need to ensure stakeholders at the project, management and executive level are all aligned on the product direction. If you start adopting more frequent feedback and demonstrating frequent delivery, the business relationships will improve!


A Cheat Sheet for Project Manager Knowledge Transfers

| Comment
Advice Featured Project Management Tips

Project methodologies often have a template to initiate a project or checklists to ensure a project is ready to pass a tollgate or a formal project milestone. If you look at your company’s own methodology, you will likely find a lot of templates for your project.

Despite all these templates, few methodologies have a checklist for project turnover. Project turnover should be minimized, but project manager changes are a reality.

I’ve seen project managers get promoted, moved to different projects, quit or simply be replaced. When I was a business analyst working on a strategic HR systems project, the director replaced the project manager three times! If you find yourself having to transition a project or inheriting a new project, I found it helpful to have a PM Knowledge Transfer cheat sheet.

The cheat sheet is grouped into several areas:

1. Project Overview 7. Project Financials
2. Project Stakeholders 8. Project Quality
3. Project Scope 9. Project Log
4. Project Team 10. Project Document Management
5. Project Governance 11. Vendor Management
6. Project Schedule 12. Advice

1. Project Overview

This section speaks for itself, however, if you have a project charter, be sure to review it. Many organizations lack a quality charter but the key is to review the purpose of the project, high level goals and expected benefits. By providing the “big picture” view, it helps to provide context. Without this context, the incoming project manager will have to stumble through the same points you did when you started the project. Why not make it easy on the new guy?

Get a PDF version of this cheat sheet here.

2. Project Stakeholders

Every project has stakeholders ranging from the Big Boss (i.e. sponsor) to the Little Guy (individual team members). Identify any key stakeholders, their influence and expectations on the project. Who are the stakeholders who will help remove roadblocks? Who has influence over the project outcome? Who is just a pain in the @#$?

Related: How to Build Strong Relationships with Stakeholders

3. Project Scope

What is the project actually delivering? What deliverables have been explicitly called out of scope? What deliverables might be creeping back into the project? What are the project constraints (budget, time, mandatory deliverables)? Are there any assumptions or dependencies to be aware of?

If the project is in execution, scope has likely changed from the original scope statement or original agreement. I’ve inherited plenty of projects where I reviewed the original scope and the team explained how scope changed. I’ve always found a context diagram to be a useful tool to convey all the people, vendors, and organizations involved with the project.

4. Project Team

Every project has its own unique cast of characters, politics and social dynamics. Understanding the personalities, strengths, challenges and idiosyncrasies with each team member will help the new project manager significantly. Be sure to identify the key team members that the project manager can count on as well as any team members who need that extra helping hand.

5. Project Governance

How is the project being managed? What is the sequence of meetings throughout the week that collect status, communicate status, track issues and report schedule progress? How often does the project communicate with mid-level management, senior management and / or the executive leadership team? Are there any formal milestones, gate review or PMO expectations for the project? This checklist item includes reviewing the communication plan but it also includes all the governance processes to ensure the project is executing correctly.

Related: Project Governance for Distributed Teams

6. Project Schedule

Hopefully, the project schedule is up to date and it reflects current progress to date and any new forecasted end dates. If you haven’t updated the schedule in a while, remember to update it and walk through the schedule with the incoming project manager. Identify the sections of the schedule that are still developing based on changing scope or priorities.

7. Project Financials

Review all the actuals to date and cost forecasts as well as any outstanding invoices from vendors. Ensure there is a clean financial hand off to the incoming project manager. If the new PM doesn’t have a clean financial view, the person will waste a lot of time chasing down unpaid invoices and working with Finance and Accounting to clarify past costs.

8. Project Quality

In software projects, project quality often refers to software testing and defect management. In manufacturing projects, it is also important to review any outstanding manufacturing defects or unacceptable variances. It is important to understand how quality is being tracked within the project so requirements are implemented and verified throughout the process.

9. Project Log

The project log is another source for current and past challenges within the project. If there are open issues, risks, change requests or outstanding action items, ensure the project log is kept up to date. Project managers can become easily engulfed in project execution that some of these administrative tasks can get lost. If the project manager has the project log review built into the project governance and status reporting processes, the administration is handled weekly.

10. Project Document Management

Where are all the project documents stored? If there are documents on your laptop, ensure they are stored in a central location such as a file server, DropBox, Google Drive or any shared document collaboration repository. Hopefully, the project has good document management otherwise it is another administrative challenge to figure out who has the latest copy of the project schedule, status report or requirements document.

11. Vendor Management

Review the key vendor contacts and any statements of work. If the contract has specific service level agreements, review the steps to ensure the vendor is performing according to the service level agreement. More importantly, discuss the quality of the vendor relationship, personalities and any nuances that influence the vendor relationship.

12. Advice

The previous 11 sections all provide a framework to convey project knowledge, however this section is useful to identify any parting words of advice or any hidden pitfalls the new PM might encounter. If appropriate, provide the current project manager’s forwarding contact information. In the past, I’ve had to reach out to the former project manager to answer new questions about old problems.

If the PM is staying within the organization, this is easy to do. If the PM is leaving the organization, it may be harder to get the contact information. But, I haven’t seen anyone turn down a LinkedIn request if the transition is a positive one.

What if the project manager isn’t there to transition?

Working with a transitioning project manager is actually a luxury versus a guarantee. I’ve inherited several projects where the “project manager” had very little documentation and even fewer project management artifacts.

If you find yourself in this situation, use this cheat sheet as a guide to ask all the probing questions to make you a success on the project.

Even if you’re not transitioning your project, you can use this cheat sheet to confirm you have all the key project management processes up and running within your project. Download a PDF version of cheat sheet here.


Three Intrinsic Rewards that Drive Employee Engagement

| Comment
Advice Careers Featured Teams

Joe has a team.

Joe’s team works long hours writing code and meeting ridiculous deadlines.

Joe’s team is already well-paid with above market salaries and profit-sharing programs.

How should Joe reward his team?

Given the compensation structure, does Joe even need to reward his team? After all, isn’t the money the reward? The team is paid to do a job.

Rewarding team members is an age old topic that continues to be a management challenge to retain talent, ensure employees are engaged, and maintain job satisfaction. Regardless if your team is an Agile team or delivering in a traditional waterfall environment, effective managers need to reward, motivate, and sustain high-performing teams.

Don’t Just Show Me The Money

If you conducted a compensation survey, I’m sure everyone surveyed would say they’d want more money. Who wouldn’t? However, studies have shown that money is not an long-lasting way to reward employees.

Dr. Frederick Herzberg conducted a study that revealed intrinsic factors (i.e. motivators) lead to employee satisfaction and extrinsic job factors led to job dissatisfaction. Herzberg’s dual-factor theory indicated if you’re not compensated fairly, you will have job dissatisfaction. If you are compensated competitively, then true job satisfaction comes from intrinsic factors.

Although money may be an extrinsic reward, it doesn’t sustain long-term satisfaction. Just think about your last raise or bonus. You were likely happy to receive that fat check (minus the substantial chunk for Uncle Sam), however, a week after, how happy were you with your job? It is likely the same as before you received the bonus. Based on Herzberg’s study, it is better to focus on intrinsic motivators to reward teams.

Intrinsic Ways to Reward Your Team

Recognize achievement.

One memory that stays with me was when I was recognized for earning my doctorate degree. My boss ordered a cake and sent out a note to the entire department to recognize my academic achievement. It was a small gesture, but I sincerely appreciated the thought. That small recognition of four years of academic work helped build stronger trust and dedication to the organization.

[Further Reading: 5 Ways to Create a Positive Work Environment]

Another simple way to say thank you and publicly recognize the team is to start a Kudo’s program. Using business card size pieces of paper, employees can say thank you to another employee. Each month, the company summarizes the kudo’s feedback and displays each note electronically on a screen. Instead of physical thank you cards, the same system can be implemented using a simple email to a central “Kudo” program coordinator.

Both examples reward an employee’s achievement or contribution to the team. Publicly recognizing someone with a “Thank You” is also a nice way to reinforce positive behaviors. Remember it doesn’t have to be a formal program. Stopping someone in the hallway and saying “Thank You” goes a long way to provide positive reinforcement and costs you nothing!

Provide opportunities for more responsibility, growth, and advancement.

Rewarding individuals and teams with more responsibility helps to contribute to individual growth and advancement in the organization. Have you ever had an employee identify a process improvement or suggest a new way to do something? One option is to take the idea and implement it. The better approach is to support the employee to implement the idea and then recognize the employee for the effort and contribution.

Team members also need to be given opportunities to grow in their role. Project managers typically submit a weekly status report and during a portfolio review, the senior leader will speak to the portfolio’s overall status. Instead of having the director represent the activities in the portfolio, encourage the project manager to attend the meeting and speak to the project status in the organization.

[Further Reading: 11 Ways to Build the Strengths of Your Team]

As new promotional opportunities arise in the organization, encourage qualified team members to apply to the position. Even if the employee doesn’t get selected for the position, the experience interviewing for the position will help prepare the team member for future positions. Managers can be reluctant to encourage their top performer to apply for a promotional assignment, however, good managers can also find and build good talent to continue the work. If you don’t provide employees with these opportunities, you’re likely to lose the talented employees to other firms who will recognize their talent and value.

Ensure the work is rewarding.

How often do you wonder, does the work I do matter?

It may not seem like a reward, but ensuring the work is rewarding will help motivate the team and drive for results. If the team doesn’t understand how their contributions improve the organization or have affect the organization, it becomes difficult to sustain a high performing team.

A balanced scorecard is a performance management tool that identifies how enterprise goals align directly to individual employee’s goals and objectives. A balanced scorecard will help provide visibility to how individual contributions affect the enterprise organization, however, if the work itself isn’t rewarding, the balanced scorecard just shows you’re got unrewarding work aligned to enterprise goals.

The reality is no job is always rewarding 100% of the time. If it was, they’d call it a hobby. One approach to ensuring the work is rewarding is by letting the team determine the priority of things to work on. In an Agile team, there is a concept of a 6×2+1 development cycle. For 6 iterations the team works in 2 week sprints for 6 weeks and then takes 1 sprint to focus on training, attend a conference or work on technical improvement versus the slew of new enhancement requests. By giving prioritization to the team, it ensures the team gets to work on the items that are important and rewarding to them.

Just try one of these intrinsic motivators and you’ll see an improvement from the team!

Other Fun Ways to Reward Your Team

The intrinsic ways to reward and motivate teams are useful but don’t be afraid to to include a few extrinsic activities. Here are a few idea to consider:

1. After a major launch or milestone, celebrate with the team! After every major system launch I took the entire team out for an excellent dinner at one of the higher end restaurants. I was just glad the $1,200 dinner bill could be expensed to the corporate account.

2. Host a team lunch. The team lunch is an easy way to get the team together to talk about anything but work. I like the idea of encouraging “No Shop” talk at lunch so team members can learn more about one another. Everyone has to eat sometime in the day and if the boss is buying at a good restaurant, who wouldn’t attend?

3. Host a team movie event during the day. One of my colleagues took his entire team out to see the latest Star Wars movie during the day as a reward to the team. At $10 a ticket for a matinee show and a couple of pizzas, it was an inexpensive way to recognize the team. (I’m suddenly recognizing a trend in my extrinsic “food factor” motivation.

4. Let the team go home early for half of the day. Believe it or not, team members don’t always want to socialize with their team since they work 8-10 hours a day with them. By letting the team go home early rather than attending a dinner or a corporate “team building” function, each individual can prioritize the extra free time.

Finding creative ways to reward teams outside of the obvious financial reward remains a management challenge. Companies can do better by publicly recognizing individuals in front of the team, posting a blog post on the corporate intranet or simply sending an email thanking the team or the individual. Recognizing a team and ensuring the others in the organization know about it is a far better reward than just the financial ones.

…although I’m still a fan of the “food factor” approach.


Adopting Agile is an Exercise in Change Management

| Comment
Careers Featured Methodology Project Management Teams

If you’re fresh out of Certified Scrum Master training, you are likely invigorated to start applying the Agile and SCRUM based techniques to your next project. Based on the classroom exercises, you’re excited to try new concepts and apply the magic cure-all that will solve all waterfall-based project problems. After all, your two-day training class and one online test later makes you a certified Scrum Master!

(Well, that’s the way I felt when I left class.)

Then you get back to work and the real world hits you—implementing Agile isn’t going to be as easy as you thought. After a few discussions explaining Agile and working with teams to adopt Agile practices, you realize:

1. The business customer has no desire to write the user story.

They gave you the requirements months ago in a business requirements document. The development team should know what needs to be done, so just call the customer when it’s ready.

2. Everyone is already Agile, and they don’t need a formal process like stand-ups, backlog grooming, sprint reviews or retrospectives

Everyone is using Agile as the buzzword to hide their lack of processes and continue to implement in a waterfall manner just in two week chunks.

3. The teams follow sprints but extend the sprint end date to accommodate just one more feature.

Sprint start and finish dates adjust based on the product owner’s need to add one more feature into the sprint. The number of committed stories grows mid-sprint and impacts other planned work. The team also extends the sprint because of defects that require more time to finish the work.

4. The team doesn’t see the value in story points because they are too abstract.

The team tried to do story points but didn’t see the value in it because they couldn’t equate it to a unit of time. Hours worked just fine for them so they didn’t see a need to change.

Do any of these experiences sound familiar?

Adopting Agile is an Exercise in Change Management

Adopting agile is an exercise in change management for a number of reasons:

  1. Software isn’t an order by number model.
  2. Existing project teams have good practices.
  3. Agile techniques can threaten team members’ roles, contributions, and control within a project.
  4. Agile affects both the business partners, the IT organization, and any 3rd party vendor engaged in the project.

Working with project teams to adopt Agile practices requires awareness, training, and organizational change management. If you walk into your organization fresh from a CSM class, you likely find yourself hitting change management roadblocks. I could refer to Lewin’s organizational change model or Kotter’s 8 step change management model, but I think these words are better spent identifying the tactical steps you can take to implement Agile in your organization.

8 Practical Steps to Implement Agile Techniques in an Organization

1. Develop an Agile overview for business and development teams.

Yep. You’re going to create a presentation.

You’re fresh from CSM training, so the course materials will provide plenty of reference material to describe how Agile techniques with SCRUM practices can be implemented. Once the presentation is developed, share the ideas with the senior leaders in your organization, as well as the management level thought leaders. Generate an interest in trying something different.

I developed two presentations for my organization: Agile 101 and A Day In the Life of an Agile Team. One presentation provide an executive level overview of Agile techniques and the other provided a detail walkthrough with product backlogs, sprint plans, user stories, and burndown charts. I presented at a few executive leadership meetings and started to socialize the concepts with other directors and managers. Some managers took interest and others preferred to continue working their own way.

Slowly, the team started to engage and ask if I had any ideas on how Agile can help their project.

2. Get buy-in to try something different for two weeks.

Ask the team to operate differently for 2 weeks. Introduce the SCRUM concepts and sprint ceremonies and get buy-in to try another way of working. If the team dislikes this new way of working, there will be opportunities to improve upon it and change it. 

3. Facilitate breaking down one large business requirements into a backlog of user stories.

BRD typically have an inventory of requirements. Ask for an important feature in the BRD and break it into user stories. Organize the most important stories or features into the first sprint and size them appropriately for a 2-week sprint. With Agile, you want to show how stories can be delivered in slices by thinking small and delivering frequently.

4. Don’t worry about story points.

Story point estimation always seems to confuse new teams learning about Agile. As a guideline, split the user stories into 3-day durations and simply rank them in order of complexity.

This gives enough flexibility to get started with a sprint without worrying about T-shirt sizes, Fibonacci sequences, or abstract estimation.

5. Execute the sprint using the daily stand-up, demonstration, and retrospectives.

Set the expectation that each team member move’s their card across the sprint board from To-Do, Doing, and Done. As teams get more experienced with SCRUM and Kanban, they can add other columns based on their development process.

At the end of the sprint, count all the completed cards, demonstrate the functionality delivered and conduct the retrospective. Compare the number of planned cards at the beginning of the sprint to the number of completed cards. Inquire about what could have been done differently to meet the original commitment.

6. Use the feedback and determine if the team wants to repeat the process again.

If the team sees success with Agile, they are likely to repeat it and gain the benefits. Within two weeks, you won’t deliver a major software release but you will get faster feedback on what’s working within the team as well as feedback from the business on the development.

The roles within the team can change gradually. Don’t walk in ready to throw out the project manager because SCRUM says there are only the Scrum Master, Product Owner, and Team roles. Use the feedback loop to improve the team’s delivery.

7. Hire a consulting team that delivers projects with Agile expertise.

I didn’t learn all this practical knowledge from being “book Agile”. Sure I read a lot of books on the topic but my real learning came when my company hired a development company to work on a new software launch. They delivered everything using a SCRUM framework with Agile techniques.

The team was comprised of the consulting company and the internal development team. The consulting company led the Agile practices and delivered the project. However, our development team worked alongside them and participated in the sprints. Consequently, the internal development team walks away with a better understanding of Agile practices and were able to repeat them on their own.

It is difficult hiring a consulting company to simply train. It is much easier if they can deliver a project and the internal team can learn by doing over months rather than a few weeks of a consulting engagement.

8. Take one Agile team and split into two.

Once you have one team working well with Agile, look for opportunities to split the team into two teams and partner them with new team members looking to implement Agile practices. One team becomes two, two becomes four, and four becomes eight fully functioning Agile teams. By spreading skilled Agile resources across the organizations, each team learns how to adopt Agile practices as well as provide new learning opportunities for each team member.

Change Isn’t Easy

Training classes provide a safe and simulated learning environment. The real challenge is applying the organizational change management to make Agile work in a real-world environment. Challenging and trying to change a team’s process can threaten a team and be met with resistance, despite the intention or benefit. By applying these eight steps and managing through the challenges identified earlier, you’ll have better success implementing Agile within your organization.