As a practitioner in the project, program & portfolio management space for many years now, I have seen different delivery approaches work for different organizations based on project characteristics and organizational needs. Each project need will have a spot on the continuum, from the predictive waterfall approach to an Agile approach.

Meanwhile most of the practitioners I interact with seem to have chosen a side – there are some strong believers of waterfall that stresses meticulous planning and a sequential delivery approach, while others are strong believers of less process heavy, iterative delivery approaches.

I, personally, beg to differ. I believe that both of these approaches have their own strengths and weakness and there can be successful co-existence between these methodologies. Being mostly surrounded by waterfall experts, I have seen a huge gap between traditional project management perspectives and the newer, more Agile approaches.

Most of these gaps stem from limited knowledge on the subject from the opposite side. Specifically, here are some key disconnects that I have encountered over the years

An Agile approach is the extreme opposite of Waterfall approach

Not true.

Even in the most Agile centric environment, many of the Waterfall project management principles are valid even if applied in a different context. These principles might not fall neatly into some of the typical knowledge areas of traditional approaches, such as scope, time and cost management – but there is still a need for striking the right balance between planning, control and agility. All project life cycles include a planning element. What differentiates the life cycle is how much planning is done and when.

For instance, risk management processes, in traditional waterfall project management, are implemented to control & monitor risks. An Agile approach, on the other hand, implements risk management in a broader sense by coaching team members to incorporate risk management principles into the way the work – thereby eliminating some of the risk monitoring aspects found in the waterfall approach. Both approaches have risk management aspects – it is just implemented differently.

Being Agile only impacts the IT departments

Again, not true.

Any methodology (Agile or Waterfall) requires organizational commitment which extends far beyond the IT or Project Management teams. Not to forget, it may require some major shifts in organizational culture to make it work. What makes any delivery approach successful for an organization is the commitment by the organization to make it successful.

It starts with deciding which methodology will be right for the organization; which one will support their current and future goals and which one can bring them closer to meeting their bottom line. It can very well be a hybrid between traditional and contemporary delivery approaches. What needs to follow is the commitment throughout the organization to change their old mindsets, processes & come onboard to support the change.

The point that I am trying to make here is that thinking of any delivery approach as being a silo to a particular department or team is incorrect. It is far broader than that.

You need to make a choice – Agile or Waterfall

Do we really have to? The idea that you either need to follow a methodology by the book – or not at all. is preposterous. The fact is, an organization can choose to design a delivery approach that creates a perfect marriage between plan driven approach and agility which aligns with the organization’s strategy.

Of course, certain changes would call for a traditional waterfall approach, for instance building a house, and some would call out for an Agile approach, for instance building an app to control the temperature of the house. The fact of the matter is that it doesn’t need to be as rigid as some practitioners perceive it to be. The right thing to do is to be focused on delivering a solution in the most efficient way possible rather than being solely hung up a particular methodology and its boundaries.

In conclusion, practitioners from both communities (traditional & Agile) are so focused on promoting the benefits of their own delivery stream that they tend to overlook the idea of co-existence. It doesn’t have to be a black-and-white proposition – it can very well be a mix of the two – you just need to strike the right balance.

I am a strong believer that there is no one right solution for everything and that a peaceful co-existence can exist amongst different perspectives.  I also believe that better solutions are yet to come, ones that are not constrained by current boundaries and that are focused on better supporting the diverse and ever-changing demands of the world we live in.

Affiliated Promotions:

The post Choosing the right approach for project delivery appeared first on Agile Advice.

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:

The post How To Stay Compliant Using Agile appeared first on Agile Advice.

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:

The post The Perils of Meeting-Driven Culture appeared first on Agile Advice.

Preamble

Is there such a thing as a perfect Scrum Master? Likely not, because of course we are all human and not perfect beings. However, we can make a case for skills that contribute to becoming a perfect Scrum Master.

In 2017, Ken Schwaber and Jeff Sutherland updated the Scrum Values document, and in a video that same year discussed the changes they were making. They talked at length about the Scrum Master role. To quote Ken Schwaber, “It’s a very tough job”.

The 2018 new Scrum Guide states:“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide”.

