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
Related
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 3 years ago.
Improve this question
I work with a small team (4 developers) writing firmware and software for our custom hardware. I'm looking into better ways to organise the team and better define processes.
Our Current Setup
Developers are generally working on 2-3 projects at a time.
We have projects that work in an iterative sort of way, where a developer is in regular contact with the customer and features are slowly added and bugs fixed.
We also have projects with fixed delivery dates, and with long lead times, final hardware might appear only a few weeks before delivery. The fixed projects are usually small changes to an existing product or implementation and the work is somehow intermingled.
We are also moving from consulting to products, so we are occasionally adding features that we think will add value, at our own cost.
The Issues
We have a weekly meeting where proportions of time are allotted to each project. "Customer A wants to test feature X next week", so the required time is allotted. "Customer B is having issues with Y, could developer P drive down and take a look?", etc.
When we're busy, these plans are very loosely followed. Issues arise and lower priority stuff gets pushed back. Sometimes, priorities are not clear to developers so there is friction when priorities appear to change. The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.
I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.
Developers are generally working on 2-3 projects at a time.
Multitasking is incredibly inefficient. Switching the brain from one task to another requires time for the gears to change over.
When we're busy, these plans are very loosely followed.
Then why create plans at all?
Is it all possible to dedicate just one developer to one task / product / customer? So developer P is the only one who talks to customer B? (Certainly the developer would need to document exactly what he's doing in case he gets hit by a bus, but he should be recording issues and roadmaps anyway.)
The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.
If there had been only one developer on project Z anyway, he wouldn't have been distracted by customer A's problems.
Don't think in terms of a pool of developers serving a pool of customers, think of one developer for a given customer. (This can make vacation planning a little tougher, but if you're constantly pulling all-nighters, you aren't spending enough time away from the office anyhow.)
I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.
Aren't we all.
"Customer A wants to test feature X next week", so the required time is allotted.
Allotted by whom?
Do you create your own schedules? If not, the only response to management creating a schedule for you is all-nighters.
Realistic non-all-nighter schedules will bother management. Until you can prove that your customers want a better schedule with fewer all-nighters, there isn't much you can do.
The only way to reduce the all-nighters is to get stuff done sooner. But if the hardware doesn't arrive sooner, there isn't much you can do, is there?
Two thoughts: drive quality and improve estimates.
I work in a small software shop that produces a product. The most significant difference between us and other shops of a similar size I've worked in a is full time QA (now more than one). The value this person should bring on day one is not testing until the tests are written out. We use TestLink. There are several reasons for this approach:
Repeating tests to find regression bugs. You change something, what did it break?
Thinking through how to test functionality ahead of time - this is a cheek-by-jowl activity between developer and QA, and if it doesn't hurt, you're probably doing it wrong.
Having someone else test and validate your code is a Good Idea.
Put some structure around you estimation activity. Reuse a format, be it Excel, MS Project or something else (at least do it digitally). Do so, and you'll start to see patterns repeating around what you do building software. Generally speaking include time in your estimates for thinking about it (a.k.a. design), building, testing (QA), fixing and deployment. Also, read McConnell's book Software Estimation, use anything you think is worthwhile from it, it's a great book.
Poor quality means longer development cycles. Most effective step is QA, short of that unit tests. If it were a web app I'd also suggest something like Selenium, but you're dealing with hardware so not sure what can be done. Improving estimates means the ability to attempt forecasting when things will suck, which may not sound like much, but knowing ahead of time can be cathartic.
I suggest you follow the Scrum Framework. Create a Scrum Environment with an enterprise product. Have product Teams working on the features for their own individual products, which is a part of the combined enterprise product. If you have the resources have a production/issues support and infrastructure Scrum Team. If the issues are coming your way too quickly, have the infrastructure Team try following Kanban or Scrumban.
The Scrum Framework in itself will solve most of your problems if adopted properly.
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.
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 3 years ago.
Improve this question
Currently, my company utilizes agile as its development principal. I was approached by my boss to determine some methodology for determining the amount of work a project manger does on a given project in flight. To be honest, I can't really think of anything fool proof.
I guess the best question is how do we assess how busy, on a day to day basis, a project manager is?
Remember that ANY metrics you can come up with is most likely going to be gamed.
[ Do I get a badge for on-topic link to Joel On Software? :) ]
Having said that, you can try a union of the following approaches:
Developer feedback!!! (e.g. a good PM's feedback would be "I had problems X, Y and Z and he made them disappear"). Not so good for measuring how "busy" a PM is but really good for measuring how effective he/she is.
Volume and rated clarity of project plans (easily gamed)
Rate of change of project plans (easily gamed)
Amount of meetings/meeting time (easily gamed)
Success rates of projects (on timeliness vs. % of features delivered vs. customer satisfaction). Not easily gamed but devil's own work to normalize this across projects.
Timesheets will measure the amount of work in one sense (you can see how their day breaks down and so on) but not I think in the sense you want.
Ultimately I don't believe there is a useful metric for Project Managers in this sense, but I don't think that's an issue.
I think ultimately you should measure project success rather than "busy-ness". After all, why do you care how busy the PM is if they deliver successful projects?
One PM may spend half a day putting together a risk log and mitigation plan which contains 20 risks, another may spend 2 days putting together one which only has 5 risks but none of those numbers are any more useful as a metric than lines of code. The key thing is not how long you spent doing it, how many risks you identified, how big your mitigation plans are, but whether you actually managed risk on the project successfully.
You're better off looking at what a Project Manager is meant to do, which is to deliver projects on-time, to budget and to customer satisfaction (which I'd use as the ultimate measure of quality rather than defects).
After all, do you measure how "busy" the CEO is? Or is he just judged on the profit the company makes?
To do this:
Time - The only way it can really be gamed is by massively padding estimates and plans and this can be minimised by reviewing the plans and estimates and having all relevant parties agree them (developers, PM, client). The other side of this is that the PM must agree to the plan rather than have the implementation date foisted on him or her. You might want to measure this on either the overall implementation or each milestone.
Budget - Measurable but gameble. For most development projects the key thing her is honest timesheets from the developers and the best way to ensure this is to make it so the PM is the PM but not their line manager. That way the developers have someone to fight their corner (a technical director for instance) if they're being pressured to fill in timesheets to keep the budget down. Again the PM should agree the budget, it's not reasonable to expect him to deliver on something he's told you is unreasonable.
Customer satisfaction - Hard to measure so I'd suggest that you keep it simple and go with a straight forward post project review with the account manager and marks out of 10 for communication, delivery and whatever else is important. It is subjective but ultimately so is customer satisfaction.
But a lot of it depends on the company culture. For some organisations the key thing will be billable hours, others developer satisfaction will be part of the mix.
I am trying to understand WHY you have been asked to estimate the amount of work that a project manager does on a project.
At best it is just a request for a rule of thumb, otherwise it indicates that your boss just don't know the first thing about running a project. Even when projects looks very similar there will always be something unique about a project:
The team is not identical (teaching
the new guy the ropes takes time)
The spec might vary just a tiny bit
(and that tiny bit might double the
workload)
Even the season might influence the
outcome
and so on and so forth
Each and every condition on the project might change the workload of the project manager, so it will always be a subjective assessment.
I would suggest you use the same Burn Down and Level of Effort that you use for the developers. A PM's task in an Agile environment is a bit different (and from shop to shop it's different), but the PM should be able to provide a list of tasks, etc. I'm thinking positive and seeing it as your bosses approach to determining how much availability the PM has.
Most project managers equate responsibility with status, so a project manager who has spare capacity is quite likely to volunteer to take on a new responsibility, because it's in his/her own best interest. In all but the most functional organizations it's often better to be visibly overloaded, for that heroic look.
It's more likely to be in the organization's best interest to slightly under load its project managers, so that there is some spare capacity available should something start to go wrong. A project manager might well choose to apply his/her spare capacity in some constructive way in any case. Excessive politicking or other unconstructive activity is a good indicator of someone who could be more constructively deployed. Even on agile projects, workload tends to be uneven across a project cycle - e.g. delivery is often a management-intensive activity - somebody who is continuously heavily loaded probably has too much to do, and may be ignoring or hiding a serious problem.
If the next level of management conducts regular project reviews, pays attention to how many problems are being escalated, whether the project reports correlate with the news from the grapevine, and does some basic estimation on workload projections for each project manager, then the organization should be able to run a reasonably efficient system.
Managers tend to be political and psychological animals. Any methodology that doesn't take that into account is ignoring reality, so a good methodology for this problem is likely to be based more on observed behaviors than on hard numbers.
Excuse me if I am being to purist, but the tag and the question calls for Agile. What would be a project manager in Agile? You might either be trying to asses the work being done by a product owner or a scrum master?
In any case, both roles perform several tasks that are hard to measure, so probably your boss is looking at the wrong picture.
For instance, a scrum master is "The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent". Basically is a coach and a facilitator. Blocking disruptive requests or distractions created by higher levels of management by negotiation or persuasion to follow scrum practices is one of the skills commonly used by scrum masters. Several of these soft skills are hard to measure as "work" since they do not involve working on a computer or producing a report.
I think a the metric that your boss would benefit most from is more related on how effective the team is and how a scrum master is described to facilitate the work of his team-mates. DVK then has a very valid point, the metrics you create can be "gamed", so it is best to trust that your managers are busy if your projects are progressing and your teams are happy and work as a team.
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.