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.

Project

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.

Maintenance

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 🙂

View full article

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.

View full article

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.

View full article

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:

1. What did I do yesterday that helped the development team meet the sprint goal?
2. What will I do today to help the development team meet the sprint goal?
3. 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.

Quote

"The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work."

This is even more emphasized in the statement of the benefits of the daily stand-up:

Quote

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

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.

View full article

I hear this all the time. "The product owner" is absent or "the product owner can't give a straight answer on what I should do, it changes by the minute". This is especially prominent in project based organizations where Agile means that you just remove the requirements phase in your waterfall process to make things fall down to the development team faster. Agile becomes ad-hoc and chaotic and it is all the product owners fault. Right?

This is a problematic attitude and one that to me clearly means that the team is not really Agile, but still work as a receiver instead of the engine it should be. Although in most organizations there are two processes and the development team always is the receiver of strategic goals, they should not be a passive one.

Not being passive means that you put demands on what you receive.

How you receive a new business need, what information you need and how you work together with the product owner is not something that you passively sit around and complain about. It is the core of what the retrospectives are for! I would bet that in most teams where you have issues with the product owner you do not include that person in your retrospectives? Do you even provide feedback or set up activities to help the product owner improve together with you?

If the product owner is not included, then could the issue be with you and not the product owner?

The product owner is a part of your team. This means that you are responsible to speak up and ensure that everyone in the team is working in the way that best benefit the team. This means that you should provide feedback if the product owner is absent or if you do not get the information you need. This should be done in retrospective, just like you do it with every other feedback concerning your work process and collaboration in the team.

Easy to say, but our Product Owner does not care.

I know, this happens all the time. The product owner is tied up in meetings all day and just ignore your feedback. This is where you need to play hardball and provide empiric evidence that the issues you have is not your fault and that you have done your job to try to improve this. The First step is to go above the product owner and point out the issue to the people above. Sometimes that works, but it may not always be an option.

In the sprint planning you should be very clear on what information need to be present for you to accept a user story. Remember that once you put the user story in the sprint, you have accepted the user story and you are responsible for the consequence for poor requirements. Never accept a user story that is not clear enough for you to work on. It is the responsibility of the product owner to ensure the user story can be accepted by the development team.

If you use Jira then your next step will be to push back everything that is unclear to the product owner. This is done by assigning the product owner to the issue, put the issue in blocked status, or flag the issue if you do not have a blocked status and then comment saying that you wait for the product owner to respond. Once done, leave the issue and move to another issue. This will effectively remove the priority for the first issue as it will now be done after whatever issue you pickup next.

This will allow you to move responsibility to the product owner and point out the issues you are having. It also allows you to get statistics on waiting times the team have due to the product owner not doing their job.

Failure is on the team, not the product owner alone

Just as the entire team is at fault if the scrum master or a team member is dragging the team down, the same goes for product owners. You manage it through the retrospective and constructive feedback. Help the product owner to be the team member you need hem to be. If that fail, then you as a team will fail as well.

Make demands, just as you would for any other team member. Make sure their calendar have all stand ups booked, all retrospectives should be holy times and if they run around for meetings all the time, have them block time in their calendar for the team. You would not accept a developer to not do their job, so don't accept if the product owner is not doing theirs either.

At the end of the day, remember that no product owner want to be a bad one. They often get dragged into activities where their role is poorly defined, so they need help to define what you as a team demand of them. This will make it more clear to them how to prioritize their time, or find a replacement to make sure you get the team member you deserve and need.

Never sit silent with a clenched fist in your pocket.

Speak up and offer constructive solutions and you will be surprised how willing many are to solve the situation with you. Teams work together and since we still have not developed telepathy we need to verbally communicate and express our need to work better together.

Product owners are not outsiders, they are valued team members.

...or at least they should be.

View full article

I recently read an article called "Scrum Is Dead. All Hail Kanban, the New King" where the author Emanuel Marques praise the Kanban flavor of Agile as his experience of Scrum have been less positive compared to Kanban. One of the responses to that article was written by Maarten Dalmijn, and he made some good points in his article on how flawed the initial article was.

To anyone who work with Scrum in multiple projects and multiple companies you probably recognize Emanuel's story. It is in no way a unique experience he has that Scrum, like many other Agile flavors, are misrepresented due to adjustments by the team or the company. Here are some examples from Emanuel's article:

