In my journey as a Scrum trainer, I’ve often encountered a startling statistic: according to Forrester Research, around 81% of development shops claim to be agile. However, the reality is that many of these organisations are not being entirely truthful about their practices. This disconnect raises an important question: how can we discern genuine agility from mere lip service?
The Reality of Agile Practices
From my experience, I’ve found that only 22% of organisations are actually implementing short iterations of six weeks or less, which is a fundamental principle of the Agile Manifesto. The Scrum Guide suggests a maximum of 30 days for iterations, yet many teams are still stuck in longer cycles. This lack of adherence to short iterations significantly hampers their ability to deliver value quickly and respond to customer feedback.
Moreover, only 16% of teams maintain an ordered backlog. This is baffling to me. If you’re investing time and resources into a team of software engineers, why wouldn’t you prioritise working on the most valuable tasks? An ordered backlog is essential for ensuring that the team is focused on delivering the highest value to the customer.
The Importance of Retrospectives
Equally concerning is the fact that only 13% of teams conduct retrospectives. This closing of the feedback loop is crucial for continuous improvement. If teams are not reflecting on their processes and outcomes, they are likely to repeat the same mistakes, stunting their growth and effectiveness.
Cultural Resistance to Change
One of the biggest barriers to genuine agility is cultural inertia. As humans, we tend to cling to familiar ways of working. Change can be daunting, and without a supportive environment that empowers individuals to innovate and adapt, it becomes nearly impossible to shift mindsets.
I often refer to the tyranny of Taylorism, a concept that highlights how traditional management practices can stifle creativity and autonomy. The scientific management methods introduced by Frederick Winslow Taylor in the early 20th century focused on efficiency at the expense of employee engagement. This mindset still permeates many organisations today, leading to a culture of distrust where employees feel they must conform to rigid processes rather than think critically about their work.
Learning from History
To understand why we work the way we do, we must look back to the pre-industrial era. Before the 1890s, people lived and worked in close-knit communities, solving problems collaboratively. The advent of the Industrial Revolution shifted this dynamic, leading to the division of labour and the rise of factory work, where individuals performed repetitive tasks without understanding the larger context of their contributions.
This shift was not inherently negative; it allowed for mass production and efficiency. However, it also created a disconnect between workers and the products they were creating. The challenge we face today is how to scale the collaborative, customer-focused approach of the past in a modern context.
The Path Forward
As we navigate the complexities of modern software development, it’s crucial to embrace agile principles genuinely. Here are some key questions to assess whether your team is truly agile:
- Are you delivering working software to real users every iteration? If not, you’re missing the essence of agility.
- Is there a product charter that outlines strategic goals? Everyone on the team should understand how their work contributes to these goals.
- Are teams empowered to change their processes based on what they learn? Agility requires flexibility and responsiveness.
- Is user feedback turned into actionable work items within a month? Quick iterations and feedback loops are vital for success.
- Can your team adapt requirements based on user feedback? Bureaucratic barriers should not hinder responsiveness.
- Is there a seamless deployment process? Ideally, there should be minimal human intervention between code commits and production.
If you find yourself answering “no” to any of these questions, it’s a clear indication that your organisation may not be as agile as it claims.
Conclusion
In conclusion, the journey towards true agility is fraught with challenges, but it is essential for organisations that wish to thrive in today’s fast-paced environment. By understanding the historical context of our current practices and actively working to dismantle the barriers to agility, we can create a culture that fosters innovation and responsiveness.
As I continue to explore these themes in my work, I encourage you to reflect on your own practices and consider how you can contribute to a more agile future. Remember, the art of simplicity is often hidden within the complexities we face. Let’s strive to make our processes as straightforward and effective as possible.
you
oh my name is Martin Henchy wit special scrum trainer with scrum dark I want little chat today I’m
some of this information comes from some well-known sources I’m going to elaborate on those saucy
party
you
80% 81% all development shops see they’re agile that’s based on Forrester Research that of that 81% around 80% and 82% I think and our say that they’re doing however the reality that almost 81% of them are lying that’s the thing that we find anybody out there who is a trainer a coach a scrum master at will know that these things are almost never so how can we tell the real thing from what might be considered I do have some very concrete measures we can use they are not mine they come from another organization which I will describe I just find them interesting enough
you
only 22% of organizations and short iterations that’s iterations of six weeks or less the manifesto does say that we should have
six weeks or less or get stuff in front of our customers six weeks or less the scrum guy you would see at 30 days our last one
but if you don’t have short iterations and are the only ones that do then the likelihood of you being
and only 16% have an order backlog this is one I do not understand if an organization is going to spend honey getting there having a team of software engineers working through a body of work why would you not want to make working on the most
sixteen percent have an ordered backlog you’ll probably find that we have something they would call a backlog at all
only 13% do retrospectives closing that feedback loop it’s super important and how do we make sure that don’t do the same thing wrong all the time tight act or not just what we just did but how we did it
it better store so this data that I’m using here and comes from Forrester Research I have a slide which with the original data for that I found it pretty interesting
feel free to and have 50 yourself because really the reality today with organizations is that while it looks
hey they’re doing the right thing it’s secret is we’re all a mess in sight I don’t know any service orientated organization I’m actually I’m thinking of
thank where I’ve heard of our consultant developer going in and really liking what
behind-the-scenes things tend to be a little bit interesting
you
let me check at the the I can do something about the sound
you
so I’m not sure if I managed to actually fix the sound or do something about it hopefully that’s ah
one comment on why it’s so hard to change it’s it’s a cultural thing we like to as humans we like to do really the same thing we get stuck in our way of doing something and unless we feel that we’re empowered to make changes through that process then um it’s it’s very very difficult I just googled why has changed so hard and Dilbert and I had a plethora of choices for em but what constitutes
so there’s something that we all know and love this is the the tyranny of terrorism and being very specific here I’m trying to avoid the term waterfall for for very specific reason
look at them as I go through but ultimately you’ll see this process reflected in many organizing fireman’s through to designing through to implement the verification and maintenance you might even see in organization that they have HR department they have our sales department they have our IT department they have an apartment as completely separate entities and there’s a very good reason why we ended up in that position it’s not necessarily good now but for the time when those ideas came about it was the right way to approve but times have changed we have more understanding of how humans interact with work we have more understanding about the complexities of a lot of the world and most people know do a cognitive work so let’s have look why do we work that way so we need to kind of go back in time a little bit go back to three at nineteen eighteen ninety before eighteen ninety people generally lived pretty close to where they work they whenever they had a problem they just rallied around and figured out how to solve it supportive innovation I need to work very very close to their family and and if you were doing a job you did the whole job not just part of the job so you can see there the the cobbler on the right the apprentice learning how to make the shoe and the reality is that that cobbler probably knew the person who they were making the shoe for the knew what their job was how they were going to use the shoe that product and the cobbler can make that shoe with that person in mind they probably made that person’s previous and they know that that person can come back in and whenever they’ve got a problem with the shoe so they get old they can they’ll know all the experience that that user that person has had with that work and that’s a very powerful way to build products that have a very high Happiness ratio with theirs but how do we scale that it can be very difficult so in just after the 1890s the Industrial Revolution kicked off into food and it was a time of lots of money was made but you can see in those pictures that there are people doing very individual tasks I would struggle to even understand what these folks were making something around for sure with boats in it it could be clocks it could be parts for cars it could be um washing machines it could be any sort of device we don’t really know and it doesn’t really matter for the individual sitting at their workstation they only need to do the one thing I usually use the example of Charlie and the Chocolate Factory
and Charlie’s dad’s had a job before he lost his job to a robot and his job was screwing the top on toothpaste bottles like a very
ask and when we do menial tasks our brains disengage from the work so what’s what’s that’s the difference here is that on the Left we have the cobbler making the custom shoe for the individual person that they know that they interact with they understand the whole process whereas on the right we have the factory floor where the individual users don’t really don’t really even care don’t even need to know what the thing is that they are creating they probably have some idea it’s probably difficult to work in a factory and not know output is but do they really understand how their piece of the puzzle contributes to the overall thing they’re just doing exactly what they’re told
so there were two really big thought leaders at the time the first was a gentleman called Frederick Winston Taylor and he has a comment that I think you’ll find very in keeping with our understanding of how current management practices like that think of this is the foundation of current management practices hardly a competent worker can be found Tudor does not devote a considerable amount of time to studying just how slowly they can work and still convince their employer that they are yes
if you think about that position of distrust that people are trying not to work and that’s a very common mental practice for management for project managers for the way people manage their people in the world today
other are not saying as everybody there are lots of progressive people out there but is a very common mindset and they’re starting to change but it’s changing very slowly
they were invented something called the scientific management method
and it was based on the knowledge at the time so what they did was they developed standard methods for performing each job best practices they divided workers into appropriate ability based groups for each job so and you know they’re going to have the steelworkers
the for one of a better expression the project managers the coders the testers the operations having them all as separate ability based groups they understand that so they should all work together on that one task you saw in the pictures of the factory floor and the they have everybody that does that one task together so they can deliver those standards they train the workers in those standard methods because there’s no no thought we need to remove thinking and we’re just going to plan their work so they do it the way we tell them to do it and and we’re going to create a bunch of wage incentives to
you’ll see some of these things in maybe the current management practices of your organization
hopefully you work in a more progressive organization but Taylor had somebody who came after him kind of a disciple somebody who looked up to his work and that was a gentleman called Henry Gantt
and Henry Gantt and came up with some things we know and love today apart from the Gantt chart but he created the tasks and bonus system of which payment he created our basic wage based on expected low performance so if we think from a position of distrust of our employees they’re gonna try and work less so let’s pay them like we expect them to work so pay them last for their work and then we’ll give them bonuses if they manage to meet the expected professions that we we sent a vice by default and also if we’re going to have all of these folks that need told what to do because we’re removing thinking then we need managers to manage them
the Pyke’s t of the work you might need more managers and you might need managers to manage the managers but the manager should be motivated based on getting bonuses on the outcomes of their staffs so if you think of well I worked in Merrill Lynch I had to fill out a bunch of status reports at the end of each week which I would give to my dev leet who elected them together for all of their direct reports and passed it on up the chain everybody had a head count they were accountable for that head count and the amount that was delivered they also henry gantt and came up with this thing is is unknown i like to call the modern school system and you may hear folks refer to the modern school system even today and when they refer to it they’re referring to this something little bit like this picture here let’s that was like my class in school
although this was a lot further ago and but everybody in a modern school everybody sits in rows people do the same thing at the same time there’s no talking you gotta put your hand up and incentive based learning and reward for fulfilled tasks these are techniques designed a factory workers the modern school system was designed to do that was thank decree remove thinking and just do it you’re told
just follow the set of tasks you’ve been given it doesn’t matter if you don’t understand it
so many of us grew up in the system many of our kids are in more of a hybrid system where teachers are trying to push away from this idea of rules but they you know they’re they’re struggling against a system like we are that defaults to the old way you go to those places in the Netherlands where they have changed the school system to be or in keeping with what we expect
group Isis learning together presenting the stuff that happened in the modern workplace so really there’s no difference between the modern school system and that management scientific management
nostril revolution in the factory floor these two folks optimized for output and not outcome you’re our coach or a trainer at following this you’ll know that’s already and but I find that knowing why something is a certain way help us combat some of the the eight years and in 1908 and this was the first Harvard Business School I think this might be the graduating class of Harvard Business School and and loads of the the leaders of the time the the people who would be managers at the time or who are going to be managers at the time and flocked to these and
schools doing MBAs so this was the first MBA and we know those ideas have lasted for a long time in the 50s this this new way of working started to emerge and become more prevalent across the board not just as part of option align process
so dividing people into specialist skills marketing sales contracts development testing and all of our separate things
and and create things sequentially in hand things between the different sections that doesn’t think you know the complexity of the work
then round about the 1950s the US military complex who is I think still the largest buyer in the world it’s it’s they have a lot of employees a lot of people that work with them a lot of consultants and because they wear such a large buyer and their their power to push vendors and consulting companies towards this model that they wanted to use was immense and most people couldn’t escape it and if you work with any large consulting company they probably work with the Department of Defense especially at the time and if you work with the varmint event you must do this this new staged process so we adopt it and eventually it just becomes part of their procurement Sassy’s that’s also the Chairman processes that we know and love
and that I struggle with when I’m working with customers I even had an engagement with a with a customer and because it was uh I think it was I remember the the big consulting company I was working with and I was doing a short engagement like a day’s worth of work and they couldn’t figure out how to pay me their procurement processes so I basically handed me a stack of cash because they just couldn’t figure out it wasn’t worth the effort of going through the process I didn’t get training engagement at Royal Bank of Scotland in Edinburgh because they couldn’t get the procurement process done in time it was just not possible yes that seems to be the way things are and a lot of our larger organisations with a little bureaucracy bureaucracy comes with these different departments and separating people into that work so if we fast forward again to the current modern times and this stuff was applied to software development and it didn’t work out so well
expediency is that off but I’ve got an interesting article so um the largest organization in the world with the most employees in the world as realized they made a mistake this particular organization and as 2.8 million employees largest employer and a 739 billion dollar budget they are in fact the Department of Defense in the US and they have realized that they’ve created this monster that is the sequential working process and it’s gone through all companies are in the world so in
2010 they brought in a bunch of agile folks so I believe I believe Jeff Sutherland was there Kent Beck was there a few other folks I don’t know what everybody that was involved and they got together to rewrite how can we change our procurement rules to take advantage of these new thinking and new ways so they pulled it all together and and the new procurement rules which mandated short iterative cycles of delivered value to to the customer which is on the defense at went live in 2013 but as you can imagine and now that the procurement rules have been changed
agile then becomes a buzzword of software development and therefore all projects now declare themselves to be agile and so the department events created this document called detecting add ups that is for their procurement officers to really understand what it what it is they’re looking for in a vendor when a vendor says they’re agile how do you know they’re telling the truth how
you know
I so I have here and some questions for you this is a small number of questions and I usually do this in a large auditorium so I usually get everybody to stand up I’m gonna stick to questions and after each question if your answer is no then you should sit down obviously you do it metaphorically so the first question our team’s delivering working software to at least some subset of real users every iteration including the first and gathering feedback I’m gonna clarify real users real users does not mean you a t-bill users does not mean attack
users means people using your software in a production environment real users means
if you aren’t doing that and you’re not you’re not agile and that’s step one are you doing this
getting real feedback and otherwise there’s no agility there second question is there a product charter that lays out the strategic goals of your project and do all members of the team understand what they are and how
how the work they do contrary
and if not then you’re not doing agile I would recommend a book called turn this ship around by David Marquette talks about pushing responsibility down the organization helping everybody understand at what the goals directives are so that they can make better decisions and stop telling people what to do
that’s this next one our team’s empowered to change their process based on what they learn and they can they change their iteration pace can they change what they do their review perspectives can they choose to do scrum can they choose to do a Kanban can they choose to do something else and all of those things need to be true otherwise and agile again oh three more questions that was number three is feedback from users turned into concrete work items for Sprint teams on timelines shorter than a month
I need to get feedback from those users that in the first one we delivered our real software - and we get feedback from them and we update the product backlog we bring that information our planning of the of the future on timescales shorter than one mark if not then unfortunately we’re still not doing agile our team is empowered to change requirements based on user feedback this can be a real problem in bureaucratic organizations that have a separation or still have a separation between contracts sales and engineer
shouldn’t be that separation to this type of thing you have are a concrete thing signed off by somebody who doesn’t really understand the interest in actually building stuff you go to build stuff you get in front of users user needs a change wants something different what you’re working on is not quite right we need to be able to make those changes and if not then yep you guessed it we’re not doing edge and the last one I think is or is that the second M is the full ecosystem of your project agile agile programming teams followed by linear bureaucratic deployments
ealier ultimately there should be no human interaction between a developer committing a line of code and getting into production if you’re going to have human interaction it should be limited to the clicking of an approval button or some kind of sign-off process it should not be any script any deployments any reading server setting up that none of those things
and if you can’t say yes to all of those questions then you’re probably not it
and Ross that line into the world and those are those are hard lines to cross and this example is from the Department of Defense in the u.s. they apply this now for both hardware and software so if you’re building a new guided missile for the Department of Defense
all of these things need to be true order for you
when that procurement and I think that’s that’s hard I don’t think they’re definitely not there yet that’s why they’re doing this
this article in order to encourage people to move a little bit faster and do those things but ultimately by improving our processes and practices by getting quicker at delivering by using those feedback loops and large projects can get up to 600 percent more more success and more likely to be successful not numbers smaller for small projects because the risk is less they’re usually closer to the customer is easier to have a discussion and change what you’re doing in a small project but in large projects that can be incredibly difficult there’s a lot of legacy code a lot of legacy ideas legacy procedures and practices and that that can be difficult now I would encourage you to look at other folks processes and see the way they do it
I like the largest company I know of to have actually made a successful agile transformation our agile evolution or start their agile evolution is Microsoft they’ve made a lot of changes in the last eight years they moved to continuous delivery and are doing all of those things but don’t just look at somebody else’s process and try and rubber stamp it onto your own and there are many practices out there they’re safe the Spotify model I always find the Spotify model I’m using because of the article was a point in time
don’t do this here’s what we’re doing now and the Spotify is not doing what it describes in that article anymore
they’ve moved on from there and these are maybe our starting point a place to glean some ideas but make sure you have the ability to create dynamic
create and manage your process and and I’ll leave you with a lovely mammal or a statement from the US Air Force this is a clarifying statement about a mammal and it says if you read the top underlined and highly discuss
discouraged from using rigid prescriptive frameworks such as scaled agile framework and safe framework and in an effort to move towards a DevOps and a more dev cell cops whatever you want to call it DevOps and agility and things like safe and any prescriptive model is potentially harmful to your ability to innovate potentially harmful to your ability to change and it’s not used by successful software commercial organizations should be an indicator as I would say that the art of simplicity is a puzzle of complexity we have to try and make things as simple as possible
do that over time well thanks for watching hopefully you enjoyed beam I’m hoping the silent problem was a little limited to a particular time frame and if not I will have to look at and I managed that
very much
