Tag Archives: Business

How To Stay Compliant Using Agile

November 26, 2019 Mishkin Berteig 1 Comment

Compliance is a necessary cost that businesses have to accept. After all, it is meant for the good of your business as well as your stakeholders. However, one aspect that makes most startups and established enterprises fear compliance is the price tag it comes with. Even worse, businesses need to comply with more than one regulation, not to mention their own internal policies.

While you will still have to pay the cost of compliance and use the ad hoc resources, the method by which you approach compliance will have a significant role to play on the quality of compliance as well as the cost. Unlike the conventional waterfall approach towards compliance, agile compliance completely revolutionizes how organizations can meet regulatory requirements. Which begs the question, why should you consider agile compliance?

Here is why you should consider agile compliance and the best to approach it:

The Shortcomings Of The Waterfall Approach

At its core, the waterfall approach is a sequential one, whereby compliance projects or tasks need to follow a specific order, often taking more time than necessary to achieve compliance. When using this approach, the intricate compliance details are defined and committed to upfront, even before businesses can identify the real behavior of their systems. This sequential approach is defined by large batches of work, late feedback schedules, and long cycles in between the integration points of the various systems. In most cases, compliance activities might have to be deferred until the projects’ end, creating bottlenecks when it comes to providing insights into the compliance progress.

This method can neither scale nor keep up with the rigid time-to-market demands. For businesses that follow this method, the chances are that you will have significant compliance challenges, experience disappointing outcomes, miss deadlines, and often end up with poor quality projects. Also, compliance risk management is not always at the core of the waterfall approach.

Why Agile Compliance Is An Optimal Solution

Agile compliance approaches ensure incremental quality throughout the development of a project, from the onset to the end. Throughout this process, the necessary compliance activities are added into the mix, making compliance an in-built aspect of product development instead of an afterthought. In the agile approach to compliance, there is a high degree of collaboration, meaning that stakeholders, let alone employees, can voice their opinions on the development of the various tasks. This not only ensures that projects can be designed with the end-user in mind, but it also increases stakeholders’ trust in the development cycle, especially when it comes to ensuring compliance.

Also, the fact that customers and other stakeholders are involved in the development process enhances transparency. They can learn more about how features are prioritized and also be part of the review process. Making changes to the different aspects of development, including compliance, is also quite straightforward, as the method allows teams to refine the quality of a project in real-time continually. This increases the effectiveness in which the development team can use up resources since quality is a priority, and tests are done regularly. Lastly, an agile approach to development reduces the amount of time between the onset of a project to its end.

How To Implement Agile Compliance And Development

Understand The Regulatory Landscape

Before you start any product development, you need to understand the compliance landscape. Ideally, you should know the number of regulations that you need to follow and the nitty-gritty details of how to be compliant. Remember, regulations change from time to time, which is why you need to continuously monitor your compliance landscape for any changes you need to implement.

Enhancing Collaboration Between Teams

For agile compliance to be successful, business leaders need to identify the stakeholders whose input will be necessary during the project. Ideally, they need to work with professionals in the operational, legal, compliance, audit, and risk management departments in collaboration to meet demand. You should consider working with applications that can help to improve communication and enhance collaboration.

As for communication, development teams need to consult the key project stakeholders in good time. They should make the best use of key stakeholders’ time by ensuring that they have done the necessary research and provided the necessary questions for easier communication. The best practices of communication are essential to ensure alignment between operational units and development teams.

Ensure Easy Document Traceability

Without a healthy record of compliance requirements, it can be pretty easy for business units to miss the necessary compliance needs. Even worse, audits will take longer, if any happens, eating into the operational time of your business. Take time to improve the storage and traceability of compliance documentation. Also, ensure that there is enough communication and collaboration between the different business units to ensure that new regulations are followed and any new product releases follow the compliance requirements.

Build A Common Compliance Requirement Repository

The Equifax data breach taught businesses the need to train stakeholders on the need for compliance. Even with a high level of training, however, stakeholders often need a point of reference when indulging in common business operations to ensure that the business remains compliant. Sadly, siloed compliance requirements repositories work against this.Ideally, you should form common repositories that every stakeholder can refer to when the need arises. It should include compliance details such as rules on data confidentiality, authentication, data availability, security, access, logging, and even auditability.

Automating The Compliance Process

Manual compliance is time-consuming and labor-intensive. Even worse, the chances of committing errors throughout a project are quite high. With automation, IT and development teams can increase the speed and quality of a project. At the same time, they can ensure that all the compliance needs are attended to in good time. Also, this will ensure consistency in terms of the outcome of every project as well as eliminate the chances of costly errors occurring. When it comes to testing the projects, it is easier to identify errors and make the ad hoc changes.

The agile approach to compliance is a sure way to mitigate the risk of non-compliance. However, success trickles down to the nitty-gritty details of how you proceed with it. Consider the tips above to improve your business posture compliance wise.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile coaching, coaching, culture, focus

The Perils of Meeting-Driven Culture

June 24, 2019 Mishkin Berteig Leave a comment

Does your organization have a meeting-driven culture? Not sure? Ask yourself how much time you spend in meetings. Are they effective? Search the Internet and you’ll discover that we spend way more time in meetings than we’re comfortable admitting. The Harvard Business Review claims that the figure has doubled in the last 50 years.

The designers of Scrum recognized this and deliberately kept the formal meetings to the bare minimum. It adds up to around 12-15% if you use the entire time box. Contrast this amount to many organizations and you will discover that Scrum is quite efficient.

Many organizations I’ve consulted for don’t have deliberate rules on how to conduct meetings. They’ve allowed the meeting culture to evolve on its own. As such, meetings are not very productive.

However, practising Scrum doesn’t automatically make you immune to this meeting burden. Teams still operate within the same office and with the same people. Scrum and Scrum Masters can help teams have better meetings.

Here is a typical example of the transition from meeting-driven culture. I was coaching a Scrum team and worked in the team room alongside the development team. On several occasions (over several weeks) I asked the team to review the product backlog and make estimates. They brushed it off and refused to do this work. Instead, they did this at Sprint planning, despite complaining that it made the session long and exhausting.

I wondered if the ‘familiarity’ of the team room discussions made the backlog work appear less important. So I created a meeting outside the team room and sent an invitation via Outlook. Everyone accepted.

I kept the meeting as a regular occurrence, and the backlog review work got done ahead of Sprint planning. The team was much happier.

Why did this work? It succeeded because the organization had a meeting-driven culture—that is, planned events sent a signal that important work requires a meeting. The extra meeting clearly wasn’t necessary, but it succeeded.

This exercise helped me realize that organizations have so many meetings because they have few ways to engage.

Many office cultures don’t promote face-to-face meetings. Could it be the desk arrangement? They don’t value the serendipity of impromptu meetings. In the absence of frequent, short, high-quality meetings, people are forced to meet in rooms away from their desks.

If you see this meeting-driven culture in your organization, it’s likely an expression of what it values. Improving it will require discussions on what you value more. Shall we plan a meeting?

When I train Agile classes (Scrum, Kanban), I ask the attendees to make a list of activities that they can start right after the class. Number one on that list is co-location. That is, move your team to the same space so that they are sitting beside each other.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, coaching, culture, Kanban, Professional Development

Towards a Culture of Leadership: 10 Things Real Leaders Do (and So Can You)

August 29, 2018 Mishkin Berteig Leave a comment

This article is adapted from a session proposal to Toronto Agile Conference 2018.

Leadership occurs as conscious choice carried out as actions.

Everyone has the ability to carry out acts leadership. Therefore, everyone is a potential leader.

For leadership to be appropriate and effective, acts of leadership need to be tuned to the receptivity of those whose behaviour the aspiring leader seeks to influence. Tuning leadership requires the ability to perceive and discern meaningful signals from people and, more importantly, the system and environment in which they work.

As leaders, the choices we make and the actions we carry out are organic with our environment. That is, leaders are influenced by their environments (often in ways that are not easily perceived), and on the other hand influence their environments in ways that can have a powerful impact on business performance, organizational structures and the well-being of people. Leaders who are conscious of this bidirectional dynamic can greatly improve their ability to sense and respond to the needs of their customers, their organizations and the people with whom they interact in their work. The following list is one way of describing the set of capabilities that such leaders can develop over time.

