 Thank you to be here with me. First of all, how many of you are into management? Management? Our managers? How many of you are new managers? They have started this year or previous year. Okay, so today we are going to explore common software development challenges that as a manager we will face regularly. Okay, so in this session we will cover unrealistic deadlines, poorly defined requirements, a scope creep, lack of flexibility, insufficient communication, inadequate resources, poor quality control, and team member turnover. So how do we know if we are facing any of those challenges or those issues? Okay, basically if you see that our team is working overtime, if they are stressed and overworked, if they are cutting corners, the quality of the work is decreasing, or even adding new features to our project are taking longer and longer, there are signs that we are suffering any of the previous issues. We can also check the velocity of our project. It means that if the number of points, the story points that we are achieving and sprint are decreasing, or the task competition rate, which means like all the items we have selected and that sprint are not being completed, or even we are facing new high-risk tasks, we foresee them in the near future, or the team morale is low, or there's even experience borne out, we should take action. So I'm Jorge Dutor, I'm an IT manager and I've worked as a project manager the last 10 years, mainly. I'm also a Drupal developer that switched to the management role. I work for Metadrop. We are a Spanish Drupal company. We are mainly based on Spain and we provide corporate and enterprise services and we focus on complex projects, mainly. So where management is key. So the first point is about unrealistic deadlines. And people under time pressure don't work better. They just work fast. So the challenges that we will face are stress and borne out because basically our development team will never meet expectations because they are not realistic at all. They will be forced to sacrifice quality in order to meet deadlines. As managers sometimes, because of this lack of time, we came to some trade offs with stakeholders that are not helping at all. Like if you give me more time, you can include more things into the scope. This is not helping at all in the project. When there is no time to think, we will start creating a lot of waste, like several features that will never be used. And probably the solutions that we are applying are not the best ones. As a company, we will have our own reputation. And our clients will lose lots of marketing opportunities because we are not going to achieve the deadlines. What can we do? The first one is obvious. Set realistic deadlines. How? We need to take into account the buffer time. We need to take in, when we are estimating tasks, we need to take into account the analysis, exploring even unexpected delays, like illness or dependencies with other teams. And it's key, like, the estimation should be provided by the team, not by managers at all. A deadline is a shared commitment. This is not something that it's only on developer's shoulders. So stakeholders should also help in order to achieve the deadlines. So in order to let them help us, we need to keep them updated on the progress of the project, be open. Better if we prioritize the task, the most important task first, so that way we can address new information or we need to adapt the task we have free time to do it. And if the deadline, and this is key, if the deadline can be challenged because it needs to be released for any marketing reason, we should challenge the scope that will be delivered at that time. Even we can decide to help multiple milestones, okay, this is going to be delivered on the first release and this will be delivered after and so on. And it's also key that if there are different teams involved in the same project, that the milestones are a shared objective. So you don't have one team working on the products and the other team working on the API if there's not much between them. And we need to say no to new requirements or at least to challenge them. And please mind the time that we have invested on the task or those items, even if they have not been started yet from the development point of view. Sometimes when you are working in Agile, you have the backlog and it looks like you can change any backlog task within the same scope, but maybe you have invested several hours trying to analyze that specific item. Trying to do something cheap to change things. Next topic is about the poorly defined requirements. And requirements that are not clearly defined are a recipe or failure. It's common like empty cards in JIRA or any other tool, but it's more common the absence or real examples of use cases. We just have like some accepted criteria, but there are not real cases that developers could understand and even to know the why it's been needed. We need stakeholders involvement in the project. Like the requirements should not be something written down in a document that everyone should follow. There will be always the possibility to challenge those requirements and even improve them. Everyone should understand the complexity of the project on the different parts of it. And if we have frequent changes in the requirements, it will be quite difficult to plan resources and to plan releases or to plan everything. Regarding requirements, we have the scope creep. We're going to cover it later on, but basically if no one knows what's been expected, it's impossible to fulfill the requirement. And of course, there will be misalignments on the contract level, because there will be blurry boundaries regarding what's been included in the project, what's not, what is a bug, what is a missing feature, what's something that needs to be done, what's something that's an extra cost, and so on. So first of all, we need to set clear expectations. We need to understand, fully understand which are the goals and objectives of this project. We also need to define a requirement management process, because the first document that we have in the tender or the RFP or whatever is not enough. We need to discuss each requirement with the client and explore what's been needed behind. And we should have, as an organization, a definition already. It's like the minimal information that an item should have in order to schedule for the next spring. We need to involve the right people on those kinds of meetings. We use, for example, the bar requirement meeting. And it's key that the people that will, that's needed are there. So it's better if you send them an agenda, so you make sure that all people that needs to be there are there. We can be helped by prototyping and mock-ups to help to visualize and to get feedback as soon as possible of the things we would like to achieve. Even better if we are able to use written executable specifications, like GERKIN. Right now, my partner is giving a session of BHAT testing and a workshop that's basically focused on how to write specifications in order to allow a machine to read those different sentences and apply them directly in the browser. And if we have no clue what's need to be done, we should iterate. Sometimes when you are involved in a project, you don't know what's going to happen next. So start small, iterate in the first spring, and you will evolve. Sometimes it's not possible to get all the definition of the products of your project or any feature. So the idea is to go incremental. Okay, the scope creep. The most important thing to do is you find yourself in a hole is to stop digging. So the scope creep is like a selling intruder in your project, gradually accumulating changes and additions that weren't initially planned. So the scope creep will, of course, create extra costs, project delays, and missing deadlines. The quality will be compromised because more work needs to be done, deadline has not been moved, budget has not been moved, then we need to take some shortcuts. And the team will be frustrated. They will need a clear path of things that needs to be done. So the strategies that we should follow is, of course, is to have a clear prediscope on objectives, as on the previous points, and we should challenge any new request. It does not mean that we should say no to new request. It means that we should have a change control process. So we analyze the impact of each change before we accept it into the scope. We should prioritize, I mean, not all changes are equal. And even sometimes when you are working in a project with a client, and you have previously specified a set criteria for this specific iteration, then that task is being presented to the client, and then the client starts asking for new kind of things. Okay, this is the next iteration of that specific feature that could be scheduled for the next sprint or not, because those new requirements are not as important as other things you could have in your backlog. And, of course, you should monitor your progress. I compare where you are with the initial plan and notice any significant deviation. Lack of flexibility, which is mainly the opposite of the scope creep. The bamboo that bends is the strongest. So when we have a lack of flexibility, it could come from both parts. Stakeholders development team. If the stakeholders are not flexible, we will need to implement always other solutions, because they will not adapt with spin there. For example, in Drupal, we have several modules that could be used. So achieving maybe the 80% of the project at first is quite easy, but going into the details takes ages sometimes. So if the client is flexible on their expectations and requirements, we have the possibility to invest that time in adding more value to the project and not to adapt in the web for module to behave exactly as the designer thought. If there is no lack of flexibility, we will need to do some work around, even to patch modules and so on, which will increase the technical depth. It will be quite hard to maintain those modules in the future. And, of course, the team morale will decrease because the team will need, in order to take the ownership and provide creative solutions, they should be allowed to suggest new things. And from the client point of view, we will have the satisfaction, as if the development team are quite strict with the initial scope, we are going to lose opportunities. We are going to don't evolve with the customers, which is something that we cannot afford nowadays. And, of course, contract fiction. What can be applied, of course, agile methodologies, whatever you would like to use. We should adjust requirements and scope by the new information. We should establish the change management process and analyze for the impact and also to work in a risk management plan and anticipate all potential risks and try to mitigate them. And we should explore also agile contracts. There are alternatives to the common fixed price contract. So, I think that we are all aware of the time and materials, but there are other models, like time and materials, with a spending selling. So, the stakeholders know which is the limit that will be spent in the project. We can be paid by Sprint, but there are also other alternatives, like the fixed profit, like since the beginning of the project, you define with the stakeholders what's going to be the profit of the project and then you charge them only the cost per hour, the real cost per hour. So, if the project goes longer, the client is not losing more money, but you are not also losing money. In adequate resources, necessity is the model of invention. So, we could have inadequate or limited resources because of lack of time, of budget, team expertise, of team capacity. Because of that, we'll have unrealistic expectations and a scope, deadlines, and budget. We'll have delays because it will take longer to complete the work. We'll have poor quality or technical depth because of lack of specific knowledge. Even without time to test things properly or bugs, then there will be flaws in the software. And we will reduce innovation that will likely, it will be less likely to meet the user needs. So, the strategies are, we should prioritize, be flexible, and we need to focus our resources in the most critical areas. Sometimes there's lots of noise when we are building a project, everyone is sharing their thoughts, but as a manager, we need to find which are the key points and focus on them all. We need to estimate realistically based on our real situation and we need to take into account the complexity of the project and the complexity could be technical complexity or even a team complexity, maybe the client has several teams that need to align first or there are lots of dependencies and so on. We should be honest with the stakeholders and be open about the limitations of the project. Sometimes it could be limitations on their side and we are the ones that should point about them. If needed, we can outsource and even better, we can cross train our team. So, we have, we develop a more flexible skill workforce. And every time it's possible, we should automate so we free our team to focus on the most important work. We can automate updates, we can automate the testing, we can automate several things. In sufficient communication, as you know, as a manager, we need to deal with humans. We are still there. Who knows what will happen with AI, but right now. So, communication is not what you say, it's what the other person understands. So, there will be misunderstandings that will produce lots of waste. There will be probably poor coordination that will make mis-deadlines and scope creep. Probably there will be some conflict between the team members and the stakeholders. And people will decrease their morale as they will feel that they are not being heard. Like, I told you that before and no one listened to me, so now right now we are feeling in something that we raised weeks ago. So, that's key that everyone is being heard in the team and also in the stakeholders side. So, we need to establish regular communication and channels and events. It could be daily meetups between the stand-ups between the team or the retrospectives or even any other agile event. We need to encourage open and honest communication. So, everyone is comfortable about asking or even challenging the requirements and sharing their concerns. We should provide feedback and this is key. I recommend you all to focus on the positive feedback. If sometimes as managers we tend to blame people that are not doing things properly and this is not the right path. It's better to focus on the positive things that are working well in the project so all the people will follow. And please use the right communication tools. You have decided to use Jira, GitLab or GitHub or whatever. Please avoid using emails or any other kind of thing. Emails, you all know that are dangerous but the most dangerous thing is like there are only a few people in that email loop so you will lose all the track of the project of what happened or why this was decided. About poor quality control and sufficient testing like quality is not an act, it's a habit. So, we will challenge reputation issues, increased cost, customer dissatisfaction and security vulnerabilities. Here we have three examples or top companies that faced stock market down 20%. They needed to ground the entire fleet of their airplane or they had a high damage reputation. So, we are the ones that need to explain the clients and stakeholders how important its quality control. One experience that we had when we provide estimates to the client that sometimes we had the test like in a different batch and clients used to ask us to remove it. Like, okay, we can save 20% of the project so please remove testing. So, what we decided is like it's been included and we don't let them know which is the percentage of the testing. But you should have a plan and a budget for testing. It could be explicit, it could be implicit but you need it on your estimating. You should allocate also resources to do it. You need to have this test plan and you can use a different kind of testing techniques like unit testing, integration testing, system testing, acceptance testing, visual version testing, security testing, all of them are needed of course depending of the project. There is a concept called testing coverage. I think it's quite impossible to get 100% coverage in all those fields. But it fully depends on the kind of project we are working on. You should focus on that specific thing. For example, you are working on an e-commerce then buying a product ski should be tested. You are working on a corporate site that creates news and then news are key so it needs to be tested. Probably the key is what could happen that will make my client to call me at 3am in the morning. All those things should be tested. Of course, you should automate all the tests so you avoid manual errors and you should involve the whole team, even stakeholders on the quality control. They should all be aware of the benefits or they should be all aware of the challenges if they are not applying or they don't agree to invest time on testing. And last but not least, team members come over. People live managers, not companies. So we have a lower morale, increased stress because of our work. When we lose someone, we are losing also their experience on the specific project but also their skills on the team. We will have a decreased productivity because we will invest time finding someone new and to train in the project and also to onboard in the projects that person is going to participate. And of course, as a company, it will be even more difficult to attract new talent. What can we do? Create a positive work environment where everyone feels respected and valued. Everyone is compensated fairly. In your company, there are career goals and people can develop new challenges and responsibilities. We should reward publicly accomplishment. And it is key. We should promote as managers healthy work life balance, flexible work and we should discourage our work. So what are the next steps that you can take? Of course, all the previous ones but the ones that I recommend to start with. Set realistic deadlines. Gather feedback early and often from stakeholders, from what you have learned of the previous spring. New concerns that the team is finding in the project, new opportunities, new market opportunities and so on. We will be willing to say no or at least explain the client why it is not a good idea or the impact in the project and if they accept, let's go. We should accommodate change. We should encourage communication and collaboration. Allocate adequate resources, have a robust quality control process and of course recognize team members achievements for the contributions. So thank you and sir your thoughts or what questions do you have? Anyone wants to ask anything or sir any thoughts? I think so. Yeah, you can ask questions through the app or you can bring in a microphone. Real life is better. Hello. Very interesting that there is few things because I worked with junior teams, senior teams, 15 years old developers or five years or three years old. What I find a bit complex is sometimes like the guilt is often in the terms of the stakeholders or the customers. Developers are more, have less, maybe another developer as well, have less tendency to accept or so that there is lax in the understanding of the process as well. By example, I think there is even for 15 years or 20 years developers, they have complexity to understand also the estimate because even if we think in terms of sprints of story points and you can declare what is like the complexity of a task, you must estimate this task. No client or no no stakeholder will accept that you say I will develop until this is done. I need to say in the terms of this print I will achieve something. So the developers have difficulty to understand that sometimes a sprint is a deadline. It's not like just a rhythm or a technique or a meeting. It's a deadline in the fact. You must say what you are able to do in the terms of the hours or days that compose the sprint. And this is an interesting point because there is sometimes a lack of, it's difficult for the developers to understand. The estimate are one of the biggest issue with the developers. I find for myself or so it was complicated. The other thing is Gherkin. I think Gherkin like a good concept, very, very complex to apply in reality. To take like someone that is not technical and say you will learn a language that is not that easy. It's always English. It's understandable to apply it because we describe together the scenario that will be like the test. It's very complex to apply. So you can use BART, you can use like end-to-end testing, user acceptance testing, but it will at the end be complicated to apply Gherkin as a like mutual language in my experience. And last, it's I think one of the point that is missing is also like the over testing. I think like one of the things that developers do often is to over test. So they will test from, so by, on Drupal, by example, you will test that the click will open this window, this window will open this message, this message, and you click submit will do this. So you are testing not only your development, you are testing the whole application every time. You are testing that the click of Drupal is working, that the Ajax response will come. And then, so the over testing is also something that especially on Drupal, because it's not the same result technology, it can cost a lot in terms of management. Okay, just a few comments on your words. I think that we have all suffered the same issues. Regarding the first point about the team not achieving sprint goals, recently what I started doing is asking the team to finalize all items, but with the possibility to discuss requirements with me anytime. So requirements or acceptance criteria are flexible. Sometimes when you are as a manager, we set specific expectations or create a different acceptance criteria, you are not aware even that you could be a technical person that sometimes things are more complex that you thought and sometimes are not really needed. Or maybe something that could be done later on or it is something that can be challenged with the stakeholders. So when, and sometimes when the team are not able to end all the items in the sprint, it's because they were blocked by something. So open that channel of discussing why what's blocking them and then discuss if something should be moved or not. So I've seen that splitting features into different iterations helps to increase morale in the team because they see that something has been finished, it's been delivered, maybe it's not released on production, but they see that advance. If not, it's like maybe that item were there like a fourth sprint and we will be forever there. Regarding testing, we strongly believe in BDD approach, I mean to create a test first, because it helps the developers to fully understand what's been needed. So sometimes just gritting down the test, even if it's not going to be run in an automatic way, but just using that gherkin syntax help all to understand what are the expectations and also to find the edge cases of the project. Which for me makes no sense, is to add tests after you have done something. Like I mean if this is working, why is you are going to, I mean for thinking on the maintenance in the future, maybe it makes sense, but you are losing that boost. For example, when you are writing down, as you said, the user clicks in this button and then there's a card that opens and can see the card that has added, the item has been added to the card and so on. I think it's good to test that because if this is not automatically being tested, the developer will need to do that manually several times. In the end, it will take longer. And at the same time, of course Drupal is based on different components, but we need to test the end-to-end, of course we have the unit testing, we have the kernel testing, we have everything that each module should provide. But as a company, I think it's key that we test the full process. Because next time you upload the new Drupal commerce or update any kind of component, even now that Drupal uses lots of vendor libraries, you never know if it's still working. So at least if this is an e-commerce, our product checkout should be tested. If this is a newspaper, a news creation, deletion, edition, and so on, needs to be tested. Even if you think that Drupal provides that out of the box, but in reality as you are going to use different components at the same time, you will need to make sure that the components of all of them are still working. So we have a question at the front and then a question through the app. Thank you for the presentation, great work. I have an important question, in your presentation you mentioned that you are a metalhead, I was wondering what type of music do you listen to. Which one? What type of music do you listen to? You mentioned you're a metalhead, but that aside, you came up with a list of items mostly titles, but I was wondering what would be the exact approach in a real-world scenario. So for instance, I had a use case that I was working with a developer and we broke down the tickets, all of them, you know, all of them assigned and estimated everything and agreed upon with the developer, we can manage it, we will maintain it. Let's say you need 100 hours throughout all the tickets and here's the deadline and the developer is like, yeah, all good. And then a week passes, no reply, you follow up, yeah, you're there, you're almost there, you know, and then a couple of weeks afterwards, the budget is done, the work progress has been like 20%, what is the appropriate take on that, you know, and this might happen again and again and at some point other PMs would like not to work with that certain developer because, well, the same reasons. And also another question is that you mentioned we have to keep up the morale, you know, and appreciate the contribution of team players within a team. What are those that you do in Metadrop, for instance, you know, any examples or whatnot? So thank you. Okay, regarding a person that is not giving you feedback on something is going wrong, I think that person is feeling fear of recognizing that it's not achieving something. In Metadrop, we work as teams, we try to avoid isolating people, so that way we'll have always someone that will help you if you are being blocked. So as a manager, we should all create the channels where people feel comfortable being vulnerable. Sometimes as a developer, we could think that we can do everything, we are superheroes, but even sometimes we are. It's not always the rule. So I mean, I suggest to discuss with that specific person to see what's happening, explain to him or to her that it's not the first time that she's not meeting expectations, that maybe that person is it's not realistic with estimation. Maybe the issue is like when you ask them, they feel that pressure that if you let them know that it will take one week, you will be angry some way. So they'll let you know now just two days and they're never is two days. Something that we do with the team on the retrospectives. We sometimes serve them the time we have invested on each task. And it's incredible because sometimes they were, I mean, most of the times they were not aware that that specific task take longer because maybe the task itself was quite short, but the QA that was needed for the task was quite long or even the deploy of that task on so on. Regarding team morale, one thing that's great is, for example, before starting a project, you have a plane and you board the team into the project, you can ask them directly what they think that they will learn after this project is being done. Sometimes we feel as a developers that we are like in this wheel where there's one project and the other and the other and the other and there's no evolution. So you focus a little bit on what you are going to achieve with this project and after it's being done you have this retrospective of the project and you can ask them, do you feel stronger than before? Just as a good example. Another thing that we do is like we use contribution by default, like we try to contribute all the modules that we provide to the custom, but the business logic of the customers. So that way they are contributing to the community which also helps a lot in their morale. And of course we avoid overwork as much as possible and we give all our team members 10 hours per month to invest in whatever they want which basically normally contribute to code and so on. So they have also flexibility and freedom to do whatever they want. So the question from MLR, do you have any advice for dealing with higher management stakeholders that refuse to listen to your suggestions or explanations for why you may need more time or resources for a project to succeed? Sometimes it's impossible. Sometimes there are bad clients. This is real. But sometimes you cannot get rid of bad clients because sometimes it's a huge percentage of your income. So I think that you need to invest more time trying to figure out what's happening on their brains, on their minds that does not connect. Sometimes people say no because they don't fully understand what's behind. So I recommend to approach them individually so that the way they can be more vulnerable. You like to approach the director of any company with several people in the same table. That person will play the role of the boss and will say no to everything. Maybe you approach that person individually. It will be easier. As I said before, the commitments, the projects, the budget even, it's a shared commitment. I mean we have a contract. We are going to do the best but we need your help. We need your direct help on this because if not it's not going to work. Thanks very much. Is there another question or if not, do you want to tell us about your metrics and preferences? Thank you very much. Thank you very much, George.