This is the fourth (and possibly final!) installment of my series of posts discussing why Agile may not be working for you or your organization. Part One focused on the role of culture and training; Part Two focused on the importance of continual improvement and evangelism; and Part Three focused on lack of knowledge, lack of commitment, and lack of demonstrable progress as contributing factors. In this installment, we’re going to talk about what you can do when you encounter situations where Agile (or “agile”) approaches aren’t working — small things that you can do to influence and support the transition of your teams, organization, and culture.
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.
Why Isn’t Agile Working for Me? – Part 3
This is the third in a series of posts discussing the various reasons why Agile transitions tend to run into roadblocks or fail completely. In the first post, we looked at some fundamental considerations that often wind up causing problems for teams wanting to make the change to Agile practices. In the second, we discussed the importance of retrospectives and evangelism in the success of such transitions. Here, in this third post, we’re going to examine some things that many teams lack which may significantly affect their ability to implement, embrace, and succeed with Agile processes: Knowledge, Commitment, and Progress.
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…
Why Isn’t Agile Working for Me — Part 2
In the first part of this series, I focused on two of the primary causes for failure in the implementation and use of Agile methodologies — cultural failure and lack of training. While these are probably the primary things that cause issues with Agile processes, they’re far from the only things that can (and do) go wrong. In this second part of the series, we will explore the need for continual (or continuous) improvement and lack of evangelism and how they relate to the success or failure of an Agile methodology.
- « Previous Page
- 1
- …
- 3
- 4
- 5
- 6
- Next Page »