Create Identity: Real leaders understand that identity rules. They work with the reality that “Who?” comes first (“Who are we?”), then “Why?” (“Why do we do what we do?”).
Focus on Customers: Real leaders help everyone in their organization focus on understanding and fulfilling the needs of customers. This is, ultimately, how “Why?” is answered.
Cultivate a Service Orientation: Real leaders design and evolve transparent systems for serving the needs of customers. A leader’s effectiveness in this dimension can be gauged both by the degree of customer satisfaction with deliverables and to the extent which those working in the system are able to self-organize around the work.
Limit Work-In-Progress: Real leaders know the limits of the capacity of systems and never allow them to become overburdened. They understand that overburdened systems also mean overburdened people and dissatisfied customers.
Manage Flow: Real leaders leverage transparency and sustainability to manage the flow of customer-recognizable value through the stages of knowledge discovery of their services. The services facilitated by such leaders is populated with work items whose value is easily recognizable by its customers and the delivery capability of the service is timely and predictable (trustworthy).
Let People Self-Organize: As per #3 above, when people doing the work of providing value to customers can be observed as self-organizing, this is a strong indication that there is a real leader doing actions 1-5 (above).
Measure the Fitness of Services (Never People): Real leaders never measure the performance of people, whether individuals, teams or any other organization structure. Rather, real leaders, practicing actions 1-6 (above) understand that the only true metrics are those that provide signals about customers’ purposes and the fitness of services for such purposes. Performance evaluation of people is a management disease that real leaders avoid like the plague.
Foster a Culture of Learning: Once a real leader has established all of the above, people involved in the work no longer need be concerned with “safe boundaries”. They understand the nature of the enterprise and the risks it takes in order to pursue certain rewards. With this understanding and the transparency and clear limits of the system in which they work, they are able to take initiative, run experiments and carry out their own acts of leadership for the benefit of customers, the organization and the people working in it. Fear of failure finds no place in environments cultivated by real leaders. Rather, systematic cycles of learning take shape in which all can participate and contribute. Feedback loop cadences enable organic organizational structures to evolve naturally towards continuous improvement of fitness for purpose.
Encourage Others to Act as Leaders: Perhaps the highest degree of leadership is when other people working with the “real leader” begin to emerge as real leaders themselves. At this level, it can be said that the culture of learning has naturally evolved into a culture of leadership.
Stay Humble: Real leaders never think that they have it all figured out or that they have reached some higher state of consciousness that somehow makes them superior to others in any way. They are open and receptive to the contributions of others and always seek ways to improve themselves. Such humility also protects them from the inevitable manipulations of charlatans who will, form time to time, present them with mechanical formulas, magic potions, palm readings and crystal ball predictions. Real leaders keep both feet on the ground and are not susceptible to the stroking of their egos.

If you live in Toronto, and you would like to join a group of people who are thinking together about these ideas, please feel welcome to join the KanbanTO Meetup.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Miscellaneous, Uncategorized

Selling Organizational Transformation – Part II

June 27, 2018 Mishkin Berteig Leave a comment

In Part I, I highlighted the basic importance of proper preparation in anticipation of an impromptu CxO meeting. The aim, of course, is to move up the organizational structure to the decision-makers who are most likely to require a greater portfolio of my services. My background is rooted in helping organizations achieve business agility so that they can better provide services that their customers desire.

If we pick up from the end of Part I, let’s assume I’ve piqued Sarah’s interest. There is a very strong possibility now that CEO Sarah will have an unscheduled, casual ‘elevator’ discussion with Christine about her efforts and perhaps even the work she’s contracting me for.

VP’s, like other Executives, hate surprises. Not knowing their relationship, there is a high probability that things will go south at this point, largely because I’ve potentially introduced risk to Christine and her career. The probability that something is going slightly ‘wrong’ in her portfolio is likely high. And she’s now on the CEO’s radar.

Next steps are obvious – it is imperative for me to speak with Christine, preferably face-to-face. Positioning the conversation is key now. In my experience, this is a “build trust” or “destroy trust” conversation. Prior to that face-to-face, I need to prioritize my talking points, which should be as follows:

Confirm the positive impact my team is having with respect to the organizational goals “to drive effectiveness and efficiencies”. Collect the “Yes”.
Determine the relationship, if any, she has with her CEO and determine the hierarchy between her and the CEO and, if possible, determine the alignment of their efforts to the CEO’s mandate (there is always a ‘black sheep’ in that mix and it could be Christine’s SVP, or even Christine herself, for instance)
Reduce the perceived risk by specifically reiterating the connection between my efforts, Christine’s efforts, and the corporate strategy. Collect the “Yes”.
Then, and only then, discuss the brief, impromptu elevator discussion I had with her CEO – and this takes tact and professionalism, and must be delivered with maturity.

My approach and the questions I’d propose, likely would take the following direction:

“Christine, what’s your overall ‘take’ on my teams efforts to….? [reiterate the mandate]”.
“Does your SVP share those thoughts, and is your leadership in the corporate strategy recognized?”
“And are your successes recognized outside of this channel?” [collect the “Yes”]
“Christine, you understand the corporate structure here, is there any risk that this project can be derailed, and is it important enough to thrive? Because, I am speaking in hypotheticals right now, but it has to look good for you, correct?” [collect the “Yes”]
[This is the tricky part] “Christine, you know part of my role is to champion you, your team and your efforts [insert mandate]. I wanted to meet today because I had the unplanned opportunity to speak briefly with Sarah about this particular project and she was quite keen about the positive work you are doing here. And specifically how it is in-step with the corporate mandate and her strategy. She was fully supportive of such efforts and I wanted to put this on your radar, should the conversation come back to you [pause].
“The other part of my job, of course, is to look for additional ways that we can help this organization. If I can help you, help your SVP and help Sarah in this process, then I’d like the opportunity to take a greater role and do so [stop].

I’m not going to walk away with a multi-million dollar contract today, but hopefully I achieved my objectives: clear the potential minefield of risk with Christine, deepen our relationship, gain further understanding of the organizational structure, continue to build trust, show that I am indeed talking with her peers and that I have the best intentions in doing so with her in mind, and I asked for further business.

In sales, we are always looking for that “inside champion” to help our deal move forward. In addition to this, I believe that in building better business relationships, the road goes both ways. I try to equally be that champion for my client. Because it serves so many purposes to do so, and it is the right thing to do as it aligns to the deeper principles I believe in, which are:

To create unity in diversity, and to help people orient their work lives towards service. To engage with people, and customer-focused organizations that seek to continually learn and grow. To work in the spirit of truthfulness, teamwork, and transparency, as this is the foundation of improvement.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Kanban, Scrum Master, Uncategorized

Slaying Hydra: The Story of A Business Agility Coaching Partnership

May 14, 2018 Mishkin Berteig Leave a comment

Part I of III

Summer 2014. The IT group of “Big Data Marketing” was in the full throws of an Agile transformation spearheaded by the new CTO. I was brought in as a Scrum Coach. My initial objective was to launch a couple of Scrum teams and serve as their Scrum Master. Around the same time, the firm’s head of PMO had been re-assigned as the Agile Practices Lead (APL) and he and I began working together on supporting the new Scrum Master community of practice, populated by his new reports. Our work gradually evolved into much more than what either of us could have imagined at the time. This 3-part series is my first attempt at putting down the story of that partnership.

In addition to serving as the initial Scrum Master for some of the teams, I was also trying to help existing team members transition into the Scrum Master role. I wanted to develop internal capacity so that I could focus on supporting a growing program of multiple teams. As the number of Scrum Masters and teams I was supporting increased, so too did the need for collaboration with the APL.

At the time, senior IT leadership was focussed on getting those doing the work of creating value (the teams) to fundamentally change the way they were working. That is, into self-organizing teams with Scrum Masters as “servant-leaders”. This included the reassignment of project managers as Scrum Masters and business analysts as Product Owners and staff into cross-siloed teams.

Chaos and confusion ensued. It was a deliberate strategy of senior leadership: Disrupt the culture of complacency. Force people to transform by throwing them into chaos. Throw everyone into the deep end and the right people will learn to swim.

A great deal of pressure was placed on the Scrum Masters to measure and improve team performance (based on pseudo-metrics such as story point velocity). They were essentially told to create a new identity for themselves and this was painful. Similarly, the APL was on the hook to support all these people in their new roles – to be a “servant-leader of the servant-leaders”. This concept of servant-leadership was front and centre in the conversation: “What is it, and how do we make it work here?” My role was to help create a shared understanding of the desired new culture.

I discovered months later that the day after I started the engagement, around 50 people had been fired. This had nothing to do with me, but naturally people thought that it did. Even years later, this day was commonly referred to by the survivors as “Bloody Monday”. Because of the timing of the mass-exit, unprecedented in the company’s 25-year history, staff understandably regarded me as the consultant who advised the cull. It’s not exaggerating to say that it instilled terror, was emotionally coupled with the transformation as a whole and implicated me as an individual. I thought of myself as one contributing help, but I was regarded as one contributing to harm. I saw myself as a Hippocrates but I was known as a Procrustes. I only learned about this months later, after I had finally managed to cultivate a bond of trust with some folks. A consequence of this fear was that I found myself in many one-on-one sessions with new Scrum Masters who were struggling to adapt and afraid of being the next victim to lose their jobs. Rather than providing Scrum Master therapy, I should have been helping the company to improve its delivery capabilities.