Quote

After a few years, I started noticing one thing: In the last days of a sprint, everyone was rushing to deliver everything they had done in the previous two weeks to avoid carry-overs, frequently taking unnecessary risks.

A common thing that happens way too often. When you are inexperienced with Scrum, estimations and you do not set sprint goals, then this happens a lot. We see that the team is not working properly in the burndown chart as well.

This is a typical Agile burndown when using story points when you either have issues that are too big or you do not close issues properly. For a team working with story point, which I think is stupid in any case, a burndown chart is completely useless.

Quote

If you needed to do unexpected work (bugs, problems in production, etc.), it would affect your time and consequently make you fail the commitment you made in the planning meeting.

This is again inexperience in making proper estimations and because of that you did not have room for the unexpected. In all processes, methodologies and frameworks you need to be able to make proper work assessments. Agile make that easier by letting you make arbitrary measurements that are more like "guesstimates". If you fail doing that, then you are in real trouble regardless of what process methodology or framework you choose.

Emanuel's team choose to go to Kanban because of their inability to adjust their way of working away from the production line of thinking to an Agile way of thinking. What was it about Kanban that attracted them?

Quote

• Kanban has no timeboxed iterations (sprints).
• Kanban does not require story estimation.
• Kanban does not have the concept of commitment. Items enter the flow as they need to be done.
• Kanban provides several metrics that measure the time that a story takes on the board.
• Kanban does not require a Scrum Master (obviously).

So out of all the things that Kanban offer, Emanuel's team choose to focus on these. As you can see all of these are about commitment and responsibility. If you combine this with the reasons Emanuel and his team felt the need to move from Scrum to Kanban you probably can see the same thing as I can and that is that this is a team that no one has taught how to work properly.

They have been left in a work environment where things are difficult to navigate and control and as a result they feel they are unable to commit to anything. I assume this is because failure, as diffuse as that definition might be, happens frequently. They also seem to be working with a poor scrum master, possibly also inexperienced or limited in his capabilities by the work environment.

Sadly I think Emanuel and his team will soon find out that Kanban with the focus on escaping accountability and control is a bad choice. Kanban is not going to make failures go away. In fact, it will probably make things worse as the stakeholders will find the Kanban way of working, especially the bare-bones version Emanuel and his team are describing, very annoying as they have little to no control in that flow.

What does this have to do with what flavor is king?

Well this has everything to do with what flavor is king. They all are. If you use them properly. Sadly many work places implement Agile in all its forms in the wrong way. They try to make Agile work in a project based organization with an ITIL based steering structure with multiple teams on the same products.

If you add inexperience and poor coaching resources, then you are setting up all flavors of Agile to fail. With that comes frustration and stress for the teams, and they will naturally try to distance themselves from management and any form of accountability as they are destined to fail regardless off their effort.

This is referred to as a MOD project by some of us that work with process and methodology design. MOD is short for "March of doom" meaning that the project or the team are already doomed before they start due to the restrictions already placed on them. It is also in reference to how managers often refer to them MODifying the Agile way of working, which often result in a poor experience.

If you work with Scrum, Kanban, DevOps or any other flavor of Agile, that can be king for you and your team. If you use it correctly and you actually take your findings in retrospective to adjust it to fit your way of working. You can even mix them to find the optimal workflow for your team, because they all come from the same source: Agile.

You have the power to make your flavor of Agile king

This might seem strange for anyone who work in workplaces where your way of working is dictated by management, but there is hope. In all organizations you have two ways of working: The Steering and the Operational. If you can find the way to meet the steering, so they can do their job, then what happens in your team should be up to you. If you are sharing responsibilities with more teams, then you should build your way of working together with the other teams. Never work in isolation if you share responsibilities.

In order to do that you need to figure out what steering need so you can provide that. Usually this is the holy trinity of time, money and quality. Time and money comes through time reporting and proper estimations. Quality comes from requirements and testing alongside prioritization. So no matter what flavor you choose you need the following:

• A handover of translated need - you need to understand what the need is so you can take ownership.
• A Prioritization meeting - to decide what to do next.
• A common practice to make estimations - learn to make proper estimations instead of "guesstimations".
• Log time at least once per day if you have time estimates.
• Break down tasks as small as possible and close as soon as they are done if using story points.

