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 days ago.
Improve this question
We're on our migration path to IaC and I buy into the immutable concept. But my team is asking good questions, like: "you want me to redeploy an entire fleet of VMs just because we need to make a small change? Isn't that overkill? It would be faster if I just ran some remote Powershell to implement a change."
And I get the benefits of immutability. But the questions are pushing me to wonder if we should refine our concept of immutable. In our case, we're looking at Saltstack with Packer building immutable images. A few dozen VMs (plus other infrastructure items that are out of scope for this question). Salt makes having immutable and mutable IaC easy (the latter via applying states). But whatever your tool, where do you draw the line?
Do we go 100% immutable? Every change requires throwing out an old VM and ushering in a new one. No applying changes via states (or any manual method)
Or do we have a hybrid? Possibly a very basic "base" immutable image and everything else gets applied mutably? (Via saltstate in my case.) Losing some benefits of immutability but gaining runtime agility? Note that we'd still have change management in place, so it's not like we lose track of our states.
The answer here may be "it depends." But I'd love to hear if anyone has good strategies that make sense and can be applied consistently. What belongs in the immutable Packer image? What is owned by salt states?
(I realize this is basically an orchestration vs config management argument, but I'm already invested in the former; my question is how much, if any, of the latter to pepper in and what are successful strategies for that. I've read seemingly every article out there on combining the two but none with any good scripture.)
Going to give a half answer to my own question, to close this out.
If you read the internet, immutability is the holy grail of infrastructure and there are only good things to come from it. Everyone on Earth and Mars wants it. But the truth is that not everyone really needs it, or it doesn't work for them (tbf, there are a lot of articles out there saying that you need to weigh the benefits/costs with that strategy). Below are the points we used in our solution:
Immutability is a goal. It's a goal we will never get to 100% on, and if you're starting from scratch in the IaC space, you probably shouldn't set your goals too high on this. We will move more things to an immutable space over time. It's ok to start with 1% immutability.
There is nothing wrong with change management and pushing IaC changes out via something like Salt states. In many cases, this is already going to be a huge improvement over what people in my boat have.
We started with the simplest "base" images created by Packer, installing other apps as needed via Salt. Over time, more of those apps will be built into those Packer images. The key is first building a manageable platform for IaC, and the easiest way to do that is via config management, if you have any sort of existing infrastructure to start with.
So in the end, a hybrid approach seems to work best for us, and I think it will for most shops out there. Unless you have a massive team dedicated to maintaining your IaC setup, a completely immutable platform is likely unrealistic. I hope this helps anyone that was in the same place I was.
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 3 years ago.
Improve this question
... and how to prove to management that use-cases can be informal and still useful?
Hi folks,
I came in the middle of a project and found out that there are no use-cases, user-stories, requirements, neither anything similar to a specification. Since the deadlines are short, the current dev team don't want to spend time on such things. I wanted to join that project, but by digging more I found out that the current development adds features just by considering their "wow-effect" and chooses what to add just by using the easiness that the underlying technology provides. I was surprised how they have managed to go so far (more than 4 months) without requirements, but this is what we have now. I believe that the way they have chosen is the most sure one to kill the product which has a good marketing value.
Am I right, and what would you do in a similar circumstances to prove the dev team/management to make use-cases/requirements before moving forward? Thanks in advance, kh.
P.S. Two copies of Cockburn's book are on the bookshelf...
You should give your colleagues the use-case spiel :D Tell them that use-cases are useful as they're:
A way of capturing business processes in a manner which is reasonably comprehensible by all stakeholders. This helps to bridge the gap between programmers, clients and users.
Traceable units of functionality. Use-cases are formed (ideally) in the analysis phase, referenced in the design phase, and can be used as sources for test cases later on.
Quick and easy to write up and useful, even if informal.
If you need more ammunition, you might want to read Use cases - Yesterday, today and tomorrow by none other than Ivar Jacobson.
If your colleagues still can't see the potential usefulness of use cases as a business analysis tool, then they're probably beyond help :P You should remind them that they're developing software to meet other people's needs and solve their problems in the long term, not to ostentatiously impress them in the short term with petty gimmicks. And so a little bit of direction and specification helps. Even if the use-cases themselves don't prove to be that useful, the simple act of coming up with them will force your colleagues to consider the actual underlying purpose of the software.
Ask questions, of both sides. Of development, ask them if they are certain that all of the ways in which they have considered using the application are all of the ways in which the end-users will want to use it; if they say they have, ask for proof. Of management, ask if they've ever used software that does everything they want, but still ends up being hard to use (they will have). These questions will seed the concept that what will be delivered might not be what is desired, on both sides; use that seed of an idea, then, to open up discussions (not documents, not at the start) on how the software will be used, and in what way any differences can be resolved. They'll get around to use-case documents eventually.
I am a product manager by profession, and my first reaction to your post is that ideas can come from anywhere, and if the dev team has decent ideas they should be incorporated into the product.
Having said that, a product can not develop a soul (a simple message) through a string of disconnected ideas that do not serve the ultimate purpose: solving the needs of a target user. And, ultimately it boils down to making the case that time is better spent on requirements/use cases that make sense for the product, while the opportunity cost of not having a clear strategy/end goal will lead to too many chefs and a jaded product message.
The ultimate way to make this message hit home is to involve other stake holders and have development demonstrate their work. Eventually, there will be disagreement and a more formalized (less cowboy) approach will lead to a more refined and simple product.
One of the problems you mention is tight schedule and scope creep induced by the devs themselves. Explain them, that by using use cases you can earn time by dropping features, which will potentially end up on the "never used" pile. With use cases you can find out what are the features customers need and will pay for and by removing unimportant features out of the scope you would have time to implement. Use cases apart from defining the scope also help to identify all the stakeholders, which might help you to focus even better while defining the scope and prevent forgetting about trivial things, which are not so apparent, but are a must if the product should be usable. The third most important thing about use cases is that they allow you to start thinking about corner cases which might be important for the customer before development and therefore you can find out with the customer what would be the ideal solution instead of letting the coder decide on his/her own under pressure of deadline.
Just show them.
Example is not the best way of educating people, it is the only one.
Lead by example focusing on extensions and exceptions. In other words emphasize the failure scenarios because everyone knows how the system should work. The real value of written Use Cases is identifying what should happen when something goes wrong.
That noted, consider you may have to live without written use cases. And, for the environment you describe, a major win is any sort of requirements documentation. Screen comps and/or prototyping are often easier to introduce.
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
I would like to set up a ROWE for my dev team: Result Only Work Environment.
Basically, people work how they want, when they want, as long as the work gets done.
This environment has been a huge success for Best Buy: increasing productivity and reducing turnover.
Does anyone have any advice for making this work for a dev team?
Edit:
More details: I will be leading a team of 3 other fairly experienced developers. I plan on standardizing the basic processes, such as version control, bug tracking, code review, planning, testing, etc. "How they want to work" more refers to how they manage their time: i.e. scheduling meetings, pair programming.
If you have other departments in your org., consider managing their expectations as well. It will be difficult to convince them that their project is going to take longer (throw in all the technical jargon you can think of) than you thought when they notice your team is never around (in their eyes).
You'll still have to have realistic expectations in your planning. Are you really allowing for flex time when they have 10 hrs of work to do that is due in 10 hours? How are you going to handle trouble-shooting issues that get escalated to the dev team?
One developer could be consistently better than the rest/take less time, but the team may feel this person has a lighter workload. Get ready to crush some egos.
I guess pair-programming is out?
The answer to this question is going to vary depending on the size and culture of the organization. Some would also argue that the process can matter, and you don't want your people taking any approach to achieve a result at the expense of something which they do not feel as as important.
Can you provide more info on the size of the organization and what working there is like today?
Make sure you hire the right people, you might find they work more than they WANT to admit X-).
Programming is more than a job, its a passion, and if you find the right person to fit your environment, performance measures go out the door, as the do it for the love of it.
WHEN they want will be easiear than HOW they want. I wouldn't give that much freedom to devs. IMHO, this would lead to a total mess of code.
There's very few very good developers out there today and those that are good enough should be made development leads and make the global decisions. Others should just follow the instructions or all hell can break loose.
You need to define what the results they're meant to achieve are clearly and completely unambiguously so they understand what they can control (essentially how they work, the order they develop things in and so on) and what they can't (usually what they're expected to deliver - both in terms of actual product and supporting materials such as progress reports - and when it's all meant to be delivered). You also need to let them know what resources they have - can they order high spec machines or order new software for instance or is that all decided?
I'd also ensure that one of their early deliverables was a schedule of completed milestones against which you could measure progress and agree with them what happens if they start missing milestones.
But I am slightly dubious about the idea that you're going to define version control, bug tracking and so on. Surely these are things you should let them decide? After all they're part of the process. Personally I'd state that they must have version control, centralised defect logging and so on but the mechanisms, tools and processes should be up to them.
It feels a little like you say you want to create a results only work environment but you don't quite trust them. If you're saying what you're going to do is create a ROWE then you need to make sure it's just that otherwise you're really only doing half the process and those situations rarely deliver the benefits people are hoping for.
After all, either you trust them or you don't but if you can't trust them to work out how to do version control which is frankly second nature to developers, you probably shouldn't be trusting them with the schedule which is normally a far less straightforward matter.
Results oriented means that you must trust your developers to make the best decisions. Some people love this freedom. They cheer when they have the freedom to use a wrench as a hammer if it meant quicker results, rather than switching tools just to nail a picture on the wall.
But sometimes it could be damaging. Processes are designed for maximum productivity, efficiency, and effectiveness, with all kinds of safety measures. With the wrong subversion tool, a developer could easily slip and delete all history of all work done by the team, thus eliminating the magical "undo" feature.
In another case, most fresh grads (that I know) don't have the knowledge or capacity to make decisions on their own. They may not produce as fast as they would be able to with someone barking orders at him/her. One of the most distinguishable characteristics of a fresh grad is when he is stumped or doesn't know what's going on, he doesn't ask for help.
Your developers must have the right set of mind in order to achieve goals. Freedom is good, but monitor and make sure it's the correct way to go.
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 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
At what point in a team's growth must process change drastically? A lone coder can get away with source control and a brain. A team trying to ship large prepackaged software to local and international markets must have a bit more in place.
If you've experienced a large transition in 'process': Was the team's process successfully changed with the current members or was the team itself mostly replaced by the time the process change came? What were the important aspects that changed, were some unnecessary?
You are going to find it hard to get a quantitative answer to this. It really depends on how "wide" the project is. If there is one simple subsystem to work on, any more than 1 person will result in people stepping on other people's toes. If you somehow have a project with 8 segregated subsystems, then you can have 8 developers no problem. More likely, you will have several subsystems that depend on each other to varying degrees. Oh, and all of this is true regardless of the process you are using.
Choosing what type of process you want to use (spiral, scrum, waterfall, CMM, etc.), and how heavyweight a version of that process you want to implement is, is another problem, and it's difficult. This is mainly because people try to take processes that work in building construction, factory work, or some other industry that is nothing like software and apply it to software development.
In my opinion, McConnell writes the best books on software process, even though none of his books are process books, per se.
If memory serves me correctly anything above five people is where things get dicey. The number of paths of comunication between the team gets really large after that.
(2 people = 1 path, 3 = 3 paths, 4 = 6 paths, 5 = 10 paths and so on).
The last three places I've been the IT team went through a massive process change. Yes, you will lose people, probably some of the better ones too. it's not that they are stubborn and trying to stick to the old ways, it's just that a change like this will cause a mass amount of stress. There are deadlines to hit and a need for quality to be met. People will get confused about what process they are supposed to do, and many will fall back to the "old ways." (i've been guilty of this too I admit.)
The key to succeeding is to take it slow and in small steps. People need to take time to understand why the process is changing and how it benefits them. That is huge, if you don't take time to do this, it won't succeed, and key people will end up quitting causing turmoil.
One of the things to absolutely remember is that ultimately some turnover is good. It brings new ideas and people with different (and sometimes better) skill sets. You shouldn't try and force change onto people rapidly, but they shouldn't be a barrier either. If they don't agree with what is going on, they should either try and come to a middle ground with the people making the process or leave. One of the real eye openers I learned at my first job is that in reality everyone is replaceable. Someone will eventually be able to step in take the reigns.
In my experience this transition occurs at exactly the moment at which you also need management. It is hard to get above 8 developers without some over-arching coordinating function being in place, whether it is a team lead, segregation of tasks or old fashioned management. The reality I have witnessed is that even with the best, most talented, most bought-in developers you still need coordination when you get above 8 working concurrently.
And there is a discontinuous step in process as you cross that boundary. However it needn't be catastrophic. The best approach is for the team to adopt as much formal process as it can when still small so that all the necessary behaviour and infrastructure is in place. I would argue that this is synonymous with good development in any case, so even the lone developer ought to have it (source code control, unit tests and coding standards are all examples of what I am talking about). If you take this approach then the step up in process when it occurs is not so much a jolt as a rigorous coordination.
Every developer you add need to be brought in with the process already in place. When you get to 8 (or whatever the number turns out being for you) then you'll find that your team meetings get a little too loose and wordy, personalities start playing a part and it is more effective to divide activity up. At that moment your boss (or you if you are the boss) will need to appoint one or more coordinators to distribute and control work.
This process (should) scales up as well if you stick to your processes. Teams can sub-divide or you can bud teams out to perform functional tasks if necessary. This approach also works regardless of the methodology you have chosen for your project management, be it Agile or not.
Once you get up to 4 or 5 teams, i.e. 30-50 people then you will almost certainly need people who are happy that their sole task is coordination.
If you are small now and contemplating or expecting the complexity shift, then make sure you get your fundamental processes nailed down immediately and certainly before you start adding more staff.
HTH and good luck
A lot depends on the people working on the project, the integration points, etc. Even a single coder should have a code management tool and needs to interact with clients or the 'boss'. From experience, I've seen a change once there are more then 2 people and then probably any increase of 50%. If teams are organized by project teams, focused on decoupled parts of the product, the overhead increase will not exponentially increase as the team size increases (project vs. matrix organizations).