The theme of this first stage was the deep, broad and painful disruption of people’s lives caused by this deep Satir J-curve transformation model deployed by senior management. What I didn’t fully appreciate at the time is that emotionally, people experience change the same way they experience pain. The human brain literally responds the same. Not only were these human beings experiencing deep, chaotic change, they were also experiencing deep pain. And I was complicit in this.

The other contract coaches and I attempted to bring the crisis to the attention of senior management. We believed that it was a leadership problem, they believed that it was a staff complacency problem. The standoff lead to the coaches losing access to the leaders we were trying to help. This was a deep crisis for the group of coaches and the staff. The staff were beginning to see us as their advocates and we failed. For many Agile coaches, their part in the story ends here. In fact, some of the coaches on our team soon decided to move on to other opportunities. Others were not asked to extend their services beyond their initial contract term. Fortunately for me, the story didn’t end here. I will share more about this in Parts II & III of this series.

A teaser: These days, I advise and coach senior management to take responsibility to deliver services to customers, to understand what makes their services fit for the purposes of their customers and to design and evolve service delivery systems the fitness criteria of which are transparent to all those involved in the work. Then, allow people to truly self-organize around how the work gets done. In other words, manage the work not the people.

To be continued…

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Miscellaneous, Uncategorized

Selling Organizational Transformation (Part I)

May 8, 2018 Mishkin Berteig Leave a comment

Perhaps the most difficult sales effort is the one where you need to move beyond the level you’ve fixed yourself in. The focus of this article is to look at one way to mature a relationship beyond the initial landing to where real traction occurs and where you could really sell effective transformational change in the organization. For example, you’ve landed a small deal somewhere in the junior corporate strata, say at the ‘Team’ level, and you’re now seeking to expand. The problem is you are stuck at that level and you may have pigeonholed yourself with that small deal. And now you face the real risk of losing out on larger opportunities – opportunities perhaps where you can help drive real business agility.

To further complicate matters, it is very rare that your customer will ever fully tell you exactly what is going on in an organization. And that can be for a number of reasons. And in my recent 24 years of sales efforts, the reasons are virtually endless.

However I have found there is one common tactic that works towards the successful expansion of your valued services within an organization, especially if the level you initially land on is junior.

To demonstrate, I’d like to look at what actually happens, in my experience, with the typical sales process. Personally, I love having my Senior Consultants helping medium and large enterprises achieve real business agility. It’s the difference, in my opinion, between ‘doing Agile’ and ‘being Agile’, so I have been quite keen on developing ways to drive towards this outcome.

True story (and all names are pseudonyms): I reached out to a colleague who introduced me to his friend in the IT side of a large bank. Purposefully I did not use a PowerPoint or give a presentation. Instead, we talked about his industry, his competitors, the future, and where the real change needed to happen in order to meet that future. As a salesperson, my feet are on the street, and I was able to discuss trends, customers, potential pitfalls and potential opportunities.

I was able to do this (hint) because I studied his industry – hard – before the meeting. I looked at the changes in associated industries, and the implications that might have on his industry. And the implications if his company initiates a strategy to meet those challenges, and the implications if they don’t make that effort. We discussed the impact on different generations, for example how Boomers consume services differently than Millennials do, and why.

Asking really good questions in such meetings can be difficult, if you are not prepared. So do your homework. I was able to secure a small deal at the ‘Team’ level based on the combination of what I’ve described above.

But still, even as the work started, I wasn’t getting the audience to discuss their larger organizational initiative, and that is really where I wanted to play.

In this same scenario, I found out that a new CEO had taken up the helm at this bank. Where did that CEO come from? What challenges were faced and overcome at their previous positions (aka, why did this bank hire her?). New CEO’s tend to ‘shake things up’, and given that, where do you think the first mandate will be directed? What is the lowest performing division or operations in that bank?

Look at the stock market, the Quarterly and Annual Reports. Look for clues. I found that the CEO stated that “it is a new era to find Efficiencies and Effectiveness” in a public announcement. I just discovered their organizational initiative.

Next step was to structure all meetings at that bank to sell that same message. If you’re not selling the same message, then you are not aligned to that strategy. And you will never get above that junior level you wish to move beyond. Of course, if you cannot deliver efficiencies and effectiveness, move onto a different client. But this happens to be completely aligned to what we at BERTEIG do, so it’s gold.

And use social media. What has that CEO written/published? How many followers does she have? Which symposiums has she attended or spoken at?

I found one of her Sr. Executives had traveled to the States for a conference. I found that out through Facebook. If you can suspend the ‘creep factor’, I was looking at his profile and I noticed that 50% of his friends were co-workers of a former 3-letter acronym company. And he published a photo of the road sign naming the city where the conference was held. Research showed there were 4 conferences in that city. Three were local in focus, but one was on Big Data and Analytics. LinkedIn told me that the Sr. Executive is in charge of End-User adoption (i.e. Customer focused).

It doesn’t take a leap of faith to figure out that the Sr. Executive is most likely looking at options to obtain and manage customer information in order to better support their customer, and to tailor future offerings to that customer. That’s a lot of data that has to be managed, and managed well. (I urge you to think like his customer when doing this research.)

Knowing that alone gives you something to talk about when you meet an Executive in an elevator – and you will get that opportunity.

But don’t stop there. Who spoke at the conference? Do a search. In my case I found out that the Sr. Executive who attended, had a former co-worker speaking on behalf of that 3 letter company. I downloaded his Big Data presentation. Since the two of them worked together, which is the most likely company to get invited in to do Big Data work at the bank? And if I went into a meeting with a negative view of that acronym company, how would that help my chances with the Sr. Executive, considering his friends are employed by it?

This is not a negative. You now know who your competition is. Do your research. That competition is really, really good at Executive-to-Executive pairing, but their delivery is known as being a bit ‘thin’. That’s your entry point. Don’t fight the battle on grounds you cannot possible win on.

You’ve done the bare minimum of research so far that if you were in an elevator and that new CEO was standing there, you could strike up a meaningful conversation of value, without “going over the head” of your contact. But the conversation must have meaning, bring value, be customer focused, show that you know her industry, and it must be aligned to her mandate.

I got that elevator opportunity, because I wasn’t sitting at my desk. “Sarah Jameson, I am Mark Kalyta, congratulations on your new role. I’m working with Christine Smith, your VP who is over in IT. We’re providing some consulting (don’t sell the ‘training’ for example, unless you want to pigeon hole yourself again) to help her team bring ‘efficiency and effectiveness’ to her vertical, and we are having some early measurable success”. Pause.

Note, you’ve just reiterated her mandate, you indirectly informed her that her message is reaching her VP’s, and ‘Christine Smith’ is actioning the CEO mandate by hiring you, and you are applying measurements that show your group is helping her team. In this case, I wasn’t able to insert my knowledge around their Big Data efforts, however I wasn’t worried, and I could play that card later.

So I started with a small bit of work in a junior team with no access to Christine Smith, the VP. LinkedIn research found a connection in the chain from my junior person up to the CEO, and identified Christine as my project owner, and the CEO as owning the mandate.

Back to Sarah Jameson. “Sarah, my challenge is that the work over there represents 5% of what my organization is really good at, and that is helping organizations at the Leadership level find those efficiencies and drive effectiveness (see what I parroted there?) so that your ‘customer’ sees the value and benefits from it” (and there). “We are doing great work with Christine, and early measurements show a 10% improvement in efficiency with her teams, and that is great for the overall effectiveness of your organization. I’d like to broaden that message across your Leadership team; is that something you can help me with or could delegate to me accordingly? Because I think we can duplicate this early success, if there is an appetite for it. How would you suggest I proceed?”

Now the above may seem sloppy, but there are key points that can be drawn from it. I am not going to get into all of them. You may fall flat on your face with this approach, and if so, that would be all about Sarah Jameson, and not about your skills. But you’ve hedged your bets.

Now, your next steps are clear. You need to advert the perceived “end-run”, and that requires a different strategy.

Read Part II to find out what comes next!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, Kanban, Uncategorized

Kanban: Real Scaled Agility for Your Enterprise

June 1, 2017 Mishkin Berteig 2 Comments

Your business is an ecosystem of interdependent services, a complex adaptive system.

A bunch of organizations I know started their journey of increasing their agility with Scrum. That didn’t solve all of their problems. Kanban enables organizations to evolve their service delivery systems towards mature business agility.

As addressed in How Kanban Saved Agile, pure Scrum is extremely rare. Scrumbut (the disparaging label that spawned from so many organizations reporting that they do Scrum, but…) on the other hand, is extremely common.

In order to not be Scrumbut, you need the following:

