Viewing Posts by Christian Bisson
by Christian Bisson, PMP
A scrum master is an essential part of an agile team. However, it seems their role is often underestimated or misunderstood. In this article I’m hoping I can shed some light on the value they bring.
How People See Them
Here’s what I’ve heard over time:
Elves of happiness
Since scrum masters want teams to perform well, they want to make sure team members are happy. That sometimes makes others think that all scrum masters are trying to do is to make everyone happy without an actual purpose behind it.
Since scrum masters often talk to the team and gather information about the status of a project, they are often mistaken for coordinators—people tasked with giving a status report to the product owner or taking notes during meetings.
Some people simply have no clue what scrum masters do, thinking they are an overhead that could be removed without any impact because they don’t actually “produce” anything.
What They Actually Do
Help teams grow
One of the scrum master’s main tasks is to educate the team with agile principles, but also to help the team become self-sufficient. In a way, their main duty is to actually become useless as the team becomes more mature.
Scrum masters can do so by sharing agile knowledge and by coaching teams as they go through retrospectives where the team is motivated to talk about how they can improve.
There are so many different roadblocks that can reduce a team’s efficiency—whether it’s poorly defined requirements, inefficient meetings, lack of documentation or communication, or conflicts. A scrum master can help tackle anything that might slow down the team.
Keep the focus on the right place
Not being hands-on in projects allows scrum masters to have a different point of view that allows them to re-focus teams when needed. Whether it’s toward the developers and their commitment to the sprint, or product owners and their focus on a product’s vision, scrum masters make sure to remind everyone where their effort should go.
It can be hard to quantify a scrum master’s usefulness since they do not actually produce deliverables. But having experienced an agile project both with and without a scrum master, I can vouch for their role. They bring so much on a day-to-day basis to the teams they work with, which in turn brings quality products to clients.
Have you experienced working with scrum masters? What do you think is most important about their roles?
by Christian Bisson, PMP
Documentation—at least on IT projects—is one of those great project challenges. Documenting everything (and then keeping it updated) can be tedious, and requires a lot of time and discipline. But documenting nothing can leave people lost as a project evolves.
Like many things in life, balance is everything. Documentation doesn’t need to be a pain. It just needs to be relevant, easy to find and reliable.
Documents can easily (and quickly) become obsolete, therefore it’s important to limit documentation to the information that can help the team save time and avoid errors. Stick to the most important elements, such as project scope, important links, FAQs, key decisions, approvals, etc.
Easy to Find
If information is scattered between emails, a server, a computer and a filing cabinet, chances are team members will skip looking for it and simply ask around (most likely starting with the project manager) to find what they’re looking for.
There are several software options out there today that are great for storing and organizing documentation, like Google Drive or Confluence (part of the Atlassian suite). Each allows you to consolidate documentation in one spot and provides access to simultaneous editing and commentating features.
If you follow the first two tips, you should only have to maintain a limited amount of information in one easy-to-find location. This is essential because documentation that is not updated can have negative consequences on your project. It can mislead team members and accidentally force them into working off of outdated information.
Where do you store your important project documents? How do you ensure they are relevant and reliable? Share below!
by Christian Bisson, PMP
All team members must make—and meet—commitments to keep a project on track. However, it’s the project manager’s job to foster the conditions that will allow the team to deliver on its commitments.
Here are three tips to help you protect team members’ time — and ensure they’ll have the bandwidth to keep their promises.
It can be tempting to ignore team members when they warn that there’s too much work to be done in a given amount of time. You may think they should simply push through. But if the project manager doesn’t commit to realistic deliverables—and find backup when necessary—problems just compound.
Take agile teams. It they commit to more work in a sprint than they feel they can complete, it will only make matters worse when unfinished work passes on to the next sprint. But if they commit to less work and get it all done, you might be surprised to find additional work added to the sprint, since the team is performing better than planned.
A team can easily lose time trying to get up to speed. As a project manager, you can reduce confusion and delays by reviewing requirements and answering questions at the outset.
For example, if you’re working on a project with wireframes or designs, you may ask a team member to complete a simple task, like display the product page.
The team member that commits to this could then deliver half of what you expected simply because he or she didn’t have the full picture. Perhaps he or she thought only the desktop version of the page was needed and didn’t bother with the responsive design as you had expected. If you review instructions before work starts, you’ll have the opportunity to catch these types of discrepancies.
If team members are constantly interrupted, their efficiency drops. You can help them focus in a few different ways:
By Christian Bisson, PMP
A deadline is the project objective defined in terms of time. But on some projects (a lot of them, unfortunately) the delivery date is not necessarily realistic.
When projects get delayed, the obvious solution is to push back the deadline. But it’s not so simple for every project.
Here are a few factors to weigh before deciding how to move forward when facing project setbacks:
The Client Relationship
Assuming the agency runs client-facing projects, not internal products, this is typically the most important reason to deliver a project on time. Happy clients bring in more projects—and other clients by word of mouth.
Determining whether or not your client will react negatively to a project delay may depend on the cause of the holdup. Is the delay related to client actions, such as adding new requirements or delivering assets late? Or is it due to internal errors, such as poor estimating or planning?
Keeping clients happy also presents a sort of balancing act for many agencies. You have to keep clients happy because they bring in the money that runs the agency. But, on the other hand, you don’t want your team members so bogged down with additional requests and revisions that they become tired or frustrated to the point they will leave.
Projects often have what we call hard deadlines, meaning the date cannot be changed under any circumstances. For example, in e-commerce, there are projects tied to holiday sales and, obviously, those dates cannot move. Missing those opportunities can have a drastic impact on sales. In these cases, it might actually be more cost-efficient to invest in more resources to speed up the project and have it ready on time.
The Big Picture
Delaying a project can have a direct impact on other projects, as well. Team members may be scheduled to move to another project once the first is completed, for example, so delaying that transition date can have a chain reaction on an agency’s planning. Talk to someone with a wide-angle view of the organization’s portfolio to better understand these potential implications.
There’s no magic solution for dealing with a delayed project. All you can do is balance the pros and cons and make a judgment call.
What factors do you typically weigh when deciding whether or not to push back the deadline on a delayed project? What advice do you have for other project managers facing a delay?
by Christian Bisson, PMP
When a new person joins the team, there’s always a bit of a learning curve. But when teams fail to prepare new members, it takes even longer for them to provide efficiencies and improve performance.
Here are three training tips to help new recruits hit the ground running:
1. Don’t Put Trainees In Control
Being available to answer questions isn’t a sufficient way to train new team members.
While knowledge is transferred when you answer a question, new recruits can only ask about issues they’re aware of. This means they’ll often make mistakes that could have been avoided.
Rather than let team members learn things the hard way, share important information before questions are asked—and remember that details matter. For example, project briefs are done differently everywhere, and it’s not always clear who should be included if no one has been specified. A new team member might not think to ask if he or she has sent briefs a specific way at previous jobs.
2. Create an Onboarding Plan
Don’t make new team members chase people down to discuss processes or protocols.
I once joined a team where I was told to set up meetings with a dozen different colleagues so they could explain how they work. I didn’t really know how the conversations would turn out, but I expected the others would be prepared to meet with me.
The result was a bit surprising. The list of people I was supposed to meet with was outdated—several were no longer with the company—and those who were still around expected me to lead the meeting since I had set it up (which made sense). So they didn’t quite know what to say.
This experience was an eye opener. To make new members feel welcome, teams should plan onboarding discussions in advance and have information ready to share.
3. Take a Phased Approach
More often than not, generic training sessions bore and demotivate people, wasting everyone’s time.
Instead, training should be relevant to a person’s role and immediate needs. For example, not everything that a new team member should know will be relevant on day one. If you give them information they’ll need a few months down the road during onboarding, chances are they’ll have forgotten everything when that time comes.
Training and knowledge sharing should be done gradually. The gaming world offers a useful example. Many games have ongoing tutorials where bits of information are shared throughout gameplay, requiring the player to practice a new skill right before it’s needed. This approach maximizes the learning experience and keeps training from becoming tedious. It makes lessons easier to absorb and more likely to be remembered.
Training is often thought of a secondary need for new team members, being conducted as time allows—which might be never. How do you make time for training on your team? What type of knowledge transfer do you prioritize?