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.
Related
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking for a team building / training activity for some of my scrum teams. I want something that really illustrates the flexibility that the team has when implementing stories to define the scope and complexity of the feature themselves. Most of the teams have long-term waterfall experience and are used to having a well-defined specification. I'm looking for something that illustrates the need for the team to vary the scope of what they are building themselves, dependent on the time and resources available.
I couldn't find anything at tastycupcakes.com and Google wasn't much help. Maybe someone has prepared something themselves they would care to share?
Edit (in response to request for example in comments)
Suppose the team has committed to building a story for displaying data to a user in a paged list for analysis purposes. The acceptance criteria can be fulfilled easily but a differnet implementation might provide added functionality e.g. wrapping a third party control which has built-in sorting and grouping functionality.
The point is, because the scrum time window is absolutely fixed the scope of the implementation may be pushed if the team feels they are ahead of schedule, especially if some technical designs proved less problematic than thought. Conversely, if some tasks have taken longer than anticipated, the team can short-cut the user story while still making sure what they delivers satisfies the acceptance criteria.
The thing I am trying to get away from is the current mindset that the feature has a specification set in stone, and that's what will be built, whatever the circumstances.
I don't think it is up to the team to define the scope and complexity of a story. It is the PO's job to define the conditions of acceptance and then it is the team's job to estimate size based on the PO's description. If the stories are right sized, the conditions are usually pretty tightly defined. This could be why you aren't seeing much out there ....
EDIT:
I don't think your example changes my answer. If the PO wanted this "additional functionality" such as sorting etc, they would have defined it in the story or in another story. To build something that isn't asked for is waste. Spending time on a story that is low priority in the backlog is inefficient. Agile is based on building what is needed and only what is needed in order of importance. So I would frown on developers adding "extra goodies" just because they are working on a particular screen.
That does not mean you shouldn't look over all the stories in the backlog and make architectural plans based on what will be needed in the future.
I think I get what you're looking for, but feel free to clarify if I'm mistaken. I'm under the impression you're looking for an exercise that will show the flexibility in implementation details the team has when using user stories.
If so, try an exercise like this.
Split the team into two groups and have the same Product Owner between them (or you can have one Product Owner for each group if both PO's know the exercise).
The PO presents a fictional story like, "As an executive at BigSales Co, I want to be able to see, at a glance, which salespeople are performing and which are not, so that I can pair performers with under-performers to improve the overall team performance."
A story like the one above is light on implementation details, but has a very clear business problem to be solved (as user stories should). Using a story like this, give the teams 30 minutes to work on a paper prototype that would satisfy the user story. They can interact as much as they want with the PO during this time frame. The person playing the PO should be careful not to give them implementation details, but leave it to the team to decide, while expressing and clarifying the business need.
At the end of the 30 minutes, have each team present their solution and explain how it satisfies the user story.
The important thing here, is that once both teams have presented, it is likely that both presentations will be quite different and yet both valid. This shows the level of flexibility the team has to provide what they feel is the best solution without having to be told explicitly what to do.
Hope this helps.
In order to estimate the story cost the team will be expecting to work with the PO to define, in at least broad terms, the requirements for that feature. In the example you gave the team may explicitly ask the PO if the sorting & grouping functionality is needed. If they say no, as the PO can't see a use for it at that stage, then the estimate is given on that basis and the implementation done according to that. No consideration is given to these additional features on the YAGNI principle. If the requirement for the sorting & grouping comes up subsequently as a result of people using early incarnations of the product, well, that's another story, and is estimated & scheduled into the backlog accordingly. The scope of the implementation of a story isn't changed just because you've got some time left in an iteration - instead you simply pull the next prioritised item from the backlog and get on with that.
Of course, when implementing the story the team are at liberty to use the most time/cost effective method that they consider suitable for the evolving product. If this means using an component with additional capability i.e. a superset of the features then they could do so (unless this is in breach of non-functional requirements), as long as the acceptance criteria are passed, but they shouldn't go deliberately adding in unrequested functionality just because they've got some time spare in an iteration.
My opinion is somewhere between your description of adapting the features to the time, which is left, and the "just fulfill the acceptance criteria and that's it" POV of the two other commentators...
In my point of view, you all should recall the formal setup of an user story:
As a -role- I want -feature-, so -aim-.
Given the purpose of a desired feature, the developer can better understand, what the PO really wants. He then can come up with additional ideas and ask the PO, e.g.:
Hey PO, if you want -aim- so why don't we do -alternative/addition to feature-. Wouldn't that be even better?
And the PO may agree and the story is implemented as described, but in another interpretation, or the story maybe adapted. The points that is important to me:
The PO describes the purpose, he would like to have fulfilled, and a feature that is appropriate to do so
The team does not just implement the acceptance criterias like development zombies, but they are open minded and are tuned to the PO's vision in general and the single story purpose in particular - so they may come up with additional/alternative ideas.
The team also does not enhance user stories or over-engineer on their own authority. That's wasteful!
I hope you share my opinion ;-)
A good training exercise and a fun team building exercise is to do the XP Planning game.
The premise is that the product owner gives requirements for something visual (like a coffee machine, a robot) and all requirements must be drawable. The developers have to draw the requirements.
There are several short iterations (the whole exercise takes between an hour and 90 minutes depending on setup time) and it's interesting to see how communication improves and trade-offs happen as the game progresses. I've ran this myself during project kickoffs and when converting teams to agile practices and the team has always found it useful and fun.
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.
I'll do a demo of my code to slightly non-technical audience, and I need to show them what I've got in my project (about 15K lines of code). I'm trying to convince them that I've spend time on the project and it's in a good state.
These guys planning to invest money into this product. Therefore I should convince them that this app worth the price that they are going to spend and justify the time I've spent, secondly they should see that this is something takes time and I know what I'm doing (basically I need to win their trust) .
What metrics I can use other than "lines of code"? (Maybe lines of comment?)
What are the best tools (preferably free) to generate a report from .NET Projects?
UPDATE :
Also a way to provide "project cost - cocomo" would be cool, like this one :
FOUND:
http://www.cms4site.ru/utility.php?utility=cocomoii will help you to calculate an estimated cost for your project.
If they're non-technical, it won't matter. It will be like trying to sell a high-end bike to people who don't know a bike from a car. 15k lines of code won't matter to them any more than 300k lines of code will.
You need to find something other than the actual code to wow them with.
Can you code up some demos and tell them how short time it will take them to build similar applications with your code? Like "If you use my code, you can build this multimedia application in 15 minutes without writing more than a few lines of code". Non-technical people generally love saving time and money.
It probably depends on how "slightly" they are in the non-technical department.
An investor only cares about money. Investors start at the exit and work backwards. Knowing this, pitch your project in terms of the return they will get in their investment.
Key points would include:
Your expertise: Do you know the market you want to sell in to? Are you leveraging your expertise in some way to make the project a reality?
Risk: Using your already existing code base lowers risk in terms of both time and money. They will probably do technical due diligence to validate your claims, so be honest here.
Time to Market: Having a code base in place will reduce their time to market, which may be significant.
Vision: They need to know that there is a future for your product. This is your chance to get them excited!
Investment is about the future, not the past, so understand that you need to achieve what you are promising. The path you trod to get to where you are now may be interesting, but largely irrelevant to the investor. What I'm trying to say is sell the vision, not where you are now or where you've been.
Good luck and hope you get what you need!
It's not clear to me from your question whether you're talking about people who would buy the use of your product or ownership of your product.
In either case, ask yourself these questions:
"What problem(s) does this product solve for my users, from their point of view?"
"What does this product let the users do, that they already want to do, but can't do without it?"
"What does this product let the users do, that they already want to do, but can't do as easily without it?"
Features don't matter. Menus and dialogs don't matter (unless they require explanation, in which case they matter in the negative sense).
If you want numbers that interest a potential buyer of (an instance of) the product, talk in terms of how much time or money the buyer can save by using your product.
If you want numbers that interest a potential buyer of shares in your company or product, talk in terms of the size of the market, how you've analyzed that market's needs, and the ROI of any investment.
I've had success showing potential customers our automated build cycle, in slideshow form. I took them through our "production line" as if it was a factory tour, and showed the nice colored bars of coverage reports, uptilted lines of historical lines of code, pie charts of breakdowns of lines of code per module.
Then I did the same for everything aroung the actual building. So there's a requirements pipeline where they are involved, and a test/validation cycle where they are again involved.
It may not mean anything to them, but it shows them you have control over your process, and control over the quality of the delivered end product.
Please note that although people may be non-technical, try to be as honest as possible. As soon as they discover one single tiny lie in your story, you're lost. And chances are that there's that one technical guy in the back who can ask that one question which makes your house of cards fall down.
Happy sales!
"good code" doesn't matter unless you are demonstrating the medium and long term advantages of it - enhanced flexibility, simplicity, which saves customer time/money while adding agility.
I think explaining the more complex aspects of the code and the work that went into it to any audience will help show how much work and effort have gone into a project.
Hours spent coding could be a good metric to give them.
Talk about the features. Explain what you have working or almost working. Go at it from what they are interested in.
Try to show them visuals that they care about if you can. I think a few minutes doodling on a board would be better than showing lines of code.
The only thing that is likely to matter to a buyer (particularly a non-technical one)is functionality. I would concentrate on selling the features. You might consider discussion how you have tested it to verify that it performs as you claim.
I wouldn't use code per se, since a non-techie wouldn't understand it. Boasting about quantity is probably meaningless (how does a non-techie know that a 1MLOC project is significant? As for quality, you can present, e.g., maintainability metrics, test coverage, things like that. Feel free to show off your excellent toolchain too (continuous integration and all that), your mastery of various performance-testing tools. Also, showing things like Workflow Foundation helps - customers like to see how their business processes can be turned directly into code with a diagram notation.
EDIT modified to reflect OP's clarification (in comment here) that these potential buyers are looking to re-sell the software
Re-sellers are going to be looking for three things:
Is anyone going to make something better, cheaper or more quickly?
Is this guy going to be able to use our investment effectively to produce more?
Can we sell what this guy has produced, and will produce?
How to address points 1 and 2 have been very well addressed in other answers, but it's question 3 which is the hardest to prove for us techie people. It's also extremely important - if you can go to these buyers and hand them 3 killer benefits which they can repeat with more flair and Powerpoint when they're doing their sales calls, you'll be off to a good start :)
The main thing you have to do is to take a step back from your work and look at the:
features: what does it do
advantages: why is it better
benefits: why should the customer care
Features are closest to what you care about as a developer, but are pretty much irrelevant to non-technical buyers. Advantages are an essential step in understanding your competition and the customers' alternatives.
By putting features and advantages together, you can hit the customer with a number of benefits, e.g.:
using my software will save you $0.01 per transaction, or $40,000 p.a.
my software will increase customer retention by 5%
your admins will need 15% less time to deploy changes using my software
These are the things that customers care about: what's going to be good for the company, and good for them.
To be brutally honest: the end customer don't care how much effort you put into it (LoC or any other metric), they don't care how well it's written (comments, tests, any other metric), they don't care how hard a problem it is to solve, they don't care about features.
Their only requirement is that it will save them time / effort / money. You know that how hard you've worked to solve the problem, and solve it well, is key to their requirement, but it's secondary. You need to make it perfectly clear why them buying their stuff will mean they'll get promoted.
For COCOMO - Project Cost Estimation
I found this website, it's kind of a manual process but it'll do.
http://www.cms4site.ru/utility.php?utility=cocomoii
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.
To quote wikipedia:
Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules."
Working on this basis, and the fact that most businesses are running 2-3 projects at a time, what actual work tasks does a SM do to fill a full time job? Or, is it not a full time job and that individual do other things such as development, sales etc?
Do any SM's out there have anything to share?
Unfortunately we don't have the luxury of having dedicated scrum masters. I am also a team leader and senior developer which more than fills the day.
I typically am on Stack Overflow all day. Oh, and I try to co-ordinate lunches.
The key to the ScrumMaster role is to remove impediments.
The ScrumMaster/ Iteration Manager
Builds the Release Plan
Builds the Scrum/ Iteration Plan
Plans and hosts the
Scrum/ Iteration Planning Meetings
Show & Tells
Release Planning Meetings
Retrospectives
Owns the blocker board and actively works with the team to identify and remove blockers
Updates the team WIKI
Updates Big Visible Charts in the team room including the story card wall
Participates in the daily standup
Participates in the daily Scrum of Scrums
The ScrumMaster/ Iteration Manager is also the sheep dog, that is they protect the team (herd). Finally, the ScrumMaster/ Iteration Manager is the point of contact for the team to external resources but primarily the Project Manager.
"acts as a buffer between the team and any distracting influences"
That is a full time job. There are a bunch of people who would love to get information from the team and it is the SM to handle those questions. To do that job well, it is important to be proactive, not reactive. Therefore they should be keeping all the wheels running smoothly. It is an amazing transformation when the SM is working well.
I think there will be as many answers to this question as there are people to answer it. On a small team with dedicated people who mostly know what they doing, the role of SM is almost invisible; on a larger team trying to cope with vague requirements and power struggles the SM will be highly visible and probably never have a moment to themselves, as they will become the lightning conductor for all the frustrations of the team (and stakeholders outside it).
There's no substitute for knowing what you want to achieve and having a small team of people who know how to achieve it. If you have that, and you "adopt SCRUM", you will probably be convinced quickly that being a Scrum Master is easy. But if instead you have a big mess of a team, and an undefined goal, and a lot of political fighting going on, and you "adopt SCRUM", you will probably come away thinking that being a Scrum Master is a full-time (perhaps impossible) job requiring a combination of very rare talents. Most real teams are probably somewhere between these extremes.
Please note: this question and answer is over twelve years old. The consensus understanding of the role of scrum master has moved on massively since then and so I no longer view this as a valid answer to the question, let alone one worthy of being the accepted answer. By all means downvote it. Beyond that, pay it no heed.
The Scrum Master will do things like ensuring scrums occur, organising sprint planning meetings, retrospectives etc. Also (s)he will be able to explain to management what the team is doing and why the team members cannot be poached off onto other projects until the sprint finishes. Beyond that, there aren't really any defined tasks for the Scrum Master. So one person should easily be able to be Scrum Master for 3 teams, and still have time left over to either do management type jobs (holiday requests, procedures, attending boring meetings with directors or whatever), or be free to contribute to the development resources of the team.
While ScrumMaster is a role within the Scrum framework, the individual fulfilling that role must be a member of the Team. In Scrum, Team members should at all costs be full time. Team members should be able to pick up tasks on the Sprint backlog. They might be development tasks, testing tasks, configuring the CI server tasks, etc... If you can't contribute to the burndown then why be on the team? Buggering off and joining another team is the last thing any self respecting ScrumMaster should do. ScrumMasters should be servant leaders that are embedded with and dedicated to their Team and product. ScrumMaster is a role on a Team, not a job title. I disagree with those that think you can be a ScrumMaster on more than one project at a time and still be world class. The fact is, that's just not Scrum.
First and foremost: remove impediments.
It is best if a Scrum Master is dedicated to one team, so that impediments are removed as soon as possible. Some of this can be done proactively, for example by pushing the PO to analyze certain stories better for the next Sprint.
If there is extra time available it is convenient if the SM has some skills that can make him function as a developer or tester on the team. I've seen good result with SM's that delegate as much as possible to a (classical) project manager and focus on development most of their time.
To make a long story short, the Scrum Master is responsible for making things happen. And in practice it is often the case that the Scrum Master is actually a project manager in disguise. At least that's the case in my company.
Working on this basis, and the fact
that most businesses are running 2-3
projects at a time, what actual work
tasks does a SM do to fill a full time
job?
Anything within their skillset to help the Team achieve the goal.
Or, is it not a full time job and
that individual do other things such
as development, sales etc?
ScrumMaster was not originally intended to be a full time job. ScrumMaster is a role fulfilled by someone on the Team. That team member is dedicated to the product full time. So, when he\she is not doing ScrumMaster duties they default back to burning down tasks on the Sprint Backlog.
Everything and anything that developers need to keep being productive. Order pizza. Go talk to admins, management, other teams. Do bureaucracy kind of stuff. Fix the build server if no one else's available.
The key word here is that a Scrum Master's role is a facilitator's role. And as someone rightly mentioned up there his most important job is to ensure seamless distraction free environment for his team, which means removing impediments, making sure his team has whatever they need at all times. Scrum master is a link between the Product team and the Development team. The decision making is done by the TEAM and not Scrum master.
It is bad idea to share one Scrum Master between multiple teams as requirement of one team may be an impediment for the other team and hence defies the whole purpose of a Scrum Master.
Also it is very dangerous to have your Manager as your Scrum master as the pressure of delivery on the manager may force him to micro manage which is a killer for any scrum team.
Other than the regular stuff which is
Arrange Sprint planning and retrospectives
Facilitate daily standups Arrange
Demo's at the end of sprint iteration
Address team's concerns mentioned at the standups
A few important things that a Scrum Master has to manage on a day to day basis is
Foresee and remove any distractions for the team before even it hits the team.
Encourage team to communicate more
Maintain constant communication with product team to check what needs to be done in
preparation for future sprints
Make sure the team follows the processes they have collectively agreed upon as sometimes
during sprint busyness some processes slip through the crack
Constantly find ways on how to improve the processes followed by the team
Most importantly a Scrum Master has to standby and support his team.
All this work takes up a lot of time and does require a dedicated Scrum Master who performs no other role.
Scrum Master is like the mother bear for the team. They look after the team's health (project wise), protect them from pesky outsiders and remove any obstacles for the team. I play ScrumMaster for my team but I am also a development lead (for the same team!) who takes part in technical discussions, design discussions, coordinating between the developers and QA on our team(if they arent already doing it themselves). I do try and take on actual development tasks to burn the chart down when time is available.
Isnt it extremely distracting for the ScrumMaster to play that role in multiple teams. God I would find that confusing. Which impediment is blocking which team again?? Wait who was working on this task??
A Scrum Master role implemented correctly, is invaluable to the Project and should not be look upon as a Part time role. The most important aspect of the role is to act as an obstacle remover for any queries raised in the Scrum meetings by the Development Teams. A Technical Scrum Master (which is what most SMs tend to be) should not be a Developer on the team, but should be able to advise on design and solutions (an extension to pair programming if you will).
They are responsible for updating the ProductBackLog (stories should be created by the business), SprintBackLog and BurnLog and for liasing with the business and IT Management on progress. They also manage a SpikeLog for any items that require investigation that may evolve into Stories (again driven by the business).
As drivendevelopment implies, the ScrumMaster is a full team member and thus should be full time. I generally treat my role as "ensuring the team functions as a well oiled machine", which can have a number of meanings at different times. Frequently, a SM spends a lot of time facilitating the team's interactions with people outside the team, especially those related to business analysis and stakeholder expectations. Beyond that, it is a matter of meeting the mechanical items listed by Cam and looking after the physical and emotional state of the team.
Related to one of the earlier answers, one of the fundamental aspects I insist on is that no member of the team is a direct report to me, nor to each other. This precludes things like vacation time, expenses, etc from being part of my job, but goes a long way towards not cluttering the trust relationship that must exist.
As generally understood priority # 1 on scrum-master list is to remove impediments as reported by team. But this should not stop here, he should constantly look out for potential impediments.. and more importantly impediments that are there but not yet identified. Ken said Impediments are opportunities. So scrum-master should avail these opportunities all day along to bring his team(s) to hyper productivity.
Ultimately purpose of scrum is to bring success to projects. Purpose of having a scrum-master is to ensure that scrum succeed in fulfilling purpose of scrum. Now to to fulfill purpose of scrum-master, he/she must think & act at strategic level as well. This is full-time job.