Cross-functional development team of 7 +/- 2 people—ALL skills needed to ship product is present on the team—there are no dependencies external to the team;
One source of demand with no capacity constraints—the Product Owner is the customer AND full-time member of the team;
Sprints are one month or less, begin with starting new demand from the Product Owner and end with the delivery of potentially shippable Product Increments, followed by a retrospective about how to do better next Sprint;
“Potentially Shippable” means that the decision about whether to actually ship is purely a business decision. All the technical work is done;
If all of the technical work required in order to ship isn’t done, then the Sprint is a failed Sprint;
The Scrum Master is a servant-leader and Scrum educator to the entire organization.

How many organizations do you know of with Scrum teams that meet all of the requirements above? I don’t know one.

So, what’s the solution? Give up on Scrum? Are we still getting benefits from Scrumbut? Alright, let’s stop it with the Scrumbut already. Let’s acknowledge what’s really going with real teams in the real world and call that Scrum. Let’s refer to the above checklist as “Ideal Scrum”.

Agile scaling methods have become a popular risk hedging tactic for all the loose ends dangling around the real teams in the real world.

Here are some of the reasons for adding layers of scaling around Agile teams:

Teams are not fully cross-functional;
Teams have external and opaque depencies;
Many of these dependencies are shared services with multiple sources of demand and constrained capacity—often overburdened;
External dependencies can be other teams—demand from other teams shows up in their backlogs, prioritized by their own Product Owners;
Many dependencies don’t play by the same rules at all—some reside in a different part of the organization, with different structures and political forces;
The Product Owners are proxies for multiple stakeholders and customers and the Product Backlogs represent an array of multiple sources of demand, with different service level expectations, strategic origins, degrees of clarity, urgency and political forces pushing them into the deliver organization;
The Product Backlogs are made up primarily of solutions defined by stakeholders and translated by the pseudo-Product Owners as pseudo-user stories—how they get there is opaque, the “fuzzy front end”—and somewhere in here a fuzzy delivery commitment was already made;
The work of a Sprint includes all of the work that the non-cross-functional teams can get done—then whatever the teams get “done” is “delivered” (handed-off) to a subsequent set of teams or process steps (usually fairly well defined at an organizational level but outside of the teams’ influence);
Delivery decisions are made based on constraints imposed by legacy technology, systems and their gatekeepers (for historically good reasons);
The teams are “done” at the end of each Sprint, yet much work is still to be done before their “done” work is potentially shippable;
The Scrum Master’s are held collectively accountable for the collective deliverables of the teams and their ability to cross-team coordinate and integrate—accountability by committee translates into no one is actually responsible.
Middle managers are scrambling to pick up the pieces because they are actually accountable for delivered results.

Generally speaking, the aim of Agile scaling methods is to apply larger Agile wrappers around clusters of Agile teams in order to re-establish some kind of hierarchical structure needed to manage the interdependencies described above. Whether its a Release Train or a Nexus, or whatever else, the idea is that there is an “Agile Team of Teams” managing the interdependencies of multiple, smaller teams. As long as the total number of people doesn’t grow beyond the Dunbar number (~150), the Dunbar-sized group is dedicated and cross-functional, there is a team managing the interdependencies within the Dunbar, there are no dependencies outside of the Dunbar and there is some cadence (1-3 months) of integrated delivery—it’s still “Agile”. All of this scaling out as far as a Dunbar (and only that far) allows the enterprise to still “be Agile”—Scaled Agile.

This is all supposed to be somehow more realistic than Ideal Scrum (with perhaps am overlay of Scrum of Scrums and a Scrum of Scrum of Scrums). It’s not. How many organizations do you know of that can afford to have ~150 people 100% dedicated to a single product? Perhaps today there is enough cash lying around, but soon enough the economic impact will be untenable, if not unsustainable.

How does Kanban address this problem? Your business is a complex adaptive system. You introduce a Kanban system into it such that it is likely that the complex adaptive system is stimulated to improve. The Systems Thinking Approach to Introducing Kanban—STATIK—is how you can make such a transition more successful (@az1):

Understand the purpose of the system—explicitly identify the services you provide, to whom you provide them and why;
Understand the things about the delivery of the service that people are not happy about today—both those whose needs are addressed by the service and those doing the work of delivering the service;
Define the sources of demand—what your customers care about and why;
Describe the capability of your system to satisfy these demands;
Map the workflow of items of customer-recognizable value (@fer_cuenca), beginning with a known customer need and ending with the need being met through stages of primary knowledge discovery (Scrum teams somewhere in the middle, towards the end)—focus on activities, not looping value streams;
Discover classes of service—there are patterns to how different kinds of work flow through your system (they are not arbitrarily decided by pseudo-Product Owners), what are they? Group them, they are classes of service and knowing them enables powerful risk management;
With all of the above as an input, design the Kanban system for the service;
Learn how to do steps 2-7 and start applying it directly to your own context in a Kanban System Design class;
Socialize and rollout (learn how by participating in a Kanban Coaching Professional Masterclass);
Implement feedback-loop Cadences for continuous evolution—learn the 7 Kanban Cadences and begin applying to your own context in a Kanban Management Professional class;
Repeat with all of the interdependent services in your organization—every “dependency” is a service—Kanban all of them with STATIK and begin implementing the Cadences.

Don’t get hung up on teams, roles, your latest reorg, how people will
respond to another “change”, who’s in, who’s out, etc. These are all part of the service as it is now—your current capability. Initially, no changes are required at this level. The kanban system will operate at a higher level of scale. Through feedback-loop cadences, it will evolve to be fit for the purpose of your customers without a traumatic and expensive reorg. Who is responsible for this? Identify this person. If you are the one thinking about this problem, there is a good chance that it’s you. Whoever it is, this is the manager of the service; take responsibility, do the work and make life better for everyone.

For more information about LeanKanban University Certified Kanban courses provided by Berteig, please go to www.worldmindware.com/kanban. Some spots are still available for our classes in Toronto, June 12-16.

For Agilists who have read this far and still don’t get it, start here:

14 Things Every Agilist Should Know About Kanban

The story below may be familiar to some:

Our IT group started with Scrum. Scores of people got trained. Most of our Project Managers became “Certified” Scrum Masters. Most of our Business Analysts became “Certified” Product Owners. We purged some people who we knew would never make the transition. We reorganized everyone else into cross-functional teams – mostly developers and testers. But now they are Scrum Developers. We tried to send them for “Certified” Scrum Developer training but hardly anyone of them signed up. So they are Just Scrum Developers. But we still call them developers and testers. Because that’s still how they mostly function—silos within “cross functional teams”, many tales of two cities rather than just one.

After the Scrum teams had been up and running for a while and we were able to establish some metrics to show the business how Agile we were (since they didn’t believe us based on business results), we had a really great dashboard showing us how many Scrum teams we had, how many Kanban teams, how many DevOps, how many people had been trained. We even knew the average story point velocity of each team.

The business didn’t get it. They were worried that Agile wasn’t going to solve their problem of making commitments to customers and looking bad because we still weren’t able to deliver “on time”.

As IT leadership, we were really in the hot seat. We started to talk about why the transformation wasn’t going as it should. We knew better than to bring the Agile coaches into the boardroom. They were part of the problem and needed to be kept at arms length from those of us who were making important decisions. Besides, their Zen talk about “why?” was really getting old fast. Some thought it was because we didn’t have the right technology. Others were convinced it was because we didn’t have the right people. After all, we didn’t go out and higher experienced (above-average) Scrum Masters and Product Owners, instead we just retrained our own people. Clearly that wasn’t working.

We started with improving the Scrum Masters. We went out and hired a few with impressive resumes. We developed some Scrum Master KPIs (HR jumped all over this one). Then one day we had a collective flash of brilliance—since the ScrumMasters are the servant leaders of teams, we will make them responsible for collecting and reporting team metrics and this will tell us how well the teams are doing and how they need to improve. This surely would be the key to improving the performance of IT and get us on a better footing with the business.

But we didn’t get the response we were hoping for. The ScrumMasters soon complained that the metrics of the teams were impacted by dependencies that they had no influence over. When we pushed harder and shamed them publicly for failing to produce meaningful metrics, they tried harder, but they weren’t able to do it. Some began disengage. “This is not the job I signed up for” became their new mantra. This was puzzling. We were empowering them and they were recoiling. Maybe we didn’t get the right Scrum Masters after all. Maybe we needed to go out and find people who could think and act effectively beyond the confines of their own teams. Or…

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Kanban, Professional Development

Learning About Kanban

April 3, 2017 Mishkin Berteig Leave a comment

From Essential Kanban Condensed by David J Anderson & Andy Carmichael

“Kanban is a method for defining, managing, and improving services that deliver knowledge work, such as professional services, creative endeavors, and the design of both physical and software products. It may be characterized as a “start from what you do now” method—a catalyst for rapid and focused change within organizations—that reduces resistance to beneficial change in line with the organization’s goals.

