There seems to be a lot of discussion these days about whether or not Agile still works, and whether or not Scrum in particular is “dead” or at the very least dying. The common thread that I see in these discussions is usually something to the effect of “why do we need set iterations” or “user stories suck as requirements documents” or comments in a similar vein about some fundamental part of the Scrum methodology. But, what many of these people forget — on both sides of the coin — is that if we are to truly embrace Scrum as an Agile methodology, it requires us to focus on one measure of success — actual, demonstrable results.
When “Bias Toward Action” Goes Wrong
If you’ve been on the job market in the past several years, you’ve undoubtedly come across the phrase “bias toward action” in one or more job descriptions or company overviews, or even during a call with a recruiter. It’s become something of a buzzword, and in the way that many buzzwords do, has a meaninglessness to it that often causes us to shrug it off as just another “thing that ‘they’ say”. The problem is that having an “bias toward action” can also be code for “completely unstructured” or “constant fire drills”, so rather than shrug it off we should dig deeper to uncover the real meaning behind the term for that particular organization.
Which is better – Kanban or Scrum?
A very common topic of discussion amongst Product Managers in general, and Agile practitioners in particular, involves the comparison of different forms of process and project management. By far the most prominent and popular of these are Kanban and Scrum. And, much to my own personal dismay, often these discussions wind up devolving into some form of “religious war” between fanatical fundamentalists on either side — insisting simply and without substance that their way is the best way.
The simple fact is that one is not necessarily better than the other — when, how, and where you use either of these approaches depends greatly on what problems you’re trying to solve, what kind of culture you have or want to have, and how the people you have doing the actual work want to manage themselves. To say, in broad strokes, that either Kanban or Scrum is objectively “better” than the other misses the point entirely. Both are equally good and equally bad, depending on the circumstances.
Scrum is Just a Starting Point
Awhile back, I got into a rather heated discussion with someone who was a firm believer in “textbook Scrum” and insisted that because the Product Owner is part of the Scrum Team (according to the biblical Scrum Guide) that they simply must be involved in every retrospective with the team, no matter what. This discussion reminded me of the trap that many people fall into when they shift from traditional, structured, waterfall or stage/gate approaches into Agile development practices — they assume that there’s one process to rule them all, one way to do things, and anyone who does anything different is a heretic and deserves to be burned at the stake for even suggesting that sometimes it might be better for the team as a whole if the Product Owner isn’t invited to a particular retrospective.
Now, don’t get me wrong — I think that Product Owners, in general, should be very involved with every aspect of their teams’ work — from stand-ups to demos to retros, and everything else in between. I think that the standard practice should be that the Product Owner is invited to the retrospective as an observer and occasional active participant. But I do not believe that anything in the Scrum Guide or any other alleged “definition” of the right way to do things should be followed to the detriment of the teams’ success and improvement.
Dogmatic application of any standard process is inherently anti-Agile, for the following reasons…
Examining the Twelve Principles of Agile
A lot of attention is paid (here, as well as elsewhere) on the “Agile Manifesto“, and while it’s an important component of the Agile way of thinking, it’s not the be-all, end-all statement that came out of the Snowbird conference around the turn of the century. Rather, there are twelve guiding principles in addition to the four core components of the manifesto. Let’s take a quick look at each of these, and see how they affect how we perceive and implement Agile practices…
- « Previous Page
- 1
- …
- 6
- 7
- 8
- 9
- 10
- 11
- Next Page »