How-To Apply Agile, product owner, Theory of Agile

Choosing the right approach for project delivery

Leave a comment

Let’s begin by agreeing that the quest for success starts with the right approach to support project delivery.

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:

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

How To Stay Compliant Using Agile

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!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile coaching, coaching, culture, focus

The Perils of Meeting-Driven Culture

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!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Scrum Master

9 Ways to Identify the “Perfect” Scrum Master

3 Comments

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:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Announcements, Professional Development

Selling What Is “Right”

Leave a comment

I recently had a scheduled call with a client that was aimed to level-set expectations around some upcoming Agile Consultation work that I’d booked. The work was specifically to help them visualize and build their workflow. I had my Sales Engineer come with me, as we both had the suspicion that the client had also bought a tool on the promise it would help them become more Agile.

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:

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

Should the AGILE MANIFESTO Require Certification – Before All Others?

5 Comments

I like to get to the heart of things – their source. Therefore, I love the Agile Manifesto when trying to understand all things agile. http://agilemanigesto.org

The Manifesto is an ideological, philosophical paper outlining the 4 values and 12 principles of how to manage your tasks (in IT but elsewhere, too) and work with your colleagues in an agile manner.  It is not Scrum or Kanban or SAFe – those are wonderful tools. However, it is the Manifesto that clarifies what it actually means to be agile.

Like many of you, I have learned and received certifications – in Scrum, Product Owner, CAL1, and Kanban’s TKP, too.  These are all good frameworks that help in very specific ways to be more agile. And in all or most of the above courses, the Manifesto is used or referenced – to a degree.  But, in my opinion, it is not used to a degree that allows the agile principles to be fully understood and absorbed.

The Manifesto is the heart and soul of all things agile.  It is the ploughed field – the source of growth and understanding.

I would really appreciate attending a one-day training class that goes through each value and principle of the Manifesto, with deep discussion on the meaning of each.  It would then be helpful to create examples of what the value/principle would look like in action.  Perhaps one should even memorize some or all of the Manifesto.

And then I’d like to write a test and be certified as understanding the Manifesto and what agility means.

In 2000 Jim Highsmith for the Agile Alliance wrote: “This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers…out of traditionalists. Quite frankly, the Agile approaches scare corporate bureaucrats— at least those that are happy pushing process for process’ sake versus trying to do the best for the ‘customer’ and deliver something timely and tangible and ‘as promised’—because they run out of places to hide.” http://agilemanifesto.org/history.

So why is there no Manifesto certification? People seem capable of learning Scrum, forming teams, working in various roles, but then question whether or not they are agile.  Agile is agile – it is not Scrum, not Kanban – it is its own thing.

Again Jim Highsmith wrote: “The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.” http://agilemanifesto.org/history.html

If I were one of the authors/ signatories of the Manifesto – and there were 17 of them – I’d shake my head at all the thousands of arguments that exist online and in organizations throughout the world about whether some company or practice or person is truly agile.

Hence, I would insist on a Manifesto education and certification, in order for a company or person to even USE THE WORD agile, and put to rest the conundrums, anxieties and arguments once and for all.

Or, perhaps, I could be wrong – and all that’s needed is more discussion, study and simple understanding.

Attachments

Affiliated Promotions:

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

Customers Don’t Pay Me to Write Tests: The Importance of Tests

Leave a comment

As a technical agile coach and trainer, I help teams discover ways of testing. Some teams ignore tests altogether, while others write every possible test possible, wasting valuable time and not being able to deliver at a good pace.

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:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
agile teaching, culture, How-To Apply Agile, Learning Compassion

What leaders need to know about Agile

1 Comment

To understand why so many people around the world have adopted Agile as their first and foremost guide to improvement, we must first look at why leadership has been failing us in the first place.

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:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Kanban, Scrum, XP and Lean, Uncategorized

The Real Relationship Between Scrum & Kanban

3 Comments

(Image: Cover image of the book Essential Kanban Condensed by David J. Anderson and Andy Carmichael.)

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:

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

On Commitment In Kanban

2 Comments