The Kanban Method is based on making visible what is otherwise intangible knowledge work, to ensure that the service works on the right amount of work—work that is requested and needed by the customer and that the service has the capability to deliver. To do this, we use a kanban system—a delivery flow system that limits the amount of work in progress (WiP) by using visual signals.

http://leankanban.com/wpcontent/uploads/2016/06/Essential-Kanban-Condensed.pdf

I’ve been reading the above book on Kanban (the alternative path to agility) to familiarize myself with the method before taking the Kanban course by Accredited Kanban Trainer Travis Birch.

Two points from my learning are the principles of “Change Management” and “Service Delivery.”

Kanban regards “Change Management” as an incremental, evolutionary process as Kanban is utilized. For example, Kanban starts “with what you do now.” A business agrees to pursue improvement through evolutionary change, which happens over a period of time, based on experience and understanding. If one is using Kanban for the first time, there may be some awkwardness at the beginning, with a number of people trying to understand the principles, and how the visual board works. As the work goes on, understanding is increased, and with the new learning, change occurs in a very organic way. Acts of leadership are encouraged at every level. Changes can occur in all sectors: within individuals, within the environment, and in the cumulative outcomes of the work.

“Service Delivery” in Kanban requires that there is an understanding of and focus on the customer’s needs and expectations. The work is managed by people self-organizing around the work, and by the limiting of work-in-progress (WIP). This can help people feel that they have the right amount of work to accomplish with the right amount of time. WIP limits are policies that need to be made explicit in order to establish flow. The work on the board is “pulled” into the in-progress section only as people become available to do the work. An employee can focus on bringing higher quality to the work, and not feel threatened by a backlog that is crushing them. Policies are evolved to improve outcomes for the customers.

Of the nine values outlined in Kanban, three are directly related to change management and service delivery. The first is “respect;” by limiting the work-in-progress, respect is shown for the employee’s time and efforts, along with respect for the customer’s expectations. “Flow” refers to there being an ordered and timely movement to the work being done that is not overwhelming. “Transparency” occurs because everything is visible on the Kanban board and it becomes clear what is being done, when and by whom.

It’s been proposed that Scrum is for teams and Kanban is for services. In that way, they are both essential to the improvement of many organizations, especially those in which pure Scrum is not enough. They are complimentary from the perspective of improving business.