In short, the Scrum Master (SM) serves the Product Owner, the Development Team, and the Organization. This involves facilitating Scrum events, coaching and educating, removing impediments, and much more. It is safe to say that successfully undertaking those relational interactions requires good people-oriented behaviours, or soft skills.

We may not normally think of Scrum Mastering in the same breath as soft skills, but a discussion lead me to consider this. A colleague stated that a good Scrum Master must understand 4 things: the business s/he works in, the technology s/he works with, Agile and Scrum principles, and, most importantly, people! Based on his experience, he was adamant that Scrum Master certification is not enough – that soft skills should be part and parcel of their training.

How can some of these soft skills be taught?

The Certified Scrum Master Training

The first thing a CST can do is model soft skills in his/her training class: treat all the attendees with respect, be clear about the goals of training, listen and be attentive to questions and concerns, create a safe learning environment, demonstrate honesty and trustworthiness. Modelling these behaviours is one way a CST can teach without words.

But in two days, is role-modelling enough? Let’s look at the Scrum Guide for clues. “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” http://www.scrumguides.org/scrum-guide

How much are these values discussed in training? What does “courage” or “openness” look like? In-depth discussion, with examples/activities of each of those values/ skills, could go a long way in teaching soft skills.

Scrum Masters can be guided through specific exercises that help them understand and practice the Scrum Values of courage, openness, respect, commitment, focus. As well, specialized skills can be taught, including leadership, negotiation, conflict resolution, compassion and more.

I recommend a video called “Agile and Scrum Soft Skills Needed to Drive Process Success” which provides helpful guidance:
https://www.youtube.com/watch?v=owa1fftIfzA&t=7s

9 Best Skills for the “Perfect” Scrum Master

After polling the readers of the REALagility Newsletter, I’ve put together this list of skills that many of us believe every Scrum Master should strive for:

1. Listening well – to your team, your organization and especially your stakeholders
2. Empathy, friendliness and respect – builds a collaborative culture
3. Trust – you do what you say, walk the talk, and create safety
4. Openness and transparency
5. Identify and help solve problems
6. Create a learning environment – for continuous learning and improvement
7. Show courage – remember Schwaber’s “It’s a very tough job!”
8. Support team, team members, PO and CEO! – why the CEO? S/he has to be on board with the changes and growth.
9. Be service-oriented/team-first attitude – it’s not about you; it’s about serving the people and the process. This is why Scrum Masters are often called “servant-leaders”.

Post Script

Additionally traits that readers added: “Altruistic”, “has humor/fun-loving”, “proactive”, “easy-going & strict”, “can cheat”!

Affiliated Promotions:

The post 9 Ways to Identify the “Perfect” Scrum Master appeared first on Agile Advice.

Becoming “Agile” is not about a tool, just like visualizing and building workflow isn’t about setting up a Kanban Board. Being “Agile” is about the people and their interactions.

I’ve seen this a number of times, where a client seeks a tool to become “more Agile”. Usually a Director or higher executive, spends money on training some or all of their staff, more often opting out of the training themselves. After a short period of time, they realize that the promise of better results isn’t looking promising. So they then seek additional funding, and invest in a tool with the promise that “this” will help their teams become “more Agile”.

It became quite clear that this was the case with this client, as their original request “to help our people become more agile”, suddenly changed to “help us use this tool”. As most people in this field understand, the first Value of the Agile Manifesto is to value “Individuals and Interactions Over Processes and Tools”.

I have that Value deeply embedded in my mind, as I’d had the fortune to work directly with two of the original twelve signatories of the Manifesto, and we often talked about the genesis of the Values. The creators of the Manifesto were people who had lived the mindset that this client presently maintains. Through similar experiences as my client, the Signatories began to foresee the pitfalls of the old mindset, and simply sought a better approach to become more agile.

So this particular client has the hallmark of having the old mindset. With great care, the Sales Engineer and I were able to demonstrate that the tool can support the interactions of their teams as they incrementally develop their products. And we would be happy to use the consulting dollars to look at their teams, leverage the training they already had, help visualize their workflow and ultimately help them understand that Agility comes from developing the Agile mindset.

