This post was originally published on ItemsOnTheLeft.com.
Author Carol Dweck has completely changed the way I approach the world.
I’m a smart guy. I’m no genius but I’m pretty smart. Through most of my life, I’ve been able to get by just by being smart. For the most part it has turned out to be a pretty good strategy. I complete tasks in less time by thinking about them longer, I demonstrate industry knowledge (thus impressing my bosses) because I can hold a lot in my big fat brain. The problem is, I allowed the world around me to turn my smarts into my identity. It became my brand, and I felt a constant subconscious urge to protect that brand. As a result, I would avoid any attempt at a challenge to my intelligence. Unfamiliar things were anathema because not knowing about them made me look not smart. I avoided anything above my cognitive pay grade, and chose the activities that allowed me to shine.
Kinda limiting, don’t you think?
Enter Carol Dweck. She wrote Mindset, a book I find myself recommending in just about every conversation I have. In it, she describes me exactly. I had, as she describes in her book, a fixed mindset. Someone with a fixed mindset believes that intelligence and abilities are fixed; you’re either born with them or you’re not. A growth mindset, however, is one that believes that intelligence is not fixed and that, with enough effort and grit, anyone can be brilliant. The message isn’t new; it’s basically a very detailed version of, “Whether you think you can or you can’t, you’re right.” But what is new, as she explains in her book, is the science and evidence behind that way of thinking.
She compares John McEnroe (fixed mindset) to Michael Jordan (growth mindset). John McEnroe would blame everyone but himself when he lost a match, but Michael Jordan consistently put in the effort to become the best basketball player ever. McEnroe wouldn’t allow himself to be labeled as someone who has something to learn, he considered himself a born tennis great. Jordan, on the other hand, was always learning, always trying to make himself a better player.
Since reading the book, I’ve looked at the world in a completely different way. Instead of looking for opportunities to show off my intelligence, I’m looking for opportunities to grow my intelligence. Instead of gravitating toward subjects with which I’m already familiar, I’m entering into new and unfamiliar domains. I’m learning about sales. I joined an indoor soccer team. I’ve always considered myself rather bad at sales and just plain awful at soccer. I’m no longer embarrassed to say that I don’t know something. Instead, I’m eager to learn about it. I don’t allow failing to result in labeling myself as a failure. Instead, I learn from it.
I value learning. And there’s a lot to learn in the domain of software development. Because it’s hard.
I believe the creators of the Agile Manifesto value learning as well. They just went about expressing it in a different way. Take a look at the first sentence:
“We are uncovering better ways of developing software by doing it and helping others do it.”
Imagine, instead, if this first sentence was written like this:
“We have uncovered the best way to develop software through academic research.”
We are uncovering better ways of developing software. We’re still trying to figure this thing out. We’re still learning. Just like doctors who say they “practice” medicine because they haven’t perfected the science, I think that we’re practicing Agile because we haven’t perfected the process. And I don’t think we ever will. That’s why we always have to be learning.
By doing it and helping others do it. By digging in, failing, and learning – we’re putting our reputations on the line by experimenting with software development approaches in settings where money is at stake.
Learning is everywhere in the Agile mindset. We learn from our customers through rapid and frequent feedback. We learn from each other through regularly scheduled retrospectives. We respond to change because we learn about shifts in the market. We rework and refactor because we learn that there’s a better way to lay down code. To truly be Agile means to be in constant learning mode. To be Agile requires a growth mindset.
Have you noticed that the term “best practice” is hard to find in the Agile canon? That’s because there really are no best practices. We implement, we retrospect, we tweak. With all that tweaking, how could we ever settle on a best practice? If we’re too focused on implementing the best way, we’ll never find the better ways.
I offer an additional Agile value: Learning over Best Practices. While there is value in best practices, we value learning more. I’d like to know where you stand on this. Please drop a comment or hit me up on Twitter at @johnkrewson. Maybe I can learn something from your feedback.
You used to practice them, but then got sloppy.
Or you never really learned to practice them that well before the need to scale was pressed upon you, and now things are growing up and out too quickly to go back and shore up the details.
How do I know this?
I’m just playing the odds that your organization probably falls into that very large group that is struggling to realize the potential of Agile. And I’m considering what I observe all too frequently to be at the root of the struggle.
We all know what we have to do if we want to get in shape, right? Eat better, eat less, and exercise regularly. Simple. So why does the fitness industry rake in tens of billions of dollars annually, while the incidence of obesity and diseases related to lack of fitness keep increasing?
Want to build a financial nest egg? Save and invest more, and consume less, of course. Again, very straightforward, but current research indicates that 76% of Americans are living paycheck to paycheck. Why?
For both of the above, the answer is, more often than not a) the delusion that “the normal rules don’t apply to my situation”, and/or b) a lack of discipline.
Ineffective Agile adoptions, including enterprise-scale transformations, can be traced to these same two causes. In fact, this applies to most things that we human beings don’t follow through on.
So why am I pointing out something so obvious and so universal?
Because I don’t want you to fail.
I don’t want you to run out and buy the Agile equivalent of a Treadmaster 9000 and a “Get Rich Tomorrow” home study course, only to find yourself sick and broke a year from now.
Is your organization holding onto collaboration-killing and throughput-throttling processes, based on the rationale that your business domain or product or technology mix is more complex than that of everybody else who is practicing Agile?
Is it shaving the sharp corners off the parts of Agile that are uncomfortable, either leaving gaps or replacing what was removed with something softer and more accommodating of the status quo?
True, successful Agile enterprises are continuously inspecting and tweaking how they do things. That’s how they get better. But they are tweaking the application of the fundamentals, not the fundamentals themselves.
Even “seasoned” Agile organizations plateau, and then seek out some advanced Agile concept or technique that is guaranteed to take them to the “next level”. But there is none.
No professional sports team’s coach says, at a post-loss press conference, “Well, we were just one or two trick plays away from winning this.” No, what they actually say is, “We didn’t execute on the fundamentals, and it cost us the game.”
The secret to Agile success is that there IS no secret. Success comes through relentless improvement in the application of a few fundamental concepts and values. Your situation isn’t the rare exception.
Yes, this can be challenging, especially when the impediments that need to be addressed are rooted high-up in the enterprise. If it was easy, every organization would be wildly successful, and lots of Agile consultants I know would be running Tilt-a-Whirls at carnivals all over this great country of ours.
But that doesn’t mean it isn’t worth the effort. If you want to succeed, you don’t really have a choice.
I was sitting with a team when their manager came in and asked, “Hey. Are you guys finished with this feature?” The Scrum Master responded, “We haven’t even had time to even begin the discovery on it yet.” The manager looked surprised and said, “Oh, OK. Would you let me know when I can see […]
Here’s an article that just drives me nuts: Using Agile Scrum to Manage Developer Teams. The problem I have with this article is that it is just crazy bad in its use of language and ignorance about the fundamentals. Here are some examples:
This is not a thing. Agile is a philosophy of doing software development. Scrum is a particular instance of Agile. Saying “Agile Scrum” is kind of like always saying “furniture table” instead of just “table”. It shows a pretty fundamental gap in the writer’s knowledge.
As with any software development lifecycle (SDLC) framework…
Scrum is definitely not an SDLC. Scrum is a framework (and the author uses the term correctly a little earlier in the article) but is deliberately missing most of the details that would make it an SDLC. It is designed to be incomplete instead of complete. SDLC’s are meant to be complete solutions for delivering software. Scrum shows you the gaps and exposes the problems you have delivering products but doesn’t tell you how to fill in the gaps and solve the problems.
Next, the article mis-quotes Scrum.org by incorrectly capitalizing Product Owner and Scrum Master. And in some sort of ironic error, puts “Scrum master” in quotes. Yikes!
The conclusion of the article about when you might choose not to use Scrum is also a bit mis-guided. There are lots of organizations successfully using Scrum in highly regulated environments: medical, banking, government, etc. Some of them are even my clients! I would be happy to provide direct references if needed.
Does your team work remotely? Despite advances in video technology and online collaboration tools, the requirements for structured daily contact makes Agile Scrum tough to implement successfully for virtual teams.
Yes, remote work is bad with Scrum. But it’s also just plain bad. Don’t do it if you can avoid it. All that Scrum does with a remote team is show you just how bad it really is.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
I’m invariably surprised how often I get contacted by project management organizations, who want to guest post on my blog, or engage me in some other way to help promote their tools and techniques. Even after twenty years of Scrum in our industry, where the project manager role is noticeably missing, there is somehow a perception that a scrum master and a project manager are the same role. Or that there is still a place for project managers in an agile process. There isn’t. Here, verbatim, is a recent exchange with a tool vendor. Names have been changed to protect the misguided:
My name is John Smith and I represent a team of devs called PM Tool Makers. We build advanced project management software for people with skill and expertise—like your audience. [That’s you, dear reader]
I’m currently preparing a Slideshare presentation on Project Management with 25 - 50 quotes from top influencers in the industry. As you may know, online presentations are currently one of the biggest (and fastest) means to reach great deals of people and Slideshare is no exception here.
I’d really appreciate if you could provide us with one quote of yours that people interested in Project Management could benefit from.The presentation will be branded and you can see it below the link and you also see it in attachment
Looking forward to hearing from you - we’d love to have you included.
I appreciate being noticed, of course, but I usually get the sense that these guys are crawling the agile blogs and hitting on agilists indiscriminately. Kind of like the lonely guy at a night club who thinks maybe he’ll just get lucky tonight. Anyway, I responded:
Thanks for writing. It’s no secret that I don’t have much respect for the discipline of project management—in fact I’ve often written in opposition to it. I believe projects need to be guided, not managed, and that guidance best comes from the teams building the software and the users who use it. I find the role of project manager to be somewhat unnecessary overhead—at best a plug for a hole that people are not effectively stepping up to fill for themselves, usually due to autonomy and empowerment issues with the organizational system in which they work.
Management (of all kinds) is a twentieth century invention. Prior to that we had mentors, master craftsman, visionaries to guide us. I’d like to see a revival of that model.
So, I’m not really the best person to offer you a quote. But here’s something, anyway:
Don’t manage projects. Instead guide teams to manage their own work, and to collaborate with their users. Let go of control. Listen to the voices of the people doing the work. Embrace uncertainty. Ultimately, create an environment where your job becomes superfluous.
Probably not the kind of thing you are seeking :)
Best of luck with your presentation, and your product.
I rather liked the quote. John Smith did not.
Thank you for your quote, but necessarily—yes, is not the kind of I am seeking.
Thanks for your message and good luck!
My job, as I see it, is not to perpetuate the myth that project management is a useful discipline, but rather to challenge that old assumption. At the same time I believe I have a responsibility to socialize a different way of working to those good folk who find themselves in a dying profession. Others have different ideas.
Today is a great day to share some killer tips on how to get the best out of one’s creative potential. These tips would be of special help to digital creative individuals, that is, to anyone, who thinks for a living as they look at a screen. So, whether you are a graphic artist struggling for that elusive touch that would make a corporate identity unique, or a UX designer who wants to put together an intuitive interface, or a product owner looking to figure out what goes next in a product, or a project manager looking to facilitate a team’s performance, or a software developer crafting a piece of code, look no further. This article is your philosopher’s stone for achieving top results.
So, friends, lend me your ears. To turn on this magical power of brilliant insights, one just needs to do these three simple things day in day out.
1. Wherever possible, spend the bulk of your most productive time, preferably in the morning, when your brain is fresh, doing a research online as to how others have done this thing that you’re working on at the moment. If you’re a graphic artist, make sure you not only dig out all possible images or ideas that can be replicated, but remember to throw all those links with images at the other fellow designers in your team. Not only will this help strangle their creative edge ensure that all the industry-accepted standards are followed, but they won’t need to spend any more effort on inventing original concepts. Leave no stone unturned. You need to chase each and every clue. For strategic decisions, make the list of step-by-step routines copied from how others addressed the same challenge. You will never do anything valuable if you fail to follow the proven routines that other people have followed many times before.
2. The second magic success ingredient is to expose the drafts of your work, or to have your incentives for strategic decisions bullied discussed by as many people as one can possibly get. Facebook is an ideal space for that. Remember to be consistent in sharing the in-progress sketches or ideas with strangers, who don’t know you personally and who are completely unaware of the particular context you’re working in. They’d shoot their comments, wasting your time making their invaluable contribution to shaping up this great idea, or a graphic, or a piece of code you’re currently working on. Consistency is the key here. The more exhausted you get filtering out the rare grains of sensibility from the avalanche of clueless comments, the closer you’re to what you’re looking for. The logic here would be the same as on the picture below. One is more likely to build a snowman with plenty of snow, picking out those special unretarded pieces with care.
3. Finally, there goes the trickiest part. Once you’ve let out your finished and polished brainchild to the outer world, work to secure the right attitude to external criticism within yourself. You absolutely need to master the skill of proving your worth based on each and every comment received from your network of personal and professional contacts. The smartest way to accomplish this would be to build a model that would transform the bites of criticism to a numeric value. You’d need to set a certain plank for yourself with this model. Once this value gets below this plank, you need to work harder on the points 1) and 2).
Repeat this cycle forever, and you will sleep serenely, like a baby, enjoying the bliss of reaping harvest from all your hard work.
The first-ever interactive Agile business novel “The Dream Team Nightmare” is about to become to first ever film to be made about Agile.
We’ll be paying Hollywood a visit this summer when filming is scheduled to start.
Check out the InfoQ interview with the author here.Who’s Who
The initial cast list looks something like this:
- Jim Hopper, Agile Coach – Jake Gyllenhaal
- Emily, Jim’s girlfriend played – Ginnifer Goodwin
- Patrick, Head of IT – Liam Neeson
- Cassandra, Product Owner – Julianna Margulies
- Jason, Developer – Steve Buscemi
- Ben, Scrum Master – Seth MacFarlane
If you’d like to audition for a role, get reading “The Dream Team Nightmare” then contact J.J. Abrams directly.
When the day to travel arrived, you reset the odometer, set up the GPS and off you went. However, the job of planning wasn’t complete. There might be detours along the way. Frequent glances at the odometer or GPS might inform you that you are ahead or behind schedule. Also, the map and GPS aren’t enough. You monitor your speedometer from time-to-time and constantly look out the windshield and at the mirrors in case another driver does something unexpected.
We use all these different measures and methods to maintain a plan and respond to change for something as predictable as driving. We need similar tools for the far more complex and uncertain endeavor of making a game!
Figure 1 - Planning Onions for Driving and Games
The figure above shows “the planning onion”, which represents the different layers of planning frequency. The inner layers of the onion are the more frequent inspection tools/cycles, while the outer layers encompass tools applied less frequently.
Layers of Planning
Let’s examine the layers of planning from the inside out using the driving example for comparison with how a Scrum-developed game would plan:
- Daily - The team will meet every day in a daily Scrum to discuss the progress and issues which are affecting their Sprint goal. This includes conversations about bugs, impediments, dependencies, or merely points about the quality of the game. This is like looking out the windshield of the car during your trip.
- Sprint - The team, product owner and domain experts forecast what is possible to accomplish in the next one to three weeks. The duration of the sprint largely depends on how much certainty the team has with the work and how long the stakeholders can go without seeing something. A team will forecast and track the work in any way they want for the sprint. Some teams use hours, others days, while some teams will come up with their own units. This compares to using the speedometer in your car to measure you velocity.
- Release - The team, stakeholders, marketing and leads identify stretch goals for the game that they hope will be demonstrated in a “shippable build” at the end of the release. Product owners might alter these goals during the release as quality, cost and true velocity emerges. Forecasting and tracking during a release is usually done using metrics that size the features on the backlog (e.g. story points). This level of planning and tracking is comparable to using an odometer during your drive. The odometer gives you a more long-term view of velocity when miles are measured against larger units of time, such as hours and days.
- Project - For a cross-country drive, you’ll likely have a map and a rough idea of your progress and stops along the way. You may have a gas budget and looked online to see where major construction delays might occur on your path. If asked where you expect to be tomorrow night, you’d have an answer like “Denver”. If asked where you would be at 2:15 PM tomorrow, you might not be much more precise. Long-term project planning should be like this. It focuses on the major cost, schedule, and feature goals and identifies significant areas of risk. Similarly, long term planning will break out epics and define some constraints based on experience. An example for “online multiplayer gameplay” might be:
- Cost: 10 people for six months to implement and 20 people for six months to produce content.
- Schedule: Starting in June, finishing in 12 months.
- Risk: Online technology risks and core gameplay risks.
Just as we don’t forecast our speed down every mile of road while planning a cross-country drive, a long project shouldn’t forecast what teams will be working on every day for a year or more. Instead, as the planning horizon extends out, the metrics for planning become larger grained and less precise. There are a few reasons for this:
Reason 1: The further out our plan goes, the more uncertainty there is with the details.
This is best illustrated with the cone of uncertainty shown in Figure 2:
Figure 2 - The Cone of Uncertainty
This figure illustrates that the further we are from shipping the game, the more uncertain its cost, scope and schedule. Everyone who has shipped a game should recognize that the great concept art and ideas and plans expressed in the initial design documents usually don’t resemble the shipped game very closely. This is not a bad thing. This is the nature of creating complex games that have a subjective and emotional dimension. We simply can’t “plan away” this complexity and uncertainty. This doesn’t mean we can’t plan. It means we need to plan at a level appropriate to the level of certainty that exists.
Reason 2: Simply breaking down a long term plan into finer details won’t give us more certainty, it’ll give us less uncertainty and waste our time doing it.
This is the hardest to convince people of. The assumption is that a 300 page design document creates twice as much certainly as a 150 page design document. When I worked in the defense industry, this assumption led me to create a 40-pound specification document for an Air Force contract. The Air Force wanted so much demonstrated certainty from their contractors, that they received documents so big they couldn’t read them.
However, numerous studies have shown that not only is uncertainty not reduced equally with more planning effort but, beyond a certain point, the attempt to plan away uncertainty with more effort (documents and spreadsheets) produces forecasts with less accuracy (see Figure 3). The reason that a bigger plan creates less accuracy is due to human nature. It’s in our nature to see a big document and turn off our critical thinking, just as the Air Force did when they saw our 40-pound document. Had they read that document with a critical eye, they would have quickly found out that it was a rushed cut-and-paste job by a junior engineer. Instead, they simply weighed it and awarded us the contract.
Figure 3 - The Accuracy of Planning Based on Effort
The tools that we choose, based on where we are in the planning onion, help us stay in the ideal range of precision, which gives us the best amount of accuracy without wasting effort.
 I’ve seen some teams estimate in “NUTS”, which stand for “nebulous units of time”.
 Although I’ve seen some producers try to do this!
 Ever wonder why new fighter aircraft are years late and billions over budget?
 One of many quote is http://tinyurl.com/leasydl
