Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are planning on introducing Agile into our development process (a shift from the waterfall we've been using so far). We are leaning towards a hybrid model in whcih the requirements gathering session is comprised of a business analyst, subject matter experts, technical person and a user interface person. The plan is to create user stories that the development team can use in their agile process with 1 month sprints.
Has anyone had experience with a hybrid model? How has it worked for you so far?
The plan is to create user stories that the development team can use in their agile process with 1 month sprints.
Some remarks:
1 month Sprints is IMHO too long, especially for an adoption and I prefer to use 2 to 3 weeks Sprints. During an adoption, shorter feedback loops give you the opportunity to inspect and adapt more frequently and since you are experimenting, this is in general appreciated.
I don't really understand what is so hybrid in your requirements gathering session as long as the goal is not to create the "final" list of fine grained Product Backlog Items in one shot (a backlog has typically a pyramidal structure with fine grained items at the top - for the upcoming iterations - and coarse grained items at the bottom). Having story-writing workshops ahead each iterations is a common practice.
PS: While I respect Péter's opinion, I have a slightly different one. I consider Scrum (we're talking about Scrum, right?) as a minimal and finely balanced framework and recommend to stick as close as possible to doing Scrum by the book. Sure, the goal is not to be Scrum but to deliver working product increments. But unless you have someone experienced with Scrum in the team, you (as organization) are not really qualified1 to alter the framework (and to understand the impacts) and might not get all benefits. Scrum is flexible, there aren't two similar Scrum implementations. But dropping a part of the framework is not the same as being flexible.
1 I often introduce the Shu Ha Ri progression model (that roughly means learn - detach - transcend) for agile adoption. From the C2 wiki:
As the beginner starts to learn, Shu gives them structure. It forces them to adhere to the basic principles (...). Since the beginner knows very little, they can only progress by slavishly adhering to these principles (...).
As the beginner gains experience, they naturally will wonder why?, how?, is there something better? Ha... the separation (much softer word than break) is the experimentation done around the principles... first straying only a little and then more and more as these ideas are tried against the reality of the world.
As the experiments of the Ha stage continue, bit by bit, the successes are incorporated into daily practice... we look for opportunities and use the patterns we have learned and tried out that closely fit those opportunities. This Ha/Ri stage is what makes an art the 'property' of the practitioner rather than the teacher or the community. Eventually, you are able to function freely and wisely.
I'm certainly not saying that one must stay at the Shu phase (the goal is beyond the first level), what I'm saying is that learning new ways of working takes time, don't ignore practice. As Ron Jeffries once said "They're called practices for a reason... You have to have done them. Practice makes perfect."
Update: (answering a comment)
One of the decisions we would like to take is the role of each person in the 'Product Owner' team.
Just to be clear: there should be only ONE Product Owner. He can of course work with a team but, still, there should be a single authoritative voice for the team. If I rephrase, there is no Product Owner Team.
For ex: What would the role of a technical person be?
Well, for me the technical person has no role to play in this team (unless he is there to train or support people at writing stories but the ScrumMaster should typically do that). Writing stories means capturing the essence of business oriented features, there is no real need for a technical point of view at this stage. Technical complexity (or even feasibility) will be included later in the estimation.
It seems to me that the end result of the requirements phase would be user stories that the developers will use in the iterations. Will the technical person be estimating the tasks? Traditionally, we've had the programmers estimate their own tasks
People doing the work should estimate the work (you can't expect a team to commit on something if someone else estimate the work for the team). In other words, the team should estimate stories. On top of that, experience shows that 1. collective estimations works better than individual estimation 2. we are better at doing relative estimations. So my recommendation would be to estimate the size and complexity of stories relatively using story points/t-shirt size/unit-less points and to do collective estimation during planning poker sessions. This worked very well every where I used this.
One of my colleagues (I work for a company which consults in agile working) has written several blogs about this separation between the requirements gathering and the development process. He describes how this can work very well in practice.
So far I have had experience with hybrid models only :-) None of the agile projects I have worked on so far implemented any Agile methodology strictly by the book. You needn't either.
The point is, any methodology is just a starting point / a collection of ideas you can use to work out your own process, tailor made to the specific project, team and circumstances.
Start with a process which looks good to you, then see how it works in practice. Keep regular retrospectives at the end of each iteration to assess how things are going, what worked in the last iteration and what didn't, and how could you improve things further. Then implement the most important ideas in the next iteration. In other words, develop the development process itself in an agile way :-)
Update: anecdotes about the requirement process
As I write this, I realize you may not got much useful info out of it... but at least it shows you that projects and processes vary a lot.
In one project, we had a fairly strict Scrum process, with a product backlog, although we didn't have a real customer: the product was new, and the prospective users didn't yet know it existed. Also it was a fairly specific and standardized domain where our company had a lot of experience. At the time I was part of the team (this was before the first release) we didn't really have much formal requirements gathering, because much of the key requirements were imposed on us by a standard. On top of that, we had some of our own ideas how to make the product stand out of the crowd.
In another project, we loosely had a Scrum process, but our sponsors and users did not really know about it, so we were struggling quite a bit. The "requirements gathering" was rather informal in that the product was huge and different people / subteams were assigned to different areas, working fairly independent of each other. Each subteam had their own contact(s) to discuss the requirements with, and the contacts were geographically separated - we rarely saw any of them face to face, so most of the communication happened via email, using lengthy Word docs. To top it off, we had a team of domain experts, who were often in wild disagreement with the users regarding the concrete requirements, however they were not very communicative. So the requirement process often consisted of reading lengthy documents containing obscure mathematical stuff, then other lengthy documents containing GUI requirements, then trying to figure out how to bring the two together... then discussing the requirements with the domain expert who briefly announced that it was a piece of sh*t, and we tried to tease some more useful and concrete improvement ideas out of him... then rewriting the requirements doc according to our latest understanding and the expert's comments, and sending it back to our contact person... then repeat from square 1.
In our current project, we again have many users scattered around a large part of the globe. However, at least our IT management is more knowledgeable about SW development and agile processes. We work on a large legacy system, which was in a pretty bad shape a couple of years ago - so maintenance and stabilization is a large part of our day to day work, and new requirements take less than half of our time on average. When we have one, though, we usually have preliminary estimation meetings where we try to come up with a crude estimate on how many person-days this project going to take. Then later our business analyst works out more and more details with the stakeholders, and our team works on filling out the technical details.
It seems to me if you label business analyst, subject matter experts, technical person and a user interface person as "the product owner" team, you really haven't deviated from "pure" agile.
That said, "pure" agile is somewhat of a misnomer because most agile advocates will tell you that the #1 or #2 selling point is its ability to adapt to the business processes and corporate culture of your existing organization.
The critical success factor might be having that product owner team, and all stakeholders really, invest in participating in some of your dev team's agile processes (showing up for demos, being accessible for questions during the sprint, etc).
Edit:
This quote from Wikipedia documents the very simple role of the Product Owner:
The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog.
Scrum isn't meant to enforce processes on how the Product Owner gets their job done. It's only the interface between the Product Owner and the Team (sprint planning and sprint review) that Scrum tries to outline.
Could we call this, "Building the back log," as that is really what this is, to my mind? The idea is to get those top priority pieces and then work from there. I have seen a few different Agile processes and some worked better than others but the key is how well is the buy-in from those involved in the process.
I'd also agree that 1 month is too long for a sprint. 2 week sprints seem about right to my mind though I have seen slightly longer and shorter sprints that also work. Another question is how big is the team and projects that are being done as stuff that may take years may not be easily done. I say this as someone that survived a project that lasted over a year and many sprints and demos later finally finished the project successfully.
I'd likely consider the technical person being the one that has to keep an eye on the big picture and understand what may be reasonable to do and what is unreasonable to do,e.g. having the system read my mind to know what I want done before I wake up in the morning without my having to write out anything other than simply thinking it would be unreasonable. Don't forget that the stories will develop into more cards as the stories are just a high-level view of what the end result is, which usually doesn't cover how easy is it, how much time will it take and a few other aspects.
For the sprints themselves, developers should estimate how long it takes to do various tasks. Determining the priority of stories though isn't part of what the developers do though. The requirements gathering session could also be seen as building a project charter so that there is a timeframe for the project as a whole, objectives and other high-level details that should be stated at the beginning.
Related
I work in a big organization, spread around the world, about 17,000 people. Have to ask for money wayyyyyy in advance for projects before even really knowing what they are.
So we're redesigning an old intranet. Spending a chunk of money we have on user research and UX design phase. More on the 1.0 and piloting it and dealing with content migration and all that fun stuff.
Any ideas (insane ballpark here) about how much $ to ask for the next phase (rolling it out, more testing, actually replacing the legacy intranet)? I know details are sparse but there are some silly budget deadlines that require me to pull a figure out of thin air before I even really know what our end users want. If I don't come up with a number, we get nothing and have to hunt around in various budgets to get cash.
What would you throw out for low / medium / high numbers here? Low being open source, out of the box functionality, not insane customization, no more UX research beyond what we're already doing, and off we go. Medium being a nicer step up, and high being paying someone like Igloo $400k to use their out of the box platform, and then another bunch of custom plugin development and design work on top of that.
Right now I'm thinking 250k, 500k, 750k. Am I in the right ballpark, or am I over in some other arena that's not even in the same league and hasn't seen a baseball game in years?
As you've all but acknowledged, it's an impossible question to answer. You are constrained by an illogical system which seeks to reduce risk by increasing control in the mistaken belief that accounting for all spend in advance will increase return on investment. Your challenge is to learn how to play that system to your advantage, secure your funding and achieve the freedom to deliver your project with minimal interference.
Support
Fortunately, you are the best-placed person to do this. You have the best understanding of your organisational context and if you look at broadly similar (global, cross-functional) internal projects, you can get a good idea of how these projects are regarded and how they secure and maintain support and funding. Talk to colleagues and learn what you can. Ultimately you aren't looking for a right answer - you need to know what constitutes an acceptable answer and how to proceed when your guess proves to be "wrong".
Start looking externally to learn what you can about projects in similar organisations. Listening to others' experiences will give you a better understanding of potential risks, so dig deeper than the run-of-the-mill success stories. You might consider attending conferences, intranet-focused meetup groups and participating in online communities.
Vision
What is important is that you have a vision for your intranet project. As you go on, this vision may change. You will hear lots of assumptions about what people expect to be on the intranet. It's great to read you are conducting UX research as it's vital to understand what people actually need and use.
Needs
A guest presenter at a recent intranet event I ran showed us an intranet she'd built in-house over a five year period which was designed solely to help employees do their jobs effectively.
There were no generic calendar tools, no pages of content that no one ever looks at and no fashionable social features. Instead there was a lean, focused business tool, written in PHP, on which she'd spent GBP20,000 each year.
Equivalent value? Probably a month of Sharepoint consultancy.
It takes careful leadership and communication, but once you stop trying to deliver mediocre generic solutions based on what everything thinks "should" be on an intranet, you can ditch out-of-the-box tools and start focusing on your users' real needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work in a small company (2-4 software developers) where software is "only" a part of the main product (specialized measurement instruments). So far the software has been built from start to end with no formal process at all, but as we're steadily growing in both in number of products and people involved, it's evident that we need to adopt some kind of methodology for the whole thing (designing, building, testing, maintaining) to avoid blowing into a mess
The problem is that none of us has much real-world experience on such processes. Wikipedia's software development methodology and software development process entries list lots of practices, and I'm aware of the modern buzzwords (agile, extreme, etc.), but we're still lost on how and from where to start all this.
What should we do to get started, given that currently we have no formal process, and the goal would be to have a light process that helps us keep things under control without slowing us down? Is there some:
Essential de facto literature that we should read first?
Essential tools? (We do have a SCM, but should we start using something like FogBugz?)
Practical "do this and this" guidelines?
Any guidelines are welcome, as long as they're not 1000+ page books! I want to avoid both the religious hype and the dull academicity that seem to surround this field, and find out what to do in practice.
Highly recommended reading includes : The Agile Manifesto and The Pragmatic Programmer. Subsequently, you'll probably want to get familiar with Scrum software development, or Test-Driven Development. At the very least you should have:
Source Control repository
Bug tracking system
Standard set of tools
for communication (A wiki tends to be
popular for documentation, these
days),
IDE
Testing framework
A lot of things will depend on the skills of your team and the application domain that you're seeking to go into. Get yourselves familiar with some methodologies, then practice them. Have 15 minute standing meetings at the start of the day. Develop code incrementally with a write a failing test, make it pass, repeat mindset. Etc etc.
I would suggest to try Scrum for start. As lightweight project management framework it should suite your small team needs.
To do that less painful I would also suggest temporary hiring someone familiar with scrum (certified scrum master maybe), after 3-4 months you should be able to keep it running by yourself. Really investing in few months of experienced team member should pay off. And I don't mean analytic, consultant or whatever you call person that comes, analyzes, makes presentation, takes money and goes while you stay with a problem. I mean Team member that will work with you but also introduce scrum to you via daily practice.
You could also just read some books instead, or send one or two team members to a training, but I think that having someone to incorporate Scrum into your daily work and start learning by examples is the best.
Good description detailed description (based on daily work) would be Scrum and XP from the Trenches (alternative source).
Subscribing rigidly to someone else's view of the development process isn't going to work for everyone. Start with the real basics
Get the basics of the development process right - see The Joel Test.
Track everything. Use a system like JIRA, FogBugz or so on to track all issues, features and bugs that are ever reported. Track how long you spend on each task; the information you have the better prepared you'll be.
Triage - Work with stakeholders to make sure what you are doing is actually important, rather than just what you think is important. In my experience, developers and customers often have wildly differing views!
I'm a huge fan of the recent Lean literature by the forerunners of the movement, Mary and Tom Poppendieck:
Lean Toolkit
Implementing Lean Software Development: From Concept to Cash
Leading Lean Software Development
These are very practical books that look at the whole business value chain from a software team's viewpoint, instead of being head-down in software land and ignoring business goals.
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 8 years ago.
Improve this question
If you have a room full of capable developers, what can be done to encourage those developers to become excited and enthusiastic about software and software development?
No gimmicks, but a genuine move to create an environment where people want to work in software, not just because the company is a good company to work for overall.
In my opinion, the absolute, #1, most essential thing that motivates developers to be enhusiastic about their work is a sense of ownership over their product. All the team-building excercises, reading groups, etc. are good but ultimately ineffective if the developers don't have a sense of ownership.
Here's a quick, off the cuff list of things that are important, in my mind, to ensuring this is the case:
Developers have a real and honest stake in the future design of the system. There will always be requirements that come from outside the development team, but developers should be represented when those requirements are discovered and be able to give real input into the future state of what you're working on.
Developer championed requirements or changes to your solution should be given a voice. A balance needs to be found, certainly, but all too many companies don't have proper mechanisms to allow pure development-focused requests to get through. These could be product enhancements, building up unit tests or simple refactorings, but they are essential to the quality of your product and for giving developers a stake in your project.
Developers should have contact with users. A development staff that's treated like the guys in the basement who churn out code are never going to have a very enthusastic approach to the product or developing their own skills.
Embrace new technologies, even if it's only for a PoC or prototype of what the technologies can do. No developer in the world has ever been excited about churning out boilerplate code, and they never will be.
Let development teams own their process. Development methodolgies decreed from on-high will without fail demotivate the development team, who now need to deal with the added burden of planning meetings and waterfall development. Require that a process exist, but until there's a problem, keep your hands off the specifics.
"Just the way things work" is NEVER an excuse for a broken process. If developers have a legitimate concern with a process they need to follow, they need a honest chance to argue against it. As a manager, one of the worst things you can say is "That's the way the VP / Executive / CEO / God wants it, so we need to follow it". You need to champion your developers concerns, or failing that, allow them direct interaction with the person in question. If you as a manager are viewed as a sockpuppet for the executive, good luck ever motivating a developer again.
Shield your developers from all the politics to the best of your ability. Let them what they do best, develop software. Nothing kills a productive team like having to squabble in inner-office politics.
This well-known conversation says it best:
Peter Gibbons: Bob, I have eight
different bosses right now.
Bob Slydell: I beg your pardon?
Peter Gibbons: Eight bosses.
Bob Slydell: Eight?
Peter Gibbons: Eight, Bob. So that
means that when I make a mistake, I
have eight different people coming by
to tell me about it. That's my only
real motivation is not to be hassled,
that and the fear of losing my job.
But you know, Bob, that will only make
someone work just hard enough not to
get fired.
Hire the Right People
During the interview process ask questions that let you see their passionate about the craft.
Some examples, Do they:
Read software books or blogs, listen to podcasts?
Play with new languages/libraries at home?
Contribute to open source projects?
Once you have good people stay out of their way. Have the right amount of process, don't force unnecessary standardization, listen to issues, be honest about reasons things are happening.
Read Peopleware by DeMarco and Lister.
I've yet to meet a capable developer who is not already excited about making great software. The trick is to stay out of their way and not destroy the natural enthusiasm.
The Joel Test is a good start.
what can be done to encourage those
developers to become excited and
enthusiastic about software and
software development?
Nothing.
A passion for software development comes from within, and cannot be created from zero. Feeding an existing passion is easy- resources, training, and a visible appreciation for that passion from management are all it takes.
The only exception may be to lead by example. If you're excited, others may follow.
UPDATE: As has been said in other answers, it's much better to hire well up front. I'd pass over ten good programmers who just want a paycheck for one good programmer who codes in his/her spare time for fun.
ANOTHER UPDATE: This answer has been jumping around with up/downvotes, so let me clarify. The OP's wording specifically asks how to make an existing team excited "about software development". It is my contention that if they are not already interested in their chosen professions, there is not much an employer can do to engender an interest. A disinterested, unmotivated team will make a mess of the most fascinating project. By contrast, a motivated team of professionals that like their jobs can make the best darned calculator program out there, and enjoy every minute of it.
Having an interesting, challenging and profitable problem to solve, where all developers have a stake in the results. If not, you have a room full of developers sticking around as long as the pay checks clear.
I have to agree a little bit with the comment made by Pascal, but I'm not going to start off that way.
Overall, it has been proven that one of the best ways to give developers an environment that allows them to like their work is to give them freedom. However, your looking at a different route here, you are trying to find "passionate" developers.
To be 100% honest there is not a direct connection to "capable" and "passionate". There are hundreds of developers out there that are capable of being programmers, and mighty good ones at that. But many of them do not have any desire to become passionate developers.
To create a team of passionate developers, you really have to start with the recruitment process and HIRE passionate developers, not try to "create" them.
For me, the things that keep me motivated are:
A problem/task that I find challenging, that I can learn from
A plan to implement the solution in a way I think is reasonable. Nothing is more de-motivating for me than a management team that forces technologies I don't believe in down my throat.
Other folks to discuss the possible solutions with, be they on the same team or not.
A management team that appreciates the hard work I'm putting in.
Just to be precise, is the question "I have a team of developers, and I want to make those specific developers enthusiastic about software development", or simply "I want a team of enthusiastic software developers"? In the latter case, simply don't hire people who aren't enthusiastic.
In the former case, you're pretty much screwed. It's hard to change someone's personality so much that they start to care about something they didn't really take an interest in before. Of course it can be done, but let's face it. How many here have been unable to convince their better half that programming is interesting? For that matter, how many people have failed to adopt their girlfriend's enthusiasm for shopping, or shoes? ;)
Convincing people to share your interest and enthusiasm for something is hard work.
Unless you're willing to set aside a few years of your life for getting into the head of each individual developer, getting to know them and what makes them tick, and gradually push and prod them towards taking an interest in something that they previously simply considered a job, you're probably better off letting them go and hiring people who are motivated to begin with.
Give them interesting problems.
Give them the means to solve those problems.
Minimize the amount of crap they have to deal with that isn't directly related to solving those problems.
Reward them for successfully solving those problems. Don't underestimate the value of a sincere pat on the back from the guy who signs your paychecks.
Give them a stake in the larger venture -- beyond the next paycheck.
And when they suggest a new problem they think is worth solving, listen.
I think the biggest thing is the company has to value what the developers can do for the company. If the company is run by cheapskates who just see your developers as an expense they can't wait to be rid of then you are doomed. The developers' team needs to be viewed by management as a strategic asset that makes them money now and will make them more money in the future.
Also good communication in the company is vital. The developers have to be able to find out what it is the company needs them to do. Autocratic top-down bureaucracy and mushroom management can wreck morale and make it impossible for developers to add value, regardless of what level of enthusiasm they brought to the job. The software your team builds will be only as good as the communication in the company--I think that is what Conway's Law is about.
So that is a big challenge, in many cases an impossible one, because senior management will have their own ideas about priorities and communication and good luck influencing them. But the alternative is guerrilla development, where you're fighting an endless battle against your own company.
money, money, money... and don't say that money doesn't matter if the project is exciting or boring routine.
You don't.
You either have people in the team that love learning and always want to push themselves to be better, or you don't have those people in your team. Of course reality is, you'd have a mixed bag.
Just employ people who are enthusiastic (it's easy to tell), and don't employ the ones who see programming/developing software as 'just' a job.
It's impossible IMO to turn complete non-enthusiasts into passionate programmers. There is no silver bullet.
In Weinbergesqe fashion:
You've asked the wrong question. The right question is "What are the things that managers do that dispirit developers and reduce moral?" Then don't tolerate those things in your environment.
And oh by the way, you should already know the answer to that question. If you don't find another job.
Hookers and blow?
How about giving them a financial stake in the outcome of their software project(s)? For example, corporate profit sharing.
That being said, passionate developers are the kind of people who go home and write software in their spare time.
Going to a software development conference with good, inspirational speakers can make a huge difference.
Read "Dynamics of Software Development" by Jim McCarthy. Seriously, nearly the entire book deals with this and related issues.
Although I agree that it is not easy (or even possible) to create passion about programming, I think it is possible to keep passionate developers enthusiastic about their work. Even the most passionate programmer developer can become disillusioned if placed in a stagnant work environment.
So what can be done?
Provide plenty of opportunity for personal development, give lots of freedom to learn new things. Let the developers have some choice in the courses they take, and the conferences they wish to attend.
Toys - Not in the traditional sense, but being able to use the latest technologies
Provide a nice place to work. It doesn't have to be Google, but it does have to be somewhere you would want to spend time.
Of course money helps. Not in the sense that a company can pay for enthusiastic staff, but people need to feel suitable rewarded for their efforts.
I have found working in an organisation that has embraced agile development has many of the correct qualities for building enthusiastic teams.
If they're fundamentally unenthusiastic about software development, there's nothing you can do.
If they're enthusiastic, that's great, and you need to avoid squelching that. There are some excellent recommendations elsewhere in these answers.
If they used to be enthusiastic, and have had that beaten out of them, you are likely to get good results by giving them reasonable challenges, shielding them from bad management, and in general treating them like valuable and respected people.
If you have a room full of capable developers, what can be done to encourage those developers to become excited and enthusiastic about software and software development
The correct question is actually "What can be done to encourage those developers to become excited and enthusiastic about software and software development in our company".
It's quite simple actually. The answer has never been a secret. It's just nobody listens to it.
Very simply elements:
Let those enthusiastic developers work among other passionate people. Remove those who don't care from the team. Otherwise they will act like diseased cells proliferating apathy and depression to the other team members.
Aspire to develop a quality and professional product
Establish a professional and effective process
Trust and respect people. Value their knowledge. Respect their opinions. Actually, it's part of a bigger strategy: let your developers be able to make a difference and let them see they can really influence and change things.
Let them grow professionally and let them see this growth is appreciated and needed by you
Now what doesn't help at all.
Pay them badly. Developers are also humans (for the most part) and they also have their bills to pay.
Reject their initiatives, proposals and improvement suggestions. Tell them each time they come up with something that their attempt to introduce change make them a foreign und unwelcome element in the company.
Have low quality product and have no interest to make it better. Hacks, copy/paste code, accumulating technical debts, things falling apart after each release, that does not motivate developers.
Have badly run development and chaotic process. Tasks, projects and small decisions taking a new vector every few days will finally remove desire to be involved from anybody. Failing schedules because of unpredicted work load and feature set, they all go down the road. It will suffice to run out of coffee some day for some of them to start moving elsewhere.
Have a boring and uninteresting social environment. Developers having nobody to talk to to share their interests will finally feel dull. Not everyone is interested in taxes, football and kindergarten issues as the only topics on social gatherings.
I am inclinced to say nothing like others have, and i must agree that a real passion for it is not something you can create, it either exists or it does not however there are things you can do.
Scoring high on Joel's test is a great start,
Fire all the PHBs and hire smart managers who maximise the chances that the software will actually be finished and work right.
A management team that knows computers and can hold their own in a technical conversation is a very helpful feature. Don't try to sell passionate developers on hype, tends and buzzwords.
Set clear and stable goals and communicate the goals accurately to the team or people. And then just get out the way to let developers get that done. Do not go far away from developers though, you need to tackle those issues like out of free food, purchase of fancy office equipments and other trivial things that developers do not care to do yet useful to improve productivity and add perks to developer team.
Dan Pink notes 3 things that motivate people if there is creativity required in a job. RSA Animate - Drive: The surprising truth about what motivates us is a 10 minute video about these but here are the 3 things:
Autonomy - Give the team control over the schedule and empower them to own their work.
Mastery - How well are they developing their craft of building excellent software.
Purpose - Why are they making this software? What massive benefit will it have?
A few other sources on this stuff:
Top Three Motivators For Developers (Hint: not money!)
Autonomy, mastery, purpose
Empowered Teams Are Dead – Long Live Autonomy, Mastery and Purpose
Why Open Is Better Than Proprietary?
Money vs Autonomy/Mastery/Purpose
Creating an Organization that Values Autonomy, Mastery, Purpose
The 3 Things That Motivate Us
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In your “enterprise” work environment, how are engineers held accountable for performing code inspections and unit testing? What processes do you follow (formal methodology or custom process) to ensure the quality of your software? Do you or have you tried implementing a developer "signoff" sheet for deliverables?
Thanks in advance!
Update: I forgot to mention we are using Code Collaborator to perform our inspections. The problem is getting people to "get it" and buy into doing them outside of a core group of people. As stalbot pointed out below it is a cultural change but the question becomes, how do you change your culture to promote quality initiatives such as reviews/unit tests?
• Our company uses peer code reviews. We conduct them as Over-The-Shoulder reviews and invite the team’s tester to participate in the meeting to gain a better understanding of the changes. We use Source Control software that requires check-in, code-review rules to be signed off. Nothing big, just another developer's name that has reviewed the code.
• There are definite benefits to code review as several studies have been able to demonstrate. For our company, it was evident that code quality increased as the number of support calls decreased and the number of reported bugs decreased as well. NOTE: Some of the benefits here were the result of implementing Scrum and abandoning Waterfall. More on Scrum below.
• The benefits of code review can be a more stable product, more maintainable code as it applies to structure and coding standards, and it allows developers to focus more on new features rather than “fire-fighting” bugs, and other production issues. There really aren’t any drawbacks if code reviews are conducted “right”. More on the “right way” below.
• Some of the hurdles to overcome while implementing code reviews are the idea that “big brother” is watching me and the idea that not having perfect code means torture and pain. Getting developers to trust each other is difficult sometimes, especially when it involves “pecking order” or the “holier than thou” attitudes and putting your hard work under a microscope. Trust is the key to resolving these issues. A developer must trust that they will not be punished by peers or management for mistakes in code. It happens to everyone. Make a note of the issue, get it resolved and move on.
Scrum
One of the benefits of using the Scrum methodology is that a development cycle (”sprint”) is short. The time-frame of the “sprint” is determined by what works best for your organization and will need some trial and error, but really shouldn’t be longer than four week iterations. The benefit is that it requires the developers communicate daily and communicate problems early on in the project. This was initially adopted by our development department and has spread to all areas of our company as the benefits of scrum are far reaching. For more information, see: http://en.wikipedia.org/wiki/SCRUM or http://www.scrumalliance.org/ . As the development iterations are smaller, the code review process reviews smaller pieces of code, making the review more likely to find problems than hours or days of formal reviews.
“Right Way”
Code Reviews done the “right way” is completely subjective. However, I personally believe that they should be informal, over-the-shoulder reviews. All of the participants in a review should avoid personally attacking the person being reviewed with statements such as “why did you do it that way?” or “what were you thinking?” etc. These types of comments diminish the trust between peers, leading to animosity, hours of arguing over the best/right way to code a solution. Keep in mind that developers do not think or code exactly the same, and there are many solutions to a problem.
Just a little clarification on over-the-shoulder reviews; these can be conducted via remote desktop sharing (pick flavor here), or in person. However, they shouldn’t be limited to the developers only. We typically invite our entire scrum team which consists of two developers per team, a tester, a documentation person, and product owner. All non-developers are there to gain a better understanding of the changes or new functionality being made. They are free to ask questions or provide input, but not to make coding decisions or comments. This has been effective as certain questions will be asked that may change the direction of the project as the initial requirements may have missed a scenario, but that is what agile is all about, change.
Suggestion
I would highly recommend researching scrum and code reviews, before mandating them. Create the basic rules for each and implement them as part of your culture to achieve a better quality product. It must become part of your culture so that it is part of a natural process and integrated at all levels, as it is a paradigm shift from poor quality, missed deadlines and frustration to better quality products, less frustration, and more on-time deliverables.
If you want to ensure that every changelist gets reviewed, before checkin, then you could have your source control tool reject unreviewed checkins. For example, a trigger could reject checkins without "CodeReview: " in the checkin comment. Although people could still lie, they could also be held accountable.
If you want to ensure that every changelist gets reviewed, after checkin, then you could see if Code Collaborator will play nicely with your source control system and automatically make a review task after each checkin (push or pull; whatever works). After that, use whatever "polite annoyance" features Code Collaborator has, to make sure reviews actually get done.
If you want people to review only some checkins, not all checkins, then good luck with that.
We have a pretty cool setup. Coders are expected to test their code before check-ins to ensure that it doesn't break the build and to write tests where they make sense to have but high coverage isn't required.
Complex methods are expected to be commented.
At the end of phases code is reviewed by the whole team.
Pair programming. Work items have a required field of collaborator, the person that you paired with for the work
We lean heavily on ITIL concepts. While we don't need the full scale ITSM that ITIL provides, we have implemented processes that draw from some of the best practices in ITIL, specifically in the areas of Change Management and Release Management.
Code reviews are part of our RM strategy. As a change or new piece of code makes its way through our RM process, a lot of eyes look at it. Ultimately the Release Manager makes the call on approval or rework, and all of this is documented (we use TFS and SharePoint). Formal code reviews are held by the Release Manager and the technical team he selects. The primary developer for a release candidate is held accountable for adherence to standards, functionality, and a verification of a completed test plan. If the quality standards aren't met, the deliverable is rejected and the project schedule is updated to reflect the rework.
Yes, this is all very heavy. I work in government and we have complex laws to follow, specifically in the areas of taxes, ADA compliance, and so on.
We use three basic rules
1) The developer is responsible for fixing bugs in code when unit tests don't exist. In cases where there is a test, the person breaking the test is responsible for fixing it.
2) Code reviews. There are some code review smells that are a good warning sign, over defensiveness and blame redirection being the two most common.
3) NO EMAILING CODE, JARs or config files. Everything is in the scm.
To create the culture 1st try define your standards and values and most of all make them known.
Then hire people who believe in them or who could be able to adapt to them. Don't hire someone who does not have any connection at all with your company values.
Make sure that those who respect these values and show improvements are "rewarded" and "properly" recognized and seen as models. Don't forget that for many is not all about the money.
Don't hesitate to take appropriate measures againts those who do not fulfill their responsibilities but make sure they know them. And have them accountable for their deeds.
Allow people to become used with any new responsibility.
To make change in culture is big deal. Still there are some ways to change.
Create awareness about code review and importance of code review tool. It can be done using training session.
Motivate the people : Giving some reward for the code reviews.
Change in process : Make sure that code review should be happen and properly. It can be done using checklist and part of release process.
Do not try to change completely. Slowly introduce newer changes. Create small group to observe and discuss the change in code review process.
Provide the solution instead of create problem. Process should not be overhead. It comes automatically. Provide solutions to peoples problem related to the process.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How can our team gather requirements from our "Product Owner" in as low friction yet useable of a way as possible?
Now here's the guidelines- No posts that it can't be done or that the business needs to make a decision that it cares about quality, yada yada. The product I work for is a small group that has been successful for years. I just want to help them step it up a notch.
Basically, I'm on a 6 or 7 person team with one Product Owner. She does a great job but is juggling a few different roles (as I believe is common on extremely small teams). Usually requirements are given at sporadic times (email convos, face to face discussions, meetings, etc). They are never entered into a system and sometimes this results in features missing a release or the release getting pushed back since everyone forgot about the necessary feature.
If you're in a similar situation but you found a way to overcome this, I'd love to hear it. I'm happy to write code to help ease this situation but it can't be a web site that the Product Owner has to go to in order to get anything done. She is extremely busy and we need some way of working together as a team in order to gather these requirements.
I'm currently thinking of something like this: Developers and team members gather requirements discussed in face to face meetings and write some quick notes on the features discussed on a wiki page. Product owner is notified whenever these pages are updated and it then becomes her responsibility to ensure accuracy.
Pros: We'll have some record of the features. Cons: The developers are taking responsibility for something that they ordinarily wouldn't. I'm okay with that here. I think in this situation it's teamwork.
Of course once we do this, then we're going to see that the product owner probably doesn't have enough time to ensure feature accuracy. Ultimately she is overburdened and I think this will help showcase that fact, but I just need to be able to draw attention to that first.
So any suggestions?
P.S. her time is extremely limited so it is considered unreasonable to expect her to need to type in the requirements after discussion. She only has time to discuss them once and move on.
Although the concept of "product owner" is a littl ambiguous to me, I think I am working in very similar circumstances: the customer is extremely buzy and always is a bottleneck in developing requirements.
On the surface, what we try to do in this situation is quite obvious and seemingly simple: we try to make sure that the customer is involved in "read-only / talk-only" mode. No writing. Minimum reading. Mostly talking.
The devil, of course, is in details. So, here are some specifics about our process (in no particular order):
We often start from recording problem statements, which are the ultimate sources of requirements. In fact, sometimes a problem statement is all that we record initially, just to make sure it does not get lost.
NB: It is important to distinguish problem statements from requirements. Although a problem statement sometimes clearly implies some requirement, in general a single problem statement may yield a whole bunch of requirements (each having its own severity and priority); moreover, sometimes a given requirement my define a solution (usually just a partial one) to multiple problems.
One of the main reasons of recording problem statements (and this is very relevant to your question!) is that semantically they are somewhat "closer to the customer's skin" and more stable than requirements derived from them. I believe those problem statements make it much easier and quicker to put the customer into proper context whenever he has time to provide feedback to the development team.
We do record all the requirements (and back-track them to problem statements), regardless of when are we going to implement them. Priorities govern the order in which requirements get implemented. Of course, they also govern the order in which customer reviews unfinished requirements.
NB: A single fat document containing all requirements is an absolute no-no! All the requirements are placed in "problem tracking database", along with bug reports. (A bug is just a special case of a problem in our book.)
We always try to do our best to minimize the number of iterations necessary to "finalize" each requirement (or a group of related requirements). Ideally, a customer should have to review a requirement only once.
Whenever the first review turns out to be insufficient (happens all the time), and the requirement in question is complex enough to require a lot of text and/or illustrations, we make sure that the customer does not have to re-read everything from scratch. All the important changes/additions/deletions since the previous reviwed version are highlighted.
While a problem or requirement remains in an unfinished state, all the open issues (mostly questions to customer) are embedded into the document and highlighted. As a result, whenever the customer has time to review requirements, he does not have to call a meeting and solicit questions from the team; instead the customer can open any unfinished document first, see what exactly is expected from him, and then decide what's the best way and time (for him) to address any of the open issues. Sometimes the customer chooses to write a email or add a comment directly to the problem document.
We try our best to establish and maintain official domain vocabulary (even if it gets scattered across the documentation). Most importantly, we practically force the customer to stick to that vocabulary.
NB: This is one of the most difficult parts of the process, and customer tries to "rebel" from time to time. However, at the end of the day everybody agrees that it is the only way to make precious meetings with the customer as efficient as possible. If you ever attended one-hour meetings where 30 minutes were being spent just to get everybody on the same page (again), I'm sure you would appreciate having a vocabulary.
NB: Whenever possible, any changes in the official vocabulary get reflected in the very next release of the software.
Sometimes, a given problem can be solved in multiple ways, and the right choice is not obvious without consulting with the customer. It means that there will be a "menu of requirements" for the customer to pick from. We document such "menus", not just the finally chosen requirement.
This may seem controversial and look like an unnecessary overhead. However, this approach saves a lot of time whenever the customer (usually few weeks or months down the road) suddenly jumps in with a question like "why the heck did we do it this way and not that way?" Also, it is not such a big deal to hide "rejected branches" using proper organization/formatting of requirements documentation. Boring but doable. :-)
NB: When preparing "menus of requirements", it is very important not to overdo them. Too many choices or too many choice nesting levels - and the next review may require much more customer's time than really necessary. Needless to say that the time spent on elaborated branches may be totally wasted. Yes, it is difficult to find some balance here (it greatly depends on the always-in-a-hurry customer's ability to think two or more steps ahead and do it quickly). But, what can I say? If you really want to do your job well, I am sure that after some time you will find the right balance. :-)
Our customer is a very "visual" guy. Therefore, whenever we discuss any significant user interface elements, screen mockups (or even lightweight prototypes) often are extremely helpful. Real time savers sometimes!
NB: We do screen mockups exclusively for the customer, only in order to facilitate discussions. They may be used by developers too, but in no way do they substitute user interface specifications! More often than not, there are some very important UI details that get specified in writing (now - primarily for developers).
We are lucky enough to have a customer with a very technical background. So we do not hesitate to use UML diagrams as discussion aid. All kinds of UML diagrams - as long as they help customer to get into proper context quicker and stay there.
I am talking about requirements-level UML diagrams, of course. Not about implementation-level ones. I believe that even not very technical people can start digging requirements-level UML diagrams sooner or later; you just have to be patient and know what to put on a diagram.
Obviously, the cost of such process greatly depends on analytical and writing skills of the team, and of course on the tools that you have at your disposal. And I must admit that in our case this process appears to be quite expensive and slow. But, taking into account the very low rate of bugs and low rate of "vapor-features"... I think, in the long run, we get very good payback.
FWIW: According to Joel's nice classification of software products, this project is an "internal" one. So we can afford to be as agile as our customer can handle. :-)
"Developers and team members gather requirements discussed in face to face meetings and write some quick notes"
Start with that. If you aren't taking notes, just make one small change. Take Notes. Later, you might post them to a wiki or create a feature backlog or start using Scrum or bugzilla or something.
First, however, make small changes. Write stuff down sounds like something you're not doing, so just do that and see what improves and what you can do next. Be Agile. Work Incrementally.
You might want to be careful of the HiPPO in the room. The Highest Paid Person's Opinion is not always a good one. We've tended to focus more on providing great tools and support for developers. These things, done right, take some of the hassle out of development, so that it becomes faster and more fun. Developers are then more flexible in terms of their workload, and more amenable to late-breaking changes.
One-Click testing and deployment are a couple of good ones to start with; make sure every developer can run up their own software stack in a few seconds and try out ideas directly. Developers are then able to make revisions quickly or run down side paths they find interesting, and these paths are often the most successful. And by successful I mean measured success based on real metrics gathered right in the system and made readily available to all concerned. The owner is then able to set the metrics, which they probably care about, rather than the requirements, which they either don't care about or have no experience in defining.
Of course it depends on the owner and your particular situation, but we've found that metrics are easier to discuss than requirements, and that developers are pretty good at interpreting them too. A typical problem might be that customers seem to spend a long time filling their shopping carts but don't go on to checkout.
1) A marketing requirement might be to make the checkout button bigger and redder. 2) The CEO's requirement might be to take the customer straight to checkout, as the CEO only ever buys one item at a time anyway. 3) The UI designer's requirement might be to place a second checkout button at the top of the cart as well as the existing one at the bottom. 4) The developer's requirement might be some Web 2.0 AJAX widget that follows the mouse pointer around the screen. Who's right?
Who cares... the customer probably saw the ridiculous cost of delivery and ran away. But redefine the problem as a metric, instead of a requirement, and suddenly the developer becomes interested. The developer doesn't have to do 10 rounds with the CMO on what shade of red the button should be. He can play with his Web 2.0 thing all week, and then rush off the other 3 solutions on Monday morning. Each one gets deployed live for 48 hours and the cart-to-checkout rate gets measured and reported instantly. None of it makes any difference, but the developer got to do their job and the business shifts it's focus onto the crappy products they sell and the price they gauge on delivery.
Well, ok, so the example is contrived. There's a lot of work in there to make sure that the project is small, the team is experienced, hot deployment is simple, instant rollback is provided, and that everyone's on board. What we wanted to get to is a state where the developer's full potential is not wasted, so that's why they're involved not just from the start, but also in the success. Start out with an issue like the number of clicks during registration is too high, run it through a design committee, and we found that the number of clicks actually went up in the design specification. That was our experience anyway. But leave the developer some freedom to just reduce the number of clicks and you might actually end up with a patented solution, as we did. Not that the developer cares about patents, but it had merit - and no clicks!