If you’re interested in the training with Travis Birch, AKT, go to:(http://www.worldmindware.com/TeamKanbanPractitioner).

“Kanban has principles and general practices, but these must be applied in context, where different details will emerge as we pursue the common agendas of sustainability, service-orientation, and survivability. As a result, the journey is an adventure into unknown territory rather than a march over familiar ground” (from Essential Kanban Condensed)

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management

5 Insights to Help HR Ride the Agile Wave

March 14, 2017 Mishkin Berteig 4 Comments

In a recent scan of the e-literature on the reciprocal impact of Agile on HR, I connected some very interesting insights which I’d like to share. A set of insights that looks like ripples across the surface of a pond. Ripples that started when the Agile stone was thrown into the pond in 2001. In its simplest form, Agile is about a different way of working with each other in teams. Teams that are cross-functional, collaborative, co-located and customer-driven in their decision making. The insights provide compelling reasons why HR needs to take an active role in Agile implementations.

Insight #1

“In the most successful Agile transformations, HR is a driver of the change and a key hub that steers other departments’ success.”

(cPrime.com)

HR certainly needs to be ‘a’ driver in the change, but not ‘the’ (sole) driver. Rather they need to partner in the change. Successful Agile transformations will benefit from HR’s expertise in

Organizational Effectiveness
Learning & Development
Workforce Planning & Talent Management
Total Rewards

The driver of the change, historically IT, will need HR’s help to manage the impact to people and traditional HR processes/tools. As the change scales and starts to impact other departments in the business, HR can play a large role in ensuring the business overall stays aligned in delivering end-to-end value to customers.

Insight #2

“2016 will be the year of Agile HR… most HR teams have no clue what Agile HR means.”

(HR Trend Institute)

Agile was a hot topic for HR in 2016 as evidenced by the number of times ‘Agile HR’ has made the shortlist of topics being brainstormed for HR conferences and networks. It was the #1 trend on the 2016 HR Trend Institute list. Its popularity is not cooling off in 2017. And yet most HR teams still don’t have a clue what ‘Agile’ means, never mind what ‘Agile HR’ means.

Insight #3

“As the world becomes more volatile, organizations need to find ways to become highly agile. HR will need to support a world where people may no longer have predefined ‘jobs’ that lock them into doing one activity.”

(HRO Today)

Agile has entered the mainstream. A necessity given the VUCA[1] world we live in. Agile is no longer the sole domain of IT. The common refrain from all C-suite leaders these days is increased agility and nimbleness across the entire business – not just IT. The impact of capital ‘A’ Agile or small ‘a’ agile will affect HR. People will no longer have predefined jobs – People’s career paths will change. In this VUCA world, standardized career paths are no longer effective. Batch-of-one career paths will become the norm.

Insight #4

“HR’s job is not just to implement controls and standards, and drive execution—but rather to facilitate and improve organizational agility.”

(Josh Bersin)

The HR profession itself has been going through its own transformation. The HR profession has evolved from an administrative and transactional service to a strategic business stakeholder with a seat at the executive table. The role of HR now includes a focus on organization-wide agility and global optimization of departmental efforts.

Insight #5

“Human capital issues are the #1 challenge for CEOs globally.”

(The Conference Board CEO Challenge 2016)

The Conference Board’s 2016 survey of global CEOs ranked human capital issues as the number one challenge. It has been number one for the last four years in a row. Within that challenge, there are two hot-button issues:

Attracting and retaining top talent
Developing next-generation leaders

The adoption of agile ways of working will change

How we recruit and engage
How we nurture and grow not only our leaders but our talent in general

In the words of Robert Ployhart, “…employees don’t just implement the strategy – they are the strategy”[2]. CEOs around the world would tend to agree.

The net of these insights is the more HR professionals understand Agile and its implications, the more effective Agile or agile initiatives and people/strategy will be.

I’d like to see HR ride the wave.

[1] VUCA is an acronym introduced by the US military to describe a state of increased Volatility, Uncertainty, Complexity and Ambiguity

[2] Ulrich, Dave, William A. Schiemann, Libby Sartain, Amy Schabacker Dufain, and Jorge Jauregui Morales. “The Reluctant HR Champion?” The Rise of HR: Wisdom from 73 Thought Leaders. Alexandria, VA: HR Certification Institute, 2015. N. pag. Print.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Case Studies

How a Non-Agile Big Corporation Lost Out

February 8, 2017 Mishkin Berteig 4 Comments

The Scenario

In a search for new vistas and growth, my husband had been scanning employment ads across the country and applied for a job he was well-suited for with a large corporation. He received two interviews by telephone and SKYPE. The new job would require us to move several provinces, leaving family, friends and a community we were attached to.

He received confirmation by telephone that the corporation wanted to hire him. We spent a few days agonizing over a decision, consulting with family and friends, praying about it, and decided my husband would accept the job. After his verbal acceptance, a contract followed a few days later, which he duly signed and sent back. He was told it had been signed at the other end and he could now announce the new job publicly.

He gave notice to his present employers, as did I mine, and we proceeded to take steps to put our house on the market, search for housing in the new city, and pack. We had begun to say good-bye.

Three days later a phone call came from the HR Department of the corporation saying they had to rescind the contract as someone “higher up” had not given approval for it.

We were stunned. There had been no hint in any part of the process that the job offer was in any way tentative or not thoroughly vetted. We had taken many steps forward, and now had to backtrack several steps.

My husband had to go, hat in hand, to his current employers to see if he could retain his job. After a painful good-bye session with my team I had to inform them that I was not leaving.

This whole experience has brought to mind the importance of what my employer, BERTEIG Inc, is attempting to do through agile training, consulting and coaching.

The “Agile Manifesto” proclaims:

“Individuals and interactions over processes and tools.”

And, further on: “Customer collaboration over contract negotiation.”

These are prime values to be lived by small and large businesses.

Admittedly, Agile was initially created for software developers, but more and more corporations and organizations are seeing the value in being agile, and are responding to this necessary change of culture in what is currently a time of deep disruption.

What If?

What if the corporation my husband was contracting with had honored the implications of “individuals and interactions over processes and tools” and “customer collaboration over contract negotiations?”

If some “higher up” had not actually given approval for this hiring, once the contract was signed at both ends (which it was), could this higher-up not have responded with more agility, more compassion, and more ethically?

What if he had acted in such a way that, even if he did not approve the contract, he acknowledged the good intentions of both sides and let it go? After all, his corporation was getting a highly-qualified, experienced employee.

What if he was transparent and acknowledged that the contract was not to his liking, and asked would my husband consider some other version of it? And then consulted directly with my husband and HR over certain changes to the contract? And made sure everyone was agreeable with the changes?

What if the “higher-up” just called my husband directly, apologizing that the contract was made without his say-so, that they were not in a position to hire him, and offered two-months salary for any damages – material and emotional – that had been incurred?

The above scenarios could have changed the situation from one of loss, to one of win-win for both sides. Agile frameworks are clearly proving to be of great benefit to employers and employees alike.

Hundreds of eager attendees take Certified Scrum Master and Certified Product Owner training from us. Many have taken our Certified Agile Leadership offering in cooperation with Agilitrix. Do the corporations they belong to welcome the changes these attendees are prepared to make? Are corporations taking steps to truly alter their culture?

The Losing End

My husband was almost employed in that organization, where hundreds of others are employed. I wonder how often their employees experience this type of trauma, since this neglectful handling of my husband’s contract is a likely sign of ongoing cultural problems within.

This rescinding of a contract was a losing situation on both ends. The corporation in question lost a highly-talented employee who would have been extremely loyal and hard-working (as was determined in the interviews). My husband lost professional credibility having to backtrack with his current employers. We lost the challenge of a new adventure.

We’re recovering, despite this having a huge emotional impact on our lives. We’ve been agile enough to say: we’re still here, we still have jobs, we can make the best of it all.

I just wish that Big Corp would get it. And soon. Before more is lost.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Kanban, Theory of Agile

How Kanban Saved Agile

January 31, 2017 Mishkin Berteig 6 Comments

In reality, Kanban isn’t actually saving Agile nor is it intended to, nor is any thoughtful and responsible Kanban practitioner motivated by this agenda. What I’m really trying to convey is how human thinking about the business of professional services (including software development) has evolved since “Agile” as many of us know it was conceived around 20 or so years ago. The manifesto is the collective statement of a group of software development thought leaders that captured some of their ideas at the time about how the software industry needed to improve. Essentially, it was about the iterative and incremental delivery of high-quality software products. For 2001, this was pretty heady stuff. You could even say that it spawned a movement.

Since the publication of the manifesto in 2001, a lot of other people have had a lot of other good ideas about how the business of delivering professional services can improve. This has been well documented in well known sources too numerous to mention for the scope of this article.

Substantial contributions to the discourse have been generated by and through the LeanKanban community. The aim of Kanban is to foster environments in which knowledge workers can thrive and create innovative, valuable and viable solutions for improving the world. Kanban has three agendas: survivability (primarily but not exclusively for the business executives), service-orientation (primarily but not exclusively for managers) and sustainability (primarily but not exclusively for knowledge workers). Kanban provides pragmatic, actionable, evidence-based guidance for improving along these three agendas.

Evolutionary Theory is one of the key conceptual underpinnings of the Kanban Method, most notably the dynamic of punctuated equilibrium. Evolution is natural, perpetual and fundamental to life. Long periods of equilibrium are punctuated by relatively short periods of “transformation”—apparent total and irreversible change. An extinction event is a kind of punctuation, so too is the rapid explosion of new forms. Evolutionary theory is not only a scientifically proven body of knowledge for understanding the nature of life. It can be also applied to the way we think about ideas, methods and movements.

For example, science has more or less established that the extinction of the dinosaurs, triggered by a meteor impact and subsequent dramatic atmospheric and climate change, was in fact a key punctuation point in the evolution of birds. In other words, dinosaurs didn’t become extinct, rather they evolved into birds. That is, something along the lines of the small dinosaurs with large feathers hanging around after Armageddon learned to fly over generations in order to escape predators, find food and raise their young. Dinosaurs evolved into birds. Birds saved the dinosaurs.

There has been a lot of social media chatter and buzz lately about how Agile is dead. It is a movement that has run its course, or so the narrative goes. After all, 20 years is more or less the established pattern for the rise and fall of management fads. But too much emphasis on the rise and fall of fads can blind us to larger, broader (deeper) over-arching trends.

The agile movement historically has been about high-performing teams. More recently, market demand has lead to the profusion of “scaling” approaches and frameworks. Scaling emerged out of the reality of systemic interdependence in which most Agile teams find themselves. Most agile teams are responsible for aspects of workflows—stages of value creation—as contributors to the delivery of a service or multiple services. Agile teams capable of independently taking requests directly from and delivering directly to customers are extremely rare. For the rest, classical Agile or Scrum is not enough. The feathers just aren’t big enough. Agile teams attempting to function independently (pure Scrum) in an interdependent environment are vulnerable to the antibodies of the system, especially when such interdependencies are merely denounced as impediments to agility.

Some organizations find themselves in a state of evolutionary punctuation (the proverbial sky is falling) that can trigger rapid adaptations and the emergence of local conditions in which independent service delivery teams can thrive. Most large, established organizations seem to be more or less in a state of equilibrium. Whether real or imagined, this is what change agents have to work with. However, more often than not, the typical Agile change agent seems adamant that the sky is always falling and that everyone accepting that the sky is falling is the first step to real and meaningful change. This is not an attitude held by Agile change agents alone. This is a standard feature of traditional 20th Century change management methods, the key selling point for change management consulting.

Naturally, most self-identifying “Agilists” see themselves as change agents. Many of them find themselves in the position of change management consultants. But the motivation for change can quickly become misaligned: Change needs to happen in order for Agile to work. If you are passionate about Agile, you will seek to bring about the environmental changes that will allow for Agile to thrive. We don’t need to follow this path too far until Agile becomes an end in itself. It is understandable then that for some, Agile appears to be a dead end, or just dead.

But if there is a larger, over-arching historical process playing out, what might that be? Perhaps it has something to do with the evolution of human organization. Perhaps we are living in a period of punctuation.

For my working definition of Kanban, please refer to my previous article 14 Things Every Agilist Should Know About Kanban (this contains links to the Kanban body of knowledge, including Essential Kanban Condensed by David J. Anderson and Andy Carmichael).

For my working definition of Agile, please refer to The Manifesto for Agile Software Development.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, Announcements

Certified LeSS Practitioner with Craig Larman

March 29, 2016 Mishkin Berteig Leave a comment

In just a few weeks we will be hosting Craig Larman here in Toronto as he facilitates the first-ever-in-Canada Certified Large Scale Scrum Practitioner training! Large Scale Scrum (LeSS) is about de-scaling. In simple terms, this is about using Scrum to make the best possible use of the creativity, problem-solving and innovation abilities of large numbers of people, rather than getting them stuck in bureaucracy and management overhead.

Here are the details of this unique learning event:

Date and Time: April 11-13 (3 Days), 2016 – 9am to 6pm all three days
Location: Courtyard by Marriott Downtown Toronto, 475 Yonge St. Phone: 416-924-0611
Price: $3990.00 / person (that’s in Canadian Dollars – super great deal if you are coming from the US!)

Check out the full agenda and register here.

Here are some quotes from previous attendees:

“It was inspiring to discuss Large-Scale Scrum with Craig Larman. The content of the course was top-notch.” – Steve Alexander

“The delivery was outstanding and the supporting material vast and detailed.” – Simone Zecchi

“The best course I have ever been on. Totally blown away.” – Simon Powers

Toronto is a great place to visit (I know many of our Dear Readers are from the United States) – don’t hesitate to consider coming in for a weekend as well as the course!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Professional Development, Scrum, XP and Lean, Theory of Agile

Refactoring: 4 Key Principles

March 24, 2016 Mishkin Berteig 4 Comments

I believe in refactoring. The Agile Manifesto holds that

The best architectures, requirements and designs emerge from self-organizing teams.

The quality of our software systems depends on refactoring. In fact, I believe that the only way that an organization can avoid refactoring is by going out of business. Maybe I should explain that.

Refactor or Die

Heart Monitor Flatline - Refactoring or Death Every software system that we build is inside a dynamic environment. The organization(s) using the software are all in a state of constant change. The people using the software are also constantly changing. Due to this constant change, every software system needs to be adapted to the environment in which it is used. Most of the time, businesses think of this constant change in terms of new features and enhancements – the scope of functionality that a system can handle. Less commonly, businesses think of this change in terms of the obvious external qualities and attributes of the system such as performance or security. But almost never does an organization, from a business perspective, think of the invisible qualities of the software system such as simplicity and technical excellence.

What happens when the business does not recognize those invisible qualities? I’m sure almost every software developer reading this can answer this question easily: the system becomes “crufty”, hard to maintain, bug-prone, costly to change, maze-like, complex. Some people refer to this as legacy code or technical debt.

The longer this state is allowed to continue, the more it costs to add new features – the stuff that the business really cares about. It is pretty easy to see how this works – for someone who has a technical background. But for those without a technical background it can be hard to understand. Here is a little analogy to help out.

Imagine that you set up a system for giving allowance to your kids. In this system, every week your kids have to fill out a simple form that has their name, the amount that they are requesting, and their signature. After a few weeks of doing this, you realize that it would be helpful to have the date on the form. You do this so that you can enter their allowance payments in your personal bookkeeping records. Then you decide that you need to add a spot for you to counter-sign so that the paper becomes a legal record of the allowance payment. Then your kids want extra allowance for a special outing. So you add some things on the form to allow them to make these special requests. Your accountant tells you that some portions of your kids allowance might be good to track for tax purposes. So, the form gets expanded to have fields for the several different possible uses that are beneficial to your taxes. Your form is getting quite complex by this point. Your kids start making other requests like to be paid by cheque or direct-deposit instead of in cash or to be paid advances against future allowances. Every new situation adds complexity to the form. The form expands over multiple pages. Filling out the form weekly starts to take significant time for each child and for you to review them. You realize that in numerous places on the form it would be more efficient to ask for information in a different way, but you’re not sure if it will have tax implications, so you decide not to make the changes… yet. You decide you need your own checklist to make sure that the forms are being filled out correctly. A new tax law means that you could claim some refunds if you have some additional information… and it can be applied retroactively, so you ask your kids to help transcribe all the old versions of the form into the latest version. It takes three days, and there is lots of guess-work. Your allowance tracking forms have become a bureaucratic nightmare.

The forms and their handling is what software developers have to deal with on a daily basis – and the business usually doesn’t give time to do that simplification step. The difference is that in software development there are tools, techniques and skills that allow your developers to maintain a system so that it doesn’t get into that nightmare state.

For a more in-deth description of this process of systems gradually becoming more and more difficult to improve, please see these two excellent articles by Kane Mar:

Technical Debt and Design Death

Technical Debt and Design Death: Part II

Ultimately, a software system can become so crufty that it costs more to add features than the business benefit of adding those features. If the business has the capacity, it is usually at this point that the business makes a hard decision: let’s re-write the system from scratch.

I used the word “decision” in that last sentence. What are the other options in that decision? Ignoring the problem might be okay for a while longer: if the company is still getting benefit from the operation of the system, then this can go on for quite a while. Throwing more bodies at the system can seem to help for a bit, but there are rapidly diminishing returns on that approach (see The Mythical Man-Month for details). At some point, however, another threshold is reached: the cost of maintaining the operation of the system grows to the point where it is more expensive than the operational value of the system. Again, the business can make a hard decision, but it is in a worse place to do so: to replace the system (either by re-writing or buying a packaged solution), but without the operating margin to fund the replacement.

In his articles, Kane Mar describes this like so:

It’s pretty clear that a company in this situation has some difficult decisions ahead. There may be some temporary solution that would allow [a company] to use the existing system while building a new product, [A company] may decide to borrow money to fund the rewrite, or [a company] may want to consider returning any remaining value to their shareholders.

In other words, refactor or die.

Refactoring and Business

Refactoring and Business Success - Growth Chart In the Scrum Master and Product Owner classes that we teach, this topic comes up frequently: how does the business account for refactoring? How do we “govern” it? How do we make good decisions about refactoring?

There are a few principles that are important in helping to answer these questions. All of these principles assume that we are talking about refactoring in an Agile team using a framework like Scrum, OpenAgile, or Kanban.

Refactoring Principle One: Keep It Small

Refactoring is safest and cheapest when it is done in many small increments rather than in large batches. The worst extreme is the complete system re-write refactoring. The best refactoring activities take seconds or minutes to execute. Small refactorings create a constant modest “overhead” in the work of the team. This overhead then becomes a natural part of the pace of the team.

Not all refactoring moves can be kept so small. For example, upgrading a component or module from a third party might show that your system has many dependencies on that module. In this case, efforts should be made to allow your system to use both the old and the new versions of the component simultaneously. This allows your system to be partially refactored. In other words, to break a large refactoring into many small refactorings. This, in turn, may force you to refactor your system to be more modular in its dependencies.

Another common problem with keeping refactorings small is the re-write problem. Your own system may have a major component that needs to be re-written. Again, finding creative technical means to allow for incremental refactoring of the component is crucial. This can often mean having temporary structures in your system to allow for the old and new parts to work harmoniously. One system that I was working on had to have two separate database platforms with some shared data in order to enable this “bi-modal” operation.

Refactoring Principle Two: Business Catalysts

When is the earliest that a refactoring should be done? Not whenever the technical team wants to do it. Instead, the technical team needs to use business requests as catalysts for refactoring. If the business needs a new feature, then refactoring should only be done on those parts of the system that are required to enable that feature. In other words, don’t refactor the whole user interface, just refactor the parts that relate to the specific business request.

Again, there can be exceptions to doing this… but only in the sense that some refactorings might be delayed until a later date. This is tricky: we want to make sure that we are not accumulating technical debt or creating legacy code. So, instead, we need to allow the technical team to refactor when they detect duplication. Duplication of code, data or structure in the system. A business request might impact a particular part of the system and the team sees how it might be necessary to refactor a large swath of the system as a result. But, the cost of doing so is not yet justified: the single request is not enough of a catalyst, and the team can also choose a simple temporary solution. Later, the business makes another request that also implies the same large refactoring. Now is the time to seriously consider it. It is now a question of duplication of another simple temporary solution. The business may not be happy with the extra expense of the large refactoring so the principle of keeping it small still applies. However, the technical team must also be willing to push back to the business under the right circumstances.

Refactoring Principle Three: Team Cohesion

Teamwork in Agile requires high levels of communication and collaboration. In refactoring work, teamwork applies just as much as in any other activity. Here, it is critical that all members of the team have a unified understanding of the principles and purpose of refactoring. But that is just the first level of team cohesion around refactoring.

The next level of team cohesion comes in the tools, techniques and practices that a team uses in refactoring. Examples include the unit testing frameworks, the mocking frameworks, the automation provided by development tools, continuous integration, and perhaps most importantly, the team working agreements about standard objectives of refactoring. This last idea is best expressed by the concept of refactoring to patterns.

The highest level of team cohesion in refactoring comes from collective code ownership and trust. Usually, this is built from practices such as pair programming or mob programming. These practices create deep levels of shared understanding among team members. This shared understanding leads to self-organizing behaviour in which team members make independent decisions that they know the other team members will support. It also impacts research and learning processes so that teams can do experiments and try alternatives quickly. All of which leads to the ability to do refactoring, large and small, quickly and without fear.

Refactoring Principle Four: Transparency

In many ways, this is the simplest refactoring principle: the team needs to be completely open and honest with all stakeholders about the cost of refactoring. This can be difficult at first. Another analogy helps to see the value of this. A surgeon does not hide the fact that care is put into creating a clean operating environment: washing hands, sterilizing instruments, wearing face masks and hair covers, restricted spaces, etc. In fact, all of those things contribute to the cost of surgery. A surgeon is a professional who has solid reasons for doing all those things and is open about the need for them. Likewise, software professionals need to be open about the costs of refactoring. This comes back to the main point of the first part of this article: hidden and deferred costs will still need to be paid… but with interest. Software professionals are up-front about the costs because doing so both minimizes the costs and gives stakeholders important information to make decisions.

The challenge for business stakeholders is to accept the costs. Respecting the team and trusting their decisions can sometimes be very hard. Teams sometimes make mistakes too, which complicates trust-building. The business stakeholders (for example, the Product Owner), must allow the team freedom to do refactoring. Ideally, it is continuous, small, and low-level. But once in a while, a team will have to do a large refactoring. How do you know if the cost is legitimate? Unfortunately, as a non-technical stakeholder, you can’t know with certainty. However, there are a few factors that can help you understand the cost and it’s legitimacy, namely, the principles that are described here.

If the refactoring is small, it is more likely to be legitimate.

If the refactoring is in response to a business catalyst, it is more likely to be legitimate.

If the refactoring is reflective of team cohesion, it is more likely to be legitimate.

And, of course, if the refactoring is made transparent, it is more likely to be legitimate.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Links to Agile Info, Miscellaneous

Asking for Free Work – Working on Spec

November 7, 2015 Mishkin Berteig Leave a comment

Great video shared by Robin Dymond:

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Agile Management, Reference Information, Theory of Agile

Agile Transformation Metrics

July 30, 2015 Mishkin Berteig Leave a comment

TL;DR

When asked to provide metrics to assess “how well” an Agile transformation is going, re-frame the discussion around measuring changes in the impact the IT organization is having (or not) on it’s Business environment, and define a small set of “fitness for purpose” metrics.

The Inevitable Question about Agile Transformation Metrics

Sooner or later, as an IT organization embarks on a transformation towards Agile mindset and practices, someone will be asked to provide “hard evidence” that the effort is paying off, and the conclusion will be that metrics is the vehicle to satisfy that request. What are your Agile transformation metrics?

It’s been my experience that this request usually leads to a discussion about measuring the specific Agile initiatives the IT organization has launched. In organizations where the emphasis has been around engineering disciplines, such metrics might be things like unit test code coverage, or integration build times. If the focus was around teams and process, then counting number of teams “converted” to Scrum, or people sent to Scrum Master training may appear as the choice.

While those measurement might be useful indicators in some context, they have two problems. First, they are akin to measuring the performance of the car engine without looking outside the window; the engine might be performing well, but if the car doesn’t have the wheels attached, we’re going nowhere. More importantly, though, these figures are usually meaningless for Business stakeholders, who are the ones usually asking for them in the first place. Agile transformation metrics need to be meaningful to the Business.

Re-framing the Agile Transformation Metrics Question

Agile transformation efforts can be very costly exercises, therefore it is legitimate to ask about the results of such endeavour. The important thing to realize, though, is that this question is really equivalent to another question: “is the IT organization improving its impact on its Business environment.” Another way to put it is, borrowing from the terminology used by the Kanban community: “is the IT organization becoming more and more fit for purpose?” Answering this question, of course, requires a clear understanding of what is that the Business expects from its interactions with IT.

The IT organization can be seen as providing various services to customers. Arguably, if IT has decided to “transform” in some way (perhaps by moving towards an Agile mindset), it’s doing so to improve its impact on those customers, so this is what needs to be measured to know “how the transformation” is going.

Some of those customers are different areas of the organization (like Finance, or HR.) But it doesn’t stop there, because the Business’ engagement with IT doesn’t have value for its own sake. Ultimately, the Business is using IT as a way to optimize its operations so that it can provide external customers with more effective products and services. Moreover, IT is these days the direct channel through which those products and services are delivered to external customers (for example, through web sites and mobile applications.) Therefore, the concept of “fitness for purpose” of the IT organization can be extended to consider the fitness for purpose of the Business respect the external customers it intends to serve.

Defining the “Agile” Transformation Metrics

Measuring “agile transformation success” really means measuring the success of the exchanges between IT and the Business, and between the Business and its external customers. Measuring the internal processes and practices that IT puts in place as part of that “transformation” is beside the point. This implies starting with a careful definition of the boundaries that delineate the exchanges to be measured. There might be more to external customer fitness for purpose than IT operations, for example, and that needs to be considered when defining Agile transformation metrics, especially if we’re later going to be drawing causation conclusions.

Defining Agile transformation metrics will be, of course, a highly contextual exercise because every business organization is different. But we can, however, draw again from the Kanban community for some general guidelines on what to look for. Their thought leaders talk about classifying metrics into 3 categories: fitness for purpose metrics, health indicators and improvement drivers. Using this framework, when talking about “agile transformation metrics” we are referring mainly to the first category, and perhaps a bit to the second. Based on those, improvement initiatives can be put in place, and perhaps driven with metrics belonging to the third category.

A fitness for purpose metric (also known as KPI) is an indicator of something a customer will care about. This is a key distinction: if the metric is not easily recognizable and meaningful for the customer, then it’s not a KPI. Another key characteristic is that a minimum threshold for its value can be defined: if the metric goes below the threshold, the Business is putting the relation with its customers at risk (perhaps they will walk away, initiate legal actions, etc.). In other words, the Business is no longer “fit for purpose”. We can then measure the effectiveness of the “agile transformation” by analyzing how KPI values over time compare to their respective thresholds. A typical KPI is delivery time, measured from the moment a customer request is accepted and committed to, until the moment it’s delivered to production. This is usually a good Agile transformation metric.

Health indicators are metrics that are inwards facing. Customers don’t really care about them (or even understand), but they indicate how a given aspect of the system is operating. The key characteristic is that they are not directly actionable; they only provide information that needs to be analyzed and put in context. As the value of a health indicator changes, we can draw some conclusions about how the system works, or explain why something is happening (or not), but it doesn’t necessarily leads to concrete action. Defect count is an example of this. Customers will certainly care about quality of the product, and we can make inferences about that quality by looking at how many defects we have, but the absolute number of defects will not necessarily make the product more or less fit for purpose. It may happen that customers consider the current quality to be “good enough”, irrespective of the number of defects.

Finally, improvement driver metrics are metrics put in place to influence behaviour towards a particular change. Their key characteristic is that they are temporary: we set a target on them and once the target is achieved, the metric is no longer necessary. The reason for this is related to the unintended behaviours that a metric might encourage in people, which may lead to locally optimizing the metric at the expense of other aspects, leading to global sub-optimization of the system. An example is unit testing code coverage: if we have determined that a given service is not fit for purpose and the cause is related to poor unit test coverage, then establishing a target for minimum coverage may influence developers to work on adding tests to reverse the situation.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Mar 31

2023

Details

Real Agility Management Track - Practitioner I (RA-MT-LA)

Online

C$7950.00

Apr 3

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 4

2023

Details

Advanced Certified ScrumMaster® (ACSM)

Online

C$1795.00

Apr 5

2023

Details

Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)

