Voices on Project Management

By Soma Bhattacharya

Sometimes I read an article where someone mentions that “agile is dead,” or that it doesn’t work anymore. I have to pause and think where this comes from. Honestly, I don’t know. What I do know is that agile never said it would work for everyone.

Most teams and organizations working in agile either step into it by accident or want to try the “trend” to figure out it works for them, then continue working with it. I reached out to my friends who are certified trainers in agile, and they mentioned that they are busier than ever. That world has opened up because trainings are now online, which means you don’t have to travel anymore to take classes or get certified. In addition, the 15^th Annual State of Agile Report notes a growth in agile adoption from 37% in 2020 to 86% in 2021. So it looks like agile is still very much alive.

Certification or not, agile is always the most natural way of working. At least, that’s what I think. Why?

1. You work in tight-knit teams, keep distractions limited and get the work done.
2. You are transparent in your communication because the team is small and a safe place for anyone to open up.
3. You plan but always adapt and adjust the work because you are flexible.
4. You demonstrate the work, and the feedback is used to course correct

So, what’s not to like about it? Not everyone agrees; in reality, things can seem more challenging for some.

Here’s why teams don’t want to go agile:

1. Lack of empowerment and support of teams: Decisions made by teams are later turned down by managers. I have been in situations where someone from the team pulled me aside and said, “All that planning was for nothing, we were just told ‘forget the process, and this is what you have to deliver by end of the month.’”
2. Reluctance to plan for sprints and releases because everything will change later anyway: Being flexible and agile is often used as a workaround for a lack of getting your homework done before coming to the meetings.
3. Forced to deliver even when things are out of team capacity: Burnout is real, and there’s a reason capacity planning is in place. So, going out of your way to enforce more doesn’t really help in the long term (think bad quality and reworks).
4. The influencer of the team is always involved in estimations and decisions: Planning poker is barely implemented because one person makes the call. Whatever happened to coming to conclusions about the story points and the estimations? New team members are never encouraged to talk about their side of estimation…so yeah, no prizes for guessing why estimations never work.
5. Why speak up when it’s already decided? Team culture always influences team behavior. So, imagine new members when they see that everything is decided. It tells them that it’s not required to speak up to air their opinions.
6. The same old retrospectives…and no one does anything about it: A team stops doing retros because similar points keep coming up without any action items being attached to them; the solutions aren’t there, and the problems remain.
7. The stand-ups literally never end: Teams have multiple discussions where more members join than are required—and it goes on for more than an hour. (Oh, by the way: Just because you do stand-ups doesn’t mean you’re agile.)
8. I get appraised based on what I did, not how I worked as part of the team: Time is wasted. The appraisal system that rewards individuals and not teams is controversial. Imagine if team performance didn’t matter…what should you focus on?
9. We might say we’re an agile team—but in reality, we don’t follow agile principles: Everyone calls us agile, but as a team we only do what we are told—and no, we are not self-organizing because no one empowered us to do that.
10. Everyone uses agile as an excuse to not do the prep or work because everything will be done “just in time”: Instead of excuses, just make it work. Try, experiment, fail and rebuild your agile culture again.

I don’t know about your experiences, but from what I have seen, agile is usually welcomed by the teams—the problems creep in later, as it’s not something management buys into (and it’s not just me: the Annual State of Agile Report also mentions challenges in adoption like “not enough leadership participation” or “inadequate management support and sponsorship”).

I know those who are happy being agile are aligned at all levels and are working on being a better team every day. It’s all about individuals and interactions over processes and tools, right?

What have you heard from colleagues about why agile isn’t always embraced?

By Sree Rao, PMP, PgMP, PMI-ACP

Atomic Habits has been on Amazon’s top 20 most read books of the week for 167+ weeks. In his book, James Clear proposes a four-step model of habits and the four laws of behavior change:

1. Cue – Make it obvious.
2. Craving – Make it attractive.
3. Response – Make it easy.
4. Reward— Make it satisfying.

Here are a few book excerpts that form the foundation for this blog entry:

“What is rewarded is repeated. What is punished is avoided. The first three laws of behavior change—make it obvious, make it attractive, and make it easy—increase the odds that a behavior will be performed this time. The fourth law of behavior change—make it satisfying—increases the odds that a behavior will be repeated next time. It completes the habit loop.”

“Success is the product of daily habits—not once-in-a-lifetime transformations. Habits are the compound interest of self-improvement. “

What can we take away from this? Here are three habits that I strongly recommend program managers implement. These are proven techniques that will help regardless of the type and size of the projects/programs:

