Detailed one pagers that talk about the work that should be done just before the commencement of cycle.
Whilst they don’t have “backlog items” in the traditional sense, Basecamp has pitches. Because delivering value is a non-negotiable tenant that they have. The book rightly calls out some of the benefits of having such a commitment or “deadline” - it makes teams conscious of the scope that they are taking in, and pushes them to consider cutting down scope to meet the fixed time that they have.Īn amplified imperative in the organisation for not just cutting scope, but aggressively doing so. An artificial time constraint, that requires a team to commit to delivering a piece of work within that time, that is of value. That’s exactly the purpose of defining a “sprint” period. The idea is the same - before starting any work, spending upfront time trying to remove uncertainty from the project, considering risk, and increasing confidence in the understanding of the work I don’t see any different than “refinement” or “grooming” of work. It gives a team enough runway to own and commit to a deliverable at the end. That said, it was great to read the thinking that went behind this standardisation of cycle time. Let me go through some examples that the book claims is unique about their in-house processes:Īlthough it is not common practice, nothing stops a team to define their sprints for a period of 6 weeks to get the benefits that the book is talking about.
However, they used their own terminology to describe them. After reading what they described, I think they described the principles and mindset behind agile frameworks with greater clarity and detail than many things I’ve read. Now - was Basecamp’s claim true? That they have come up with a unique software development methodology pure of the buzz of waterfall, agile and scrum? I don’t think so. That said, the book was successful in talking about how Basecamp works in a very accessible manner. I would have much preferred a fully developed set of ideas for the book to rank higher. However, it is also a key reason why I rated the book as I have (3/5) - it is predominantly based on anecdotal evidence. This was great because I was able to get the insights that I wanted quickly. The book was a very short and easy read (finished it in a day). Intrigued by this thought, I immediately picked up the book to understand how another company can have such success without utilising the prevalent agile principles that are ubiquitous in most tech companies today. I was originally recommended this book by a friend who made a note on how Basecamp is describing their software development process - that is not waterfall, agile or scrum - and how it works really well for them.
0 kommentar(er)
