As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I would prefer if those who answer this question state whether or not they have experience developing in an Agile Environment or if they are speaking from a theoretical standpoint.
Backstory:
Let's say there is an opportunistic company that develops technologically innovative products (multi-touch interfaces, speech recognition devices, etc, etc) all of which are fundamentally unrelated. However, as one may see, the key advantage of working on products like these are that libraries can be created / extracted from the product and sold to other companies, developers, etc. Thus, working in an incremental fashion is advantageous as it allows the milestones to be separated from the final product.
Question1 : Is this advantageous from a business standpoint? Have any of you encountered the separating of libraries into individual products within your company?
Question2 : If products are indeed created in such an incremental manner, does Scrum seem like a valid methodology to apply?
Let's assume that this incremental process of creating components to piece together into a final application is set in place. The development team is initially very small, 6 or 7 people. For the fun of it, let's call this team a Guild. The company is just starting out, and they need to make something profitable. For argument's sake, let's say the Guild developed the FaceAPI Library. All of this was done within the Scrum methodology, let's say in one sprint. Now, the company has enough funding to employ 7 more people. These new 7 people are put into their own Guild, and their skills mirror the skills of the original Guild.
So now, this company has 2 Guilds, and 1 library off which to develop. Let's say that the one Guild is tasked with creating Product1 using the original library, and the other Guild is tasked with extending the library with more features. These two "sprints" would be carried out concurrently, and at the end the updated library would be merged into the application. As you can see, it is possible that some modifications might need to be made to the library by the team working on Product1, in which case the merge will be non-trivial.
In any case, this is the general idea. The company would have individual Guilds, or teams of people (Question 3: What do you think of this idea? Since teams are smaller, they would want to hire members that have good synergy. Is this likely to increase overall morale and productivity?), which would carry out sprints concurrently. Because of the nature of the service the company offers, the teams would work with more or less the same components, and parts of the applications, however their sprints could be created so that the teams could always carry out work without impediments. Each Guild would be a self-enclosed unit, having testers, designers, and QA's.
Final Questions:
As developers or testers, what are
your opinions on a company that
functions in this manner? Does it
foster leadership skills in
developers? Does it sound appealing?
Does it sound destined to fail?
Anyone with knowledge or experience
with Scrum, does it seem to apply
naturally in this kind of
environment?
Has anyone worked for
a company that functions similarly to
the above description? If you don't
mind answering, what was it called?
Was it successful?
To start with, I have been working on 3 more or less Scrum projects so far.
There are a couple of unclear things in your story. What is the company aiming for - developing libraries or final products? To me the two seems fairly conflicting, especially for a small company.
Another thing is, starting development with a library itself without any real users doesn't sound very agile to me. IMO an agile setup would start the other way around: develop a concrete product first, refactoring the design as dictated by the concrete situation, to possibly arrive to some sort of layered architecture, in which the lower layer(s) could be extracted into a reusable library. Then start developing more concrete products, looking for possibilities to reuse code between the projects, and evolving the design of the common library - again, as dictated by the concrete usage and needs of its clients (the product development teams).
At some point, library development would probably require its own team - in the beginning, it might suffice to have its design and its backlog coordinated between the different teams.
Regarding your question about teams treading on each other's code - this is what source control is for. Fork for the new stuff, then in the next sprint reintegrate and stabilise.
Regarding q2, scrum is an incremental approach so if the design lends itself to incremental segments of work then of course it's appropriate.
Regarding q3, how could it ever be a bad thing to hire "people that would work well within them and that they would want to work with"?
Team organization and system structure are highly dependent. See Conway's Law
This means that for you to have two separate teams working on two separate code modules (the Library team and the product team) you will need to have a clearly defined communication channel between the teams and thus, the code developed will reflect those channels in the design. Traditionally what this means is you end up defining an API or interface for the library which acts like a contract to which each team can develop. Agile practices normally adopt a more emergent design philosophy so it can be difficult to create an API that makes sense.
The way most agile teams get around this is by time boxing development to manageable increments. So while it might be unrealistic to design the entire API, the product team and library team could probably agree on an API design enough for 2 weeks of work. Write the code, deploy, design for the next iteration, and repeat. This way communication paths between the teams and code modules are established so the two teams can work independently without stepping on one another's toes.
Another option I've seen used recently is to have larger teams managed with a Kanban/Limited WIP process. Having everyone on the same team managed by a Kanban allows for more organic and flexible self-organization which means your system will be able to evolve more easily. By keeping work-in-progress highly visible it increases communication and by limiting work-in-progress you constrain developers from clobbering each other by keeping the system from evolving too far in any one direction. Combined with a solid VCS you should be good to go.
Finally, another option is that you take some time to really think about your architecture before diving into development. Using a software architecture design process such as the Architecture Centric Design Methodology (ACDM) in a limited "spike 0" kind of role could help you resolve many of the issues commonly encountered when allowing emergent design. By the end of the design sprint, you'll be able to lay out a plan that makes much more sense for what you need to do. And remember, just because it's a design phase doesn't mean you don't write code - quite the opposite. ACDM advocates strongly for experimentation.
Related
I manage a team with seven developers with more than ten products and 20 integrations between products. I took over the team a year ago, and we have worked hard to spread knowledge across the team. A year ago, every developer was basically a silo for several products and integrations, making us very vulnerable. This has improved much, and we are in a much better place today. This has been handled organically and ad hoc through co-developing and pair programming.
Recently, some developers have suggested a more structured approach to ensuring all our products and integrations are well known in the team. They want every developer to have a specific range of responsibilities regarding systems they can be asked to make changes to. So development in system X can only be done by developer x, y, or z - and not by the developer a, b, or c.
First I thought this was a great idea - everybody should not know everything. But giving it more thought, I can also see some downsides to this approach. It becomes significantly harder to plan sprints and make sure work is divided evenly with these restrictions. We could end in a situation where developers have nothing to do at the end of a sprint, whereas others are overburdened. This does not feel like a team taking responsibility for a sprint. Also, we can be forced to but less valuable work in the sprint to make sure there is work for everyone.
Are there any best practices or experiences you can share regarding having a flexible team without too much vulnerability? For example, is it realistic to ask developers to work in many products if there is an exact language and framework, common code practice, well-documented code, well-tested code, and good review processes? Or do we have to assign certain developers to certain products?
It seems like you and the team's efforts over the past year have broken down knowledge silos (via co-development and pair programming). If so, developers have T-shaped expertise; broad understanding of most products/integrations and deep historical expertise associated with a specific product as well as their technical skillset. If moving forward, I would follow a phased responsibility group approach:
Community rules: The definitions associated with each responsibility group would need to be communally defined. They should not be too narrow so that responsibility would rarely align with a DEV member at time of Sprint (think OR's not AND's). Initial ideas are either languages/frameworks, historical expertise with specific products, or process roles (e.g. Quality Assurance), however you and the team know best. The definition of the responsibility groups as well as DEV team self-assignment should be documented and available in a team accessible location.
Code review: A person within the responsibility group reviews pull request before merger. This comes into effect regardless of whether the person/pair is within the responsibility group. Especially when code is submitted by a person within the responsibility group, review by another person within the responsibility group ensures that technical expertise is distributed (peer-to-peer learning on technical area).
If the team is enjoying the process of contributing within their expertise area (responsibility groups), all DEV members are contributing to the code reviews in a balanced manner (if not review responsibility groups), and they still want to take it a step further then I would introduce an experimentation timeframe and capacity planning trump card.
Experimentation timeframe: This is an experiment with an end date, not a forever process change. The experiment duration should be long enough to see whether the process change of capacity allocation based on responsibility group has the positive impact the team is looking for (improve workplace joy due to skill fit/reduce risk of burnout, increase velocity, etc.). A pre-defined end date provides an opportunity for reflection and decision point (continue or stop). If the team agrees upfront on success metrics this makes review much smoother.
Capacity planning trump card: If code review is occurring in a balanced manner, then generally capacity planning across sprints should also work out. At sprint planning, emphasis would be on aligning with the community rules. However, if capacity (in concordance with responsibility group allocation) does not match sprint workload, then sprint completion trumps responsibility group assignments. Under capacity team members, according to responsibility groups, fill the gaps. Sprint to sprint, the same DEV members should not be forced out of their responsibility group. If so, the community rules need to be reviewed.
Of course, scrum is just a framework that you can customize according to your needs, but as far as I experienced, it doesn't work for a team with multiple projects. For this kind of scenario, kanban is a better approach.
Besides, learning a project is learning a specific historical era; it can not be achieved by only reading. A developer should read the code and the documentation, talk to the previous developers/business stakeholders, practice solving problems with some real issues. And this takes time. If you multiply this with multiple products and keep the turnover rate of the developers, you will see that it will not be feasible to achieve what you have in mind.
What I would recommend could be preparing a runbook for each project and doing pair programming sessions with a navigator & driver model and try to achieve to have at least 2 developers mastering a product and optionally others to know at an introductory level which at least help them to build and debug it. Here's my article about this approach.
I don’t think Kanban is the real solution. I have used Kanban for production issues and scrum for standard development.
So basically, the question is making a team A and team B and splitting the responsibilities across, the answer really lies around the complexity of the products and amount of work these generate. Cross training is very good but there is always a limit and you as a manager being best aware of situation have to do a judgment call or some AB testing. Changes and variations do avoid burnouts in my experience.
You could also ask questions like being under resource? Or maybe the products outdated and time to replace or rebuild?
I wish I had the silver bullet I could suggest but really it’s down to you and your team at the end, so my advice is avoid burnouts, change and embrace the change, think outside of the box, may be retire some product, do a team rotation like 3 months in team a and others 3 in team b, start some rebuilds so team stays motivated and learns new things , other could be hire additional developer remote are more cost effective.
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
We are acting Scrum in our department now. But the up level management structure is traditional, such as Project Manager(PM), Development Manager(DM), Team Leader(TL) and Test team leader(TTL).
Team Leader act as a Scrum master, he controls all the things in our team: communicated with PM/DM/TTL, development management... Our PO's responsibility is just maintaining PBL.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum, and they said some Scrum rules are hidebound.
I act as another SM, I want to change the current status.
But I haven't any headship, just is an ordinary developer in our department. Does anyone has this kind of bother too?
Thanks in advance!
I heard a lovely saying once and can't remember who said it. "They want Agile but they don't know what it is - so we give them Agile but we don't know what they want."
It sounds as if this is happening in your company. Someone, somewhere wants the team to use Scrum, but it's not the team.
That must be a difficult job for an SM, especially if you're doing it unofficially! There are some things I can suggest for you. First, learn some basic coaching techniques: positive language, GROW framework and giving and receiving feedback. This will give you some additional tools which are outside of Scrum and support someone in a leadership rather than a management position (even an unofficial SM can become a leader).
Then, don't worry about the actual practices. If someone has mandated Scrum then the team will be forced to do this anyway. Instead, concentrate on the values and principles of Scrum - particularly collaboration, communication and transparency. Help the team to work with each other instead of being silo'd away. You will have to be an example for them. Don't mandate pair programming, but do go over and pair. Don't mandate stand-ups, but do have conversations first thing in the morning and draw in as many people on the team as you can. Look at the principle of "Continuous Improvement". Learn how to do root cause analysis and the 5 Why's so that the team can understand better why things are hard and take action themselves.
I also recommend Mary Lynn Manns and Linda Rising "Fearless Change". This will help you to work out who else could help you.
Finally, I will echo #sjt. Don't commit Scrum suicide. However, if it's something you really want and your company aren't doing it in the right way, don't be afraid to look elsewhere. Learn some of the fundamentals, practice TDD on your own and find a new job.
Whatever you do, good luck! The first step to change is desire.
If you don't have buy in from your other developers its not going to work. Period.
Scrum requires a heap of discipline, especially during the early adoption phase.
I wouldn't be bothered that management don't care for it. If you're free to do the work of developing the software, and all they care about is results, then it shouldn't matter if you happen to have a 10 minute stand up each morning, and plan small chunks of the work into manageable bits, as long as you're hitting the targets they want you to hit.
If you're team isn't on board though, you're going to have a really hard time getting it working, and it will probably fail and cause more impact that not having tried at all.
If you can try to start it in a small project, with a few developers who are on board with the idea, then you can report back to the rest of your development team on how you found it works, what were the benefits and what were the negatives (reflecting is after all an important part of Scrum).
If you want to get your management on board, you might find that after doing a few projects this way you're much better at estimating the time it will take to develop the requirements you've been given by the PMs, hopefully being able to hit deadlines with more accuracy.
Remember, the PMs and BAs can still work in their normal way, once they've handed requirements to you, you're able to build them using Scrum. Its not ideal, but short of having the buy in of everyone, and the ability to speak directly to users and get them to help write user stories, it will be the best you've got.
When asked to estimate the time it will take to complete the project you can apply Scrum techniques. You can break the specifications down into smaller chunks, group them into sprints and develop them accordingly, hopefully yielding better results.
"I act as another SM, I want to change the current status"
Well, that's a good start right there, wanting to change the situation. Although I must say that without the management buy in, it will be tough. Try and arrange an experienced Scrum Speaker or Agile Coach come and do a presentation or workshop at your company which involves all the upper management. Once you have the management believing in Scrum, it will be all downhill from there.
"Team Leader act as a Scrum master, he controls all the things is our team"
This goes against the Self Organized and Self empowering Teams principle in Scrum. A good Scrum Master would empower the Team in a disciplined fashion within the Scrum Rules, to that appropriate level that, the Team should be able to run on it's own. One suggestion is that the Team Leads need to have a different mindset when working as a SM and different one while working as a Senior Developer, there are no Team Leads in a Scrum Team, only Scrum Team members. You cannot assign true leadership, that is a mutual role which can be earned by creating a reputation of helping others and mentoring others. Have them spit time between SM and development duties 30%, 70% or 50-50 or whatever you find appropriate. Command and control could be counter productive for the Team.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum
A Scrum Trainer had told once told me, "Do not commit Scrum Suicide". If your managers do not care about Scrum, don't get fired trying to convince them. Whatever methodology you guys might follow or "not" follow, you have to realise that all this is a business. Your pay check is dependent on your boss's approval, if your boss or manager does not care about Scrum, then don;t do it. If they care about waterfall, Switch to it, do it like you care, but don't do Scrum halfway and call it scrum.
What has worked for me in the past is to identify and communicate pain-points. Certainly, you should never do something because Kent Beck told you to, especially something that will just get you fired. However, some smart people worked at figuring out a set of practices which is cohesive, and divergence from these practices almost always leads to pain points.
As just one example: if you do Scrum where you have a requirements iteration, a design iteration, an implementation iteration, and a testing iteration, this in theory could work but in practice never does. (When it does, it ends up being Waterfall, and the "iteration" notion becomes meaningless.) Pointing out to your boss that you learned something about the requirements while QA was testing might help him realize there's value in getting QA involved in requirements. Or finding risks in the software design by doing a small prototype may help to show why it might help to collapse the design iteration.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As a ASP.NET developer with 5+ year experience. I like to measure my competency level in ASP.NET & SQL Server. Basically my goal is to raise my competency level and skill-set in ASP.NET; before that I need to know what is my level considering current ASP.NET and related technologies...
So, please provide some pointers...
Is there are any skill-set measuring Quiz or exam, which account experience and technology ?
How do you measure your or your junior developers skills or competency?
I guess I could rattle off some exams, like the MCP exams, or BrainBench, but you have to pay lots of money for those.
If you were really sold on taking an exam to gauge your competency, you could get a one of the MCP exam prep guides for ASP.NET, C#, and SQL Server and see how well you comprehend and take in that material. I'm not sure that it's the most accurate way of measuring competency though.
You can get a good qualitative evaluation of your SQL Server skills by simply reading Itzik's or Kalen's books and seeing how you comprehend them. For .NET, read Richter and critically evaluate yourself against the concepts you find in that book. Do those concepts make sense?
Probably the most valuable way to get feedback is to ask your senior developers for a frank evaluation of your skills.
If you're asking how I evaluate my junior developers, it's pretty easy once I see their code and they get a track record for a few months, but I don't believe quantitative analysis is the best way. Instead, I ask questions like:
Can they deliver?
Are they writing good code?
Are they taking the initiative to learn more?
What have they brought to the table?
Do they understand the software development lifecycle?
Do they break builds?
Are they good team players, or do they code in solitude?
Do they make suggestions?
Are they open to others' suggestions?
Do their design decisions make sense for the projects they've been on?
Ask yourself how your leaders would answer these questions about you. If you are seriously confident that they will respond positively, you will have an easier time "grading yourself".
Honestly, it's all relative. I've worked on teams where the junior devs from one team out-class the senior devs from the other team in every way. Different environments are going to value different skill sets in different ways.
As for a "test" of your skills, a pretty handy one would just be right here on StackOverflow. Look for .NET questions, try to answer them. The ones you can't answer, learn from those who do answer them. Rinse, repeat. It's not very structured, but it can definitely be helpful.
It's also good just to follow some of the major blogs and see if you can keep up with what they're talking about and try to implement some of it on personal side projects just to learn and practice.
The only way to really measure your skill level is to push it forward. Find stuff you don't fully grok and learn it. A truly skilled developer is never an expert, but rather just more of an expert than he was yesterday.
When asked on similar lines , I read it from somebody here on SO that
he will try to answer the questions on SO.
Let me rephrase it,
I will try to measure my performance with somebody's questions and answers.
Having said that i won't compare my competence with collective knowledge here on SO.
This is usually pretty specific to the company. There will be a bunch of criteria that the developer must meet before they get a promotion or advance to a higher level.
The hierarchy is usually pretty similar; with general (cumulative) criteria for progress to the next level. In my experience it is something like the following:
1 Graduate/recent work experience
Fair understanding of basic language concepts (agnostic).
Good all-round technical knowledge. Demonstrable
Problem solving skills. Numeric and verbal skills. Generally competent
Shows passion for a certain part of the domain.
Not a crazy person.
2 Junior/Trainee Developer
Good understanding of the primary language they use.
Makes use of de facto tools and technologies to deliver software.
Has delivered software on time and schedule.
Trusted to deliver components with guidance from more senior developers.
Can (and does) participate in design meetings and code reviews.
Has a good understanding of how the company works as a whole.
Understands unit testing and test driven development.
Fair understanding of source control and continuous integration.
3 Developer
Advanced understanding of the primary language.
Demonstrates skill in at least one other language.
Demonstrates the passion to learn more about their language.
Makes good use of design patterns when developing software to write maintainable code.
Actively seeks to improve process and efficiency.
Delivers components to a high level of quality.
Has the ability to lead a small team of developers to produce components.
Good understanding of test driven development, unit testing, mocking and stubs.
Good source control management knowledge: branching, merging, tags.
Can lead a code review with a junior developer and supervise their work.
Requires minimal guidance from more senior developers.
History of delivering quality software, on time
4 Senior Developer
Excellent understanding of their primary language
Good skills in other useful languages in the domain. In general, has a passion for learning about other languages and how the company could benefit from employing it/these to aid development
Great understanding of the domain, all of the components within it and all interactions between. This knowledge can easily be transferred to less senior developers.
Can design beautiful software
Actively seeks to improve development process and efficiency. Demonstrates languages and technologies in this area.
Fully understands the development process from start to finish.
Can lead a large team of developers to successful and timely project completion.
History of delivering excellent software and designs.
5 Lead Developer
King
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
My organization has been experimenting with the introduction of more "Agile" methods. We've been trying the Scrum approach for a short while, and most of the team has, more or less, adapted to it. I like it as a whole, but I'm concerned about one potentially severe impact of the methodology: as teams are consistently focused on features and backlog items, and testers are more integrated with the overall development process, it seems like skill sets are becoming blurred, and people are sensing less respect for their individual abilities.
Some of our developers are excellent at server-side technologies and optimization of heavy-weight data provisioning. Others have invested a large amount of their careers learning GUI technologies and have developed a fundamental understanding of users and usability in an application. Neither skill set is better than the other, but they are certainly different.
Is this an inevitable result of the Scrum process? Since everyone on the team (as I understand it) contributes to satisfying the next feature/requirement, backlog item, or testing goal at hand, the underlying philosophy seems to be "anyone can do it." This is, in my experience, simply not true. Most engineers (developers, testers, etc.) have a particular skill set they have honed over the years, and the Scrum methodology, in my mind, tends to devalue those very abilities they were previously respected for.
Here's an example for clarification:
If a sudden change of technology occurs on the server-side data provisioning, and every item on the to-do list for the sprint is based on this new change, the GUI developers (who likely haven't had time to become acclimated with the new technology) might not be able to contribute to the sprint. At the very least, they will need to invest time to get ramped up, and then their code will be suspect because of their lack of experience.
I understand the need for rapid development to discourage "role silos" but doesn't this discount one fundamental reality: people develop skills in accordance to necessity, their interests, or their experiences. People seem to be less motivated when they perceive their position is one of "plug-ability" (e.g. we can "plug" anyone in to do this particular task). How does Scrum address this? If it doesn't, has anyone addressed this when adopting the Scrum methodology?
The short answer is an emphatic NO! Scrum does not blur or depreciate the skills required for specialization. Scrum does not promote generalization.
The long answer is that in Scrum, the most important thing is to get the work "Done". The team, as a team (as opposed to a collection of individual "stars") collaborate, as needed, in order to get the job done. Whatever it takes - however they want (Scrum is about self managing, self motivating teams, right?).
What this means is that a scrum team may be composed of several specialists, who primarily do what they specialized in (DBA, Graphic Design, even technical writers). The team, as a whole, should have all of the skills required to fulfill the requirements. This is not the same as saying that each team member has to have all of the skills aforementioned.
That being said, it is often desired - often by the members themselves - that members other than the specialists be at least adequate in skills different from their specialty. Another poster already mentioned Scott Ambler's "General Specialist". This helps the team when there's too much work of one kind, when the specialist is absent, and it helps the member when he really would like to gain experience outside his specialty.
Given that the team is self organizing, if for some reason a specialist finds himself in the middle of the sprint, without any work to do in his specialty, the best way to deal with it, is to simply ask the specialist what he wants to do. Let the team decide. The specialist can decide to help in his other areas of adequacy, do a POC for the next sprint, "shore-up" the defenses by fixing some long forgotten technical debt, or shine the shoes of the members who are working.
Yup. I don't know if this is the long answer. But it definitely was a long answer.
:-)
The point of Scrum is for the developers to self-organize. We use scrum where I am, and jobs get passively sorted by a person's focus. We don't do it on purpose with a chart and list, it just happens. We all know who's best at what, or what their main/secondary focuses are. If the 'main' person needs help, they get the person/people with a secondary focus in it to help. We do get plenty of tasks not necessarily in line with whatever our particular focus is, but you always know who to ask for help then.
For your example - I don't know that if you say had 3 server guys and 5 gui guys, that you'd expect to get all the work done in that sprint (if the server guys + some help from the others wasn't enough). The way the sprint is supposed to work is that from a prioritized list, the developers pick what they think they can get done in that 30-day timeframe. If that meant the GUI guys needed 2 days of server-side training in order to help, that's what it'd mean. Unless there were concurrent things also high up the list that they could do instead. The sprint tasks are not supposed to be dictated by management as a psuedo-deadline.
If you have a Safari account, there's an interesting mostly case-study book by one of the guy/s who invented scrum.
I've been working as a ScrumMaster for about 18 months and have worked with two different teams. I initially expected to experience the potential issues you raise but this has not been the case. What I generally observe is that the team evolves into a mixture of specialists and generalists as people find the appropriate role for themselves - one that they can enjoy and be successful at. This is self-organisation at work. I have never had a case where our specialists were sitting idle.
If this did occur, I would expect it to be raised as an issue in Sprint Retrospective and the team would discuss how to improve the situation. The most obvious (and brutal) conclusion would be to change the team composition.
I am not sure why skill set will get blurred. There is a fair amount of confusion in the agile world. Scrum is a project management process and not a software development process and should not be seen as one. The engineers have to follow their own methodologies like TDD or extreme programming to add their own part to being agile.
Nothing goes away in scrum.
PM's still document as they go
Architects still architect their components. The only thing is they just delay some major decisions to more responsible point in time.
Developers should still follow best practices such as SOLID principles to enable for refactoring in a consistent manner as features change.
I think Scott Ambler addresses this issue very thoroughly in http://www.agilemodeling.com/essays/generalizingSpecialists.htm...
His concept of a Generalizing Specialist is exactly the thing Collective Ownership / Scrum Team calls for, and makes total sense to me.
Its hard to achieve in real life though ;-)
If you find for any reason ('sudden change of technology' or not) that the amount of work required for a system over a sprint is greater than the amount available then there's a problem with your scheduling.
One fix is that, as you suggest, you take programmers from other areas and throw them onto the mix. How well this works depends on the skills of that person and how different the problem domain is, but treating programmers as generic units that can be farmed out as needed is generally not a successful strategy for developing software.
This is still a scheduling problem though.
The best thing about Scrum is exactly the fact that skills do get a bit blurred! The point is to avoid silos at all costs by spreading specialist knowledge across the team and letting people work a bit outside their comfort zone.
Obviously this is not for everybody. Some developers are happy in their own narrow specialist field and such people are more of a hindrance in a Scrum process than an asset, whereas well-rounded and multi-talented people who are determined to get the job done, usually adapt very very well to it and are far more productive.
One of the key benefits of Scrum is to get the whole team actually involved and invested into the project instead of tackling their own special tasks and then riding off to the horizon. I'd claim that for most people, this is a far more rewarding way of working than the conveyor belt -approach of waterfall processes.
So I'd advise to boldly embrace the mixing of skills and having people come together to take down nasty problems instead of relying on specialist silos. The result of teams consisting of motivated people can be surprising.
Sounds like this would lead to more well-rounded developers, and also allow those who are experts in certain areas to continue to contribute their expertise.
I haven't used Scrum much myself (yet), but from your description, these types of teams would lead to a team/organization that is also more well-rounded as a whole - and shouldn't that be the goal of any team?
Handling sudden changes is part of Agile and this may mean that some people have to go off and learn new skills. Course this is more within the general Agile philosophy than anything Scrum-specific. There may be some extreme cases where the customer or business decides to change the world by bringing in something new and thus has to handle the subsequent pain of those people ramping up but if this is what they want and the developers are overruled, then there are only a couple of choices: (Take your lumps and try to handle the major changes) or (quit and get out of there).
While there can be some cases where someone that has specialized in something may be able to do things faster, this doesn't necessarily mean much if that is just one person on the team that is an expert and there is enough work in that area for 10 people for the whole sprint. Should those not an expert simply not do that work and let that one person attempt to get through as much as he or she can? I don't think so but there should be something to be said for those that aren't the best at something still trying to get done what they can get done.
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 months ago.
Improve this question
.NET 3.5, .NET 4.0, WPF, Silverlight, ASP.NET MVC - there's really a lot of new Microsoft technology released / on the horizon to try out these days.
(The examples I gave is all Microsoft technology but this can apply to any language or platform). I am curious how this is handled in the company you work for. A few examples:
Do you have a CTO that determines what technology the company uses?
Are development teams free to choose what technology they use? For example: framework version, classic ASP.NET vs ASP.NET MVC, ADO.NET Entity Framework vs Linq2Sql or NHibernate? Or a mix of these?
What new technologies does the company you work for try out and why?
Does your company have dedicated resources (time) to try out WPF or whatever technology, just for research, or do you try things out in your spare time and try to introduce them to your company?
These are just examples to make my question clearer. To summarize, I'd like to know what this process looks likes, who is responsible, who makes the decisions. Does your company jump on the bandwagon, or is it reluctant to try new technologies? And are you comfortable with this situation?
At the company I work for, we still use .NET 2.0 (although we are now slowly switching to .NET 3.5), haven't seriously looked into ASP.NET MVC, haven't tried out WPF at all, etcetera. And, some find it pretty hard to convince people to do. Is it fair to expect otherwise?
At my company, we have an architecture group that determines which technologies are used. People are welcome to read up on alternative technologies and make suggestions, but at the end of the day, it's the architecture group that makes the decisions.
While this may seem restrictive, it does ensure that all of the development groups are using the same or similar technologies, and moving from one group to the next is fairly easy. As well, by having one group do all the research, you ensure that you don't waste time by having multiple groups duplicate the research effort.
Since I work in such a small company and am I typically either the only developer, or the lead developer in a very small group, I can usually convince my boss to use whatever I think would be the best for a given project/situation.
We stick to what we know for our major and key projects within the company.
For any new "mini" projects that come along, we take the hit on the learning curve to try and build them in the latest technologies if at all possible.
This enables us to get up to speed on these things to then comfortably and safely use these technologies in our major projects as we see fit.
Where I work there is an architect team which looks at technologies from a high level and makes recommendations to various actual teams. A subset of the architect team actually takes the technologies and experiments on them and out of the produces
Internal 1 hour overview sessions
Week long boot camps
Whitepapers/Posters
The more important the technology is the more of that list is produced. All of that just feeds to teams, which combined with customer requirements for technology actually make the decision for what that team should use.
I have a mix answer to this question. Where I work, lower level technical managers are usually the ones that chose a certain technology and sometimes even the developers have the freedom to try something new. For example, I really wanted to learn about JavaScript's Prototype while working on a web site. I made the case to my boss, he was reluctant first because nobody else knew it or had used it before, but gave me the go ahead. It was great for me to be able to learn Prototype and take advantage of it's many built in functionality. Other bigger projects come down from higher management and we don't really have much of a choice. Right now, my company is adopting SAP, so everything is moving into that direction. I don't necessarily want to become an SAP expert, but if I want to stay here, I'll need to at least learn how to work with it.
Every company has its own pace for innovation, and it's dependent first on the comfort level of the managers, and second on whether anybody actually does the work to research and propose using new things. When the managers start getting uncomfortable, innovation slows or stops until they get comfortable again. Some innovations they will never be comfortable with.
Keeping this in mind, I'm not sure how to answer your question about whether or not it's fair to expect more innovation than is happening. Certainly it's reasonable for you to want more; equally, once you've hit your organization's speed limit on innovation, it's not likely to change and, if it does change, it will probably take a long, long time.
I've been given rather large amounts of freedom to change things by various managers in my past, and I took advantage of it. I also ran into the limits on a regular basis, and finally dealt with my frustration by starting my own company. (This may be considered a somewhat drastic measure; certainly by doing do you reduce the time you have to research and develop the very things for which you started your company.)
These days I'm developing rather significant applications in Haskell, and I'm pleased as punch. After a year, I'm starting to get the hang of it, and I certainly have several more years ahead of me just learning what I can do with the tools I have now.
I suppose the summary of my response is: if you want to innovate more than those around you, you need to change your peer group.
I think any company that tries new technology for the sake of it, as its bleeding edge and 'innovative' is crazy. To have a formal 'lets play with new technology to try it out department' is just nuts.... unless they're in the business of providing technology consulting to other businesses.
For everyone else technology is there to help the business get things done. Not to help developers line their CV's with cool sounding TLA's.
The company I'm working at the moment is quite large and has a CTO that chooses 'strategic platforms'. But I've have to say, if you can pick a technology, they're probably using it. They're too big to beat everyone down with the corporate stick, but they try. If the technology will work in the project and bring it in on time, then it gets used.
We need solid and proven platforms for our stuff. And, we don't need anything fancy. Therefore we might go for .NET after 5-10 years or so, hope it's ready by then. On the other hand, Java is already mature enough, so we're using it alongside with C++ and some Jython scripting. These decisions are pretty much autonomous (we're a small shop).
I don't mean to mock bleeding edge developers, but whether you need solidity or newest features obviously depends on what you're working on. Many scientists are still happily using Fortran 77.