IT and Project Management (PM)

This is one of many postings about observations of an organization "doing it wrong" when it comes to projects, with some suggestions on how such a situation can be improved.

20210720

I have been showing an intern examples in the real world (by having him attend) of rather broken project management.

Like many companies, this company claims they use a "hybrid Agile", but it is mostly just broken PM and bad overall management unfortunately.

One variation of hybrid Agile involved effective use of the best of waterfall and Agile methodologies.

Unfortunately this company is not effectively using Waterfall for big picture, and Agile for iterations with small teams.

As I have discussed in many of my lectures, one source I like to cite because the constructs are more accessible to laypersons and professionals than some others (perhaps stronger empirical constructors, but much more complicated to grok), is Bruce Tuckman's work on small group formation, communication, and dynamics. Based on this and related theories, it is shown that small groups are most effective (with best chances to get through forming, storming, norming, to performing), when kept around 3-9 members. Furthermore a team is a small group of people with complimentary skills brought together to achieve a specific goal for a project, remaining as a team until the project is completed.

It is critical that the team members are not being pulled away mid-project (or in Agile mid-sprint), because anytime the makeup of the group/team changes, they move from whatever progress the group made in stages from forming-storming-norming-performing, to re-forming.

Unfortunately this company has a culture of almost constantly pulling people for other projects mid-spring, almost every sprint, and sometimes many people.

The real-world examples I have shown the intern, are of a project currently in crisis. It has between 15-25 team members (too large, should be broken into separate teams) many/most of which are being juggled across 1 or more additional projects simultaneously, often pulled over to the other projects exclusively mid-sprint.

The project cannot count on most of the team members being available in future sprints either. There is no consistency in who the team members, or even the scrum master, will be for the project from sprint-to-sprint, or even in the middle of each sprint.

To compound all of this, the company has a culture of almost no documentation using the PM tools when moving from column to column a task in a swim lane. Team members just move them without explanation. Often forget to move them to reflect their actual state, and they only use: TODO, IN PROGRESS, QA, and DONE, with no other options.

Prior to my coming on board no one used the flagging features either for blocked tasks.

To compound the lack of documenting progress in the PM tools, almost no one updates the core central documentation pages either.

Also, when a team member has a block, they don't immediately reach out through the many communication channels we have for help, instead they just leave that task, even if they have no other task, and don't bring it up until the next day's standup. They don't even flag the task as blocked so that scrum master can see at a glance any blocked issues that need priority to address first!

And to top this all off, the scrum masters don't manage the standup meetings correctly at all. they should be 15 minutes or less, and if there are issues, then spin those blockages into a separate meeting to address, bringing in all resources needed to unblock that task. Instead, each meeting the scrum master clicks through each team member's tasks, and each task, one by one, asking what the status is, if there are any blocks, etc. So the meetings generally average 30-60 minutes each day! And then there are still needed the separate focus group meetings for full resolution of blockages.

The team-size is an issue.
The juggling projects, we all deal with in the IT world, that is not that big a deal, but worth noting.
The inconsistency of the team membership is a huge problem, it means the project is forever in forming/re-forming, rarely gets to storming, and never gets to norming or performing, which means the project never shows velocity achievment.
The poor PM is huge.
The incorrect use of stand ups is significant.

But, there is hope. After months of ramping up, I'm finally making inroads (albeit painfully slowly) with getting team members to daily update their status on each task, to migrate documentation to the central documentation core, and to ask for help when blocked, when it happens, rather than waiting for the next standup meeting. I don't have a say on the scrum masters, so that is still is an issue, and the SM keeps changing, so I don't really get to develop a rapport with any of them. And they aren't open to doing things properly, just this broken approach that appears to be company-wide.

So, there is some improvement, and some hope to keep improving, but wow, it is quite the mess.

More updates down the road.