Most people would rather be wrong than uncertain. When the prospect of being right is questionable, human beings would rather commit to a position and be wrong, rather than hold a posture of uncertainty and avoid commitment altogether.

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:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile coaching, Agile Management, agile training, Kanban

On Managing Work – Not People

4 Comments

Most leaders I work with have a common frustration they express to me: an inability to achieve significant gains in how quick and predictable they are in delivering work to their customers.

In my work as a consultant, coach, and trainer, there is one strategy that I help them discover that results in dramatic change to their thinking and how they view work and workers within their organization. So what is the strategy?

Flow Efficiency

Work items (ie: user stories, features, epics), or whatever artifacts represent customer recognizable value within your context, can spend their lifespan alternating between two states: active and waiting. Work is active when we are currently engaged in adding value to a work item – it has our attention and we are actively working on it. Work is in a waiting state when it has been started, but is then interrupted (for a variety of reasons) to address something else. The active time in relation to the total lifetime of a work item is a construct known as Flow Efficiency. An understanding of this relation can have serious implications on how you view your work and the decisions you make.

It’s expressed as a percentage using the following formula: (Active Time / Total Time) * 100

Here is an example. A user story has taken 26 hours to complete (from start to finish). Out of that 26 hours, only 2 hours where actually spent working on the item and 24 hours of the total was in a wait state. That is a flow efficiency of 7.7%.

( 2 / 26 ) * 100 = 7.7

You may be surprised – as are many of my clients and students – to discover that in knowledge work (ie: Software Development) a typical flow efficiency is measured at 4-8%! In fact, 40%+ would be VERY good.

Think about that!

This means that work items spend their existence primarily in a waiting state. Even though we have started to work on something, 92-96% of the time we are not adding value to the work item! There are numerous reasons as to why work items are placed in a waiting state: task-switching, queues, blockers, internal/external dependencies, etc… (Remember: If you are working on more than one item, every time you put aside one item to work on another, that item effectively goes into a wait state.)

So what are the implications of a low flow efficiency system and how might it change how we work and the decisions we make?

Implication #1: How busy people are is largely irrelevant.

20th century management techniques have engrained in us an obsession with the high-utilization of people. Everyone must be busy working on as many work items as they can.

This stems from a desire within us to measure what we can see, and unless we are in a manufacturing environment, what we can see are usually people! In knowledge work we can’t see the work going on – it is for the most part invisible. It happens inside people’s heads. Yet managers consume themselves with ensuring that people are busy in the hopes that this will churn out more work in less time. And even if it doesn’t, at least they can claim they were getting the most out of their people!

In a low flow efficiency environment high-utilization of people is not the path to greater speed and predictability. The fact of the matter is that if work spends the majority of it’s time in a waiting state, then it really does not matter how busy people are – to the contrary. More work for individuals in a low efficiency environment only contributes to a degrading flow efficiency – particularly because of task-switching.

Customers are not paying for key strokes. They don’t care how busy your workers are. They care about speedy delivery, reliability, and quality. Idle work, not idle people should be the centre of your attention. Your customer’s needs will be more positively impacted by focusing on the flow of work (and removing delay within that flow), not the utilization of people.

Implication #2: The performance of people is largely irrelevant.

In an effort to increase the speed and amount of work that teams deliver, the response from most managers is to hire more people and/or make people work faster and harder. The majority of my coaching engagements usually begin with a manager meeting with me and pleading for help to “please go make my teams faster”! Thus begins the process of me helping them understand that if they are in a low flow efficiency environment (they usually are) focusing on improving the performance of individuals (or hiring more of them) is not really going to have much of an impact in addressing their pain points. Why?

Imagine this frustrated manager has an environment where flow efficiency is 6%. So 94% of the time work is in a wait state, and only 6% of the time is value actually being added to work. If we choose to focus on optimizing the performance of the 6% of active work, any improvements are going to be very marginal on the overall increase in delivery time of work over its entire lifespan – we are only addressing 6% of the total!

Let’s suppose that out of that 6%, that 2% of that time is development work. Even if you make your development team 10 times faster, or double the size of your development team, you are going to have very little impact on the whole.

