6 ms·

Disagree. Language is not an immutable thing and is always evolving in its use to reflect the concepts of the people using it. I think capitalizing Agile as a

Disagree. Language is not an immutable thing and is always evolving in its use to reflect the concepts of the people using it. I think capitalizing Agile as a noun makes it a "thing" that we can refer to collectively and ultimately helps us communicate about the concepts that it entails. The unfortunate down-side is when a popular term is misused due to ignorance and misunderstanding by a large group of people - which will happen more prevalently as a word becomes popular. As someone who has had the pleasure of receiving Scrum coaching from Jeff Sutherland, I can say that there is a HUGE difference in understanding between people who spend time to learn it (from a book or coach) and those who muddle their way through - never taking the time to learn about it more deeply and put it to practical use (the only way to truly learn is through doing). I work at a small company and teach an internal course on the principles of Scrum to our project managers, so I have first-hand exposure here. It's amazing how really smart people who have heard the terms used for several years and even claim to have been involved in Scrum teams at past jobs still have many misconceptions about the core principles and how to practically apply them when the situation arises. There is definitely a shallow understanding amongst a good majority of developers and it's exacerbated by companies that claim to use "Agile" practices yet have only really scratched the surface. It's immediately clear that many have used "Scrum-but" and really only do standup meetings as if that will be all that is needed. Actually many people think Scrum is "that process where you hold standup meetings". I like Scrum because it brings together not only a way to manage a project, but more importantly a way to lead a team of people! I think being a servant leader to the team and providing them the necessary resources to be at their peak effectiveness is a trait of a good leader. It's actually kind of amazing all the different ways even very smart people can get "stuck" - distracted by a less important task that is shiny and interesting, slog through hours of debugging to resolve an issue that someone else on the team could have helped them with, not communicating with other team members that they can't get their part done unless another has provided them something first. From experience, just helping people identify these blockers and get the team unstuck has been a big win. I think tools absolutely are a big help too. I've used sticky notes on whiteboards and it's good for small teams that are co-located. It breaks down for distributed teams. We just started using JIRA and it is surprisingly good at helping us managing all of our work which would grow unwieldy using more primitive methods. I'm not sure how I feel about the agile manifesto. I guess it has its historic place as a reaction against the poor waterfall practices of the past and paved the way for new methods to emerge. Besides that, it seems a bit dated and hasn't served a useful practical purpose for me.

lifeisstillgood 13y ago
Thank you for a defence there. I do think the word "Agile" is getting over-loaded (I recently had an talk with some folks at the GDS and it went sideways when we did not realise we meant different things). So the manifesto is useful just as a common reference point. I am also glad someone else is saying "hey sticky notes and paper may not be so useful in a remote working world". Admittedly I do love the methodology he espouses What to do: Find out where you are Take a small step towards your goal Adjust your understanding based on what you learned Repeat How to do it: When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.
ctb_mg 13y ago
Agree completely on all points. I've also seen the large disconnect between people who say they practice Agile and those who have actually spent time to learn it. Regarding the Agile manifesto. It seems like it's a relic of the past and perhaps that's why it's not included directly in the Scrum Rulebook. I haven't gotten any practical use out of it, and it seems to only confuse people who do not take a minute to interpret the wording at more than a superficial level.
hibikir 13y ago
While it's true that many people do not really learn or understand scrum, I do not think that just getting a good trainer is the most common problem. There is something way worse, and harder to cure: You can't teach something to someone if their livelihood depends on them not knowing it. For instance, if you start with an departments whose sole job is build software, and they make scrum teams that happen to have 5 people that only know the business, 3 testsrs that don't know how to write code, a dba who is the only person who can change DB structures, and 4 developers who do not talk to users, there is NO WAY you can make scrum work without major amounts of turnover. 13 team members is too many for a scrum. Scrum members have to be able to play multiple roles, even if they are only excellent at one of them. Otherwise, the team is not self organizing, and can't adapt to much. Most large organizations around town that claim to do scrum follow that pattern, and the end result is that they are doing all the scrum ceremonies, but the teams are lumbering hulks of failure. I agree with the article: Agility is more important than the process, and people have to carry agility with them. If your team is full of specialist that can't claim ownership of the totality of the team's output, there is no agility.

lifeisstillgood 13y ago

Thank you for a defence there. I do think the word "Agile" is getting over-loaded (I recently had an talk with some folks at the GDS and it went sideways when we did not realise we meant different things). So the manifesto is useful just as a common reference point. I am also glad someone else is saying "hey sticky notes and paper may not be so useful in a remote working world". Admittedly I do love the methodology he espouses What to do: Find out where you are Take a small step towards your goal Adjust your understanding based on what you learned Repeat How to do it: When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.

ctb_mg 13y ago

Agree completely on all points. I've also seen the large disconnect between people who say they practice Agile and those who have actually spent time to learn it. Regarding the Agile manifesto. It seems like it's a relic of the past and perhaps that's why it's not included directly in the Scrum Rulebook. I haven't gotten any practical use out of it, and it seems to only confuse people who do not take a minute to interpret the wording at more than a superficial level.

hibikir 13y ago

While it's true that many people do not really learn or understand scrum, I do not think that just getting a good trainer is the most common problem. There is something way worse, and harder to cure: You can't teach something to someone if their livelihood depends on them not knowing it. For instance, if you start with an departments whose sole job is build software, and they make scrum teams that happen to have 5 people that only know the business, 3 testsrs that don't know how to write code, a dba who is the only person who can change DB structures, and 4 developers who do not talk to users, there is NO WAY you can make scrum work without major amounts of turnover. 13 team members is too many for a scrum. Scrum members have to be able to play multiple roles, even if they are only excellent at one of them. Otherwise, the team is not self organizing, and can't adapt to much. Most large organizations around town that claim to do scrum follow that pattern, and the end result is that they are doing all the scrum ceremonies, but the teams are lumbering hulks of failure. I agree with the article: Agility is more important than the process, and people have to carry agility with them. If your team is full of specialist that can't claim ownership of the totality of the team's output, there is no agility.