Delivery Leading Archives

How to manage multiple projects: a few tips

by Raj | Sep 10, 2023 | Delivery Leading, Project management | 0 comments

Managing timelines for multiple projects can be challenging, but with the right strategies and tools, it becomes more manageable. I have been managing multiple projects for a while and it can become chaotic if you are not in control. The idea is to stay on top of things smartly by employing systems. Any process you use must work for you and not the other way round.

Managing multiple projects means managing stakeholders, customers, team members, products, timelines, roadmaps etc. At times, it does feel like herding cats, but it also brings a sense of achievement once you deliver outcomes.

Things don’t always go as planned, but that’s part of the game. It is about learning, practicing and adapting. You want to create visibility for yourself and others so that things do not fall through the cracks.

Secondly, your relationship with people will pay you more than behaving like a tyrant. For that, communication and respect an important role. Don’t be a jerk!

Here are ten effective tips to help you handle timelines on multiple projects simultaneously:

Tip	Description	Tools/How
Prioritize Projects	Identify and rank projects based on importance to your organization’s goals. Allocate resources accordingly.	Use a prioritization matrix or a simple ranking system. Business value based prioritisation is often useful.
Create a Master Schedule	Develop a comprehensive schedule with all project timelines and milestones.	Utilize project management software or a spreadsheet. A visual representation will help you stay on top of things.
Break Down Tasks	Divide projects into smaller, manageable tasks or phases (batches) for better tracking and resource allocation.	Create a breakdown structure for each project.
Set Realistic Deadlines	Establish achievable deadlines for tasks and projects, considering potential delays and unforeseen issues.	Estimation is almost always wrong, but it can be useful if used as a guideline. Secondly, estimation done by people who will do the work is more reliable.
Use a Project Management Tool	Employ software like Asana, Trello, or Microsoft Project for task and resource tracking, and collaboration.	Train your team on the chosen tool for effective use. Drive the tool, and don’t let the tool drive you.
Delegate Responsibility	Assign specific responsibilities to team members and communicate expectations and deadlines clearly.	Implement a responsibility assignment matrix (RAM). Again, use that to guide the delivery, and not to performance manage people.
Regularly Review and Adjust	Hold regular project meetings to review progress, identify issues, and make necessary timeline adjustments. But don’t create a meeting tsunami.	Create a meeting schedule and stick to it. Have a clear agenda to keep the meetings short and on topic.
Resource Allocation	Monitor and allocate resources, including personnel, budget, and equipment, based on project priorities.	Use tools that work for you.
Time Blocking	Dedicate specific blocks of time in your calendar for each project to improve focus and reduce multitasking.	Use calendar or time management apps to schedule blocks.
Risk Management	Identify potential project risks and develop contingency plans to mitigate their impact on timelines.	Conduct risk assessments and document mitigation strategies.

Remember that effective communication and collaboration with your team are crucial for successful delivery/project management. Keep stakeholders informed of progress, challenges, and changes to timelines. Make things visible as much as you can. Additionally, flexibility and adaptability are key as project priorities and requirements may unfold and evolve over time.

I shared the team’s mistakes with everyone, then this happened…

by Raj | Feb 14, 2022 | Agile, Culture, Delivery Leading, Product development, Product management | 0 comments

A few years ago, I led a product development effort at an enterprise. We were constantly experimenting, so had our fair share of wins and failures. But I had the feeling that we weren’t learning from mistakes quickly enough.

Large organisations maintain risk registers, which usually keep details of risks and issues. We also had a risk register, but it was being treated as one of those documents created for the sake of documentation.

Frustrated, I decided to put a poster on the wall with the title “Failure log”.

Why the heck a failure log?

The team reacted differently to the failure log. Some were amused, some confused, and some annoyed.

The annoyed ones saw this as exposing their weaknesses.

The confused ones didn’t know how showcasing our mistakes was going to help the project.

Others were happy that we were taking an initiative that could not only build psychological safety, but could also help us learn from our mistakes.

My challenge was that the organisation was not very mature. It was very much a command and control environment, so having the courage to publicly admit you’d made a mistake was a bold move, and to some extent a risk.