The opportunities for improvement that are really going to shift the needle in delivery times and predictability are in tackling the 94% of delay that exists in the flow of work. In such an environment we need to help managers move away from managing and measuring people, and instead managing and measuring the flow of work.

Implication #3: Your estimates are doomed.

Most organizations are horrible at estimating. There are numerous reasons for this, but a key contributor to why our estimates are so unreliable is that when we estimate we are producing “effort” estimates. We are estimating the amount of effort we think it will take to complete a work item, and when we do this we are estimating the 4-8% of active value-adding-work-time we anticipate to incur. But we are NOT estimating the amount of wait time that our work item is going to spend in its lifespan. That’s 92-96% of the lifespan of a work item that we are not taking into consideration. No wonder we are so far off in our estimates. We can try and game the system by adding buffers to our estimates, but alas this tactic is often futile and detrimental to developing predictability.

Implication #4: Focusing on team performance is not the path to business agility.

It has been my experience, that in most organizations of more than 50 people, the notion of self-organizing cross-functional teams is a fantasy. Time and time again, when I look at how work flows through an organization, it rarely exists within the boundary of one team and independent of any other teams. What I more commonly witness are cross-functional silo’d teams that have dependencies between each other.

Even more detrimental to the delivery times and predictability of our work is the delay that exists between teams. If work is flowing through more than one team (it usually is) and that work is not arriving to the right-team-at-the-right-time then delay is going to be introduced – and with delay we have negative impact to our flow efficiency.

It won’t matter how optimized individual teams are if the flow of work amongst them is not managed to create smooth flow. Business agility is not achieved by how many high-performing teams you have, but rather, how well you manage the interactions amongst teams.

“The performance of a system is not the sum of its parts. It’s the PRODUCT of its INTERACTIONS.” – Dr. Russell Ackoff.

Let’s Do Something About It

Now that we are aware of some of the implications of a low flow efficiency, what practical and actionable guidance should we consider in order to improve our service delivery and deliver value to our customers when they need it? How can we do this in a way that favours managing and measuring work OVER managing and measuring people?

Visualize work: Knowledge work and professional services are domains in which the work we do is largely invisible. We need to find a way to make this work visible so that we have something tactile that we can have conversations about. We need to see how-our-work-works!

Limit the amount of work in progress: If we are to catalyze improvements in how we work and develop a sustainable pace, we need to start limiting the amount of work we commit to at once. Predictability in our delivery is not possible unless we limit the amount of work in progress.

Manage the Flow of Work: As we have discussed in this article, we need to focus our efforts on identifying those things that hinder the flow of work. We need to shift our attention from the utilization of people towards the management of work and how it flows.

Make Policies Explicit: Whenever we discover flow impediments we should strive to resolve them. Part of the resolution should include updating the policies of how work flows through our system and making them visible. Evolving our policies and making them explicit is a cornerstone to continuous improvement.

Implement Feedback Loops: Business agility and continuous improvement are rooted in a desire to quickly learn and respond to feedback. We need to establish mechanisms where we can collect and evaluate feedback so that we can maintain or correct our course. These mechanisms should foster an ability to gather meaningful feedback that we can act on.

Collaborate and Experiment: An agreement to pursue evolutionary improvement by encouraging acts of leadership and collaboration at all levels of an organization are necessary if we aspire to a culture where change can flourish through experimentation founded on the scientific method. Our approach needs to move towards a non-deterministic probabilistic way of thinking, and away from a speculative and wishful mindset.

Helping organizations develop an understanding of the implications of poor flow efficiency and then using these practices to help overcome that challenge is a strategy that has proven very effective for myself and my clients. My premium management training classes provide in-depth practical guidance on how to apply these techniques.

Conclusion

I’m not suggesting that an obsession with accurately tracking flow efficiency will be time well spent, in-fact, even if you wanted to, it can be quite difficult to do without electronic tools. However, even an approximate understanding of your flow efficiency, or being on the lookout for interruptions of flow (blocked items, items aging in queues, dependencies, etc..), and focusing on developing smooth-fast-flow, can have tremendous benefits to your ambition of delivering more quickly and more reliably to your customers.

