On "Agile Doesn't Work" Articles
Can everyone please do me a favor when you write about #Agile and wonder how it could be construed and misconstrued?
The vast majority of anyone writing about the topic are people who "got it" themselves and have a wealth of experience to bring and as such, any contribution is valuable and necessary but to assume that something will be employed "for the good" and not the opposite assumes a level of goodwill that doesn't exist across the board in the business world.
As a result, any article that comes from a place where there may be practical frustration looking around at half-cooked or bastardized implementations becomes fodder for the sequential-thinking-Prince brigade to prove "it doesn't work".
Any list meant to remind us of the fundamentals of the manifesto in terms of eternally going back to people be they the consumers or the team becomes a list of pitfalls and perils.
Any examples of implementations where people did it "by numbers" and as a result didn't come anywhere close to the speed and magic #Agile promises is an example of why it shouldn't be done.
When you have a truly #Agile mindset you're thirsty for knowledge. Feedback and communication are the only way to move forward, but when you don't, those aren't welcomed a priori, so when any information sips through, it has to confirm bias and align with the views of the sequential-thinker or it's filtered out. Anything contrary will be banned, anything even remotely ambiguous will be twisted.
Equally, when you're in a real #Agile mindset you assume everyone just wants to get the job done, hence pointing out it needs a change of course or new ideas to do so better or faster, is natural and at the base of the way you engage, but in the absence of the mindset, the shared purpose doesn't exist and overall success is certainly secondary if not irrelevant.
One side has a fetish for progress and betterment (I know most of us cringe at the word it's correctly depicting precisely what we do when we grow through #Agile so view it as resilience-training to read it :) and the other has sworn allegiance to the status quo and is clenching their teeth and various other body parts waiting for the "trend" to be over. What are the chances that side will take any criticism as constructive and not use it to further their bankrupt point?
If, on top of that, we take into account that working in #Agile environments while not having "gotten it" is especially hard (think back to the days before you had seen the light, how unnatural was all that openness, that obsession with flexibility and that drive to do better, more and do it for the customer?) it is little wonder that anything that can be read as a critique to show #Agile is perennial will be taken as such.
In the last week alone I must have read 10-12 articles that were a decent critique or an honest account of where various Agile transformations went off the rails (99% of the time because of the lack of mindset at the top) and then invariably saw them featured in statuses or further articles on here which gloriously declared "Agile is dead, see?!? Doesn't work! Told you so!". I'm not going to link to examples for obvious reasons but I'm sure we've all seen them.
What's the answer then? That we don't point out any negatives? That we pretend the pitfalls aren't there? That we make it look easy and PR-proof it at every corner? Of course not! How would either of us move forward if we tried that? I just think we need to be a lot more conscious of adding disclaimers and addressing the Prince fans directly to disallow them from using it as an excuse.
If we want to be sad about it, we can. Those who write with any constructive criticism do so out of a sense of team they have with the rest of the community at large. Ironically, there's a diffuse sense of psychological safety in sharing this way. They want to show what they've learned and think it will further the effort in reaching the same goal. They can't imagine other intellectually gifted, grown-up adults wouldn't see any criticism for what it is - a part of the process of creating a new work paradigm which happens to be the only one possible to match technology and the appetite humans have for consuming it, but that's still our reality with those of us being truly #Agile at heart being a small minority of the larger business community and we are doing nothing to bring them along if we're not conscious of the disparity.
But let's not be sad about it, let's be smart (and implicitly compassionate) about it and denounce the cargo culture in the same breath that we reaffirm a true #Agile mindset is still non-negotiable and the promise of faster and better is still the same.
IT Project/Program Manager | Servant Leader | Solving business problems with the latest technology
5yUse the right tool(s) for the job or project, don't get hung up on labels or buzzwords. The Agile methodology was designed for software development which benefits greatly from the agility not found in traditional project management. In many organizations, there are necessary or required activities that must be done outside the typical Scrum master role. These often fall under heading of project management, even with software development. Traditional project management is the best tool for companies like those in Construction. If we limit the discussion to technical project management, it is still true that traditional project management may be the best tool for some projects. My experience has shown this to be the case with technical infrastructure projects and that doesn't preclude using principles of the Agile Manifesto or an iterative, streamlined, customer focus approach. Agree that a good technical project manager can/should apply an agile mindset to projects and be flexible, so that the right things get done the right way at the right time and cost (no political message intended or offense intended to left-handed people).
Interim | Product | Technology | Strategy | CPTO – Special projects in digital business, public interest technology and venture building.
5yAgile: make it up as you go along. Waterfall: make it up before you start and live with the consequences.
Programme / Operations / Strategy / Transformation / Governance / Change / Management / Leadership / Partnerships / Local Government / Central Government / Police / Health / Social Care/ HE Higher Education
5yAgile is about taking ownership and delivering in a fluid (pun not intended) situation. Prince & Waterfall are about death through administration and always making it someone else’s problem, it legitimises not achieving.
colouring outside the lines
5ygreat piece! agreed, pitfalls and failures need to be disclaimed with ways to overcome the challenges of agile or explaining how it wasn't actually a failure but a prime example of Agile's core tenets (a product that does what users want rather than delivering what X Manager asked for in a memo sent to the Head of IT six months ago? Yes!!) it can sometimes be too much readymade fodder for the entrenched traditionalists who don't want to change!
Experimentalist | Psychological Safety | Organisational Learning | High Performing Teams | Just Culture | Research | Public Speaking | Leadership
5yThis is crucial - agile (and scrum) is HARD. Waterfall and prince2 is easy - but partly because waterfall project management gives you somewhere to hide behind. When a project is late or over budget, you can always point to something that went wrong, some dependency delivered late, the scope changed, or something else - BECAUSE waterfall can't cope with changes. Agile, on the other hand is designed FOR change. So in agile teams, nobody can hide behind "the scope changed" or "the supplier delivered late" or "we didn't anticipate X", because dealing with unknowns is (in part) why agile exists. This, to me, is why many big organisations still use waterfall. Everyone wants to cover their ass with old-school PM methodologies. In agile organisations, we want to deliver value, and we don't feel the need to hide from "failure". But for that, as you say, you need psychological safety.