“Successful people ask better questions, and as a result, they get better answers.” – Anthony Robbins
Have you heard this leadership quote from Anthony Robbins?
Anthony Robbins is an American author, coach, motivational speaker and business owner known for his infomercials, seminars, and self-help books including Unlimited Power and Awaken the Giant Within. He has taught hundreds of thousands of people on success worldwide, so he knows a thing or two about it.
Changing Your Frame
We see the world through certain lenses – through the things we were taught as we were growing up, through our religion, our beliefs, our current physical restrictions. Changing any of these, and many others will change how we see the world and even how we believe what is possible.
What Anthony Robbins is saying in this quote is that by asking a different question you will start to shift the lens you see the world through, and by asking better questions you will get better results.
For example, if you ask yourself: “Why does this always happen to me?” your brain goes searching for all the reasons why these things always happen to you and comes back with demoralising things like “You’re stupid, you’re not worth anything more, you’ll never be good enough.”
But if you ask yourself “How can I get better?” your brain will search for all of the ways you might be able to get better – maybe exercise, meditate, study new things and work for a promotion.
“Seek and you shall find, ask and you shall receive.” is such a true quote. Your brain is constantly serving you, just make sure it is serving you in the right way, by making it search for the right answers to the right questions.
“It is not the strongest nor the most intelligent of species that survives, but the one that is most adaptable to change.” – Charles Darwin
Have you heard this quote from Charles Darwin?
Charles Darwin was an English naturalist, geologist and biologist, best known for his contributions to the science of evolution. His proposition that all species of life have descended over time from common ancestors is now widely accepted, and considered a foundational concept in science.
Because of this, it makes sense to listen when Charles Darwin says something about survivorship – after all, he studied the reasons behind species surviving or perishing, and the same can be said of people, civilizations, and even companies.
The World Changes – So Must We
Is the world the same as it was fifty years ago? Certainly not. There were no iPhones, no internet, limited globalisation, no social media, among many other things. If the world constantly changes it is folly to think that we can remain the same and still survive, or even thrive.
Charles Darwin saw this in the mid-to-late 1800s, and the same is true today, because the one true constant is change itself. Things are always evolving, things are always changing.
Kodak film and cameras saw the digital revolution coming early on – they even wrote a paper on the coming digital revolution in the early 1980s – fully twenty years before it happened. And yet, they still went bust because they were unable to change. Middle management in-fighting and bickering over organisational turf took priority over actually changing the company toward something profitable, even until the end when the writing was truly on the wall. Eventually, Kodak went bankrupt.
Meanwhile, Amazon always does business like it’s “day one” – in other words, the most vulnerable time for a business. They are constantly moving, constantly evolving, and its CEO Jeff Bezos is consequently the richest man in the world. Is he smarter than everyone else? No, not everyone. Is Jeff Bezos stronger than everyone else? No. But it is not the strongest nor the most intelligent of species that survives, it is the one that is most adaptable to change.
“Do not follow where the path may lead. Go instead where there is no path and leave a trail.” – Ralph Waldo Emerson
Have you heard this Leadership Quote from Ralph Waldo Emerson?
Emerson was an American essayist, lecturer, philosopher, and poet who published dozens of essays and gave more than 1,500 public lectures across the United States in the mid 1800s. He was a champion critic against the prevailing pressures of society.
A Leader Makes Their Own Path
Many times we’ve heard true leaders needing to make their own path, even when others ridicule or make fun of them at first. Steve Jobs was ousted from his own company before he made his own way back and made it a success. Bill Gates was so adamant that computers were the future he gave everything towards making the software that controlled it. Jeff Bezos sold books online even as others thought it was crazy to do so, and he held fast during the dot com bust to prevail as the world’s largest marketplace a decade later.
None of these billionaires, these leaders, followed someone else into their billions. They formed their own path and left a trail for others to follow.
“The challenge of leadership is to be strong, but not rude; be kind, but not weak; be bold, but not a bully; be thoughtful, but not lazy; be humble, but not timid; be proud, but not arrogant; have humor, but without folly.” – Jim Rohn
Have you heard this leadership quote from Jim Rohn?
Jim is a well known author, entrepreneur, and speaker. One of his best speeches is “How To Have Your Best Year Ever” and is a speech that can be listened to over and over again, teaching some of the most powerful fundamentals of life, success and business.
The Paradox of Leadership
In his quote, Jim Rohn rightly points out the paradox of leadership – that a true leader is strong enough within themselves to be humble, strong enough to know the difference they made and give credit to their people to lift their spirits and build their self esteem, but also strong enough not to be bowled over or led astray.
From this perspective, “strength” doesn’t mean beating someone up, it doesn’t mean putting others down, and it doesn’t mean all talk and no action.
A lot of it comes back to self-discipline, which Jim talks about frequently in his speeches. When a leader has the discipline within themselves, they clearly know when to draw the line and when to cross it.
There are many different business documents that you’ll need to help kick-off and then manage your project, and we call these Project Management Business Documents that we’re going to need in the managing of our project. There are two main business documents, which are the project business case, and the project benefits management plan. Ultimately the business case will help us kick off the project and start the project but the project management benefits plan will help us manage those benefits that we’re wanting to deliver and make sure that we are delivering on those benefits when the project is delivered. The pre-work we’re looking at is the needs assessment – for example what’s the need of this project? Why is it being kicked off? Why is it being initiated? That helps us and feeds into our business case.
Benefits Management Plan
The project business case also has the benefits management plan within that, so that we know what benefits we’re delivering. All these documents will feed into our project charter which ultimately is one of the first steps, or is the first step in initiating a project. From there the project charter will feed in with all of the information that we’ve gathered from our needs assessment, business case, the risks involved, the stakeholders as an early view of the stakeholders, and risks and scope and schedule that might be involved and all of that feeds into the project management plan on a larger scale where we’re using that now to manage our project on a daily basis.
Project Business Case
So let’s dive into the project business case. What is actually in it? There are a few things usually, and they include business needs – so a description of what is prompting the need for action. Maybe customers have fallen off over the last year and we’re wanting to get more customers, maybe there’s a lot of rework that’s happening in a certain area and we’re wanting to reduce that rework. Whatever the business need is, we’re wanting to include that in the project business case. It’s a feasibility study of why we’re initiating the project. We usually give an analysis of the situation, so what are the facts, what is currently happening, are we currently at 80% capacity but we need to be at a hundred percent capacity? Whatever it is put the raw data and that project management data and info into this analysis of the situation for your business case, and then based on that we’re wanting to give a recommendation.
What’s the need, what’s the current situation, and based on that what are we recommending that people do to make a change and deliver what we need to deliver for this project.
Lastly once we’ve done that of course we’re wanting to see how the benefits that we’re delivering will be measured. Will it be Bob over there in a certain department measuring this for the next two or three months to make sure that things are on track and that it’s actually delivering what we want to deliver? However we’re going to measure it we want to put that in the plan as well.
Project Benefits Management Plan
Which leads us into the project benefits management plan. How are we managing these benefits? We want to usually include what the target benefits are, is it increasing this or decreasing that, include it in the project benefits management plan. We want the time-frame for realizing those benefits – is it a year? Is it six months? Is it one month?
Next, who owns the benefits. This comes back to our BAU, our operations. What are the metrics that we’re measuring, what are the assumptions that we’re making when we’re here measuring these things? We just need to know what those assumptions are in case they end up being wrong, and then we can see why we didn’t meet the the target or maybe we did better than the target (or whatever it is).
Ultimately we want to see what risks there are to meeting those benefits as well and put those in the project benefits management plan.
How to Measure the Project Benefits
There are many different ways to measure these things and measure these benefits and some of these are called out in the project management body of knowledge. They are Net Present Value – you will need to know this for the exam usually they’re fairly straightforward to go into and often the way they’ll word it on the exam will be “you have a net present value of of this and a net present value of that, so which one should you actually choose?” And you choose the highest.
For your Return On Investment we just want the highest return on investment. Internal Rate of Return – we want the higher rate of return as well. The payback period we want a shorter payback period if possible, and the benefit to cost ratio we usually want a higher benefit to a lower cost if possible.
But all of those are just numbers and numerical objectives and financial objectives – usually we can also have things like meeting non-financial objectives, fulfilling contract terms or conditions, meeting governance or regulatory requirements, achieving stakeholder satisfaction, meeting organizational strategy or goals – all these things could be non-monetary benefits that we’re realizing at the end of the project and we can also include.
And those are the project management business documents as part of our foundational elements of project management.
This is the Agile Practice Guide from the Project Management Institute and Agile Alliance, and this particular one is delivering in an Agile environment.
Check out the video and article below!
Delivering in an Agile Environment
There are two things in focus when delivering in an Agile environment, and the first is the team and the project charter. The second is the way we measure results – it can be very different than that of a traditional approach when we’re using Agile. First let’s look at the Charter.
Charter the Project and the Team
Usually in a traditional approach using the project management body of knowledge, which goes through very set steps that will initiate a project with a project charter. It will go through what the project stands for, what the risks are, who the stakeholders are, all those things. It will initiate that project and kick it off.
Now in addition to that when we’re using an Agile approach, our cross-functional team will initiate with a team Charter. What that means is you’ve seen the cross-functional team before where we’ve got the roles like the facilitator, we’ve got the product owner, and they represent the customer or the business. And then we’ve got our cross-functional team members who are those T-shaped members who have a general knowledge of a lot of things and then one really deep specialty knowledge. So these team members are extremely valuable because they might have one deep specialty of development and then many many general knowledge areas such as design or testing or or even leadership. All of those different things.
Our team Charter includes the project vision or the purpose, and this is so important and it’s so wonderful as well. Why? Because we want to start with “why”. Start with why is a classic book by Simon Sinek, and it’s just a wonderful way to get everyone on the same page and make sure everyone is heading in the right direction. “Why” is it that we are doing this in the first place?
Once we’ve got that, we work on a clear set of working agreements and that can involve many different things. When we were working on the purpose and the why we ask the questions “why are we doing this project, who benefits from this project,” and what does done mean for this project? What is the definition of done, when do we finish working? And then how are we going to work together. Now the best role and this can be anyone who has this leadership quality is the Servant Leader, who may facilitate that chartering process sitting down with the team, facilitating everyone, getting them working together and extracting that information from the team.
So they can put it down into words where it may have been hidden before. The servant leader’s role is also to help coach and to help remove blockers.
Now the team charter is also a social contract. That social contract can include things like team values, such as the sustainable pace and the core hours. We’ve talked about the sustainable pace before – we don’t want people to be working the midnight shift and then crashing and burning the next day. Or really going crazy one week and then having three days off sick – it’s just not sustainable, and it’s not a great way to work. From an Agile perspective we want that sustainable pace, and we want to put that down in words. What is that sustainable pace? Do we have set breaks, do we have set hours, what are our core hours, are they late or are they early, does everyone get in at the same time? All of those things, let’s write it down.
We have working agreements such as what “ready” means, so the team can take in work. So when are you ready to take in more work? What done means – so when are you finished that work? And the team can judge that completeness consistently.
Respecting the time box – so they are iterations of two to four weeks, and their work in progress limits. If the team is working in an Agile format where they’ve got cards and maybe they have limits for how many cards they can take on at a time, you don’t want all of your cards sitting in the backlog of work, but likewise you need to make sure that everyone understands when they can take on a new piece of work as well. And that goes in the team charter.
We want ground rules, such as one person talking in a meeting at a time. Or maybe you want a lot of discussion, a lot of collaboration at a time and maybe everyone agrees with that. And we want group norms such as how the team treats meeting times – is everyone on time? Or can someone miss it if they’ve got something really important on? What are those rules and does everyone agree?
Of course you can put any other behavior that the team wants to work with or address. Maybe something has bugged someone in a previous working arrangement and they just want to bring it up and they want to say – “Hey this didn’t work well the last time or maybe this worked really well,” and they want to bring this up and that can go in the team charter
as well.
How Agile Teams Measure Results
As we’re delivering in an Agile environment, Agile teams measure things quite differently to that of a normal project. The way they do that is that they actually measure results in the way that the project is delivered in other words the pieces of the project that are delivered, the functional pieces.
Agile favors value-based measurements, and that’s value from the perspective of our customer. So what are the valuable pieces that our customer can get their hands on and use, and how many of those pieces have we delivered? Instead of normal predictive measurements like Earned Value Management or Schedule Management or cost management that we could use in a more traditional waterfall approach, by measuring what is done and re-planning at each iteration by iteration there’s less room for error and more room to correct course.
And we’ll see that in the way that we measure those results with a burn-up chart or a burndown chart, and these burn up charts or burndown charts are basically these story points remaining. As you can see we might have features and then often many smaller “stories” will make up those features. And features can make up larger increments that we’re delivering to a customer.
The pieces of work that we’re working on as a team – maybe we have a thousand stories altogether in the in the product backlog and then per iteration we might have 20 or 30 or 50, but each time one of those stories is finished we’re marking it off on the chart, so we’re basically counting down the number of stories that we have completed. We want to aim for a certain amount of stories so as you can see here over 10 iterations we’re wanting to
finish that amount of stories but in reality sometimes it is a little bit different. So we can give ourselves a guide but obviously when it’s happening it might fluctuate – it might go up and down or not go at the exact pace that we want it to, because life happens and things get in the way.
So by making it visual and by measuring by the story points and the features that we’re releasing and the things that are getting done and the value that we’re adding to the customer – that is the way that an Agile team will measure results.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. There are core frameworks and auxiliary frameworks that you will come across on your Agile journey. Depending on the organization or the team that you work in, usually someone will be using some of these methods. You don’t have to use all of them, as often many of them have the same core practices underneath such as visual management, daily stand-ups, having a product owner, and grooming a backlog.
It’s really useful to know the actual frameworks and the names that
people might be using to refer to them, just so that you can keep up with the conversation and also understand what’s happening underneath – the underlying principles behind these methodologies. This one we’re going to look at involves Scaling Agile methodologies. We’ve got Scrum of Scrums, the Scaled Agile Framework, we’ve got Disciplined Agile, and we’ve got Large-Scale Scrum.
Check out the video and the article below!
Scrum of Scrums
With Scrum of Scrums, it is similar to Projects, Programs and Portfolios. If you’ve worked in project management you’ll know that we’ve got portfolios at the high level, then we’ve got programs underneath that, and we have a number of projects underneath that. It’s just a really high-level approach to managing a portfolio of work.
Scrum of Scrums is conducted when we’ve got two or more teams, usually of three to nine people (most often in a scrum team we’ve got three to nine people so it’s not too big but also not too small) and we’re needing to coordinate all of the work across those teams. A representative from each team will attend a meeting with other team representatives around three times a week. This is very similar to the daily standup but not quite – it’s just a method of keeping everyone on the same page across streams. That representative from the team will attend the meeting with the other representatives from their teams three times a week to report on their completed work, their next set of work, any current blockers in their work and potential upcoming blockers.
This is a really good practice and it’s good to see what other teams are doing. Keeping that
communication line open is important when you’ve got multiple streams of work all working towards similar dates or similar deliverables. The goal is to ensure that our teams are coordinating their work and removing blockers across teams, not just within the team itself.
The way it looks is you’ve got your Scrum teams of between three to nine people. You might have multiple Scrum teams so then one of these representatives will come and report to the Scrum of Scrums meeting three times a week. Then once a week we’ve got the Scrum of Scrum of Scrums – similar to that portfolio level.
Scaled Agile Framework (SAFe)
As part of our Scaling Agile frameworks we’ve also got the Scaled Agile Framework, or SAFe. SAFe basically helps with detailing practices, roles and activities at the portfolio, the program and the project levels, similar to our scrum of scrums.
It focuses on organizing the enterprise around value streams, that provide value to the
customer. We’re focusing on the customer’s point of view. These programs that we’ve got and the projects within them provide this particular piece of value and it’s basically with the end customer in mind, so everything is all organized around that value to the customer.
The principles are to take an economic view, to apply systems thinking (so to understand that this small piece in the system will affect the bigger cog in a system will and so on), in other words nothing is done in isolation and we always think about the consequences of even the smallest actions. Assume variability and preserve options, building incrementally with fast integrated learning cycles.
Does that sound familiar? That’s definitely an Agile principle – we’ve got our iterative approach, we’ve got our incremental approach, all of these things help us get stuff into the
hands of our customers quickly.
We want to base milestones on objective evaluation of working systems. This is Continuous Integration where we’ve got all of our changes going up into the one
environment so we can see whether it’s working or not, and we can see that on a daily
basis.
We want to visualize and limit the work-in-progress, reduce batch sizes, and manage queue lengths. Now that will be familiar to you as well with the visual management approach of Kanban. We’ve got the Kanban board and we can clearly see the work and whether it’s flowing through the the value chain, or our team value chain, from the backlog on the
left to done on the right. We can clearly see whether it’s flowing or whether it’s stuck.
We want to apply this cadence for synchronizing with cross-domain planning, and that is where our scrum of scrums will come into it. So now we’re planning with other teams and we’re helping other teams remove blockers, and we’re making sure that we know what’s
happening across streams as well.
We want to unlock the intrinsic motivation of knowledge workers. This is something that I haven’t seen mentioned in any other part of Agile, but it really is a core part of Agile. In fact the all of the practices that we perform as an Agile team and their core methods will actually help unlock that intrinsic motivation. That’s where you’re motivated internally as opposed to just motivated by money or a bonus or something similar like that. We’ve got things like checking in with with our team and making sure that everything is really clear, helping bring meaning to the work by making sure the work is connected to the customer. All of those things really help with the intrinsic motivation.
We’ve got decentralizing the decision making, and that comes across with our whole team approach where we have all the people involved, not just you know one person or one team.
Large Scale Scrum (LeSS)
As part of our scaled Agile frameworks we’ve got Large Scale Scrum, also known as LeSS. LeSS aims to organize several development teams towards a common goal by extending the Scrum method across teams, similar to scrum of scrums.
Because of that you’ll see some similarities between LeSS and Scrum and some LeSS techniques have been added to scrum. These similarities we’ve got one single product backlog, we’ve got one definition of done for all teams so everyone is on the same page. We’ve got one potentially shippable product increment at the end of each sprint (and we’ve touched on that many times we’ve got a sprint of two to four weeks and we’re showcasing an increment to the customer at the end of that so that they can see whether we’re on the right track or not and that’s our potentially shippable product)
We’ve got one product owner, who is someone representing the customer. We’ve got complete cross-functional teams – that’s our T-shaped person, our generalizing specialists with one specialty area and many general knowledge areas.
We’ve got one sprint and sprint planning is more formally divided into two parts of what
and how.
We’ve got organic cross team coordination, we’ve got overall cross team refinement (an overall retrospective focused on cross team improvements). This is where we take all of those normal scrum methodologies and we apply them across all teams. For example that retrospective where we can get all of our teams together and say what’s working well
across our teams, not just within the one scrum team itself.
Enterprise Scrum
Enterprise scrum is a framework designed to apply the Scrum method at an organizational level, not just at a single product development effort.
It advises leaders to extend the use of scrum across all aspects of the organization and to generalize the scrum techniques to apply easily at those various levels. We are wanting to scale the scrum method with supplemental techniques as necessary – core principles like stand-ups, retrospectives, Kanban boards and visual management, having iterations and
increments and all of those things.
In other words we’re not precious about which scrum techniques we’re using, but we can add to them whatever we feel works for our teams as long as it helps us scale that method across teams.
Disciplined Agile
Lastly for our scalable methods we’ve got Disciplined Agile. DA is a process decision framework that blends various Agile techniques based on the following principles:
People-first
Learning oriented where we’re encouraging collaborative improvement,
Full delivery lifecycle, where we’re promoting fit for purpose life cycles
Goal driven, where we’re tailoring processes to achieve specific outcomes so we’re looking at results over the process – that’s one of the core things you’ll see in Agile come back time and time again.
Enterprise awareness, where we’re offering guidance on cross departmental
governance. That means we’re still managing across teams whether it’s by
any of these scalable techniques that we’ve seen or just a scalable scrum
technique that seems to be really the core common denominator across all of
these scalable techniques.
Lastly, Scalable, covering multiple dimensions of program complexity and doing that in such a way so using the Agile techniques where we’ve got Visual management across streams and Scrum or stand-ups across teams
All that can help us scale this this approach and help all of our teams work together.
And those are the auxiliary methods and the scalable methods of Agile.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile Practice Guide from the Project Management Institute and Agile Alliance. This one in particular is “Evolving the organization.”
Check out the article and video below!
Evolving the Organisation
When we say evolving the organization, really what we’re talking about is bringing Agile into an organization in a way that also uses the Agile methodology. Maybe traditionally you’ve been using a more linear approach, very step-by-step, very focused and figuring out all the scope and cost upfront, and then being afraid when all that changes as the project rolls out.
But if we’re moving towards more of an Agile approach it’s really recommended that we undertake that work incrementally. In other words we’re actually using Agile, and our Agile way of putting things in the hands of our customers (which in this case is our teammates and our organization) then we’re using that to actually roll it out so we treat the change as an Agile project with its own backlog of work, and backlog of changes or Agile things that we could implement and that could be introduced to the team, based on the perceived value.
In this case our team is the customer so whether you’re leading a team or maybe you’re trying to implement it across an organization, but either way the customer in this case is other people who you’re moving the implementation of Agile onto. That means that the value has to be based on what they perceive the value to be, and that’s very important.
Iterating Towards Agile
When we’re iterating and getting that feedback from the customer as we’re implementing Agile, then we’re putting that feedback back into the process and using what works and discarding and what doesn’t. So when we are are implementing practices like Scrum or Kanban or Feature Driven Development, or maybe Scrum of Scrums across multiple teams, or many other things like the whole team approach and regular feedback using iterations – each of those changes can be treated as an experiment. They can be tested for a short period of time to determine the suitability or need, or to further refine it.
What that means is we don’t have to say “Look everyone, this is happening!” We can instead say “Let’s try it out for one or two iterations,” in this case using Agile terminology again, say four to eight weeks in total, and then let’s round back on it using a Retrospective where we ask is this working well, what didn’t work well, what did I learn and what still puzzles me during this implementation.
Then we can put that feedback back into the process.
Using the Agile Method of Kanban to Track Progress
We can also use Kanban boards to track the progress of the things that we’re implementing – showing the new approaches to use as “done” and the things that we’ve tried as or we’re currently trying as in progress. Again this is another Agile approach. We’ve got all of these things that we want to implement in the backlog – maybe we’re going to move to Scrum, maybe we’re going to use Kanban, maybe we’re going to use the Whole Team Approach or a cross-functional team and some of those will be moving those across into “in progress” and some of those will already be finished.
Assessing the Current Culture
We’ll have gone through that retrospective process to find out what worked, what didn’t work, what we want to keep and what we want to discard. Now before we get into all of this or to start implementing these changes we can assess the current culture and its readiness for a job and tailor a solution to suit.
As we’ve seen there are quite a few different methods and practices that we can use in Agile and not all organizations will want to use all of those practices. One model that we can use to find out what would suit an organization is where we ask:
Do we value exploration more than execution for example, maybe we really really just need to deliver things and we need to deliver things quickly and in that case maybe we can increment and deliver increments every two to four weeks on a regular basis. Or maybe we want speed or maybe we’ll want stability in the team. Which one is more valuable?
Maybe we want quantity maybe we want quality. And maybe want flexibility in our work or maybe want predictability in our work. This will just help us determine which of the Agile practices will be valuable from a team’s perspective. You could use any framework really when you’re figuring this out and what to use from an Agile perspective but the key point is that we want to be understanding the team. Whether it’s just going and talking to the team and saying “Hey what are you currently doing, would this work, can we use it as a test?” and we then get feedback on it, let’s work together. The whole point is delivering value from the perspective of your customer, and in this case the customer is the team.
And that is evolving the organization from an Agile perspective.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
“Servant-leadership is all about making the goals clear and then rolling your sleeves up and doing whatever it takes to help people win. In that situation, they don’t work for you, you work for them.” – Ken Blanchard
Have you heard this leadership quote from Ken Blanchard?
Ken is a well known author and coach in the leadership field, having authored over 60 books including the 13 million best seller – “The One Minute Manager”. Most recently Ken’s thoughts have turned to servant leadership, where the leader serves the team. This really contradicts most modern managers and thinking, where people believe the team should serve the manager.
In fact, both are true – read on to the end to find out why.
The Rise of Servant Leadership
With the advent of Agile and Agile project management and leadership methodologies, we have seen a greater focus on Servant Leadership.
In an Agile environment, Servant Leaders have a few roles.
Servant Leaders Facilitate
Rarely do Servant Leaders dictate to the team. Instead they facilitate discussion and encourage participation. What does this look like? It looks like a leader sitting down and collaboratively deciding outcomes or goals with the team. It looks like a leader checking in every day to see how things are going. It looks like a leader sitting with the team and asking “What’s working well, what’s not working well?” and then putting that feedback back into the process.
Servant Leaders Remove Blockers
In her groundbreaking research on employee motivation and engagement, Teresa Amabile found that employees were at their happiest when they were making progress. And it makes sense, doesn’t it? Now think about your own job. How many times have you been blocked and stalled for reasons beyond your control? You might be waiting on another person or department, on a customer or a payment or in many cases on a manager themselves.
Servant leaders check in with their team every day, ask what is blocking them from achieving their collaboratively set objectives, and help them put the pieces in place to remove those blockers. Maybe it is connecting them with another person, maybe it it having a conversation with a higher level of manager within the organisation, maybe it is improving the process itself, maybe it is raising an issue to be fixed with another relevant team. Either way, servant leaders help their team make progress, and that progress makes people happy.
Servant Leaders Are Coaches, not Bosses
Lastly, servant leaders coach their team. They don’t boss people around, they don’t give orders. As a coach, they don’t need to. But what is the function of a coach? Let’s think about it. A good coach will give you a playbook – they will give you the moves on the field of play and A good coach will give you feedback on your process – not on you as a person, they will not judge – but they will tell you when you’re running the wrong way or if your stride needs adjusting or your pass is on target. They will help you adjust your process so you can continually get better at the game you are playing.
And that leads to Mastery
Lastly, you might be wondering, what is the point of all this? Improving your game, removing blockers, constant practice and improvement – all of these things lead to one of our core driving forces called Mastery of a task. You see – people will go to great lengths to master something they love, are passionate about or are good at, even when they are not being paid. So money has nothing to do with it – they are being motivated by the process of mastery itself.
That’s why people play video games, do woodwork or stitchwork, play sports. It’s also why they take pride in being “that person” who knows how to use the database, or the system, or the sales method. They have spent many hours mastering it and can take pride in their work. And that pride leads to engagement, and that engagement leads to profit.
“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” – Antoine de Saint-Exupéry
Have you heard this Leadership quote from Antoine de Saint-Exupery? He was a French writer, poet, and pioneering aviator in the early 1900s, and his quotes on leadership really hit the mark. Why?
Because only now is the research starting to reveal just how right de Saint-Exupery was.
Start. With. Why.
By now you may have heard of the famous book by Simon Sinek, “Start with Why”. In it he explains the importance of not starting with “What”, not starting with “who”, but starting with “Why” we are doing what we are doing. The overarching reason for us all to be working together is the most important thing that leads to success, profit, and engagement.
Starting with the reason for doing something is also the key to Meaningful Work, and meaningful work has been shown to improve productivity. After all, how many times have you worked on something – maybe a hobby or a task for a friend – simply because you believed it was important? While we need money to survive, money is not the main motivating factor when it comes to doing great things in our work.
Research on Meaning
One study from Wharton University also discovered that meaning had a big impact on the quality of work. Employees in a donation collection call center were allowed to speak with some of the recipients of the donations they collected. Doing that, they could see the real difference it made to people’s lives. After hearing the impact their work had, and using those stories, donations collected by those employees tripled.
They didn’t whip their employees (the classic “stick”) or pay them hefty bonuses (the often used “carrot”). They taught them the meaning behind what they were doing – they taught them to yearn.
Researchers Jaqueline and Milton Mayfield also found the power of meaning in their research on what kind of pep-talks gave rise to action. After clarity or certainty evoking language (the path of what must be done), meaning-making language gave the biggest impact to motivation and results.
Bringing meaning to your work is something that can be done for free. It doesn’t cost a cent to do, all you have to do is be willing to do the thinking up-front with your team, write down your “why” and the reasons your work is important, see the benefits your work brings, and agree to it as a team.
View All The Leadership Cards (48)
Get "The Lean CX Score" now, and start creating disruptors in your industry that completely annihilate your competition. 