Focus on eliminating wait times of your work items! Strive for flow that is smooth and fast! Spend more time managing and measuring work, less on managing and measuring people.

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:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Jobs, Professional Development, Scrum Master

The Secret to Finding a Job as a New Scrum Master

4 Comments

It appears to me there are more jobs available for Scrum Masters than ever before!  Why is it so hard for some people to find employment with Agile teams?

The problem is entirely predictable.  And for those eager to work in Scrum teams, the answer is also predictable.  I’ll explain.

Having taught Scrum to more than 2000 people, I have ongoing dialogue with many former students who are struggling to find opportunities to serve Agile teams and gain experience as a Scrum Master.  I have struggled to understand this dilemma because my experience was very different – I learned of Scrum in 2007 and simply asked my workmates:

“Would you like to try Scrum…I could be our Scrum Master?”

Unanimous reply: “Yes!”

That is not the common experience.  Many organizations are willing to send their staff to Scrum training for the sake of ‘Professional Development’ but only some of those organizations intend to develop Agile teams.  That pattern has created the current condition in which many recently-trained Scrum Masters are eager to apply their new knowledge but do not have organizational support to do so.

I opened my inbox today to a question from a former student of my Scrum class.  Let’s call her Jane:

“Hi David, I wanted to get your advice on a dilemma I have. I’m back on the job market and several companies are looking for Scrum Masters which is great to see.  I was in your CSM course last year and would love to work with a Scrum team…but I didn’t have the opportunity with my former employer.  How can I gain experience if all the available jobs require 2+ years experience?  What advice do you have for me?”

Jane is not alone.  The job market (today at LinkedIn) offers 591 positions in Canada for keyword ‘Scrum Master’ – and all that I’ve scanned require 1 or more years’ experience in the role.

In contrast to the dilemma described above, I have a totally different problem: I am contacted a few times per month by recruiters and hiring managers who ask me if I’m looking for a new contract.

Where’s the welcome mat for newcomers?  Do jobs exist for enthusiasts with no prior experience?

I believe so.

The dynamics we’re observing in the job market for Scrum Masters are well described by Everett Rogers in his paper called “Diffusion of Innovations” (1995).  You may recognize his theory by the following bell curve:

Scrum Innovation has Achieved Early Majority Adoption

I assert that Scrum has achieved “Early Majority” market penetration. And you might be asking what evidence I have to support that claim – of course, other than the fact that opportunity knocks frequently at my door but never at Jane’s.  I’ll describe the patterns I’ve observed in the market.

The authors of Scrum (Ken & Jeff, and others) were the Innovators.  When I first took on the role of Scrum Master (2007), knowledge of Scrum was limited to a few enthusiasts and early adopters.  Worldwide, a few thousand had learned of Scrum; in Canada, perhaps a hundred or so.  None of my friends or workmates had prior knowledge of Scrum; there were no job advertisements for Scrum Masters; there were no public training classes; many of the well-known books on the subject had not yet been written; and there was exactly one Certified Scrum Trainer in Canada: my colleague, Mishkin Berteig.

By 2012, awareness of Scrum was spreading.  It was a buzzword among start-ups and software development firms and a few brave souls were socializing the practice in large enterprises.  Despite the increasing awareness, the number of people who had served as Scrum Master in a proper Scrum team was, I’d estimate, less than 100 in Canada.  Yet, anyone with “Scrum” on their resume was considered rare and hiring managers among the early minority adopters were eager to snap them up.  A swell of “Agile Coach” contractors was starting to emerge and anyone willing to hang that shingle was considered an expert.  I’d argue their enthusiasm often out-weighed expertise but it was a new frontier after all and sheer enthusiasm counted for a lot.

By 2014, I noticed 2 patterns emerge.  First, young tech companies in Canada (the ‘early early adopters’) were no longer hiring Scrum Masters.  They considered Scrum expertise (or willingness) an obvious requirement of all new hires – like table-stakes.  Second, large enterprises were starting to post job advertisements for Scrum Masters.  These two patterns infer that the ‘late early adopters’ were onboard.

