It's been a while since I've heard an amazing episode of JavaScript Jabber podcast about agile development JSJ 349: Agile Development - The Technical Side with James Shore. The ideas from that episode are coming up again and again, not only in my mind but also in discussions with other developers about the software development process. I decided to summarize my key takeaways from that episode in this short blog post:
Scrum masters aren’t there to charge but to enable. Perhaps, they should be just a temporary role until the team is self-organized in the process.
Scrum certifications are unfortunately more about the business that has been built around it rather than bringing actual value.
Agile tends to be more focused on how to organize rather than how to do the actual work. We need to discuss the technical side of agile more.
Start with one particular method (XP recommended), but always be focused mainly on the basic ideas from Agile manifesto.
Agile manifesto values some things more than others, but it doesn’t mean that the other parts are not important or useful.
Software development is not a sprint, it’s a marathon. Try to imagine athletes to run one sprint after another. Don't count weekends as a pause between sprints. Look at The Six Week Cycle by Basecamp for an example of a different approach.
Agile is about shortening the feedback loop with a focus on delivering value to the customer according to values in Agile Manifesto. Keep it in mind whenever introducing some process or technique from any agile methodology.
Top comments (2)
"Software development is not a sprint, it’s a marathon." Amen Brother!
One question, why do due dates never move even when week after week the Impediments stay active?
I usually try to avoid any due dates, but I can imagine you can keep them unchanged as original estimates and measure how much they met or missed reality, analyze causes and improve upon it.