It was a risk because the board and the management team had invested heavily in the program and they were watching our progress very carefully. It was quite possible to face unintended consequences of making mistakes. In other words, it could have been a career-limiting – or perhaps even career-killing – move.

Luckily, the Chief Product Officer I worked with was progressively minded. He encouraged and supported experiments. Plus, the Program Director and I had become friends and she supported everything I did. Both could understand my vision and wanted to be part of it.

We were like a start-up within a traditionally managed enterprise.

Many of the team members, including the Product Leads and the Innovation Manager, were itching to do more and my bold step encouraged almost everyone to step up and forward.

I started adding smaller mistakes and things on that poster that could have been improved.

The Blunder!

And then one day… it happened!

A team member mistakenly sent a test email to hundreds of customers. It was a PR and Communications disaster.

You may be wondering why a test web page was connected with a production database?

The web page was built for a fake door experiment and the idea was to expose a very small number of customers to that page.

We got through that issue… but the question around recording that mistake on the Failure Log felt almost as tough.

The team was divided on sharing an embarrassing mistake with everyone else. Specifically in an environment where we were expected to have Gantt charts, detailed project plans, roadmaps, scripted test cases, and God knows what else.

So, what did we do about sharing the mistake?

After a bit of discussion within the team, we decided to include the mistake on the Failure Log because that was the right thing to do. There was a consensus about being congruent.

What happened after taking that major step?

I was sacked… right?

No. Nothing major happened at all. We were warned to be more diligent in future. That’s it. I thank my lucky stars for that.

Lessons that I learned:

But something did happen that was major for me:

The team became bolder
The experiments we quietly discussed earlier turned into open discussions
More items appeared on the Failure log, which by now had become the learning log
More and more visitors from other departments wanted to learn from us
And the best of all, the cohesion and collaboration among team members (as well as with the management team) improved

Taking a bold step, and then taking another courageous step on top of that, taught us many lessons and made us a great team. We delivered value to customers, and we were more open about our outcomes. Best of all, the tea cohesion improved.

I can’t ignore the fact that the senior folks I worked with made it easier for me to take bolder steps. If executives aren’t supportive, then forget about experimenting with new ideas.

The failure log was an experiment that could have gone in any direction. It could have become a political mess, or quietly died from lack of interest.

Users don’t know what they want, and we don’t know our users!

by Raj | Feb 10, 2022 | Delivery Leading, Product development, Product management, Software Development | 0 comments

I was speaking with a friend yesterday who happens to be a senior leader in a big 4 bank in Australia. He told me that he recently rubbished a new feature that a group of tech and prod people brought to him for improving frontline staff’s work.

He wasn’t pleased that the group didn’t know what the staff on the frontline did. So, he asked them to spend a day in the bank’s branch and observe what the staff did.

The group returned with their observations and admitted that their idea was faulty.

It seems that product and tech teams don’t invest enough time and effort in learning what their users do, or how they perform their jobs.

Asking users what they want isn’t a good approach:

Don’t ask users what they want. Users don’t know what they want, so they ‘dictate’ what they desire.

You should have heard the quote attributed to Henry Ford where he says, “If I had asked them what they want, they would have said a faster horse!”

Horse cart users would have desired for faster and healthier horses, and more comfortable carts.

So, Instead of asking users what they want and then jumping right on doing that, we should:

– ask them for their pain points
– get their insights and learn from those
– ‘explore’ rather than ‘gather’ requirements

So what do we do if not ask users?

It is true that often users are served features or products that aren’t useful for them. Possibly because people who build those products never find out how users do what they do. That’s another problem because of which we see so may rubbish products in the market.

A while ago, my doctor (GP) explained a similar situation to me. She was struggling to use the software that the health practice had recently bought from a software firm.

Her comment was, ”They built this software for doctors without understanding what doctors do and how they might use this software.” Fair enough!

Not engaging with potential customers or users is one of the biggest shortcomings of product development. An even bigger problem is not knowing what the users actually do.

Knowing what a user does provides deeper insights into their work. Those insights can significantly inform and influence the development work that the product teams undertake.

Three Agile and Scrum questions from a reader

