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
Schwaber & Beedle's 'scrum' book (and the other scrum literature I've read) seems to focus on having a releasable product by the end of the sprint. Web development for an established site (at least in our case) consists of developing 'enhancements' (of various sizes) and many small 'fixes'. Deploying (to web) only at the end of the sprint would slow down our deployment of large enhancements (probably a good thing) but would dramatically slow down our deployment of small enhancements and fixes (i.e. the bugs hang around longer).
Are mid-sprint deployments heretical in scrum? Are sprints even applicable in our case? Have I misunderstood sprints entirely?
I really think deploying to production mid-sprint sounds like a bad idea. A real focus-stealer.
Maybe shortening the sprint length would be something for you ?
The completed work at the end of a Sprint has to be reviewed by the product owner during the review meeting. If you release mid-way, this may not be the case.
If you feel that the work is complete before the end of the sprint you can:
Add more work by picking highest priority items from the release backlog
Shorten future sprints
Given your work environment description, I would opt for 2.
You may also want to consider another agile methodology that may be more appropriate to your environment.
I would not release mid-sprint.
Having releasable content at the end of a sprint does not preclude mid-sprint releases. In fact, when your team has production support responsibilities, it is required.
I would ask a few questions about these mid-sprint releases though:
1) Does the incremental value of earlier release exceed the cost of deployment?
2) Have you assessed the risk of each of these mini-deployments to ensure they don't backfire and create more work?
3) Can you get customer feedback for these mini-releases to ensure you're releasing what they want?
4) Have you considered shortening your sprints?
"Strict scrum-driven development" (proferred above) is, to me, an oxymoron. The mantra is inspect and adapt. I chaffe at the suggestion that scrum is being wielded as a doctrine against improved responsiveness to your stakeholders.
If you want to perform a strict-scrum driven development - then mid-sprint deployments are heretical. In my opinion is a strict-scrum approach not the best tool to use for scenario. I'd use a more classical approach where you have defined deployment-packages and tasks appointed to them. you develop on a single trunk and if all the tasks for a given deployment-package are done - you deploy it. But be aware of constraints within your code and project.
You could have a look at Alistair Cockburn Crystal "Orange Web" method. He adapted agile principles with the public web site constraints.
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
could someone explain to me the iterative development methodology and the benefits/limitations for using it in developing a web application?
Also, I've been researching it but I am confused, is it part of Agile or not? Some sources say that it is and some don't?
Thanks all.
Iterative is opposed to waterfall development. As you know, you should go through a couple of different phases for delivering a software product.
Requirements Engineering/Elicitation
Analysis & Design
Implementation
Testing & Verification
Deployment & Maintenance
At the end of each phase, you will have some Artifacts or deliverable results. In waterfall strategies, once you finish a phase, everything is done, and you will not come back to that phase again.
In iterative approaches, you will go through these phases repeatedly. In each cycle you repeat all of or part of these phases and at the end of each cycle you will deliver a working product.
Iterative approaches let you to develop your software incrementally and you will be able to establish and then further extend your product step by step. You may deliver just a skeleton of your web application at the end of first cycles and thenafter in each cycle, you will revisit your requirements, design, implementation, and your testing plans. You will find bugs and fix them. At the same time, you will receive feedback from your end-customers and change your product accordingly.
Agile methodologies like scrum, are mainly about how to eliminate unnecessary extensive processes like heavy documentation, formal meetings, etc. So, you can focus on your product and code instead and iterate through your cycles much faster. Agile neither enforce waterfall nor iterative approaches, but the fact is that waterfall is now outdated and it is not going be used any more in industry.
Iterative development has been around quite a while. It certainly predates agile, though you could argue it is ancestor of the agile development approach.
There are some non-agile development approaches that include iterations, such as RUP, so it is not exclusively an agile practice.
There are also a lot of ways to use the iterative approach. You could, for example, do up-front gathering of requirements and design and then use iteration during the development phase only.
Agile frameworks like XP and Scrum take iterations a bit further and look to have a 'releasable' product at the end of each iteration.
Benefits of the agile iterative approach:
The product is releasable at an earlier stage in development
Progress is often easier to measure (released code is a great measure of progress)
The iterative approach allows teams to more easily respond to change
Limitations of the agile iterative approach:
It can be a challenge to fit things like UAT and regulatory compliance in to iterations
There can be an overhead associated with frequent releases and frequent re-planning
You could think of having a releasable product at the end of each iteration as a pure form of iterative development. Not every team uses this approach. For example, some may leave the user testing until after several iterations. The downside with this is that you are never really sure the work is 'done', because potentially user feedback could change things.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What are the difference between Agile and iterative and incremental development? Is Agile considered as iterative and incremental? Some info shown the Agile is the latest of iterative and incremental. I need a clear clarification on this.
Iterative - you don't finish a feature in one go. You are in a code >> get feedback >> code >> ... cycle. You keep iterating till done.
Incremental - you build as much as you need right now. You don't over-engineer or add flexibility unless the need is proven. When the need arises, you build on top of whatever already exists. (Note: differs from iterative in that you're adding new things.. vs refining something).
Agile - you are agile if you value the same things as listed in the agile manifesto. It also means that there is no standard template or checklist or procedure to "do agile". It doesn't overspecify.. it just states that you can use whatever practices you need to "be agile". Scrum, XP, Kanban are some of the more prescriptive 'agile' methodologies because they share the same set of values. Continuous and early feedback, frequent releases/demos, evolve design, etc.. hence they can be iterative and incremental.
Incremental development means that different parts of a software project are continuously integrated into the whole, instead of a monolithic approach where all the different parts are assembled in one or a few milestones of the project.
Iterative means that once a first version of a component is complete it is tested, reviewed and the results are almost immediately transformed into a new version (iteration) of this component.
So as a first result: iterative development doesn't need to be incremental and vice versa, but these methods are a good fit.
Agile development aims to reduce massive planing overhead in software projects to allow fast reactions to change e.g. in customer wishes. Incremental and iterative development are almost always part of an agile development strategy. There are several approaches to Agile development (e.g. scrum).
Iterative development implies revisiting usual waterfall model steps over the course of product lifetime. The stages can even overlap, i.e. while doing end-to-end testing you could already start preparing new requirements.
Incremental development means you roadmap your features and implement them incrementally.
Agile aims at creating "potentially shippable product" after every sprint. How you achieve it is a different story. Agile tries to employ "best" techniques from various fields (e.g. extreme programming). Agile does not exclude running neither incremental nor iterative development.
Some important and successfully executed software projects like Google Chrome and Mozilla Firefox are fine examples of both iterative and incremental software development.
I will quote fine ars technica article which describes this approach: http://arstechnica.com/information-technology/2010/07/chrome-team-sets-six-week-cadence-for-new-major-versions/
According to Chrome program manager Anthony Laforge, the increased pace is designed to address three main goals. One is to get new features out to users faster. The second is make the release schedule predictable and therefore easier to plan which features will be included and which features will be targeted for later releases. Third, and most counterintuitive, is to cut the level of stress for Chrome developers.
Laforge explains that the shorter, predictable time periods between releases are more like "trains leaving Grand Central Station." New features that are ready don't have to wait for others that are taking longer to complete—they can just hop on the current release "train." This can in turn take the pressure off developers to rush to get other features done, since another release train will be coming in six weeks. And they can rest easy knowing their work isn't holding the train from leaving the station.<<
Agile is mostly used technique in project development.In agile technology peoples are switches from one technology to other ..Main purpose is to remove dependancy.
Like Peoples shifted from production to development,and development to testing.
Thats why dependancy will remove on a single team or person..
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 5 years ago.
Improve this question
I am working as Scrum Master on a large software project. We are currently running Scrum.
We have about one month left in the development phase before we are supposed to end our implementation phase.
I am strongly considering switching to Kanban (Or GTD) for the last couple of weeks due to:
We have an absolute deadline
It is very hard to plan two (or one) week ahead now that we are this close to the end. The agenda, priority and outstanding tasks changes almost each day. We daily find new tasks we must remember to do before we can say our development phase is finished.
Kanban let me easier identfiy which tasks are waiting for reponse, which tasks are waiting for verification etc.
Anybody have experiences with this? Is this a good idea?
Our sprints are not entirely pontensial shippable increments (I know they should have been, but thats not what I want to discuss here)
Even though I can be considered a Kanban proponent I would think twice before making such move.
On one side:
Kanban deals very neatly with rapidly changing task priorities. It is a good answer for environments where classic time-boxed approach, here: Scrum, doesn't work very well.
Introducing simple Kanban system doesn't require much effort.
Kanban itself isn't an approach to software development and/or project management and should be put on the top of something. However, it seems that you already have this "something" as, at the moment, you have your project organized.
On the other hand:
Adding new tool to your toolbox always adds some hassle and, since you are at the end of the project, it may not be such a good idea to add the hassle now.
Kanban, as pretty much any other tool, will give you value if and only if you get team buy-in before introducing it. I mean Kanban board is useless unless it is updated by everyone in the team regularly.
If you are fluent with what you do, namely following Scrum, resigning from a part of it, namely time-boxing, may have a negative impact on team's productivity. At the same time it'll take some time before you get familiar with a new method, so there can be a question when you're going to get value of switching to other method.
All in all, I would definitely consider Kanban to such work as it gives you pretty good visibility and high flexibility in a situation where priorities are changing all the time. However, I wouldn't say that, in your case, it is a sure-shot decision. If you planned for it in a bit longer perspective it would be a no-brainer to try Kanban.
Personally, I'd probably try anyway and treat it as an experiment. If it works you keep doing it. If it doesn't you retreat back to what you are good at and eventually try Kanban in another project with a bit more preparation.
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
Let's say that a developer is interested in learning Scrum, but nobody else on the team is interested. I realize that Scrum is made for teams, and the process would have to be modified to fit a single person.
Is there any benefit to be gained by the developer trying Scrum, even if the team doesn't? If so, how would the process be modified to suit the situation?
I think there's benefit to be gained by any method that helps you develop goals, tasks, keep on top of work and deliver something often.
Your individual work-products would gain the same advantages that teams gain with scrum:
You'd get something done every {Sprint Iteration Period Here}, something you can hand off and say "This is now ready".
Your estimation technique will start to improve with reflection and retrospectives
You'll start to plan your day and make commitments to yourself about getting things done, so again your estimation of your capacity will increase
Retrospectives will formalize improvement of your personal work process. You'll start actively improving, removing and adapting to suit you and your individual needs.
You wouldn't be able to rely on other team members to help out, which is a bit annoying, and you wouldn't have a product owner, Scrum master or a backlog to pick tasks from. You may not even be in a position to make decisions on what to work on next. But I think the formal discipline and reflection is helpful for all craft practitioners, at all levels, alone or in groups.
And who knows, you might even inspire your team to Scrum it up once they see what great results you're getting.
I would suggest that you use Extreme Programming instead, as that works better for one programming than a decidely team-based process.
Then you can get the benefits of being more agile, but if your team is not agile then you will have some issues due to the use of a different paradigm.
For me, the biggest key was getting buy-in from my supervisor. It can be tough to try and have some sort of Sprint only to have it interupted multiple times (Supposedly XP teams handle this better, but I don't think any developer does.). Also, don't forget to include either power users (they could be testers) or members of other departments that could be used as Product Owners. I like to sit with other users and do a type of paired programming (OK they don't code) where I can ask questions while coding and do quick demos to get feedback. This helps when I'm struggling to create specs because those requesting the app are having a hard time telling me what they want.
Even if it's just you in the daily stand-up, it can be scrum.
If you compare yesterday's planned with actual and define today's plans -- without talking to other people -- that's still a kind of daily stand-up.
I'd say that what you're doing probably is scrum if you're following the daily-sprint-release cycles; even if there aren't a any other people to talk to each morning.
G'day,
For the best thing to come out of learning Scrum is the concept of involving the customer early and often. That way there are no nasty "that's actually not what we wanted" moments when you deliver to the customer after six months hard work.
HTH
cheers,
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
So I find myself working for a few weeks in a small team of four, including me. Quite a change from my last job at a 300+ developer shop where I'd been part of the adoption of an agile methodology.
I've been sneakily introducing useful tools like a continuous integration server and am surreptitiously starting test-driven development.
What other agile project management and development practices are appropriate for the smaller shop?
Well, to me, your actual configuration is much more appropriated for Agile than a 300+ developer shop (not really sure how Agile was implemented there, I'd love to hear more about that as scaling to that size requires a very high level of maturity on Agile IMO).
So, my answer would actually be: starting with 4 people, all values and practices are appropriate and valuable. Actually, what Agile methodology did you adopt previously? What practices did you implement? What makes you think they wouldn't be appropriate?
PS: If I may, try to see beyond engineering practices, Agile is not (just) about that (this is especially true for Scrum). Practices such as Test Driven Development, Continuous Integration, etc are nice but they are just a mean, not an end. They won't suffice for a successful Agile implementation. Agile is a business oriented organizational pattern. In other words, technical stuff is not really the best starting point when implementing Scrum, you should start with organizational things.
IMHO all of the development practices are appropriate. In fact, for a long time an agile team was expected to be a small teams (5-9 people). There is an artile of infoq about it.
Also, because you have a small team both communication and collaboration will become easier, so the practices would work even better.
Focus on introducing practices that add the most value to the team.
As the team is small impact of the change will be highly visible, if you work with the team and show improvements then you can go back and add another one - again the one that add the most value to the team.
One of the most important thing is that the projects are approached with an agile mindset, adding tools & techniques in the context of long projects that can't adapt to change & are not highly tuned with the customer won't have the ultimate result that you should be aiming for.
Communal code-review whether or not everyone is on the same site
I think you may want to flip the question around; what agile methods would not be suitable because you are a small team. I am no expert in agile practices, but I can't really think of any that would not be appropriate because of your team size.