By 2016, evidence of ‘early majority’ adoption was mounting.  I received frequent requests to speak at hospitals, marketing agencies, industry events, ‘Leadership’ seminars.  Our federal Government departments started recruiting, not only Scrum Masters, but Product Owners too.  Small armies of young MBA grads were being sent by their big consulting firms to my Scrum classes to “get certified”.

So, in 2018… Jane is certainly asking “what does it mean for me?”  Well, it means there’s more opportunity than ever before.  That is certainly true and awareness and demand for Scrum continues to grow.  It also means I see a vast landscape of opportunities, but Jane sees closed doors – unfortunately for her.

There’s good news in this story for Jane… I promise!

Let’s think about the mindset common among the ‘early majority’ adopters. They are risk-averse, but not so much that they ignore market opportunities.  They live by a simple rule: “the 2nd mouse gets the cheese.”  They watch the early adopters carefully hoping to spot advantageous patterns.  (Scrum is one of those.)  And when they see a trend, they don’t pounce on it immediately – remember, they’re pragmatic.  They will want to hire Scrum Masters, but they’ll be careful about it: perhaps they’ll hire contractors rather than commit to full-time/permanent roles; perhaps they’ll require 5+ years’ experience hoping to acquire one of the early adopters who helped prove the efficacy of the new method; perhaps they’ll train internally hoping to gradually adjust and minimize disruption.  They’ll be reluctant to “take a chance” on a new hire without proven experience.

Those pragmatic habits of the early majority adopters make it difficult for them to hire Jane.

5 to 10 years from now, Jane’s job search may get a lot easier. Why?  Let’s think about the mindset common among the ‘late majority’ adopters.  They are risk-averse – to the point they ignore new trends and look instead for so-called “best practices”.  These organizations are doubling-down on Waterfall right now and sending their staff to PMP exam-prep courses.  They still think Scrum is a buzzword.  But they’ve taken note when Brian Porter, the CEO of Scotiabank said publicly, “we’re in the technology business. Our product happens to be banking.”  They’ve felt some shock when Alex Benay, CIO of Government of Canada talks about agile procurement and relentless incrementalism.  They will start hiring Scrum Masters when they’re shown evidence that Scrum is teachable, repeatable, reliable, and so-called “normal”.  They will believe (and trust deeply) that the community has developed well-established and standard methods which can be taught and learned systematically.  They’ll find the senior practitioners too expensive; and they’ll look to less experienced practitioners, like Jane, as a bargain.  They’ll be less concerned about in-the-trenches experience and more interested in industry norms.

Those risk-averse habits of ‘late majority’ adopters will make it easy for Jane to find employment – unfortunately though, the salary range is likely to be average at best.

(Let’s not discuss the Laggards today – they’re just funny.  They’re the reason your office still has a fax machine and your car still has a cigarette lighter.)

Jane!  I promised good news. Here it is…

Even at this stage of ‘early majority’ adoption, you’ll find some people who are on the edge of innovation.  Look for those enthusiasts and visionaries!  You’ll not find them easily in the big employers (banks, telecoms, etc.)  You’ll find such people in start-ups, small tech firms, product companies.  Those organizations are not looking for the stodgy corporate mindset – they’re eager to find other enthusiasts and they’re willing to take a chance.  They’re more interested to forge new paths than to follow others – so they’re excited by Jane’s willingness to forge her own new path and they’ll want to help her!

So, what if Jane herself is not ready for that level of risk?  Well, on one hand I feel every Scrum Master must develop high risk-tolerance.  But I understand not everyone starts there. Jane might seek the sense of job security and stability common in large enterprises.  In that condition, my advice to Jane would be: consider taking a job as not a Scrum Master but as a team member.  If you’re a Project Manager or Developer, or Business Analyst in the past, hunt for those opportunities then look for ways to transition into a new role.  That is, after all, the type of pragmatism the enterprises (early majority) appreciate.

Happy job hunting!

***
Thanks to Massimo for the conversation we had on the train yesterday.

Thanks to Brian.

Thanks for Valerie who reviewed and helped improve the article.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, coaching, culture, Kanban, Professional Development

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

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.

  1. 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?”).
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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).
  7. 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.
  8. 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.
  9. 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.
  10. 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.

