In the end as long as the meetings you have are clear and focused and relevant to all parties then, for me, it doesn’t really matter if you are standing up or sitting down.
If there is one theme that is weaved through all of Agile’s principles and practices, it is feedback. TDD. Pair programming. Continuous delivery. Stories. Estimation. Reviews. Retrospectives. On-site customers. Feedback comes up against and again. Feedback from code, the team, and users.
A lot of people are cynical. Well, we tend to be pretty cynical as a culture. Whenever someone does something, we tend to sneer them and we tend to talk about why things can’t work.
Their message boils down to committing often, writing descriptive commit messages, making branching a logical process and making sure to have other eyes on your work.
There is a phenomenon common in many vehicular sports that occurs when the driver’s gaze is focused too near the front of the vehicle. With the field of vision narrowed, the pace at which the world around you moves seems to speed up.
As software developers we spend a large amount of time learning. There is always a new framework or technology to learn. It can seem impossible to keep up with everything when there is something new every day.
I hate “Agile” Initiatives because of the damage they usually cause. The problem is that when people start thinking that “Agile” is the goal they start to use “Agile” as a Whip or a Shield.
"So this post is kind of a tutorial for anyone that feels they could earn better money with less time spent working. I wish I read (or more importantly followed) these directions when I was still freelancing."
I once worked for a manager who thought everyone should bow down and kiss his feet.
As a senior person, I had a responsibility to speak up. As a team member, I had a responsibility to get our work done. I don’t know if I made the right choice in this instance.
Many people are now very savvy about how they use the internet to share knowledge, build up contacts, help solve a problem. This especially can apply to new recruits who choose your organisation to work for.
We have thankfully largely moved beyond the days when business execs believed that they could change their businesses on a shoestring budget through the introduction and viral adoption of free or very low-cost social collaboration tools.
To do a great job, product owners need a strong ScrumMaster at their side. This post explains the differences between the two roles, what product owners should expect from their ScrumMaster, and what the ScrumMasters are likely to expect from them.
As the title suggests the article looks at why project status reporting, specifically for IT projects, so often fails to alert companies of the problems in project work.
We’ve ... been experimenting with the idea that one size doesn’t need to fit all by running different styles of meetups aimed at different people.
I was talking to someone the other day. He said that given two Turing Complete programming languages, A and B, if you can write a program in A, you can write a similar program in B. Is that true? I suspect not.
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.