Being one of the people that participated in the creation of the Agile Manifesto, I find myself very disappointed by the reaction of engineers to the question “Are you practicing Agile?” Their shoulders drop. They start to slowly shake their heads. They mumble; they grumble. They tell me agile is horrible. I ask why. Reasons I head most often are:
- We’re being micromanaged
- The pressure is constantly on, these two-week delivery are too short
- All they care about is the date
- We only have time for cr**py code, we can’t do it right!
None of those management behaviors are part of Agile (read the Agile Manifesto and its related principles for yourself). Unfortunately, the dysfunction the authors of the Agile Manifesto were rebelling against are alive and well today in most places that claim to be Agile.
How do we find ourselves here? An all too common starting starting point is one of mistrust (note they above), where things are not going so well. Someone hears about agile and deliveries every two weeks. Sounds pretty good to a manager that is used to long lead times, delays, and defects. Someone is sent to two days of Scrum Master training to get the sprints started. Managers are updated everyday at the daily meeting; engineers no doubt get the idea they are micromanaged, and that they are the Scrum slaves.
I dig a little deeper, to understand “why do you feel micromanaged?” They say “We have to update the boss every morning instead of once a week.” “There is continuous pressure in these two week sprints!” “No time to document or to think”
GET UP, Time for another Sprint
Why is there so much pressure in the two week iterations? I don’t use the ‘S’ (sprint) word. It is a completely wrong metaphor. In sports, sprints don’t happen back to back. Sprinting leads to exhaustion. Sure there will be times when we sprint, but those sprints happen in the context of a marathon where you won’t finish if you do not have a sustainable pace.
Engineers tell me “The stories we are assigned are so huge there is no way to get the work done with any quality. We have to rush everything. The Product Owner says it’s priority one. We have to do what the PO says, right? No documentation; no thought; just do it! That’s Agile! Right?”
No, that’s not Agile; thought I agree that is a demoralizing way to work. As one manager told me when In the early days of coaching and training Extreme Programming “This all sounds great, but instead of being beat up once every six months now I get beat up every two weeks!” (His VP was definitely not quite on board with the realities and values of Agile, yet.) We had some more coaching to do it seems.
Too many supposedly Agile shops are missing a lot. They are not even doing plain old Scrum. If they were, programmers would be better off, for example by:
- Self-organizing teams manage themselves
- Choosing your work lets you follow your interest (sometime you have to take less desirable work)
- Committing to how much can be done in an iteration
- Updating each other in the stand up. (It’s not a manager update, though they participate.)
- Talking responsibility for design and other technical decisions (being professionals)
- Facilitate continuous improvement by doing meaningful retrospectives (being honest with yourself)
The motions of Scrum can help, but they are not enough. With Scrum, you change the cadence of delivery. Have you changed how you engineer your products? The practices of Extreme Programming are designed to help skilled engineers create software with a long useful life.
Managers, Scrum Master, POs does your engineering team use the technical practices of Extreme Programming to deliver high quality working software every iteration? Do you give them the resources and time to learn the skills they need to be successful in Agile?
Now it sounds like I am one of those anti-management types. I’m not. I spent a decade in management and leadership in a fortune 500 company. I know a bit about the job and can relate to the problems and pressures. The problem is not all in management.
Engineers, programmers, developers! We need to build trust. When we ask for three months to deliver, what happens after 2.5 months? We give the bad news that we’ll need an extra month. Bad news late is the worst kind of bad news. Your trust takes a hit. Then it happens again as you near the new deadline. Your reputation is weakened further. It looks like you are really busy now! You claim to be done and then the bugs start rolling in. You fix the bugs and unknowingly break previously working features your customer relies on. Your trust and reputation is in the trash.
Can we get out of this mess? If you got good at delivering meaningful valuable progress every iteration, delivering features that continue to work rather than randomly break as new changes are made, you can build a trusting relationship. Management will applaud you.
How do we do that? We’ve been trying to do that all along.
With Agile, the delivery cycle fundamentally changed. Have you changed how you develop software? As a senior developer, are you programming the same way you did that first year out of school? Do you have 10 years experience, repeating the cycle of code, test and fix that is too common in our industry? Have you read any books on iterative development, Test-Driven Development, Extreme Programming, or Design? Have you read any books on development at all? Are those crickets I am hearing? (you are reading this article, so probably you said yes).
The cadence of delivery is changed, so must your practices change. Kent Beck told me long ago (paraphrasing): “You’ll never be able to figure it all out up-front. You’ll never be able to stop changes even with a signed requirements document and contract defined penalties. Things will change. That’s the world. If you can’t beat ’em, join ’em. Get good at dealing with change.”
Agile 2016
As it turns out, Agile as practiced is dominated with management in 2016. Most the people that were involved with the Agile Manifesto were programmers, doing what they could to make the world better for programmers and the people that need programs.
Programmers, you have a professional responsibility to improve how you work. We (programmers) better get our act together; we’re just a few more software caused problems away from having the lawyers and government in our business. We better learn to be professional, or some lawyer or government bureaucrat will tell us what professional is. Agile might not be the whole answer, but it does advance the state of the art. It introduces the two week cycle and we can and should use that cycle for continuous improvement. Serious technical improvement, not lip service.
Managers, Scrum masters, and POs do you encourage your team to learn the technical practices of Agile? Do you even know what they are and why they are important? Here are two key areas you cannot afford to ignore if you want your team be more successful and make your customers happier:
These are only a start. But they are foundational.
Agile 2017?
That is up to you.
This article is based on my answer to a Quora question: In a nutshell, why do a lot of developers dislike Agile?
One thing made me hit the brakes as it were in this article.
“As it turns out, Agile as practiced is dominated with management in 2016.”
I wonder if this is springboard for another series of articles. And if you have written them kindly excuse my questions.
Why did this happen?
Who let this happen?
Are we who try to learn and espouse Clean Code, XP and the rest just not that as influential as we thought?
If so why?
If not how can we be?
Why have we failed?
My circle of friends (who seem to be more of a ‘Clean Code support group’) have all chewed our tails endlessly on these questions producing a lot of heat but no light….
We don’t want to give up – but man… we’re tired.
Thank you for writing.
Hi, thank you for this post I like agile because the best part in agile is the bad news that we got late in traditional approaches we can get that early according to sprint whip can be fixed easily but not in traditional method. useful information I will bookmark for future use
Hi, thank you for this post I agree with you that Engineers tell “The stories we are assigned are so huge there is no way to get the work done with any quality. We have to rush everything. The Product Owner says it’s priority one. very useful information
No true scotsman,huh? The truth is no matter how you try to apply the manifesto you reach the same crappy results because the manifesto is utopic. It ignores completely human nature. Maybe you should learn some basic psychology before XXXXX the life of milions of people.
Dear Cyp,
I am happy to post respectful comments from people that do not identify themselves. If you want to contribute disrespectful comments you’ll need to keep clean up the language a bit and identify yourself.
If by respectful you mean agreeing with you then I am sorru I cannot do that. You seem to have deleted every comment from programmers telling you the basic concepts of Agile Manifesto are completely wrong. When you cannot identify a big enough piece of vode as your own you do not care for it. It is a very well studied phenomenon that in groups of people no on will willingly take responsability for a thing if there is no reward in it. Also pandering to children like clients is demeaning and what Agile demands. I will not answer to the demands of one that deletes any comment saying he is wrong. I am just one of the 90+% programmers that say Agile is horrible. You can ignore people like me but the number of people that choose not to accept IT jobs where Agile is practiced are increasing. Soon we will be legion and you will be forced to listen.
I’m not looking for agreement. I’m looking for respectful discussions.
You say “You seem to have deleted every comment from programmers telling you the basic concepts of Agile Manifesto are completely wrong.”
I don’t approve replies from spammers. I don’t approve replies with the f-bomb in them. Disagreement without insult, that is what I mean by respectful.
Virtually everyone that comments on my blog does so as themselves. Why is a secret identity needed to voice your opinion?
I agree with your assessment that many programers think agile is horrible. So is over-cooked broccoli. It does not say anything about broccoli done well.
We could discuss specific objections and things you have seen. For example, where do you get “Also pandering to children like clients is demeaning and what Agile demands.”? Pandering is not part of the Agile Manifesto. Sounds like a local dysfunction.
I do not have a secret identity. The site demands I provide my credentials so you need just to check for them. Ciprian is my name. Not sure why it would matter but as I said I do not have a secret identity. The problem with Agile done right is that there is no right way to do Agile. And is not a local disfunction but a general one. Ok, let’s take the Agile manifesto line by line and show why is wrong:
1. Individuals and interactions over processes and tools
This translates into useless meetings and a lack of plan almost always. if you have a plan a blueprint of what you need to do, it can be done by anyone with the right qualifications, if not as in the case of Agile then only the original designer may understand what happens inside the cluster*** and many times not even him.
2. Working software over comprehensive documentation
Again the lack of documentation thing. Working software is a sign of progress only if you know from the start what the end product should be. Without documentation every time you need to make a change you need to talk to a dozen people just to make heads and tails of it.
3. Customer collaboration over contract negotiation
This is the worse line in the Agile Manifesto. The client cares only by end functionality and interfaces. He does not care or understand anything related to backend. And this means that almost always will ask for major changes late in the game and expect that you redo all the work in a couple of days and not ask for extra money. In the earlier models that work extremely well if a client asked for a major change late in the game it will be at a high cost of both time and money. now you are asked to make any change no matter how big on the fly without asking any more money. you are literally a slave.
Also clients are usually like this for two reasons:
a) they are usually non-technical or minimally technical but they think they know a lot about the software you are asked to develop
b) they look after their own interest which is to squeeze as much work for you for the money you are paying. And Agile gives them just that: the opportunity to treat developers as slaves.
4. Responding to change over following a plan
This type of thinking always but always produced bad quality products, regardless of are of work. It is the reason we have blueprints for houses and every electronic device we use. And if you still believe in this I will ask you: will you live in a house build on this principle? Would you trust it to withstand a mild earthquake or a mild rain? Because I would not.
What I found most annoying from Agilists is that when presented with all the problems of Agile they just say: “you are not doing it right” or “it is just a problem with your team” . Agilists always use the no true scottsman defence. It is never the fault of Agile but always the fault of the team.
PS: your example was involuntary a good one because there is no brocolly cooked well. Broccoli tastes bad to most people regardless on how is cooked.
Ciprian,
I used to hate broccoli! Now it is one of my favorites. Its both good for me and I like its taste.
I think we could discover that we agree on what not to do. What you call agile is not what I call agile. What I call agile is effective. What you call agile is not effective. What I call agile helps specific problems. What you call agile causes new problems to pile on top of the old problems. Me saying that does not mean that you are wrong about what object to. I object to the behaviors you describe too. I am against agile done wrong. I am for agile done right.
You managed to interpret and implement each point of the manifesto wrong. Who would be a proponent of what you suggest agile is? If you want to have a dialog I am open for that. (Also, I don’t like the f-bomb on my family oriented site. So I edited it out of your last post.)
The manifesto is vague. The authors wanted a statement of principles not a bunch of rules. I came to be part of agile through Extreme Programming. XP includes a set of engineering practices that help support incremental development.
Many agile adoptions are doing it wrong. They are doing agile in name only. Likely that happens because they are adopting some solution without really knowing what problem they are trying to solve. If you equate agile with Scrum where all that is done is the planning and meeting cycles, I’ll agree with you that it is a mess.
The cycle is supposed to be a continuous improvement cycle. The creators of Scrum knew about the practices of XP, but did not prescribe them. They figured a team that seriously wanted to improve would go to that next step.
For instance, the short cycles will reveal that there is a lot of manual retest needed and it is likely that defects are escaping to the customer. Many think chasing bugs is the norm in SW development, so they don’t look to solve that problem. If they will look a little deeper they will find others that have improved that situation through automated testing. Some will discover that automated test at the feature level is nearly impossible to hit all the edges. They might find TDD and use it to further improve their code and product.
You talk about programming as if there is a blueprint available. Usually there is not. The code is the blueprint. Take a look at this: http://www.developerdotstar.com/mag/articles/reeves_design_main.html. Have you ever known a software product that did not change? Design has to evolve with new functionality and old functionality must be preserved. Test automation, a core part of XP, is needed to keep a product young for a long and useful life.
If there were a blueprint, where does it come from? Is that a linear process or a iterative process? Having built and contributed to many systems since the late 70s I know the process is iterative. Having designed and built a house, as well as designed and built four basements, I know the design process is iterative, even though a blue print is eventually produced. Having that blueprint did not stop requirements changing. XP is about getting good at change.
In the 90s, I remember thinking like you: “if you have a plan a blueprint of what you need to do, it can be done by anyone with the right qualifications”. This thought was prevalent in the 1900s and 2000s. Many USA companies thought they could do design in the USA and email the designs to low cost programming countries and get good results. That did not turn out so well for many reasons. One of which is specifying SW is difficult. The number of details is immense. Some can only be discovered once you are deep into it. On top of that, once you do what the customer asked for, they are most likely going to say thanks, but what I really need is something a little different.
Regarding bullet point 2: “Again the lack of documentation thing”. The point does not say no documentation. You interpreted it as no documentation. At the time of the Manifesto, processes and documentation were growing. I worked with a very documentation oriented company in the 2000s. Why are we writing this document? Because the process document says so. IBM/Rational were growing great lists of prescribed documents. Maybe my project does not need them. Maybe yours does. One of the companies I work with has so much documentation that they rarely get to work on the code, the part that really adds value to the user of the system.
With the Manifest being vague, it requires thinking. What we wanted the reader to do was to make sure any documents were needed and were built with their cost and customer in mind. We also preferred, thought did not prescribe, automated documents. A requirements document can be written precisely enough to be test cases.
You totally missed the point of point 3.
Maybe you should go look at the Extreme programming Bill of Rights.
And again in point 4.
Points 3 and 4 are about change. Our thinking and experience was that requirements will change so we better get good at dealing with it. That means short feedback cycles, test automation, getting features in front of customers sooner. In short, getting good at incremental design.
Most the companies I see getting little from agile, are unaware of the technical practices that really help evolve a system to meet client needs and keep costs down. Engineers are downtrodden. Their reputations are damaged by late delivers with many defects. What if engineers could deliver valuable working software every two weeks that stays working until you change your mind on how the system should work? They would earn better reputations and likely have a less stressful work environment.
Maybe its time to try broccoli done right and agile done right.
What I call Agile is the real world agile. The moment you try to implement it is what you obtain. We do not live in a perfect world.
Xp and Lean have failed Agile is just an attempt to ressuect them.
The blueprint comes from the client . The client should know what they want.
The short cycles actually prevent from developing quality code because it does not give the developper enough time to see which solution is best and is forced to do quick and dirty implements.
It can be seen as an iterative process but each iteration is linear and should provide sufficient time.
The blueprint is the client requirements not the code.
Not sure why you believe things did not turn well for them. I can give you a ton of examples of good and efficient code written by that model but not one quality software written using xp and Agile. Blizzard are against Agile and make the most efficient code in games.
Documentation has to give guideliness . For details you can use comments and doxygem but you still need a documentation base.
Otherwise the code becomes impossible to debug.
Requirements may change but if there are big chages it produces instability. And short cycles make the code consisting from pieces that do not fit well with each other.
How can you deliver a consistent piece of code in two weeks? Is unrealistic. This remainds me of the joke that a pm believes 9 women can deliver a baby in one month. You have the same way of thinking.
My experiences are quite different than yours.
I am confident that there are more bad implementations of agile/XP than good. Its hard to do it right but worth it IMO. In the 80s we denied that incremental development was doable. I wish I knew then what I know now.
Oh, you asked me a question:
“How can you deliver a consistent piece of code in two weeks? ”
Have you ever heard of a walking skeleton? I would be surprised if games were not iteratively refined. I’ve worked with game companies that use the approach.
I’ll say it again. My experiences are quite different than yours.
By walking skeleton I suppose you mean the agile developpers.(joke). I know what you mean. But you still have to have a consistent base for it to work and not even then can you be sure it does. Yes I know plenty of such companies myself. They usually deliver games yearly or more often, the games have huge resource demands and are full of bugs. I am still waiting for an example of a piece of software developped with Agile that is a quality product. Also about foing it right argument if your medicine kills the pacient in 75 % of cases and works as it should just in 25% it is not a good medicine. Similar with Agile if a big majority of people using it find themselves wanting to quit programming rather than do Agile then the idea is bad. Also you said doing it right is worth it. You have not proved it or said for whom it is worth it. It may be worth it for the bussiness but not for the devs. After all drones and slaves are always a good bussiness.
You actually do not know what I mean. You continue to not know what I mean.
You said that you work for game companies that implement Agile. But are those games quality games or are the crap companies like Ubisoft, Gameloft,EA are producing yearly from some years now?
I can’t say that I fully understand your comment. I’ll comment for the part that I understood.
I worked with a very successful slot machine company. They had many critical regulatory and legal issues. Was it a crap company? No. A very high quality company, with a lot at stake for their games.
First off, ‘major props’ (hopefully just shy of the point of pandering 🙂 ). The Agile movement has done and continues to do a lot of good in the software development world – hell, in the world in general – and IMO none of the proponents – even those who have profited immensely from it – have profited from it nearly as much as they might have if their main goal was money, and certainly not as much as the Agile snake oil salesmen. If I had been in your position, I hope but I’m not certain that I would have acted as ethically.
For the poster Cyp, I have a thought experiment for you. I’m not asking you to believe that the following premise is true, I’m only asking: if the premise were in fact true, would it at least cause you to rethink some of your stance on Agile? And here’s the premise:
Part of the premise is that there are in fact projects that employ Agile with great success (remember, I’m not asking you to believe this, only asking you to consider if you would start to reconsider your stance, were you to find the premise to be true).
Another part of the premise (that I believe you’ll agree with) is that there are many projects that employ Agile and ‘fail’ or struggle.
Finally, the third part of the premise (and the crux of the thought experiment) is this: for any given Agile project, if one of the Agile signatories could disguise themselves and observe incognito (so as not to influence anything) in the project for its first ‘active two or three weeks’ (i.e. once it’s past inception meetings, etc.), they could predict how much the project would struggle if it were to continue its current practices, etc. They could also predict which practices on the project would need to change – and how – in order for the project to ‘succeed’ (i.e. struggle much less). And they could do this on project after project with an accuracy that – while not perfect, because nothing is – would astound just about anyone.
And remember, I’m not asking you to believe this premise, only to consider: if it were true, would you reconsider your stance on Agile?
Now that you’ve thought about that, I’ll tell you: there’s strong evidence that it’s true. First off, if you’re open to it, Google ‘successful Agile projects’ and read some of the links. You’ll find a good bit of ‘non-hype’ stats and examples that there are projects successful with Agile. And that’s success determined by objective criteria such as customer satisfaction, projects’ contributions to business’ bottom line, etc.
And if you ever were to research the writings, thinkings, etc. of the Agile signatories, and learn just a little bit about what these guys **actually write and say** about Agile practices, then looked at the practices of the ‘successful’ Agile projects/teams/companies versus the ‘unsuccessful’ or struggling ones, you would in fact start to see a pattern emerge: the projects/teams/companies that ‘struggle with Agile’ are failing to apply, or misapplying, some crucial pieces that the Agile signatories recommend. And they’re suffering from the consequences predicted by the Agile signatories.
As an Agile proponent and practitioner (since long before the Agile convocation i.e. a proponent and practitioner of the lightweight methodologies, etc. that preceded ‘Agile’), and one who has spent ‘lots of time in the trenches’, I promise you that I get where a lot of your vitriol comes from and, while I’ll admit it irritates and depresses me (that isn’t a slam against you, this is my problem not yours), I identify with it. And I absolutely promise you that a stance that at first blush seems like the ‘no true Scotsman’ fallacy can, in fact, have some objective criteria applied to it that explodes that objection. If you can ‘clear your palate’ of the bad taste left in your mouth from your bad experiences with ‘bad Agile’ and do some objective exploring, there’s a very good chance that you will discover ‘good Agile’, a joyful thing. I hope you decide to try that, and if so, I confidently await welcoming you into the world of Agile converts someday 🙂
P.S. In the post above, I said ‘proponents’ hadn’t profited when I meant ‘progenitors’ like the Agile signatories 🙂
1. The Agile “successes” are one of the following categories:
a) very simple applications and apps that are 90% interface
b) cases where the team succeeds despite Agile and not because of it
c) most often crap code is produced but it is still a success as the feedback from end users is completely ignored
2. Every google product released starting with the hummingbird search engine was utter crap so is not a good example
3. Please give me one example of quality software written with Agile and maybe I will consider it giving it a chance. But from games to anything else I only see crappy inconsistent software that consumes tons of resources promoted by Agilist and because the average user is more attracted by sparkling useless features they have some success.
4. Agile principles the moment you try to apply them in any form they fail because while good in theory in practice they go against logic, human nature and common sense.
5. How can I cleanup my palate from being treated as a thrall? That is what Agile promotes : treating developers as slaves while pretending to release them from the burdens of clear specs, a clear career path and so on. I am not that gullible. The attempt to reverse reality on me will not work. I have the sun glasses (“They Live” reference) and I can see the truth.
I’d recommend people who are thinking of introducing agile to their teams to be agile ie. introduce agile best practices one by one, step by step, with 2 weeks or 1 month iterations. At the end of each iteration if you see a good result you take it, it you don’t discard it or change it. If you like sprint planning you keep it, dump it if you don’t. If you like a scrum maste keep it. If you don’t feel the need of having a scrum master in the team, then you don’t need it.
After all every team is different, some work and some don’t. There is no magic bullet. If something didn’t work at your team why do you need to keep using it. It’s not agile.
I’m sorry, but Agile is nothing more than the latest bunch of buzzwords; just another satchel of weapons for MBA’s to use to blame engineers when things don’t go to their elaborate, arbitrary plans.
Features, Stories, Tasks, Epics… I’m sure I forgot some of the slew of made-up definitions that add nothing to the process.
Maybe the original concepts in your manifesto were noble, but the result, as it’s being implemented in the real world, is disenfranchised, burned out engineers with no control over what they work on, and a spotlight on their every move.
It replaces creativity and elegant design with “just crank out some code to get it out the door because the next sprint is already starting.”
Those short, endless “sprint” cycles contribute directly to micromanagement and a sweatshop environment.
Supposed to complete three [feature|story|task|whatever] but you only completed two? There’s no room for documenting what interfered with your work; it’s obvious you should have spent more time at your desk.
Gosh, why is it so hard to retain talent? We gave them a ping-pong table…
Add to that the unending administrative burden of running the whole process – now we need a “scrum master” on the team, where we didn’t before, just to make sure everyone’s nose is hard to the grindstone. That’s bloat and bureaucracy, just for the sake of making management feel like they’re squeezing every drop of productivity from those lazy developers.
I fricken HATE Agile. I know what you’re going to say: That’s not Agile. Well, it’s what passes for Agile most places I’ve seen it.
Nothing makes me feel more like I’m on a treadmill and nothing is used as often as a way to browbeat anyone who guesses wrong about how complicated a feature or bit research will take.
Is Agile dead? A guy can dream.
It is true, most places do not back up their agile with engineering practices and humane principles. This has been an evident problem for over a decade. It is easy to get wrong.
What will you do instead of Agile?
I am pretty sure the Agile name should go away. At its core it is iterative and incremental development. At the core there needs to be sound engineering. At the core there has to be respect for people and their efforts and time.
What would your alternative to Agile look like?
I’ve been lucky enough to land a remote development position with a company that trusts me to get things done as quickly as possible while providing a quality product. I could never go back to the corporate grinder unless there were absolutely no alternative. Unfortunately, Agile as practiced today has made the corporate world even more… corporate.
Awesome blog and discussion!
Mr. Grenning, much respect.
Cyp is spot on.
A few respectful comments/questions:
1) The intent of the principles is good.
2) However, a process (agile. scrum, etc.) that is so easy to be performed in the wrong way, is not a process at all. By this definition, scrum, agile is an art. Very few people can do art “right”.
3) What good is it to be a senior engineer in a scrum team? It is a democracy. Your opinion/vote/estimates are deemed worth the same as the guys who just came out of school. They mechanize the stories so that in theory anyone could do them, like if it was a factory and we, interchangeable assembly line workers.
3.1) Your responsabilty/impact is only limited to your current story. You go from myopic story to myopic story. As a senior engineer I find this very frustrating. I want and can handle a large responsability.
4) I look forward to the day agille/scrum fades away, like many other methodologies have. I will be trying to find a job where this abomination does not exist, but, these days that is almost impossible. Managers love exerting pressure on us every day with daily standups and related practices and they love it. It is a dread working like this.
5) We need to organize as engineers and exert pressure to accelerate the demise of agile/scrum from the workplace.
Thoughts?
“Your reputation is weakened further” – said a project manager to a programmer..
and I say: never trust a man who reasons what is best for you…. you should know it the best!
project managers’ goal is to deliver project as fast as possible, while keeping cost as low as possible. programmers goal is to take as little effort as possible and to satisfy basic project requirements. so, solution is not to push the programmer, but to push the project manager to make clear specifications and take responsibility for his work…
you don’t have to trust me. I have been working as developer and software project manager for last 20 years. I used to enjoy coding, now I prefer to manage. however.. I never tried to run away from my responsibility, and agile enables project manager exactly that..
Duncan, thanks for the post. Your opinion seems to be the popular opinion.
2) Agree.
3) Senior engineers that know their stuff will still lead. Scrum is democracy? Would a dictatorship be better :-)? In a healthy team, it’s neither of those even though some voting can happen. Interchangeable developers? to some extent. Broad range of skills and one or more deep/deeper skill, graph that looks a cave roof with stalactites. A bus number greater than one (how many people on the team have to be hit by a bus to put you out of business?) Teamwork/collaboration so you can get the best from the team. Two heads are better than one.
3.1) I do not recommend myopia. The team should be working toward a shared vision, with as much detail as your team needs to move the same direction. Call it a high level design if you like. I would expect a senior engineer to influence the vision and help the less experienced to learn.
4) I would not miss scrum. It has become the managers way to claim to be “agile”. There are three parts to agile as I see it and your post underlines a message I have been giving to the scrum community for almost a decade. There is way more to being agile than sprinting and having the scrum meetings.
The easiest part is what the world of scrum is doing. The hard parts are largely ignored: technical excellence and respect for people.
Adopting iterative management and planning, without investing in your people to learn iterative engineering and collaboration is a recipe for pain.
Regarding the best
I may be misunderstanding you. When you said “you should know it the best!” did you mean “you should know [delete: it] the best!” I’ll presume the later.
How did you come to know the best!? I don’t think there is “the best”, except the best given our current knowledge, skill and situation. If you think you already know the best and that is all there is, it might suppress your motivation to learn.
Regarding trust
My suggestion: don’t undervalue trust. It’s hard to get, and easy to loose. I’ve had a boss that did not trust me and an employee that did not trust me. It was much more fun and productive with all other bosses and employees.
Regarding Experience
I had 20 years of development, management and consulting experience when I bumped into Extreme Programming. I saw the possibilities it could make my work life better. For me it has helped greatly and resonated with problems we experienced for the first 20 years.
A lot of companies adopt agile in name only. They don’t really look at their organization’s problems and try to understand how agile might help. If you don’t know what problem you’re are trying to solve, you should expect poor results. The damaging word “sprint” makes people think it’s all about speed. It’s not.
It’s OK with me if you think Agile is a bad idea. I used to try to convince people about agile. I can’t. I can help people understand the problems that I think agile helps with. I can cast a shadow of a doubt on currently held beliefs. As far as convincing, you have to convince yourself.