Online

C$1895.00

Apr 11

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 14

2023

Details

Win as a Manager with Your New Agile Coach: ChatGPT

Online

C$0.00

Apr 14

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 17

2023

Details

Kanban for Scrum Masters (ML-KSM)

Online

C$495.00

Apr 18

2023

Details

Kanban for Product Owners (ML-KPO)

Online

C$495.00

Apr 19

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 21

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 25

2023

Details

Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)

Online

C$1895.00

Apr 26

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Apr 28

2023

Details

Win as a Manager with Your New Agile Coach: ChatGPT

Online

C$0.00

Apr 28

2023

Details

Advanced Certified Scrum Product Owner® (ACSPO)

Online

C$1525.75

May 3

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

May 5

2023

Details

Kanban Systems Improvement® (KMPII)

Online

C$1610.75

May 10

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

May 12

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

May 12

2023

Details

Team Kanban Practitioner® (TKP)

Online

C$1100.75

May 16

2023

Details

Kanban for Scrum Masters (ML-KSM)

Online

C$495.00

May 16

2023

Details

Kanban for Product Owners (ML-KPO)

Online

C$495.00

May 17

2023

Details

Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)

Online

C$1610.75

May 17

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

May 19

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

May 19

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

May 26

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

May 26

2023

Details

Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)

