The top three reasons for adopting Scrum are to deliver value to the customer, flexibility and responsiveness, and quality. These are achieved when we use Scrum’s meetings as feedback loops. Scrum’s meetings, or events, 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.
Doug Bromley, Technical Product Owner at 6B Digital, attended our Agile Fundamentals course in November. He chose to do his Lessons Learned Log, the final work for the course, as a mind map. And what a mind map it is! We loved it so much, we asked him if we could share it with all of you. Thanks Doug!
Our Agile Fundamentals course, accredited by ICAgile, helps you experience the Agile mindset and principles that underpin all of the frameworks. You’ll learn how to use and combine Scrum, Kanban, Agile Project Management, Continuous Integration, and Lean Startup. Fix problems with late releases, lacklustre development teams, and plans that are destined for failure.
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.
The results of the latest State of Agile survey are in. The annual report, released on 7th May, is the 13th from the software vendor VersionOne. Over 1,300 people were surveyed, most working as Scrum Masters and internal coaches (34%), development managers (15%), and project or programme managers (11%).
Takeaway 1: We need the right culture to be successful with agile
The report says ‘organization culture issues remain the leading impediments to adopting and scaling agile’ along with ‘inadequate management support and sponsorship’ as barriers to getting the value from using agile methods. ‘Executive sponsorship’ was given as a critical ingredient for success.
“Culture eats strategy for breakfast” is the well-known saying that means all of the best business planning and execution will fail without the right culture to support you.
But wait a minute… we’ve known, for almost 20 years, the culture needed to get benefits from agile methods such as Scrum, XP, and DSDM. It’s described in the values and principles of the Manifesto for Agile Software Development. So what’s the problem?
Most coaching in organisations has focused on delivery teams, however my own research has shown that organisations realised the most benefits from agile methods when the delivery team had business representatives committed to achieving the product or service delivery goals. Strong relationships must be in place across functional areas. It is leadership’s role to ensure this happens.
Takeaway 2: Organisations are still over-reliant on Scrum alone
On the chart showing the agile methods used by the organisations of the 1,300-plus respondents, the agile project management method DSDM is nowhere to be seen. And yet, most people I meet who use agile methods are delivering projects. Pure Scrum (not combined with other methods) is used exclusively, said 54% of respondents.
One wonders what mindset and tools were adopted in place of traditional project management. Anecdotally, agile teams still are, generally, working at odds with PMO and other project governance functions.
The State of Agile survey results seem to corroborate what I’ve experienced in my work with organisations: the project controls that organisations put in place to de-risk their hefty investments in IT systems delivery are not adapting to uncertainty. They are being ignored, though the need to control and de-risk projects is still as high as ever.
I’d like to see agile evangelists working together with project governance to build a common mindset – they could use the principles and techniques of DSDM, for example, and adapt them to their own environment.
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.