Atomic Habit #1: Run regular retrospectives
Retrospectives are an excellent way to identify incremental improvements on a continual basis. Continuous improvement is also the foundational concept of Kaizen. Retrospectives are built into the Scrum methodology; however, you can use retrospectives irrespective of the methodology. Here are some steps to build this habit of running regular retrospectives:

1. Make it obvious by scheduling a recurring retrospective on your team’s calendars (biweekly, monthly or whatever cadence works for your project team).
2. Make it attractive by varying the format of the retrospectives regularly. Example: Use some fun templates for running retrospectives. There are several formats and templates that you can find on the internet.
3. Make it easy by allocating 10 minutes at the start of the retrospective to add everyone’s thoughts into the retrospective template. Identify only one improvement that is easy to implement.
4. Make it satisfying by starting off the retrospective by sharing the results of the improvement that you have implemented from the last session. Another way to make it rewarding is to add a “Thanks to…” section in the retrospective, where participants give thanks to the team members that helped them out

Atomic Habit #2: Templatize
“Templatize” as many artifacts like status reports, requirements documents, design documents and strategy documents as possible. While some leaders believe that templates limit creativity, I strongly believe that it is not the best use of our time to start everything from scratch when there are already well-established and researched templates. Creating an initial set of templates is a one-time cost with huge benefits in the long run. Get your project teams into the habit of using templates:

1. Make it obvious by creating a shared repository of all the templates and publicize the location of the templates widely. Make it part of a new project team member onboarding guide, project information resources page, etc.
2. Make it attractive by creating templates that are not only visually appealing, but also follow the accessibility guidelines. We don’t need to go overboard in terms of visual appeal, but ensure they meet the minimum standards for your team/company. Additionally, have an influential team member start using these templates. People form habits by imitating others, and having an influential team member using them would be a good way to get them motivated.
3. Make it easy to create the artifacts from the templates by providing as few instructions as possible. Also give them the freedom to make changes to the artifact based on the specific need without any approval process.
4. Make it satisfying by recognizing the team members that use the templates to create their artifacts. This is needed in the initial stages when the team members are getting into the habit of using the templates.

Another advice from the book is “standardize before you optimize” and this is perfectly applicable for templates. Standardize the use of templates first and based on the patterns that emerge, optimize the templates

Atomic Habit #3: Consolidate project tasks and action items
One of the challenges I have been facing has been that the action items from meetings are all over the place (Google docs, Words docs, Excel docs, etc.) and the project tasks are typically tracked in a tool (Jira, Asana, Monday.com, etc.).  Consolidating project tasks and action items would greatly simplify tracking both for the PM and the team. Here is a suggestion to get the team into the habit of adding action items to the task tracker:

1. Make it obvious by creating a specific section in the task tracking tool for tracking meeting agendas and action items. I have added a section called “weekly stand ups” in our regular project tracker and started adding agenda topics and action items there. You would have to figure out the best way to do this with the specific task-tracking tool that you use.
2. Make it attractive by using the features that the tracking tools already have for creating dashboards to show items in progress, completed, etc. Several contemporary task-tracking tools have the ability to create very attractive dashboards.
3. Make it easy by using existing tools and creating a section in the same task tracker so that the team has one place to check all their tasks and action items.
4. Make it satisfying by recognizing and acknowledging the completed action items and tasks. Send out weekly reports. Recognize team members that diligently use the tracker.

In summary, here are my top three atomic habits that you can cultivate amongst your project/program teams for success over the long term:

1. Run regular retrospectives
2. Templatize
3. Consolidate project tasks and action items

I would love to hear the habits that have helped you as a program manager. Share them in the comments below!

by Christian Bisson

I’ve recently been part of a discussion concerning changing the length of sprints from two weeks to three weeks, and the product increments (“PI” from SAFe) from 10 weeks to 12 weeks. Hearing the arguments throughout the meeting made me realize how the impact the sprints have on teams is greatly underestimated. Also, it’s important to note that in this case, the sprint length is aligned for all teams—meaning all teams need to change.

In the discussion I was in, the arguments for having longer sprints were that it would reduce the number of meetings (therefore deliver more value), and that we would have better sprint reviews. Let’s review those arguments, and other factors to consider

The Number of Meetings

Assuming we are only referring to “agile” meetings, it’s true that the events (ceremonies) will occur once every three weeks instead of two weeks. However, aside from the daily scrums, the length of each of those meetings is expected to be extended accordingly. 

For example, a good rule of thumb for sprint planning length is about one hour per week in the sprint, so a two-week sprint would have a two-hour sprint planning meeting, and a three-week sprint would have a three-hour meeting—making it an average of one hour per week, and thus not really saving time. The same goes for the review and the retrospective.

The daily is the exception; that would remain at a maximum of 15 minutes every day, so no gain there either.

Better Sprint Reviews

