Want to create sustainable change in your organisation that goes beyond the team? Find out in our one-of-a-kind Systemic Agile Coaching, accredited by ICAgile, and earn your Agility in the Enterprise (ICP-ENT) certificate.
On successful completion of our Systemic Agile Coaching course, you’ll receive the ICP-ENT certificate from ICAgile.
Have a question? Get in touch and we’ll reply within one business day.
Focusing your change efforts on the team is not enough. Business agility requires a change of leadership style, organisation structure, culture, and Lean principles at the enterprise level. In this course, accredited by ICAgile and delivered by Laura Re Turner, you’ll learn coaching skills to support the transformation of agile leaders, teams, and business stakeholders.
Build your Agile toolkit to create true business agility with Lean, business process improvement, and customer-centric measures of agility such as OKRs. We will examine two popular Agile scaling frameworks to learn how to approach scaled Agile in a sustainable way.
Ready to get started? Contact us. We’ll respond within one business day.
Answers to your questions from the webinar, my notes, and of course the webinar recording here.
Agile Coaching isn’t just for teams! Leaders have just as much, if not more, influence on creating a culture to beat the competition and stay relevant in today’s fast-paced market.
Agile Leadership coaching helps you build resilience, think strategically, motivate your teams, and plan for the future.
This webinar is for leaders of development organisations, directors, product managers, senior project and programme managers, and HR business partners.
Notes
I promised to send my notes on each the areas that come up for leaders that work in complex and uncertain environments — leaders who want to be agile. Here are descriptions of each of the areas for leadership coaching that I mentioned.
Adaptability
Being able to adjust to new conditions
Resilience
The capacity to remain flexible in thoughts, behaviours and emotions when under stress. For more on resilience coaching, have a look at the work of Carole Pemberton.
Servant leadership
A leadership philosophy and set of practices, defined by Robert Greenleaf, to build better organisations. A servant leader ensures that other people’s highest-priority needs are being served. He said the test of servant leadership is Do those served grow as people? Do they become healthier, wiser, freer, more autonomous? I discuss servant leadership in my book Becoming Agile.
Sense and respond
Sense – acute and accurate awareness of what’s going on in the world and in business, in broad terms. Awareness of the facts. Respond – to make a small adjustment in how we lead or work with others, to move closer to what we want. Working incrementally toward goals or objectives.
Critical thinking
Solving problems through rational processes and evidence-based knowledge.
Cross-silo leadership
Leading with the whole organisation in mind. Helping teams see their work though the eyes of customers, business partners, or suppliers. Read my book Becoming Agile for more about what this means for individual leaders and their teams.
Growth mindset
The belief that we were not born with all of the skills needed for life and work. We can learn and improve through our own effort. For more on this, see the work of Carol Dweck.
Q&A
How do you explain the Agile concept when you coach and in what session do you introduce it to the coachee?
I try to hold back from explaining or ‘telling’ in my work, as much as possible. Some of agile coaching is teaching agile frameworks and techniques, so I only explain concepts if appropriate. As a leadership coach, my first job is to find out what the client wants from the coaching session and work from that point.
How is ‘adaptability’ different from ‘sense and respond’?
Thanks for that great question. The phrase ‘sense and respond’ has to do with taking in a wide plane of information about current events and global trends in business and other arenas (political, economic, social, technological, legal, and environmental). By understanding systemic trends (sense), a leader can then work toward incremental change (respond).
To me, adaptability is a personal willingness to have the courage to throw away the plan when needed, and change to current conditions.
When you are coaching, how do you practice selflessness and how to understand it’s the moment your ego forces you to make the decision and how do you come to the state of ego-free coaching?
I mentioned that a great deal of information about your client and the coaching relationship comes from paying attention to your (coach’s) own feelings, instincts, thoughts, responses. Nevertheless, when coaching we always work with the client’s agenda, not ours.
What tips do you have for coaches on coaching leaders who don’t appear to have a growth mindset? Leaders who are stuck in their ways and are not seeing the reasons to change?
My question back to you is ‘how do you know’? It may seem at first as if someone doesn’t have a growth mindset, however I think what we’re noticing is a resistance to change. That can have many root causes. Tell your client what you’re noticing, and ask for their thoughts. Try giving feedback and asking a question to draw out their thoughts and feelings.
Some people really don’t have a growth mindset, and if your client determines that that’s the case or you’ve seen/heard evidence that convinces you of that, work with your client to understand the strength of their need to learn new skills. I’d ask the client to rate their need on a scale (say 1-5), and go from there.
Transcript of Create an Agile Culture, from the Free Webinar Series to Create an Agile Organisation, on 21st October 2019.Presented by Laura Re Turner, Director, Future Focus Coaching, and Phil Summerfield, Executive Coach.
Welcome – from Laura Re Turner and Phil Summerfield
Most of you know me, Laura Re Turner, I’m an accredited Executive Coach, certified Agile Coach and a Trainer. I help leaders and their teams develop an agile mindset, behaviours and skills to succeed in the very complex and uncertain business environments that we’re operating in today. I’m also very happy today to have my friend and colleague and fellow coach Phil Summerfield with us today; he’ll be co-presenting.
Introduction
The topic of today’s webinar was inspired by questions that we’ve heard so many times from our clients:
“What beliefs and mindset do we really need to have here in order to be successful with agile methods?“
“If we’re going to be successful with Scrum, what is it that we really need to do at the most fundamental level?”
”How do we change the mindset of others?”
“How do we get other people to come along with us and how should we measure success?”
What is organisational culture?
So what is organisational culture? It’s such a big topic and when looking into it we found out that most organisations think about culture as how we get things done around here. That’s the definition that’s given most often. In fact, when we really read the literature on organisational culture specifically Edgar Schein, we found out that “how we get things done around here” typically only points to the visible signs of culture. For example, a leaders reorganise teams into squads or Scrum teams. We’ve also seen many times that a leader gets the team to use a team board or Kanban board and points to that as an example of things changing, becoming more agile. It’s an indication that something is changing but it really doesn’t get right to the heart of the organisation’s culture.
Also things that we can observe are things like in team meetings, the team leader tends to do most of the talking. We don’t know why, we don’t know the reasoning behind some of these action plans or artefacts or visible things that organisations. They start to indicate a certain culture but they don’t tell the whole story — just the tip of the iceberg. Schein describes another level of culture which isn’t as obvious as things like putting our work on a Kanban board. He calls this ‘level two: espoused values and beliefs’. Or, ‘what we say when asked what’s important to us here.’ The trouble is that these things may not be true all the time in practice.
I have a few examples in an Agile context, and I think everyone can relate to some of these. For example, we believe in transparency here. We probably do believe in transparency but we may not have transparency all the time. We believe in the values and principles of the Manifesto for Agile Software Development, but we still micro-manage the team by asking project manager to track technical tasks. Our company values are printed on the wall of every one of our meeting rooms, but nobody remembers what they are.
Schein says that company culture is really influenced by the unconscious beliefs and assumptions that we have about the best ways to work here, the ways of working that have helped us succeed in the past and therefore are taken for granted unquestioned even though some of these ways of working may no longer be useful. And the technical description for that is tacit assumptions.
Here are a few examples:
We develop a comprehensive business case and detailed product requirements before starting any product development work [because that’s what we’ve always done here].
We provide a workplace that allows human beings to work in comfort and safety because that’s important to us, it’s what we value — a workplace that’s physically comfortable and safe for work.
All decisions about whether to release a major version of the platform must go through the Change Advisory Board for approval because releases of new functionality to the production environment are risky.
Uncertain and changing business environment
What we want to have a look at next is the influence of change coming from the external business environment. This is where I would love to hand over to Phil. He’ll talk to you about the PESTLE model and the uncertain and changing business environment.
The PESTLE model helps us think about the different sources of change:
Political
Economic
Social
Technological
Legal
Environmental.
I’m going to use the UK and Apple as examples. What I suggest you might want to do is just note down any thoughts about your own organisation while we’re going through this.
Political– a current one, I won’t go into any detail, changes in our regional trade agreements. You may have your own views on those and using Apple as an example more global how they’re operating in China and the factors that are changing for them there.
Economic– are new tariffs on goods imported into the UK or there could be for a company like Capo as China which does a lot of its development most of it as the society increases or improves rather, the labour costs will increase. How will that affect their business? That’s a massive impact on them there.
Social– the different working expectations of the younger generations these days it’s really starting to have an impact on business because it’s not a job for life anymore so people think and behave in different ways and have different expectations. In the case of Apple, they’re looking at third world use of technology. Is that a dramatically big new market for them or maybe they’re not so interested in it.
Technological– that’s a big thing these days. The disruption caused by new innovations, new ways of working and very relevant to what we’re talking about today. With a company like Apple, well that could flip itself over because my phone it’s also a computer; nearly everyone’s these days. It can be as good as my Laptop or notepad. Does that mean that Apple will start selling far less as more and more the different products look very similar?
Legal changes– how those affect your business national local laws or global laws. In the case of Apple, they’re moving heavily into automotive, how does that affect their insurance and regulatory costs and what happens if my Apple based Satnav directs me in the wrong place? Who do I sue? Do I sue Apple for that? So the question they’re facing there.
Environmental– that’s manufacturing processes are changing, government laws environmental laws are saying some materials we’ve used in the past are no longer acceptable because they’re a danger to society. In the case of a company like Apple, disposal of lithium batteries for instance very, very expensive. So there’s another way of looking the thermal fuse the PESTLE example here. You can also look at some new acronym of hookah, which is volatile uncertain complex and ambiguous. I guess you probably all recognise that as the business world of today.
Handy’s Culture Model
So here we’re looking at organisational culture. This was developed by an Irishman called Charles Handy who you probably all heard of; he’s written lots of books on organisational development. He identified four different cultural behaviours that organisations he looked at exhibited.
Power, which is centralised top-down power and influence.
The role culture and this is bureaucratic run by strict procedures and very narrowly define both roles and powers.
Task-based, this is small teams results based and results-oriented and it’s narrowed by flexibility adaptability and empowerment.
Person culture, which is based on the individual. It’s the people are the most important thing and even the behaviours and processes are geared towards individual success.
So just looking in a bit more detail about those going back to person. It’s really a cluster of stars successful people and the individual is the focal point. If there is any structure there, it’s only there to serve and assist individuals so it’s all about the individual here.
Task-based the emphasis here, well the focus is on the individual expertise and it’s highly, highly valued. The emphasis is getting the job done and the culture brings together the right resources, people and at the right level and at the right time to actually get the success they want which could be completing a project or a program quite common here these days. It depends totally on teamwork – totally. The teams can be formed and then reformed or abandoned where the team can decide to abandon it. So the point there is that the team has the power; they don’t need to go upstairs to actually get decisions about what they’re doing.
Role-based, this is really focusing on the allocation of work within roles. It’s really focused on very stable environments where the markets steady, predictable or controllable or perceived to be. So a good example here would have been the bank’s I guess and insurance companies very slow to change and very slow to see the need to change and they’re having major problems these days because they are role-based.
And finally the power-based organisations. This can be very successful but maybe these days for the wrong reasons. They are very successful because somebody at the centre of power like a spider in a web controls everything. The closer you are to the sense of the web the more power you’ve got and if this can feel sometimes quite unpleasant for the people working within it tough and abrasive and lead to low morale and high turnover.
Mckinsey 7S Framework
Just to carry on from that a little bit, I’d like to expand now our thinking about culture and about agile culture in particular using a model that I use quite a lot in my coaching and consulting work called McKinsey 7S. As you probably figured out it has 7 aspects in each of them starts with an “S”.
Strategy
Staff
Skills
Systems
Structure
Style
Shared values.
A group of McKinsey consultants in 1980 decided that they were leading so many organisational change programs, that there needed to be a holistic way of approaching change and they found that most organisations wanted to focus on the so-called hard aspects of organisational culture more than the others. So of these I think we can guess which of the hard aspects strategy, structure and systems and people wanted to look at these aspects, the more visible or hard aspects of culture in order to make the changes that were required to help a company move forward.
It is probably no surprise by now those of you who know me and my company’s work and the focus of the webinar so far that in order to be successful with any kind of culture change we need to also focus on the softer aspects and those are of course staff, leadership style and shared values. So in order to broaden our idea of what an agile culture means I’d like to take each of these aspects of the 7S framework one by one. I’d like to give you the vanilla definition from the McKinsey Consultants from 1980 and then also give you an example of what we mean by an agile culture for each of those.
Strategy – the plan devised to maintain and build competitive advantage corporate strategy and an agile adaptation of that would look like a long-term strategy is created and can be revised, should be revised based on anything that we learn about the market as we go. In other words because of the change in external business environment our strategy doesn’t stay static. We’re learning as we go.
Staff – the employees and their general capabilities and what that means for us in an agile environment is that employees are trusted and empowered to get the job done according to their own judgment. That also means they self-organise and take on the roles that they need to in a task culture based on a specific project work or product development work that they have.
Skills – the actual skills and competencies of the employees working for the company. They self-organised to build solutions that create knowledge sharing networks as needed based on the current challenges and problems and opportunities that they’re working on in order to increase their capability. So learning is a huge part of organisations where there’s lots of uncertainty.
Shared values – the core values of the company today that are evidenced in the corporate culture and the general work ethic. Examples from the Scrum framework which are very well-known, openness, commitment to respect, courage and focus. We could quite easily point two values and any of the other Agile Frameworks because in Agile we know that values are important but Scrum is probably the best known example of those.
Systems – the daily activities and procedures that staff members engage in to get the job done. So anyone who’s been on a course with me and I think that’s a few of you, know that iterative and incremental development is the heart of all that frameworks, whether it’s Scrum or DSDM or Extreme Programming. Teams’ work iteratively seeking feedback in short development iterations, short cycles to improve the product and the teams’ internal capabilities through retrospectives.
Structure – the way the organisation is structured and who reports to whom. We tend to have flatter organisations with cross-functional teams that are formed to address specific project or initiative.
Leadership style – facilitative leadership rather than command and control. Some people also describe servant leadership, which is certainly one of the definitions of the Scrum master and Scrum. A coaching culture to support employees’ ability to think for themselves. So empowering people to think for themselves and moving away from this hub-and-spoke type of management environment to allow people to be able to work more tightly with each other rather than reporting to a single manager.
Success factors
There are a couple success factors for changing culture. Number one, definitely challenge your organisation’s tacit assumptions, the level 3, the unconscious, ways that we work that have worked for us in the past which may no longer work for us going forward in the future. Remember to think about those unconscious culture like we put all the work on a Kanban board, why haven’t we changed the culture? And second examine all aspects of an organisation not just the organisational structure. This is why the McKinsey S7 framework is so useful for this to help us stay on track.
Ready to get started? Contact us. We’ll respond within one business day.
Transcript of Is Agile Right for Us?, from the Free Webinar Series to Create an Agile Organisation, on 20th August 2019.Presented by Laura Re Turner, Director, Future Focus Coaching.
Welcome
Thanks for joining us today. I think it’s a good idea to start with a definition and when I think of agility, it’s a whole collection of things for me. It’s the mind-set, behaviours, practices, iterative processes and leadership style, which is very important that allow teams to experiment, plan and deliver valuable products with minimum waste. And the reference to waste is a very over referenced to lean which is where most agile methods originate and it’s important to think about sources of waste so that we know what’s slowing us down in organisations. It’s all the non-value-added work that often leads to frustration; partially done work that doesn’t lead to value because we can’t deliver something that’s partially done. It started, sits on the shelf and maybe never gets finished; extra features, re-learning or extra processes, handoffs, delays, task switching and defects.
If we think about the hierarchical and sometimes distributed organisations working in silos kind of old-school organisations we’re thinking of them now, a lot of them have symptoms of a lot of these wastes. I think it’s important to provide a definition because the way the word agile is being used lately is as a thing or a process or a methodology. I’m hearing the word methodology more and more these days, which is interesting. I’m always reminded of Dave Thomas’s terrific blog where he says “Agile is not a noun” it never was. If you look it up in the dictionary it’s not a noun. To us when we think about how to be effective and get the most value from being agile and agility, it’s important to think of whole collection of behaviours, mind-set, leadership style and processes and tools that help us be flexible.
Manifesto for Agile Software Development
You’re probably aware of the manifesto for agile software development and this is perhaps where the word kind of caught fire agile. And I remind people that being agile is really about the left hand statements and yet when we use agile as a noun it makes us think of a single process or a software development life cycle or the one methodology that we need to adopt to be successful. So I don’t want to say too much about the manifesto because I know so many people have seen it but I think it’s important to remember that agility is a way of working and not a single process.
Should everyone use an agile approach now?
So we get questions all the time in our training courses; should everyone use an agile approach now? Should everyone be agile? Should everyone have scrum teams and scrum masters and throw away documentation? I’m just wondering what questions you have about that? I haven’t seen any questions come into the Q&A yet, but perhaps you have some burning questions about whether or not one of the iterative processes or methods or frameworks that we’ve heard of before is the best one. Is that the way to go? Is there a reason the whole world seems to want to be agile now?
The case for agility
Well things that we’ve heard from our clients are for example; new technology and new delivery platforms have allowed start-ups to get new products, niche products to market quicker and they’re actually taking away market share for some of the products that we have that we’ve enjoyed a good sales on for quite a long time. Also, we’ve heard things like small companies with flat organisation structures can organise their teams to be more nimble, to come up with ideas and to be able to organise themselves quite quickly to work on new initiatives much more quickly than we can.
We’ve also wrote things like we have a really hard time predicting how changes in legislation will affect us, especially from the government agencies that we work with. To make the company look more attractive when we look for a buyer; getting ready to sell the company and we want to make the company look a little bit more attractive – interesting.
Poll: What are your Reasons for Becoming ‘Agile’?
So, I’m wondering what are some of your reasons for becoming agile? It wouldn’t be an interactive webinar without a little poll and I thought it would be interesting to find out from you what are some of your reasons given in your organisation for becoming agile? So I’d like to invite you just to choose as many of the statements that you think apply to you and choose as many as you want and go ahead and vote and we’ll take a minute to give you a chance to read through the options and let’s find out what you think.
It looks like everyone’s voted; I’d like to show you the results. So 33% said to reduce costs and actually we’re hearing more and more that people are looking to use an agile approach to reduce costs. 50% said it’s to stay competitive while delivering innovative products and then 83%, the majority said that the reason for becoming agile in our organisations is to reduce the time that it takes to get new products and services to market. So it’s about time and speed. I thought it would be interesting to throw in a few slightly humorous reasons because the competition is doing it and sometimes there is a real reason although perhaps not stated explicitly or out loud.
The wider community: Reasons for Becoming Agile
So I thought it would be interesting also to see what were some of the reasons that other people more widely in the community said that they were becoming agile, what were some of the reasons? If you’re anything like me you tend to follow the reports and anything that’s reported on where the market’s going and where organisations are moving to and the reasons for adopting an agile approach.
Well, I thought it would be interesting just to take a snapshot from Version One’s annual State of Agile report; this came out in May and they surveyed thousands of people working in the domain every single year. Perhaps not surprisingly, most people said in response to the survey that their top reason was to accelerate software delivery very much like the reasons that we stated in the pole.
Enhancing ability to manage changing priorities which really speaks to the amount of change in the external business environment and the uncertainty that we’re experiencing now. To increase productivity is interesting. I think there’s a perception that using an agile approach will somehow make us faster; perhaps it’s the daily stand-ups that people love and to improve business of IT alignments – that’s a massive one. I would love to see more people stating that as a reason for becoming agile because it’s one of the biggest things that we can do actually to increase our ability to change is having a real business focus right the way through all the functions including the IT function. I’ll leave you to find this on the web Version One.
So when I published the topic for the webinar, I thought it might be interesting to think about the processes a little bit. Even though we say in the Agile Manifesto that we value individuals and interactions over processes and tools people are always interested in what should I keep? How much of project management methods should we keep and how do we decide? Well, I wanted to give you a few examples of the best-known agile approaches and methods that I think are in use today and being combined.
Scrum- Scrum remains extremely popular if you have a look at the Version One report. Scrum is a product development framework and helps teams to create a habit of learning how to improve. I often get questions like ”are we doing it right?” “What are we leaving out and what’s the impact of not having a sprint review or doing the daily stand-up?” To me, Scrum is a way of creating good habits to reflect and improve their processes, and improve the requirements for the products that they’re building.
DSDM- Another popular one is called DSDM, also known as Agile Project Management. It’s a project management framework and parts of it look an awful lot like Scrum. It can be in fact combined with Scrum if you are delivering projects. So I think one of the traditional mindsets is that when we move to Agile, we’re actually replacing everything that we’ve done before with a new methodology or a new process and in fact many people don’t think about combining the popular approaches. In fact, when we’re delivering projects, we need some kind of project governance so there’s no reason why we can’t combine Scrum and DSDM.
Extreme Programming- Likewise for software projects, most people are aware of test-driven development and continuous integration, but few people realise that that whole suite of practices comes from Kent Beck and all the guys that created extreme programming back in the early 1990s. And for software projects we absolutely need test-driven development and continuous testing and checking to be sure that we’re fixing the bugs that we create so soon as possible.
Lean- So that together with the lean mind-set of reducing waste together to me that’s a whole suite of practices and processes that we should be using in combination.
Critical success factors
It’s important to think about critical success factors.
Having a shared business vision and understanding business outcomes both among the business stakeholders and the guys who deliver the products and projects it’s really, really important, everybody has to understand why we’re delivering the project.
Effective teams and what we mean by effective teams is really a whole list of things. We know that small teams is really, really important for communication and even better when we can see each other because it just reduces miscommunication.
Stable and cross-functional. There’s nothing worse for killing productivity than asking people to work on two or three things at once. To me is kind of like trying to get your chores done on a Saturday, you know, the cat comes in and wants to be fed and the husband is in the garage playing with paint cans and needs a hand with getting a rag or an emergency clean up. The postman knocks on the door and has your Amazon parcel and at the same time you’re trying to get the hoovering and the dusting done. When you’re working on three or four things at once, it seems like everything is in progress and nothing’s getting done. So protecting the team to be able to focus on one product or one project at a time is important and really allowing them to make changes to the process and their practices in the way they get the work done so that their practices are fit for purpose.
Iterative development – evolving a small idea to a finished feature is really, really important and taking on very small pieces of work just like in lean where we prefer to work on small batches of work so that we can get something started and finished as quickly as possible.
I have another quote for you. This comes from the Harvard Business review article.
For me the really key word in that whole sentence is learning. The agile methods for me really come down to the ability to learn and get transparency and find out more about the processes and tools that are really working for us and the practices that are going to lead to success and what the customer really wants and the features that are really resonating with them. The requirements that we might have put on a backlog or requirements list that are no longer needed because either the markets moved on or something else come in and becomes more important to us.
Ready to get started? Contact us. We’ll respond within one business day.
Transcript of The Project Manager’s Changing Role, from the Free Webinar Series to Create an Agile Organisation, on 1st October 2019.Presented by Laura Re Turner, Director, Future Focus Coaching.
Good afternoon everyone. Thanks so much for joining the webinar today, The Changing Role of the Project Manager.
What I want to cover today on the webinar is understanding how the project manager’s role changes when we’re using an Agile Project Management approach. Working in an agile environment where we’ve chosen to deliver a project in a very complex environment that has lots of business change.
Agile Project Management
I’d like to give a little introduction to Agile Project Management. Why might we use Agile Project Management over a traditional approach? Well, organisations that want to adapt their project planning practices to complex and changing environments will use an Agile approach which has very short planning horizons and allows us just to commit to a small amount of work at a time. Then decide based on what the business needs next in another short planning horizon of usually a month or two months what needs to happen next. By committing to a very small amount of work at a time, it allows the business to change direction without having a difficult conversation about what to do with work that has been started but not finished.
Many organisations that want to use Agile Project management will use the Agile Project Framework. It’s based on Dynamic Systems Development Method (DSDM) and it is owned and maintained by the Agile Business Consortium. Scrum is the most popular for all the Agile frameworks in use today, but it’s only part of the story.
My favourite quote perhaps from the framework is the philosophy.
“The best business value emerges when projects are aligned to clear business goals, deliver frequently, and involve the collaboration of motivated and empowered people.”
Agile Project Management Handbook V2
And this is different to most project management frameworks that we might have come across, which shall remain nameless today but we all know what they are. Frameworks that tend to be very process driven and heavy on, traceability, and documentation, and delivery of management products and artefacts. In agile projects, we emphasise the motivation and empowerment of the team in order to deliver the right solution for the business in a timely way. So project managers now have to be agile leaders as well as managers of time, cost, quality, and scope.
Who is the PM in Scrum?
Now I mentioned Scrum and we’ve seen the polls. Those of you who attended my previous webinars know that Scrum is still, after many years, the most popular of all the agile frameworks in use today. In fact, when I work with my clients, I often hear “we don’t have project managers anymore” and it takes me by surprise because we still have projects. So why shouldn’t we have a project manager to hold the budget, and on-board resources, and manage risks and issues? I think this belief that there is no more project manager is that there is no project manager role in Scrum.
Scrum is a product development framework, not a project management framework. Many organisations have successfully adapted their project governance and planning practices to bring in the iterative development, and empirical planning style, which is very popular in Scrum and very effective when done well.
However, I meet people all the time who are looking to get some guidance on how to adapt their project management and the governance around Scrum. This is where Agile Project Management based on DSDM is full of terrific guidance. What we need to do is now start to think about two things; the leadership style of the project manager to be more facilitative than command and control; and use high level outcome-based planning to manage the team.
Motivated and Empowered People
First of all, the leadership style motivated and empowered people, motivated and empowered teams. The motivation of team members comes from allowing them to take responsibility for how they design and deliver products, solutions, and services that the business needs. Empowerment comes from trusting team members to make decisions within their areas of authority.
Agile PM Skills and Behaviours
High-level agile-style leadership for the team uses clear descriptions of the project goals, facilitation and coaching conversations to support the team. The project manager coordinates at a high level and leaves the detailed planning of the actual delivery of the solution at the task level to the team.
Some more details about what an agile project manager does in terms of their skills and behaviours, which is different to what we usually think of when we think of project managers:
Agile project managers perform high level project planning but not detailed planning inside sprints or time boxes.
Agile project managers still manage risks and issues but in an agile way. They are highly available and visible to the team.
Responsive handling problems escalated from the team in a management by exception way.
Monitoring progress against the high level plan. For example, a release plan as they’re called in scrum or delivery plans.
The project manager also motivates and ensures the impairment of the teams to meet their objectives, manages the working environment, including the physical locations of the teams to ensure they have face-to-face communication as much as possible.
Help and guidance to team members where difficult situations arise.
Ensuring effective and timely communication and provision of information to the project governance board and stakeholders. So stakeholder management and good communication is a huge part of this person’s role.
Outcome-Based Planning
I’d like to give you an example of what I mean by outcome-based planning. What I’ve done in the slide is I’ve really separated out the project manager’s high level view of the plan versus the team’s detailed view of the work that they deliver in very short planning horizons. So a project manager will typically have this outcome-based view or high-level view of the project and what needs to be delivered. The plan must describe business dates, release dates that are important to the business to meet business goals. Objectives of the plan releases which should be able to be described in one very clear sentence.
For example, the objective of this release is to announce to the world that we sell books online. Release two the objective of this release is to communicate to the world what types of books are in our catalogue and which market segments we appeal to. Release three, the objective of this release is to provide additional ways for people to order and pay for books online. It’s very high level and does not at all get into the detailed work that the team needs to do because team members are the experts on how they can achieve the business goal or the need or the goal of a release.
Below the dotted line on the slide is where I’ve shown the team’s responsibility and the details on each sprint backlog or timebox plan or the team’s detailed plan of what they’re going to deliver in a two or four week period is entirely the team’s responsibility and we’re still seeing a lot of agile project managers assigning work or getting involved in how the team is working at the detailed level. This is one of the behaviours that we’re working hard to change. If we find that there’s some discomfort in project managers moving towards this very hands off kind of view of how they work with the team and allowing the team to decide how they deliver the work well, we have some leadership coaching available for you.
Note that what I’ve not done below the dotted line is fill in or illustrate the details of each and every sprint because in scrum we do empirical planning, meaning we look at the results of each sprint in order to understand what needs to be planned at the detailed level for each subsequent sprint. How does the team know that what they’re planning is the right thing? They always have that high level plan managed by the project manager in order to relate the work that they need to do at the detailed level back to the objective statements at the high level. We cover this in our Agile Fundamentals course.
Benefits of Agile Leadership
I think it’s fair to say that there are some benefits of this style of leadership and management. For example, one of the project manager’s responsibilities we said was to facilitate meetings and have informal discussions with the team when problems arise. When the team makes decisions themselves about the evolving solution, it allows for them to create more options to solve problems rather than taking direction and executing the decision made by a single person.
Using agile-style leadership for example, with coaching conversations rather than telling the team what to do or giving direction, and using more open questions than giving solutions, encourages the team members to think for themselves. This leads to greater commitment and buy-in to decisions that the team makes and ultimately leading to greater quality of the work that the team is doing.
When the PM’s high-level plan shows the business goals and drivers and key business dates, then the team understands why it’s being asked to do the work so that the team members can change and adapt the plan at the detailed level from Sprint to Sprint, not just delivering tasks blindly.
Q&A
So I hope that really what’s your appetite about agile style leadership of the project manager and the new focus of that role. I’d love to hear your questions and I see that some questions are starting to come in, which is wonderful and I would love to just take a moment here and pause and allow you to think of any questions that you have about the benefits of agile-style leadership. Perhaps some of the responsibilities that are summarised here. For example, the coaching skills or facilitating meetings or any queries or concerns about high level planning and what might be included in that high level plan or left out.
So some terrific questions coming in. I have a question from Alan. His question is, if you have two agile teams developing a product in parallel, would you expect the product manager to manage dependencies?
There is a manager, who oversees the teams and whether that person is called a product manager or a project manager, if it is a project with a budget that’s been allocated and a business case, there should be someone who can manage the working environment. This is what we mean by managing the working environment; understanding any dependencies between the teams and trying to reduce those dependencies by working with the teams to look for options as much as possible. When we add teams that are dependent on each other for parts of the solution, we increase complexity. (For more on scaling and complexity, join our Systemic Agile Coaching course.) Where in agile projects we’re looking to only deliver small pieces at a time in order to reduce the complexity of delivering very difficult solutions. So typically a project manager will also have that 30,000 foot view and be able to see across teams.
Thanks so much for the questions coming in. Virginia says she’s heard the term product owner or scrum master, which is closest to the project manager role? These are fantastic questions and ones that I get all the time. The product owner and scrum master roles come from scrum. And in scrum the product owner is the voice of the customer, the person who knows the most about the business value or business benefits that the team is expected to deliver. And the scrum master is a facilitator, sometimes also a member of the development team and working as a team leader.
So which one is closest to the project manager role? Very interesting question. I’m seeing a lot of organisations assigning the scrum master role to the project manager. I guess at first when I started working with AgileFrameworks, I didn’t really question it. Then I realised that in projects the project manager knows the most about the value that the project is meant to deliver because the project manager then needs to report on that progress to the project board on how the team is achieving the business benefits that we’re expecting. So to me the product owner role is really the closest to the project manager role and the scrum master role tends to be a trouble-shooter or a person who’s closest to the team, who knows many people in the organisation to help the team unblock issues and solve problems.
There’s some more questions coming in. Phil it’s really great to have you on the webinar today. Phil is a friend of mine, an excellent leadership coach and someone I do a lot of work with. He asks if the PM is working at a higher level, who’s responsible for spotting the interface gaps where the cracks in the woodwork? That’s a terrific question. Well, often there’s someone who has a little bit more experience and is able to help to see some of these issues as they arise and work with the team. That is often the Scrum Master or a the team leader.
In fact, Agile Frameworks, DSDM, Scrum, Extreme Programming, all of them have regular touch points for the team to be able to identify these cracks or interface gaps or issues while they’re still small before they become massive problems. For example, in scrum we have a daily scrum, which is a 15 minute meeting held at the same time, in the same place every day for the team to be able to identify these issues. DSDM calls it a daily stand up meeting. So does extreme programming, a daily stand up. These meetings are 14 members to be able to discuss what’s going well, what’s not going well, how can I help you today? How can I show you what I did on another project that was similar that might help you with this? When I’m finished with what I need to do today, I’m happy to sit with you and we can put two heads together.
Sometimes we’re finding that teams in those daily meetings aren’t having those open conversations. I have seen some evidence of different reasons for that and often, it comes down to leadership style. Often when team members aren’t really trusted and empowered to make decisions to achieve a goal for that short planning horison, that two week or four week sprint, then they feel afraid to step up, and ask questions, and to openly describe problems that they’re having. Things tend to be kept to themselves.
So when the leader demonstrates that issues happen, problems occur and I trust you to find the right solutions to the problems come to me when you’re really stuck, then team members tend to talk about those things more openly. If when there’s a problem, the agile project manager is available to step in, there is nothing else that’s more important to an agile project manager than responding as soon as the guys come out of the daily stand up meeting and say the team down the hall has hijacked our test environments and we’re not going to be able to get our integration testing done by Thursday afternoon, which is the deadline that we had. So in fact, the motivation and the empowerment and the trust helps to spot these small problems quite quickly.
Often when team members aren’t really trusted and empowered to make decisions to achieve a goal for that short planning horison, that two week or four week sprint, then they feel afraid to step up, and ask questions, and to openly describe problems that they’re having.
We have another question from Alan. Thank you so much. We have the same issue, he says, our project manager is the scrum master. For me I don’t think it works. So interesting. It’s, yeah, I’m not sure where the pairing came from. I think I’m seeing a lot of organisations who maybe see this word master or scrum master. Like this is a person who is a task master or someone who’s in charge, and is responsible for orchestrating, the team somehow. I think some of the interpretations of the scrum master role kind of lost focus a little bit. In fact, the project manager as well as the scrum master role are more hands off, more facilitative than command and control. More management by exception, which means give the team some space and allow them to solve their own problems. As soon as there is an issue, we jump into action and we make it the most important thing for us to solve for them.
More questions coming in, brilliant. Thank you very much Virginia. I’m really happy that you found it really interesting about the scrum roles. Virginia says she’s a project manager who likes detail, a business analyst by trade. I like detail as well, I’m with you Virginia. I’m really not sure where she would best sit in the agile framework world, what a terrific question.
Well business analysts have some terrific skills with regard to properly analysing the business need and ensuring that there’s proper communication for everyone to understand the proposed solution and to gain buy-in. So the business analysts really I can see fitting in to either, the team leader or a scrum master role or the product owner role because the product owner often knows the most about the business need and can write very clear requirements to help the team.
So a business analyst in an agile environment needs to really manage change very carefully. We had a lot of traditional business analysts who would appear at the start of a project with a list of 5,000 detailed requirements and hand it over to the team and say, yup, this is exactly what the customer wants and they signed it in blood. Good luck and I’ll see you at the end when it comes time to do testing and I’ll see you then. Well, in fact, it’s more important than ever now for the business analyst to remain engaged because the focus of the team can change from sprint to sprint as they decide how best to achieve the business need that was described in the high-level plan.
Ready to get started? Contact us. We’ll respond within one business day.
Transcript of Get the Most from Scrum, from the Free Webinar Series to Create an Agile Organisation, on 10th September 2019.Presented by Laura Re Turner, Director, Future Focus Coaching.
Good afternoon everyone. Thank you very much for joining us. I’m the Director of Future Focus Coaching, Laura Re Turner. Welcome to our webinar series on creating an agile organisation. This webinar Get the Most from Scrum, will help you think about the value of using the Scrum Framework and what it takes to get the most value out of using Scrum.
Welcome
Today’s webinar will be for 30 minutes and the presentation part of the webinar will be 15 minutes, followed by 15 minutes of Q&A. The webinar finishes at 1:00 PM and it’s being recorded. The recording will be available on our website this afternoon at http://box5252.temp.domains/~futurhu6/webinar-series-recordings/. I also want to let you know that this webinar is part of a series. We held our first webinar ‘Is Agile Right for our Organisation?’ on the 20th of August, just a few weeks ago almost. People were on their summer holidays. It was great to have such a fantastic turnout for that. Today is the second in the series.
So if you joined us for the first webinar, you’ll know that I like to start with a definition. It’s good to level set and understand what we mean when we talk about Scrum. What better way to find out what Scrum is, than by getting a definition from the Scrum Guide.
“Scrum is not a process, technique, or definitive method. Rather it’s a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.”
The Scrum Guide, scrumguides.org
So interestingly, scrum is saying that any processes, techniques, and tools and other methods that you feel you need to use in order to be effective at delivering a product or a project are ok.
Reasons organisations use Scrum
So Scrum Alliance does a survey every year. In the most recent State of Scrum survey from Scrum Alliance, respondents to the survey said that the top three reasons for adopting Scrum were to deliver value to the customer, flexibility and responsiveness, and quality.
Feedback loops of Scrum
What attributes of the Scrum framework give us these features to deliver value to the customer and flexibility and quality? These are achieved when we use the feedback loops of the Scrum framework. [Feedback loops have their origins in systems thinking and you may be interested in our Systemic Agile Coaching course.] Scrum’s meetings are used for examining feedback on what the team has just completed in the previous few weeks, and deciding what to do for the next few weeks.
For example, a planning meeting uses feedback from the previous Sprints to decide what should be delivered in the next Sprint, which is typically two to four weeks. If you say you’re using Scrum and you’re not asking for feedback and using it for forward planning, you’re not using Scrum as it was intended, and you won’t get the benefits organisations expect from Agile.
Do your Sprint Reviews
To get the most value from Scrum, you really need to do your Sprint Reviews. The team must have a Sprint Review with business stakeholders, not just a Product Owner.
This helps the team adapt the product requirements to get the work done in priority order. It helps business stakeholders understand what the team’s working on, and it builds trust and helps the team shift focus when at the end of a Sprint, which is a few weeks long, they find out that the business priorities have changed and they need to do something slightly different.
Do your Sprint Retrospectives
Also to get the most value out of Scrum, do your Sprint Retrospectives. These can be a little bit uncomfortable because in a Retrospective the team talks about which processes, techniques, and interactions among the team members are working or not. This is really where you’re starting to get the most value out of the Scrum framework and where the hard work is done. This helps the team adapt its processes, behaviours and mindset to be more effective.
I’d like to offer you a quote from a certified Scrum Master from State of Scrum Report.
“Scrum is not difficult to implement. The discipline, commitments and capabilities required to be good at delivering real value frequently, and often are hard to master. It takes a lot of work. Teams and organisations suffer from technical and cultural debt. The difficulty is not really scrum; it’s the technical and cultural debt. In these cases, scrum is doing one of the things that it’s great at- making a team’s problems transparent.”
So I’m interested in what some of the questions are that you have, some of the things that have been working well or not. Please use the Q&A window to submit your questions. How long you’ve been using Scrum? What are some of the challenges you’ve run into? What’s happening in your Sprint Retrospectives? Do business stakeholders attend, and what kind of feedback are you getting from them? Are you doing your Sprint Reviews with your stakeholders? Are you doing your Retrospectives with the team?
Thank you for your questions.
You’ve been using Scrum for four years and as you say, the biggest challenge is building trust with customers. The real challenge is bringing them on the journey with us so that they can start to see that the iterations and the work that we’re doing is really leading to something that’s valuable. To do that, they need to be committed too, and they need to join us for all of the Sprint Reviews.
It’s difficult in a distributed environment when the Product Owner is not the real customer. One of the challenges that we’re finding often is that the Product Owner who is meant to be a representative of the business requirements and the voice of the customer is not a real representative. That the person is perhaps appointed or reluctantly asked to be the Product Owner to the team when the person perhaps doesn’t have the experience to understand what the customer really needs and how to get the requirements or perhaps the authority to make decisions about the priority of the requirements.
Another participant on the webinar said that what he’s done is really to get feedback from people using their product, which is a mobile app, who may be difficult to reach, difficult to get involved in product development. So a Product Owner has to be creative and be a little bit innovative and think about how best to represent the actual users of the app.
Another comment from you is about working iteratively and finding out what the customers, the end users, really need. The temptation is, when planning a big project, to want to start to feel some certainty and get some plans written down and understand what we’re going to be delivering for the next 6 or 12 months. One of the biggest mindset shifts that we make when working in an Agile way is understanding how to use iterations of the product to find out from our end users what they really need next. To do that, we need to suspend the temptation to plan months of work in a project, to try to have certainty.
How Can We Help?
Thank you so much for your questions. It’s been great having you today. I wanted to let you know about some of the work that we do at Future Focus Coaching and Development. We work mainly in two areas:
Business agility Think about how often you’re asked to do more with less, deliver faster, or create the next killer app to deliver more. • You need to prioritise your work and deliver product versions incrementally. • Enable the right people to work together regardless of where they physically sit in the organisation. • Develop strategic thinking and plan by business outcomes instead of tasks. • Learn how to influence your colleagues, customers, suppliers, and business partners to come with you on the journey. So for this, we work with leaders in order to develop an agile mind-set and behaviours.
Motivated teams The sparkle of passion and team members comes from giving more responsibility to help the business achieve its strategic goals. Product development teams are most effective when they’re part of the planning process, and they can generate options and shape solutions to problems. Build knowledge sharing networks that can identify end-user’s true needs and possible solutions faster than the hub and spoke management style fostered by command and control management of single individuals.
Catch up on the ones you missed. Our free webinars answer your most important questions about becoming an agile organisation, in 30-minute sessions that you can watch now.
Create an Agile Culture on 21st October 2019
What beliefs, mindset, and behaviours are needed to be successful with agile methods? How do we change the mindset of others? How do we measure success? What can we change in our org structure now?
The Project Manager’s Changing Role on 1st October 2019
Yes we still need project managers in agile organisations that deliver projects. Find out how project managers need to adapt their leadership style to motivate the team, and focus on business outcomes instead of tasks.
Get the Most from Scrum on 10th September 2019
We’ve heard it many times: ‘Are we doing it correctly?’ Find out what really matters in Scrum. Empower your team to learn fast from mistakes, and get new products and services to market quickly.
Is Agile Right for Our Organisation? on 20th August 2019
We look at the basics, such as when to choose Agile over traditional methods, and why you should combine Scrum, DSDM, and Kanban. Which of your existing processes you should keep?
Ready to get started? Contact us. We’ll respond within one business day.
Becoming Agile
The worlds of Agile development and professional coaching come together for the first time to show how organisations become Agile in more than name only. For all leaders, coaches, and change agents.
