“A Scrum Master did a good job when his team no longer needs him”.
I hear various versions of this saying a lot.
It’s one of the most harmful Agile-related adages. We should kill it, bury it deep, and erase it from our collective memory.
Wait, but why!? Isn’t it true?
Continue reading “Do mature teams need Scrum Masters?”
It’s still so common in our industry to drop good practices in a crisis.
When things go well, we indulge in good practices. We pair program, unit test and pretend to be Agile. But when the project is over schedule or the financial results are bad at the end of the year, these practices go out of the window.
This begs a question: why we use them at all?
Continue reading “Do we believe in our practices?”
We’re quick to label people. One a bit too harsh review of your code, and you’ll see the reviewer as narrow-minded and ill-willed from now on. One unfortunate comment on a meeting and you’ll consider your colleague as adversarial and non-collaborative for years. One poorly written requirement and you’ll think of a stakeholder as inherently careless or stupid.
Such labels are hard to erase and lead to a poisonous atmosphere. But does it have to be this way? Why do we form these negative opinions? And, more important, how to avoid it?
Continue reading “How to stop labeling people: 6 ways to prevent the Fundamental Attribution Error”
Developers hate meetings. They seem such a time-waster. But there are a lot of meetings in Scrum. Way too many for some people’s taste.
Completely dropping Scrum ceremonies is out of the question. They are the main sources of communication and feedback that enable empiricism – the main advantage of Agile. But do we really need meetings for these ceremonies? Can’t we get the feedback continuously?
- Do we have to run daily scrums? We sit together in the same room. We can coordinate throughout the whole day, as needed, not only once a day in the morning.
- Why review our work with stakeholders only once a sprint, in a big batch? They’re sitting at the same office. We can make a review feature by feature, just as they are completed.
- Wouldn’t it be better to discuss improvement ideas immediately when one comes up, instead of waiting till the end of a sprint to make a formal meeting out of it?
- We’re doing continuous integration. Why do we need sprints at all? What’s the benefit of arbitrarily timeboxing our work?
I hear a lot of arguments in this vein. And they sound reasonable. Isn’t Agile, after all, about getting feedback as frequently as possible? Isn’t it in the spirit of XP to amplify good practices to the max? Why, then, Scrum ceremonies are so rigidly scheduled? Is it possible to break free from the tyranny of meetings? What are the risks?
Continue reading “Can we do Scrum without meetings?”
I was talking about remote work with my two colleagues recently. Our opinions on this topic lie on the opposite ends of the spectrum: I’m a big proponent of remote work while my colleagues strongly believe in co-located teams.
We have made a lot of typical arguments for and against remote work. As most of them are addressed in 37 Signals’ “Remote”, I’ve used this fantastic book to support many of my points. But then my colleagues argued that 37 Signals’ experience isn’t a good example because their situation is special. They’re famous for creating Rails, so they can attract a very different breed of developers – more motivated and self-driven than the ones working for a typical company, only to get a salary. The proof of this is that most big companies don’t allow remote work.
There are 3 underlying assumptions in this opinion:
- only especially driven developers can reliably work remotely
- only a few companies like 37 Signals can employ such developers
- big corporations should be your role models for new methodologies adoption
Are these assumptions true?
Continue reading “Is remote work only for the chosen few?”
Recently, Paul Wade’s “Convict Conditioning” went viral in our team. It’s a book about calisthenics (strength training using only body weight for resistance). Yep, we developers ain’t couch potatoes! But that’s not the point. What has struck me is how many similarities Paul’s philosophy shares with Agile. Let’s hear what “The Coach” has to say, because he can teach us Agilists a thing or two:
Continue reading “8 Agile lessons from “Convict Conditioning””
This is a copy of the post originally published on the eSKY IT blog.
How does our way of scaling Scrum at eSKY compare to Nexus, the new Scrum.org’s framework? This is the question we asked ourselves recently – and that I’ll try to answer in this post.
Continue reading “We have invented Nexus!”
Embracing change is at the heart of Scrum. The whole Agile philosophy is built around empirical, inspect and adapt approach. The Agile Manifesto contains statements like: “Responding to change over following a plan” or “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” It goes so deep, that we not only embrace change – we expect, or even desire it. We become suspicious of our process if the change doesn’t happen.
Yet, we want to have a well refined and ordered backlog. We want detailed user story acceptance criteria. We do a sprint planning and make a strong commitment of what goals we’ll achieve during the sprint. We even fight against changing these goals; the Scrum Guide states: “During the Sprint […] no changes are made that would endanger the Sprint Goal”.
Continue reading “Empiricism in Agile – embracing change AND planning”
Some time ago, I discussed why an MVP should be built iteratively. In this post, I’ll illustrate the benefits of such an approach on a concrete, step by step example.
Continue reading “Building the MVP iteratively – a practical example”
On the one hand, Agile is based around inspection and adaptation. It acknowledges that every company, product and team is unique, and that to achieve high efficiency we have to fine-tune our methodology to our particular context.
On the other hand, some Agile frameworks may seem very prescriptive at first. Scrum, for example, defines what meetings should be run, how often, what’s their maximum duration and so on.
Is it contradictory? How should we adopt Agile: by the book, or through experimentation?
Continue reading “How to implement Agile”