Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I lead a team of six programmers, and we are presently implementing a number of agile development practices. I'm very interested in Scrum, however it seems to assume that your project will have multiple developers. Most of my projects are smaller, and involve a single developer. We run 3 or 4 such projects in parrallel at any time.
From reading Schwaber, a lot of the benefit of Scrum seems to derive from teams self-organising to achieve a complex task. If you have a single developer doing all the work, will Scrum deliver much value?
Scrum might be more than you need as a single developer, but if you have a stake holder and a QA person then Scrum can still be helpful. Remember they are apart of your team, and should be at your standups to trade information with the team.
If you are truly alone there are other agile practices that might make more sense to you. For example, Kanban might be a better fit. You don't have iteration overhead, retros, sprint planning, etc. You just have a backlog that you pull tasks from. This works well as a way to organize your work, allows stake holders to adjust priorities, and works well for a single developer or small team where you can break up work without a lot of need to synchronize between developers. Maybe you have a product built that only has small features that doesn't need a lot of architecture being built to support new features. Or lots of small projects that are independent say for advertising firms, etc.
The single most important benefit of Scrum that is there even if there is just one developer is not the daily sync (meeting), but rather the limitation on context switches. While working in sprints this single developer can concentrate on given stories within his (presumably short) sprint knowing he won't be interrupted or pushed to do something else before finishing this.
Less context switching == less waste == more productivity.
BTW - Kanban offers less overhead than Scrum, but it is easier to circumvent and force developer to context switch. This can be a benefit but can easily become a problem too.
I think that the value you may get can come from scrum or other agile concepts.
For example, instead of a weird standup meeting, have the one developer tell you why he has taken x desicion for the y task. You may or may not be able to suggest things (depends on your background as a developer I guess), but the fact that the developer is hearing his own explanation might be useful for finding bugs or dead-end reasonings.
As a professor of mine once commented on asking yourself a question aloud: "If you ask the universe for an answer, it will give you one"
While, as others have pointed out, the daily standup may be weird, there's still value for an individual developer in adopting a scrum-'like' process.
Timeboxed, potentially releasable, iterations and a stack-ranked backlog can only help an individual developer keep focused on actually getting something done instead of endlessly ratholing.
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
I posted this question on Reddit Programming and did not get a single response. So I am hoping that Stack Overflow community will have an opinion.
Have any of you ever been on a software project that had fallen behind, where 'Crashing' or 'Fast-Tracking' the project schedule actually brought the project schedule back on track? I have never seen either of these project management techniques actually work. And all the articles on software development that I have read all state that these 2 techniques do not work and actually pushing the project further behind (for example literature on the Mythical Man Month). So who has seen it work?
Thanks Bill.
I have only ever seen it work once. It was a three or four month long project that was projected to run an extra two months over the original delivery date. The project got fast-tracked and things ended up getting back on track for the release.
...keep in mind though, that was only once. I've been on many more projects where the PM tried to use one of those two methods and they failed miserably and dragged the project out for months beyond already extended date.
It can work. But there's a price to be paid: lower quality (more bugs, less testing) and turnover of burned-out programmers.
And in many cases, a fast-tracked project will both fail to deliver on time and will still pay the full negative price, for the reasons stated in Mythical man-month.
I've seen it work but it's not the norm.
Things I'd want to see before I thought it might be feasible:
1) Staff available with suitable skills and approach. By that I don't mean ".NET programmer", I mean detailed technical skills, business domain skills (so they understand the problem), personality fit and understand the tools and the approach (source control, methodology and so on). This can happen in large companies where there are common tools, standards and knowledge but you need to be sure that they're ticking pretty much all the boxes.
2) Tasks must be nicely divisible. The best situation is where there are whole modules, applications or tasks unstarted and you can put new people on that. It minimises upskilling, additional communication and so on. If you can't separate out what the new people will do you're likely to majorly disrupt the existing team.
3) The whole team must have bought into the approach. If the existing team don't agree that bringing people on board will be right they'll likely fight it and you're doomed.
4) You need to be sure you've addressed why it was running late in the first place. If it was just bad estimates then are you confident the new estimates are good? If it was scope creep have you got the scope and change control in hand now? If it was because the deadline moved, are you sure it won't move again?
If you can't tick all four of those off, it isn't going to work.
Crashing and Fast-Tracking are two very different things...
Fast Tracking is where you take something (tasks or work packages) out of sequence and do it early. This may because of hardware delivery lead times, availability of resources, risk or whatever. So you might do things in parallel where originally you had planned to do it sequentially. I've fast tracked a lot of projects.. and yes it works.
Crashing a project is different in that you typically throw more resources at a problem to get it done quicker... this can be tricky. If it's done as a crisis response it can be painful adding extra people as you are already under the pump. In some situations you just add more problems.
Another alternative to crashing is to reduce scope. This is not always possible, but it should be considered.
With fast tracking or crashing... the sooner you know when you need to make a schedule change the easier to manage. This is why early deadlines are so important, they indicate how the rest of the project will go.
Both of these project management techniques work well to maintain a schedule, but they should be used intelligently by judiciously analyzing the network diagram:
study the variance,
study lead and lags;
decide what suits to your project: ‘Crashing’ or ‘Fast-Tracking’.
There is a software management principle that says adding manpower to a late project makes it later.
That said, as long as the measures taken are sensible it should be ok. Don't expect too much of your staff and provide reasonable incentives and don't take short cuts. It won't make miracles happen but if you're practical and want to push things just that little bit faster it can definitely be done.
When people have a stake in the potential success of something it's amazing how much more effort they're willing to put in.
It depends on what you mean by "work". I don't think I've ever seen it make a way late project deliver on time, if that's what you are asking.
However, I have seen it make way late projects deliver only a bit late. From the fuzzy perspective of management, that might be called "working". I've also seen it significantly lower the customer-based pressure on the company. Some might also call that "working".
Of course the price is rather high. Employees burn out, develop health problems or big problems in their neglected personal lives, etc. All of that has large financial repurcussions to the company. So I doubt the company comes out ahead in the long run. Is that "working"?
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
Imagine you work as a contractor in a large project involving multiple systems, and you are creating one of them. The whole project uses a traditional process, but there are smells that tell you that an agile process would be much better.
Now the question. Does it make sense to introduce an agile software development process in your own group only? There is no chance to change the whole project, but you might perhaps change the process in your own group.
What would be the major benefits and pitfalls of such a local process change? Are there specific agile processes that would work good in such a case?
Here's a great diary of how a guy changed his whole company towards Agile over a period of a couple of years - yes, starting with his own subproject, i.e. "bottom-up". But he does go into the pros and cons of trying a "top-down" change.
http://jamesshore.com/Change-Diary/
Very entertaining and intruiging stuff.
Read Effective Ways to Introduce Agile into the Workplace and Joel's seminal Getting Things Done When You're Only a Grunt.
Beyond that it's probably mostly marketing/expectation management with your superiors and customers. Both of which might resent investing in the various agile customer-inclusion "games". Both of which also might resent the "new-fangled" way of doing things.
I think the answer depends how isolated you can be from everyone else's process. If they just tell you to go get your portion done and come back with a completed widget, implementing Agile locally should be relatively easy. If, on the other hand, you are expected to follow lots of random dates and procedures, it will be more difficult.
You'll have to be flexible and make sure that whatever sprint cadence you have lands on similar dates to the rest of the system. You'll have to plan out your sprints ahead because the central planners will probably want an all-up feature list early and won't stand for the more laid back Agile approach. Just be conservative about what you'll deliver and you should be fine.
The advantages should be the same as the advantages Agile has elsewhere.
This is an interesting scenario. I had a similar situation years back, and I'd say doing this essentially doubles the project manager's (your?) workload. You will need to play double face, with one set of cards towards the customer and one set towards the developers.
If your developers are GOOD, I would go for it. If they are not, and would require kicks and handholding, be careful. If they are good but may get carried away to their own agendas, be firmly in charge.
It is sometimes funny how organizations with traditional project model emphasize minor features, irrelevant to the developer's mind, and completely ignore the real hot spots. I still don't get it - maybe it's plain stupidity and nonprofessionalism. Expect that.
And do remember test based approach is the heart of Agile development. Do tests first. This will be peculiar to the customer, but they will benefit in seeing how the subproject actually proceeds. You might get less "progress" early on but more at the final yards.
Depends on your motivations, and what you aim to achieve.
Pitfalls: the major one is that agile development works by increasing visibility. Thus, adopting agile practices in one sub-project, if the effort is at all successful, can lead to exposing issues that affect the whole project, resulting in a risk of backlash. Keep in mind the parable of the two envelopes.
Which practices you take on first depends on how you want to handle this risk. If you start by adopting the planning-related practices (task board, release plan, user stories, velocity) matters may come to a head relatively fast.
Ditto, more or less, if you start with practices in the area of requirements (user stories, automated acceptance tests).
If you start with internal quality (test-driven development, refactoring, continuous integration) you may improve the motivation of the developers on the project, at the risk of not necessarily mattering a whole lot in the larger scheme of things.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I work in the technical department of a design agency. We use XP to manage our department's software development. I have been asked to give a short presentation describing Scrum and whether it would be suitable, in a broader context, for managing client project work.
Scrum would be applied to cross functional teams containing graphic designers, information architects, content editors, user experience engineers, web designers and software developers.
What benefits could scrum bring to this sort of team?
Based on my experience, I would say the key features of Scrum are:
High visibility of progress.
Regular feedback from customer.
Predictable rhythm.
Measurable productivity (via burndown, velocity, etc.).
Cross-functional, self-organising teams.
Inspect and adapt.
Low bureaucratic overhead (meetings, documentation, etc.).
Emphasis on face-to-face communication.
And these features lead to the following benefits:
Project can respond easily to change.
Problems are identified early.
Customer gets most beneficial work first.
Work done will better meet the customers needs.
Improved productivity.
Ability to maintain a predictable schedule for delivery.
If we're talking about the benefits only they are pretty much obvious.
Using a proper methodology you work better, i.e. you have higher rate of successful projects. If your projects are already 100% successful you probably do not need to change anything.
For us using Agile helps to:
Increase the quality of the deliverables (because of the strict iteration rules, when you expect everything to be working by the end of the iteration instead of 'coding being complete' it works wonders)
Cope better with the changes (and expect the changes. It's mostly psychological issue but it really helps when your developers expect that a requirement will change at some point)
Provide better estimates and spend less time doing them
Be more in control of the project schedule and state (short iterations, clear, unambiguous ways of calculating the velocity etc.)
As a result we achieve higher customers satisfaction rate in general
In my experience, the main benefit is that your manager gets to say you are doing Scrum, and you get to waste more time going to daily meetings instead of getting work done.
... it's possible they weren't doing it right ;-).
For the team you describe I see these main benefits:
Visibility into what's happening and accountability. During the SHORT daily meeting you get a better idea of what's happening, what was finished and what was not. After some time you start to see trends: who's good estimating, who is not, who is telling you they are working when they really are not. You have a better picture of when you are going to be done.
Self organization. The team members are the ones that pick what to do and when for the given iteration. This takes time when people are not used to it, but ends up making team members happier because nobody is dictating who gets to do what. They decide.
Improved ability to rapidly react to requirements changes. The concepts of time boxing , daily status checks and user involvement will make it easier to both capture feedback and change your priorities.
I don't see much differences between XP and Scrum. If you already have XP, you likely don't need to switch. Maybe adopt some Scrum specific practices for better scalability like Scrum-of-Scrums. Almost all the other practices exist in XP like daily meetings, iterations, roles separation, retrospectives, etc.
In fact I am not sure that such separation have benefits. It is bette to decide what you are doing bad during retrospective meetings and apply practices from any process (or create own solutions) to your specific problems. XP and Scrum give you a framework that will help to be adaptive and creative. While traditional processes gives you a set of rules that impedance any creative behavior.
Your team and your project IS special. Think and communicate to sharpen your development process.
First of all Scrum is a methodology for project management not for development...it can be combined with XP or RUP...
Scrum is good for you if you have a project that changes...when your requierements changes you need to keep up with these changes... Scrum has short iterations (2-4 weeks) and this provides more response to the changes... and the client can have a early release of his product and you can have all that feedback you need... maybe this is the first benefit...
Another benefit: your team will be always working syncronized specially when they depend on each other...
As I understand it, daily Scrum meetings are for the team to discuss progress and blocking issues. The Scrum master facilitates. The product owner can be invited if the team decides to do so, but the meeting is not intended to provide any progress status to a boss or a manager.
I hope I am correct.
When you say "Scrum" I don't know if you mean agile, or just the daily meeting. Assuming you just mean what is the advantage of the daily meeting I see 3
1 - You have an opportunity to expose any issues you are having to the entire team and can get help an advice from people you might not have thought to ask. It's more efficient that having to interrupt coworkers throughout the day to try to get help for some problems you're having.
2 - Group teams get a better picture of what the entire group is doing and you have an opportunity to influence development you're not immediately involved in.
3 - You generally get to spend less time writing progress reports because everyone, including your boss, hears everyday what you're working on and what progress you've made.
That's my experience with scrum
I've been "Scruming" for two years and my experience tells me that it's much easier to know "where we are" at any point because the development process is in fixed length periods (Sprints) that allows to evaluate what's been done. And in the middle of those periods having the Daily Scrum (those meetings Dmitriy was talking about) and the Burndown Chart (the graphic of the remaining work) allows the team and the manager to always know what's already done and what's the team is working on.
In your case you'll probably need to have several smaller Scrums, instead of a large one, because Scrum works best with smaller teams. This book has some insights about that:
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
You won't get deadlines getting late :)
I think scrum is more of a habit than a method or practice. There are lot of teams operating in scrum without knowing that they are doing agile and there could be lot of teams claiming that they are agile and not following the basic principles of scrum.
I have worked with kanban, waterfall, agile scrum and others while development software products and with my experience, I am more comfortable with scrum. It gives you sense of achievement and keep you awake in the light of what needs to be achieved further and how to do it.
Scrum product development methodology is based on incremental and iterative product development process where solutions grow due to collaboration between cross-functional and self-organizing teams. Here are the major benefits of scrum
Simplicity and transparency of processes
Adaptive planning
Quick adaptability to change
Evolutionary development and delivery model
Iterative approach
Quick learning cycles
Automated testing offers a stable platform
Rapid market release
Integrated and flexible teams which can change requirements anytime based on user feedback
I feel I have made enough justice to the answer.
Here is where you can learn more on my experience: http://www.cygnet-infotech.com/blog/agile-scrum-methodology-for-product-engineering
Team Spirit
High visibility of progress.
Frequent demonstration and early feedback from stakeholders
Problems are identified early
Quality of product and Improved productivity
Higher customer satisfaction
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
We are just starting on a pretty big project with lots of sub projects. we don't currently use any kind of named process but I am hoping to get some kind of agile/scrumlike process in by the back door.
The area I will be focusing on most is having a good backlog for the whole project and, at least in my head, the idea of an iteration where some things are taken from the backlog, looked at in more detail and developed to a reasonable deadline.
I wonder what techniques people use to break projects down into things to go in the backlog, and once the backlog is created how it is maintained and ordered. also how relationships between elements are maintained (ie this must be done before it is possible to do that, or this was one story now it is five)
I am not sure what I expect the answer for this question to look like. I think what may be most helpful is if there is an open source project that keeps its backlog online in some way so I can see how others do it.
Something else that would get +1 from me is examples of real user stories from real projects (the "a user can log on" story does not help me picture things in my project.
Thanks.
I would counsel you to think carefully before adopting a tool, especially since it sounds like your process is likely to be fluid at first as you find your feet. My feeling is that a tool may be more likely to constrain you than enable you at this stage, and you will find it no substitute for a good card-wall in physical space. I would suggest you instead concentrate your efforts on the task at hand, and grab a tool when you feel like you really need one. By that stage you'll more likely have a clear idea of your requirements.
I have run several agile projects now and we have never needed a more complex tool than a spreadsheet, and that on a project with a budget of over a million pounds. Mostly we find that a whiteboard and index cards (one per user story) is more than sufficient.
When identifying your stories, make sure you always express them in terms that make sense to your users - some (perhaps only small) piece of surfaced functionality. Never allow yourself to slip into writing stories about technical details that you could not demonstrate to a user.
The skill when scheduling the stories is to try to prioritise the things you know least about first (plan for what you want to learn, rather than what you want to do) whilst also starting with the stories that will allow you to develop the core features of your application, using subsequent stories to wrap functionality (and technical complexity) around them.
If you're confident that you can leave some piece of the puzzle till later, don't sweat on getting into the details of that - just write a single story card that represents the big conversation you'll need to have later, and get on with the more important stuff. If you need to have a feel for the size of what's to come, look at a wideband delphi estimation technique called planning poker.
The Mike Cohn books, particularly Agile Estimating and Planning will help you a lot at this stage, and give you some useful techniques to work with.
Good luck!
Like DanielHonig we also use RallyDev (on a small scale) and it sounds like it could be a useful system for you to at least investigate.
Also, a great book on the user story method of development is User Stories Applied by Mike Cohn. I'd certainly recommend reading it if you haven't already. It should answer a lot of your questions.
I'm not sure if this is what you're looking for, but it may still be helpful. Max Pool from codesqueeze has a video explaining his "agile wall". It's cool to see his process, even if it may not necessarily relate to your question:
My Agile Wall (Plus A Few Tricks)
So here are a few tips:
We use RallyDev.
We created a view of packages that our requirements live in.
Large stories are labeled as epics and placed into the release backlog of the release they are intended for. Child stories are added to the epics. We have found it best to keep the stories very granular. Coarse grained stories make it difficult to realistically estimate and execute the story.
So in general:
Organize by the release
Keep
iterations between 2-4 weeks
Product owners and project
managers add stories to the release
backlog
The dev team estimates
the stories based on TShirt sizes,
points, etc...
In Spring planning
meeetings the dev team selects the
work for the iteration from the
release backlog.
This is what we've been doing for the past 4 months and have found it to work well. Very important to keep the size of the stories small and granular.
Remember the Invest and Smart acronyms for evaluating user stories, a good story should be:
I - Independent
N - Negotiable
V - Valuable
E - Estimable
S - Small
T - Testable
Smart:
S - Specific
M - Measurable
A - Achievable
R - Relevant
T - Time-boxed
I'd start off by saying Keep it Simple.. use a shared spreadsheet with tracking (and backup). If you see scaling or synchronization problems such that maintaining the backlog in a consistent state is getting more and more time-consuming, trade up. This will automatically validate and justify the expenditure/retraining costs.
I've read some good things about Mingle from Thoughtworks.
here is my response to a similar question that may give you some ideas
Help a BA! Managing User Stories ...
A lot of these responses have been with suggestions about tools to use. However, the reality is that your process will be the much more important than the tools you use to implement the process. Stay away from tools that attempt to cram a methodology down your throat. But also, be wary of simply implementing an old non-agile process using a new tool. Here are some strong facts to consider when determining tools for processes:
A bad process instrumented with a software tool will result in a bad
software tool implemention.
Processes will change based on the group you are managing. The
important thing is the people, not the process. Implement something
they can work successfully in, and your project will be successful.
All that said, here are a few guidelines to help you:
Start with a pure implementation of a documented process,
Make your iterations small,
After each iteration talk with your teams and ask what they they
would change, implement the changes that make sense.
For larger organizations, if you are using SCRUM, use a cascading stand-up mechanism. Scrum masters meet with thier teams. Then the Scrum Masters meet in stand-ups of 6 - 9, with a Super-Scrum-MAster responsible for reporting the items from the Scum-Master's scrum to the next level... and so forth..
You may find that have weekly super-scrum meetings will suffice at the highest level of your hierarchy.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
The company I work for has historically had very little process as far as software development. Currently we don't really follow any specific method. The problem is of course it makes it difficult to plan, successfully have a decent release or even attract good software developers.
I think I may be able to convince them to do some sort of Scrum process. Key however is getting management/owner buy-in. The idea of locking into specific features for any period of time I think scares them off.
Does anyone have any suggestions on how I can make my case?
So far I plan to:
Give presentation on how Scrum works. how I see it working with the people we currently have and how it will benefit the business.
Ask for training for specific people so we aren't "making it up as we go along"
Set a date to implement, there is some planning and loose ends I probably have to tie up to start a process fresh.
If your projects are like the standard / typical IT projects, then chances are your projects have failed, or been buggy, or cost too much, or didn't do what the customer (internal or external) needed, or took too long to develop.
If you are going to advocate a process, it needs to be shown that you will not lose flexibility just to have structure.
Points to make to decision makers:
Having a Scrum-like process will improve how much information that management has at its fingertips, and allow them to make decisions more quickly. Consider the scenario that you have a 6 month project. Well, with no processes, how do you know how much work is done until it is released? With Burndown charts, you can track how much time is left in a visible way. If you couple that with TDD, where you define say 100 test cases, they can see that 50% of the test cases are left to get working, but from the burndown rate there is only enough time to do 25% (remember Managers like it simple, so this isn't a perfect state of the project, but it is an easy to understand one that was better than what they had before). .e.g. they will feel more in control because the projects have better visibility.
Having process allows you to improve quality, which long term will result in less bugs, less time spent on bugs, more knowledge transfer (what happens if your star developer is hit by a bus), and all this means that the company will get developers focused on a better product than on continuously fixing bugs. e.g. this will save them money
A small set of changes will be implemented first. This will be a proof of concept, and safe and easy to back out of if needbe. e.g. this shows that you are mitigating perceived risk . And you need to mitigate perceived risk because that is what they'll be focusing on. That said, you will want to gather some data before you even make the proposal. Why? Good question: you need a baseline for 2 reasons:
You'll want to know how much the changes have helped. So you can propose more changes.
You'll likely have a manager complain about a problem while the proof of concept is going on. You'll want evidence that shows that problems in a chaotic process free environment are the norm, and this is not a worsening of the state, and perhaps a slight improvement. You can bet on something going wrong in a process-free environment. And you can bet that the proof of concept process changes will be blamed. So be ready for it.
In my experience it's easier to sell management on a design methodology or practice after it's been piloted once. I would cherry-pick a small project, usually internally facing if possible, and ask to "pilot" your new scrum process. Generally it's a lot easier to get people to buy into a pilot because they only have to commit on a limited basis.
As your new scrumified pilot project moves along, be sure to document (post-its, notepads, Word doc, whatever) how scrum is making your project more or less successful than the previous (lack of) method. Be brutally honest here, and try to quantify things in real terms whenever possible.
After the project completes, compile your notes and present to management your findings using the completed project as evidence. Use findings such as:
"product backlog provided users with real sense of progress on featureset X"
"pigs/chickens meetings style saved X man/hours a week by keeping meetings in control"
"sprints allowed developers to work more closely together and resulted in X% less buggy code"
Generally, if you can bring leaders to a spot where they can draw dollars-and-cents conclusions, they will go for a new product or methodology. Also, and this is important as well, be prepared to walk away from your original process ideas if you find them not bearing out during the pilot.
Good luck and happy productivity!
You can sell Scrum as a "No Lose" proposition. Look at what happens when you use Scrum:
All development work is always focused on the highest priority tasks.
Progress is 100% open, and inspected daily.
Users/customers get to examine the progress at the end of every iteration.
Shifting requirements are handled automatically.
The only reasonable objection that I've ever seen to Scrum is that it isn't really possible to predict how much a project will cost, or how long it will take. This is because Scrum acknowledges that everyone will learn as the project commences, and the requirements will change. Waterfall pretends to be able to do this, but we all know how well this works.
Run the Joel Test to determine how much work you have to do. If you are having trouble estimating release dates, look into Evidence Based Scheduling.
Provide some sort of argument that shows how Scrum will address past pain points experienced by the key decision maker. Extra points if you can also provide evidence that demonstrates this.
Keep in mind that it is also possible that you don't have a process because the management doesn't know and doesn't care about it. If your managers have no interest or no understanding of a process, such a process could also be started by getting all the programmers to agree to it (or at least team leaders) and telling new employees, "this is how things are done." Of course, it is necessary that you pick a process that is compatible with your manager's requirements if you do this (e.g. if your managers ask for daily updates on milestones, don't pick a process that has no coding for the first two weeks).
This is really only appropriate if you have a discussion with a manager and their basic reaction is "It doesn't matter, as long as you keep writing code." If you present a process as being a means to redistribute order of work done rather than as one which adds new work, you're more likely to succeed in such an approach.