In theory, since sprints would be longer, teams should deliver more within them (more on that under “Predictability” below)—and that will allow teams to present more accomplished work.

Depending on your circumstances, one could even argue that stakeholders would need less travel time to attend the review since it’s once per three weeks instead of two (although these days, even that argument has lost its value!).

But let’s look at the other side of the medal. The review is a key event to gather feedback from stakeholders and obtain precious information to move forward. That now happens less often, and could risk gaps in communication. In some cases, releasing an increment of work is not possible without having approvals within the review, meaning that value could be delivered slower.

So for this argument, I would caution analyzing your circumstances properly before deciding it’s a good idea to change the length of the sprints.

Predictability

This argument was the “con” discussed in our meeting, which I felt was underestimated. For organizations and teams, having good predictability means delivering all (or almost all) of what we forecast to deliver within a specific timeframe. This is key for planning product roadmaps, aligning dependencies, forecasting budgets, etc.

Predictability in our world is a challenge though; as we know, things change, and what we thought would bring value is only confirmed by empirical information that allows us to adapt as needed. This means that the longer the forecast is needed, the less chance we have to be accurate.

Don’t get me wrong—teams that have gained a certain maturity are expected to get to a point where they can accurately forecast the work they’ll accomplish within their sprint, and moving to a longer sprint would be viable for them. 

But the maturity of the team may vary, and in our case, we were talking about brand new teams that had a decent amount of carry-over from sprint to sprint already, so it was a no-brainer that they would struggle with longer sprints.

Scope Stability

Another element to take into account when selecting the length of sprints: Are the circumstances related to the scope stable enough to be able to focus on a sprint that doesn't (or barely) changes? The longer the sprint, the longer a potential “change” would have to wait—and if it can’t, then the sprint’s scope risks being changed.

Estimating and Splitting Stories

In order to properly plan and deliver sprints, it’s a good practice to split stories so that they fit within a sprint. Therefore, the smaller the sprint, the more it’s important to split stories—and that’s a habit teams develop as they grow.

On the flip side, if a team has not yet developed a good habit of splitting stories, a larger sprint will give it the impression that “it can be delivered within a sprint.” This results in a higher risk of having a backlog of large items that the teams struggle to deliver.

Conclusion

The length of a sprint largely impacts the ability for teams to forecast and deliver accurately. It’s not a decision that should be taken lightly. It’s also important to involve team members in the discussions.

What factors do you consider when deciding the length of your sprint? Any lessons learned to share?

By Yasmina Khelifi, PMI-ACP, PMI-PBA, PMP

Why is it so important to recognize and fight imposter syndrome? Over my project manager career, I have often felt imposter syndrome—especially when I began a new position or started on a new team.

Psychologists Pauline Rose Clance and Suzanne Imes developed the concept, originally termed “imposter phenomenon,” in their 1978 founding study “The imposter phenomenon in high achieving women.” Imposter syndrome is defined as “a psychological condition that is characterized by persistent doubt concerning one's abilities or accomplishments accompanied by the fear of being exposed as a fraud despite evidence of one's ongoing success.”

Let me share with you a painful memory from my early days as a project manager. I was interviewed for a position in a more operational role, and I felt miserable in the interview. I was hesitant, diminishing what I did (“It was a small project”). I was accepted, but I nonetheless began the new role thinking that I was chosen by luck and not because of my accomplishments.

I was going to replace one contractor on a team that was formed by contractors. I lacked so much self-confidence that I asked many silly questions at each step. One day, I needed to retrieve an FTP file, but I didn't have access. I went to one of the contractors, and he told me, "I will not do it for you because you have to learn to do it." I stayed voiceless.
Imposter syndrome paralyzed my thoughts. In my own head, my behavior gave me an image of strong incompetence. It was a vicious circle. A few years later, I was fortunate to have a 360°-feedback session at an external firm. I met a work counsellor who changed the way I thought about myself.

"The excess of humility—appreciated and encouraged in some cultures and countries—does not serve you well!" she told me. “You have to describe fairly and positively what you achieved." It was an eye-opening conversation.

The way you introduce yourself in a new environment can influence your credibility. Over the years, here are some strategies I’ve developed to fight imposter syndrome:

1. Be proud of your achievements.

Focus on what you have achieved so far. I do this in two ways:

• I have a dedicated folder in my professional email where I store all the positive feedback/messages I get. It sounds narcissistic, but when I am uncomfortable or insecure, I can go through them to boost my self-confidence.
• I also have a file where I track both my professional and personal achievements. This also helps me to know my strengths better, and it gives me examples to use during an interview or a self-introduction. Don’t limit yourself to professional settings; you thrive in many other fields.