by Raj | Sep 28, 2020 | Agile, Coaching, Delivery Leading, Job and career | 0 comments

Delivering work using Agile practices can be tough because work environments vary and different organisations throw different kinds of challenges on us. I often receive questions from readers about agile delivery practices. What I have been observing for a while is that the questions mostly relate to dealing with people. As Jerry Weinberg said through his Second Law of Consulting, “No matter how it looks at first, it’s always a people problem.”

This post answers some of the common questions that I recently received from one of my contacts. I have made some minor edits to make the questions generic.

Coaching teams and organisations

Question 1. How should I as a Scrum master go about coaching the organisation about Agile. I come from a consulting background and coaching is usually limited to the Scrum team that I work for. Are there any techniques that can help me coach organisations or stakeholders?

Answer: As a Scrum master, oftentimes you will only work with a couple of teams. Coaching one or two teams is easier, manageable and more convenient. However, there’s no optimum number of teams that a Scrum master can work with. Although it might appear useful that a Scrum master should only work with one team, a lot depends on the nature of the work the teams are doing, their maturity in terms of the agility, the complexity of the work, the structure, size and the culture of the organisation etc.

One thing is sure that as a Scrum master, an organisation wouldn’t want you to be spread too thin. In his book Secrets of Consulting, Jerry Weinberg offered us his Law of Raspberry Jam, “The wider you spread it, the thinner it gets.” And, as you may know, good jam has lumps. I think a thinner jam loses taste too. In our terms, that’d be losing focus or interest.

Now coming back to your question of coaching the organisation. It pays to confirm what someone means by coaching. People often confuse training and coaching. Let’s assume that they want you to coach the organisation on using Agile practices. How would you do that? Of course you will understand their context, the training and skill gaps, and possibly the problems they want to solve through coaching. Accordingly you will find the things that will offer you few quick wins and time to find a long term solution.

Techniques of coaching depend on who you’ll deal or work with. I often mix things to make them accessible and practical. For example, I’ve organised brown bag sessions, arranged team surveys to find out what they want to learn, scheduled coaching sessions with other Scrum events so that teams don’t use the sprint time for training, coached teams by organising team contests etc. My experience is that given sufficient notice, stakeholders enjoy taking part in contests or challenges.

Getting pushed back on Agile Delivery

Question: Many times I get to deal with Clients who have low agile maturity. Either at the team level, or at the stakeholder level. I get pushed back on Agile process delivery as this would disrupt their business. In such a scenario, I initially did an Agile/Scrum 101 training. Talked about my successful experiences from the past with successful Agile delivery. However, I still felt that the clients or teams were not convinced. How should I have approached this as SM differently to get the stakeholders or team to buy into Agile ways of working?

Answer: That’s a good question and many Scrum masters, Agile coaches and delivery managers experience similar challenges.

First thing that we should understand is that Agile itself is not the goal. Even though some organisations might say that they want to be Agile, their main objective is possibly to solve some other problem through applying Agile methods or the mindset.

What often seems to happen is that when given a responsibility, many Agilists blindly start applying frameworks, tools or methods. This results in pushback from teams as well as stakeholders. (You might want to watch this video about tools and frameworks). Agile is about change and we know that people don’t like change because change is hard. (But remember that change is not always resisted. Having new born babies brings a huge change in people’s life, but almost everyone enjoys that even though it turns their lives upside down, at least for a while.)

Your clients must have hired you for a specific reason or reasons. They wanted you to solve some problem for them. Understanding their problems, their context and what bothers them builds your own confidence in the problem solving process and also instills confidence in the client. Running Agile 101 is the easy part. Knowing whether that is required, is the hard part.

Old School Product Owner?

Question: I had a tough PO who needed all requirements into the project delivery roadmap. What would be the best way to convince a PO that we cannot have all the features in the product roadmap and can only accommodate a MVP approach ensuring we can only focus on features that can be developed in a given period of time.

Answer: It appears to me that your PO was not trained in product ownership and was only carrying the PO label. You might want to show them this video from my talk at the Agile POs and BAs meetup. In this talk I explained what product ownership is and how the prioritisation works. I’ve heard that many people found it useful.

