Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have met a lot of people for whom Agile has worked really well, and most of them tend to be managers and architects who plan and delegate the work. However I really haven't found much good developers convinced that Agile is working for them.
Of course you can say if Agile isn't working for you, you aren't doing it right. But whatever remixes of Agile are out there, is it working for you as a Developer? And why? Does anyone else think, within a traditional (or close to) team structure, Agile feels more like a form of micromanagement than self-management?
At my first job, we had daily scrums, wrote automated tests, had automated builds, pair programmed, etc. We had been in the agile groove for several years. And for our efforts, we were rewarded with software that I wouldn't touch with 20ft pole. The quality of our product was atrocious: I'd describe as the piecemeal hacking of 100 amateur developers.
What went wrong:
The company I worked at had a notorious reputation for hiring entry-level developers for the lowest pay ($25-27K/yr was the norm), and frequently we'd outsource work to the lowest offshore bidder. I've heard that agile just doesn't work on inexperienced developers, and I think it showed through the code and our turnover rate.
No documentation of any sort. No functional documentation, no technical documentation, no requirements, no bug tracking. No one ever wrote things down on persistent media: all requirements and bugs were communicated by email, word of mouth, and psychic mindreading.
Lousy testing: our automated tests were invaluable, but QA and UAT testing was a disaster. Since we didn't have any formal requirements documentation, QA users didn't know what new functionality they were testing, so all QA consisted more or less of haphazard end-to-end testing. User acceptance testing was performed in production: we installed the product on our customers servers and reported bugs as they occurred in production.
Crisis-driven development: bugs were handled by using the "OMG WE HAVE TO FIX THIS AND REDEPLOY PRONTO! NOW NOW NOW! NO TIME FOR TESTING JUST FIX IT!" management methodology.
Although we did everything right and really adhered to agile principles by the book, the methodology failed harder than anything else I've ever seen.
In contrast, the company that I work for now uses a waterfall-like methodology, produces a few hundred pages of documentation for each project, has few automated tests but a sizable QA team. Interestingly, the quality of our product is through the roof, and the work environment is orders of magnitude above and beyond the other company.
I know many people have had the opposite experience. As is usually the case, methodologies are not a golden hammer --- you can probably start a successful project no matter what methodology you choose. In my experience on successful and unsuccessful projects, I get the feeling that methodology doesn't matter as much as environment: comfortable, happy developers and sane project managers are all it takes make a project work.
At my company, we made a wholesale switch to agile practices about 4 years ago when a new VP came in. This VP had experienced success with Agile in the past, and decided it was what we needed.
As it turns out, he was right. I was a developer at the time (albeit a somewhat junior one), and I loved the practices. Pair programming really aided knowledge transfer and prevented the formation of knowledge silos. Unit testing, test driven development, and test emphasis in general made for more robust code that wasn't over-engineered. No Big Design Up Front meant that instead of spending 6 months writing requirements documents (by which time the market had passed us by), we were prototyping and delivering real value to customers in a timely matter. Working closely with a customer surrogate (in our case, a technical product manager) greatly shortened cycle feedback time, which helped us deliver what the customer actually wanted.
Our organization had quite a few talented developers, but we were very prone to cowboy coding. A few developers didn't like the new practices ("What do you mean, write tests? I'm a developer!"), but generally everyone loved the changes. Defect rates went down, customer satisfaction rates went up, and our office became very well regarded in our company.
About a year ago I became a manager, and I heavily use Agile practices, incorporating some Lean principles as well (value stream analysis, waste elimination, kanban). Tightening up release cycles has been an ongoing activity, and my team now releases as often as possible (with quality!) - often every two weeks. We have no field reported defects from my team in the past year, and the sales people and product management love the shorter release cycles.
As a developer, Agile really increased my confidence in working with various areas of code (I now feel nervous whenever I'm changing anything in a package that DOESN'T have 100% unit test coverage!), taught me to be a more well-rounded programmer (thinking of test implications, business impacts, etc.), and helped me write simple, self-documenting code. As a manager, Agile and kanban gives me predictability, lower lead times, lower defect rates, and an empowered team. This is not theory, or speculation, or hand waving - our team morale, defect rate, customer satisfaction, and balance sheet have proven that Agile can do wonderful things for an organization.
To comment on the Principles of the Agile Manifesto from my experience at a site that tried it.
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
This was a double-edged sword for my last site -- valuable was taken to mean 100% perfect and bug-free.
Welcome changing requirements, even
late in development. Agile processes
harness change for the customer's
competitive advantage.
I still communicate with that site and just today, their rock-hard deadline date, they were given a requirement change. That was just the way things were there; it's almost as if they wanted failure.
Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference to the
shorter timescale.
The norm for many years was basically build and deploy daily, hourly, near real-time...
Business people and developers must
work together daily throughout the
project.
Some of the meetings/reviews with respect to this were hilarious. We were reprimanded for not working with the people (because they asked us not to because they were already working 9-10 hour days) and then for bothering them because they were busy.
Build projects around motivated
individuals. Give them the
environment and support they need,
and trust them to get the job done.
Ahh, here's our problem... We had top-of-the-line PCs but the business side wasn't supportive. The positive morale essentially got beaten out of you after about a year or so... This also negates your micromanagement concern (if implemented correctly).
The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation.
This worked out well. Personally I prefer email because I hate taking notes.
Working software is the primary
measure of progress.
No doubt here.
Agile processes promote sustainable
development. The sponsors,
developers, and users should be able
to maintain a constant pace
indefinitely.
I agree with this 100%; the problem with the last business team I worked with was the expectation of 30-hour days, 10-day weeks, and 400-day years was not a pace I agreed with.
Continuous attention to technical
excellence and good design enhances
agility.
This is where some developer morale & education was needed.
Simplicity--the art of maximizing the
amount of work not done--is
essential.
I love this one and it's long been one of my goals. However, there was a "if you're not typing, you're not working" attitude that was tough to overcome.
The best architectures, requirements,
and designs emerge from
self-organizing teams.
I agree with this about 90% -- my only caveat is that they must be well-educated and well-informed teams.
At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts its
behavior accordingly.
We just failed here and it likely caused a lot of other problems we had. The business side was really good at saying "you need to do what we say needs to be done."
To wrap it up, if you're working somewhere where everyone is informed and on board with an Agile methodology, it should be a great place to work. When the goal is great software, momentum alone will carry any project.
Agile has worked awesomely for me as a Developer in my current environment. Here are some practices and why it seems to work so well:
Pair programming - This prevents anyone from feeling an individual ownership of the code. Pairs of developers tend to make better code than one person's "mad science" code that seems to happen if one person writes a bunch of code in isolation. This also allows for someone else to be brought in if someone goes away and that feature or enhancement has to get done while the person is away. Sometimes, one developer may think something will be great but if no one else can understand the code, it is useless to have unless it is perfect and futureproof which isn't likely.
Scrum - This creates both an accountability and communication so that each person knows what the other is doing. If someone wants to know how the sprint is going, just show up at the stand up. The standup is really simple in that it is just 3 questions: What did I do yesterday, what I am doing today and what would prevent me from getting that done?
Test-driven development - A variation on this is practiced where I work in that we generally try to have tests for most of the plumbing code we are writing to customize a CMS in the big project we are doing. This mindset can be tricky to get into though it does get easier as one practices it more.
YAGNI - The "You Aren't Gonna Need It" principle that can really be hard if you've been a perceptive programmer that generally puts in 101 things as a "Well, I might need this someday..." mindset. Another way to put this is a "Keep It Simple, Stupid" idea.
Sprints - The idea here just seems to prevent a sense of being overwhelmed as we are just working for 2 weeks on this or that, and don't look too far forward as it may well change.
Demos - Showing off what we have done, getting feedback on what is good and what isn't is crucial for getting things better and having a mindset that we want "continuous improvement" in the project and what is good enough today, won't be good enough tomorrow and get better at what we do.
IPM, Retrospectives - The ability to look back at what was done in retrospectives is useful for venting frustrations, celebrating things working well and finding ways to address pain points. IPM is where we determine our future for the next sprint in terms of what will be the goals and how long do we think various things will take by using a couple of different estimation tools, one for points on "epics" as we call them and the other for hours on an individual task or card which is part of a story that is something between the epic and a small piece of work.
Storywall and user stories - Now this low tech tool since it is just a few whiteboards, with dividers and post its provides some structure to things. We have lanes for each of the epics and various columns for states of work: Backlog, in development, on dev, or on test. There are also places for the task backlog, blocked cards, questions, standards and practices and a few other things that may be useful for managers to see to get an overview on the current status if they want more of a bigger picture than what they would get at standup.
Broken windows/technical debt/tasks - These are similar in some respects and are useful as a way to illustrate that quality matters,i.e. we don't want broken windows that can be easily explained in non-technical terms by either using a house in a neighbourhood or the New York Subway sytem as starting points. Technical debt being something that doesn't immediately add business value that is sometimes an important thing to use to prevent some problems as there may be problems with a particular architecture and so part of a sprint may be spent doing a re-arch that has to be communicated so that if there is a sprint with little to demo this is why.
I don't know if the idea of a "self-organizing" or "self-managing" team is part of Agile, but it has been a bit of a challenge for me to have enough faith and trust in my co-workers that things will work out fine. The professionals that are the rest of my team know what has to be done, are reasonable, honest people with integrity to just get the work done and not be jerks about getting things done. There aren't egos or bad attitudes which really do help foster building a team.
Agile hasn't worked for me, the main reason being that the systems I usually develop need a well-defined and well-thought architecture, which is hardly realisable by an agile approach. Agile approaches tend to write as little code as necessary to pass the applicable tests, and thus to grow the system organically. This can be nice from many perspectives, but it wreaks havoc from the architectural viewpoint.
From my personal experience, Agile methodology tends to create a huge technical debt in the long term, and while it might save you (as a business owner/management) a couple of bucks short term, in the long term it will come back and bite you. Whatever you do not fix now will eventually cost you many hours of work to fix at a much higher cost than it would have cost you to invest some more hours into the original problem.
Agile is always great from the point of view of beginners and management, but I do not know one experienced programmer who actually loves it. The whole point of Agile is to save development money for a company, it has nothing to do with actual product quality. In fact most of the methodology promotes bad code done quick over well-engineered code. The difference is that a few years down the road, you have to do the whole work all over again whereas the well-engineered code can last decades without corrections. Good programmers do not need Agile methodology most of the time.
We have a business logic library written 22 years ago here by a single team of 3 programmers using waterfall methodology, and that code hasn't needed a single correction since. Because it was tought properly, was well-engineered, and the three programmers took their time and were careful with their implementation. Agile methodology would instead ask of those three to do the strict minimum to make sure some ill-defined tests passed, and then wait until the next time you hit a wall to add some more duct tape code. It's a ridiculous way to work and goes against every engineer fiber in my body.
To this day I refuse to work in an Agile environment, because frankly I do not need it, and I do not need an employer who thinks I do need it.
Agile is not a methodology, it is a subset of methodologies that have a common set of goals, and more often then not those methodologies have wildly varying results based on team makeup, corporate culture, and implementation.
Off the top of my head, purely developer agile practices would include pair programming, TDD, user stories over specs, the assumption that all code is going to be refactored several times (although this is part of TDD) and code reviews more then anything. Things that impact us are daily standups, being engaged with users regularly and directly, postmortem introspections, and very tight development cycles.
I'm a developer and a manager at the same time, so I either have special insight or my opinion is totally invalid. ;)
I will say that Agile means a lot of things. It's actually a whole family of methodologies and guidelines at this point.
Exposing yourself to all these interesting ideas is really the thing. As a manager, it's very hard for me to decree that a whole team suddenly adopt a whole methodology, but if they see me constantly trying to improve every aspect of my game, I think they appreciate that. And hopefully, if they like what they see, they follow my example.
I've managed to slowly implement a bunch of things from Scrum without (hopefully) coming off as a tool. Burn down reports, stand-up meetings, and story cards on the whiteboard have really made us better at shipping software. For instance, on any project tasks are constantly being done ahead of schedule or late. In a really big project, it can become very difficult to tell what that's doing to your ship date. With burn down reports, I can tell what a slip does to our ship date, and if we need to just start cutting features in order to meet a deadline.
That's more of a management thing, but the other devs here care about it because it might mean they get to keep their jobs or avoid a death march. :)
But it's not just management stuff. There's tons in Agile about best practices for source control, unit testing, etc. Just good solid best practices. As an industry, we are pretty terrible about mentoring, so it's good that this information is out there.
From the developers perspective I think it works well. In my point of view agile techniques have in common that the loop between defining the task, working on the task and getting feedback from that task is a very small one as compared to a non-agile approaches.
Take TDD as an example: Code the test, red bar, code the functionality, green bar, refactor, red bar, fix, green bar.
From the managers perspective this faster feedback loop is also true: Daily meeting one, status green, daily meeting two, status yellow, countermeasures / re-assign ressources, daily meeting three, status green.
Immediate feedback and knowing where you are heading gives a feeling of safety.
In the so called 'traditional team', Agile development would increase the visibility of individual developers to management. That would probably allow managers and architects to plan their work better. Ofcourse that could be interpreted as micromanagement.
But from an organizational perspective, if it produces results, who cares.
I guess what makes an "agile" project agile, is the methodology: "Design for today not for tomorrow".
For any not life-critical software systems this is a way to keep programmers coding in stead of discussing ages about design. Please note that design is not scrapped, it is just done in smaller and therefore more overseeable chunks.
All other techniques that are associated with agile, like pair programming, are more borrowed ideas that could also be used effectively in any other methodology.
Now, does this technique 'work'? Yes! If applied correctly, the technique promotes that the software product will be ready for shipping at any time to react to competition.
On the other hand, because programmers are feeling they are coding more, they are generally happier. And they are less irritated by writing specs because this phase is inherently always small.
But again, if you know exactly what your product is going to be and especially if it is life-critical like the space shuttle, agile development is not what you want.
Nearly every management is aware of "Agile" by now: It's this thing, you know? Alone by your initial question I would assume that something is really going wrong. I really recommend you reading a book like Practices of an Agile Developer (as the title suggests - it's about what's in for you).
Some managers read a book and then will know what agile is all about. They are telling you what to do and everything is fine, isn't it?
If you look around, there are a lot of developers (in Agile companies) who can't tell you within a second what the purpose of a stand-up is - and that's an issue. If you (and maybe even nobody else) don't know the why the StandUp won't make things better.
Take a look at time tracking (and time estimation) - there are some managers who think it's about measuring how much work you do: Hey, you have a 40h contract but the time tracking tool says that you have only be working for 38h this week! That's not how it was meant to be used.
The only thing you can do about that: you need to learn what agile methods are out there. Mediocre managers will pick the ones they find interesting. Good managers will grasp the why and not only choose the methods for their direct benefit - but also those which will make the team more happy / efficient / teamish (Team vs Workgroup).
P.S. Something you really need to take care of: In agile there is no place for slackers. Everybody has to do stuff on their own. You have to put personal interest into the success of the product. If you don't do things on your own, somebody will tell you what to do (and then there's micromanagement).
Has Agile really worked? "Yes."
Before there was "Agile Programming" there were equivalent largely unrecognized methodologies. I thought these were called incremental prototyping but apparently this has been split into that and evolutionary prototyping.
I suspect that many or most of the successful systems were so constructed. Just because the methodology grew a new name doesn't mean that it suddenly appeared.
It's just that Waterfall and other broken management techniques that got all the press.
I say Agile works.
I say it's the only thing that ever worked.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Our team is debating whether we want to become Agile or not. None of us are really fluent in Agile. I'd like some thoughts on when Agile works well, and when it doesn't.
To give a little background, we are a small group of developers, six in total. We have far more work that we can handle. Our priorities change often. What is a high priority today, may not be tomorrow. We have many applications to create and maintain. We have started to dabble in Agile practices to the extent that we have daily scrums and two-week Sprint cycles.
If you need more information to answer this, please feel free to ask.
Thanks.
Ralph Stacey's complexity matrix is commonly used to illustrate the sweet spot for Agile:
(source: typepad.com)
For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.
For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.
When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.
I'm speaking only from experience; YMMV.
My team was unsuccessful at making agile work. IMO, it was because:
The very first time the dev team
would hear about a project, it was in
the form of a requirements document
and a deadline.
Stakeholders were often reluctant
to take time to look at the result
of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
When we showed stakeholders our work,
they generally just OK'd it. They
would talk about what they would
like, to which we would reply "That
can be done in about X amount of
time," to which they would reply,
"Well no need to go over the deadline
for that."
The deployment process was long and
complicated, discouraging frequent
deployments. So in practice, we
often deployed things when a 2-month
project was done, not at the end of a
sprint.
Our sprint planning meetings were
long and inefficient.
It seems everyone was confused about what scrum is (and about what our process was), except for the scrum evangelists.
So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.
Some things that have sped us up, which we continue to use:
automated builds that work on
everyone's machine (HUGE help!)
a formal arrangement for our code
repository
learning how to apply apply
abstraction mechanisms to UI code
refactoring
unit and integration tests
continuous integration
I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.
(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)
Reposting a related answer of mine:
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)
It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.
Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.
I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).
Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.
Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.
Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.
In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.
Team must be stable and 100% dedicated to this.
Team must be colocated in one workspace.
Customer/product owner must be available on site at all times.
Support from management. This means providing funds and courage to ensure the points above.
Give these points, you can probably tackle anything as long as you keep to the values.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
As a developer who's never worked in Agile specifically (but have worked in TDD shops), I see employers that are running Agile shops resistant to hiring someone who hasn't worked in Agile. I've run into this a few times over the past few years. Is it really that fundamental of a philosophy change? After working in TDD, I can almost make an argument for not hiring someone who's never done TDD (when working in a heavy TDD environment). Perhaps I don't understand Agile and the difference between it and TDD.
I'd actually like to work in Agile, but this seems to be one of those times where you have to have the experience to get the experience. Sure, you can do it on your own, but that doesn't qualify if you ask me. As an employer, I wouldn't really call it applicable.
Agile is not an engineering philosophy in the strict sense - TDD, Peer Programming, etc are engineering practices that Agile uses - but rather Agile is a management methodology. As such, it's more important that someone be open to the mindset that Agile demands, rather than them actually having worked in an Agile shop before. Yes, it really is a different philosophy and approach to software development. People who expect everything up front and to be told what they need to do will be very out of place in an agile environment.
When I have interviewed people, I do ask whether they have any Agile experience or knowledge, but what I really look for are some of the following:
Flexible mindset
Confidence to allow self-empowerment (critical in any agile environment)
Ability to self-assign tasks
Communication skills (top 3 most important)
Ok with vague instructions, able to self-teach
Those are some of the qualities that I think qualify someone to work in an Agile environment.
Having an understanding of what Agile's core principles are is important to understanding Agile. TDD is just a small part of Agile and more specifically XP (Extreme Programming).
First I would take a look at the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Then I would take a look at the SCRUM process (which is also a small part of Agile) to see what's involved there.
When I interview developers I look to see that they have an understanding of Agile and what that entails so that I can then determine if the Agile enviroment/mentality is one what they would enjoy working in.
I've hired developers into agile teams quite a few times. I'm not at all resistant to hiring a developer with no prior agile experience - they'll be slightly cheaper ;-)
However there are questions that I would ask such a candidate and there are certain responses that set off alarm bells - letting me know that this person is going to be too much work to re-train.
For instance being precious about their code and designs - a sure sign they'll be a 'mare in scrums and code reviews.
Agile is an extreme democracy - everyone is equal, but that doesn't suit everyone. Some developers just seem happier in an autocracy (tell me what to do and how to do it), monarchy (layers of middle management) or bureaucracy (specs and development by rote) - those guys just don't work in agile.
Some developers are much happier with the agile ideas, and those guys can get hired whether they have have prior agile or not.
I wouldn't worry about not knowing all the process details - good developers read up and stay current on the technologies they use, not process methodology. Since every company tailors their agile model anyway (if they don't they're doing it wrong) it really doesn't matter which variant they started with. You should know some of the terminology, but that takes a day of reading up before the interview at most.
The brand of agile that we use is composed of Project Management Practices as defined by SCRUM and Engineering Practices as defined by XP. If we are starting a new team, we will look for key roles to serve as embedded coaches for the team (an Iteration Manager/ Scrum Master Coach, Analyst Coach, Technical Coach and Testing Coach). For an existing team, given that we use pairing, we are more interested in developers that work well with others than a super programmer.
Because we using pairing, a new developer will become productive within a month with the agile engineering practices as well as the business and application domains. It provides the team with little value if a strong programmer joins the team but is unable to pair effectively.
When we interview, we ask the candidates to pair with several team members. Through pairing, we learn if the developer works well with others in a pair. In addition, we gain insight into the developer's technical skills. Because the candidate works in several pairs, we get the perspective of a number of team members.
All of our agile teams have been very effective and their projects successful. We have trained more team members to become effective with agile than we have hired experienced agile personnel.
I think it is a typical case of over-insisting on a specific skill set. Like employers who don't want someone who knows JBoss when they use BEA for their application server.
A good employer will recognize if someone is adaptable to an agile method or not. Now if they have two otherwise equal candidates in front of them, perhaps that is a bit different.
It is certainly a handy way out of having to explain other reasons that may play a more important role in the decision.
Any company or opportunity that dictates SDLC by practice instead of best fit for the current project/situation is already showing signs of it's limitations and you are probably better served continuing your job search.
Absolutely YES
There's a lot of teamwork and trusting your peers in agile and specifically in extreme programming. You need to know other people are writing decent tests and not breaking your code. Good XP developers don't want people on the team that are going to make their job much harder.
Nothing wrong with being a beginner, or somebody new to a team - but there is an element of building trust just like you would to get committer rights in open source.
These days everybody says they are agile and if you offer enough money, practically everybody with the slightest tech skill will apply for the job... so expect people to put you through a pair-programming interview.
Typically we need to know:
Can you really pair program?
Do you really know how to do TDD?
Are you just saying these things or can you demonstrate you do them?
Are you going to take the initiative or are you waiting for an old-school "project manager"-type to tell you what to do?
Stuff that will help get you hired in an agile shop:
You have tried to introduce test-driven development somewhere even if you didn't get buy-in. (It worked for me...)
You have sample code you wrote - or an open source project on which you can demonstrate test-driven development, automated builds...
You find that you've worked in teams with short release cycles ...
In your current job, can you implement some form of Agile Developement to show you are interested, have looked into it and actually have some experience? You may be able to find some non-developers to work with you. A power-user could sit with you during some coding. I'm sure no one would get in the way of using some of the Agile documentation (sprint log, burn chart).
I'd likely put forth this question: What development methodologies have you been using up to this point in your career? Do any of them encompass the spirit of Agile's ideals?
If you are someone that loves to develop via Waterfall and think it is just absolutely perfect for your world of development, then going Agile would be like going from driving a car to flying a plane or a boat. It is that fundamental a difference as you aren't going to necessarily know where you are going and deal with changes very differently than a waterfall style where each stage goes in order and there isn't any reprioritizing without jeopardizing the whole process.
When a company uses the umbrella term "Agile" in recruiting without being more specific (e.g, by asking for XP or Scrum experience), it's often a placeholder for something else they're looking for. They may want "developers who will pair program" or "developers who won't dig in their heels about not having requirement and design documents before they get started" or "developers who won't go off into a dark corner for weeks on end". The trick is to figure out what they mean.
From a narrow Silicon Valley hiring perspective, a candidate who is familiar with Agile practices (e.g., knows what XP is), has done some of them (e.g., pair programming and TDD), and who wants to work in an Agile environment gets past that hurdle.
Employers most likely stick to hiring people who are knowledgeable of agile, rather than not, because agile methodologies require that almost every team member know about the processes required by each agile methodology (SCRUM, Crystal, XP). For example, SCRUM requires that all team members, including management, understand and follow the concept of self-organization. They’ll need to understand that they won’t be dictated on their current performance: They need to instead address their issues openly (or what typically happens at the daily SCRUM). If you put someone on the team who does not know agile, they may immediately assume that since this methodology has low documentation, they can run in and code-and-fix to build a project. However, agile methodologies are process-heavy, rather than documentation-heavy.
I understand your frustration but the truth is, if you never worked in an Agile environment you are very likely to behave in counter-agile ways (so to speak), and you will likely not even understand what is it that you are doing wrong.
Since Agile is so much about work philosophy it's not something you can learn merely by reading a book, you need to have intimate understanding of how non-Agile firms operate, what issues this causes, how Agile changes that, and how you to fight the entropy (the attempts of the external world to introduce the non-agility back in).
My advice is that you first read more about Agile and start analyzing your own behavior and behavior of whatever firm you currently working at from the Agility/non-Agility perspective. Once you're able to discern the patterns, you can start trying to change your firm from within. When you fail with that, go to an Agile company and they will hire you, I promise.
Maybe they take the mentality of the barkeep in the Mos Eisley cantina (paraphrased):
We don't want your kind here.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been reading about the various forms and aspects of agile development, but all focused on the corporate environment. I am on a student project team at my university, and I'd like to see if some agile concepts could work in an environment other than 'everyone works full/part time'.
We do have our own project server, with Subversion for version control, and Sharepoint for documents, wiki, and action items.
Some challenges
It's hard enough to arrange a weekly meeting, daily standups are infeasable
We're our own customers for the most part (we're part of a competition, but we can't work closely with the organizers)
Not just programmers, also mechanical/electrical team members
Sharepoint's action items don't have the best interface. Are there any extensions available? Would it make sense to switch to something else (like Trac) at the expense of a unified interface for everything non-svn?
Procrastination. As students, the most natural thing to do is wait to the last minute
We have our own space, but often, it's easier to do work elsewhere, and there's no way to predict if anyone else will be there except by making explicit arrangements
Other classes (still have to pass them, so total commitment to the team is limited)
Perhaps our team could benefit from more than just agile techniques, so all suggestions are welcome.
EDIT Thanks for all the great answers. I'm going to start asking my teammates how they feel about some of these ideas, and see what they buy into. Should I link them to this question? You can edit your answer or just leave a comment to answer this secondary question.
I wouldn't try to force a full, corporate environment style Agile programming workflow onto your team, but I do think that some level of Agile methodology could be valuable. I actually think that some of your "challenges" would be mitigated somewhat by some of the Agile ideas, but would require some level of commitment from every one on the team.
For example - the daily standups/weekly meetings issue.
This doesn't have to be a large thing (and, especially in a student project case, I'd say making it smaller is better). Having a Trac site (which I'd recommend over sharepoint if you're using SVN already) with a single place (like a wiki page) to just track the standup info in one sentence can still be valuable, without taking more than 1-2 minutes per day / person.
If somebody misses a day or two here and there, it's not a big deal, but if the team agrees to doing this, it can actually help the procrastination issue (forcing people to just say "I did nothing. I'm doing nothing" has a benefit - it keeps people at least thinking about your project, which tends to reduce the amount of procrastination), as well as having people work in different locations but still stay in communication.
This is also easy enough for non-programmers to do, and can help keep the mechanical and electrical teams working together, and everybody moving forward.
That being said, I'd make sure to keep it short and sweet - Try to keep the burden to a minimum, but I still think there's value in some of the Agile programming ideas, even in a student setting.
If you ask me you're adding too much overhead to your student project. Methodologies are generally only used in corporate environments because of the need to monitor and control human resources (control isn't the right word - but I needed one stronger than co-ordinate). In a group of students, there's absolutely no need to bother with anything like that. Adhering to a methodology will only slow you down.
You have identified your challenges. Make your peers aware of them and talk about how best to deal with them. Use methodologies as a source of ideas, but don't bend to one in your situation.
You can do a weekly or bi-weekly meeting that simulate a daily. Start your meeting with the three questions:
What did you accomplish since thelast time we met?
What do you plan to do until next time?
Is there anything blocking your progress?
Note that these can also be answered by your non-programmer teammate. In the company I work for, we have multidisciplinary team using scrum (programmer and artists) and it's working well.
If you don't want to do your meeting standing up, at least don't go for comfortable sofas. This should make your meeting shorter by making people more attentive.
You should use the method to your advantage and minimize procrastination by making interim milestones. Build your task list (excel, any other spreadsheet software is fine). Split them in milestone. When comes the time to review, sit with your team and look at your product like a client do, maybe involve your teacher.
Poker planning is fun, and a nice way to clarify your what you have to do, and how you plan on doing it. Breaking down objectives into tasks will involve people from all disciplines. But only people that can do the task should evaluate it.
IMO, SharePoint and agile don't really mix well. Pick something that's more "throw-it-up-there". I'd go with something like Trac, which has great Subversion integration.
It sounds like communication and procrastination is going to be your biggest challenge. If you don't give yourself enough time to do the work and do good testing, you're not going to have a good result. This is only logical, and doesn't really have anything to do with whether you're agile or not.
In your situation, not all of the Principles behind the Agile Manifesto will be easy to apply You might be able to apply some ideas that come from the principles, specifically:
short iterations at the end of which you always have a "working" project, even if some desired features have not been implemented yet.
maximize the amount of work not done - rather than designing a grand framework that you hope will cover all the needs of the project, start small and do just what is needed as you go.
If you have milestones during your project, consider having a meeting (called a retrospective) after each milestone just to look back and see how your process worked / didn't work and how you might improve it.
On the software parts, you could consider TDD and pair programming
I would say go with SCRUM. Skip the daily meetings and instead make a private forum and require each member to check it at least once a day. Try to make your sprint retrospective and planning meetings an "in-person" event over drinks or coffee.
The whole who is doing (and has done) aspect of SCRUM is amazing once everyone gets used to doing it. The 'sprint release' concept also helps team members from 'going dark' for too long and keeps the project based in reality ("What can we do in two weeks" vs. "I have this idea I am going to start and who knows when I can finish it").
Also, if your team has more then 8 people, skip SCRUM =)
Lastly, if you have the talent and someone on your team has the means (and desire), consider TFS workgroup (I think it comes free with academic MSDNs). If you don't have someone on your team who REALLY wants to take on that burden, skip it tho.
When I was in college, I took several courses that encouraged the adoption and use of Agile practices. They were mostly a mess and although I learned a lot of from them they generally weren't the things the professor was expecting us to learn. I do agile development professionally now and love it, but here are the things I wish that I had known when I was doing agile in school:
Getting things squared with your schedule is really, really hard, which makes daily standups more important, not less. If you can't sit in the same room (very hard) then use Twitter or Yammer or just email.
A lot of Agile's benefit is simply in getting you into a rhythm. That doesn't just mean weekly meetings; it means set goals, commitment to points, and weekly deliverables. This is tough to pull off in an academic context but should go a way towards helping you with your procrastination problem.
It's tough to get used to pairing; everyone has their own computer and style of development. Try to hook a second keyboard/monitor/mouse up to your existing laptops if possible, or use screen sharing software, and standardize on an IDE. Pairing also really, really helps with procrastination but trying to do it without good tools is an awful lot of trouble.
Don't skimp on unit testing, even if you think of it as a silly, academic, one-off project. I've done projects before that I figured were too small to bother with testing and it's never failed to come back and bite me on the ass.
Sharepoint might be a bit heavyweight. Believe it or not, we still do an awful lot of things on whiteboards or with index cards. You may be your own customer but that doesn't mean you can't have stories (discrete, estimable features, basically) and goals. It's helpful to be able to visualize it: these features are planned, these are in development, these are ready for testing. If you'd like software recommendations I can give you those but I do recommend simple paper for a lot of the planning process.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
For those of you who have implemented Scrum in your organizations, what were your biggest obstacles and if you did overcome them, how?
Background: In 2006 I contracted with a large company which had adopted Scrum cold turkey just months before I arrived. The company hoped Agile/Scrum would save their huge enterprise software product. Of the hundred or more programmers there, I worked closely with a team of about a dozen for a year, observing and participating in their Agile experiment.
Summary: I believe Agile helped more than it hurt. By the end of the year, the team could consistently estimate and produce features, whereas previously their productivity was rather erratic.
Implementation: Since this was a large organization and a large product, the project ran as a "scrum of scrums." There was one scrum master for about every 15-20 developers and these teams were often divided into smaller, closely working scrums of about 6-8 people for an iteration. Teams were largely independent, could adjust their own iteration frequency (1 month down to 1 week) and were given lots of flexibility to implement agile as they saw best. The company regularly brought in Agile coaches (such as Object Mentor) to help train the scrum masters, teams, and management.
Obstacles: Plenty. Some of them related to Agile, some not. In no particular order, here are some lessons learned:
The product backlog was revised way too often in the beginning. Eventually, the team and management took several days to go over all the features, estimate them, and prioritize them. It was a big hit, but it helped tremendously. Lesson learned: get your product backlog in order early and keep it maintained. Product owners must have a clear idea of what they want.
We lost time experimenting and dealing with fads and hype. When you start, you have no way of knowing if you're doing things correctly. There's temptation to constantly fiddle with the agile process taking the focus away from the product. Lesson learned: having an experienced Agile coach does help reduce this learning curve. There should always be someone pushing back on any experimentation. Limit the number of "spikes".
A good scrum master is invaluable. Certainly in the beginning, it's a full-time position.
It takes time. It took several months before the team started to be comfortable with the process.
Pick your battles. Some programmers will be understandably skeptical and others will outright dislike and flight the change. Allow for some flexibility. For example, enforce the use of a product backlog and iteration schedule, but don't require everyone use note cards. Be particularly sensitive to introducing tools and programming methodologies such as pair programming or test first development.
Finally, keep communication open and manage expectations.
Good luck!
While working as a Delphi developer a few years ago, I managed to get Scrum adopted by my development team for a time.
The whole process worked very well for us - having the team estimate prioritized tasks on a backlog gave us meaningful timeframes to target, and the whole "Managements job is to remove impediments" was great.
The biggest problem was that the process was always perceived - and referred to - as "Bevan's good idea".
While the team appreciated the value we gained, and were happy to continue with Scrum, the Team didn't take the scrum methodology on board as their own. After a while, I got tired of "pushing" and we "fell out" of following the Scrum approach.
Lesson: Make sure the team takes Scrum on board and owns the approach.
We do mostly scrum projects at the customer site. Hardest part in my experience is finding a good product owner in the customer organization:
Too many people think they should be the product owner,
The product owner has a hard time following the pace of the team
Product owner has a hard time getting all the detailed information the team needs
Moving items down the product backlog to add something with a higher priority is difficult
etc.
Training internal teams to use scrums is doable, bringing in your own scrum master is doable, but a good product owner should be part of the client organization. It's harder to train this external person.
Having a proxy product owner, who works together with the customer product owner does help a lot.
I moved from a company that adopted Agile to the tee to another company which follows the traditional methodologies.
Perhaps the biggest difference I have seen is that the second company struggles to prioritize. There is so much work on each person's plate that they fail to deliver on time. IMO, Agile brings about some transparency to the situation and lets the team as a whole prioritize.
A scrum master in the Agile world would take care of fire-fighting and be the voice of the (sprint) team. In fact, in the first company (where we had a separate scrum master and program manager), the scrum master would fight it out with the program manager when the latter makes false promises to the management. Meaning, the scrum master knows how much a team can produce/deliver after a few sprints, which helps her nail down on the predictability of a team.
I also noticed that the R&D resources have a sense of accomplishment at the end of each cycle, and are looking forward to the next one. But then, a good project manager could get this done in traditional scenarios as well.
The biggest issue, as already stated, that I too have experienced is the lack of buy in. It is very difficult to get people to truly become vested in the process.
The other issue, which is also one that directly contributes to the above issue, and also in a large part one of the founding causes of Agile is the lack of management to stick to the outlines of the manifesto of Agile.
In Scrum, Lean, or whatever version of Agile you are working with one cannot break from the manifesto points. If a process is being used to break away from those priorities then most likely the management is screwing up and the buy in will fall apart. The manifesto MUST be followed:
Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Some scenarios might be when a gantt chart appears from one of the above processes for whatever reason. Gantt charts can be useful, but if all of a sudden a developer is reviewing a gantt chart with management, the last point is broken. Responding to change has slowed because encouragement of the plan is being favored over change. Instead a board with stickies should be used, simplify what is on the board with only the current working items and back burner items. This makes changes easy. Once anything is solidified in a "tool" it slows responding to changes. Sure, management needs to record and track things in some ways, but pushing that onto development only slows the responding to change, and pushing tools onto developers (unless they want them for development and can utilize them appropriately) messes up the first point, of the individuals over tools and process.
In another way, don't stop development for the purpose of writing comprehensive documentation. Unless you only have a single developer, then someone should take the documentation load autonomously from the development role. Pushing these things together drastically slows development and for periods of time, can shut down any effort to actually get working software.
The last point, is to always, ALWAYS stay in contact in some way with the customer or prospective customer. Talk to them regularly about what they want. Talk to them daily and show them as much as you can of UI, or even data flow work. Anything that they would understand they should see. Talk to them, educate them about the architecture and ideas going into the application and never forget that you are building the application for them.
Summary:
Biggest issue is buy in. Second is management sticking to the manifesto guidelines.
If you can mitigate these two risks, you should be good to go. Anything else is cakewalk after getting buy in and getting management to understand that they'll need to be truly strong, and non-micro management managers. Specifically, managers might even need to become leads, or fill a different style of role.
...hope I didn't stray off point too much. :)
I have been running Scrum in several projects. The biggest problem, as I see it, is that not everybody in the organization is into the process. Everybody needs to be committed. Not only the team of developers. Often the managers are the persons that initialize the process and expect that things will change to the better without them doing anything.
My suggestion is that you run a workshop with the whole organization so everybody knows how the process works. Not only the developers. It's essential that you have a person that is really into the process. A person that can answer questions the team and organization have. A mentor.
Being agile is about welcoming change. You should not let the process gets in the way of sense. Do things that works for your organization, but you should try out the whole process before throwing something out.
We implemented Agile (set of SCRUM - management and XP - engineering practice) in an environment that was waterfall with large projects in an environment that was heavily integrated. The waterfall police were everywhere. As you can imagine, many projects failed. Having done Agile at a previous employer, we received permission to trial agile for the project.
Internal to the team, we used the Agile practice. Externally, we wrapped the agile practices with waterfall processes meaning primarily reporting. Thus, we looked from the outside like a waterfall project. However, there was a big difference, internally we were using agile and consequently we delivered, on time, within budget with high quality.
The critical success factors were embedded coaches (Iteration Manager Coach, Dev Lead Coach, Test Lead Coach and a Solution Analyst Coach). Securing commitment from dependent system in advance (required that we look ahead to identify depend systems and the work required from those systems) was a must in a heavily integrated environment. Prior to starting, we immersed the technical and business members of the team in an agile boot camp. This ensured that the key players (product owner and technical team) knew there roles and could execute effectively. Finally, the wrapping of the project with waterfall reporting enabled us to tie into all the existing reporting structure in the enterprise.
The net result is that the company is now moving waterfall projects to agile. This is all possible only because we have been able to deliver high quality software at a sustainable pace.
Where I work has been using Scrum for a while now but it seems to have gone through a few phases. In terms of obstacles, one part is to prevent putting in too much change at once and just introduce things slowly,e.g. put in a daily standup one week, a couple weeks later put in a story board, a couple weeks later bring in pair programming. This allows for the various tweaks that will happen to work and if the changes improve things then this can help build up some good momentum. Another point is to make sure that if there should be changes in how something is done that the person being corrected isn't belittled or mocked. At times this may mean that you interrupt someone or that you bring in a "Can we get back to basics?" or something similar to try to put things back on track rather than just yelling at someone or doing something else that is counterproductive.
Bringing in consultants was one of the best things done around here, IMO. Now, these guys came in to help evolve how development was done here. Bringing in pair programming, TDD, concepts like broken windows, organizing project folders, and bringing in mocking for tests, were all excellent additions that while we may have gotten there on our own, it may have taken a long time which wouldn't work out so well.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
If you had to make a case to a business about adopting or moving to an agile development methodology (like SCRUM or XP etc) what case would you make (how do you sell the concept)?
e.g.
How would you describe the concepts and benefits to a non-technical person?
If you have successfully done so, what was the winning argument/case/rationale?
Edit: The reason I ask is that a friend of mine (he is the solution architect at a firm) is currently trying to decide how to approach his management about exactly this topic, and I've given him what I can in terms of suggestions. Curious especially to hear from those who have successfully made a case to move to an agile-aligned methdology.
My Case: The organization thrashed around for a good 2 years and failed before finally jumping onto the agile bandwagon... there is no better alternative (as of now... personal opinion) to produce quality software at the rate at which the world changes. You cannot afford to make things the old way anymore. Some learn the hard way.
Elephant in the room: Just because an idea is good doesn't mean it will be accepted.
Logical Arguments:
Feedback loop is short. Customers can see working software at the end of each month/iteration, play with it... refine and tweak to taste. No more developers sucking dough for a year and coming back with an drunken elephant for the customer waiting for a horse.
You don't need to set everything in stone (the holy SRS) before development gets to work. You CAN change your mind to reflect change in business priorities/market conditions as time goes on.. (developers won't throw a tantrum).
Better communication: No more 'This isn't what I asked for!' when nothing can be done to salvage the ship. Dev talk to real customers in real time to clarify doubts and verify that they build the right thing. The onus is squarely on customer + development to ensure that the right product is built... by talking to each other.. all the time.
Human process: Agile recognizes the fact that software is made by people for other people. The practices facilitate interaction, learning and respect among the team. Better morale is also observed
Following practices like TDD, Automated tests, Pair Programming, etc. lead to better Quality products. Time traditionally spent in the 'bug-fixing-and-churning' phase at the end of the project is minimized.
Ease of maintenance. Regression testing is a SNAP! The systems built are amenable/easier to change/extensions.. if done right. The developers value simplicity vs over-engineering as second nature. Developers are not afraid to 'go in there and change it' vs 'I'm not touching that twisted thing.. last time's scars haven't healed yet.'
More realistic chance of meeting deadlines due to developer buy-in. Estimates are revised based on actual team velocity rather than gut-estimates of the person tasked with creating the chart/mpp/plan
Visible Progress - Big visible charts (burndowns, etc.) tell you exactly what's happening in the project without having to mine it out of secretive/reluctant/very busy people. Issues are In-your-face and can't be ignored/hidden for long. Development doesn't have to context switch to 'progress reporting' mode for a day a week to generate information for management... Easy to gather metrics that developers don't seem to mind.
Did I break the char limit?:)
Non-technical people are interested in projects done on time and within budget with good quality and which would satisfy their requirements at the time of the delivery. You should focus on how Agile helps to deliver those qualities.
It's sometimes quite difficult to sell Agile to a non-technical person for two reasons:
The concept of not trying to plan 100% ahead is not really intuitive
Quite a lot of people claim that they use Agile, fail miserably to deliver anything and give the great SDP a bad name
Talk about Agile process ability to handle changes.
It's usually easier if you work with the customer who already work with you. You could easily show them for example all of the change requests accumulated over the time and show how they affected the schedule and the costs of the project. You could then go into explaining how Agile process will help handling such cases.
Along the same line you could take the initial estimations done on a 'waterfall project' and compare them with real-life results.
I would also talk about the Agile approach to quality. Testing during iterations increase the quality considerably. Short iterations with immediate feedback are great help too, mention them.
Things that sell it well is:
Tangible product after each iteration that can be tested, played with, and released. (Good for a product owner who likes to see what his/her money buys)
It brings transparency to the development process, especially during daily stand-ups and so cuts down on functionality duplication and confusion
Having a demonstration after each sprint educates fellow employees about what direction the product is heading, what is available after the development work and gets people talking and thinking about what would make it even better
Development estimations can be made to a reasonable accuracy after a dozen sprints. At least after a few modifications to focus factors.
Improves developer buy-in as they get to own a particular functionality
Cost of product changes when using Agile tends to be much smaller than when using a waterfall methodology
Great for smallish development teams, but require buy-in from the development team.
It's almost impossible to introduce a new methodology without specifically referring to problems with the old methodology and how the new methodology is going to fix those problems.
In reality, you probably need to offer a bunch of choices, and then end with recommending your favourite. Come prepared with a good explanation of why it is your favourite, and with a really good knowledge of the weaknesses of your chosen methodology.
And make sure that you're not confusing the strength of your feeling for the strength of your argument, and that you're not trying to pass off personal value choices and cultural attachments as objective technical evaluations. Your colleagues aren't stupid - they will know if you're doing this, and they'll quickly flip the bozo bit on you.
If you want to get philosophical about this, communication doesn't actually depend on eloquence, rhetoric, or articulation, but on the emotional context in which the message is being heard. People can only hear you when they are moving towards you, not when your words are pursuing them.
In my experience, the one thing that instantly sells Scrum to non-technical management is the burndown chart. The idea that there is a paper chart - available for all to see and readily understand - that shows daily progress is an instant winner. It clearly shows very early on whether a project is on schedule.
Since the backlog, sprints, daily scrum etc are all required to make the burndown chart work, sell the idea of the burndown chart first, then explain there is a need for the rest of Scrum and finally point out that it is viable to perform a three week trial of the process with minimum impact to the schedule.
I think the number one selling point to the business is that they decide what you are going to work on, so they will be setting the priorities.
My boos, a non-technical person, usually prefer to listem about how a new methodology will improve productivity of the team. So, our aproach to introduce SCRUM, as a management methodology, focused on gains at progress visibility, better communication and sooner feedbacks.
All the other gains, as a fact of matters, seens intangible for people like my boss.
From what I have read and heard the term Agile seems to get a bad rap and scares people. From a business perspective I think what it boils down to is how can I provide business value in a more responsive way. Agile is a method of supporting the concept of delivering business value quickly.
Instead of discussing it in technical terms I would suggest your friend discuss it in business terms and state that he has some ideas that could help deliver business value to his end customers more quickly.
I would not reccomend he discuss XP or agile as the methods but instead introduce short, deliverable focused meetings (ie SCRUM) and then attempt to grow it from there. I feel if you tell the business that you can get them what they want faster and in a more predictible fashion and you deliver on that statement you will get buy-in to the practices that get you there.