I found that no methodology works as well as getting the right people in and let them organise themselves. If you have the wrong people, it doesn't matter what methodology or process you bring in, you're screwed.
On that basis, methodology isn't that relevant.
I just watched a company apply SCRUM to apparently solve process problems and it just made things worse because the staff aren't disciplined or interested in what they do.
That's after five years of agile consultants and perpetual change.
If you want a manifesto with real values:
1. Fix shit when it goes wrong right away.
2. Tell people what you are doing.
3. Write everything down somewhere centrally that everyone can get to(tickets)
4. Have a rough vision and make sure people are working towards it. Don't plan the details too much.
5. Be opinionated. Someone's got to win an argument.
The point of that article is that you need to be self reflective and open to change.
I'll post it here again, without any of the other distracting things he said about verbs and so on. Just take a moment to think about what these steps actually mean:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
If you want to work as effectively as you can, you should actively change your process constantly based on reflecting on past performance against your goals.
...if you don't care, or can't be bothered, well, that's fine too (self reflection isn't easy); just realize that your own set of pedantic dogmatic rules is no better than any other Agile process set.
Spot on. This has been sort of an obsession of mine lately using the game of hangman and decision theory to "prove" why this works and how it applies to software development.
There are so many dogmas out there (Fail fast, MVP, Agile, Lean, etc) which all boil down to the same thing: Maximizing information gain and minimizing the cost of failure.
I'm planning on a blog post/email course/talk/something in the next few weeks but it's not quite ready yet.
This has been sort of an obsession of mine lately using the game of hangman and decision theory to "prove" why this works and how it applies to software development.
Oh come on, you can't tease us like that! You have a duty to satisfy our curiosity now. :)
How can hangman with decision theory apply to software development?
Well, I've started on a landing page for an email course. It's pretty rough around the edges, but I suppose I could take this opportunity to solicit feedback. ;)
I would also be thrilled to get my first signup. :)
If Scrum is applied well, all issues with the staff and the rest of the organisation will surface as blocking issues.
That's pretty much the #1 reason I find Scrum useful. It makes shit hurt. When introduced in a disfunctional organisation, it's basically a role-playing version of root cause analysis.
Of course, when implemented internally in a disfunctional organisation by people who are part of the problem, those issues will be swept under the rug and the problem will only get worse.
If an organisation doesn't want to change (including making the hard decision of firing the incompetent and undisciplined), not methodology will help.
And neither will your manifesto.
Yes, everything depends on having the right people and having them organise themselves (which is the very foundation of Scrum and most Agile methodologies). But in order to organise yourself it's helpful to use a clearly defined method instead of re-inventing the wheel.
Teams that fail with any Agile method are likely to fail at self-organising anyway.
No methodology solves the people problem, but some methods, particularly Scrum, are very good at identifying the exact nature of the people problem.
>> Of course, when implemented internally in a disfunctional organisation by people who are part of the problem, those issues will be swept under the rug and the problem will only get worse.
I think that's the point. Agile/Scrum is often just window dressing. If you have a good team then it will give you some nice things like frequent interim releases and a better idea of progress. But if you don't have staff who are interested, disciplined (and talented!) then you're screwed either way. And I've met a lot of staff who are not like this.
Frankly I'd rather that people had a mandatory five-year term in a disciplined team at one of the traditional, enterprise-class, quality focussed firms that demand good practice. I can work in whatever methodology you want, but that made me the software engineer I am today.
I spent a few years inside Big Blue. It moves very slowly but (IMHO) has world class people putting out well written, quality stuff.
It has its dark corners like anywhere else, I'm willing to concede it may just have been the teams I worked with that were awesome, it's certainly not cool, I wouldn't want to spend my whole career working for them and (frankly) god help you if you let one of their salesman in the building... But I learned a lot about doing things right. And now I'm a freelancer without the massive organisational overhead so I get to do things fast and right.
I dunno, maybe a large traditional corp isn't the only answer, but some way of enforcing good practice on people for a while, like a boot camp, so that they can take some of it with them to environments where it's not enforced as rigidly.
I think a lot of the federal contractors still have the legacy SDLC focus. Projects are huge with low margins and long timeframes. It's all about quality to keep the customer happy and not choosing the other guys.
"Development methodologies" are all about Process, as in the process to yield good results with ordinary people. For a team with good people that can self organize, processes stay in the way.
My general rule of thumb for considering somebody good (or great) is his/her ability to recognize / to be upset about problems / to care about usability or correctness of the implemented business logic ... and to roll up their sleeves and simply fix it, even without confirmation. If you have such people on the team, then the team can self-organize, if not, then prepare for sprints and meetings.
Actually I disagree. The large part (possibly not the intent) was about building a consulting empire around something utterly vague with multiple religious opinions about the best way to perform these manifesto actions.
The original meaning of agile, the manifesto, was doing it right. The consultants jumped on the bandwagon and called themselves agile until it stuck. But I don't think the right response is to say agile is now bad, it's to reclaim the word from those who're misusing it.
I don't think a missused word was ever reclaimed, in any language. But while you are on that path, can you do something about "hacker" too? (Or maybe you should start with the easier, less valuable "ordinary" and "literaly".)
> The original meaning of agile, the manifesto, was doing it right.
My impression of the original Agile project (C2), from reading their wiki, was that it was an attempt to make their customer feel really bad that they were incapable of lasting a week without changing the requirements.
Also, didn't the project fail? Though, in a way where it actually got partially deployed.
Yes. It doesn't deserve nicer terms. I've seen companies destroyed, careers destroyed and armies of consultants make off with people's livelihoods on a false promise.
For ref, I've migrated to the side of thing where I get pulled in (Harry Tuttle style) to sort companies out after they've been pillaged by these asshats.
The problem is that there are a lot of people who don't organize themselves, and need some sort of structure. So maybe they're not so suitable for agile development, and maybe you shouldn't hire them, but that really limits the labour pool, and in the end, someone is going to hire those people. We still need a way to make those people productive.
And they should be hired; they're often perfectly competent programmers, testers, etc, just not so good at working effectively with this kind of agility.
In Fowler's terms, the intent of the original Agile Manifesto was EnablingAttitude, but the result of the term "Agile" in many environments has been DirectingAttitude. It's a nasty cognitive dissonance - that "Agile" has in many places become a heavy, clumsy, tool-driven process that gets in the way of developers rather than helping them work efficiently.
And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. But process needs to be scaled to team size, talent, and risk tolerance. A broad-strokes "Agile" process that restricts competent teams is worse than useless.
And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects.
There's a surprising low upper limit on the size of a closed-source codebase before which it becomes a lead weight. Why? Because large projects (beyond about 6 devs in 2 years) without modularity generate a lot of maintenance work. (Modular design is to pay that maintenance cost upfront, which most executives don't like.) Maintenance needs to be done well, but the only thing that motivates good people to do it (instead of hopping to another team, changing jobs, or demanding a $500k+ salary) is either (a) caring about the module as a client, which means they typically aren't more than 25%-time maintainers because their main project is whatever uses the module, or (b) the possibility of gaining a national reputation in OSS.
The open-source ecosystem can motivate the kind of work that large codebases need. (That doesn't mean they never turn to crap. It means that it's not inexorable.) Corporate codebases don't have that.
Twitter hasn't open-sourced, for one example, Storm because they're nice guys (not to rag on them; this is one of a million examples I could use). That may be a factor, but the main reason is that they don't want it to turn to crap, and the open-source ecosystem is more robust against that than anything in the closed-source world. If you rely on something but it's not extremely proprietary, you should probably open source it for its own health. Proprietary stuff should probably be kept as data, not code.
That's why software organizations need to be modularized, just like code, so the small teams can work efficiently. But on the other hand, doing that just pushes complexity around. Instead of having a team chaos problem, you have an API and requirements chaos problem.
But on the other hand, doing that just pushes complexity around.
This. In my experience moving to small teams, service-oriented architecture, and semi-open allocation, the underlying problems of coordination were not solved. We had all sorts of issues coordinating API work and being blocked because one team's API was not performing up to par, but they were not fixing it because they had competing priorities. What ultimately helped get us moving again was getting a new engineering lead who had very good overall product judgement and could bang heads to get people on the same track.
If your app is intrinsically decoupled, then obviously small teams and SOA is a good idea. But if your app is inherently interconnected and requires coordination among complex pieces, then you are really choosing your poison either way.
Ultimately, I think the only proven solution for building high quality, complex software systems is to have Steve Jobs or another extremely talented and charismatic BDFL.
Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically".
I would say that when you are within a project team it should emphasize the agile values but once you are on an organizational level where several project teams need to co-operate to deliver a product the constraints given to teams should be formalized over the right hand side, strongly, but in a way that is ready to take immediate feedback from the realities. Preferably, my dream system would be formed of strong spec based contracts between teams, enforced by automatic tools and architects, who work as part of feature teams implementing features and have the ownership of the spec-framework and can swiftly change it to respond to changes.
Completely forgoing specs and plans leads to anarchy and headache where the only two-channel communication with developers is facilitated by broken unit tests and system-test or (the horror) customer side regressions.
Good software systems are composed through a firmly kept set of as strong constraints as possible, IMO, and someone needs to own the constraints.
> Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically".
For all the points in the Agile Manifesto, the right hand term isn't bad at all. It's a good and important thing, but the left hand term is even more important. Plans and processes (in a large organization) are definitely important, but they should never trump change and people. Documentation is also important, just not as important as working code. Contract negotiation is unavoidably important in any business environment, but don't let it get in the way of cooperation.
Yes. I think this is one of the most important and yet misunderstood aspects of agile. You aren't throwing out the right terms, just re-prioritizing them.
>> "Under 2.4, can we have more jobs in the jobstore and is the console more optimized?"
I agree with this. You create a plan so you have an idea when the project will finish, when resources will become free, when you deliver to other dependent teams etc. That doesn't mean the plan is cast in stone and once the Gantt Chart is finished, it never changes.
Obviously, you do what you can with scope, resource moving, etc to keep to original dates but if you can't, then the plan should be updated to reflect reality.
I think this hits the most interesting point. Personally I agree with the article that the best way to develop efficiently is to continually take small steps in the right direction and reevaluate where you are after each one - you save a lot of time by not planning things you don't need that way and it's much easier to maintain focus. But against that, people need estimates for how long projects will take and how much they will cost, and that demands a plan.
"you save a lot of time by not planning things you don't need that way"
Yes, but on the other hand you will lose time if you do not plan those things ahead of time that you can plan ahead of time. It's much cheaper to catch ill defined requirements while planning on paper than once the constraints reach production and people start implementing features and tests based on them. Although you cannot plan _everything_ there is always _something_ you can plan - and should plan. Unless you have a spec or a plan at day 0, you do not have a documentation platform available when the shit invariably does hit the fan and you need to do the learning-organization-disco and facilitate a change to your product because some real world constraints were not known or acknowledged before hand.
I am not sure I agree with that first point, having been involved in a short project, that just became one monstrous exercise in feature creep. That was essentially taking small steps in the right direction, but it never finished.
I think it is beneficial to have a plan in certain situations.
I think they worded it correctly. Notice it doesn't say, "Responding to Change over Making a Plan." Your version is horribly ugly. Theirs is succinct and poetic.
However, if you are not going to Follow a Plan, and while you're at it, you are attempting to Eliminate Waste as per the lean thinking movement, one may quickly follow with the conclusion that plans that are not followed are wasteful, and therefore unnecessary.
My experience has shown me that this is the interpretation people very often make. YMMV as always, though.
Preferring to Respond to Change over Follow a Plan doesn't mean you never follow the plan. It means that when changing circumstances conflict with your plan, then you respond to the change rather than blindly follow your plan.
I think what the Manifesto was targeting was "blindly" following a plan. In those days, reqs were drawn up, a design spec'd, a plan written out and there tended to be considerable resistance to changing the plan. That's what they were aiming at.
Well said. A friend of mine is another company are supposedly moving to "Agile". Their approach is to have whole day meetings to discuss how it will work! Three months later they're still planning how their Agile, Scrum based thing will work. The conferences, the consultancies, the big companies, etc. really have destroyed the essence of the Agile manifesto in many ways.
It's not that they've destroyed the essence of the manifesto, it's that the organization is simply inherently not agile, and incapable of dealing with agility. This is pretty common for large organizations (thought there are also a lot where it kind of works). Their real problem isn't so much the introduction of Scrum, it's changing the very nature and culture of their organization. They should focus on that first, and then Scrum will follow naturally.
That's why I like to make the distinction between little-a agile (the non-dogmatic vision of the original manifesto) and big-A Agile (rigid, sold as a product methodologies backed by expensive certifications).
> anyone who comes up with something bigger or more complex is just trying to sell you something.
I don't think being misled by snake oil salesmen is the only, or even the primary reason people get misdirected away from true agility toward 'agile'.
There are intrinsic motivations and interests in most human organizations which lead against actual agility.
A few of these include:
* The need for people in many positions to feel and be able to represent themselves as in control of the process and product;
* the desire to have someone else to blame when something goes wrong;
* the interest in shortcuts and magic bullets, instead of realizing how much work and time things will actually take (including from non-technical stakeholders).
There are social/organizational reasons that make true agility hard, especially in large organizations, especially in organizations where software dev/IT is just one component of a larger mission. But that doesn't change that actual agility is the only way to produce high-quality software efficiently. And we probably do need people investigating and suggesting how we overcome these barriers; but indeed, the 'agile' industry has not succeeded in doing so, they mostly take the easier path of figuring out how to cater to these barriers while calling it 'agile', instead of how to change organizational culture and surmount them.
Although it's a little off topic, I'm fascinated by how much time 2000s bloggers spent namedropping all the other bloggers (see paragraph 2).
When someone mentions your name all the time, they're trying to sell you something, but what did it mean to mention other people's names all the time? If they're selling the message that they're Spolsky's close personal friend, it's hardly working.
I guess it lets you steal their page views if you summarize their post…
I liked most of the generalizations in the blog post,I think that if he isn't 100% right, then at least he is really on to something.
The place I balked, is where he said that design patterns are almost dead. I find design pattersn to be invaluable, and so does at Apple Computer and with them millions of developers, so the death of design patterns is a bit premature.
I understand what he says, but from a grammar perspective, he's wrong. He complains that Agile, which started out as an adjective, has been turned into a noun. He wants it to be an adverb instead, so he introduces agility, which already is a noun. And then he says it's not a noun. (I'm sorry, but I just couldn't not point that out.)
But other than that, I agree. What should be making our work easier has been turned into something complex by itself. Though in a sense, maybe that's unavoidable. Not everybody truly groks agility, so they have to be taught, which means training and certification. Although personally I think if you don't innately understand it, you can't learn it in a workshop either. Maybe you need to discover it through experience, and I know people who never will.
So where does that leave us? Only the people who grok agility should work this way, and those who don't should stick to something else? What about the companies who want the hip new buzzword, but also want to have some handle on the process they're using?
An agile process like Scrum definitely fills a need, but I've also learned that Scrum in one place can be totally different from Scrum in another place. Nobody completely follows all the ideas of Scrum, but maybe that's as it should be: adapt what you do to what you need. And there may be a limit to the amount of agility some companies can deal with.
> I understand what he says, but from a grammar perspective, he's wrong. He complains that Agile, which started out as an adjective, has been turned into a noun. He wants it to be an adverb instead, so he introduces agility, which already is a noun. And then he says it's not a noun. (I'm sorry, but I just couldn't not point that out.)
Your knowledge of English programming is excellent, it is a rare and underrated skill. I can only recall one article on English coding posted on HN [0]. BTW love the double negative at the end.
> He complains that Agile, which started out as an adjective, has been turned into a noun.
The only programming languages I know of that use adjectives for their names are "Basic" and "Groovy". So this suggests when adjectives are used as nouns is a strong indicator of consultants flogging faulty processes and products for both development methodologies and programming languages alike.
The agile principles are fairly solid, as far as principles go. They're people-first and they downplay process and planning. You can't blindly follow a plan, process, or ideal. Think. Communicate. The right thing to do changes in every situation. You can't follow dogma.
But the idea that we should switch to a new word because the old one has been abused makes no sense. Why rally behind a word? Brands and labels only serve to stop people from thinking. They go against the whole idea.
Words become dogma. Hell, even principles become dogma. Trying to distill it down to something that's easy to digest robs it of its value.
The solution isn't a better dogma. It's people who can think. If you don't have the right people, no principle will save you.
You can't blindly follow a plan, process, or ideal
You can. The question that you might ask is whether the plan is good or not.
You can't follow dogma
As above. Dogma actually has its uses. The trick is knowing how, where and when to use it, or someone who is dogmatic. Machiavellian, but its a tool nonetheless.
Saying we don't need a plan is to thumb our nose at thousands of years of wisdom. Sun Tzu was not stupid when he suggested choosing a path only once the objective and environment are understood. Stephen Covey puts the same concept into modern terms when he suggests beginning with the end in mind.
And that brings us to the disconnect we live in. Developing something using agile practices does not require a plan. A plan is however required at a level above the developer to steer development. As you go, you'll find yourself becoming interested in that plan more and more. It's a natural shift because the plan reflects the strategy, development is purely tactical. Understanding the strategy is motivational - it answers the why. Development is all about the how.
Real value as a developer only comes from experience. An experienced developer is successful in spite of any methodology, approach or framework, not because of it. Something else we're really good at blinding ourselves to.
Experience has no price. It amuses me to no end that we as an industry place higher value on the 20-something hacker than we do on the 50-something veteran. We're unintentionally letting culture hobble our chances of success.
The author is quite defensive about the commercialisation around agile. I don't think this is warranted.
I'm a developer, but I have described myself as an agile consultant in the past.
This isn't out of cynically spotting an opportunity to make a buck. Its because I've spent a lot of time working in agile environments, learning the pitfalls and how to do it well, and want to share what I really and genuinely think is a better way to deliver software.
When vendors and consultants start to coallesce around an idea, it usually means that the idea is a good one that is gaining traction, coming down from the ivory tower. It's a positive thing and not something to leave the community that you founded over.
I've heard this argument many times over the years, and it always sticks in the throat a little. I'm evangelising an idea that I passionately believe in but am seen to be selling out the community ideals somehow. I walk the same line on my current venture in the DevOps space.
I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses. They were indeed trying to break out of that mindset and felt they were doing something revolutionary (which, in fact they were).
I worked on big government projects using military standards that more or less imposed the dreaded 'waterfall'.
What was our mantra? "Design a little, code a little, test a little".
Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man), argued for copious documentation. Documentation makes a lot of sense when trying to built a jet-liner, and is often a time and money sink if you are trying to write, say, research code for computer vision.
So, "revolutionary"? I dunno? Certainly many places had taken the deliberately flawed Royce model as the way to do things, and so there was a big change as far as that goes. But I can't recall a time where some form of iterative/evolutionary development method was not known about and practiced, or where decision making was favored over process.
To make this clearer - the Royce-ers patted themselves on the back, and then got hopelessly entangled with process. Yourdon came along. Wow, was that a great process - which everyone got entangled with. Then there was Booch..... And now, we have Agile. The details vary, to be sure, but the fundamentals remain the same. Some good ideas for approaching engineering a solution gets turned into conferences, endless books and training, independent consultants, certifications, requirements to be certified to win contracts, and on and on.
That's not waterfall as used in the conventional sense. A key element of waterfall was/is: "Thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified."[1]
>The details vary, to be sure, but the fundamentals remain the same.
I disagree. Agile is distincly different at a fundamental level from waterfall. If you walk into a modern shop doing mostly agile with continuous delivery, you'll find that there is almost no process at all that maps directly to waterfall. Literally, not a single one: not design, not coding, not testing, not building, not deploying. They're all fundamentally very different. Coding is probably the one that comes closest and if the site uses TDD or pair programming, it will be clear how drastically different even that is.
[1] https://en.wikipedia.org/wiki/Waterfall_model
People should stop using the term waterfall to describe any real process. It's only been used to describe a fictitious cartoon of a process, purely for the sake of their argument.
That wikipedia article is a bit of a mess, but read the article at footnote 7:
http://www.idinews.com/waterfall.html
"There's no such thing as the Waterfall Approach!
(and there never was)"
There may have been no capital-W Waterfall approach, but implying that projects weren't routinely being run in a waterfall-esque, staged-handoff fashion smacks of revisionism.
I was there. I was on those projects. They existed, and unless everything went perfectly according to plan, they were messes.
I never really understood this whole rage about agile and some people preaching it like a religion. You can't fit everyone in one frame, people are different. As the matter of fact the better the engineer the more quirks he will have. Some people like to jog, some like to sprint and rest, but if they cover the same distance and reach the finish in the same time, who cares what methodology they use? Even though I probably use quite a few agile ideas I don't call it agile or anything else, I call it development.
I always understood agile development as a way to organize your team and yourself in a way that works best for everyone. So don't follow a scheme, even if it's called agile, but think yourself.
Probably this is, how I WANT to understand it, because I don't like to follow rules that make me unproductive, even if others may become more productive by following the same rules.
Seriously. I like the focus on practical productivity but was surprised by the conclusion. "Let's all change from saying agile to saying agility" feels like quibbling over semantics. (Fixed spelling, thanks)
Yeah Agile is used as a way to make money now days. For what other reason there are Agile consultants, Agile agencies and Agile certification.
I firmly believe that Agile is about doing what makes sense in this team right now. You let the team to decide on their process, on their way of work and get away. And for good managers this is enough - you are empowering your team to succeed.
Recently I had a great success demolishing standups in our team. We clearly weren't getting enough value from them (I though they were plainly hurting us), so it was time for change. I had a great resistance from the management team, but some developers were keen to try a change (some of them were long enough in the industry to remember the pre-agile days, when we were delivering software too). So we tried it for some time, everybody loved it, and we stopped doing it completely.
Now days we all agree that iterative development is the way forward. We should also think if we can apply the same on a meta level - the team, the process, the product, the design, the organization. Do small steps, check if you are going into the right direction, repeat. It may work :)
What was it about your standups that were hurting your team?
I'm on the fence with daily standup meetings. they definitely can help a team communicate when there are a large number of external forces at play in a larger organization and if there are no underlying asynchronous communication channels available. on the other hand, in a team that communicates regularly with historical communications available to new team members, they aren't as useful.
- Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers.
- Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer. Most of the time the team members who come early suffer - they already started work, now you are forcing them to get out of context and attend a meeting.
- Sometimes standups are used as a way to force some team members to do what they have promised (the what I'll do today). But if you are using them in this way is really counterproductive - you either trust that your peers are doing their best for the team or you might consider team change (which I understand is beyond our control sometimes).
- Failure to communicate (or "the what problems I have/had" part). If your team members are mature enough and they had a problem during the course of the day, they shouldn't wait for the next day's standup to let everybody know about that. The should be proactive and seek resolution as the problem comes up.
- Finally the "what I did yesterday" part. This information is commonly used by the managers, but there are better ways to deliver it. Most of us use some way of tracking our work. We only need to flow this information to our managers. It is also a mind shift for them - instead somebody pushing this information to them, they should be proactive and seek it and pull it. If you don't know what somebody is working on, then go and ask him. You don't need to loose the time of the whole team for this.
That being said whether you will use standups or not depends largely on your team dynamics. In new teams or teams formed largely by junior developers it makes sense to have standups - its a way to force communication patterns and certainly can be used as a casual form of a team building. But in my opinion as the team matures there is less and less need for standups, so at one point it just becomes a hurdle. And the good thing about being agile (not SCRUM) is that you can evaluate your process and change it as you (and your team) see it fit.
I find it really hard to understand how a quick, 5 minute meeting every day can hurt a team.
> - Rarely the right information.
You were doing it wrong: standups are not to give or receive information, just to inform the team what did you do yesterday, what are you doing to day and any blockers.
> - Rarely at the right time.
We schedule them 15 minutes before the first team member goes out for lunch (10:45 am), this forces a hard deadline.
> - Failure to communicate.
You should communicate blockers to your SCRUMMASTER immediately, the daily meeting is to remind him/her the blocker is still there.
> - Finally the "what I did yesterday" part.... If you don't know what somebody is working on, then go and ask him.
This is so wrong in so many ways. The SCRUMMASTER's job is to keep management off developers back and play interference so they can focus on getting the job done.
A stakeholder should NEVER be invited to talk directly to developers about what they are working on. If they want a daily status, they can attend the daily standup where they cannot talk, just listen. If they have questions, ask the scrummaster after the meeting.
The daily standup is a tradeoff, as SCRUMMASTER you promise the team they will not get dragged to any other meeting during the iteration.
However I still thank the Agile "industry and business" as it allowed me to open my eyes as a developer years ago.
Because believe it or not, some of the so called master/consultant are genuinely caring about the values behind the manifesto, and putting a lot of efforts into improving everyone practice of software development.
Meanwhile, I'm watching helplessly from the sidelines as "DevOps" becomes the next "Agile", tasting bile in my mouth and wondering when a brilliant concept for reworking the culture-clash problem between developers and operations got reduced to a "knows how to use Chef/Puppet" for recruiters.
Funny how this post made me realize I've often been confronted with people wanting to implement 'agile' by imposing us to follow strict processes. I'd never seen it that way, even if the irony is pretty obvious.
You're right that good ideas like eco and also agile follow that growth curve. After a while the original idea and intention is partly lost on the way to economy and marketing. I observed that in the organic movement around 2000 as well. It is never totally lost, the impulse improved reality, but we need new ideas, new movements to hold spirit, values and ideas high. I don't know what you think about our impulse wholeheartedmanifesto.org which we started this February. Let's focus on the doing and on being authentic.. that's what counts. Thanks for your blog. Christine
Dave didn't seem to mind cashing the checks he got for all the "agile" books his company published. This piece would have been interesting in, say, 2008, but now he's just riding the wave.
From what I can see none of his own books are actually about "Agile". In fact "Agile development with Rails" is probably the only one that used that word in the title, and I can't really fault him for taking advantage.
Also he wrote some quite good books, 'Pragmatic Thinking and Learning' come to mind. I don't think your comment is particularly fair, nor does it diminish the point he is making in any way even if you're right.
"Pragmatic Thinking and Learning" was Andy Hunt, but as he and Dave Thomas are kind of a double act I can see why you'd get mixed up.
As to your point about whether they wrote any books on 'agile' I think it could be argued either way. More specifically, whether or not "The Pragmatic Programmer" (the book they made their name with) counts as a book about 'agile' is an interesting question, and one that throws some light on the wider debate.
Although they sometimes talk about "pragmatic programming" as if it were a thing, in the same way as XP and Scrum, their approach was more one of giving a smorgasbord of potentially useful techniques and practices rather than codifying a tightly defined set of best practices.
"Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, co-opted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand."
No not really. None of those are books he wrote himself. He runs a book publishing company. It's primary purpose is to publish books people want to buy. Though I'll agree that many of those authors capitalize on the exact things he is railing against in his post.
I once attended a meeting where a manager said "We won't be doing agile, but we will work with more agility", which basically translated to we won't be changing our existing process.
Agile to me is real: it has not been diluted as I know exactly how I will implement an agile process (scrum in my instance). I don't care if others misuse or misunderstand the term. For me it's concrete.
> "We won't be doing agile, but we will work with more agility"
At a previous client, I was sitting next to a really nice poster that emphasized the difference between "doing agile" and "being agile". You don't "do" agile. That's simply not a thing. You have to be agile.
Working with more agility is totally fine. But if you do that, it means you won't be sticking blindly to your existing process, it means you should consider what you actually need from that process.
> Of course, this involves a fair amount of thinking, and the basic loop is nested fractally inside itself many times as you focus on everything from variable naming to long-term delivery, but anyone who comes up with something bigger or more complex is just trying to sell you something.
Basically, the process is recursive, but my explanation is more agile.
I like the comments section in this article. The industry really isn't as bad as the writer thinks. Also the other comment that the word is bastardized but the values live on is so true.
Changing the name to agility is only going to make everyone follow suit and convert that into a marketing buzzword.
Language is not an immutable thing and is always evolving in its use to reflect the concepts of the people using it. I think capitalizing Agile as a noun makes it a "thing" that we can refer to collectively and ultimately helps us communicate about the concepts that it entails. The unfortunate down-side is when a popular term is misused due to ignorance and misunderstanding by a large group of people - which will happen more prevalently as a word becomes popular.
As someone who has had the pleasure of receiving Scrum coaching from Jeff Sutherland, I can say that there is a HUGE difference in understanding between people who spend time to learn it (from a book or coach) and those who muddle their way through - never taking the time to learn about it more deeply and put it to practical use (the only way to truly learn is through doing).
I work at a small company and teach an internal course on the principles of Scrum to our project managers, so I have first-hand exposure here. It's amazing how really smart people who have heard the terms used for several years and even claim to have been involved in Scrum teams at past jobs still have many misconceptions about the core principles and how to practically apply them when the situation arises. There is definitely a shallow understanding amongst a good majority of developers and it's exacerbated by companies that claim to use "Agile" practices yet have only really scratched the surface. It's immediately clear that many have used "Scrum-but" and really only do standup meetings as if that will be all that is needed. Actually many people think Scrum is "that process where you hold standup meetings".
I like Scrum because it brings together not only a way to manage a project, but more importantly a way to lead a team of people! I think being a servant leader to the team and providing them the necessary resources to be at their peak effectiveness is a trait of a good leader. It's actually kind of amazing all the different ways even very smart people can get "stuck" - distracted by a less important task that is shiny and interesting, slog through hours of debugging to resolve an issue that someone else on the team could have helped them with, not communicating with other team members that they can't get their part done unless another has provided them something first. From experience, just helping people identify these blockers and get the team unstuck has been a big win.
I think tools absolutely are a big help too. I've used sticky notes on whiteboards and it's good for small teams that are co-located. It breaks down for distributed teams. We just started using JIRA and it is surprisingly good at helping us managing all of our work which would grow unwieldy using more primitive methods.
I'm not sure how I feel about the agile manifesto. I guess it has its historic place as a reaction against the poor waterfall practices of the past and paved the way for new methods to emerge. Besides that, it seems a bit dated and hasn't served a useful practical purpose for me.
The problem with Scrum is it is rarely about principles and more about a process. Not that there is anything intrinsically wrong with that, but generally speaking, there are no one size fits all processes that will work for (or "fix") every business and team out there.
If it's really working for you and your team, that's great though. But there really isn't anything magic about Scrum. It's not the silver bullet many of it's proponents sell it as.
And not that I think this is worth anything, but I have learned it from a coach, I'm even a "certified Scrum Master (tm)", which again isn't worth anything, and I worked on a team where everyone was trained in Scrum, using a coach. It was arguably one of the least "Agile" teams I've worked on. Additionally, I've attended and even organized "Agile" conferences, both before and after working with that team.
I agree 100% with Dave.
If you like Scrum I think that's ok, I don't actually think it's a bad process, but in the hands of a mediocre team it's next to useless. However, in a lot of ways things like Scrum are anti-agile. Call it "Scrum" if you want to, but, and you're right, words do have meanings and "Agile" has been co-opted by these consultants for all the wrong reasons.
I wholly agree. Which is what I find so confusing about Agile "methodologies" and their ardent supporters. I'm not knocking the methodology (well I probably am) rather that they have little, if anything, to do with agile in the original sense.
I do think the word "Agile" is getting over-loaded (I recently had an talk with some folks at the GDS and it went sideways when we did not realise we meant different things). So the manifesto is useful just as a common reference point.
I am also glad someone else is saying "hey sticky notes and paper may not be so useful in a remote working world".
Admittedly I do love the methodology he espouses
What to do:
Find out where you are
Take a small step towards your goal
Adjust your understanding based on what you learned
Repeat
How to do it:
When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.
While it's true that many people do not really learn or understand scrum, I do not think that just getting a good trainer is the most common problem. There is something way worse, and harder to cure:
You can't teach something to someone if their livelihood depends on them not knowing it.
For instance, if you start with an departments whose sole job is build software, and they make scrum teams that happen to have 5 people that only know the business, 3 testsrs that don't know how to write code, a dba who is the only person who can change DB structures, and 4 developers who do not talk to users, there is NO WAY you can make scrum work without major amounts of turnover. 13 team members is too many for a scrum. Scrum members have to be able to play multiple roles, even if they are only excellent at one of them. Otherwise, the team is not self organizing, and can't adapt to much.
Most large organizations around town that claim to do scrum follow that pattern, and the end result is that they are doing all the scrum ceremonies, but the teams are lumbering hulks of failure.
I agree with the article: Agility is more important than the process, and people have to carry agility with them. If your team is full of specialist that can't claim ownership of the totality of the team's output, there is no agility.
Agree completely on all points. I've also seen the large disconnect between people who say they practice Agile and those who have actually spent time to learn it.
Regarding the Agile manifesto. It seems like it's a relic of the past and perhaps that's why it's not included directly in the Scrum Rulebook. I haven't gotten any practical use out of it, and it seems to only confuse people who do not take a minute to interpret the wording at more than a superficial level.
is it me or when an article is titled: "[something] is dead, long live [something]", you immediately want to flag it out of existence? seriously, comes up with a better title.
So much of "Agile" is an attempt to "patch" the top-down, closed-allocation organization that is simply incapable of hitting technical high notes no matter how much it spends or how many people it hires.
Since organizations are tough to change and all dysfunctions have champions (some deeply hidden) the "Agile" ends up having to make smaller and smaller motions while its desire for control, as the velocity in an irrotational vortex, gets stronger. Then it devolves into micromanagement, as discussed here: http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-a...
The reality is that the future just has no use for closed-allocation tech companies. Every tech company needs to decide either to play for real and try to excel (open allocation, highly selective hiring) or GTFO and do something else.
Scrum is a formational hack, but closed allocation is a foundational problem and, if technical excellence is needed, a show-stopper.
There are plenty of companies putting out bad software, slowly but profitably. They occupy various niches where the people doing the selective hiring or being hired selectively just aren't interested in playing. Sure, they could be out-competed by an agile, well-staffed, disruptive new competitor. They could be, but they probably won't be.
On that basis, methodology isn't that relevant.
I just watched a company apply SCRUM to apparently solve process problems and it just made things worse because the staff aren't disciplined or interested in what they do.
That's after five years of agile consultants and perpetual change.
If you want a manifesto with real values:
1. Fix shit when it goes wrong right away.
2. Tell people what you are doing.
3. Write everything down somewhere centrally that everyone can get to(tickets)
4. Have a rough vision and make sure people are working towards it. Don't plan the details too much.
5. Be opinionated. Someone's got to win an argument.
that's it.