The article starts with the current note - agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).
But then it goes downhill with proposing yet another model that will people will try to adopt verbatim, and again, experience failure to implement.
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
What really killed agile fwiw, where the consultants, going from development team to team, peddling false hope, snake oil, and tedious time zapping process that people learnt to game rather than actually deliver.
Of course, someone will pop up saying agile is awesome, they love the daily scrums, the project is fab, the sky is blue, etc. Question is: can it be better?
^ this. Agile is only a set of principles set out to help write flexible software. It in no way made the actual writing of software, the gathering of requirements, the effort of design, easier; it simply gave us a process to follow that could potentially help avoid tedious re-writes. At the end of the day it's up to the people to put in the effort to make good software
Agile does not give us a process, because Agile is not a process (it is a set of principles that can be applied to evaluate processes in the context of a particular team, but its 100% not a process.)
Two problems for me:
[1] What bothers me is that people writing the manifesto admit that they are wrong, and they start the whole thing in the same way all over again. All over again!
[2] I have also seen practitioners and consultants that never did a single-frickin-project in their short lifetime, but preaching success. That's how you get wrong - theory and practice are often 2 very different things. And when the shit hits the fan, people say "you are doing the agile wrong". Alright.. teach me master, and admit how wrong you were 14 years ago.
p.s. Apologies for the rant.
> agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).
You know Scientology, Amway and most other cult-like phenomena say the same thing: It's never the "system" that's wrong, if it's not working it means you're doing something wrong. You missed something, you didn't try it hard enough, you didn't do it like X, Y, Z.
In my experience, the people who say agile is awesome would likely say any process is awesome. Because the true awesomeness they are experiencing comes from being on a good team. After wading through years and years of agile, even working for a major agile tool maker for a while, I've come to the conclusion what process you choose isn't that important. Get a good, passionate, driven team together, and they'll figure out how to kick ass. Without that ingredient, nothing else matters.
> In my experience, the people who say agile is awesome would likely say any process is awesome. In my experience, the people who say agile is awesome would likely say any process is awesome.
Agile is awesome because its not a process, but a set of principles which addresses exactly the problem that context-blind adoption of processes creates that makes good teams mediocre and bad teams worse.
Most of the processes sold in a context-blind manner as "Agile" suck, but they are a recreation of exactly what the Agile Manifesto was a reaction against.
That's true in theory but rarely in reality. The reality is Agile is a process, often a rigid one. I find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant. I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.
> The reality is Agile is a process, often a rigid one.
No, the reality is that Agile is not a process, though there are a number of different processes sold as "Agile". (The most common now seems to be Scrum as defined in the Scrum guide and a number of variants on it; for a while XP was somewhat prominent as well.)
> find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant.
Teams that do that are Agile: that's exactly and all of what the Agile Manifesto says.
> I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.
The thing is the "Agile movement" consists of two separate and opposed forces: one (and the origin of "Agile") is people promoting exactly the behavior you mention characterizes good teams, the second (and the thing you seem to have a problem with) is people using the name that the first group came up with to promote exactly what the first group is reacting against -- rigid, context-blind adoption of externally-developed process (largely as a reaction against the threat posed by the good ideas of the first to the second groups pre-existing business of selling rigid, context-blind processes.)
But the reality is almost everyone who "does agile" has rigidly adopted scrum, xp, kanban, etc. That is the reality most of us face. Just because a group got together 14 years ago and created a hypothetical scenario that essentially no one follows doesn't seem all that relevant to me.
And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?
The end reality is we have an entire industry built around that stupid manifesto. Sure, it's not what they wanted, but it's what we all got. We would have been better off without it.
> And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?
Because while there are lots of people who won't understand that with an explanation, and some people who get it intuitively and don't need an explanation even with all the noise from people selling one true way, there's also lots of people in the middle who benefit from people selling there one-size fits all approaches not being the only voice in the marketplace of ideas.
> The end reality is we have an entire industry built around that stupid manifesto
No, we have an industry that existed long before the manifesto built around selling canned, context-blind process and jumping on anything even mildly popular to sell it that, predictably, when the manifesto calling for exactly the opposite of what that industry sold became popular, jumped on that to sell exactly the same thing they'd always been selling.
> We would have been better off without it.
No, I think that there are lots of people who have learned something from the Agile Manifesto, writings actually addressing how to implement its principles that don't amount to context-blind process, and related movements (Lean software development, etc.) and applied the ideas to improve teams and make software in a better way.
Most developers -- before and after the manifesto -- work in places where management is operated with shallow knowledge and poor respect for their staff and buying whatever consultants are selling in terms of process, sure, but that's not the fault of the Agile Manifesto
You do make some good points. Perhaps my frustration at the Agile Manifesto is misplaced. I'd still argue that the canned processes that emerged due to the creation of the Agile manifesto are amongst the worst ones available, but for sure I have no real proof for that other than my own personal experience.
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
People are soft and squishy. Too much rigid process pevents taking advantage of that squishiness. A complete lack of process will result in those squishy humans just producing a gooey puddle.
For every piece of process:
* what problem does it solve?
* what side-effects does it have?
* are the side-effects good or bad, and how much so?
* are there alternative solutions with better side-effects?
What really "killed" Agile are two things: the absence of good guidance on how to apply Agile principles as opposed to canned methodologies, and the fact that most people don't have the skill to apply the principles without guidance.
There is some good guidance it there, but you have to get outside of the Agile "brand" for most of it, since much of the work on evaluating methods and other aspects of higher-level metamethodology that fits in with Agile principles is associated with "Lean" rather than "Agile".
> Most of it exists as arse-covering material anyway.
I think bean counter types throughout the business world truly believe there must be some secret fairy dust you can use to transform mid/low competency people into high competency people, and dysfunctional teams into highly functional teams. It's about wages. It's essentially a delusion that you can take cheap, socially lower status people and substitute for more expensive people as long as you have the right fairy dust.
The mentality works to a degree for certain disciplines. It works with McDonalds employees. You can apply management theory and systems to an infantry brigade and get good results from lower grade enlisted men.
The model simply does not map over to the "creative" professions and crafts. But managerial types are often averse to the idea that software engineering is a proper profession on par with their own, not commodity, and must command high pay. They prefer to keep seeking the right fairy dust.
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
This depends on the environment. Working for a consulting company, where time spent on the project is billed to a customer and the project has a fixed budget, Process is needed to make sure the project is estimated and executed properly, and the arse-covering helps to guarantee that you get paid when the customer makes changes mid-way through that increase the project costs.
It would be fantastic to work on projects with open-ended budgets and collaboration with customers to figure out what the software should be as it's being developed, but in the real world I don't think that is often possible. It's not just consultant/client relationships; even in big companies where IT is given a budget from upper management you have the same situation. Management won't approve a budget without a detailed description of the deliverable, and IT can't exceed the budget or deliver something other than what was promised.
Waterfall, for all of its drawbacks, handles this situation well. The problem is that no one wants to pay for all of the paperwork and management overhead it requires to function properly.
Someone pointed this out to me long ago, and I've yet to see anything that disagrees with it:
Every time you see someone succeeding at Scrum, it's because they're also doing most of XP.
Maybe we need to go back to our roots. I know that several elements of XP have only recently clicked for me and I feel foolish for having taken so long (but nearly everybody I know is still struggling with those aspects too, so I'm in great company). And I was exposed to XP in '99, which means it took me 15 years.
I was on board with the article until he tried to sell me Agile 2.0. (an unproven and confusing iteration, to make matters worse. Dreyfus skill model? Nursing industry? I'll wait and see and hope someone else has some sort of success with this before considering it myself)
It started good and I thought it would get even better by creating a imaginary new method (even with the "TM" sign) to make fun of the craziness it was complaining about. At the end I didn't know if it was a joke or not but, sadly, it looks it's no joke (to the authors, at least).
Most of the agile problems I've seen have been organizations cargo-culting things they've read, rather than trying to actually be dexterous. Big-A agile versus, well, "agile".
Scrum has been the largest offender - squashing discussion in standups, allowing scrum to erode QA process, rote meetings that take 50% of the week, story points and refusing to discuss timetables in hours when absolutely needed, reporting status multiple times, having others estimate tasks who are not doing those tasks, etc.
These organizations that have done so have been some of the least agile, and waterfall-esque organizations can even be better. (They planned up front well, they changed a few minor things in the middle maybe, but cut out the overhead).
I think most teams that implement/try to implement agile/scrum/xp and end up disliking it / failing at it completely miss the point of the retrospective step - and thus, skip that step.
Without the retrospective, it's just modified waterfall.
We had them in about half of the scrum shops. The retrospective, in my experience, was yet another meeting where things didn't get done either. "We are having too many meetings" was usually not popular either. Don't get me wrong, I like good meetings that result in actionable decisions.
My personal view on scrum is it attempts to trick a software team into micro-managing itself, and it usually results in feeling like kindergarten as a result.
The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to.
I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is.
When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens.
Scrum is, to me, something people pick when managers don't want to manage.
I like release-early release-often, MVP (in small doses), see http://michaeldehaan.net/post/118860078737/the-rock-paper-sc..., and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead.
I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough.
>>I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc.
Sounds like your teams were underestimating task effort.
>>If you have a PM that doesn't allow time for such things, it can be rough.
Anything's rough with a shitty PM, which is what you've described.
Nope, the features always won in priority because the project manager / scrumlords would keep it that way, and didn't value the technical plumbing that would actually increase velocity and reduce churn and improve code quality.
I think one problem is that Agile gives a numerical value to how much work has been done: story points.
Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
That's a problem with management. All of the agile/scrum resources I've read exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE; THEY ARE FOR ESTIMATION OF EFFORT'
> I think one problem is that Agile gives a numerical value to how much work has been done: story points.
Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.)
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
Ok, explain this to me. Why is this not a meaningful number?
Story points are essentially hours and generally in the shops I worked in, they are converted to hours. If something takes longer, the hours are adjusted.
So really, that's a metric for maximum hours worked ... why is that not a good metric?
If someone is on a remote team and they're expected to work 40 hours a week, why is measuring the maximum hours they were on the job a bad metric?
What? No. Glad I don't work for you.
Nearly all developers I know estimate time (and storypoints) by some (often linear) function of volume and complexity. Volume estimation is usually not very difficult, but complexity is very tricky (and dynamic too). Estimating developer work hours by any proxy that depends on complexity will introduce a margin of uncertainty so large as fo render the number meaningless.
I'd think by and large you would evalute remote workers by theit work output, not by estimating how much time they've spent.
> I'd think by and large you would evalute remote workers by theit work output
Which is what? Lines of code? I think that's even worse.
How do you determine how much work to assign someone if estimates are meaningless? How do you determine if someone is productive or is doing one hour's work per week?
Aside from insults, I don't really see any answers. Have you ever been in a PM role?
Again, if you adjust estimates as you're doing the work ... as in, it's more complex than you thought, so you adjust the estimate ... why are estimates a bad metric and what metric (something that can be quantified) would you recommend?
Uhm, I think you're reading my post a bit uncharitably. I don't think I insulted you, for instance.
I never said that estimates were meaningless, but they are tools for planning with high intrinsic uncertainty, and translating that uncertainty to evaluations gives unfairness. People are very sensitive to (perceived) unfairness and the idea that they will be treated so will give rise to resentment, not to mention incentives to game the system and overestimate. Hence endless bickering about points.
If agile failed for any reason it was misunderstanding human psychology.
Personally I don't think human performance in creative professions is well suited to quantified analysis, especially when team efforts are involved. So I don't really have an answer there.
I've seen average story points reported that way too -- but I think it's just that people don't know not to report all the decimal places that Excel gives them.
> Scrum is, to me, something people pick when managers don't want to manage.
This is a really good observation, I think, and lines up with my own experiences--every incapable manager I've ever had thought Scrum was a great idea. The ones I've known have been very linear thinkers with a tendency towards restricted domains of thinking, and Scrum reminds me a little bit of Orwell's "if you can't say it, you can't think it" idea. Scrum gives you a vocabulary that, if you hide in it, requires you to confront many fewer things and make fewer choices.
They're almost all the wrong choices, I think, but there are strains of manager that find choices anathema in the first place and so I can see the appeal.
> Don't get me wrong, I like good meetings that result in actionable decisions.
Which is what a retrospective _should_ be! "what went wrong, what went right, how can we change our process to keep those wrong things from happening again?" It doesn't necessarily need to be a meeting. The introspection needs to happen, though. No matter what type of process you have - if it's not being constantly reevaluated for efficacy, it's just cargo cult.
Very true, it's not the format but the goal of adapting that matters. If you can discuss and fix your problem in a stand-up, do it. If you need to sit down for half an hour, take time for it. If you need 1/2 day to really understand what is happening and get a shared view to decide what to do, plan it. But make sure that you take action.
Retrospective has, in my experience, been a candidate for biggest 'agile' time-sink and a great example of how agile 'evangelists' and scrum masters are so inward-looking and process-focussed that they get in the way of work.
You clearly haven't worked with people who like the sound of their own voices quite so much as I have.
>> What went well during the sprint cycle?
>> What went wrong during the sprint cycle?
>> What could we do differently to improve?
I have had Agile Evangelists, who are supposed to be good at making this stuff streamlined, turn around and say "Everyone needs to come up with five things in each category, then we'll go through and discuss them all, deciding on the most important things to change at the end"
In a team that was already too large (15ish people) I watched that eat an entire afternoon and produce no useful output on more than one occasion. In the team I was on (four, five?) it still seemed to take hours.
I know, I know, they were probably doing it all wrong, this is just my experience of one workplace.
I'm not saying it can't be done right, just that it doesn't seem to be a magic bullet and can devolve into navel-gazing.
In that case, part of the retrospective should probably be 'these meetings aren't actually solving anything, are actively getting in the way of getting things done. how can we do this meeting differently?' ;)
From my limited experience, scrum can work (defining 'work' as 'make people more productive'), and even in the classic situations that give rise to the flaccid variety (I work for a blue-chip media corporation which is just in the last couple of years trying to build a modern engineering culture basically from scratch, and it happens to work).
A pretty important point for making scrum work, however, is aggressive timeboxing of everything. If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.
I understand that this is not always an option in malfunctioning corporate environments; but Kanban/XP/programming motherfkerism wouldn't fly either in those situations.
>> If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.
When I rule the world, as they say, every meeting will contain only the people it needs to, "I don't feel this is relevant to my work or that I can contribute" will be the best reason not to attend and time limits will be aspirational in as much as everyone will aspire to beat them by as much as they can.
Unfortunately, as a contractor, I can suggest these things but not mandate them.
>>A few people end up discussing some minor point only of interest to them while everyone else stares into space
Mostly the manager's minions and pets talk, generally in a softer tone more towards appreciation bordering sycophancy. The remaining fear to give any genuine feedback, fearing retribution. If some one does speak they are taken as non team players who will be handled appropriately the next raise/promotion cycle.
The scrum master or even "team lead" is supposed to catalyze things a little bit in those situations. A lot of times there's a culture of "everyone knows about it, but nobody will say anything about it because they're afraid of the axe," where "it" is the thing that's horribly wrong.
These are clear symptoms of not having retrospectives facilitated in a proper Wat. A good facilitator uses different exercises, has people focused on a fixed scope or time period to catch learning points, supports a team in coming up with actions that they can do immediately and that are small enough to finish on a short notice.
The problem is that in many large organizations, the retrospective is a political game where the objective is to find and blame a person (or persons) who caused the team to underdeliver on the sprint. That mindset is an anathema to the sorts of honest constructive discussions that are required to meaningfully improve process. Instead the meeting turns into a toxic political mess that ends up disadvantaging the most talented developers on the team.
And I think that, in turn, might be a symptom of how large organizations often implement scrum. Scrum's meant to be an alternative to - even an inversion of - the traditional way of running software projects. But as it passes through the kaleidoscope of corporate culture, it's all too easy for scrum to just become a layer of makeup on top of the traditional approach.
For example, Scrum has a "scrum master" role that is most certainly NOT that of being a project manager. But usually a project manager gets placed in that role, and is naturally going to interpret the role by finding and then exaggerating analogies between it and the stuff they learned in PMP class. In the more traditional structure that the "project manager" role comes from, the PM owns and dictates a lot of the processes that the team follows, including daily meetings and suchlike.
This is in direct conflict with the idea that the entire scrum team owns and collaboratively determines the processes that they follow. And that idea is fundamental to the inspect/adapt process that the sprint retrospective is supposed to facilitate.
>>Without the retrospective, it's just modified waterfall.
This is true. But retrospectives will never work in any reasonably sized team, the reason is middle managers don't like being told or like being talked about their work in front of everybody, or being told to change something. Ego plays a big role in these things and they don't like being given feedback or advice, especially because these managers tend to think themselves as people in authority as all knowing and in complete control.
This is human psychology, developed over thousands of years. Masters never took feedback from slaves, so why should the modern incarnation of the older masters take advice from the current day slaves?
It takes a different mindset to make changes happen (agile or not). If people resists changing their mindset, nothing will happen and we keep struggling. That's a choice I'd rather not do.
Scrum has the particularly noxious side effect of driving underground any sort of drive to improve and to learn new things. An engineer in a Scrum team is an engineer, has his or her lane, and is largely expected to stay in it. Learning? Branching out? No, get your promised tickets done this week. That concerns me; while it's possible for a Scrum-based shop to invest in its people, it's not part of Scrum to really do so. And the people are what matter, at the end of the day, so I find it rather dehumanizing.
(This is a big part of why I'm moving towards consulting--so I can invest in me more often.)
Scrum's pre-committed units of work across the team promotes this; its one of the reasons that many groups prefer flow-based methods (which can support regularly-timed releases simply by shipping the features that are ready at the time of the release cutoff) rather than Scrum's cycle-based method.
I don't see how this is true. If you're building slack into your cycle there should be regular investment time available that a pure flow-based system wouldn't have.
If there's no slack in your sprint schedule, well there's your problem.
In my experience, Scrum's work-unit factorization encourages thinking of developers as spherical cows that need no personal development, with slack as a concession to reality that patches the damage Scrum itself causes. And Slack is generally considered to be for technical investment, though, not personal investment.
A good manager could think past that, for sure, but I've never encountered a good manager that felt Scrum was good or necessary for their teams.
I've never seen an agile article recommend rote meetings taking 50% of the week. Anyone even remotely interested in agility would call that an anti-pattern. I don't think it's a case of organizations blindly cargo-culting, but rather an inability to embrace agile.
Nobody who has any kind of interest in selling or implementing Agile anywhere would. That doesn't mean that the reality of the situation doesn't cause it to happen.
No, that's one of the really good things it's done. Half the time I'm not involved in any way in those discussions, so moving them out of the status meeting means I don't have to stand around listening to stuff that doesn't concern me.
Every time I read one of those posts, it makes me go back to http://programming-motherfucker.com and I enjoy it just a bit more than the previous time.
my company is "totally agile" (they wish) and it gives the management layer something to do cuz they are analyzing JIRA all day coming up with horse-shit charts, so of course they keep pushing all of it like its solving high-level organizational issues in ways we will experience tangibly sometime by 2018...
if you got rid of all that process infrastructure and just had a few programmers discussing proper design patterns now & then our company would be lightyears ahead of where it is now. i think everything becomes cargo cult when you refocus technical people onto processes that discourage technicality to make management feel fuzzy about their stats. people aren't more productive now, they are just gaming the agile system
process planning has its place i just feel like its becoming the focal point of discussion rather than a means to it. bureaucracies will continue to grow, what can you do other than look for a job with a more technical group that is focused on code?
i'm a former academic, i was astronomically more productive in that setting and there were no real process restrictions imposed at all. people need to be cultured into code & self-education, not process. optimize process once there is a good technical core in place, not in lieu of one
(i've also noticed that fake agile just promotes a lack of requirements docs from business... in that case i'd be better off doing damn waterfall with a half-decent reqs doc anyway...)
Urgh Jira. Jira symbolizes the entire problem. Issue and task tracking where the actual issue and tasks are 3 layers deep from the main interface, and graphs and burn down charts are front and centre. It's all carefully architected to appeal and sell to the managers who buy it, rather then the dev's who use it.
Contrast to something like GitHub, where code is front and center, and issues are a flat list and which has no other BS cluttering it up. Why? Because GitHub isn't selling a product to managers first - it's selling to to dev's first (via getting them in on open source).
- sit close to the customer (literally)
- write good automated test coverage
- release early and often and get feedback (see point 1)
If you are doing those three things, it's hard to totally fuck up.
There is a lot of process in making those things happen to be sure, but how that process happens is not important.
the Agile Maifesto / Scrum tried to downplay process so much it became a by-word for no process, and almost broke the good it was doing as no one could track / report what was going on so every implementation looks like an uncontrolled mess.
(Yes there were sticky notes up on boards, but it's hard to mail that to upper management)
So a little more process, a lot more talking to end users and waaaaay more automated tests and automated releases and we might have something
Feedback from customers by iterating and releasing early and often.
Feedback from the team with proper frequent retrospectives.
Projects that I have been part of that skip or mangle retrospectives have all struggled. Listen to the team. Keep tweaking, improving every week/sprint. But keep the delta low so you can see what actually made an impact. And keep retrospective to mostly the team only so root causes are actually mentioned and not railroaded by external chiefs.
If GROWS became popular, it would also be 'sloganized', branded and ruined. People would go to one-day intensive GROWS courses, get certified and then just do waterfall anyway - exactly what's happened to Scrum and everything else.
I find it slightly ironic that they (correctly) say they are no silver bullets, then suggest a silver bullet.
I don't know anyone who just does waterfall anyway except for simple projects. You just can't get all you architecture and design done up front. There is a lot of iteration between architecture, design and coding. Requirements change and things need to adapt. That is not waterfall.
> If GROWS became popular, it would also be 'sloganized', branded and ruined.
Claiming a trademark is a threat of legal action against those hijacking the name to sell things in the same domain using the name without permission, which could be a potent way to prevent people from marketing things that are exactly the opposite from it calls for using its name the way it happened with Agile.
> People would go to one-day intensive GROWS courses, get certified and then just do waterfall anyway
Only if the owners of the trademark license GROWS certifications; if they are serious about preventing hijacking, they'll tightly control how the trademark is used and only use it on material (books, videos, potentially courses) consistent with the the intent of the system, and not for certification of people.
Is it April 1? Andy poo-talks Agile and then drops GROWS (TM) on us? You have got to be kidding me.
It's been mentioned on here a lot that if you have a skilled set of programmers on your team you probably don't need Agile. They are self-managed and tend to do the Right Thing (TM) on their own.
I have seen Agile work and when it does it's pretty fun. Things move along, issues are dealt with, and nobody panics when things get behind a little. Just move it to the next release.
I think the problem is that The Consultants sold Agile to enterprise dev shops and they really ate it up. I don't feel Agile works from the top-down but rather organically from the bottom-up. In fact I believe that is true for most programming methodologies like this.
This. Craft and passion beat any process. These people will organize themselves into the most efficient process eventually.
My direct experience of working with programmers over the years is that this will generally descend rapidly into an inefficient mess. Yes – maybe it works, sometimes. I'd argue that's the exception, rather than the rule.
If you work with people who dont care, youre screwed. Nothing will ever work to force them to actively engage with the process of creating good software.
..but, surprisingly, when you do work with people who do care, they self organize remarkably well. The Valve megacorporation is fundamentally based on this. It works. Thats been my personal experience, over the years.
The problem that has to be addressed is convincing people to care, and self improve.
Forcing a process on the unwilling is going to fail no matter what you do.
And often they self-organise by taking an established process and bending it into something that works out for them. Which is fine. But that doesn't mean designing a process is useless - if it's a good base it'll be easier for the team to adapt it into something that is good for them.
I agree that a group of people who don't care will almost always produce substandard results.
I don't agree that people who do care necessarily self-organise well, or that this self-organisation is compatible with other business goals.
Sometimes it works, and a group of engineers et al. do a good job of forming a coherent team with minimal process. Valve's maybe an example – I don't know. My experience is that this is the exception, rather than the common case.
A good process can provide tools that help good people who care communicate and deliver more effectively. They help us to keep track of how we're performing and analyse pain points, and to make sure that there are methods for dealing with common problems.
For example, if my team felt that daily stand-ups were an inconvenience that weren't helpful, then we wouldn't do them. That's the goal; there's no cast-iron set of rules, just a generally applicable set of principles to follow.
You know, I probably don't know as much as you do, but every time I've ever seen lots of negative reinforcement get applied to teams both in software and outside, it seems to have the opposite effect. Sometimes you have to quietly handle the most toxic people, but on the whole, when you take this sort of approach to managing, I would be very surprised if you only make the situation drastically worse in the long run.
> if you have a skilled set of programmers on your team
Emphasis mine. You probably have more experience than I do, but largely I've seen it to be true that skilled (or, in the absence of skill, passionate) programmers tend to self-organize, as long as they all have the same goal (which hopefully is true for the majority of your team - if not, no methodology is going to help you).
At several previous jobs I went on and on about how most process was unnecessary and nobody would believe me that you could do with less process. Then I joined a company with better people that has minimal to no process, and we make it work well, and it's the best job I've ever had.
All the companies I was at before this one that hid behind process had the usual problems with quality, scheduling, communication, etc. There's no process that's going to pull excellent work out of average people. It's just band-aids that keep people from taking real responsibility because they believe the Process will take care of things.
Absolutely... as others here have said, if you don't have people who want to think, then no amount of process can save you. You only have deal with any official bureaucratic process or government department to see that.
From my POV, a minimum amount of process is useful to keep things on the rails when the pressure goes on, so people don't end up doing things wrong. After all, unit tests, git and CI are 'process'...
Those people also cost money, and most managers are allergic to spending money on good people (ignoring the difficulties in finding those people in the first place).
I have just bought a "Learning GROWS" book from the Pragmatic Programmer online store, and have hired a consultant to educate (inculcate?) the team on the new methodology.
We even are using one of the new open source libraries that tests and enforces the process, it is called 'poison ivy' - it hurts, like all good software engineering processes do!
Edit: do the downvoters disagree? We don't think there will be books, courses, tools for this new methodology?
We're not humor impaired, there's just a higher bar. Otherwise it becomes like every other internet forum ever: dominated by one-liner meme-based reply-chains that drown out the real conversation.
^^^ Exactly this. I've seen Agile work extremely well when experienced developers decide "we need to change how we've been doing things". Coming down from management it becomes just another way of lowering the boom on development. Furthermore I think the correct pronunciation for "Scrum" is "Scrummerfall".
> I don't feel Agile works from the top-down but rather organically from the bottom-up.
I believe that is the crux of the issue. Larger organizations, and especially those that view IT as a cost center, do not feel comfortable giving control to programmers.
Every time a consultant proposes a new method with a new name, it seems like it's just a way to create a side industry; a long con that doesn't really attempt to fix the larger issue. I believe the hard problem to solve (which may be impossible, I'm not sure) is getting an organization to see their programmers as business collaborators rather than an inconvenient necessity.
I largely agree, but think it has more to do with passion or interest than strictly skill. Any process that leads people to work with each other to GSD seems best. The best project I've ever been apart of was with myself and a couple others in other time zones in our free time. We communicated by email with our progress, what we planned to do, what we needed from others, etc. And since the team was small, everyone had their place and pitched in, and we created something beautiful at an amazing pace. It is an open source project I work on to this day, though largely just small fixes anymore.
In a corporate environment, you tend to have some burn outs, some 'holier-than-thou', some paycheck collectors, etc. The biggest difference probably is that you can't choose who you work with. It seems Agile as I've seen is implemented around that, which ultimately discourages the behaviors described in the prior paragraph. It becomes one writing quickly to finish things for the manager, rather than writing things for your coworkers.
> if you have a skilled set of programmers on your team you probably don't need Agile. They are self-managed and tend to do the Right Thing (TM) on their own.
"Any sufficiently complicated company w/o management contains an ad hoc, informally-specified, bug-ridden, slow implementation of management”--wycats
I think that I left software development just as these schemes where becoming en vogue.
Being on the outside of the industry and reading about all of these acronyms of "how to succeed with great apes" ... it reminds me of being in middle school band. It smells like how first chair worked to get all of us clarinets to practice more and to try to out do each other performance-wise.
It works.
But eventually it changes from first chair to "first chair". And then it became, iirc, a lighting-rod for interpersonal problems amongst the single-reeds that became disruptive.
I suppose that I think of these schemes as MBA-encoded first chair politics. They work while the meta-game is immature. But as soon as players get to see the carrot for what it is ... it is all about a competition for who gets to hold the stick.
The problem with agile development has always been Agile Development.
Cargo-cult management practices freely adopted the brand facade without embracing or even understanding the underlying principles that must be present before the branded process elements can be good practice.
I don't care how good your process consultants are. They are not going to convince any manager to reduce his own importance within the organization. Just like it is much more difficult to make software secure by waiting until version 2.0 to add it, it is harder to make an organization agile by patching that in after the startup phase. It is far easier to be born agile than to reorganize into it.
The failure comes when trying to convince a clumsy organization, with plenty of vested interest in remaining that way, to become agile. What you end up with is a racing stripe painted onto their t-shirts and shiny plastic spoilers taped onto their asses, and no real improvement.
So in this context, GROWS will also fail. The only way to stop it from happening is by the developers pushing back hard against any more brand-name processes that are uncritically peddled to any organization flush enough to pay a process consultant. Screw your new snake oil, buddy. My org listens to me barely enough right now, and I don't need anyone messing that up with some new kind of pointless meeting.
This has to be a really late April Fools' joke. There is no way in hell they could seriously be trying to pitch a "basically-new-agile-methodology" that is this buzzword laden. I mean, the (TM) on the name?? Come on...
Trademarking the name may be a way to prevent GROWS from being hijacked the way Agile has been. The reference to the Dreyfus model makes me suspect that (aside from rebooting to bypass the way Agile has been coopted) this may be an attempt to put some concrete guidance into the metamethodology of developing process in an Agile (in the Manifesto sense) organization, which was always a fairly big gap in the Agile literature, which tended to be largely principles plus the specific processes used by specific organization, without covering how the agility actually should work (though, if you got outside of the Agile brand into works on Lean, which is pretty much the same set of principles arrived at from a basis that has much stronger process engineering background, and so tends to feature a lot more work on concrete methods of process evaluation, there was quite a bit of that.)
agile per se is good -- making it a religious is ususally bad;
I saw many companies using scrum and often I felt like this is a process for slower moving teams, instead of the opposite;
Great software is being written by great individuals that move it forward, pretty indecent of whatever process a company tries to use. To me a process must not get in the way or productivity and creativity.
The problem with agile is that it requires a completely different way to think about productivity and company finances not just in the team but the entire connected reality of a project.
Agile solves a conceptual issue which is it creates a more effective feedback loop that keeps everyone more informed than they used to be with classic waterfall models.
The problem though is that the financial reality isn't following the logic of the agile model and so whether you are trying to use the agile model for customer projects or internally in your organization you are still a child of the the overarching financial reality which dictates how companies are measured and budgets created.
Agile is great for innovation where there is no deadline and no limited budgets. It creates a false sense of effectiveness when it comes to projects with deadlines and budgets.
At the end of the day all it does is allow you to say earlier to those you have to deliver to that they aren't going to get everything they asked for at the same price as what they thought they were getting.
> "Agile is great for innovation where there is no deadline and no limited budgets"
that rings very true with me. I'm nearing the end of a 3 year project where scrum was prescribed and followed, but the truth is we've basically shoehorned agile practices into a waterfall model because of business needs.
My experience with agile projects is probably far removed from how it should be implemented, but it still feels like it's fundamentally flawed to address business needs which rely on fixed scope and accurate estimates from the start of the project succeed (e.g. critical 3rd party tools being end-of-lifed, product mandates beyond company control, renewing client licenses based on feature completion).
I guess until something better comes along, I'm stuck with being told to do some strange type of scrumfall/water-gile.
Almost every new idea in software development is having problems when facing "majority adoption" phase. Agile definitely is replacing waterfall now and there are so many people that capitalize on this trend and don't give a shit about agile roots and principles. Every new wave is eventually hiped and monetized. Agile is not an exception. It doesn't mean agile is bad, it just means agile went mainstream with all side effects.
I personally have a strong feeling that this article is just another attempt to monetize agile, by selling "agile failure". Agile is not failed for sure. Some people did.
Every new idea in management have problems at the "majority adoption" phase. Software is no exception.
Those problems appear because organizations are chaotic, in the mathematical sense, in that the sum of the details completely eclipses the worth of any idea. And that's an inherent problem.
The proposed solution feels good and all but in my experience it would be almost impossible to adopt for most companies operating in VC-istan.
The most extreme case I can think of was a "startup" I worked at that was VC'd to the gills, had an impressive board, with no traction, no revenue and about 25 engineers on staff. What they did was what I liked to call "product development by whim" where they had 5 product managers which each got to decide which features they wanted and the devs went and built it (we really really really needed a way for our non existent users to invite their friends via email, etc).
So if we needed evidence before development the whole house of cards would come falling down because the evidence would have shown no one wanted what we were selling, period.
Agile glorifies treading water, which will sometimes save your life, but won't get you anywhere. The problem is that it discourages actually swimming, and people forget how.
To explain: where this sort of project management actually works is in a short-term, time-limited crisis that large companies might call a "Code Red" or (in the original meaning of the word) a Scrum. See my Quora post on the topic: http://www.quora.com/Why-do-some-developers-at-strong-compan...
When you're a small web consultancy that has landed a make-or-break project that (say) must be delivered inside of 4 weeks, and when you have absolutely no leverage and must accept any changes in scope as they come, Agile can work. You can reasonably expect people to set aside their long-term goals (career progress, tech debt reduction) and solve the problem at hand. Moreover, when you're a big company fighting a Code Red (meaning, money is being lost right now in large amounts) and have to assemble a cross-cutting do-nothing-else-for-now team with no clear manager, Scrum can actually make sense.
In a true sprint-- a short-term reorganization necessary to solve an immediate problem-- unsustainable effort is OK because, well, no one's going to be expected to sustain it. You're under a short term emergency. You can ignore whether the assigned work helps peoples' careers, because they're not going to be doing it for long. You can mandate that people work on the "official" top priority (of which there's only one) and most people will do so.
The problem is the perma-Scrum that's been sold (dishonestly) by the Agile industry. This stuff works for a few weeks and people don't mind doing it. In fact, even if the work itself is painful and the hours are bad and status updates are (by necessity) frequently demanded, being tapped for the "elite emergency team" is something that people generally like and, over a span of 2 to 6 weeks, it gets results. However, when you have permanent "sprinting" and frequent status meetings or impose these rules over the whole organization, it starts to hurt morale. It starts to feel less like being on an elite emergency team and more like a culture of permanent juniority/micromanagement... which is what Scrum/Agile has become in many organizations.
Long hours are just one variety of unsustainable practice. Accumulation of technical debt, and an absence of concern for individuals' career needs and goals, are likewise acceptable in the context of a short-term emergency but not sustainable.
In perma-Scrum terminology, though, the end of one sprint leads straight into the next. This is the core problem with Agile/Scrum as it's sold: it takes behaviors that are known to be unsustainable and encourages people to carry them permanently, and then says they're not doing them right (No True Scrumsmen) if the arrangement deteriorates. It can't be sold truthfully, as a short-term fix that does a lot of damage if it stays in place for too long-- no one would buy it if it were advertised as something that only works for 6 weeks, max, out of a given year-- so the Agilemongers present it as a permanent arrangement.
I think you are confused. A "sprint" is not "crunch". Its not a period where we work our asses off, late hours, weekends etc. A sprint is just a period of time. For us its two, forty hour weeks. Its sustainable and we've been doing it for 16 months.
It leads to a very confusing situation, where on the one hand the team is lauded for being the most productive team in the company, and on the other, for not working hard enough. o_0
If you can find anything in any Scrum publication that says otherwise then you can make the No True Scotsman claim, but otherwise you are at best misinformed.
Over on http://growsmethod.com/, when you sign up for the mailing list, the page confirming your subscription is loading in mixed content (JS!). I'm suddenly not inspired.
That said, I don't see the point of "methods", agile, waterfall or otherwise. When I worked building SaaS for school districts, we shipped roughly once a month, so I guess that was waterfall, but some ideas we iterated multiple times within that ship period until we liked one. Now I work with a set of e-commerce websites, and nothing front-end isn't AB tested (which slows down shipping anything), and new backend functionality is iterated almost daily. But I've never called these methods anything other than the right approach based on the situation.
The reason that BigCo never does capital-A Agile is that their release dates are fixed months ahead of time (to coordinate across the organization), and they want to know what they'll actually be shipping in 6 months (again, to coordinate across the org). This makes the biggest two selling points of Agile - continuous release and rapid change - completely worthless.
The only model I've actually seen in a large organization is for the dev team to throw together a barely-working prototype, then spend the next 6 months fixing all its problems while the Marketing, Sales, and Customer Service departments train up on the new software. And they'll find a way to call this "agile", because otherwise the developers will revolt.
I still remain totally unconvinced that 'Agile' is broken, or has failed. I have worked in places that do FakeAgile, and places that do GoodAgile, and there are two conclusions:
1. Bad companies and practices will not be magically fixed by applying 'Agile' or whatever other methodology you want.
2. When companies do agile development well, it is effective at solving some of the worst problems that software development faces.
Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology. I'll tell you what our process is.
- Spend a couple of hours planning a sprint of work. Two weeks, in our case. During that planning meeting, look at the backlog of features and tickets that the product manager has built up. Identify tasks we can reasonably accomplish in that time frame, ensure we have enough information to start, and discuss each one so we have a clear idea of what it involves.
- Make sure that those tasks are customer-visible features wherever possible. It's not always the case that this can be done, but it helps to provide feedback.
- 10-minute daily stand-up to discuss any issues and communicate who's working on what. Also time for the product manager to feed back any information from outside the team.
- Work on some tickets. Review the code. Pass them through QA. Deploy them. Let the product owner receive feedback from customers.
- Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.
That's the core of Scrum, and I don't see what's wrong with it. The problem arises when it's abused; story points as burndown charts, or productivity monitored in terms of 'number of tickets finished', or whole-company stand-ups, or whatever.
Agile development works well if you're agile. It's not a set of rules that must be followed – it's a set of guidelines that can help to improve the development process. If you are performing useless, time-consuming overhead tasks, then you are not doing Agile – end of story.
Agreed (though maybe not "two years"), and that was what I was getting at. Scrum is not a system for investing in people--and we need to do that. It's a fairly exploitative mode of organization and this industry's largely uncritical adoption of it is something we don't look at particularly often or with much real gusto.
You're right – Scrum is a process framework for developing software.
That is totally, absolutely, 100% orthogonal to professional development. I work in a mostly-Scrum environment as I described; that doesn't preclude research, or conference attendance, or any other form of professional development.
Bad culture is bad culture, regardless of development methodology.
What you're essentially telling your engineers is that A) doing their job has nothing to do with getting better at their job, and B) if they want to advance beyond the junior engineer level, they will have to do so on their own time. I've seen this referred to as "terminal juniority."
Having a development process that does not produce senior engineers is a problem, even if you try to make up for it by providing a conference attendance budget and a Safari books membership. At the very least, such a process unfairly penalizes those with large personal time commitments.
Fantastic post, and I agree. I've always been in a weird place professionally because I came out of school at a somewhat-above-junior level and so I've been in an interesting position to watch companies try to mold developers. There's that "five years of experience"/"one year of experience, five times" thing people sometimes refer to, and Scrum seems tailored to doing the latter.
Terminal juniority is an amazing term for that. Thanks.
"That's the core of Scrum, and I don't see what's wrong with it."
Depends on what you are trying to do. Add some buttons and a new report feature to some 100K code base with 5 programmers? Sure, why not. Get changes in front of the customer quickly, backtrack or iterate, and so on.
Software for a medical device? Not so fast, bucko. Endless regulations (for good reasons), extended test cycles, changes require changes to hardware, long sales cycles, well, scrum is not your friend. Neither is waterfall, or whatever strawman someone wants to erect. I've worked hard projects (military hw/sw) and no well defined process gets you there. It comes back to the real core of agile, which the OP emphasizes - inspect and adapt.
2 week sprints (or any other number) makes no sense if you are held to an external release schedule (work for TV, sports? You are going to be releasing on that schedule, not your 2 week sprints, sorry). Do you have subcontractors? Scrum usually doesn't work there, especially if they are making hardware. Work in a truly 'requirements change' environment (TV, war, etc). Ya, sorry, not going to work to the end of the sprint no matter what, no requirements changes allowed. Conversely, is someone making hardware for you, or are you making hardware? Changing something could change delivery dates and costs by months to years. You can't just treat every 2 weeks as a new day (so to speak), changing things willy nilly. Want to build a search engine or a cloud infrastructure? Lots of planning required - you can't just add features every two weeks.
Scrum is a tool in the toolbox - if the problem you are trying to solve fits its assumptions it'll work fine. But it sticks it head in the sand about things that it considers hard. For the right domain that is brilliant - requirements are hard, let's get ideas in front of the customer sooner, because they don't know what they want anyway. Scrum says 'schedules are hard' and decides not to do schedules. Great if you don't actually need schedules, but if you need to deliver a hw/sw system for a business opening (say), well, you better be scheduling. And soft starts are not an option (as I said before, I used to work for the DoD, now I work for TV - you mostly can't soft start war or the Super Bowl). In military work every meeting is basically risk assessment - what are the risks I am facing, and you manage and mitigate from there. Risk is not in the vocabulary of scrum, and it is hard to think about things when you don't have a vocabulary for it. When I start something or work something I think in terms of 'goals, strategies, and tactics.' Ya, military again. But it works. Goals usually don't change, and you need to choose strategies and tactics to meet those goals. But people get wound around the axle 'we must do X' - well, not if X doesn't meet the goal. 'but X is agile'. I don't care, it's the wrong thing in this case. Scrum, as practiced, doesn't give us the vocabulary for that (the linked article does in the 'think and adapt' paradigm, but that is still a bit too loosey goosey for me). What are we trying to do (goals), how are we going to do it (strategies), and what are we doing today (tactics) is a pretty good, but imperfect way to organize your thoughts.
Scrum can work in places in those things, sometimes. Have a mobile app that is digesting and displaying the data of your system? Maybe/probably that can be scrum (maybe not if medical - regulations, extensive testing, and so on).
Brooks is still right - there is no silver bullet. There is no alternative except think, observe, pull the levers for which you have control, observe the feedback loop, adapt, and continue on. If you need a schedule, make one, and then adapt a risk control methodology to keep costs and other creeps in line.
Scrum is a system. Where else in engineering would we have 8 or 10 rules where we argue that wou...
I completely agree that Scrum isn't suitable for all software development, and that there's no silver bullet. If it doesn't work, then that's totally okay – don't use it. Doesn't mean it's 'broken' or 'dead', as so many claim.
Scrum is a system in the sense that it provides a framework upon which you can build a sensible process. Not every aspect works for every environment, and that's totally fine! It's the key principle of agile development.
I think what's happened is that so many places have completely ballsed-up the implementations of processes like Scrum, and that's given it a bad name. People naturally push back against that. I do find it a little frustrating that the two issues are conflated so often.
As an aside – at it's core, Scrum is just a process that breaks development work down into small, actionable parts. In most cases, that's an internal implementation issue, and is still compatible with meeting fixed external deadlines. Again, it's situation-dependent, but that's why it's advisable to avoid agile-by-numbers and implement the parts that work.
> Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology.
Scrum is a useful development methodology with some teams in some contexts, and is often a reasonable process starting point for team seeking to apply Agile principles in software development.
> Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.
This (without the "sprint" and "when its done" or the specification of the 1-hour timebox) is really the core of Agile: regularly evaluate the results you are getting applying your current methodology with your current team to your current set of challenges, determine what is working well and what isn't, and revise your processes accordingly to make them better.
If anything else is viewed as "core" and non-negotiable, your organization isn't Agile and, in regard to those particular areas, you are elevating process over results.
Your process is one of the things you change. You hack it. You can try a change for one iteration and evaluate at the end of the iteration.
If you have a Defined Process(TM) - of whatever flavor - you're missing a big part of agile, perhaps even the most important part.
Let your process adapt to your people, your environment, your situation, your project, and your goals. Eliminate everything that isn't useful; shorten to the minimum everything that is useful.
Even if you started with Agile(TM) as defined by a Scrum Master(TM), but you're willing to change the process as you find out what doesn't work or is wasteful, you can still converge on something pretty good. You just have to keep tweaking the process, paying attention to what works and what doesn't.
Or to put it in XP terms: Pay attention to pain, not just in your technical areas but also in your processes and procedures.
Is a "new Agile" really what will solve this problem? I think really this just isn't a priority for many employers. Maybe we just need something new so us employees can see who's paying attention and flock there?
260 comments
[ 3.0 ms ] story [ 275 ms ] threadI mean, it's completely tautological; conveys no useful information, and must be fully understood before acting over it in any way.
It's also funny. I'm upvoting :)
But then it goes downhill with proposing yet another model that will people will try to adopt verbatim, and again, experience failure to implement.
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
What really killed agile fwiw, where the consultants, going from development team to team, peddling false hope, snake oil, and tedious time zapping process that people learnt to game rather than actually deliver.
Of course, someone will pop up saying agile is awesome, they love the daily scrums, the project is fab, the sky is blue, etc. Question is: can it be better?
^ this. Agile is only a set of principles set out to help write flexible software. It in no way made the actual writing of software, the gathering of requirements, the effort of design, easier; it simply gave us a process to follow that could potentially help avoid tedious re-writes. At the end of the day it's up to the people to put in the effort to make good software
[2] I have also seen practitioners and consultants that never did a single-frickin-project in their short lifetime, but preaching success. That's how you get wrong - theory and practice are often 2 very different things. And when the shit hits the fan, people say "you are doing the agile wrong". Alright.. teach me master, and admit how wrong you were 14 years ago. p.s. Apologies for the rant.
You know Scientology, Amway and most other cult-like phenomena say the same thing: It's never the "system" that's wrong, if it's not working it means you're doing something wrong. You missed something, you didn't try it hard enough, you didn't do it like X, Y, Z.
Agile is awesome because its not a process, but a set of principles which addresses exactly the problem that context-blind adoption of processes creates that makes good teams mediocre and bad teams worse.
Most of the processes sold in a context-blind manner as "Agile" suck, but they are a recreation of exactly what the Agile Manifesto was a reaction against.
No, the reality is that Agile is not a process, though there are a number of different processes sold as "Agile". (The most common now seems to be Scrum as defined in the Scrum guide and a number of variants on it; for a while XP was somewhat prominent as well.)
> find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant.
Teams that do that are Agile: that's exactly and all of what the Agile Manifesto says.
> I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.
The thing is the "Agile movement" consists of two separate and opposed forces: one (and the origin of "Agile") is people promoting exactly the behavior you mention characterizes good teams, the second (and the thing you seem to have a problem with) is people using the name that the first group came up with to promote exactly what the first group is reacting against -- rigid, context-blind adoption of externally-developed process (largely as a reaction against the threat posed by the good ideas of the first to the second groups pre-existing business of selling rigid, context-blind processes.)
And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?
The end reality is we have an entire industry built around that stupid manifesto. Sure, it's not what they wanted, but it's what we all got. We would have been better off without it.
Because while there are lots of people who won't understand that with an explanation, and some people who get it intuitively and don't need an explanation even with all the noise from people selling one true way, there's also lots of people in the middle who benefit from people selling there one-size fits all approaches not being the only voice in the marketplace of ideas.
> The end reality is we have an entire industry built around that stupid manifesto
No, we have an industry that existed long before the manifesto built around selling canned, context-blind process and jumping on anything even mildly popular to sell it that, predictably, when the manifesto calling for exactly the opposite of what that industry sold became popular, jumped on that to sell exactly the same thing they'd always been selling.
> We would have been better off without it.
No, I think that there are lots of people who have learned something from the Agile Manifesto, writings actually addressing how to implement its principles that don't amount to context-blind process, and related movements (Lean software development, etc.) and applied the ideas to improve teams and make software in a better way.
Most developers -- before and after the manifesto -- work in places where management is operated with shallow knowledge and poor respect for their staff and buying whatever consultants are selling in terms of process, sure, but that's not the fault of the Agile Manifesto
People are soft and squishy. Too much rigid process pevents taking advantage of that squishiness. A complete lack of process will result in those squishy humans just producing a gooey puddle.
For every piece of process:
There is some good guidance it there, but you have to get outside of the Agile "brand" for most of it, since much of the work on evaluating methods and other aspects of higher-level metamethodology that fits in with Agile principles is associated with "Lean" rather than "Agile".
http://agilemanifesto.org
I think bean counter types throughout the business world truly believe there must be some secret fairy dust you can use to transform mid/low competency people into high competency people, and dysfunctional teams into highly functional teams. It's about wages. It's essentially a delusion that you can take cheap, socially lower status people and substitute for more expensive people as long as you have the right fairy dust.
The mentality works to a degree for certain disciplines. It works with McDonalds employees. You can apply management theory and systems to an infantry brigade and get good results from lower grade enlisted men.
The model simply does not map over to the "creative" professions and crafts. But managerial types are often averse to the idea that software engineering is a proper profession on par with their own, not commodity, and must command high pay. They prefer to keep seeking the right fairy dust.
>>socially lower status people
This depends on the environment. Working for a consulting company, where time spent on the project is billed to a customer and the project has a fixed budget, Process is needed to make sure the project is estimated and executed properly, and the arse-covering helps to guarantee that you get paid when the customer makes changes mid-way through that increase the project costs.
It would be fantastic to work on projects with open-ended budgets and collaboration with customers to figure out what the software should be as it's being developed, but in the real world I don't think that is often possible. It's not just consultant/client relationships; even in big companies where IT is given a budget from upper management you have the same situation. Management won't approve a budget without a detailed description of the deliverable, and IT can't exceed the budget or deliver something other than what was promised.
Waterfall, for all of its drawbacks, handles this situation well. The problem is that no one wants to pay for all of the paperwork and management overhead it requires to function properly.
Every time you see someone succeeding at Scrum, it's because they're also doing most of XP.
Maybe we need to go back to our roots. I know that several elements of XP have only recently clicked for me and I feel foolish for having taken so long (but nearly everybody I know is still struggling with those aspects too, so I'm in great company). And I was exposed to XP in '99, which means it took me 15 years.
Scrum has been the largest offender - squashing discussion in standups, allowing scrum to erode QA process, rote meetings that take 50% of the week, story points and refusing to discuss timetables in hours when absolutely needed, reporting status multiple times, having others estimate tasks who are not doing those tasks, etc.
These organizations that have done so have been some of the least agile, and waterfall-esque organizations can even be better. (They planned up front well, they changed a few minor things in the middle maybe, but cut out the overhead).
Without the retrospective, it's just modified waterfall.
My personal view on scrum is it attempts to trick a software team into micro-managing itself, and it usually results in feeling like kindergarten as a result.
The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to.
I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is.
When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens.
Scrum is, to me, something people pick when managers don't want to manage.
I like release-early release-often, MVP (in small doses), see http://michaeldehaan.net/post/118860078737/the-rock-paper-sc..., and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead.
I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough.
(Not everything fits in two week blocks either)
Sounds like your teams were underestimating task effort.
>>If you have a PM that doesn't allow time for such things, it can be rough.
Anything's rough with a shitty PM, which is what you've described.
But yes, it's a people problem.
Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.)
> Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
Ok, explain this to me. Why is this not a meaningful number?
Story points are essentially hours and generally in the shops I worked in, they are converted to hours. If something takes longer, the hours are adjusted.
So really, that's a metric for maximum hours worked ... why is that not a good metric?
If someone is on a remote team and they're expected to work 40 hours a week, why is measuring the maximum hours they were on the job a bad metric?
I'd think by and large you would evalute remote workers by theit work output, not by estimating how much time they've spent.
Which is what? Lines of code? I think that's even worse.
How do you determine how much work to assign someone if estimates are meaningless? How do you determine if someone is productive or is doing one hour's work per week?
Aside from insults, I don't really see any answers. Have you ever been in a PM role?
Again, if you adjust estimates as you're doing the work ... as in, it's more complex than you thought, so you adjust the estimate ... why are estimates a bad metric and what metric (something that can be quantified) would you recommend?
I never said that estimates were meaningless, but they are tools for planning with high intrinsic uncertainty, and translating that uncertainty to evaluations gives unfairness. People are very sensitive to (perceived) unfairness and the idea that they will be treated so will give rise to resentment, not to mention incentives to game the system and overestimate. Hence endless bickering about points.
If agile failed for any reason it was misunderstanding human psychology.
Personally I don't think human performance in creative professions is well suited to quantified analysis, especially when team efforts are involved. So I don't really have an answer there.
This is a really good observation, I think, and lines up with my own experiences--every incapable manager I've ever had thought Scrum was a great idea. The ones I've known have been very linear thinkers with a tendency towards restricted domains of thinking, and Scrum reminds me a little bit of Orwell's "if you can't say it, you can't think it" idea. Scrum gives you a vocabulary that, if you hide in it, requires you to confront many fewer things and make fewer choices.
They're almost all the wrong choices, I think, but there are strains of manager that find choices anathema in the first place and so I can see the appeal.
Which is what a retrospective _should_ be! "what went wrong, what went right, how can we change our process to keep those wrong things from happening again?" It doesn't necessarily need to be a meeting. The introspection needs to happen, though. No matter what type of process you have - if it's not being constantly reevaluated for efficacy, it's just cargo cult.
I've only been at ones that work. I don't see how you could ask these questions and have it be a time sink: https://www.scrumalliance.org/community/articles/2014/april/...
>> What went well during the sprint cycle? >> What went wrong during the sprint cycle? >> What could we do differently to improve?
I have had Agile Evangelists, who are supposed to be good at making this stuff streamlined, turn around and say "Everyone needs to come up with five things in each category, then we'll go through and discuss them all, deciding on the most important things to change at the end"
In a team that was already too large (15ish people) I watched that eat an entire afternoon and produce no useful output on more than one occasion. In the team I was on (four, five?) it still seemed to take hours.
I know, I know, they were probably doing it all wrong, this is just my experience of one workplace.
I'm not saying it can't be done right, just that it doesn't seem to be a magic bullet and can devolve into navel-gazing.
A pretty important point for making scrum work, however, is aggressive timeboxing of everything. If you don't want retros to become a 4 hour developer-kvetch about somebody else's team, start by ruthlessly clipping it to 45 minutes.
I understand that this is not always an option in malfunctioning corporate environments; but Kanban/XP/programming motherfkerism wouldn't fly either in those situations.
When I rule the world, as they say, every meeting will contain only the people it needs to, "I don't feel this is relevant to my work or that I can contribute" will be the best reason not to attend and time limits will be aspirational in as much as everyone will aspire to beat them by as much as they can.
Unfortunately, as a contractor, I can suggest these things but not mandate them.
- A few people end up discussing some minor point only of interest to them while everyone else stares into space
- Every retrospective ends up being the same as the previous one: it's like someone recorded a meeting 2 years ago and plays it back every 8 weeks
- Things that went well are all internal; things that went badly are all other teams' fault (this can't always be true)
Yes, I realise those aren't really agile issues, just a symptom of having a relatively poorly defined meeting with lots of people.
Mostly the manager's minions and pets talk, generally in a softer tone more towards appreciation bordering sycophancy. The remaining fear to give any genuine feedback, fearing retribution. If some one does speak they are taken as non team players who will be handled appropriately the next raise/promotion cycle.
There fore no one talks.
For example, Scrum has a "scrum master" role that is most certainly NOT that of being a project manager. But usually a project manager gets placed in that role, and is naturally going to interpret the role by finding and then exaggerating analogies between it and the stuff they learned in PMP class. In the more traditional structure that the "project manager" role comes from, the PM owns and dictates a lot of the processes that the team follows, including daily meetings and suchlike.
This is in direct conflict with the idea that the entire scrum team owns and collaboratively determines the processes that they follow. And that idea is fundamental to the inspect/adapt process that the sprint retrospective is supposed to facilitate.
This is true. But retrospectives will never work in any reasonably sized team, the reason is middle managers don't like being told or like being talked about their work in front of everybody, or being told to change something. Ego plays a big role in these things and they don't like being given feedback or advice, especially because these managers tend to think themselves as people in authority as all knowing and in complete control.
This is human psychology, developed over thousands of years. Masters never took feedback from slaves, so why should the modern incarnation of the older masters take advice from the current day slaves?
(This is a big part of why I'm moving towards consulting--so I can invest in me more often.)
Scrum's pre-committed units of work across the team promotes this; its one of the reasons that many groups prefer flow-based methods (which can support regularly-timed releases simply by shipping the features that are ready at the time of the release cutoff) rather than Scrum's cycle-based method.
If there's no slack in your sprint schedule, well there's your problem.
A good manager could think past that, for sure, but I've never encountered a good manager that felt Scrum was good or necessary for their teams.
Then management comes over and asks why you're slacking off.
But that's the problem of arguing from anecdote.
No, that's one of the really good things it's done. Half the time I'm not involved in any way in those discussions, so moving them out of the status meeting means I don't have to stand around listening to stuff that doesn't concern me.
It's oppressive.
if you got rid of all that process infrastructure and just had a few programmers discussing proper design patterns now & then our company would be lightyears ahead of where it is now. i think everything becomes cargo cult when you refocus technical people onto processes that discourage technicality to make management feel fuzzy about their stats. people aren't more productive now, they are just gaming the agile system
process planning has its place i just feel like its becoming the focal point of discussion rather than a means to it. bureaucracies will continue to grow, what can you do other than look for a job with a more technical group that is focused on code?
i'm a former academic, i was astronomically more productive in that setting and there were no real process restrictions imposed at all. people need to be cultured into code & self-education, not process. optimize process once there is a good technical core in place, not in lieu of one
(i've also noticed that fake agile just promotes a lack of requirements docs from business... in that case i'd be better off doing damn waterfall with a half-decent reqs doc anyway...)
Contrast to something like GitHub, where code is front and center, and issues are a flat list and which has no other BS cluttering it up. Why? Because GitHub isn't selling a product to managers first - it's selling to to dev's first (via getting them in on open source).
You can ditch a lot of the cruft from Jira by making your own dashboard etc.
the Agile Maifesto / Scrum tried to downplay process so much it became a by-word for no process, and almost broke the good it was doing as no one could track / report what was going on so every implementation looks like an uncontrolled mess.
(Yes there were sticky notes up on boards, but it's hard to mail that to upper management)
So a little more process, a lot more talking to end users and waaaaay more automated tests and automated releases and we might have something
Feedback from customers by iterating and releasing early and often.
Feedback from the team with proper frequent retrospectives.
Projects that I have been part of that skip or mangle retrospectives have all struggled. Listen to the team. Keep tweaking, improving every week/sprint. But keep the delta low so you can see what actually made an impact. And keep retrospective to mostly the team only so root causes are actually mentioned and not railroaded by external chiefs.
I find it slightly ironic that they (correctly) say they are no silver bullets, then suggest a silver bullet.
They're mostly places that look for a methodology-in-a-box type solutions.
Claiming a trademark is a threat of legal action against those hijacking the name to sell things in the same domain using the name without permission, which could be a potent way to prevent people from marketing things that are exactly the opposite from it calls for using its name the way it happened with Agile.
> People would go to one-day intensive GROWS courses, get certified and then just do waterfall anyway
Only if the owners of the trademark license GROWS certifications; if they are serious about preventing hijacking, they'll tightly control how the trademark is used and only use it on material (books, videos, potentially courses) consistent with the the intent of the system, and not for certification of people.
http://growsmethod.com/
I can't figure out what it is, though. Then again, I never figured out what agile is either.
It's been mentioned on here a lot that if you have a skilled set of programmers on your team you probably don't need Agile. They are self-managed and tend to do the Right Thing (TM) on their own.
I have seen Agile work and when it does it's pretty fun. Things move along, issues are dealt with, and nobody panics when things get behind a little. Just move it to the next release.
I think the problem is that The Consultants sold Agile to enterprise dev shops and they really ate it up. I don't feel Agile works from the top-down but rather organically from the bottom-up. In fact I believe that is true for most programming methodologies like this.
And Scrum. Don't get me started on Scrum.
This. Craft and passion beat any process. These people will organize themselves into the most efficient process eventually.
My direct experience of working with programmers over the years is that this will generally descend rapidly into an inefficient mess. Yes – maybe it works, sometimes. I'd argue that's the exception, rather than the rule.
If you work with people who dont care, youre screwed. Nothing will ever work to force them to actively engage with the process of creating good software.
..but, surprisingly, when you do work with people who do care, they self organize remarkably well. The Valve megacorporation is fundamentally based on this. It works. Thats been my personal experience, over the years.
The problem that has to be addressed is convincing people to care, and self improve.
Forcing a process on the unwilling is going to fail no matter what you do.
So where's my Half Life 3, dammit ;-)
I don't agree that people who do care necessarily self-organise well, or that this self-organisation is compatible with other business goals.
Sometimes it works, and a group of engineers et al. do a good job of forming a coherent team with minimal process. Valve's maybe an example – I don't know. My experience is that this is the exception, rather than the common case.
A good process can provide tools that help good people who care communicate and deliver more effectively. They help us to keep track of how we're performing and analyse pain points, and to make sure that there are methods for dealing with common problems.
For example, if my team felt that daily stand-ups were an inconvenience that weren't helpful, then we wouldn't do them. That's the goal; there's no cast-iron set of rules, just a generally applicable set of principles to follow.
Some people are self motivated and other needs their slap in the morning (for some, that's a couple of times daily).
Why is Valve a megacorporation vs. just a corporation?
Emphasis mine. You probably have more experience than I do, but largely I've seen it to be true that skilled (or, in the absence of skill, passionate) programmers tend to self-organize, as long as they all have the same goal (which hopefully is true for the majority of your team - if not, no methodology is going to help you).
Experience needed (read: got fucked before, now can avoid the treacherous waters and apply effort where and when meaningful).
Ability to deal with herding cats much needed as well.
Add relentless ability to move forward and not hold grudges.
All the companies I was at before this one that hid behind process had the usual problems with quality, scheduling, communication, etc. There's no process that's going to pull excellent work out of average people. It's just band-aids that keep people from taking real responsibility because they believe the Process will take care of things.
From my POV, a minimum amount of process is useful to keep things on the rails when the pressure goes on, so people don't end up doing things wrong. After all, unit tests, git and CI are 'process'...
We even are using one of the new open source libraries that tests and enforces the process, it is called 'poison ivy' - it hurts, like all good software engineering processes do!
Edit: do the downvoters disagree? We don't think there will be books, courses, tools for this new methodology?
I believe that is the crux of the issue. Larger organizations, and especially those that view IT as a cost center, do not feel comfortable giving control to programmers.
Every time a consultant proposes a new method with a new name, it seems like it's just a way to create a side industry; a long con that doesn't really attempt to fix the larger issue. I believe the hard problem to solve (which may be impossible, I'm not sure) is getting an organization to see their programmers as business collaborators rather than an inconvenient necessity.
In a corporate environment, you tend to have some burn outs, some 'holier-than-thou', some paycheck collectors, etc. The biggest difference probably is that you can't choose who you work with. It seems Agile as I've seen is implemented around that, which ultimately discourages the behaviors described in the prior paragraph. It becomes one writing quickly to finish things for the manager, rather than writing things for your coworkers.
"Any sufficiently complicated company w/o management contains an ad hoc, informally-specified, bug-ridden, slow implementation of management”--wycats
Being on the outside of the industry and reading about all of these acronyms of "how to succeed with great apes" ... it reminds me of being in middle school band. It smells like how first chair worked to get all of us clarinets to practice more and to try to out do each other performance-wise.
It works.
But eventually it changes from first chair to "first chair". And then it became, iirc, a lighting-rod for interpersonal problems amongst the single-reeds that became disruptive.
I suppose that I think of these schemes as MBA-encoded first chair politics. They work while the meta-game is immature. But as soon as players get to see the carrot for what it is ... it is all about a competition for who gets to hold the stick.
I've been political, I have been apolitical, I've been places where there were no politics. In the end, it's all the same.
Cargo-cult management practices freely adopted the brand facade without embracing or even understanding the underlying principles that must be present before the branded process elements can be good practice.
I don't care how good your process consultants are. They are not going to convince any manager to reduce his own importance within the organization. Just like it is much more difficult to make software secure by waiting until version 2.0 to add it, it is harder to make an organization agile by patching that in after the startup phase. It is far easier to be born agile than to reorganize into it.
The failure comes when trying to convince a clumsy organization, with plenty of vested interest in remaining that way, to become agile. What you end up with is a racing stripe painted onto their t-shirts and shiny plastic spoilers taped onto their asses, and no real improvement.
So in this context, GROWS will also fail. The only way to stop it from happening is by the developers pushing back hard against any more brand-name processes that are uncritically peddled to any organization flush enough to pay a process consultant. Screw your new snake oil, buddy. My org listens to me barely enough right now, and I don't need anyone messing that up with some new kind of pointless meeting.
I saw many companies using scrum and often I felt like this is a process for slower moving teams, instead of the opposite;
Great software is being written by great individuals that move it forward, pretty indecent of whatever process a company tries to use. To me a process must not get in the way or productivity and creativity.
Agile solves a conceptual issue which is it creates a more effective feedback loop that keeps everyone more informed than they used to be with classic waterfall models.
The problem though is that the financial reality isn't following the logic of the agile model and so whether you are trying to use the agile model for customer projects or internally in your organization you are still a child of the the overarching financial reality which dictates how companies are measured and budgets created.
Agile is great for innovation where there is no deadline and no limited budgets. It creates a false sense of effectiveness when it comes to projects with deadlines and budgets.
At the end of the day all it does is allow you to say earlier to those you have to deliver to that they aren't going to get everything they asked for at the same price as what they thought they were getting.
that rings very true with me. I'm nearing the end of a 3 year project where scrum was prescribed and followed, but the truth is we've basically shoehorned agile practices into a waterfall model because of business needs.
My experience with agile projects is probably far removed from how it should be implemented, but it still feels like it's fundamentally flawed to address business needs which rely on fixed scope and accurate estimates from the start of the project succeed (e.g. critical 3rd party tools being end-of-lifed, product mandates beyond company control, renewing client licenses based on feature completion).
I guess until something better comes along, I'm stuck with being told to do some strange type of scrumfall/water-gile.
I personally have a strong feeling that this article is just another attempt to monetize agile, by selling "agile failure". Agile is not failed for sure. Some people did.
Those problems appear because organizations are chaotic, in the mathematical sense, in that the sum of the details completely eclipses the worth of any idea. And that's an inherent problem.
The most extreme case I can think of was a "startup" I worked at that was VC'd to the gills, had an impressive board, with no traction, no revenue and about 25 engineers on staff. What they did was what I liked to call "product development by whim" where they had 5 product managers which each got to decide which features they wanted and the devs went and built it (we really really really needed a way for our non existent users to invite their friends via email, etc).
So if we needed evidence before development the whole house of cards would come falling down because the evidence would have shown no one wanted what we were selling, period.
To explain: where this sort of project management actually works is in a short-term, time-limited crisis that large companies might call a "Code Red" or (in the original meaning of the word) a Scrum. See my Quora post on the topic: http://www.quora.com/Why-do-some-developers-at-strong-compan...
When you're a small web consultancy that has landed a make-or-break project that (say) must be delivered inside of 4 weeks, and when you have absolutely no leverage and must accept any changes in scope as they come, Agile can work. You can reasonably expect people to set aside their long-term goals (career progress, tech debt reduction) and solve the problem at hand. Moreover, when you're a big company fighting a Code Red (meaning, money is being lost right now in large amounts) and have to assemble a cross-cutting do-nothing-else-for-now team with no clear manager, Scrum can actually make sense.
In a true sprint-- a short-term reorganization necessary to solve an immediate problem-- unsustainable effort is OK because, well, no one's going to be expected to sustain it. You're under a short term emergency. You can ignore whether the assigned work helps peoples' careers, because they're not going to be doing it for long. You can mandate that people work on the "official" top priority (of which there's only one) and most people will do so.
The problem is the perma-Scrum that's been sold (dishonestly) by the Agile industry. This stuff works for a few weeks and people don't mind doing it. In fact, even if the work itself is painful and the hours are bad and status updates are (by necessity) frequently demanded, being tapped for the "elite emergency team" is something that people generally like and, over a span of 2 to 6 weeks, it gets results. However, when you have permanent "sprinting" and frequent status meetings or impose these rules over the whole organization, it starts to hurt morale. It starts to feel less like being on an elite emergency team and more like a culture of permanent juniority/micromanagement... which is what Scrum/Agile has become in many organizations.
In perma-Scrum terminology, though, the end of one sprint leads straight into the next. This is the core problem with Agile/Scrum as it's sold: it takes behaviors that are known to be unsustainable and encourages people to carry them permanently, and then says they're not doing them right (No True Scrumsmen) if the arrangement deteriorates. It can't be sold truthfully, as a short-term fix that does a lot of damage if it stays in place for too long-- no one would buy it if it were advertised as something that only works for 6 weeks, max, out of a given year-- so the Agilemongers present it as a permanent arrangement.
It leads to a very confusing situation, where on the one hand the team is lauded for being the most productive team in the company, and on the other, for not working hard enough. o_0
If you can find anything in any Scrum publication that says otherwise then you can make the No True Scotsman claim, but otherwise you are at best misinformed.
Get your team GROWS™ certified today!
That said, I don't see the point of "methods", agile, waterfall or otherwise. When I worked building SaaS for school districts, we shipped roughly once a month, so I guess that was waterfall, but some ideas we iterated multiple times within that ship period until we liked one. Now I work with a set of e-commerce websites, and nothing front-end isn't AB tested (which slows down shipping anything), and new backend functionality is iterated almost daily. But I've never called these methods anything other than the right approach based on the situation.
The only model I've actually seen in a large organization is for the dev team to throw together a barely-working prototype, then spend the next 6 months fixing all its problems while the Marketing, Sales, and Customer Service departments train up on the new software. And they'll find a way to call this "agile", because otherwise the developers will revolt.
1. Bad companies and practices will not be magically fixed by applying 'Agile' or whatever other methodology you want. 2. When companies do agile development well, it is effective at solving some of the worst problems that software development faces.
Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology. I'll tell you what our process is.
- Spend a couple of hours planning a sprint of work. Two weeks, in our case. During that planning meeting, look at the backlog of features and tickets that the product manager has built up. Identify tasks we can reasonably accomplish in that time frame, ensure we have enough information to start, and discuss each one so we have a clear idea of what it involves.
- Make sure that those tasks are customer-visible features wherever possible. It's not always the case that this can be done, but it helps to provide feedback.
- 10-minute daily stand-up to discuss any issues and communicate who's working on what. Also time for the product manager to feed back any information from outside the team.
- Work on some tickets. Review the code. Pass them through QA. Deploy them. Let the product owner receive feedback from customers.
- Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.
That's the core of Scrum, and I don't see what's wrong with it. The problem arises when it's abused; story points as burndown charts, or productivity monitored in terms of 'number of tickets finished', or whole-company stand-ups, or whatever.
Agile development works well if you're agile. It's not a set of rules that must be followed – it's a set of guidelines that can help to improve the development process. If you are performing useless, time-consuming overhead tasks, then you are not doing Agile – end of story.
Where does professional development come in, my true Scotsman?
If you want to keep coding, you're expected to leave within two years.
You're right – Scrum is a process framework for developing software.
That is totally, absolutely, 100% orthogonal to professional development. I work in a mostly-Scrum environment as I described; that doesn't preclude research, or conference attendance, or any other form of professional development.
Bad culture is bad culture, regardless of development methodology.
Having a development process that does not produce senior engineers is a problem, even if you try to make up for it by providing a conference attendance budget and a Safari books membership. At the very least, such a process unfairly penalizes those with large personal time commitments.
Terminal juniority is an amazing term for that. Thanks.
Depends on what you are trying to do. Add some buttons and a new report feature to some 100K code base with 5 programmers? Sure, why not. Get changes in front of the customer quickly, backtrack or iterate, and so on.
Software for a medical device? Not so fast, bucko. Endless regulations (for good reasons), extended test cycles, changes require changes to hardware, long sales cycles, well, scrum is not your friend. Neither is waterfall, or whatever strawman someone wants to erect. I've worked hard projects (military hw/sw) and no well defined process gets you there. It comes back to the real core of agile, which the OP emphasizes - inspect and adapt.
2 week sprints (or any other number) makes no sense if you are held to an external release schedule (work for TV, sports? You are going to be releasing on that schedule, not your 2 week sprints, sorry). Do you have subcontractors? Scrum usually doesn't work there, especially if they are making hardware. Work in a truly 'requirements change' environment (TV, war, etc). Ya, sorry, not going to work to the end of the sprint no matter what, no requirements changes allowed. Conversely, is someone making hardware for you, or are you making hardware? Changing something could change delivery dates and costs by months to years. You can't just treat every 2 weeks as a new day (so to speak), changing things willy nilly. Want to build a search engine or a cloud infrastructure? Lots of planning required - you can't just add features every two weeks.
Scrum is a tool in the toolbox - if the problem you are trying to solve fits its assumptions it'll work fine. But it sticks it head in the sand about things that it considers hard. For the right domain that is brilliant - requirements are hard, let's get ideas in front of the customer sooner, because they don't know what they want anyway. Scrum says 'schedules are hard' and decides not to do schedules. Great if you don't actually need schedules, but if you need to deliver a hw/sw system for a business opening (say), well, you better be scheduling. And soft starts are not an option (as I said before, I used to work for the DoD, now I work for TV - you mostly can't soft start war or the Super Bowl). In military work every meeting is basically risk assessment - what are the risks I am facing, and you manage and mitigate from there. Risk is not in the vocabulary of scrum, and it is hard to think about things when you don't have a vocabulary for it. When I start something or work something I think in terms of 'goals, strategies, and tactics.' Ya, military again. But it works. Goals usually don't change, and you need to choose strategies and tactics to meet those goals. But people get wound around the axle 'we must do X' - well, not if X doesn't meet the goal. 'but X is agile'. I don't care, it's the wrong thing in this case. Scrum, as practiced, doesn't give us the vocabulary for that (the linked article does in the 'think and adapt' paradigm, but that is still a bit too loosey goosey for me). What are we trying to do (goals), how are we going to do it (strategies), and what are we doing today (tactics) is a pretty good, but imperfect way to organize your thoughts.
Scrum can work in places in those things, sometimes. Have a mobile app that is digesting and displaying the data of your system? Maybe/probably that can be scrum (maybe not if medical - regulations, extensive testing, and so on).
Brooks is still right - there is no silver bullet. There is no alternative except think, observe, pull the levers for which you have control, observe the feedback loop, adapt, and continue on. If you need a schedule, make one, and then adapt a risk control methodology to keep costs and other creeps in line.
Scrum is a system. Where else in engineering would we have 8 or 10 rules where we argue that wou...
Scrum is a system in the sense that it provides a framework upon which you can build a sensible process. Not every aspect works for every environment, and that's totally fine! It's the key principle of agile development.
I think what's happened is that so many places have completely ballsed-up the implementations of processes like Scrum, and that's given it a bad name. People naturally push back against that. I do find it a little frustrating that the two issues are conflated so often.
As an aside – at it's core, Scrum is just a process that breaks development work down into small, actionable parts. In most cases, that's an internal implementation issue, and is still compatible with meeting fixed external deadlines. Again, it's situation-dependent, but that's why it's advisable to avoid agile-by-numbers and implement the parts that work.
Scrum is a useful development methodology with some teams in some contexts, and is often a reasonable process starting point for team seeking to apply Agile principles in software development.
> Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.
This (without the "sprint" and "when its done" or the specification of the 1-hour timebox) is really the core of Agile: regularly evaluate the results you are getting applying your current methodology with your current team to your current set of challenges, determine what is working well and what isn't, and revise your processes accordingly to make them better.
If anything else is viewed as "core" and non-negotiable, your organization isn't Agile and, in regard to those particular areas, you are elevating process over results.
This. So much this.
Your process is one of the things you change. You hack it. You can try a change for one iteration and evaluate at the end of the iteration.
If you have a Defined Process(TM) - of whatever flavor - you're missing a big part of agile, perhaps even the most important part.
Let your process adapt to your people, your environment, your situation, your project, and your goals. Eliminate everything that isn't useful; shorten to the minimum everything that is useful.
Even if you started with Agile(TM) as defined by a Scrum Master(TM), but you're willing to change the process as you find out what doesn't work or is wasteful, you can still converge on something pretty good. You just have to keep tweaking the process, paying attention to what works and what doesn't.
Or to put it in XP terms: Pay attention to pain, not just in your technical areas but also in your processes and procedures.