That is usually all you need, regardless of flavor.

So go out and make whatever flavor you prefer KING today.

View full article

In the case for Agile 2 the statement is that one of the issues with the original is that it lack the inclusion of leadership. I agree with that as well as to note that the developers do not always enjoy what is referred as Agile in many organizations. The fracture of the Agile community and then the stagnation into a fixed perception almost to the point of worship also resonate with me.

Quote

Large organizations that tried to use Agile – the word quickly became a noun – often failed. This was no surprise because early Agile was about individual teams, but a large organization is far more complex than a single team. Everyone expected that over time, consensus would emerge for how to use Agile methods at scale, but instead, the community continued to splinter. Today, organizations that want to use Agile methods at scale are stuck choosing one of several competing and divergent approaches.

This is by far the most common experience for me when meeting with organizations. A will to move towards Agile, but a methodology that is fixed in its ways and lack the component of leadership and steering. I also find the interpretation of Agile to be heavily reduced when facing the opposition of reality, leading to an ad hoc situation that is damaging and frustrating to the people involved.

At first glance Agile 2 seem to be on the right track. I look forward to seeing where this will go and how it will challenge today's Agile community. Hopefully the Agile community will adopt their own methodology and embrace this new input to evolve their way of working.

I support the work of Agile 2 and I hope you do too.

Agile 2 – THE NEXT ITERATION OF AGILE

AGILE2.NET

---

THE NEXT ITERATION OF AGILE

View full article

Few lift an eyebrow at the mention that someone is in a project for as low as 20% these days. Sadly no one really bat an eyelash when a coworker break down mentally and get sick from the mental stress either. In my line of work as an IT consultant I often see people splitting their time and I see what it cost those persons as well as the projects they are doing their best to contribute to.

Not to long ago I witnessed a co-worker taking a seat after lunch looking pale. A faded smile and assurance that he would join soon and just needed a moment to himself was followed by an ambulance taking him to the hospital. It took him a year to come back to work. More than once have I seen people pass out in a meeting and outbursts of anger and frustration for small things happen on a regular basis by even the most gentle and kind persons.

What could possibly cause such extreme amounts of stress? The answer is that all of these people have suffered from extreme forms of content switching. As a human we need time to focus in order to make rational decisions. As the time to focus is interrupted we experience content switching. That is that moment when you are forced to go from one focused thought to another. This change of focus comes at a cost of mental energy and eveyone need a different amount of time to make the switch mentally.

As a manager you do this a lot as part of your work. That mental flexibility and speed that you have as a manager serve you well to manage most situations. That is because the content switching is still within one context. When you need to split your attention on multiple context however the cost will increase exponentially and with time, you will build up negative stress. If you do not reduce that stress it will eventually cause physical harm and you will hit that famous wall head first.

Other fields in IT have the same situation, but there is one group that suffer from this more than any other group: the developers. Developers unlike most other groups are focused oriented, mening that they spend more time in their own minds setting up structures and logical flows that create the code they write. Once interrupted it takes far longer to get back to their focused state of mind. Fortunately developers are less likely to work on multiple projects at the same time, but when they do the damage is more severe than for other groups. Designers have a similar situation, but have an easier time to make the mental switch.

How to mitigate and avoid getting burned out

Speed is everything, or so they make you think. Meeting after meeting where you jump from onte topic to the next in frantic speed. As you solve issue after issue with your quick and skilled mind you will experience a sense of accomplishment. This is because your brain reward you for it and it becomes an addiction. Soon you will crave it and like a junkie you will crave your fix even when you are off work. Eventually the rewards will not measure up with the cost and you will get frustrated and eventually have problem being happy. A sense of feeling empty and caught in a endless loop is your last warning before you bend the knee to the mental exhaustion and collapse.

The price you pay fror strecthing yourself thin benefit no one as you break down. There are things you can do however to prevent this. Both as regular practices, but also as strategies and rules you set for yourself.

Managers, Requirements & Business people

• Make time for focused work - As a manager or if you work in the Business area the biggest danger is having long periods without proper focus. Meetings and workshops take up much of your time, so make sure you dedicate at least 1 hour every day for focused work (no, not during lunch...). This is a time where you take time to be fully alone without distractions to focus on emails, power points and whatever else you have promised to do. This will naturally lower your stress levels and allow you a form of soft reboot. If this does not work, then dedicate a longer period 1-2 days a week. This can be that you work from home one day once a week or two half days for example.
   
