Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
The company I work for is currently looking to move from traditional waterfall into Scrum for development. We are in the process of slowly adopting what practices we can without fully making the move (we still have much to learn before we can fully move on over!).
One of the things we want to implement now, before making the full switch, is the taskboard. We all feel it's a great tool that can help with development, and help keep those business users off our backs with the "what you doing?" and "how's it going?" questions and meetings.
So with all that said, one thing I've been wondering is can the tasks on the taskboard change? I know you don't want to be changing Stories, but what about tasks within a story? What if a new task came up, or an old task is no longer valid? Can they be added and/or removed mid-sprint (though we're not really using sprints, more like short development cycles).
Thanks!
I know you don't want to be changing Stories, but what about tasks within a story? What if a new task came up, or an old task is no longer valid? Can they be added and/or removed mid-sprint (...).
Yes, they can. During an iteration, a team typically gathers knowledge and gets a better understanding of what has to be done, or not. As a consequence, a team may discover that a task isn't really relevant, that a given Backlog Item requires more work than expected, that an initial estimation is wrong. In such cases, you definitely want to update your Sprint Backlog and the Burndown Chart to stick to the reality and keep what has to be done visible: you really want to know if the iteration is still on track, if you can take one more items, etc.
So, yes, don't hesitate to update, remove, add tasks as soon as you discover it has to be done. And the earlier, the better.
In our team, we use a task board inspired by Scrum and XP from the Trenches from Henrik Kniberg and we have a special location for "unplanned items" as illustrated below:
We like this approach because it makes easy to detect if unplanned items are killing an iteration. And we also "review" such tasks during the retrospective to see how we can improve our planning meeting, our estimations, the way we break down items, etc.
The team commit on user stories, not
tasks
It's not a problem to have some tasks changing as you are facing problems or have better implementation ideas.
In fact, it's very rare to finish a sprint with every task 100% "predicted" accurate in the sprint planning meeting.
They can and should change. The board should be updated at least daily.
But Pascal replied to that already - I want to make another point: from experience 'trying to adopt' Agile through small changes won't work. Scrum is a complete framework - by this I mean there is very little in Scrum (I'd say nothing) that can be dropped without doing harm to the process and promoting dysfunction or at least allow dysfunction to continue (wrote about it). Going slowly can be the only way to go in some companies/circumstances, but it has this risk that lingering dysfunctions will blow the process of change/improvement before it can reach its end and yield benefits.
I already like Pascal and Andy's answers so not to repeat.
A usefull alternative is to start a Kanban Board. Henrik Kniberg also has a good 'book' about it, available here:
http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
It allows you to organise your work and be isert some Agile thinking into the company. As Andy said, Scrum is an All-in, if not you will find that 'It doesn't work'.
Why not? Leave the space to team to complete the work the way they would like to do.
Stories are 'contract' between client, product owner and team, therefore it is good to not change, add, remove stories without letting them know. But tasks are only for team.
The team should be able to track the effort the way they need to make it visible.
Questionable is a change of hours the team commited to complete in the sprint, but good scrum master and experienced team is able to self-organize that.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
In our company we do usability test at the end of each Sprint. Many times we discover that the users don't like the implemented feature, so we either completely change it or scrap it in the next Sprint.
However if we start doing potentially shippable product, thus fixing all bugs, running a lot of tests, preparing documentation for FDA and for users, fixing little UI issues - all this work will go to waste if users will not like the feature. Isn't it better NOT to do all this extra potentially shippable stuff until we are sure users actually like the feature?
If you face that users don't like your last increment, that is because you missed a critical point. You should have higher customer involvement all during the sprint, thus making sure that you are really making what the customer wants to see.
If you have a customer representative helping you all the sprint, it is not likely that you are going to implement something that they don't like. If you already do it like this, maybe you should improve your communication. You should have your customer guiding you all the way, helping to find the way they going to like it.
So, the answer is yes. You should make sure that the users really wants this, and this way, but instead of waiting for the end of the sprint you should go and get feedback much earlier, during the sprint and user story definition; minimizing waste and maximizing word not done.
Let me recommend you a great book on Agile:
The Agile Samurai - How Agile Masters Deliver Great Software
If you do not have access to a customer representative during the development process (which is the case in this situation, based on the comments), you should make sure that your customer has a good understanding of why it is needed. Make sure that they understand if they won't guide you, you are not going to be able to deliver superior, word-class quality software.
As part of an agile team, and as a whole team you should be fighting for higher customer involvement.
And one more thing, that people tend to forget. Go your own way. Agile is just about sharing some good practices working for people, and willing to share them. Some people did it this way, so they sharing the knowledge. If it is working a bit different for you, that is just OK.
A way to go could be for you, as you wrote: show your customers the new features, the more times, the more involvement, the better. Show them the user stories, show them the mock ups, show them the half working solutions, communicate with them; get the most out of the situation, and the most information about their expectations. Make sure that you get the necessary feedback in time, this way you can make sure that you won't end up again, standing there during the sprint review and having something that they don't like.
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 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 12 years ago.
Improve this question
I am a trainee in development sector. My Boss says that i should be an agile programmer.
I went through through the net and found some interesting things about agile programming. Being a newbee how should I start with agile?
What should be my first step in Agile programming?
At present I am in pair programming. But it's not exactly pair programming as I am just watching what my co-developer is doing.
I also wish to be an agile developer.
Can you suggest a way for me stepwise?
I wish to develop myself and also my programming skills.
The keyword is Courage.
Courage to estimate and discuss your work
Courage to start work on small stories with insufficient detail
Courage to talk to customers to elaborate said stories
Courage to constructively critique team members code
Courage to review your mistakes (in public) and learn from them
Courage to release "unfinished but good and shippable" code when it already delivers value.
Courage to stick to the agreed team processes when management has a bright idea
Courage to amend agreed processes in team when a better way is found
Courage to deliver high quality code using test driven development and continuous integration.
...
Note: The unfinished part does not mean "low quality", it means satisfying the customer, cleanly implemented, tested, ship-ready. However falling short of the developers idea of perfection, i.e. spring configuration is a bit clunky, some refactoring can be made, some auto configuration, some speed improvement, some corner cases... I found that some developers take the "user story hostage" and keep it unshippable till it is perfect. If it is good, you should let go, better is for the next sprint.
In my organization, all you have to do is declare yourself to be an Agile Programmer. Magically, the need for planning and documentation disappears.
What should be my first step in Agile programming?
Read the 12 principles of the Agile Manifesto over here. Understand and try to make sense out of each one and implement them as simply as they are stated.
Although agile principles can be adopted individually, it should be adopted on an organisation level or at least project level IMO. Urge your Team and your project to use SDLC methodologies which are more agile like Scrum for e.g. If you adopt Scrum properly you will automatically be agile.
As for Agile programming - Pair program, configure a Continuous Integration and Build system, use Test Driven Development, pay continuous attention to code quality and design best practices by doing Code Reviews, design discussions and have high unit testing code coverage.
Ask what needs to be done.
Sort that list in order of priority.
Code, test, and deliver the most important thing on the list; resist being interrupted while you're doing that: if someone tries to interrupt, explain that you're busy doing the most important thing, and that because you're concentrating on only doing that one thing it won't take long and they they'll be able ask you to do something else soon (this phase is called the "sprint").
Once you've delivered, ask for the next most important thing to be done, and then do that, etc.
As per my understanding Agile development process can be put forward ( as already told by ChrisW & Peter :-) ), something like :
There should be agility/movement/progress in the work being delivered in the specified time.
You need to be :
1) Choose yourself/ get allocated by your boss, a task with an accepted period of time
line.
2) Ready with a correct estimation of time for the bit of work to be handled and get
an agreement on that
3) Every day have a discussion in the sprint/meeting(just for : 10-15 min.) with your
boss/team and explain your goals/plans for that day.
4) It will be a best practice to not to get deviated from your bit of task until it is
finished successfully otherwise it can disturb your time lines.
5) At the end-of-the-day, send a status across, of the state of work.
6) Once your task has completed, inform and get your next task pro-actively from your boss.
6) More important is, you try to accustom to the time-line based delivery without fail.
Doing this all by yourself is going to be very difficult. If you take the principles on the agilemanifesto site you'll see that at least 6 of the items deal with groups of people and teams. You're going to need some buy-in from your co-workers and boss.
I'd start with your pair partner. Ask for a turn occasionally. You could try something like so, "lets see if I undersdand this, can I try to add the next feature point."
That being said, there's a good Ghandi quote, "Be the change you want to see in the world." There are a lot of actions you can take by yourself to raise the level of your game. Writing tests, getting a continuous build working, set achievable goals that have some basis in past experience, refactoring.
There are also tons of books that will be very helpful to someone getting started. There's probably someone at your site who would like to mentor you. If you show you're interested in continuing to learn someone would likely be able to help you. Talk to your boss too. If he wants something from you he should be able to at least point you in the direction of someone who could help.
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 am working in a dev team where we religiously follow agile.
However, I have not had to change how I work (unit testing etc doesn't count as I do that anyway). I mean, do I need to change how or how often I communicate? This soft skill side of things with agile is what I am interested in.
Thanks
If your team is utilizing agile well, then you probably should see some changes in how you work. It's possible that you already developed with a fairly "agile-compatible" mindset, even if your previous work experience was in a more waterfall-style methodology.
Some specific things that I think agile developers ought to be doing (and in a well-run agile team, will naturally find they need to do)
Focus on incremental, complete changes rather than massive architectures - This is a core tenant of agile from the macro planning side, but it's also important to practice even for an individual developer. With a 2 or 3 week iteration, you'll find you simply don't have the time to spend 1 1/2 weeks developing something, and half a week integrating it all together.
Check in early, check in often, and check in working code - Don't do this, and you'll soon find you're that guy famous for breaking the build with a day left before the iteration ends.
Know what's blocking you, and what is likely to block you in the upcoming week or two, and tell people about it - No one in an agile team likes hearing at the last second that a developer working on a critical piece is held up waiting for something to complete his work.
Think about the end of an iteration throughout the iteration - Every line of code you write should be done with the consideration of whether this is realistic to complete before the iteration is over.
Always Be Crunching (hey, I couldn't have a pithy list of advice without a cute, Glengarry Glen Ross ripped off acronym!) You'll learn by your second or third iteration that slacking off for a week followed by some all nighters is going to bite you in the ass.
If you're already following all these - great! They're certainly general best practices rather than being specific to Agile. I think most developers do have a bad habit or two that this list addresses, though (I know I do on occasion.)
In addition to Ryan's great points here are a couple more.
Discuss your ideas with other members of your team. Your fellow developers will quickly point out potential flaws in your thinking and suggest alternatives (be ready to listen and not get offended). I found this works best during planning/story tasking. In a 2-3 week sprint it is painfully obvious when you go down the wrong path. It might even stop you from successfully finishing all you tasks/stories. If others know your plan of attack up front it makes it easier for them to step in and help you out finishing your work if you need it.
Do not hesitate to suggest new ways of doing things. One of the great things about agile is that team processes are not set in stone but evolve from a series of retrospectives. If you have developers who never speak up, the process never changes and things do not get better.
Put your user's hat on. Every application has an end user. Sometimes (especially when you do not have a close contact with your users) you have to step back and question decisions (even if made by a product owner). If you can make a good case, not only your users but the entire team will benefit from it since the product will be better received. Developers do not do this often enough. We want to make things better, faster and leaner in the expense of other, sometimes more important things like delivering on time or adding more features.
I hope this helps.
The specifics of agile will be different for every person you ask. Yes, you probably want to communicate regularly, but you don't want to take it to extremes that keep you (or your coworkers) from being productive.
But like I said, it will be different for everybody. The only people who know how best to match your team are the people on your team. Just tell them you aren't used to agile and you were wondering how you've been handling it. They're really the only ones who will be able to say for sure.
Short answer but was very useful to all developers that asked me that question:
There is a book called Practices of an agile developer,http://www.pragprog.com/titles/pad/practices-of-an-agile-developer.
This book will specifically answer to your question. I like it very much because it's not just about the process, but behaviors and psychology.
Attitude-related things:
1) Good pair programming means making an effort to explain things really well and listening carefully. That's a skill in itself. You have to learn how other people tackle things and be patient when other people tackle things differently from you.
2) Being prepared to be flexible and change your mind. The smaller the ego, the easier and less painful it is to handle this.
3) To do agile well, you need to be communicating continuously with everybody in the wider team (i.e. not just devs - sysadmins, managers, customers, network admins, hardware people...) Part of this is feeling comfortable, safe and confident - i.e. there needs to be real trust in the team, not just phoney trust - real trust
4) Be prepared to work outside your specialism and comfort zone. I often have to pair with graphic designers, system admins and DBAs. Saying "that's not my job" isn't part of agile. We're part of a multidisciplinary team and getting the product released in a useful state is the whole team's problem - not just looking after my pet specialism.
5) Try to keep things simple and minimal - no "we'll make it totally generic" or "we'll need it later". Think "you aren't gonna need it." We're shooting for small, simple, concrete steps informed by feedback.
6) Tackle the difficult things and the things that aren't clear first - so that the you get feedback on the problems as early as possible so you if you have to revise estimates or cancel the work the customer gets informed as soon as possible.
7) Try to keep the team dynamics co-operative rather than competitive. Pitting people against each other pulls the team apart - and it gets you well-polished fragments and a broken product rather than a cohesive whole made by people that give-and-take as they find necessary to be successful.
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 starting to adopt agile in a project we are about to begin.
Although I am not actually involved in the development of this project, I am involved in the stand up meetings.
Is it acceptable to say how you are learning a new technology (eg C# 4.0) as one of your tasks, alongside the actual deliverables?
My task is constant everyday so it is embarassing to say how I am doing the same thing (which is not a fun task - more admin type) while the other team members are doing C#/ASP.NET - the fun stuff. This obviously dents my morale.
How should I approach these meetings?
Thanks
Is it acceptable to say how you are
learning a new technology (eg C# 4.0)
as one of your tasks, alongside the
actual deliverables?
Learning time is legitimate, and if the company sees it that way you can make it a task.
Full disclosure: although the company I work for sees learning as a part of the process of software development, I don't actually put individual learning tasks into my weekly reports; I just build it in as a part of the larger development task.
My task is constant everyday so it is
embarassing to say how I am doing the
same thing (which is not a fun task -
more admin type) while the other team
members are doing C#/ASP.NET - the fun
stuff. This obviously dents my morale
Where I work the people that have ongoing "areas of achievement" list the individual tasks they achieved when we meet each week. Some of these tasks can be quite mundane, such as "I went to this meeting," or "I ran this script that took 2 hours," or even, "I read this chapter of that book because I needed to know how to do this." Our company understands that this is the nature of the work. You shouldn't be embarrassed about this.
Full disclosure: I break my "areas of achievement" into smaller goals that can be completed in roughly a week's time, so that each week I can say that I completed something.
I'd try to embrace the three questions:
What did I do yesterday? (Did you
learn about some of the dynamic new
features of C#?)
What are you going
to do today? (Do something with what
you have learnt that challenges you)
What is impeding you? (If you lack a
skill look to the senior guys to
help teach you.)
Kindness,
Dan
Suggest that you are a "chicken" in the process, which is an agile term for being an observer to the meeting but not a participant. http://www.agilejedi.com/chickenandpig
Since you consider your present task 'embaressing', I am assuming that you want some more development responsibility.
In my opinion is the stand up is probably a good time to ask for this.
I suggest that you say something passive like: before the next standup I will try to put what I have learned thus far in C# 4.0 to good use within some area of the project.
You in short order, you will be given something to do... then instead of having nothing to say during the stand ups, you will be too tired to go to them.
be careful what you wish for... because some day, you might get it.
As a junior, you're expected to learn. So, unless you feel admitting to learning would imply you're not doing your other tasks, I say go for it.
You can still report what you learned yesterday, what you plan to learn / try out today, and if you have any blockers that are preventing you from learning.
You will not spend the whole career as "Junior" (and everyone too). How do the team know that you can do higher responsibility? of course by showing that you're capable of. As it's Agile meeting, I believe everyone will have chance to show his idea.
Do your best to answer questions and show your "out of the box" idea to the team.
One day once they think that you can handle higher responsibility, you will out from your current position to more challenging works.
Learning/knowing something doesn't show that you can use it. There are some way to let the team know about your C# 4.0, by talk about it at lunch, writing on your blog then let your team know, write some tool for your daily tasks, etc.
Not only on the meeting :-)
Good luck!
Where I work, we do have people that will say in the stand up that their day will be spent on non-project work as the stand up is for a specific project that almost everyone speaking in the stand-up has a part.
If you repeat the same task a few days in a row in stand-up, you may be asked why you are taking so long on a card, if you have enough resources, etc. as there may be some thought that you are off on a tangent or spike.