In todays world, the mantra is innovate or die.
You’re either climbing ahead or falling backward … there’s no hanging out in the middle.
And some folks are actually leap frogging ahead.
Disruptive innovation is keeping everybody on their toes.
Whether you are re-imagining you or your company, or you are driving innovation in your process, product, or capabilities, there are skills you can learn to be a lot more effective in your innovation efforts.
It’s a crazy world where a One-Man Band can write an app, serve it up on the Cloud, and change the world. It’s also a strange world where a little idea can be a big shot heard round the world. It’s a scary thing for businesses when a handful of developers can spin up a new service in the Cloud and instantly make a business obsolete.
What can you hold on to in this crazy world? What can you latch on to, if you want to rise above the noise, and instead of getting washed out by a wave, be the one that makes the waves?
There are several things, but I’ll boil them down to this:
- Use your customer as the North Star (and remember that some customers are better for you than others)
- Share and scale your unique value to the world
- Adapt or die
What happens to a super successful business or a super effective person when the landscape changes under their feet?
It depends on how they adapt
Nature favors the flexible. Darwin taught us that.
You have to get your bold on, and embrace innovation as your shiny sword to do battle against challenge and change, but most importantly, to create the change that serves you, and those you serve.
I’m taking a fresh look at innovation, as well as going back through hard, expensive lessons I’ve learned in the past. Whatever doesn’t kill us makes us stronger, so my battle scars are a healthy reminder of the lessons I’ve learned on how we can use innovation to leap frog ahead, as well as change the playing field (heck with changing the game, change the field and be the disruptor.)
Believe it or not, Peter Drucker was a wealth of wisdom when it comes to innovation. Many of you know him as the wise and wonderful professor of business and guru of management. But when you read through a lot of his work, he was incredibly insightful and pragmatic when it comes to creating a culture of innovation.Innovation Nuggets to Get You Started on Your Innovation Journey
I’ve got a ton of innovation books, but one that I’m really liking lately is Out Think: How Innovative Leaders Drive Exceptional Outcomes, by G. Shawn Hunter. I’ve been sharing some nuggets from the book, and it’s been reminding me what it takes to build a culture of innovation.
If you want to start your innovation journey, and create a culture of innovation, here are a few posts to help you on your way:
If you need to remind yourself what innovation feels like or what’s possible, be sure to soak up some powerful words of wisdom:
In my Innovation Quotes, I’ve also included a special section to light up what Bill Gates, Steve Jobs, and Walt Disney teach us about building a culture of innovation.
Let’s boldly go where we have not gone before.
Note: this is not an April Fool – honest!
I’ve been watching the #NoEstimates conversations with interest and decided its about time to pitch in with my own perspective. I don’t want to take any ‘side’ because like most things, the answer is not black or white. Estimates can be used for both good and evil. For me they are useful as a sensing mechanism. Put another way, by estimating, I can get a sense of how well I know my actual capability.
Lets take an example. I’m taking part in a 10K run this Sunday (*) and I am estimating that I will complete the distance in 55 minutes. This is based on an understanding of my capability from participating in regular 5K runs, and more general training runs over a 10K distance. I’ve never run an official 10K race, let alone this course, and I don’t know what the conditions will be like, but I’m aiming for 55 minutes. If I run quicker and do better than my estimate, then my actual 10K capability is better than I thought. If I run slower and do worse than my estimate, then my actual 10K capability is worse than I thought. Either way, I will learn something about how well I know my 10K capability.
What helps even more with that learning is regular feedback! I use MayMyRun on my phone to track progress and give me feedback every kilometre for total time, average pace and last split. This could be considered a distance-based cadence. I could probably also use a time-based cadence to give me equivalent feedback every few minutes. This feedback on a regular cadence helps me decided whether my estimate was way off, or if I should slow down because my pace is probably unsustainable, or speed up because I feel I can push harder.
How does this relate to product development? Well, we can use estimates in the same way to get a sense of a teams delivery capability, and use regular feedback to learn whether we’re making the progress we thought, and need to re-plan, slow down or speed up. Time-boxing, with Story Point estimates and Velocity can provide this time-based cadence and feedback. Alternatively, how long it takes to complete 10 User Stories can be used as a distance-based cadence and feedback.
To sum up, I recommend using estimates to sense capability and create feedback for yourself. I don’t recommend using them to make promises and give guarantees to others. Or maybe we could just call them sensors instead of estimates?
(*) Of course this post is primarily an excuse to invite readers to sponsor me. If you’re so inclined, or would like to show support for this post in a charitable and financial way, then please head over to my JustGiving page and do so there
Update: My final time was 49:23 based on the timing chip, or 49:30 from the starting gun. I’ve learned that I’m better than I thought I was, and next time I’ll be estimating 50 minutes!
Another great article by Mike Caspar: Consider the ability of your Stakeholders to come to your Sprint Review or Demo before declaring it. From the article:
If you are in an environment that is struggling to get stakeholders to your review, ask yourself if you have chosen an impossible day of the week for this ceremony.
Please, for the sake of your team(s)….
When considering when your Sprint will end,
think of the ability of your stakeholders
to actually show up once in a while!
Stakeholders are people too. They don’t want to let the team down either.
Mike has great experience working with Scrum teams and I hope you read through his other articles as well.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
The Scrum Product Owner must lead the project strategically, collaborate with customers and team on a daily basis, and manage the business value.The Scrum Product Owner takes back the accountability from the traditional project manager for delivering the right solution to the customer and end-user. This two-day CSPO course will provide you with the core […]
The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile and successful. This […]
This 2-day training course provides a deeper understanding of Kanban for knowledge workers. The training is therefore particularly suitable for those who: want to start with Kanban and are looking for initial support have already introduced Kanban and want to check if the implementation complies with state-of-the-art Kanban knowledge This is a certified Kanban training […]
Certified Scrum Master The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile […]