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 8 years ago.
Improve this question
After learning about source control the first thing I did is do a project with svn. After learning about git I used it in a personal project. After learning about UML/Design Patterns/Design Principles/TDD I applied them to a personal project. How can I do the same to agile development? Is agile just for teams and big projects? How do I set up these iteration things?
I think Agile is definitely not just for team projects. Agile advocates a set of values that apply equally well to many types of projects, even personal ones. I was in exactly your situation a while ago, trying to apply agile development to a personal university project, and learned a lot in the process. Some useful things that the agile mindset can give you include:
Work on stuff that adds value to the final product. Make yourself a backlog of features and prioritize them as though you were the customer. Then discipline yourself to work on features based on their value to the product rather than what you want to do right now. This might save you from a lot of unnecessary, over-designed code that you won't use. If you have a deadline, it's even more important.
Have an evolutionary design: start with The Simplest Thing That Could Possibly Work and Refactor Mercilessly.
Postpone decisions until the Last Responsible Moment.
Timebox yourself into sprints or iterations (VERY important on university projects).
...
If you go over some of the agile methodologies again, I think you'll find plenty of values and practices that you could apply by yourself.
While writing this answer, at least 3 other answers came up and beat me to it. I agree with all of them. :)
Make list of tasks and features that you want in your application. Take those tasks and put them on a card wall.
You can't really have a meeting by yourself, but in the morning decide what you will do for the day and what you successfully did yesterday. Take those tasks, do them and then move to the next. Make sure at every point you are delivering continuously integrated, working software and you update your backlog. You might have "bug bash days" where you just fix bugs. That would be a one man scrum. :)
It's hard to truly apply agile coding to one-man projects because many of its benefits are aimed at small teams where you can quickly collaborate on focussed areas.
That said, you can adopt some of the techniques:
Release often
Focus on your users' needs
Feel free to deviate from major version plans - you can change direction whenever you feel the need
Spend less time in setting up major frameworks and get something working as soon as possible. Then go back and refactor to accomplish your original needs (if they still apply)
Other than pair developing, you can do the remainder of the practices if you are willing to play multiple roles. If you have someone who is willing to work with you, you can also do pair developing.
First you would build a product backlog. This would be a prioritized list of features or story cards you wish to develop. No card should be bigger than the work you can complete in a single iteration or sprint. If your sprints are a week or two, that will determine the size of the features or story cards on your prioritized product backlog. As the product owner, you can change the priority of the product backlog for each iteration. From the product backlog, you could build your iteration and release plans.
Since you are playing multiple roles, you will need to allow time for you to author the story card. The story card should sketch the GUI, describe the primary and secondary workflows and most importantly have acceptance criteria.
Once you sign off the written story card, you can begin development on the card. You would use TDD (test driven development) to write the test first, then the code. You would repeat until the card is done. The acceptance criteria would help you decide what unit tests to write.
Once the developed of the card is done, you would write the automated functional tests. You could use Quick Test Pro, FIT, Cucumber or some other favorite automated unit test tool. I would stay away from any play and record features as that can drive up rework in the future as you refactor.
Once the unit test is completed and the card passes, it can be added to all other automated functional test and can be run at least daily if not at every check in.
At the end of the iteration and prior to moving your working software to production, you can perform the User Acceptance Testing.
As the developer you should use continuous integration, automated builds kicked off with each of the frequent check in to your source code control system.
After the story card has been written and prior to developing the cards for the iteration, you can task them out (i.e,. provide estimates for each of the tasks required to develop the card). You can determine if any refactoring needed can be completed within your estimate or if you need to create a new story card that captures the technical debt you identified.
As you can see, you can take a single member agile team very far. Given that the agile management practices help collaboration and identify what is important, you can benefit from those practices also. Given that the engineering (XP) practices enable the code to remain healthy thus supports sustainable pace, you code will remain flexible, contain a strong unit and functional automated test harness and allow you to continue development at a sustainable pace indefinitely.
Is possible to use Scrum for one man projects.
Create backlog
Optimal time for one sprint is half day
At Friday create plan for next week and every half day update burndowns for each projects.
For example, don't be afraid to refactor your own code, even if it works, if the result is more flexible and robust.
A few thoughts on this:
Iterations are as long as you'd like them to be
IPMs are still possible where you pick what you want to do over that length of time
Demos at the end are still useful to see working functionality in a somewhat professional manner rather than your own little debugging area that may not be as clean or orderly
Retrospectives are still useful to see what is and isn't working for yourself at a point where you can see the forest for the trees in a sense
It is quite possible to be Agile in a personal one-man project, IMO.
All of the advice here is good, but there is one important aspects of Agile that usually goes unmentioned: monitoring.
Agile asks you to take a look at what you have done, what you are doing, where you are going, and make appropriate course corrections if needed.
I think Big Visible charts and Burndown/Burnup charts are so useful, I wrote a program, Task Analytics, to make these charts easily. It's perfect for small or one man projects.
Good luck.
Related
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
In my workplace, we "follow" the agile methodology. However, all we do is standups. How else do I have to change my way of working as a developer, to follow agile?
Thanks
Agile is really a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. It's hard to do by yourself.
That said, there are things you can do that will make you more agile, and that your teammates may choose to emulate once they see the advantages:
Work in small pieces. You want to break your tasks down into pieces that can be completed in a reasonable amount of time. (The teams I've worked on usually measured things in half-day units. Thus you could complete 2 units of work a day, and 10 units in a week.)
Commit functioning code. When you're working, you want to commit your code frequently, but only when the code compiles, and works without breaking your unit tests. You do not want to be the person who commits code that breaks a build.
Write Unit Tests. Your team IS writing unit tests for its code, right? If not, then start now. Writing unit tests will force you to structure your code to be testable, which will also force you to improve your implementation and design. It will also detect regression errors, by checking everything that used to work when someone makes a change.
Unit Tests for all bugs. Any time you need to fix a bug, first write a unit test that causes your code to fail in the same manner as the bug. Then fix your code. If the fix is good, your unit test should now pass -- and all of the rest of your unit tests should continue to pass.
Unit Tests for all new code. When you're building new code, you should be building to a spec. One of the best ways to ensure that the spec is good, is to use the spec to write unit tests for your code. Once you've got enough tests to validate the code you intend to write, go to work, testing your code against your tests. Once your code passes the tests, you can commit to the team repository.
Use Continuous Integration. This is something that the team itself should be doing, but if you can get the use of an extra PC (it doesn't have to be fast, just have enough memory and disk space to build your tools and build your software). Load CruiseControl.net or Hudson on it, point it at your repository, and configure it to wait for new commits, checkout your workspace, build your software, and run your unit tests. Why? Because it will catch when someone has neglected to commit all of the pieces of their change, before the change propagates to the whole team.
Automate your builds. Before you can use Continuous Integration you need to be able to build your software repeatedly without human intervention. If you're using Visual Studio, learn how to build using MSBuild or Nant. If you're doing Java, learn how to build with Ant or Maven. By building automatically, you avoid build and release problems associated with manual steps. (I once reduced the build process for a project from a notebook that took 2 professionals a week to complete, to a set of scripts that would take about an hour to run -- you better believe that improved the quality of releases.)
That sounds like waterfall with daily meetings. Implementing agile is quite a vast difference and you can't just change from waterfall to agile yourself, you need others to follow suit for it to work.
I think the largest change will be to stop thinking in "project" scope, and start thinking in very small increments of work. For example, when the project "Create website X" comes up, you'll need to break that down on a page by page basis. Determine what needs to be done, how exactly are we fetching, storing, updating, displaying the data. How long will it take to write the different pieces of code required to do that? Once that is laid out (there is much more planning involved in agile, from my experience) then you can start saying "By Wednesday, I'll be able to show you guys that I can save on page X and I'll display the data on page Y".
Usually there is a "planning" meeting. This can take an hour or it can take 6, this depends on how well your criteria is conveyed, how many members are on the team, and how long of a sprint you're working with. Everyone selects work that they will do, and puts estimates on it. After your sprint (which most people recommend to be one or two weeks) there is another meeting. Ideally in this meeting everyone will demo what they have been doing the past week(s), and it will work perfectly. Afterward there is some reflection, what worked well? Did we mis-estimate something terribly?
That is one "cycle", do that ~50 times and website X is complete! :)
To start with, there is no such thing like "the agile methodology", agile is an umbrella term that describes several agile methodologies and if all your workplace is doing is standups, I can already tell you that this doesn't make a workplace agile.
Second, while you can adopt some "agile practices" (especially engineering practices) at an individual level, this will never be enough to make you agile: 1. agile is in my opinion more about the way to drive product development than engineering practices 2. agile is a collective team game.
So, my recommendation would be to dive into for example Scrum and XP from the Trenches and to grab some copies for your coworkers, your boss or potential sponsors.
Congratulations on doing stand-ups. It's a good first change.
That you're asking suggests that you or the team would like to be better at this. In that case, you can go one of two ways:
Huge change, or
Incremental improvement
If you decide you'd like a huge change, you'll probably need some books, training and maybe a coach or experienced practitioner around. This is often successful if people higher up in the organisation are invested in the change too.
If you decide you'd like to improve incrementally, it's worth reading around Agile just to get some ideas. I recommend "XP Explained". There are a lot of blogs out there, too, as well as posts here. The two things you'll need to do are:
Try to deliver some software, or at least get feedback from the stakeholders
Work out why that was hard and what you can do to make it easier.
We normally do the first with showcases and the second with retrospectives. I recommend having retrospectives at least every two weeks, even if it's really hard to showcase working code.
Things I often see flagged up quickly as problems include:
Team not co-located ("Team" includes BAs and QAs)
Environment not suited
Lack of visibility of work in progress or overall goals
Too much work in progress - things started but not finished
Projects in progress that nobody really cares about
Project progress makes it obvious that it's not worth doing
Codebase is really hard to change
Blame culture discourages collaboration.
Whatever you find out, you won't be the first.
Note that Agile is a transparent methodology, whichever version you use. A lot of people get scared by transparency. This is normal. Sometimes managers higher up have a vested interest in not allowing things to be transparent. This is also common, and at that point you might need external help. Delivering working software can be very persuasive, though.
Good luck!
If you want do to this from the ground up, then all you need is the agile manifesto and recurring retrospectives each week. But I guess that is not enough, so here is my start-up-list:
Convert your existing project tasks/points/todos into User Stories
Pair program on everything. Switch pairs often!
Use Test Driven Development. Strive for 100% coverage!
Use one week iterations. Repetition is learning!
Deliver valuable software to the customer in each iteration.
Even if entire team doesn't work in an agile way there are few practices that you can adopt as Developer. You can begin with CI, TDD, automated deploy. As a team you can try out retrospective session.
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
Our team is debating whether we want to become Agile or not. None of us are really fluent in Agile. I'd like some thoughts on when Agile works well, and when it doesn't.
To give a little background, we are a small group of developers, six in total. We have far more work that we can handle. Our priorities change often. What is a high priority today, may not be tomorrow. We have many applications to create and maintain. We have started to dabble in Agile practices to the extent that we have daily scrums and two-week Sprint cycles.
If you need more information to answer this, please feel free to ask.
Thanks.
Ralph Stacey's complexity matrix is commonly used to illustrate the sweet spot for Agile:
(source: typepad.com)
For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.
For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.
When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.
I'm speaking only from experience; YMMV.
My team was unsuccessful at making agile work. IMO, it was because:
The very first time the dev team
would hear about a project, it was in
the form of a requirements document
and a deadline.
Stakeholders were often reluctant
to take time to look at the result
of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
When we showed stakeholders our work,
they generally just OK'd it. They
would talk about what they would
like, to which we would reply "That
can be done in about X amount of
time," to which they would reply,
"Well no need to go over the deadline
for that."
The deployment process was long and
complicated, discouraging frequent
deployments. So in practice, we
often deployed things when a 2-month
project was done, not at the end of a
sprint.
Our sprint planning meetings were
long and inefficient.
It seems everyone was confused about what scrum is (and about what our process was), except for the scrum evangelists.
So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.
Some things that have sped us up, which we continue to use:
automated builds that work on
everyone's machine (HUGE help!)
a formal arrangement for our code
repository
learning how to apply apply
abstraction mechanisms to UI code
refactoring
unit and integration tests
continuous integration
I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.
(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)
Reposting a related answer of mine:
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)
It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.
Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.
I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).
Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.
Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.
Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.
In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.
Team must be stable and 100% dedicated to this.
Team must be colocated in one workspace.
Customer/product owner must be available on site at all times.
Support from management. This means providing funds and courage to ensure the points above.
Give these points, you can probably tackle anything as long as you keep to the values.
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'm trying to figure out how to solve some challenges that my team is facing while attempting to apply agile. The one that is causing the biggest headache at the moment is due to the dual role nature of projects that come into the business.
Basically, we have a number of software that we produce and deploy for various markets. This software is planned and scoped in quarterly release cycles. At the same time we have large contracts come through that take anywhere from 1-3 months to complete. The problem comes from the fact that management wants to work on the incoming contracts first and foremost and all normally scheduled release work is brushed aside to get the next contract out the door.
We're trying to scope the releases to shorter than 3 months so that a contract would have to wait that long for work to begin.
Has anyone dealt with a scenario like this while trying to apply agile? What are some ideas/approaches to working on release scoped/planned work and keeping management happy that high priority contracts are being delivered in a timely manner?
The only way I can see is an internal market.
Assign a $ value to the next release of your 'real' product and then you can fairly apportion effort to that vs the incoming contract.
Of course the value of the 'real' product depends on management but at least it pushes the problem onto them in a rational way.
Instead of looking at your situation as multiple shorter projects that are interleaved into one longer project, you might instead think of it as a single larger project. The small projects then become interrupts or the equivalent of scope changes, which are things that all large projects need learn to manage anyway.
As with interrupts and scope changes, you will need to address schedule impacts, the effect of "context switching" overhead on your staff, etc -- and possibly consider dropping features or cutting back in other ways in order to make your next scheduled delivery date.
If management wants the new work to be done first, while the mainline project is put on hold, then it seems to me that's what you should give them. Why drag your feet for 30 or 45 days before starting the new project? From the perspective of a single larger project, that's certainly not very agile. You could instead get a faster start, and then communicate the resulting impact.
Over the long term, you may find certain staff members are slowed down more by periodic course changes than others. In those cases, you might consider making semi-permanent assignments, so they can continue what they were working on, even in the event of interrupts. Similar arrangements are typical in larger, interrupt-driven shops.
Even in an agile workplace there is some kind of "resource planning" at management level. As long as there is some predictability on when the contracts come in, the allocation of people to teams and between teams can be decided before the start of each iteration.
If an unexpected event occurs and it is necessary to terminate a sprint, or re-plan it mid-iteration then that's what you have to do.
Agile methodologies are supposed to help you to "embrace change" and make sure that the highest value requirements are delivered first. They don't change the fact that there is always more work to do than people to do it, but they do provide a framework for managing the chaos that this will cause if people aren't realistic about priorities, actual staffing levels and work rates (or "velocity").
Agile doesn't mean that there won't be difficult conversations, but if it's done well then the conversations should mostly happen in time to take some kind of corrective action.
I'm assuming that there is some kind of officially sanctioned agile process in place. I don't believe that agile methodologies (e.g. Scrum) can be made to work under the radar, because:
Agile methodologies are about self-managing teams. If your management doesn't accept the teams' right to self-manage then there is going to be a power struggle.
Agile methodologies are about having high quality communication both within a team and between the team and it's stakeholders. It doesn't work if the process is hidden from the stakeholders.
From the comments above, your process seems to be in pretty good shape. You have identified a genuine business problem and you are having a constructive dialog with your management team.
If you haven't got management buy-in, doing Agile is very difficult.
By the sounds of it, the management don't have a problem at the moment. They drop a contract on you, you do it, the quarterly release slips but they get the nice contract money.
Is your team large enough that you could conceivably split it into two teams: one focused on the internal releases, one focused on contract work or perhaps two teams that swap over responsibilities after each release so they each get to spend some time on green field and some time on BAU projects.
On a general Agile methodology note, you'd be better off with Kanban than Scrum because it sounds like if you tried to plan iterations, you'd end up with 90% of the work in the unexpected 'contract came in' column.
Who is driving the quarterly releases on your product: customer requests or what you would like to do? Like mgb said, what profit is the business making from them?
I think it's first important to define by what you mean to "apply agile." There are a lot of different parts of agile and I would try and start small with the pieces that you can do. For example, do you have a continuous build running? Have you developed a product backlog?
Working on multiple projects is difficult to begin with but without management buy-in (as Wysawyg mentioned), it will be difficult to become more agile. You need to show the benefits of agile development in terms of cost savings to management. Have you determined why you want to become agile? How will it help? Once you have shown why, then just start doing some of the pieces that you can and after you start seeing some improvements, talk to management about the bigger pieces.
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
For those of you who have implemented Scrum in your organizations, what were your biggest obstacles and if you did overcome them, how?
Background: In 2006 I contracted with a large company which had adopted Scrum cold turkey just months before I arrived. The company hoped Agile/Scrum would save their huge enterprise software product. Of the hundred or more programmers there, I worked closely with a team of about a dozen for a year, observing and participating in their Agile experiment.
Summary: I believe Agile helped more than it hurt. By the end of the year, the team could consistently estimate and produce features, whereas previously their productivity was rather erratic.
Implementation: Since this was a large organization and a large product, the project ran as a "scrum of scrums." There was one scrum master for about every 15-20 developers and these teams were often divided into smaller, closely working scrums of about 6-8 people for an iteration. Teams were largely independent, could adjust their own iteration frequency (1 month down to 1 week) and were given lots of flexibility to implement agile as they saw best. The company regularly brought in Agile coaches (such as Object Mentor) to help train the scrum masters, teams, and management.
Obstacles: Plenty. Some of them related to Agile, some not. In no particular order, here are some lessons learned:
The product backlog was revised way too often in the beginning. Eventually, the team and management took several days to go over all the features, estimate them, and prioritize them. It was a big hit, but it helped tremendously. Lesson learned: get your product backlog in order early and keep it maintained. Product owners must have a clear idea of what they want.
We lost time experimenting and dealing with fads and hype. When you start, you have no way of knowing if you're doing things correctly. There's temptation to constantly fiddle with the agile process taking the focus away from the product. Lesson learned: having an experienced Agile coach does help reduce this learning curve. There should always be someone pushing back on any experimentation. Limit the number of "spikes".
A good scrum master is invaluable. Certainly in the beginning, it's a full-time position.
It takes time. It took several months before the team started to be comfortable with the process.
Pick your battles. Some programmers will be understandably skeptical and others will outright dislike and flight the change. Allow for some flexibility. For example, enforce the use of a product backlog and iteration schedule, but don't require everyone use note cards. Be particularly sensitive to introducing tools and programming methodologies such as pair programming or test first development.
Finally, keep communication open and manage expectations.
Good luck!
While working as a Delphi developer a few years ago, I managed to get Scrum adopted by my development team for a time.
The whole process worked very well for us - having the team estimate prioritized tasks on a backlog gave us meaningful timeframes to target, and the whole "Managements job is to remove impediments" was great.
The biggest problem was that the process was always perceived - and referred to - as "Bevan's good idea".
While the team appreciated the value we gained, and were happy to continue with Scrum, the Team didn't take the scrum methodology on board as their own. After a while, I got tired of "pushing" and we "fell out" of following the Scrum approach.
Lesson: Make sure the team takes Scrum on board and owns the approach.
We do mostly scrum projects at the customer site. Hardest part in my experience is finding a good product owner in the customer organization:
Too many people think they should be the product owner,
The product owner has a hard time following the pace of the team
Product owner has a hard time getting all the detailed information the team needs
Moving items down the product backlog to add something with a higher priority is difficult
etc.
Training internal teams to use scrums is doable, bringing in your own scrum master is doable, but a good product owner should be part of the client organization. It's harder to train this external person.
Having a proxy product owner, who works together with the customer product owner does help a lot.
I moved from a company that adopted Agile to the tee to another company which follows the traditional methodologies.
Perhaps the biggest difference I have seen is that the second company struggles to prioritize. There is so much work on each person's plate that they fail to deliver on time. IMO, Agile brings about some transparency to the situation and lets the team as a whole prioritize.
A scrum master in the Agile world would take care of fire-fighting and be the voice of the (sprint) team. In fact, in the first company (where we had a separate scrum master and program manager), the scrum master would fight it out with the program manager when the latter makes false promises to the management. Meaning, the scrum master knows how much a team can produce/deliver after a few sprints, which helps her nail down on the predictability of a team.
I also noticed that the R&D resources have a sense of accomplishment at the end of each cycle, and are looking forward to the next one. But then, a good project manager could get this done in traditional scenarios as well.
The biggest issue, as already stated, that I too have experienced is the lack of buy in. It is very difficult to get people to truly become vested in the process.
The other issue, which is also one that directly contributes to the above issue, and also in a large part one of the founding causes of Agile is the lack of management to stick to the outlines of the manifesto of Agile.
In Scrum, Lean, or whatever version of Agile you are working with one cannot break from the manifesto points. If a process is being used to break away from those priorities then most likely the management is screwing up and the buy in will fall apart. The manifesto MUST be followed:
Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Some scenarios might be when a gantt chart appears from one of the above processes for whatever reason. Gantt charts can be useful, but if all of a sudden a developer is reviewing a gantt chart with management, the last point is broken. Responding to change has slowed because encouragement of the plan is being favored over change. Instead a board with stickies should be used, simplify what is on the board with only the current working items and back burner items. This makes changes easy. Once anything is solidified in a "tool" it slows responding to changes. Sure, management needs to record and track things in some ways, but pushing that onto development only slows the responding to change, and pushing tools onto developers (unless they want them for development and can utilize them appropriately) messes up the first point, of the individuals over tools and process.
In another way, don't stop development for the purpose of writing comprehensive documentation. Unless you only have a single developer, then someone should take the documentation load autonomously from the development role. Pushing these things together drastically slows development and for periods of time, can shut down any effort to actually get working software.
The last point, is to always, ALWAYS stay in contact in some way with the customer or prospective customer. Talk to them regularly about what they want. Talk to them daily and show them as much as you can of UI, or even data flow work. Anything that they would understand they should see. Talk to them, educate them about the architecture and ideas going into the application and never forget that you are building the application for them.
Summary:
Biggest issue is buy in. Second is management sticking to the manifesto guidelines.
If you can mitigate these two risks, you should be good to go. Anything else is cakewalk after getting buy in and getting management to understand that they'll need to be truly strong, and non-micro management managers. Specifically, managers might even need to become leads, or fill a different style of role.
...hope I didn't stray off point too much. :)
I have been running Scrum in several projects. The biggest problem, as I see it, is that not everybody in the organization is into the process. Everybody needs to be committed. Not only the team of developers. Often the managers are the persons that initialize the process and expect that things will change to the better without them doing anything.
My suggestion is that you run a workshop with the whole organization so everybody knows how the process works. Not only the developers. It's essential that you have a person that is really into the process. A person that can answer questions the team and organization have. A mentor.
Being agile is about welcoming change. You should not let the process gets in the way of sense. Do things that works for your organization, but you should try out the whole process before throwing something out.
We implemented Agile (set of SCRUM - management and XP - engineering practice) in an environment that was waterfall with large projects in an environment that was heavily integrated. The waterfall police were everywhere. As you can imagine, many projects failed. Having done Agile at a previous employer, we received permission to trial agile for the project.
Internal to the team, we used the Agile practice. Externally, we wrapped the agile practices with waterfall processes meaning primarily reporting. Thus, we looked from the outside like a waterfall project. However, there was a big difference, internally we were using agile and consequently we delivered, on time, within budget with high quality.
The critical success factors were embedded coaches (Iteration Manager Coach, Dev Lead Coach, Test Lead Coach and a Solution Analyst Coach). Securing commitment from dependent system in advance (required that we look ahead to identify depend systems and the work required from those systems) was a must in a heavily integrated environment. Prior to starting, we immersed the technical and business members of the team in an agile boot camp. This ensured that the key players (product owner and technical team) knew there roles and could execute effectively. Finally, the wrapping of the project with waterfall reporting enabled us to tie into all the existing reporting structure in the enterprise.
The net result is that the company is now moving waterfall projects to agile. This is all possible only because we have been able to deliver high quality software at a sustainable pace.
Where I work has been using Scrum for a while now but it seems to have gone through a few phases. In terms of obstacles, one part is to prevent putting in too much change at once and just introduce things slowly,e.g. put in a daily standup one week, a couple weeks later put in a story board, a couple weeks later bring in pair programming. This allows for the various tweaks that will happen to work and if the changes improve things then this can help build up some good momentum. Another point is to make sure that if there should be changes in how something is done that the person being corrected isn't belittled or mocked. At times this may mean that you interrupt someone or that you bring in a "Can we get back to basics?" or something similar to try to put things back on track rather than just yelling at someone or doing something else that is counterproductive.
Bringing in consultants was one of the best things done around here, IMO. Now, these guys came in to help evolve how development was done here. Bringing in pair programming, TDD, concepts like broken windows, organizing project folders, and bringing in mocking for tests, were all excellent additions that while we may have gotten there on our own, it may have taken a long time which wouldn't work out so well.
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
I'm starting up a personal project to develop some open source software. I want to use Scrum as the PM process on this (as I like the Product Backlog, prioritisation, and if I can get them, the burndowns) but it seems to me that I won't get the full value because I can't at the outset guarantee the amount of time myself and my collaborators will be able to commit to work during a given sprint.
I know there are other benefits that I will still get from using Scrum but are there variations or tricks and techniques I am unaware of which will enable me to get the value of things like burndown charts and timeboxed iterations? Or am I just being too hopeful?
TIA.
Regs, Andrew
As this is a hobby project, are you actually concerned about deadlines? How much value would it in fact give you to know how much will be done after a Sprint?
If your answers are no, you might want to look at a kanban approach as an alternative.
I think about agility in software development and come back to three aspects which provide real utility:
A known backlog of tasks to do
A regular opportunity to openly discuss the current status of tasks being addressed and hurdles to overcome
Team-managed iterations that result in a working subset of the eventual full product
In a work environment, say my 9 to 5, it is easy enough to adopt such a methodology. You've got devs who will be there at least 40 hours a week, every week and so there are few barriers to engaging in an agile practice, like Scrum.
In "after hours" settings, commitment levels of participants often vary. That's life. So you work with what you've got. If Matt is excited about the project but his schedule is busy and the number of hours he can dedicate to the project will fluctuate a bit, so what? If he's "on board" and serious about the time he is willing to invest in the project, then it is just a manner of planning your iterations accordingly.
I personally wouldn't get wrapped around the axle about this, though. In the end, Scrum or any 'agile' process that you adopt should be a means to an end, not the end itself. Particularly in an environment where conditions will differ from those in the 9-5 world, you need to be flexible in your iteration plans. You still plan your work and work you plan and engage in the regular communication and the "where are we today?" exercise to keep everyone in the loop.
The goal is solid software - if you can't get a lot of utility out of a particular aspect of Scrum, or any process, so what? You'll likely develop a hybrid process anyhow. I wouldn't get too too concerned about getting things like burndown charts and velocity and all that. I honestly think the focus needs to be more on quality software being developed and less on the artifacts that might help down the road in the next iteration or the one after that. That's my opinion though.
My advice is to use the things that work and keep it simple. Backlogs are great and the daily 'meeting' to touch base with everyone - even if this is a virtual one done by IM - is where the real value is found. Hobby or side jobs are tough things to commit to and I wish you well with it. But be open to the fact that it might not work as well as the process would at the 9 to 5.
In a by the book setting you won't use real time for calculation of the burndown chart but rather story points. After a few sprint you will see an average velocity and thus be able to generate a burndown chart and use this velocity for commiting to the sprint items.
And I strongly disagree with warrens post on the scale-down point. The main problem I see is a strongly varying velocity between two sprints, since it is only a hobby.
When the amount of time the Team is able to put in at every iteration varies too much, the velocity cannot really help to plan the Sprints since it will vary too, especially at the beginning. However, the average velocity may start to stabilize after several Sprints.
Nevertheless the burndown charts will be useful still as they show an accurate status of the current iteration.
You'll also take advantage of the estimations "calibration" Agile processes bring.
The problem with Scrum for this sort of project is more around the type of development team structure that Scrum is designed to support, in particular the colocation of the team for the daily standup meetings. Its hard to have a daily standup meeting when you aren't at the same physical location. In addition, I doubt you will have a Product Owner on your team, and you will be both the Scrum Master and a developer. On top of this you and your other developers will be working at different times and days may go by without any work being done at all. This may make coordination of the team difficult.
Every project, regardless of develoment methodology, should have a good idea of what needs to be done (the product backlog), what needs to be done shortly (the sprint backlog), and how long it will take to do these tasks so you have a reasonable estimation of how long the project will take (the project velocity and burndown). It is the other parts of Scrum that you may have problems with - not being colocated for meetings, the lack of a Product Owner, using a notice board to show the sprint status, etc.
This is not to say you can't modify the Scrum process to suit your purposes. For example:
have video conferences/Skype calls/IM meetings at prescribed times several times a week even if nothing has been done. Daily is probably too often for this type of project but maybe three times per week would work for your team.
use a web based issue management system so you can all see the product backlog, know what the sprint backlog is, and know what people are working on
have set sprint lengths (say, 3-4 weeks) so that the developers can sense the momentum and know the deadlines
understand what time is being spent on development so you can work out your project velocity and what can be acheived in the next sprint. This may be hard as available time will vary from sprint to sprint.
have retrospectives after each sprint so you can tune your development process with respect to what went well and what didn't. This would be the ideal time to meet at the same physical location if possible.
Scrum, at its essence, is mostly about effective communication so if you get that right you should be able to make a modified version of it work for you. Just remember that communication reduces in effectiveness down the list of
In person
Video conference
Skype/phone/voice calls
Instant messenger
Email
so try to use the most effective method at your disposal for your meetings.