By the end of the call, two of the three team members fully understood that they were perhaps going down the wrong road by placing the value of the tool over their people and the interactions of their teams. In this specific case, the third person had arrived to the meeting late, was the most senior person in the room, and in my belief, had missed information that might have also changed their perspective. It is impossible to know, but I strongly suspect that none of the three were in a political position to change course. Whether they had directly invested in the tool or not, is immaterial.

The agreement is now on hold, and that is probably the best thing for our client-vendor relationship in the long-term. We could have provided training on the tool and taken their money, but that would be unethical. As an Agile consultant-salesperson, and all of us here at Berteig, we deeply understand the nuances of the Manifesto, and as such, we need to sell and deliver what is right for the client.

For now, the personal and financial investment they made with respects to the tool will need to be seen through. Which I respect, for all the business, political and personal reasons. There is a high likelihood that their original request will resurface in a number of months. Obtaining “agility” is a journey and often takes such time.

Affiliated Promotions:

The post Selling What Is “Right” appeared first on Agile Advice.

Affiliated Promotions:

The post Should the AGILE MANIFESTO Require Certification – Before All Others? appeared first on Agile Advice.

My first question is always this: How much does the customer pay for tests?

Nothing.

That’s right! Not a dime. I don’t even ship my product to them with any tests. They aren’t even compiled into bytecode for them. They are not going to pick up my application and open a debugger to make sure I’ve written tests that pass. They don’t care how many tests I’ve written or my code coverage ratio. They don’t care about unit, integration and acceptance tests, or how much time I spent on mocking and stubbing to isolate my functions. They only pay for working software.

So why write them?

I don’t write tests for the user. I don’t write tests for management. I write tests for me. I write tests for my future self. I write tests for my team members and any other developer that will need to change my code.

I write tests to prove that what I have written is what I have intended. I write tests to make my code manageable, to help me refactor when, inevitably, a new feature or change request arrives. I write tests so that I can fearlessly alter a system and know what I will break, and to find and repair bugs quickly before they are pushed into production.

I write tests so that my team members can feel a sense of code ownership, so that they too can alter, improve and remove my code and be able to predict the outcome. I write tests so that it becomes a form of documentation of the capability of the system.

Certainly they take time to write, but they save all kinds of time when it comes to changing things later. They allow me to do the one thing that software needs to do in the rapidly evolving market: adapt. I can adapt quickly to the needs of my customers to deliver quality features rapidly.

I write as many tests to make myself and my team feel confident that we can continuously develop a quality product at a sustainable pace, responding to the changes of the market and the needs of our customers. I write enough tests that I am releasing nearly bug-free code and I write as many tests as needed to satisfy just that!

In my Agile Software Developer training events, I help developers learn ways of writing tests to improve the quality of their work, so that they are able to spend more time developing new features rather than debugging old ones.

Affiliated Promotions:

The post Customers Don’t Pay Me to Write Tests: The Importance of Tests appeared first on Agile Advice.

Leadership, in the modern world, has been equated to a highly visible role, a spokesperson whose suave charisma is infectious, and following their mantra is made easy. No one can deny that they are not impressed when a sharply dressed leader bounds onto the stage at a conference and proceeds to use impressive statistics to back up his or her claims that ‘if we just did this, then the world would be a better place’.

Unfortunately, reality is rarely as static as those brief moments of exuberance. The truth is, companies have been built and shaped over many years, sometimes decades. The charismatic hand-gesturing of the modern world leader (especially in technology) does not go far in the grand scheme of things to change an approach that has been ingrained in us. Undoing bad habits and helping people build new habits is hard work.

What purpose then does Agile serve to help us with this task of getting better and why should you, as a leader, care?

Leadership implies leaving a legacy that was stronger than when you first started. The leadership you provide has to be ingrained within the culture of the organization you leave behind. In short, being Agile, thinking in an Agile way allows us to be transparent and honest, learning from our mistakes without fear of retribution and scorn. That in itself is a huge shift in the way we think.

One of the Agile Manifesto principles states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” While the concept is simple, it implies that you, as a leader, need to act in a supporting role. Encourage acts of leadership in others. Don’t focus on the mistakes. Create an environment where work, and even innovation, can happen!

“Culture eats strategy for breakfast”