Although things have slightly changed since Henrik Kniberg wrote about MVP, sometimes I still use the sketch that he created to explain the idea.

You may also want to make sure that the POs you work with get training in product ownership and understand that their job is not to manage people, but to work with them for frequent delivery of valuable outcomes. You can do that by building a trusted relationship with them. Think about getting into a social contract with them.

Side note: there is no single ‘best way’ for almost anything, but there are always many good ways. ‘Best’ expresses ‘the only way’, while there can be more than one way of achieving our goals.

So, these were my responses to the questions. What else would you add to these answers? Would you answer these questions in a different way or would you give a completely different answer? Let me know.

Biases, mindset and tools

by Raj | Sep 14, 2020 | Agile, Delivery Leading, Management | 0 comments

Few recent conversations made me think about the approaches and tools that we choose for delivering valuable work. Many people rely solely on tools that they’ve always been using. They never change their ways of working. Or, they may change the labels, but not the actual approach.

This is the snippet from the first conversation:

One of my ex-colleagues mentioned that his primary stakeholder, who happens to be the executive of the department, told him not to bother her about the process and frameworks he was using. She hated any mention of Agile, Kanban or Jira. She needed detailed plans, roadmaps and estimates and believed that other approaches didn’t work.

Why was that?

The other conversation happened during a recent event. A participating senior manager of a large organisation was concerned that stakeholders don’t understand iterative approaches. He wanted to collect and use more data points to prove that work was happening. My personal observation was that his team and he himself lacked an iterative delivery mindset. Was his approach to rely on data right?

What seems to be the problem?

“Elementary, dear Watson!” (Actually, Sherlock Holmes never said those words in any of the stories. At least I didn’t come across those words. I have read Sherlock Holmes more than once, I enjoy that so much.)

These conversations remind me of a few cognitive biases. Primarily of the curse of knowledge bias and Dunning-Kruger Effect.

It might be true in both cases that one party thinks that the other one knew more than they actually did. My colleague possibly was talking in a jargon laden language that the business executive didn’t understand and decided that it was all nonsense. All the while the ex-colleague assumed that she being an executive knew more about what he was talking about. That’s the curse of knowledge.

It is also possible that the same executive believed that she knew more about all delivery approaches. And the ones she actually knew more about, were the better ones, because she knew more about them (sounds dumb, but that happens). That assumption by her makes the other ones bad automatically, at least for her.

That’s the Dunning-Kruger Effect.

The third point I want to make is not about bias, but about data.

Data is ruining everything.

Well, not really. We rely on data for decision making. However, over-reliance on anything is bad, isn’t it? I must remind you of the Challenger catastrophe if you disagree with my assertion. You can read about that here. If you read the report, pay special attention to Richard Feynman’s observations and findings. Every word there is insightful.

In a nutshell, what happened then was that NASA wanted to make decisions purely on data, while an engineer had a gut feeling that there was something not right with the O-ring (type of a valve that stopped gases from leaking from the spaceship). That engineer didn’t have data to prove, only a strong gut feeling.

We all know about the disaster where few astronauts sadly lost their lives.

The CTO in our scenario is focusing on data. It has been proven many times either through research, or in real life, that statistics often fails to influence us compared to social proof.

Not convinced?

Think how many times you have made decisions based on a friend’s advice. We approach our family or friends and read online reviews when we buy cars, houses, electronic equipment and other stuff. We look for social proof there.

So, I’m not surprised that by offering data to executives, this person is hardly making a difference.

What else is happening?

What do you think is happening in these scenarios? I’m looking for more insights before we jump into potential solutions.

Let me know either by commenting or emailing.

How do you improve collaboration when everyone is remote

by Raj | Aug 18, 2020 | Agile, Coaching, Delivery Leading, Facilitation, Leadership | 0 comments

Building trust, enhancing collaboration and establishing relationships is hard enough when teams work together in a physical office. Things become more challenging when teams are distributed. This issue doesn’t sound too challenging when one team is co-located and works with other teams that are at different locations or different time zones. Actually, ever since offshoring and outsourcing became mainstream, we have learned to live with the distributed nature of work.

