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…
When the Chips Are Down, Our Values Show Through
There comes a time in every Product Manager’s life when they face adversity and challenges above and beyond the day-to-day administrivia that we struggle with every day. And it’s in these moments, at these times, that we find out what we really believe in, and what we’re really willing to do to stand our ground and push through the barriers before us. This is especially true in organizations going through a transition period — whether it’s growth, changes in ownership or management, or even shifting patterns from front-loaded development practices toward more agile approaches to product development. And it’s not only our values that come to the front when these things happen — it’s the organization’s values that stand out — often in stark contrast to the espoused positions that sound good when things are going smoothly.
What is it that drives these vast differences in behavior, and what can we do to bring the two closer together, especially in times of struggle?
- « Previous Page
- 1
- …
- 8
- 9
- 10
- 11
- 12
- …
- 18
- Next Page »