I feel point #1 (on the kind of people) is very important. That is why you always need a mix of methodologies/practices to manage Agile teams that are composed of differently ‘abled’ individuals. In point #6 (on ownership/accountability) I am not sure if you really need to distinguish/evaluate individual performance during reviews. Will your ‘true’ stars under perform if they aren’t distinguished ? Debatable.

Nice post.

I fully agree on the observation that Agile are not methodologies - they are frameworks of various kinds. Those frameworks provide the structure for the process, but the using organization needs to fill in the gaps (like the things mentioned in this article - risk management, budget etc. - but also with things like engineering practices that make sense in their domain). Some interpret this as lack of process, but it’s just lack of pre-defined choice. Agility requires a lot of discipline, more than the traditional approach, to be frank.

I don’t recognize the Agile spoken here in many regards with the way I understand Agile to be. For example, “the ScrumMaster (Scrum word for team leader) goes around the table and each team member mentions the status of tasks and other issues such as impediments or changes” is contrary to what I teach. SM _does_not_ go around the table. The SM is not responsible for the tasks of the individuals in any way - the team members themselves are. Therefore, in the Daily Scrum, the people themselves go through themselves (in a way they choose) and go through the three questions to share what’s important with the other team members. It’s not a meeting for the SM. If everything goes smoothly, the SM doesn’t have to do anything, and that’s a sign that the SM has done his/her job properly. And if something starts going wrong (or becoming less useful), for whatever reason, then the SM should help the team to fix it and get it working again.

I wouldn’t personally take this blog post as a guide to Agile transitions. It’s more like how to avoid the painful changes organizations would have to face and change if they were to really adopt Agile. And as such this is a great find - it lists many of the central pain points to tackle (in the long run, at least, if not immediately). And many of the suggestions are exactly what a traditionally minded person would suggest as ways to “fix Agile” in their environment. And which very likely lead to failed Agile transformation in the long run, as they’re not aligned with the key principles of Agile. Agile is definitely not easy, and this article underscores that point.

Yours Sincerely, Petri

I have now working on the implementation of agile methodologies and its impacts on business. My belief (which I intend to validate or not) is that most of the time, agile methodology implementation is “engineering” driven, not a strategic move decided at the top of the company. I have the feeling that agile methodologies solve some issues and create new ones. In most of the cases, I am not sure such methodologies lead to a competitive advantage because other functions will resist and, in the end, prevent the company to move toward a “more” agile organization.

Do you have any case I could study where the implementation of such methodologies went as far as leading to a complete reorganization of companies, redefinition of HR strategies and collaboration with other departments?

thank you

The Scrum Master is not even in ‘The Team’. In an Agile - Scrum environment there are three roles, The Team, Scrum Master, Product Owner. The Team consists of individuals all equal (albeit they may bring different skillsets developer, analysts etc.) to get the job done. The Scrum Master is someone who facilitates the process and insures that the team is really being ‘Agile’. They are also someone that is a team builder, but they are NOT the leader of the team. As apart of ‘The Team’ one person could be and probably should be elected as the lead to help deal with conflict etc. These are two different roles.

To me, Scrum has been chosen as a method which fits well with the Agile way of thinking. It’s obvious that Scrum cannot fit with all type of organizations, but it’s important to understand that each of them can find its part in this method.

When I read the Agile Manifesto, I find it’s all about:
- Reducing Waste
- Increasing Feedback
- Perceiving Integrity
- Increasing Knowledge
- Respect (people are in the center of the process)

I feel this is strongly aligned with the Lean way of thinking.

Agile Software Development is promoted by stars. They are hard worker and brilliant persons bringing the messages of a larger communities of software developers who want to set the standard for the Agile and Professional software developer. This standard requires a lot of works and disciplines from each individual developer, but when this level of skills is reached, the need for a strong methodology is less obvious.

If you want to win a football competition, will you choose in your team, anyone who is able to play with a ball, and then apply a method for winning? (I believed you’ll search for the artists)

Agile Software Development is limited, but in a way that it requires real competence for writing software, not only methodology on processes.

Thanks for pointing me to your article after reading the one on my journal. It’s clear that you have thought through the issues and limitations far beyond what I have and I commend you for that.

In my experience, adopting Agile has been an excuse to perpetuate a lack of process and accountability. The unspoken implication is “well, we don’t have any process right now, so why not do Agile, since it seems to dispense with process?” Wrong answer, of course.

To Mike Dwyer: I really think you have missed the point of this article. An Agile methodology does not in itself drive project success, just because it has some excellent techniques as you say. There are certain pre-requisites both organizationally and skill-set wise that are needed before Agile will be successful in a given company or team.

Too often Agile is sold as a panacea by starry-eyed practitioners; it’s like prescribing Aspirin for anything from a headache to a heart attack.

I am so glad you didnt write this years ago otherwise I would have been deprived of some of the most fulfilling and successful work I have ever been engaged in.
Not only do you misunderstand what this is about, you have a complete lack if knowledge as to the simplest and most powerful aspects of the approach.
To anyone reading this understand it is this mindset that limits what can be done.
Yes to the respondent, this is cultural in nature, but organizational in form,
No this is not a methodology. it is a way of getting things done. Not trying as the performance hooey spewed above is attempting to reward. DONE. teams get rewarded because they keep commitments on what they say they can do and what they do. That means, as I tell my clients, that you dont do what you say you cant do even when large shiny objects are dangled in front of you.
Agile is all about self respect coupled with self discipline and it is not about stars or prima donas or gurus. it is about a team of average people who join together to do extraordinary things exceptionally well over long periods of time.

Tom, indeed the title of the article could have been “agile prerequisites”. Limitations and prerequisites are but two sides of the same coin. Just mentioning limitations would not be very constructive. Therefore I proposed solutions to these limitations.

Note that ultimately any methodology could be used for any projects, provided you work hard enough to satisfy the “prerequisites”. Consequently, the question becomes: is it worthwhile, in your case, to enable agile in your organization? Let’s keep in mind that it doesn’t matter that you can race fast if it takes you years to drag the team to the start line.

If you can’t comply with the limitations of agile but still decide to use an agile method, you should definitely factor that into project costs and risks.

Dan comment’s highlights that the main barrier for agile is also the fuzziest one and probably the one that is the least discussed: culture. Indeed agile is first and foremost a mindset. And buy-in from management is a challenge because agile is still often perceived as little more than cowboy programming.

Bruno

This isn’t really about Agile’s limitations more the prerequisites that make it hard to achieve.

Having just done the Scrum Master training, when questions were raised, the trainer retorted that getting Scrum (I assume similar for other Agile approaches) to work is actually really hard. You need buy in from that management team, it’s a culture thing as much as anything else.

Where I am everyone seems to have taken it to heart and it seems that more departments outside of dev are changing to accommodate (which is cool). We’ve now got small teams of people with different job titles working together. We have a smaller geographical problem (different buildings same city), we’ll see how that pans out.

For us I feel that the culture is changing and becoming more vibrant and enthusiastic. It’s really to early to tell, we’re still all buzzed up.

Rock stars we’re not (well maybe on Guitar hero), maybe we have a few. Couldn’t I argue that Waterfall needs Rock stars to make it work also?

Team responsibility I think is important, it stops us from chucking stuff over the fence, especially if you’re now working with the people who used to be in the next silo. Individual accountability, where I’m judged by the team lead, that’s akin to saying “all are equal just some more than others”, I don’t think it fits with scrum, 360’s might work but I haven’t tried either I couldn’t say.