• Turn off at the end of the day - The most common mistake managers do is that they never stop working. My suggestion is that you leave the computer at work if you can, or leave it in the bag when you get home. The same goes for the phone. make sure it is turned off as soon as you leave work, or at least as soon as you get home. If you are required to be reached every hour of they day, then you are constantly on stand by and never relaxed. Not only is this bad for your health, it is actually a legal issue as well in many countries as you are working over time. Stop doing that today!
   
• Say no or delegate - If you get asked to split your attention between multiple areas or you feel that thet area you are in charge of is becoming difficult to manage within your normal working hours, then you should say no or delegate.  Saying no is always difficult since most managers are driven by status or to help others. It s however a very useful skill to master and it will save you a lot of stress. Just make sure you say no for the right reason and not to avoid stepping out of your comfort zone, because that is actually a good thing.
  
  This is very hard in some cultures and if you feel that this is impossible, then find a way within the situation you find yourself. A trick that you can try is to promote people that work for you or offer to teach someone what you do. Just make sure you make sure the person you delegate to also have their regular workload reduced or you will burn them out instead.
   
• Never try to lead someone that is not fully commited - Having people in your team that split their time is a cause for much frustration. No matter how much time they dedicate to your project you will never get that time because of the cost of content switching. You will also find the moments when they are not working on your project, no matter how rare they are, to be annoying and inconvenient. My advice is to never try to lead anyone who is not fully commited to your project because of this.

Developers & Designers

• Never split your work - There are times when you might be asked to split your work and my advice to you is to say no. No matter what split you have you will never be able to dedicate 100% time between the two. Each split will cost you a lot of time just for switching between them and the mental toll will be far worse then you think. If you split yourself 50/50 you will do 40% in each project and you will work 120%. You will constantly feel stressed and that you do not do the work you are supposed to. It will eventually break you down mentally so never accept a split work situation.
   
• Avoid meetings if you can - Some meetings you need to attend, but try to avoid meetings that are not necessary. The reason is that a meeting, even if it is just 30 minutes long, will completely content switch you from your work. Unlike a short interruption that cost around 10-15 minutes of lost time a meeting will cost at least double that. Some meetings may be even more disruptive causing fragmentaion of thought for hours afterwards as you try to focus on work, but have the new information or task in mind as well.
   
• Take time to clarify things - The biggest issue for most developers and designers is unclear requirements and unclear expectations. If you take time to clarify things, then you will save a lot of time. That is because not only will you wate time trying to find answers, you also suffer from content switching. This can make a simple question cost hours of focused work. Everyone have different need when it comes to clarity so do not rush sprint startups, requirement sessions or technical architect forums. Make sure everyone in the team understand what to do and why. This way you can focus on working without having to find answers or explain things to other members of your team.
   
• Agree on work environments - All teams have different compositions. Some need a lot fo focus, others less. Make sure you define wht your team needs and agree on how you will work. I have had teams that work with the hand so they just put up the hand to let you know they are busy. This way you can signal that the person have to come back later as you are deep into something right now. If that is still to disruptive then use a hat or something that indicate this before you even approach teh developer. In some cases it can be a good idea to assign a team lead or project manager to handle all outside requests to further reduce disruptions. Whatever your team need, make sure it is defined and agreed upon by everyone.

Test

• Insert yourself into the information flow - As testers it is sometimes difficult to know what is going on. This is because testers can be seen as an external part of the development flow. This usually means test comes in long after requirements and development planning, which is not only stupid from a quality perspective, it is also cause for frustration and stress. As testers you should sign off on all requirements and you need to be on top of development and deploys. So if you are not included in the information flows you need to be in, then make sure that you are. This way you do not need to run around looking for information or work within an isolated workflow. If you do not, then you will constantly feel stressed and frustrated.
   
• Agree on bug flow with developers - As testers you should not sit and verify browser compability or standard flows. These should already be well tested by the developers. If this is not the case then you will feel that you are just writing bugs all days and no development ever get past test. This is a bad situation and you should make sure there is a proper definition of done that prevent this.
  
  When you find a bug you often want to discuss this with a developer. Doing so is disruptive however and I suggest that you set aside two slots every day where you can go over the defects with the team when it does the least damage. This can be done directly after the daily standup and directly after lunch as that is also when many teams collaborate on code reviews and so on. Just agree with the developers when and how you will go over the defects to ensure the impact is as small as possible.

