Getting involved in managing the process
The company I work with has historically had very few software development processes. We are not currently implementing any specific method. The problem is that it makes planning, getting a decent release successful, or even hiring good software developers difficult.
I think I can convince them to do some kind of Scrum process. The key, however, gets the management / owner buy-in. The idea of blocking certain functions for any period of time scares them, I think.
Does anyone have any suggestions on how I can do my thing?
While I am planning:
- Give a presentation on how Scrum works. how I see that he works with the people we are currently and how it will benefit the business.
- Request training for specific people so that we don't "come up to us as we walk."
- Set a date for implementation, there are some planning and loose ends that I probably need to tie in order to start the process.
source to share
If your projects are similar to standard / typical IT projects, then chances are that your projects failed or were too complex or too expensive, or did not do what the client required (internal or external), or take too long to develop.
If you are going to advocate for a process, you need to show that you do not lose flexibility in order to have structure.
Points for decision makers:
- Having a Scrum-like process will improve the amount of information that management has at their fingertips and allow them to make decisions faster. Consider a scenario in which you have a 6 month project. Well, without processes, how do you know how much work is done before it's released? With Burndown charts, you can track how much time is left in a visible way. If you link this to TDD, where you define, say, 100 test cases, they can see that 50% of the test cases are left to run, but from the burn rate there is enough time to do 25% (remember that such managers are just like that this is not the ideal state of the project, but it is easy to understand the one that was better than theirs before)..eg they will feel more control because projects have better visibility.
- The process improves quality, which in the long run will lead to fewer errors, less time for errors, increased transfer of knowledge (what happens if your star developer gets on the bus), all of which means that the company will force developers to focus on the best product. than constantly fixing bugs. eg. it will save them money
-
A small set of changes will be implemented first. It will be a proof of concept and also safe and easy when needed. eg. it shows that you are reducing the perceived risk . And you need to mitigate the perceived risk, because that's what they'll be focusing on. That being said , you will want to collect some data before you make this offer. What for? Good question, you need a baseline for two reasons:
- You need to know what changes helped. This way you can suggest more changes.
- The manager will probably complain about the problem while the proof of concept is out. You will need evidence to show that problems in a free environment without a chaotic regime are the norm, and that this is not a deterioration and possibly a slight improvement. You can bet on what goes wrong in a no-process environment. And you can bet that proof of change in the conceptual process will be blamed. So be prepared for this.
source to share
In my experience it is easier to sell a design methodology or practice guide after it has been piloted once. I would choose a small project, usually internally if possible, and ask to "pilot" your new scrum process. It is generally much easier to get people to buy a pilot because they only have to commit on a limited basis.
As your new experimental project progresses, be sure to document (post-on, notebooks, Word doc, whatever) how scrum makes your project more or less successful than the previous (flaw) method. Be brutally honest here and try to quantify things in real terms whenever possible.
After completing the project, compile your notes and present your results to management using the completed project as evidence. Use results like:
- "the product provided users with a real sense of progress in feature X"
- "the pig / chick style has been maintained by X man / hours per week, keeping meetings in check"
- "sprints allowed developers to work more closely together and resulted in X% less buggy code"
Typically, if you can get leaders to a place where they can draw conclusions about dollars and cents, 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 they are not given out during the pilot.
Good luck and happy productivity!
source to share
You can sell Scrum as a Lossless offering. See what happens when you use Scrum:
- All development work is always focused on the tasks with the highest priority.
- Progress is 100% open and checked daily.
- Users / clients get the opportunity to investigate progress at the end of each iteration.
- Requirements are changed automatically.
The only reasonable objection I've ever seen in Scrum is that it's actually impossible to predict how much a project will cost or how long it will take. This is because Scrum recognizes that everyone will learn as a project starts and requirements will change. Falls claims to be able to do this, but we all know how well it works.
source to share
Run Joel Test to determine how much work you need to do. If you're having trouble estimating release dates, review Based on the evidence .
source to share
Keep in mind that it is also possible that you don't have a process because management doesn't know or care about it. If your managers have no interest or understanding of the process, such a process could be triggered by getting all programmers to agree with him (or at least the team leaders) and telling new hires "this is how things are." Of course, it is imperative that you select a process that is compatible with your manager's requirements if you do so (for example, if your managers request daily updates on milestones, do not choose a process that has no coding for the first two weeks).
This really works if you have a discussion with a manager and their main reaction is, "It doesn't matter if you keep writing code." If you think of a process as a means of rearranging the order of work done, rather than adding new work, you are more likely to succeed with this approach.
source to share