There probably won’t be a defining moment in a successful project which someone can point to and say: that was the moment where you as a leader made all the difference in a project. But slowly, over several months of sustained support and Agile thinking, you will positively affect the culture of the organization. As the late management guru Peter Drucker said, “Culture eats strategy for breakfast”, implying that no amount of managing of people would be more positive than the intrinsic motivation people have to succeed in their work.

Kiichiro Toyoda, the founder and first president of The Toyota Motor Corporation, created and espoused the Toyota Production System (TPS). In this management philosophy (built from the Lean production perspective), he believed that because people operate the system, the strategy to success has to be a people-oriented system. TPS respects the fact that only the people on the production-line can make the changes necessary for improvement. This is where leadership should focus.

Moreover, the culture of excellence has to become ingrained in the line worker to the extent that ‘good enough’ is no longer a workable philosophy. So what can you do as a leader to make the change happen? The well-known thought leader in business-leadership, John Kotter, writes about the ways that change management can be ‘made-to-stick’. For this article, suffice to say that establishing a need and creating visibility are at the forefront of what he espouses.

Creating transparency allows us to understand the current situation. Only then can we begin to tackle the problems with a frank and consolidated effort. Mistakes will ensue; however in an environment of learning, where mistakes are opportunities for improvement, success will undoubtedly follow.

At BERTEIG, our coaching and consulting approach is to support leadership in this endeavour. Almost every great leader has had the support of a non-judgemental partner to help them achieve more, and we take your success as our success. We believe that the legacy of your company will therefore be in the Agile way that people work, not the antiquated legacy systems in place that hold you back.

Affiliated Promotions:

The post What leaders need to know about Agile appeared first on Agile Advice.

Many people I interact with seem to believe that Kanban is another Agile methodology for helping Agile teams manage their work. The aim of this post is to help people see how Kanban can be so much more.

I am aware that there are some who believe that a high performing, self-organizing, cross-functional Agile team is as good as it gets and that it is the job of Leadership to change the organization such that this kind of team becomes a reality. This is a belief that I also held for many years, during which time I actively advised my clients to pursue this lofty goal and I invested a great deal of time and effort towards helping them achieve it. I understand this belief. It is very powerful, so powerful that it shapes identity. Therefore, it was a big part of my own professional identity and this was not easy for me to change. I empathize with those who struggle in similar ways as I have.

I could go on with my personal story, but I’ll get back to my opening statement. Kanban is so much more than just another Agile methodology. So what does this mean? How can it be so?

In my own experience helping businesses improve for over a decade and from the many stories I’ve listened to of the people I’ve met in my consulting engagements, training classes, conferences and meetups, the ideal of fully cross-functional teams is not a reality, not even a feasible possibility for their organizations and this reality is causing them pain and harm.

Let’s be clear about what we mean by cross-functional teams: According to the Scrum Guide (paraphrasing), a cross-functional team is a team that possesses all the skills required for starting and delivering potentially releasable product increments in a Sprint. A Sprint is a complete project that must be completed in one month or less. Many organizations add to this the idea of establishing stable teams (membership does not change) and Sprints of 1-2 weeks in duration. For many organizations, integrating all of the above is simply not realistic.

Most people I meet who are working with Agile teams (mostly Scrum teams) have already done everything they can to create the conditions for their teams to realize this ideal. Teams are already as “Agile” as they can be under the current constraints. Leaders have already done everything in their power to remove the constraints.

Some would describe this as a “failed Agile transformation”. But it need not be so. Rather, I have begun to see it as a natural stage in some organizations’ maturation process. Perhaps at an organizational level it is analogous to the “Storming” stage of the Tuchman maturity model: “Forming”, “Storming”, “Norming” and “Performing”. Regardless of the best analogy, the important point is that an apparent failed transformation does not have to be a bad thing. It also doesn’t mean you need to start all over again (with another re-org) in the hopes that you will “get it right” the next time. Rather, it is a natural stage of organizational maturation and the frustration, pain and conflict you are experiencing are telling you that your organization has an opportunity to evolve.

Kanban helps organizations move beyond this difficult stage. The Kanban principles of service orientation and evolutionary change help organizations focus on improving survivability of the business and the sustainability of the work. All of the Kanban practices are evolutionary stimulants for whole-organization improvements and they all scale naturally to all levels of an organization.