These are just a few small tips on how to reduce stress and what the cost is for stretching yourself thin by splitting your attention between multiple projects. Most of these may be most relevant to a certain group, but most of them are valid for all groups. Content switching and bad work processes cost billions every day and they cause health issues that should not be underestimated.

Stress related illness is increasing and in many fields you can name at least one or two persons that you work with that have suffered from being burned out. In Japan there is even a specific word for working yourself to death: Karoshi. So be wary of the many ways that you can harm yourself unintentionally. One good start to protect yourself is to never accept working on multiple projects at the same time.

If you have more tips, please share to help others avoid getting burned out.

View full article

It is with a sad smile that I see the complete hysteria from middle and upper management when it comes to working from remote. It is as if the last 20 years of advancement in that area never actually reached this group. Their futile need for control and the withdrawal symptoms from not getting your daily meeting "fix" is in my eyes nothing new, but it becomes so very obvious in times of crisis.

We see large organizations cutting away their workforce and while they try to trim away across the organization it is pretty obvious that it is people who are close to the consumers that suffer the most. Stores, restaurants, hotels and travel are all sadly on the brink of extinction. On the technical side of things we see less work as well, but not because the work is no longer needed, but because investments are more careful when the cash flow is less stable.

We see an upswing for collaboration tools such as Miro and Trello while at least my daily feed is filled to the brink of articles on how to remain productive from remote. Most articles are so basic that I have to wonder who they are written for as most development teams have this as part of their daily work. Things like "focus on direct calls instead of chat" and "make sure your team know how to reach you" is utterly ridiculous however and in many articles I feel like I am being patronized and addressed like a five year old.

Working from home is not something that should be strange or confusing in 2020. If you do not have work processes that work for that, then I would argue that you have been neglecting to evolve as an organization for a long time. To be a manager that are having problems functioning within a remote teamwork environment is not only a liability in this crisis, but for the foreseeable future. If you are having issues with that now, then I suggest you start looking into improving that right now. It is a skill that you must have in this day and age.

The silver lining with this situation however is that many organizations now are forced to transform. We see it already that some larger organizations are reducing the middle management section for faster communication and more direct management. Meetings are heavily reduced, which is because many meetings at middle management levels are just to transfer information. In a remote workforce that is wasteful, so sharing information are done more efficiently.

We also see how badly communication between business, IT and Operations are working. I don't think I have seen this many articles about DevOps or Incident Management in the last decade. I have seen a big upswing in Quality Assurance discussions, especially surrounding requirements and facilitating workshop on remote. Portfolio management is on the rise and I get more questions about Portfolio for Jira, BigPicture and Structure than I think I have ever had. Clearly people are in need of ways to get an overview of the work to satisfy their need for control.

It is also interesting that I have not seen a single request for Jira Align...

While business and management are in a bit of panic mode at the moment I see the opposite in the development and test areas. People are working well from home and I see productivity is skyrocketing. The pressure on management is increasing to get better requirements and improve communication, but as long as the development teams get the information they need, then they are golden it seems. I hear people are less stressed, better focused and I even hear that things like system stability and technical debt is getting a bit of focus lately.

I hope that this crisis can lead to some change in management in the long run. Having more time to actually think and being forced to learn how to communicate more efficiently should benefit management greatly. Having the tools and processes to work from remote is a good way to future proof your organization. I also hope more managers will realize that working from home does not make you less productive. In fact it will greatly benefit some groups that not only can get more focused, but also can work when they are most productive.

If you are a manager that are struggling with remote teamwork, then don't chase articles that give you platitudes and nonsense advice. Talk to your development teams instead. They most likely already have this in place for working from home or to collaborate with other teams or offshore. Take this opportunity to slow down, process the information and then communicate it clearly instead of just running all the time. If you lack the tools or infrastructure to work efficiently on remote, then invest in it now. It is a good investment, not just for a crisis like the current one, but also for meeting the future demands of the employees.

Embrace Remote Teamwork, just like the rest of us did back in 2005. 😉

DISCUSS REMOTE TEAMWORK IN THE FORUM

View full article

This is the Remote Teamwork thread, so share your best suggestions and tips here.