Online

C$1610.75

Jun 7

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Jun 9

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

Jun 9

2023

Details

Kanban System Design® (KMPI)

Online

C$1610.75

Jun 13

2023

Details

Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)

Online

C$1610.75

Jun 14

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Jun 16

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

Jun 16

2023

Details

Kanban for Scrum Masters (ML-KSM)

Online

C$495.00

Jun 20

2023

Details

Kanban for Product Owners (ML-KPO)

Online

C$495.00

Jun 21

2023

Details

Team Kanban Practitioner® (TKP)

Online

C$1015.75

Jun 21

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Jun 23

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

Jun 23

2023

Details

Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)

Online

C$750.00

Jun 30

2023

Details

Real Agility™ Real Agility™ Ask Me Anything / Coaching

Online

C$750.00

Jun 30

2023

Details

Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)

Online

C$1610.75

Jul 5

2023

Details

Kanban Systems Improvement® (KMPII)

Online

C$1610.75

Jul 11

2023

Details

Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)

Online

C$1610.75

Jul 12

2023

Details

Team Kanban Practitioner® (TKP)

Online

C$1015.75

Jul 19

2023

Details

Team Kanban Practitioner® (TKP)

Online

C$1015.75

Aug 15

2023

Details

The Shortcomings Of The Waterfall Approach

Why Agile Compliance Is An Optimal Solution

How To Implement Agile Compliance And Development

Understand The Regulatory Landscape

Enhancing Collaboration Between Teams

Ensure Easy Document Traceability

Build A Common Compliance Requirement Repository

Automating The Compliance Process

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Part I of III

Affiliated Promotions:

Affiliated Promotions:

Your business is an ecosystem of interdependent services, a complex adaptive system.

In order to not be Scrumbut, you need the following:

Agile scaling methods have become a popular risk hedging tactic for all the loose ends dangling around the real teams in the real world.

The story below may be familiar to some:

Affiliated Promotions:

Affiliated Promotions:

Insight #1

Insight #2

Insight #3

Insight #4

Insight #5

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Affiliated Promotions:

Refactor or Die

Refactoring and Business

Refactoring Principle One: Keep It Small

Refactoring Principle Two: Business Catalysts

Refactoring Principle Three: Team Cohesion

Refactoring Principle Four: Transparency

Affiliated Promotions:

Affiliated Promotions:

The Inevitable Question about Agile Transformation Metrics

Re-framing the Agile Transformation Metrics Question

Defining the “Agile” Transformation Metrics

Affiliated Promotions:

Upcoming Courses