When do we collaborate?

We collaborate with others to achieve something of common interest. For example, entrepreneurs may collaborate to build and launch a new product. In corporate settings, different teams collaborate to build products and to deliver valuable outcomes for their customers.

Collaboration is successful when the level of trust is high among the people who work together.

However, the question remains.
How do we build and enhance collaboration and trusted relationships among team members?

There are hundreds of methods that help us do so. But we’re not going to list all of them here. Google is good for that sort of stuff. In this post, I’ll tell you what has worked for me and then you can tell me what has worked for you. Hence, don’t forget to add comments below.

Current challenge:

When it comes to collaboration, the current pandemic has made the situation even more challenging. How? Now not just the teams, but every single person of a team is located remotely. That brings a different dynamic to the equation when we talk about collaboration and teamwork.

I’m going to share two techniques that I’ve found useful.

The first one is personal mapping.

Enhancing collaboration using personal mapping:

When team members know more about each other than just the work stuff, the bonding improves. It mostly happens that when we sit in the vicinity of others, communication begins. The generic, “hey, how was your weekend?” often becomes the icebreaker and increases the flow of communication. And it appears to me that this improved relationship also helps us deliver better outcomes. This might just be human nature. When our ancestors worked together, they survived and grew.

Personal mapping technique is a simple mind mapping exercise where you tell your story through visualisation. Here’s my personal map.

Personal mapping

How to get your team’s started with personal mapping:

A good place to start is to use the technique as an icebreaker before workshops. Or, do it when New team members join.

I often start with asking team members what they knew about me. One they respond, I share my personal map with them. I normally include details of education, work, hobbies, family, goals and values etc. The idea is to keep the session interesting. This often helps in making team members feel safe, relaxed and engaged.

After sharing my personal map, I encourage team members to pair with someone who they don’t know much about.

Team members talking of their colleague’s personal map:

When team members know that they will be introducing their colleague to others, they listen intently and they try to understand them better.

How to do it remotely

Easy. If you’ve created your map on your computer and if you’re using a solution liked Google Meet, Microsoft teams or Zoom, you can share your screen. If you’ve created your map on paper, you can show it on camera.

Drawbacks of personal mapping:

My observation is that introverts can find this exercise a bit awkward. Some team members also do not want to share information about themselves for personal reasons. Each person is different and it’s better to familiarise the team with this exercise beforehand and find out whether it might make someone feel uncomfortable. You can work with them to adjust the exercise for them and make them feel safe for participation.

Using collaboration game Quinks for team bonding

I came across this interactive game when one of my friends invited me to join a free session with the game’s inventor, Viren.

The game is available online as well as a physical set and that makes it easier to either do it remotely or in person.

Quinks game

How to play:

Quinks is based on experiential learning techniques in which two players ask each other questions related to specific contexts by drawing cards. One person is assigned the role of Questioner, and the other the role of Answerer. The Questioner draws a Quinks card (a question card) and combines it with a Context card to create and ask a powerful question. These cards consist of powerful questions that Viren collected through his research and experience.

Since the game limits conversations (responses of the contextual questions) to just 3 minutes, it compels team members to pay attention, learn to express themselves in a concise way, ask good questions, empathize and engage in deeper conversations.

Outcome:

I had fun playing the game even with total strangers in public sessions. It was interesting and surprising to realise that given a context and a relevant question, how you can bond with those who you’ve never met before. This was a great way to introduce people and build relationships.

Value map for further discussions:

The game also lets players map various values of their partners based on their conversations. Once everyone completes the game, you see the value map that represents how others have perceived you through your responses. Through this process you learn about your blind spots and improve self awareness.

A good reference regarding self awareness here is Johari Window. Have a look.

Personal mapping and Quinks can possibly be combined as one big workshop. I haven’t tried that yet. You may want to do that.

If you have used other collaboration techniques that gave you good results, let me know. Actually, even if your efforts didn’t succeed, we can learn from them. Why not share them here.

References:

https://quinks.co/?variant=32701557342283

https://management30.com/practice/personal-maps/

https://en.wikipedia.org/wiki/Johari_window