Kanban can help Scrum teams. Kanban can help with project, program and product management. Kanban can help with portfolio and enterprise services planning and management. Finding ways to implement the practices, little by little, at all levels of your organization will enable your organization to become fitter for the purposes of your customers, fitter for survival.

The Kanban Method, as opposed to other approaches, has built in double loop learning feedback loops. This makes it always contextually appropriate to help any organization. -Martin Aziz

The Kanban Principles:

Change Management Principles:

• Start with what you do now;
• Agree to pursue evolutionary change;
• Encourage acts of leadership at all levels;

Service Delivery Principles:

• Understand and focus on customer needs and expectations;
• Manage the work, let people self-organize around it;
• Evolve policies to improve outcomes.

The Kanban Practices:

• Visualize the work;
• Limit work in progress;
• Manage the flow of work;
• Make policies explicit;
• Implement system feedback loops;
• Improve & evolve with data, models and the scientific method.

Affiliated Promotions:

The post The Real Relationship Between Scrum & Kanban appeared first on Agile Advice.

Our order of preference is: #1 – to be right, #2 – to be wrong, and #3 – to remain uncertain. Why #’s 1 and 2? Because we are addicted to the false sense of security that commitments give us.

Organizations that are part of a domain where uncertainty is high, such as knowledge work or professional services, pay a heavy price if they take a similar approach to commitments about what and when to work on customer requests.

Making too many commitments results in unpredictable delivery times. We have so much work in the system that we really have no idea when things are going to get done. There are too many potential outcomes (variability) stemming from unmanageable levels of work in progress (WIP). Unfortunately, even though customers are going to be disappointed, we feel good because many things have been committed to. That’s a false sense of security.

We are emotionally attached to the idea of just saying yes! However, many ideas that initially seemed like good ideas are often discarded once we receive more information. In fact, 50% is a commonly observed discard rate! We should strive to keep customer requests optional for as long as we reasonable can. We should also limit the amount of time we spend in the care and feeding (grooming) of optional work – especially if 50% of it is likely to be discarded.

Another downside of committing too early is that we are more likely to abort the work once we have already invested time and money in starting it. Why? If you say yes to everything, or say yes too early, you’re likely agreeing to a lot of bad ideas! We become so emotionally attached to our commitments that it can be hard to let go. Choose wisely!

It is ideal to keep work optional and un-prioritized for as long as you can. Options have value in uncertain domains.

Developing options before converting them (committing) is an important risk mitigation strategy. It does cost money to develop options, but think of it as buying insurance to protect you from much larger negative consequences down the road (like starting work you did not really want to do and having to abort it at great expense). The more uncertain the environment, the more insurance you are likely to want.

Okay! So committing to start work too early (or taking too much of it on) and not keeping our options open can be a costly strategy in uncertain domains. We should aim to defer commitment and keep customer requests optional for as along as we reasonable we can!

How do we do that?

The Kanban Method encourages deferred commitment and provides a set of principles and practices that are receptive to developing an approach to managing risk that enables work to remain optional. In doing so, service delivery of customer requests is more predictable and reliable. It also helps to increase the likelihood that we are working on the right things at the right time.

Constructs within the Kanban Method that help to leverage deferred commitment are:

• Upstream Kanban – a way to marshal options before the commitment is made.
• Clearly identifying commitment points.
• Two-phase commitments: a commitment to start and a commitment to deliver.
• Mechanisms to funnel options (pay our insurance) before we choose to convert them.
• Shaping Demand – a way to balance demand with capability by allocating capacity to certain types work and risk.
• Enabling a responsible approach to the discarding of options so that we can avoid aborting after commitment.
• A practice of limiting the amount of work in the system so that we do not make commitments that exceed our capacity and make our delivery unpredictable.
• Visualizing the flow of work and the policies around our work – so that when we do commit, we can meet our promise to deliver.
• Visually seeing the interruptions to the flow of work in a WIP limited system encourage us to have discussions and evolve our policies.

If you are interested in learning more about each of these practices and how to apply them in your place of work, consider signing up for one of my premium management training workshops. I offer three LeanKanban University accredited management classes:

Team Kanban Practitioner

Kanban System Design

Kanban Management Professional

Follow me on Twitter @jamesdsteele

Affiliated Promotions:

The post On Commitment In Kanban appeared first on Agile Advice.