Many developers have been voicing their concerns about Agile being broken lately. Among them are prominent figures like Robert C. Martin and Kent Beck – two of the people who charted the Agile Manifesto. Some of the most frequently-mentioned problems with Agile are: Agile ignores technical debt; frameworks like Scrum are just “red tape,” which they were never supposed to be; programmers are asked to commit to arbitrary estimates and deadlines and never get the time to think thoroughly about the features they’re creating. So if we can acknowledge and work on these problems, perhaps we can fix Agile.

But here is the real challenge: How can we learn to recognize our own ignorance and misbeliefs? To begin with, imagine that you are part of a small group that needs to make a decision about some matter of importance. Behavioral scientists often recommend that small groups appoint someone to serve as a devil’s advocate—a person whose job is to question and criticize the group’s logic. While this approach can prolong group discussions, irritate the group, and be uncomfortable, the decisions that groups ultimately reach are usually more accurate and more solidly grounded than they otherwise would be.

For individuals, the trick is to be your own devil’s advocate: to think through how your favored conclusions might be misguided; to ask yourself how you might be wrong, or how things might turn out differently from what you expect. It helps to try practicing what the psychologist Charles Lord calls “considering the opposite.” To do this, I often imagine myself in a future in which I have turned out to be wrong in a decision, and then consider what the likeliest path was that led to my failure. And lastly: Seek advice. Other people may have their own misbeliefs, but a discussion can often be sufficient to rid a serious person of his or her most egregious misconceptions.

Interesting article written by David Dunning, of Dunning—Kruger effect fame.

When you are solving a difficult problem re-ask the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.

A good software architect, as well as a good project manager, doesn’t need meetings and never organizes them.

Meetings demotivate, waste time, burn money, and degrade quality. But more about that later. For now, let’s discuss a proposed alternative.

This is not to say that skill doesn’t matter — merely that in a competition in which all the leaders are highly skilled, randomness may explain the difference between triumph and failure. Good luck plus skill beats bad luck plus skill any time.

Standing out, rather than fitting in, could in fact be the smarter route to success. A phrase coined in a study published in the Journal of Consumer Research in 2014, the “red sneaker effect”, revealed we confer higher status and competence on mavericks versus conformists.

So we often perceive someone wearing clothing that deviates from the norm in professional settings as having higher ability, rank and respect than colleagues who conform to dress codes.

This is because diverging from the norm signals you have autonomy and can bear the cost of nonconformity – even if it costs you your job.

...

But she found that in collective cultures,such as East Asia and Latin America, people prefer norm followers as leaders, because they may prioritise organisational goals over their own.

I’ve never stepped into a leadership role without it quickly becoming clear why a new leader was needed. I think it’s normal for companies to hire new leaders when there are problems that need to be addressed. So I suspect that as the congratulations die down, it’s also normal to look at the set of problems that surround you and ask, “Where do I begin?” (also normal: “What have I done?!”). I suggest instead starting with these two questions:

  • How do I create clarity?
  • How do I create capacity?

In the year 1930, John Maynard Keynes predicted that, by century's end, technology would have advanced sufficiently that countries like Great Britain or the United States would have achieved a 15-hour work week. There's every reason to believe he was right. In technological terms, we are quite capable of this. And yet it didn't happen. Instead, technology has been marshaled, if anything, to figure out ways to make us all work more. In order to achieve this, jobs have had to be created that are, effectively, pointless. Huge swathes of people, in Europe and North America in particular, spend their entire working lives performing tasks they secretly believe do not really need to be performed. The moral and spiritual damage that comes from this situation is profound. It is a scar across our collective soul. Yet virtually no one talks about it.

A lot of evidence suggests that in cases of this kind, employers will stubbornly trust their intuitions — and are badly mistaken to do so. Specific aptitude tests turn out to be highly predictive of performance in sales, and general intelligence tests are almost as good. Interviews are far less useful at telling you who will succeed.

It’s a situation many of us are familiar with: a large legacy, monolithic application, limited or no tests, slow & manual release process, low velocity, no confidence… A lot of refactoring is required but management keeps pushing for new features. Now what? We talked to Michiel Rook, a Java/PHP/Scala contractor and consultant about the challenges that walk hand in hand with continuous deployment.

1–10 (73)   Next >   Last >|