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
If everything in scrum is all about functional things that a user can see is there really any place for refactoring code unrelated to any new functional requirements?
I don't think that this has as much to do with Scrum as it does with project management philosophy.
Regardless of whether a project uses Scrum or not, many project managers do not like developers spending time on "unnecessary" things like code refactoring or restructuring that doesn't directly advance one of the outstanding functional requirements. It's not "work that yields results" like normal development, it's "work that prevents a delay of results later". Given the typically short time-lines used for Sprints, the benefit is often hard to see and nearly impossible to quantify.
Keeping code maintainable needs to be an item on your burn-down list (if you use a Scrum). It is just as important as new development. While it may not seem like something that is "visible to the user", ignoring it increases your technical debt. Down the road when the technical debt piles up enough that your code's lack of maintainability slows down development, the delays in new feature development will be visible to customers.
It's all a matter of management/philosophy. Instead of looking at refactoring and maintainability enhancements as "extra" work that doesn't impact customers, it should be viewed as a time investment to prevent customer-visible delays (and potentially bugs as well) down the road. Developers can sometimes see these benefits more clearly than managers can; if your manager doesn't understand the disadvantages of neglecting maintainability, you might want to grab several other developers and have a chat with your manager.
I think there is a fair case to make for technical debt refactoring where the effort/cost impact of maintaining the code is as high as, or higher even, than the cost of refactoring it to improve quality or work better / properly - specifically to lend it a higher degree of maintainability.
eg: if the software is so problematic you are losing customers, or money, you'd act fast to fix it.. Some might argue this is a business requirement of it's own, but it's often not placed front and centre on small to mid sized development projects, which instead focus on the technicalities of creating apps rather than the impact of the quality of the app on the bottom line.
I think you are probably talking about large scale refactoring rather than the continuous refactoring you would do whilst in the whole red-green-refactor cycle.
My approach would be something like this, if reafactoring an old feature makes it easier to add a new feature then go ahead and do it. But in some ways you are right, if there is no pressure on a particular unit to change (i.e. it is completely finished and will never change again and will never impact on other modules) then there is no practical need to refactor. However I rarely find a module that is quite so finalised.
If everything in Scrum is all about functional things that a user can see (...)
Any project and methodology should be about generating business value, you rarely do things just for the fun in a business environment. Having that said, I see quality in Scrum (and other Agile methods) as a way to not kill your velocity on the long run and, ultimately to achieve hyper productivity. I thus believe that a typical "Definition of Done" should include something like "no increase of technical debt" (put your quality standards in there). If you think a new feature will impact existing code that should be refactored, include this cost in the estimate (or create a refactoring item in your Product Backlog) and explain things to your Product Owner. Because at the end, it's up to the Product Owner to prioritize items and to decide if quality can be sacrificed temporarily (if your business die because you don't release a feature, what is the point of refactoring existing code?). But he must be aware that this can't be a long term strategy or he will kill the team velocity.
bta: Regardless of whether a project uses Scrum or not, many project managers do not like developers spending time on "unnecessary" things like code refactoring or restructuring that doesn't directly advance one of the outstanding functional requirements.
Definitely a noteworthy observation; my solution to this would be as follows:
Perform regular code reviews. Every code review should recommend actions to improve on deficiencies in the code.
There is now a requirement for jobs which improve code quality. Build these into the sprint and track them in the same way as any other job.
If your manager needs any more convincing, cast 'the maintainer' as a user, and describe some user stories for them - and then 'features' are things like 'the code is fully commented with xml doc comments' and 'the code does not produce any warnings from ReSharper'
If you can justify it as part of the process of completing other tasks by identifying issues/risks with current sets of code, and it is a better end result, go for it. But don't get overzealous and screw the timelines/budget.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I work at a small service based company where we are starting to implement Scrum practices, and we are also starting to use JIRA with greenhopper for issue tracking. Our team has defined "done" as:
coded
unit tested
integration tested
peer reviewed
qa tested
documentation updated
I'm trying to figure out whether this should be done using a separate issue for each item in the above list for each "task", or if some of these items should be implemented in the ticket workflow, or if simply lumping them together in one issue is the best approach.
I'm disinclined to make these subtasks of a task, as there is only one-level nesting of issues and I fear there is a better use for that capability.
I also am not too excited about modifying the workflow, as this approach has proved to be a burden for us in other systems.
If all of these items are part of the same ticket then that seems weird to me because the work is likely spread between multiple team members, and it'll be hard to make tasks that are under 16 hours that include all of those things.
I feel like I understand all of the issues, but as of yet I don't know what the best solution is.
Is there a best practice? Or some strong opinions?
Done is done - it has to be all those things you defined, however treating them as steps explicitly with a bug tracker can have the undesired side effect of encouraging divisions within then team and throwing stuff over the wall. So coders would claim they are done once ticket is marked "coded" and "unit tested", testers when marked tested etc.
This is exactly the opposite of what Scrum intends to do - the whole team commits to doing the stories so that they meet the definition of done in the end. So even though some of the elements of achieving done are indeed steps one should be very careful with solidifying these steps in any kind of defined workflow.
(This btw shows nicely why using a bug tracker as a scrum tool is a bad idea. Those are different tools that should be optimized for different things - even if linked together through some APIs.)
I certainly wouldn't nest them, since they are steps common to each task. Making them subtasks would just increase the complexity and boilerplate of the system. These seem like perfect workflow stages to me.
Something like Submitted->Assigned->Coding->Review->Testing->Finished.
Where Coding requires "coded", "unit tested", and "integration tested" before moving to Review, Review requires Peer Review before moving to Testing, Testing requires QA Testing before moving to Finished.
The only reason this would be tricky is if you're allowing Peer Review and Testing to be done in parallel. I see problems with allowing that, since if the code fails peer review and is subsequently changed it invalidates the testing work done by QA.
coded
unit tested
IMHO these belong together, as both should be handled by the same person (preferably TDD, which really makes it impossible to separate these).
integration tested
In our team, this is usually done by the same developer, so we typically do it as part of the above task. Other teams may do it differently.
commented
Do you mean code comments? Then, to me, this does not deserve a separate task. Otherwise, please clarify.
peer reviewed
A separate task for a separate developer (or more).
qa tested
A separate task for testers / QA personnel.
I would add documentation - it may not always be needed, but often is. Again, it should be a separate task, typically for the same guy who did the implementation (but not always).
One prime concern to practically all the Scrum teams I have been working with so far is to make sure that nothing important is forgotten from the above. Partitioning into distinct tasks may help this. Then you can clearly see in your backlog what's left to do. Lumping all of these into one task makes it easy to forget about this or that little detail. For us, it was most typical to forget about code review and documentation, that was the main reason why we turned these into independent tasks.
Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the definition of “done” does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration.
Reference: Scrum Guide - Written by Ken Schwaber and Jeff Sutherland (Inventors of Scrum)
You state that you are following "Scrum Practices". It sounds to me like you are just using a few parts of the Scrum Framework and not others, is that true? First of all, Scrum is not necessarily a practice, it is a Framework, you either use the framework or you don't. It works on the basis of inspect and adapt, so apart from the basic Scrum framework rules, nothing is set in stone, so you won't get an exact answer to your question. The best way to know the answer is hire experienced Scrum Professionals, and Experienced Developers and Testers and try the above done plan in your Scrum Team.
Remember always Inspect and Adapt. There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable.
Do not spend loads of time documenting or looking for a solution to a given Process problem because most of the time the problems change faster than you would realize, it is just better to inspect and adapt provided you have at least the basic knowledge of scrum and you are using the Scrum framework and not just a few Scrum like practices.
We use a pretty similar system in JIRA and I have an open question here and on the Atlassian boards asking a very similar question. We have a similar definition of done. We create the main story in descriptive form i.e. "The legend text on the profit and loss graph overlaps". We then define sub-tasks which are either of type 'technical' or 'process'. Technical tasks are the actual work of implementing the story "Research possible causes on vendor site", "Implement fix in the infographic class". Process items include 'Peer Review', 'Make Build', 'QA Testing', 'Merge'. As one comment noted you may have QA going on before/during Peer Review. As a part of the Scrum process we have QA going on nearly all of the time (they are part of the team) sometimes they sit with the developer, sometimes they get 'bootleg builds' to run in a test environment. This is exploratory testing and is considered part of the coding process to us. The sub-task for 'QA Testing' is for integration and regression testing and is a final validation of the whole story after Peer Review is completed. By that time the QA team already has a complete test plan they worked up during exploratory testing and it's typically just a matter of running through the plan and 'checking it off'.
We've gotten to this point after running sprints for a year and making changes during the retrospective. I'm open to suggestions as I think one of the downsides to the retrospective is that you can group-think yourself in one direction with little hope of ever backing all the way out and considering a different path.
We use two boards for this purpose. We have one board for the Development Sprint where "Done" is Ready for Testing. You can't enter a sprint unless you're well and truly ready to start development (all analysis done, estimates done, people know what they are supposed to be doing - all the conversations have been had, shall we say, though our conversations tend to take place in JIRA Comments given the distributed team) ... and you exit when you finish development. That's the best way to track whether our development team is meeting their own goals without being impacted by QA. Meanwhile, QA uses a Kanban style board and they go from "Ready for Testing" (this is their "to-do"), through In Testing to Ready for Release.
We switched to this because we previously had all these steps in a single board, and we weren't "meeting our commitments" within any sprints because there was no way to both develop & test all in a single sprint, where we have to do a code migration to the QA environment for final testing to occur, although testing is happening all along the way. We are still trying to figure out how to do things correctly, so this may not be the right answer, and yet it sounds like it's not something you've thought of, so maybe it would work for you.
and it'll be hard to make tasks that are under 16 hours that include all of those things.
This is your real issue; ability to break down stories into small useful vertical slices of functionality. Working on this will make your team more agile and give the PO more flexibility.
To the contrary, breaking down the work by process/mechanical step will only make you less agile and really serves no useful purpose. Either you are done or you aren't; no one cares if you are dev complete and not tested so don't bother tracking it by the hour....its waste.
Refocus on your stories, not on tasks.
We use subtasks.
Given that the story is a shared item (the whole scrum team works on it), we use the subtasks as 'the post-it notes' allowing to track tasks which individuals need to tackle.
We don't require that every little piece of task is represented as a subtask.
We are not bookkeepers, but developers.
The team agreement is that if you can't take up a task immediately, just jot it down as a subtask to the story. (Using the agile plugin, it is really easy). ie. we will never have systematically a subtask 'create unit test', but in some occassions, when someone is struggling to get that dynamock up and running, you will see this subtask popup in the story. Having it there allows the team to discuss it during the scrum.
If you want to generate the checklist automatically, look at the create subtask on transition plugin.
https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition
It allows you to automatically add the subtasks when the story has been committed.
BTW - JIRA is more than a bug tracker. We are using it in a wide variety of applications,
including the management of our sprint activity. (as an Atlassian partner, I'm biased :-).
Francis
Important thing is that you use sub-task as real task; not as activity of main task. Issue tracker is primarily meant for what you are doing; not how you are doing and in what order.
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
How can you stop the dev team from padding their numbers when it comes to creating task times? How is there any motivation for them to do their work if there are no real deadlines and they are just measured against their velocity.
Get the job done by this deadline
vs
Get the job done whenever we will reduce scope, quality or increase resources
The foundation of most agile methods is trust. If you don't trust your team, why have you hired them in the first place? If you think they are not up to the task, it is better not to start the project because it is almost surely doomed to failure - either because you are right and the team is a bunch of inept developer,s or because you are wrong but your lack of trust and overcontrolling suffocates the team and actually saps their commitment and enthusiasm.
OTOH if you are sure that you have hired the best guys available, and that they are talented and motivated, the best is to give them a good challenge, let them work and try to remove all obstacles from their way.
In my experience most developers start out enthusiastic and motivated to create products they can be proud of. However, impossible deadlines, irrealistic expectations, too much bureaucracy, overcontrolling management - and last but not least, reducing quality - can quickly kill that motivation.
The point of agile methods is that developers are the right people to know / estimate the cost of a specific feature. If management insists on estimating both the resources, scope and time allotted to the project, it almost always results in disaster. If OTOH the developers are given trust and responsibility, they will usually live up to the task. In Scrum, the team together works out the estimates and fights problems / issues coming up during the sprint. In a good projects, team members quickly gel with the team and they feel personal responsibility for the project. This can go as far as poking laggard members to produce results instead of pulling the team back.
In my experience, developers pad numbers due to uncertainty. Are your product owners clear in their business requirements? Are the stories sufficiently small to estimate against?
Your 2 choices indicate to me that you have a fundamental misunderstanding of Scrum. The promise of Scrum is not getting the same result, just faster. It is the ability to iterate quickly, respond to feedback and alter course. The foundation of Scrum is the self running team. If you don't have teams you trust, Scrum probably isn't for your organization.
As Péter said in his response, team motivation is key and the quickest way to kill that is to undermine them. If the team feels management doesn't support or believe in them they will have no reason to make aggressive estimates and will simply cover their own butts. It's your job as a manager to help them succeed.
Additionally, the agile methodologies promote responsibilities to the peer. You shouldn't have just one person estimating items. Make it a group thing, and make sure (mostly) everyone agrees to the estimate. If you have your whole team colluding against you to pad estimates, you have a lot more problems than you think.
Besides, there's a lot of opportunity to pad estimates and make excuses in traditional waterfall / BDUF (big design up front) effort. I would say that scrum, with the daily scrum meetings, helps to contain this more than it helps to promote it.
I wrote a blog post a while back on estimation anti-patterns. It's a funny read but sadly all of the patterns are things I've either seen done or heard of from colleagues. We've gone through about 3 of them on our current project; I don't think there's any team which manages to avoid all of them entirely!
http://lizkeogh.com/2009/11/30/estimation-anti-patterns/
Also have a look into systems thinking, game theory and perverse incentives. If the devs are padding the estimates it's because the environment they're working in is encouraging them to do so. Changing that environment will help them.
Good answers on this one already. Basically, if you assume developers will cheat on you by reporting hours they didn't in fact work (but spent playing whichever MMORPG is now en vogue) why you even work with them in the first place? And if you trust them, why you think they "pad"?
BTW - it is completely normal for teams that are new to Scrum to first overestimate (and have to drop items from Sprint), then - getting thus burned - underestimate to avoid that happening to them again, then as others have pointed out team velocity will level out and people will have a better understanding of how much they can do within a sprint.
One more hint as to what you can do: don't question their hours, don't try to "manage" them by telling them how much time this or that should take. Rather, ask them how they want to achieve this or that, what solutions they want to use and why? It is quite common with good geeks that they tend to over engineer - if things look way bigger than you expected probably there is a misunderstanding here about what is being built that needs to be cleared.
It is actually quite impossible to "pad" estimates in scrum. After a few sprints the velocity will average out and the team will "know" how many points it can commit to. There is nothing to pad.
I think you have your statements backwards because
Get the job done whenever we will reduce scope, quality or increase resources
is an exact description of Waterfall; not scrum. In scrum we have deadlines, it is called the end of the sprint. In scrum we NEVER sacrifice quality because we know that will cost us more in the long run. In scrum we don't add resources because we know that people gel and form a "team" and upsetting that balance is detrimental to productivity.
Why are you bothering at all with task times? The only time I have seen good developers pad estimates is if they are forced into giving an estimate for an unknown feature. We don't do this in scrum. We know what the conditions of acceptance of a feature is before we commit to it.
One approach to avoid this situation entirely is to estimate in story points, i.e. ask the question "does this story require more or less work compared to that story?".
In my experience developers rarely pad their estimates. The general tendency of developers is actually to underestimate complexity and effort.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
My organization has been experimenting with the introduction of more "Agile" methods. We've been trying the Scrum approach for a short while, and most of the team has, more or less, adapted to it. I like it as a whole, but I'm concerned about one potentially severe impact of the methodology: as teams are consistently focused on features and backlog items, and testers are more integrated with the overall development process, it seems like skill sets are becoming blurred, and people are sensing less respect for their individual abilities.
Some of our developers are excellent at server-side technologies and optimization of heavy-weight data provisioning. Others have invested a large amount of their careers learning GUI technologies and have developed a fundamental understanding of users and usability in an application. Neither skill set is better than the other, but they are certainly different.
Is this an inevitable result of the Scrum process? Since everyone on the team (as I understand it) contributes to satisfying the next feature/requirement, backlog item, or testing goal at hand, the underlying philosophy seems to be "anyone can do it." This is, in my experience, simply not true. Most engineers (developers, testers, etc.) have a particular skill set they have honed over the years, and the Scrum methodology, in my mind, tends to devalue those very abilities they were previously respected for.
Here's an example for clarification:
If a sudden change of technology occurs on the server-side data provisioning, and every item on the to-do list for the sprint is based on this new change, the GUI developers (who likely haven't had time to become acclimated with the new technology) might not be able to contribute to the sprint. At the very least, they will need to invest time to get ramped up, and then their code will be suspect because of their lack of experience.
I understand the need for rapid development to discourage "role silos" but doesn't this discount one fundamental reality: people develop skills in accordance to necessity, their interests, or their experiences. People seem to be less motivated when they perceive their position is one of "plug-ability" (e.g. we can "plug" anyone in to do this particular task). How does Scrum address this? If it doesn't, has anyone addressed this when adopting the Scrum methodology?
The short answer is an emphatic NO! Scrum does not blur or depreciate the skills required for specialization. Scrum does not promote generalization.
The long answer is that in Scrum, the most important thing is to get the work "Done". The team, as a team (as opposed to a collection of individual "stars") collaborate, as needed, in order to get the job done. Whatever it takes - however they want (Scrum is about self managing, self motivating teams, right?).
What this means is that a scrum team may be composed of several specialists, who primarily do what they specialized in (DBA, Graphic Design, even technical writers). The team, as a whole, should have all of the skills required to fulfill the requirements. This is not the same as saying that each team member has to have all of the skills aforementioned.
That being said, it is often desired - often by the members themselves - that members other than the specialists be at least adequate in skills different from their specialty. Another poster already mentioned Scott Ambler's "General Specialist". This helps the team when there's too much work of one kind, when the specialist is absent, and it helps the member when he really would like to gain experience outside his specialty.
Given that the team is self organizing, if for some reason a specialist finds himself in the middle of the sprint, without any work to do in his specialty, the best way to deal with it, is to simply ask the specialist what he wants to do. Let the team decide. The specialist can decide to help in his other areas of adequacy, do a POC for the next sprint, "shore-up" the defenses by fixing some long forgotten technical debt, or shine the shoes of the members who are working.
Yup. I don't know if this is the long answer. But it definitely was a long answer.
:-)
The point of Scrum is for the developers to self-organize. We use scrum where I am, and jobs get passively sorted by a person's focus. We don't do it on purpose with a chart and list, it just happens. We all know who's best at what, or what their main/secondary focuses are. If the 'main' person needs help, they get the person/people with a secondary focus in it to help. We do get plenty of tasks not necessarily in line with whatever our particular focus is, but you always know who to ask for help then.
For your example - I don't know that if you say had 3 server guys and 5 gui guys, that you'd expect to get all the work done in that sprint (if the server guys + some help from the others wasn't enough). The way the sprint is supposed to work is that from a prioritized list, the developers pick what they think they can get done in that 30-day timeframe. If that meant the GUI guys needed 2 days of server-side training in order to help, that's what it'd mean. Unless there were concurrent things also high up the list that they could do instead. The sprint tasks are not supposed to be dictated by management as a psuedo-deadline.
If you have a Safari account, there's an interesting mostly case-study book by one of the guy/s who invented scrum.
I've been working as a ScrumMaster for about 18 months and have worked with two different teams. I initially expected to experience the potential issues you raise but this has not been the case. What I generally observe is that the team evolves into a mixture of specialists and generalists as people find the appropriate role for themselves - one that they can enjoy and be successful at. This is self-organisation at work. I have never had a case where our specialists were sitting idle.
If this did occur, I would expect it to be raised as an issue in Sprint Retrospective and the team would discuss how to improve the situation. The most obvious (and brutal) conclusion would be to change the team composition.
I am not sure why skill set will get blurred. There is a fair amount of confusion in the agile world. Scrum is a project management process and not a software development process and should not be seen as one. The engineers have to follow their own methodologies like TDD or extreme programming to add their own part to being agile.
Nothing goes away in scrum.
PM's still document as they go
Architects still architect their components. The only thing is they just delay some major decisions to more responsible point in time.
Developers should still follow best practices such as SOLID principles to enable for refactoring in a consistent manner as features change.
I think Scott Ambler addresses this issue very thoroughly in http://www.agilemodeling.com/essays/generalizingSpecialists.htm...
His concept of a Generalizing Specialist is exactly the thing Collective Ownership / Scrum Team calls for, and makes total sense to me.
Its hard to achieve in real life though ;-)
If you find for any reason ('sudden change of technology' or not) that the amount of work required for a system over a sprint is greater than the amount available then there's a problem with your scheduling.
One fix is that, as you suggest, you take programmers from other areas and throw them onto the mix. How well this works depends on the skills of that person and how different the problem domain is, but treating programmers as generic units that can be farmed out as needed is generally not a successful strategy for developing software.
This is still a scheduling problem though.
The best thing about Scrum is exactly the fact that skills do get a bit blurred! The point is to avoid silos at all costs by spreading specialist knowledge across the team and letting people work a bit outside their comfort zone.
Obviously this is not for everybody. Some developers are happy in their own narrow specialist field and such people are more of a hindrance in a Scrum process than an asset, whereas well-rounded and multi-talented people who are determined to get the job done, usually adapt very very well to it and are far more productive.
One of the key benefits of Scrum is to get the whole team actually involved and invested into the project instead of tackling their own special tasks and then riding off to the horizon. I'd claim that for most people, this is a far more rewarding way of working than the conveyor belt -approach of waterfall processes.
So I'd advise to boldly embrace the mixing of skills and having people come together to take down nasty problems instead of relying on specialist silos. The result of teams consisting of motivated people can be surprising.
Sounds like this would lead to more well-rounded developers, and also allow those who are experts in certain areas to continue to contribute their expertise.
I haven't used Scrum much myself (yet), but from your description, these types of teams would lead to a team/organization that is also more well-rounded as a whole - and shouldn't that be the goal of any team?
Handling sudden changes is part of Agile and this may mean that some people have to go off and learn new skills. Course this is more within the general Agile philosophy than anything Scrum-specific. There may be some extreme cases where the customer or business decides to change the world by bringing in something new and thus has to handle the subsequent pain of those people ramping up but if this is what they want and the developers are overruled, then there are only a couple of choices: (Take your lumps and try to handle the major changes) or (quit and get out of there).
While there can be some cases where someone that has specialized in something may be able to do things faster, this doesn't necessarily mean much if that is just one person on the team that is an expert and there is enough work in that area for 10 people for the whole sprint. Should those not an expert simply not do that work and let that one person attempt to get through as much as he or she can? I don't think so but there should be something to be said for those that aren't the best at something still trying to get done what they can get done.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
When first approaching a project is best to step back and think through everything or just dive in and start coding and polish at a later date? Essentially, do you design first or try to rapidly prototype?
I have been burned by both methods, sometimes I try and think everything through but when I actually get down to the nitty gritty I encounter problems that I didn't take in consideration, and sometimes when I code first I end with code that needs to redone to fit in with a better overall design. Alot of my problems stem from inexperience, but any advice is welcome.
Go incrementally and iteratively.
Design a bit, implement a bit.
Starting with a design you can suffer from a tunnel effect where you cannot have any real feedback before you actually implement something.
Starting without design, you can take decisions you'll regret.
The ideal situation is to be able to implement a very skeletal end-to-end version of your system that can be tested, and demonstrated to the customer.
It is always safer to design first, but this does not mean prototyping does not work. The real problem with prototyping is resisting the urge to keep the code you already wrote instead of throwing it away when the time comes to do the design.
There is no silver bullet. It seems like design first is the preferred approach. But you will not be able to predict all complications that can arise while implementing your design. Some of them could potentially be show stoppers. Plus, if you're writing for a client, it's good to be able to show something just to make sure that you're on the same page.
At my workplace we do both - we do a rapid prototype, just to get feedback and get an idea of any potential problems. Then we do a formal design and formal implementation. In most cases we are able to salvage a lot of code from the prototyping stage. I like this approach, since we usually end up with clean, maintainable code.
See Gall's Law. The key is to iterate: design a little, implement a little, test a little, then repeat until you (or your customers) are satisfied. This is the essence of the new breed of "agile" methodologies.
It depends.
Prototyping is most useful when the requirements or a solution aren't necessarily clear. As an example, I am doing a data warehousing project in an environment (large commercial insurance) where financial reconciliation is a big deal. This project has involved a large prototyping exercise to get a system that will reconcile to the financials. As the business rules surrounding this were not well documented, the prototype was instrumental in exposing all of the corner cases.
In other cases, a design-first approach might be more appropriate. This is most applicable where requirements and a sensible solution architecture are reasonably obvious.
You must have some idea of a cohesive architecture before you start working. This is especially true of large scale systems.
Prototyping could be used for particular aspects of the design, e.g. presentation layer.
I think it depends on what kind of business requirements you have up-front. If they are (relatively) detailed and complete, then I'd design based on those requirements. If you have barely anything to work with in the beginning, then prototype out and show your customer what you got, to receive further requirement info.
You should develop using Agile Methodologies. Simply put, you design has you go. The team together with the product owner define a list of topics to develop, order them by importance, and split the development in iterations. Each iteration as features to be developed and on the start of the iteration is design each feature.
See more here.
When first approaching a project, prototype. But don't prototype everything. Prototype one important thing (one "use case" if that means anything) and "turn the inner eye to follow its path" - keep an eye out for the practical problems you encounter in trying to get that one thing done.
Now that you have some idea what it takes to do an important thing, you can design from more than just first principles.
Of course, this assumes you're working in an environment where you can turn out prototypes at minimal cost to ongoing development efforts. But if you're working in such an environment, pepper your design discussions liberally with prototypes. With any luck you may get to keep some of them.
note that agile methods are not an excuse to avoid designing, they just encourage testing of the design more frequently, and in smaller increments
i like to sketch the design and break its elements down until reasonably sure that there are no obvious unknowns or risks; unknowns and risks are highlighted for 'spike' projects, with a time-box for determining feasibility and notes on possible alternatives if the preferred methods prove unworkable
once comfortable with the overall architecture, jump into the features bottom-up (or in priority order) to complete the design, write the initial tests, then implement
EDIT: note that the question "design or prototype first" is making a bad assumption, i.e. that it is possible to prototype without doing any design, which of course is not the case (unless you are using the million-monkeys methodology)
Design first, unless you're willing to take the risk of throwing out all the work put into your prototype when you find it can't do what you need it to do. At a minimum, you should make some high level designs for your project that can help you make some decisions about how you're going to build your prototype so that you will have a minimum of wasted effort.
If I know what I want to build, I just go right to design.
If I'm building something for a client, then I prototype to ease out more specific requirements from the users.
Maybe not an answer but a suggestion from my experience.
In most cases I'd be better off if I had started coding earlier. You can design until the cow comes home, but if the cows are on the horizon when you start coding, you might find your careful design hard to implement in time.
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 a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.
Have you any recommendations for improving the the quality of input from the functional people?
Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Have you tried working with your customer to define / formulate acceptance tests?
Using something like Fit to come up with these tests - would result in better specs as well as force the customer to think about what is really required. The icing on the cake is instant-doc-executable specs at the end of this process.
That is of course, if your customers are available and open to this approach. Give it a try!
If not (and that seems to be the majority - because it is less work) - calendar flash 'em - schedule meetings/telecons every week until they sing like canaries :) +1 to Dana
Sometimes the easiest way to get input from people is to force it out of them. My company used SCRUM on a project, and found very quickly that people tend to keep to themselves when they already know what they're doing. We ended up organizing weekly meetings where team members were required to display something that was learned during the week. It was forced, but it worked pretty well.
I'm a big believer in Use Cases, detailing the system behaviour in response to user actions. Collectively these can form a loose set of requirements, and in a SCRUM environment can help you prioritise the Use Cases which will form that particular sprint's implemented features.
For example, after talking to your functional team you identify 15 separate Use Cases. You prioritise the Use Cases, and decided to plan for 5 sprints. And the end of each sprint you go through and demo the product fulfilling the Use Cases implemented during the sprint, noting the feedback and amending the Use Cases.
I understand that the people you call functional people are acting as Product Owners, right?
I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Actually, without having any specs you probably have no acceptance test for the backlog itens as well. You should ask the PO to write the user stories, I like the "As a - type of user -, I want -some goal- so that -some reason-." form. Keep in mind that the User Stories shall be INVEST - Independent, Negotiable, Valuable to users or customers, Estimable, Small and Testable. What is a must is to have the Acceptance tests written together with the story so that the team should know what the story must be able to do in order do be set as done.
Remember that as the product evolves, it's expected to the PO have ideas as he sees the working product. It's not a bad thing, actually it is one of the best thing you can get through Agile. What you have to pay attention is that this ideas mus be included in the product backlog and it needs to be prioritized by th PO. And, if it's necessary and will add value to the customer, the idea should be planned to be built in the next sprint.
Someone from the functional team should be part of the team and available to answer your questions about the features you're adding.
How can you estimate the Backlog item if they are not detailled enough ?
You could establissh a rule that Backlog item that do not have clear acceptance criteria cannot be planned.
If would be better to have someone from the functional team acting as Product Owner, to determine, choose and priotitize the Backlog items, and/or as Domain Expert.
Also, make sure everyone in both the functional team and the development team speaks the same language, so as to avoid misunderstandings ; See ubiquitous language.
Track the time most waiting for answers from the functional team as well as he time wasted developping unnecessary features or reworking existing features so that they fits the bill.
Are they participating in the stand-up meetings?
You could propose to have a representative at each (or some) of them, to ask them for input before the end of the sprint
Are you doing stand-up meetings and do you have burn down chart? I think those two areas would benefit you greatly.
I recommend the book "Practices of an agile developer" it is full of suggestions how to make a scrum team successful. It also gives good tips how to get the product owner/customer more involved and how to get the whole process rolling. It's worth the money IMHO.
I agree that you need some sort of requirements (user stories or else).
One piece of advice I can give is to use some sort of visual aids with the functional teams. When customers have plenty of ideas (as you've said) they usually also have a visual idea of what a feature looks like, when the developed product doesn't fit this visual idea it creates a lot of doubts, even if it does the job functionally.
When discussing functionality with customers, I try to be very visual. Drawing sketches on a board, or even verbally describing what something would look like. Trying to find a common visual image. You can then take a photo of the sketches and use them as part of the documentation.
Another advice is to keep your sprints as short as possible, so that you do more frequent demos. But you may already be doing this, since you didn't mention your current sprint duration.