Another way of saying “results are not the point” is “do not trust your fortune to randomness.”
When you work remotely, you want to have some kind of a standup meeting regularly. In our team, after experimenting with many different approaches, we settled with text-based, asynchronous standups every day.
See, 2-5 years is about how long a not-really-Agile Agile team can survive before things shudder to a complete halt.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (May 23 to May 30). Topics include chronic stress, Parkinson's Law of Triviality, the importance of developers, adjustable standing desks and employee value.
It was late at night, when I stumbled on yet another Quora question concerning the topic of “Programmers not programming”. The topic itself always seemed ridiculous to me. What is a programmer if they can’t program?
I don’t know where the idea that Agile can be distilled down into one or two practices or principles comes from. Thinking this way is extremely harmful.
When working as an in-house developer you will have colleagues to bounce ideas off. If you have an idea, talking it over with someone can enhance it, or stop you making a less than optimal design decision. A SOHO Developer does not have this option.
In the quest to understand how the delivery teams feel about changes in delivery process, a simple tool called the “Safety Check” can be used to measure how empowered the team feels.
When you think scaling agile, think out, not up. You use small world networks, and when you say, “think out, not up,” it’s a very nice catch-phrase.
Everyone in the business of software development has had experience with wanting estimates, being asked for estimates, or both. That experience frames how they look at the issue. A considerable share of those experiences have been painful.
A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders, and to acquire a budget for the product. But creating an effective roadmap is not easy particularly in an agile context where changes occur frequently and unexpectedly.
I have no idea since when the word velocity found a new home in software development, it is nevertheless popular these days. However I am pretty sure that Mr. Isaac Newton would not be happy if you talk about motion without mentioning his laws.
Well it's true: too much coding can kill you, the real question is "what is the reason?" and the answer to that is; Chronic Stress.
Anyone you ask will says they are encouraging learning, and that theirs is a learning organization. But is that really true?
Would you rather be known as the person who does a lot of stuff that is almost right? Or the one who nails every deliverable?
If you want a vibrant and dynamic engineering culture, standing desks are a must. I view them as fundamental to a programming team as decent workstations and SSDs.
Critical decision-making meetings can easily run off the rails when many key stakeholders are present. Here are 7 ways to guarantee yours will fail.
Parkinson's Law says that "organizations give disproportionate weight to trivial issues." This statement later became known as Parkinson's Law of Triviality, or PLOT. Although Parkinson was referring to organizations as whole, over the years this problem has become a pervasive issue in software development.
Technology changes have moved developers, previously of little importance within the world of IT, to a central direction-setting role within companies.
I spoke with Dave West (Chief Product Officer at Tasktop, former analyst at Forrester Research, hyper-guru on all aspects of ALM), about all aspects of the software development lifecycle, with some emphasis on how good software engineering can shorten cycle times and avoid technical debt.
In early April I received a message from Ben, delivered to my Reddit account.
Firing brilliant jerks is the absolute worst thing to do for teamwork, or indeed the health of the company as a whole.
All managers want employees with excellent development and organizational skills, but when forming an Agile team, talent alone won’t cut it.
It can be an underlying reason individuals at the team level are resistant to an agile adoption. There are a number of ways to “solve” this problem.
Good testers have the wonderful skill of asking “What if I do this”? This thinking is different than “happy path” coding, where we “know” the answer. People with experience in TDD develop this skill as well.