Register here for a LeanKanban University accredited leadership class with Travis.

Affiliated Promotions:

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

Agile Blog: Scrum vs Open Agile vs Kanban (Visual Summary)

3 Comments

Welcome Agilist…whist we focus on ‘Being’ Agile, ‘Doing’ Agile goes hand in hand towards achieving a common goal…here is a quick visual comparative summary of 3 closely related but unique systems (Scrum, OpenAgile and Kanban) to get started…

  1. Origin
  2. Domain Application
  3. Time Availability for Change
  4. Roles
  5. Workflow
  6. Frequency

Ref:

https://www.scrum.org

http://www.openagile.com/

https://leankanban.com/

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
agile training, Kanban, OpenAgile, Scrum Guide

Scrum, Kanban, OpenAgile: Same Goals, Different Approaches

4 Comments

The inspiration of this opinion piece comes from a professional student who just finished reading “The Scrum Guide” by Ken Schwaber and Jeff Sutherland, “Essential Kanban Condensed” by David J Anderson and Andy Carmichael, and “The OpenAgile Primer” by Mishkin Berteig and The Berteig Consulting Team. These thoughts come from a humble place and is very open to feedback, differing opinions, or just comments in general. If I’m out to lunch, let me know!

On the surface of what seemingly looked like 3 very similar practices–after careful deliberation–turned out to be 3 unique approaches to creating high performance teams that deliver quality services. The objective of my article is to share some of the key differences that I uncovered after reading about each practice.

 

Differences in Structure:

All 3 agile practices rely on iterative development and continuous feedback to optimize the delivery of products and services. However, the difference I see is in the structure of each. Scrum is a defined framework with a set prescription to maximize the output of software delivery and product building. Whereas, Kanban is a flexible method that uses evolutionary change and self-organization as a way to continuously build out value and services, without overburdening the team. OpenAgile uses self-organizing behaviour that allows team members to commit to tasks based on capacity while prioritizing tasks with the highest value drivers.

 

Differences in Reflection periods:

All 3 agile practices stress the importance of reflecting and receiving feedback, however, each one implements this important event at different times. One of Scrum’s most vital ceremonies is the “Retrospective”. This time of reflection takes place at the end of every sprint—giving team members the time to reflect on ‘what went right’, ‘what went wrong’, and ‘areas for improvement’. OpenAgile encourages reflection within the ‘Engagement Meeting’ which kicks off every cycle—allowing team members to start off with improvement ideas at the forefront of every new cycle. Kanban on the other hand, incorporates seven specific opportunities for feedback loops (i.e. cadences) which are strategically placed so that feedback is continuous and supports the goal of evolutionary change.

 

Differences in Defining a “Team”:

All 3 writings described the importance and closeness of the “team” that is building these high-value services/products yet, the makeup of these teams differed quite largely between the 3 agile practices. Starting with Scrum—this practice has the defined role of ‘Scrum Master’ and ‘Product Owner’ but a cross-functional group of people who makeup the ‘development team’. The ‘Scum Master’ and ‘Product Owner’ are very intentional roles—serving strict and important functions for the ‘development team’ and their success. This differs from a ‘team’ within the Kanban practice which is just a group of people with no real designated roles. The team as a whole, works collaboratively and self-organizes on their own. Similarly, OpenAgile does not concern itself with defined roles and is also made up of a self-organizing team (or individual). However, OpenAgile does speak on the importance of team members stepping up to serve their teams in necessary capacities in which they name as the process facilitator and growth facilitator.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
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
Win as a Manager with Your New AI Coach: Max Good (WEBINAR)
Online
C$0.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1895.00
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1495.00
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$1270.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$1270.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$845.75
Jul 19
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Aug 2
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Aug 16
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Sep 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Sep 19
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Sep 26
2023
Details
Kanban System Design® (KMPI)
Online
C$1525.75
Sep 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Oct 3
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Oct 18
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Oct 24
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1525.75
Oct 25
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Nov 7
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Nov 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Nov 21
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Dec 5
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Dec 12
2023
Details
Kanban System Design® (KMPI)
Online
C$1525.75
Dec 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Dec 19
2023
Details