I will also put sticky note reminders on my computer with some encouraging words and tips—for example: "Speak slowly and breathe when you speak in English" (as English is not my first language).

2. Build a circle of kind friends.

Surround yourself with a circle of kind friends you trust and who can give you honest feedback.

Is there a former alumnus from your college you can reconnect with? A former colleague/manager you can talk to from time to time? Do you know a more seasoned project manager you can connect with?

I don’t mention “mentor,” as I have a team of mentors more than a unique mentor. You may also have friends outside of work willing to listen to you—they will help you reframe the situation you’re experiencing.

3. Join a community.

I’m part of several project management communities at work and through PMI. I’m also a member of some PMI chapters. It’s the place where I turn to when I have doubts.  

Don’t stay alone! Others face the same issues as you, and that realization will energize you and push you to find new perspectives.

What other strategies have you developed? Share your comments below.

By: Lynda Bourne

We now live in an age where Google search is ubiquitous, and the “find” function in Word and PDF documents is almost instantaneous. The challenge for most people is sorting through the long lists of information returned from a search to locate the most useful items. This was not always the case. As Dennis Duncan—a British writer, translator and lecturer—set out in his book Index, A History of the: A Bookish Adventure[1], the need for indexing first emerged in the 13^th century and has been evolving ever since.

There are basically two indexing systems. The simplest is a listing of the important words that occur in a reference book, identifying the pages or sections in which the word is used. The more complex system is built around topics and identifies the section of a book in which the topic is discussed, often indexing multiple publications. Both systems were developed around the year 1230, and marks the change from a time when books were a valued artifact to be read and enjoyed, to one where books became an information repository to be used as a resource. The invention of the printing press would not occur for another 200 years (1440), so in 1230 books were an incredibly valuable resource in limited supply.

The word “index” was invented in Paris by a Dominican Abbot named Hugh of Saint-Cher. The Dominicans are a preaching or mendicant religious order, founded in 1216. Their calling was to have Friars live among the people in big cities and preach sermons to stop the flock from going astray.

To help his Friars write their sermons, Saint-Cher instructed a group at the Dominican Friary of Saint-Jacques to create a word index, or a concordance, of the Bible. Every single word in the Bible was put in alphabetical order with a locator indicating where that word appears. The friars listed about 10,000 individual words and 129,000 locations. As a consequence of this work (that still exists), the preaching Friars writing new sermons were able to find the information they needed reliably and consistently.

A parallel driver for indexing was the creation of universities, with Oxford being one of the earliest. Robert Grosseteste, a medieval English scholastic philosopher, taught at Oxford until his appointment as Bishop of Lincoln in 1235. Grosseteste read widely, and to help locate materials for his lectures, invented an indexing system based on symbols made up of curved and straight lines, circles, E-shapes, etc., which were added as annotations in each of his books. Different symbols represented different subjects, and in a separate general index he kept a record of where they were located. The result was a kind of parchment Google—once he's read and annotated a book, he knew where information on a subject was for future reference. This type of index is still called a general index.

In the 13^th century, very few people could read, and books were scarce, making the oral delivery of information vital either as a lecture or a sermon. But delivering a lecture (or sermon), required information to be sourced, organized, synthesised and written down in preparation for the delivery. This means the presenter needed to use books—not just read books, but to be able to go back and use the contents of books as an information resource.

Engaging with a book transitioned from being a linear process where the reader had all the time in the world to journey from end to end, to one where books became seen as storehouses of morsels of information. The invention of indexes allowed people to use and research their books more efficiently, enabling them to preach or lecture at short notice.

800 years later, these concepts are still evolving. Unfortunately, the traditional concept of indexing is rapidly disappearing. The fundamental requirement for an index is a page number, and e-books don’t have set pages; the page a word appears on changes depending on the font size and screen size selected by the reader. This is a pity; creating a good index is both an art and a craft, requiring interpretation and judgement to look at each passage and decide what words a person would use to look for that specific text.

On the other hand, Robert Grosseteste’s concept of the general (or subject) index has moved from the world of academia to mainstream. Google indexes millions of pages of new information every day. Both Google and the various feeds to your PDA index then select what you see based on the topics you are interested in, filtered by the application of a liberal dose of artificial intelligence (AI).

The challenge for everyone in the modern era is being able to filter and validate the thousands of returns from a typical Google search and to make sure their feeds are not too limited. The various systems will order the information you see in a way its AI systems calculate will give you the best experience. But best from the system’s perspective is that you like the result and will therefore use it again. This is not the same as offering the most accurate selection of information, particularly if there are contradictory viewpoints.

How reliable do you find the search engines and indexes you use to find information?

[1] Index, A History of the: A Bookish Adventure, Duncan, D. Allen Lane, UK, 2021. ISBN: 9780241374238