Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Management

    Management is not easy and in this category we have articles on Management to help you understand and navigate the world of management.

    20 articles in this category

      Project, Maintenance or Line Work - what is the difference and does it matter?

      If you work in IT, you have probably heard the words projects and maintenance many times. Usually it is in reference to different teams and organizations, but not always. Sometimes the same team can do both projects and maintenance, which can cause some confusion. To add to that confusion, you will sometimes hear the word line work as well. As these all see to be a bit malleable, it can cause some annoyance. With this article, I hope we can make a definition so we all know what we are talking about.
      These are all financial constructs
      Before we begin, let us define what these three terms refer to, since they are sometimes confused with processes or even methods. Projects, maintenance and line work are all financial constructs. This means that they exist as a way to manage budgets and resources. In most cases, projects and maintenance exist together and form sequential ways of working (waterfall, RUP and so on) while line work is the basis for iterative forms of working (Agile). This is also reflected in their financing where projects and maintenance mostly have fixed budgets and scope, while line work have fixed budgets, but scope is more loosely defined against value themes.
      A project is usually the easiest to define of the three. This is because most of the work in IT are still project based, so most people still work in projects. Projects are by their very nature sequential, meaning that they follow a step-by-step process to get funding and approval based on certain values. These values are often defined as features, but in some cases it can be other types of values. The difference between projects and line work is however that value need to be measurable and once set it normally can not be changed.
      Projects are defined as time limited bubbles of time, scope and resources that can span across different borders such as systems, organizations and even companies. When this happens, the project is split between the different areas and placed under an umbrella structure we call program. This makes projects the easiest form of financial structure to organize when you need to span multiple areas.
      Most companies that have been around a while also have a strong culture of organizing external resources around temporary work as projects as well. This is usually well-defined in their vendor management structure as well. This is why projects are the most common form of financial construct in most companies.
      One of the most misused term of these three as it is often used for anything that is not project based. It also comes in two very different forms based on how contracts are defined in Vendor management.
      At its core, maintenance is nothing more than making sure the systems are working properly once a project has ended. This means that as a project ends, there will be a list of items that need to be taken care of, usually in the form of known bugs and technical debt. After the handover, maintenance handle unexpected incidents in production, problems and in some cases it also includes enhancements such as refactoring to make the system more stable.
      In some cases the maintenance get to work right after a release. This is when contracts are written without post go-live support, meaning that as soon as a delivery is accepted and released, the team in charge of the development no longer are responsible. This is often an awkward situation where the maintenance team and the development team can start to resent each other if there are a lot of incidents being released to production due to poor testing and acceptance processes.
      All of this is handled in a service management process that is matched against a contract with SLA and a budget for the work to manage the system or systems. This is often paid for by the product owner(s) or a business area within the organization on an annual basis, which is often managed through maintenance plans.
      Unlike project and line work, maintenance are not generating new value. The purpose of Maintenance is to maintain value, or to correct loss of value due to problems and incidents.
      Line work (line organization)
      If you have ever worked in maintenance where you also do development for new features as part of your work, then you are probably in some form of line organization doing line work. The term refers to a manufacture line where you continuously build things. Unlike a manufacture line, where you do the same thing all the time, line work in this context refer to continuous improvement when it comes to development.
      Line work, just like maintenance, usually have an annual budget. Unlike maintenance where the goal is to maintain value, line work have the same aim to produce new value in the same way as projects. In line work, however, this value is usually defined in terms of focus areas, or themes, and larger goals rather than defined ones as you have in a  project. This makes line work better suited for exploratory work such where value creation is iterated based on result.
      Line work often employ a flexible workforce, allowing them to quickly adjust resources based on need. This also works well for larger initiatives where the flexible workforce simply expand their numbers for a period of time and then shrink again. This however require a different way of handling vendor management and contracts as you can not define them around deliveries, but rather against value creation.
      The confusing mix
      It does not really matter what form your financial construct have, because at the end of the day you will adjust your preferred way of working anyway. You can work in an Agile methodology within a project and you can do waterfall in a line work setup. There will be challenges of course, but people do it every day all over the world.
      It is when things get mixed up you start to get problems. This usually happen with line work and maintenance, or projects and line work.
      Anytime you hear that maintenance also should so development of new features, then you are fading into a mixed situation, or are moving towards line work. This is confusing because you mix the concept of not generating new value in maintenance with creating new value as in line work, but without the flexibility in financing. This can cause headache, not just for managing the budget, but also because maintenance usually do not have a requirement process defined. The situation can be fixed however by moving over to a line work setup instead.
      The most common situation however is when projects try to mix fixed time and scope with exploratory methodologies. This is often done by implementing a sequential scrum methodology and an ad-hoc requirement process. Scope creep are very common and frustration high from confusing requirements and trying to iterate value within a confined time frame with fixed budged and deliverables.  The solution for this is usually to focus on requirements to reduce the ad-hoc situation and try to iterate within the limitations presented in a more flexible way, rather than agile.
      I hope this helps
      As I see these terms used on a daily basis and sometimes in a very confusing way, I hope this definition helps. If you disagree with my definition, feel free to write a comment and we can discuss things. If you like this article, or better yet, find it useful, a comment or like is always welcome 🙂

      The bad boss - what is a bad boss and what can you do about it?

      Employees don’t leave organizations, They leave bad bosses. We have all heard it and we all probably have a bad boss experience or two in our career. But what is a bad boss really? Are they just terrible monsters that tear organizations apart, or are they just people like you and me?
      Just as people are different, so are our perception of what a bad boss is. What I consider to be a bad boss, may not be a bad boss to you. It all depend on who we are as individuals and what we currently need. Regardless of who we are though there are three mental types that everyone dislikes and those are psychopaths, narcissists and machiavellians. This is how Birgit Schyn, Barbara Wisse and Stacey Sanders describe these types in their article Shady Strategic Behavior: Recognizing Strategic Followership of Dark Triad Followers:
      “Narcissists have a strong sense of entitlement and a constant need for attention and admiration. They are arrogant and consider themselves to be superior to others. “Machiavellians are sly, deceptive, distrusting, and manipulative. They are characterized by cynical and misanthropic beliefs, callousness, a striving for … money, power, and status, and the use of cunning influence tactics. In contrast to narcissists, Machiavellians do not necessarily have to be the center of attention and are satisfied with the role of puppeteer, unobtrusively pulling the strings.
      Psychopaths “are unlikely to consider the needs and wishes of others and are unafraid of crossing moral boundaries. … By creating chaos in the organization, as well as in coworkers’ personal lives, they can pursue personal agendas without detection. They do not only enjoy hurting people, they strategically use humiliation and bullying to direct other people’s attention away from their hidden selfish activities. … psychopaths are often viewed as the most malevolent ones of the Dark Triad.”
      We call these collectively Dark Triad personalities and when you encounter them there is very little you can do but to leave the organization. These are not bad bosses, they are bad people with mental issues that can hurt you, so stay away from them whenever possible.
      These are not the bad bosses we are looking for however, because there is another group, that is far more difficult to handle than the Dark Triad bosses. I am of course talking about the Sudden Asshole Bosses and the Micro Management Boss. These are people that actually are very good people, but they suffer from insecurities and inexperience as leaders.
      These are usually people that others like because they are caring, well-spoken and often action driven people that listens and take care of problems in a way that make everyone happy. Then when they get appointed to a leadership perspective they change overnight to become a controlling asshole of a boss.
      Why do good people become bad bosses?
      My personal experiences and observations is that this happens to new and inexperienced people due to a shift in the direction of care. By that I mean that as an employee my direction of care is usually towards my co-workers. That would be the other employees. As a person moves up and become a manager you have new responsibilities to people above you in the hierarchy. That means that you naturally shift your direction of care upwards.
      This is nothing bad, but if you add stress and the feeling of not being a hundred percent sure of what you are supposed to do as a manager, then the need for control start to take over. As we know stress does not help with maintaining a kind a generous disposition, so that does not really help the situation either.
      We also tend to adopt behavior from those that we work with. If a new manager are unfortunate to have others around them that belong to the Dark Triad, or that have fallen into the trap of micromanagement, then it becomes natural to be drawn into that. This is not because they want to be bad bosses, but because they need something to cling to as managers very rarely get any leadership training before they are tossed into the new roles as managers.
      People that feel insecure, or that are in a position where they feel they have to live up to certain expectations due to their gender, religion, sexuality or race, they are more prone to this in my experience. Not because they are any worse or better than others, but because they fear failure or letting down others more. Fear is a great motivator, unfortunately it often motivates good people to become bad bosses...
      How do we get bad bosses to become good bosses?
      Most Sudden Assholes and Micro Managers tend to get over the initial shock of becoming a manager. With time, they will again shift their direction of care to the people they are in charge of. They will learn how to navigate the minefield of leadership and distance themselves from behavior that is detrimental to the people under their care. They will also realize that micromanagement is not a healthy or sustainable way of working and as they feel more secure in their roles as leaders that need will dissipate.
      As people feel more secure they will also realize that the very reason they were chosen for leadership in the first place was because they are awesome. More often than not it is also because they add something to the company that is missing. For this reason it does not make sense to conform to what already exist. Many leaders blossom greatly when they realize this and a lot of people transcend from bad bosses to amazing bosses.
      For some however the bad boss attitudes get stuck. These are people that need help to break free from the bad boss loop. In my experience there are three things that seem to work well on most people:
      Time - One of the bane of new managers is stress. Helping your manager to reduce stress is a great way to help them get over the hurdles of transition from bad boss to great boss. Be proactive in providing information and take care of problems and you will quickly see a transition in attitude.
        Proximity - Being away from the people you are supposed to lead make bad bosses feel more connected to other bad bosses instead of the people you are responsible for. Break this by asking the bad boss to spend more time with the team. Don't let them hide in a closed room, bring them out in the open and in close proximity of the team. The bonds will naturally reforge with the team and the bad influence from other bad bosses will be reduced.
        Respect - Even if you are getting treated like crap and you are frustrated, show respect to your boss. Remember that they are probably struggling badly with things you have no idea of and with a show of respect you can ease that stress. Also remember that they are human and that the goal is to help them over the speed bumps of being a bad boss so they can become great bosses. Showing respect reduce their insecurities and remind them how awesome you are as well. I am not saying this is easy or even feasible in some cases, but just remember that bosses are people just like you and me and they have things going on in their lives you probably have no idea of.
      I know of one middle manager that was pretty much ambushed by several teams that gave him hell for almost 30 minutes before he broke down crying and told them that he had cancer and did not know how to deal with that.
      A woman I read about a while back was struggling because she was gay and was afraid that people would find out and she would be fired, only to find that everyone already suspected it and loved her regardless.
      Some are struggling with addiction, others with family issues such as divorces or deaths in the family. Some are struggling with bigotry from higher up in the company, some have asshole bosses of their own to deal with. Others may have illnesses or suffer from anxiety. There are a million reasons why someone may behave poorly in certain times of their lives.
      Just be open to the possibility that bad bosses may just be amazing bosses trapped inside their insecurities, bad company and a stressed out mind.
      You may hold the key they need to break free.

      Value Stream Management - another top down approach to ROI?

      Value stream management, probably most noticeably introduced as a part of the SAFe framework in nothing new. It is a simple visualization of the value creation process connected to the financial aspects. In short, it is a way to organize work based on finance and perceived value to the end user. This approach is another top-down version and as such it comes with both positive aspects and negatives. If handled correctly it can be mostly positive however.
      Let us begin by setting the stage for what Value Streams actually are: artificial constructs designed to match value with cost. In a sense that is the same as a line organization that continuously create value, but with a specific value in mind that is not tied to IT structures such as systems.
      This is where the first problem usually start to show itself: what is value and to whom?
      If you have spent any time with Agile or Lean evangelists then you know they will talk about the end users experience as the one and only metric of importance. I find that to be a naive and narrow point of view because as a company you are in the business of making money. That means that the metrics that matters is what do we benefit from as a company. In order for the company to benefit you usually want end user satisfaction, but it is not the only metric.
      There is no benefit for the company if the end user is satisfied, but the company lose money because of it.
      In order to set any form of metric to measure value you need multiple perspectives and this is very difficult when you have experts that either focus on end user satisfaction or company profit. The answer is in the middle, but very few companies have the capability to bridge the gap and find that value.
      Defining what value is
      What happens is that value often are defined in services rather than value. Customer support for example or E-commerce. In some cases it even is split into business areas such as countries or brands. Neither is probably what constitute a value stream, but then again value streams are artificial constructs that still are very poorly defined other than "what drives value" in a typical theoretical abstract manner.
      My advice for this is to define what value are you driving and how will the company benefit from it. This is something almost all companies already have as it is a part of Portfolio management. Everything that you have a budget for already have value creation as part of the metrics used to motivate the funding. The only thing you need to do is to take your portfolio and sort the items in there into recurring areas. You can do that with a simple card sorting activity because if you work with Portfolio management you probably already have this in place in a way and you just need to challenge the structure a bit.
      It is worth mentioning that value streams are not organizations or departments. They are time limited artificial structures that you should treat as long term project or programs. Eventually these value streams will change, in fact you should have a process to re-evaluate value streams annually or at least bi-annually to verify that the value creation are still in line with what you expect from a value stream.
      Value Streams live on top of systems
      This is as true for Value Streams as it is for programs and projects. All IT organizations are system based and no matter what financial body you place above it should live above the system structure. What I mean by that is that each system should have one truth when it comes to documentation and competence. So financial bodies that touch the system will "borrow" competence from that system and they will share documentation with other financial bodies that touch that system. This prevents fragmentation of information and duplication of technical roles such as architects and test.
      It is common that when you define value streams that you will define entire systems as part of that value stream. This makes sharing systems less of an issue, but you should still keep in mind that the value stream is more or less hiring that system to deliver value and that other can, and usually will, have reason to pass through that system as well.
      Measuring Value. Actual value.
      When you start working with the value stream you will have certain things that you measure to see how well you deliver value. If you have defined the value  correctly as suggested above, then you will get multiple points of value to combine into the actual value. This is where it is common that companies realize that they do not have the tools to actually collect the metrics. In some cases they get the metrics, but do not know how to combine them into actual value.
      My advice here is to make sure that you define value the same throughout the company. Don't use arbitrary points of measurement like t-shirt size or story points because they will be useless at scale. You also need to measure cost, for real. Most companies only start to measure cost after the requirement phase, which provide a very skewed perspective as there are a lot of costs involved in defining a need.
      So start measuring all aspects of the processes before the need hit the development team and you will probably be amazed about how much time is spent defining the need. Ideation, meetings, workshop, decisions, estimations, technical solution design and requirement analysis easily add up to 50-500 hours of work for even small needs. I have seen features that added only a visual effect on the side with negligible value cost well above $50.000 just in meeting costs to argue about the correct implementation.
      You also need a way to translate other arbitrary measurements such as customer satisfaction into something useful. Hopefully you already have a template for this if you work with ROI from CRO, or at least you have some way to measure how an increased customer satisfaction also increase profit for the company.
      When you measure actual value and not just a part of the value creation, then you usually will have very different results than if you only measure single points.
      Value Streams. For real.
      Like I said, value streams are nothing new and most organizations already have it based on either financial value or customer value. The trick is to combine the two into value streams that give you the real answer to the big question: what creates value for the company and how do we improve that.
      Combining soft values such as feelings with hard values such as money is no easy feat however. As you dive into the esoteric and abstract world to try to combine the intangible with hard realities you should expect to fail initially. There are no magic formulas for working with value streams, which is why you should be aware that this will probably be a very expensive exercise of futility unless you truly commit to making it work.
      If you commit and you find that sweet spot between measuring too much and not measuring enough, then I firmly believe you will have a big advantage compared to your competitors. If you also work with predictive activities to test theories before you commit to them, use predictive data analysis and engage with the end users to drive decisions, then you are a winner, regardless of what field your business operates in.
      Just don't throw in Value Stream Management as some form of magic bullet, because it is not.
      You will not be the best in the world by adding a new way of training, you still need to put in the hard work. This is true for sports and it is true for business processes as well. You do the work and you commit to it. Or you fail.
      Commit, or fail.

      The Proxy Organization - five ways to battle a wasteful culture

      As organizations grow it will always increase the number of middle managers to stay organized. If the organization assign the wrong type of managers you may notice that that number start to grow a lot. You may also notice that the level of trust that exist between the different areas drop as well. This is what I call The Proxy Organization, and it is very damaging for your company.
      Every organization forms a hierarchy. This is how we make sense of the world around us. We define structures such as responsibilities and mandates to make sure we know our place in the organization. In an organization where these structures start to be confusing or poorly defined you often see the number of people between the leaders and the people that make things happen grow. This is because not only is it very difficult to handle a poorly defined workload, you also start to have meetings for everything. Not to take decisions, but to form consensus since it is not clear who should take the decisions.
      The more meetings you have, the less time you have to think about what happen in the meetings and the more help you need to go to more meetings. And so you enter into a running organization. Meetings happen all day and without time to reflect you start to make poor decisions and reduce time to communicate outside the meetings. So you hire more people to handle that, but soon they also get sucked into the meetings, and they need to hire more people.
      As these people start to get more and more stressed they feel the need to attend more and more meetings to keep up to date with everything that happens. As stress sets in the need for control grow. We introduce KPI's that are designed, not to make teams work better together, but to make the team accountable if anything goes wrong. We implement restrictions and control points in our systems to "ensure" people work "correct". Morale drops and segregation begin to foster a "we vs them" attitude.
      Slowly the organization split into silos, and we have more managers than people actually working. The managers spend all their time forming a biological proxy network with a single purpose to receive and send information in the endless meetings. People start to get sick from stress and start to leave the organization as the distance between the workers and leadership is made up of dozens of proxy positions all focused on control from a top-down perspective.
      Sound familiar?
      This is a very common thing as companies grow, and it is actually not that hard to turn around. It will require a lot of effort, and it will take time, but you will save a ton of money long term and most importantly you will stop hurting your staff.
      Step 1: Define roles.
      The first thing you should always do is define the roles in your organization. Make sure all roles are clearly defined, following a standard that is the same in all areas of the company. Don't make up roles like scrum manager or other combined roles. Stick to proper roles that are the same across the globe. You are not unique, so stop making up unicorns because you don't live in an imaginary fantasy world. Define responsibilities and mandates for all roles, so everyone knows what is expected of them.
      To avoid a situation where you pretty much play the whisper game and just forward information you define what input and output for each role. Every role should have some value passed in the output that is higher than the value they receive in the input. If the role does not add value, then consider why that role exists in the first place. If it actually reduces the value, then remove that role.
      In this step you should also match the role definition with the skill and experience of the manager(s) that hold that role. You will often find that you have the wrong person in certain roles, and you should try to match the roles with the people to get the best result. Never put a manager in a position on the merit of being with the company a long time. That is not the right experience to promote.
      Step 2: Define decision processes
      Endless meetings often come from poorly defined decision processes. So set clear decision processes that either comes as part of the portfolio process, or inside the teams if the team and product owner are given mandate. If everyone knows what need to be decided and the process to get that decision, the number of meetings are reduced drastically.
      Defining the decision processes also prevent "ghost projects" that are driven in isolation without coordination elsewhere in the organization.
      Step 3: Define information flows
      One of the reasons why proxy organizations exist is because the information flow is poor. By that I do not mean that you don't have information flowing, I mean that it is difficult to get the information you need. This is just as common with an overwhelming information flow as with an underwhelming one.
      Make sure that information is properly classified, so it is easy to find the type of information each person need or is interested in. Also make sure you make the information easy to overview with short snippets that I can drill down if I want. Lastly make sure the information is both sent in regular intervals when it is information that affect the whole organization, but also, so I can subscribe to get information of my choosing.
      If you do this right, then confusion and uncertainty is reduced. This lead to less stress and better decisions from everyone as they are better informed.
      Step 4: Define Meeting guidelines
      In a proxy organization meets are used as crutches by managers that are afraid to take decisions. Either because they don't understand what they are supposed to take a decision on, or because they feel unsure on their mandate, so they seek to get as much approval from others as possible.
      In Step 1 you make sure that you have the right people in the right position. This alone will help mitigate the endless meeting syndrome. Next you require every meeting to have a set agenda, what outcome should come from the meeting and most importantly a cost for the meeting. This will discourage meetings that are not really necessary, or that people that actually just want to have control join without having any impact on the desired outcome.
      The last thing to do in this step is to set  limit on meetings. If all you do is going to meetings, then what do you actually produce in value? Everyone need time between meetings to reflect and take care of the actions undoubtedly coming up in the meetings. Enforce 30 minutes waiting between meetings and 2 periods each week with 2-4 hours of consecutive meeting free time. Sometimes it can be a good idea to have this hard blocked in the calendar for everyone in the company, especially during the change process.
      Step 5 : Introduce bottom-up evaluations
      In most organization evaluations of people's performance within the organization is done top-down. To best understand the performance of the people in your organization you should also have the opposite represented. As a manager your job is to ensure that those below you in the hierarchy have what they need to be successful. In a Proxy organization this is often forgotten and a blame and punish attitude is used towards those below you in order to look good to those above you. This should be removed and introducing bottom-up evaluations is a good way to do that.
      This should be done often as a way to determine where in the organization people are running off to meetings instead of taking care of their people. It will also indicate where you have the wrong people in place or where people have too much responsibility to manage.
      Don't think you can change your organization "organically"
      While these five steps seem easy to implement they are not. This is not something you can throw into your organization in the form of "read this article and make it happen" kind of activity. This is something you need an organized change management process for, and it will cost money and time. As with all change you must commit to it and pay the price short term to enjoy the benefits long term.
      It will hurt, and it will not be an easy journey to stop running in an eternal meetings based proxy organization, but it will be worth it. If not for the financial gain, then for the well-being of the people.

      The Daily Stand-up - can we make it better?

      If you have worked in IT in the past 10-15 years or so, you probably have endured the endless regurgitation of meaningless information in a daily stand-up. You have probably felt the anxiety of being judged and been annoyed over your teammates doctoring their results to look more productive. You probably also wished you did not have to go to the meetings once or twice. What if I told you there is a better way to manage daily stand-ups? Because there is.
      First let us figure out what the purpose of a daily stand-up is and where it comes from. The need to organize groups and to collaborate is as old as time itself and while many consider the daily stand-up, or daily scrum to originate from the Scrum framework, that is not true. Regular meetings have been a common practice since long before Scrum, and it is also why it is the most used aspect of Scrum in less than Agile work processes.
      What Scrum did however was to add psychological stress to the formula with the intent of increasing productivity. This was done by putting emphasis on proof of progress rather than collaboration. It is an effective way to shame people into becoming more productive, and it is a typical behavior for extroverts to seek the admiration and praise of others. The downside is increased levels of stress, which is counterproductive. In many cases it also leads to manipulation of data and fragmentation of work, especially in continuous delivery situations where people tend to work on multiple things at the same time.
      For many years Scrum had three questions that was the law to regurgitate every daily meeting:
      What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal? In the 2020 scrum guide they have backed off from this a bit, but they still focus on the feeling of guilt by pushing the conversation towards progress.
      This is even more emphasized in the statement of the benefits of the daily stand-up:
      Again this is clearly written from the perspective of an extrovert because for many introverts this is NOT a forum for improved communication. The idea that the daily stand-up eliminate the need for other meetings is not true. It most certainly can consolidate questions into a more focused forum, which does reduce the need to bother developers and others multiple times, but you often find reasons for more meetings, not less.
      How do we make this better?
      Let us first decide why we want to have daily meetings in the first place. The most obvious reason is to gain control. This is how most managers that are detached from the team see the daily stand-up because it is the only way they can stay on top of things, so they can look good in other meetings. That is not what daily stand-ups are for however and as a manger you should instead manage your time and make sure you work with the team and not act as a proxy.
      The reason we have daily stand-up should be to make sure everyone in the team have a voice and to make sure everyone is informed. By making sure everyone in the team get a voice we can find impediments and help each other solve problems. We can lift concerns and ask questions in a safe setting that allow the team to feel safe. It allows for a common forum for information, so everyone can feel that they have the information they need at all times.
      We do this because questions and doubt are the bane of productivity and team health.
      The first thing we do is to remove the time cap. Our minds are very sensitive to time and performance under pressure, so we remove that. Instead, we add a 30-minute slot every morning where we spend as much time as we need. Sometimes it is just 5 minutes, sometimes we extend the 30 minutes and change it into another type of meeting.
      The second thing we do is remove the need to report what has been done. This is the cause of much anxiety and in a healthy team you should not need that type of information anyway. Instead, we focus on questions, impediments and requests for help. We make sure everyone in the team get a chance to speak, and we make sure that everyone feel safe, so they dare to say what is on their mind. This is important because one thing we want to capture is if time estimates need to be extended or if new tasks might be needed.
      We sort things that come up as team related or personal, so we can focus on the team related issues first and then take personal questions after the meeting to make the disruption as small as possible. To make this disruption even smaller we put the daily meeting as early as possible without limiting peoples freedom. This means that you most likely have people in the team that have kids or other family situations that require them to have some flexibility in the morning and afternoon. 9 or 10 are common times, but you can just as well do this after lunch for example. The aim is to avoid disrupting the team as content switching is bad.
      The final part is for the team lead and architect to inform the team of things happening outside the team that is relevant to the team.
      I strongly suggest that you make this daily meeting as comfortable as possible instead of actually making it an actual stand-up. The reason for that is that most people are more likely to raise questions and ask for help when they are comfortable. If you can align this around a coffee break or breakfast, then that is excellent.
      The summary:
      Schedule the meeting as early as possible without limiting the flexibility of your team members. Go around the team and let everyone ask questions, request help and raise concerns if there are any. Team lead and Architect give information relevant for the team. Confirm activities such as additional meetings or request for information or to solve impediments Grab some water or coffee and then return to work again. I find that these types of daily meetings often lead to better productivity for the simple reason that people feel less stressed when they get information and can get their problems solved. The outcome of these meetings often lead to technical discussions to answer technical questions and sometimes new activities to refactor things that might not have been captured otherwise.
      So if you are stuck in a daily routine of regurgitating Jira numbers where you feel the need to adjust numbers a bit just to look good, then I suggest you give this approach a try instead. 
      Management by fear and intimidation is a poor substitute for making your team feel safe and informed.
  • Create New...