Loading...

Follow Agile Advice on Feedspot

Continue with Google
Continue with Facebook
or

Valid

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

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

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

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

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

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

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

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

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

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

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

(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 every 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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

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

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Agile Advice by James Steele - 7M ago

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

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

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

The post On Managing Work – Not People appeared first on Agile Advice.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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:

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

The post The Secret to Finding a Job as a New Scrum Master appeared first on Agile Advice.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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:
Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.
Please share!

The post Towards a Culture of Leadership: 10 Things Real Leaders Do (and So Can You) appeared first on Agile Advice.

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview