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,
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
Agile development is a very useful methodology. Is it realistic to apply this to a lone developer who codes as a hobby (I also code for a living in a team where I have learnt agile from)? Things like stories, scheduled retrospectives, etc, can be useful (Even if I am asking myself things)?
Thanks
Yes, Agile is a lot about Getting Things Done (the real meaning, not the book, see below). It's about getting trough procrastination too. I've found that Agile methodologies tend to solve mostly psychological problems. In fact, most problems we encounter in software development are not technical, but psychological.
I have many projects where I'm the only one involved, and yet I've my own backlog, sprint backlog, my own information radiator, I apply the same "done" definition rules, reviews, retrospectives, ...
But no, I'm not doing standups meeting alone or with my cat :)
I've read many books about productivity improvements before I discovered agile methodologies. And what I've observed is that agile is very similar to them.
For exemple, Scrum is a lot about Getting Things Done, and others well known books on the subject.
That book certainly saved my life at a certain point. So get it and read it. It will helps you "get it", I mean, understanding what Agile means. Trying to do Agile not understanding it will leads you to failure.
Certainly, though some of the practices may not apply or may feel a bit silly.
Breaking your work into stories and timeboxing your development can definitely help even if your all alone.
Test-Driven-Development is really an individual process anyway, and certainly is useful as a solo developer.
Pair-programming would require schizophrenia however. Daily standup meetings would probably go much more quickly...
There was some talk of this on Ward's Wiki years ago, which might be worth a look.
Is it realistic to apply this to a lone developer who codes as a hobby (I also code for a living in a team where I have learnt agile from)? Things like stories, scheduled retrospectives, etc, can be useful (Even if I am asking myself things)?
Definitely yes and it worked for me. I have tried doing it myself and it definitely makes me more productive. A good way to try it without the need of buying a whole lot of office supplies is using ScrumWorks (google danube) which is freeware for the basic version. You can add products, releases, user stories. tasks, and see burn down charts etc.
Doing a retrospective by yourself would be a little weird and it may make people in your house think you are losing your marbles while you talk to yourself out loud but that is just my opinion. What I do is I write down the Retrospective notes on a soft document and attach it to the Sprint or a Backlog in ScrumWorks.
Hoping this will help you.
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 a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
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
When you have sprint task in Scrum, where do you put how you want to program something? For example, say I am making a tetris game and I want to build the part of the game that tracks the current score and a high score table. I have my feature, my user story and my task, but now I want to talk about how to design it.
Is that design something that is recorded on the sprint somewhere as to how to do that or is that just somethign the programmer figures out. Do you put do task x use database such and such, create these columns, etc.? If not, do you record that at all? Is that what trac is for? I don't mean too high level design.
I touched on it here: Where in the scrum process is programming architecture discussed?
but my current question is later in the project after the infrastructure. I'm speaking more about the middle now. The actual typing in the code. Some said they decide along the way, some team-leads. Is this is even documented anywhere except in the code itself with docs and comments?
edit: does your boss just say, okay, you do this part, I don't care how?
Thank you.
There can be architectural requirements in addition to user-specified requirements that can muddy this a bit. Thus, one could have a, "You will use MVP on this," that does limit the design a bit.
In my current project, aside from requirements from outside the team, the programmer just figures it out is our standard operating procedure. This can mean crazy things can be done and re-worked later on as not everyone will code something so that the rest of the team can easily use it and change it.
Code, comments and docs cover 99% of where coding details would be found. What's left, if one assumes that wikis are part of docs?
Scrum says absolutely nothing about programming tasks. Up to you to work that out...
Scrum doesn't necessarily have anything explicitly to do with programming - you can use it to organise magazine publication, church administration, museum exhibitions... it's a management technique not explicitly a way of managing software development.
If you do extreme programming inside scrum, you just break your user stories for the iteration down into task cards, pair up and do them.
When I submit tasks to my programming team, the description usually takes the shape of a demo, a description on how the feature is shown in order to be reviewed.
How the task will be implemented is decided when we evaluate the task. The team members split the task in smaller items. If a design is necessary, the team will have to discuss it before being able to split it. If the design is too complex to be done inside this meeting, we will simply create a design task, agile/scrum doesn't force how this should be done (in a wiki, in a doc, in your mind, on a napkin, your choice) aside for saying as little documentation as possible. In most case the design is decided on a spot, after a bit of debate, and the resulting smaller tasks are the description of how things will be done.
Also, sometimes the person doing it will make discoveries along the way that change the design and so, the way to work on it. We may then thrash some cards, make new ones. The key is to be flexible.
You do what you need to do. Avoid designing everything up front, but if there are things you already know will not change, then just capture them. However, corollary to YAGNI is that you don't try to capture too much too soon as the understanding of what is needed will likely change before someone gets to do it.
I think your question sounds more like you should be asking who, not when or where. The reason Agile projects succeed is that they understand that people are part of the process. Agile projects that fail seem to tend to favor doing things according to someone's idea of "the book" and not understanding the people and project they have. If you have one senior team lead and a bunch of junior developers, then maybe the senior should spend more of their time on such details (emphasis on maybe). If you have a bunch of seniors, then leaving these to the individual may be a better idea. I assume you don't have any cross-team considerations. If you do, then hashing out some of the details like DB schema might need to come early if multiple teams depend on it.
If you (as team member) feels the need to talk about design, to so some design brainstorming with other team members, then just do it. About the how, many teams will just use a whiteboard and brain juice for this and keep things lightweight which is a good practice IMHO.
Personally, I don't see much value in writing down every decision and detail in a formalized document, at least not in early project phases. Written documents are very hard to maintain and get deprecated pretty fast. So I tend to prefer face to face communication. Actually, written documents should only be created if they're really going to be used, and in a very short term. This can sound obvious but I've seen several projects very proud of their (obsolete) documentation but without any line of code. That's just ridiculous. In other words, write extensive documentation as late as possible, and only if someone value it (e.g. the product owner).
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.
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 in a new contract where they seem to have gone overboard with Agile, including hiring a consultant merely for facilitating Agile processes. Something he is instituting is a notion of "core hours" where we will all actually be in the same room together. Is this really what "core hours" constitutes? I ask because it's highly inconvenient to pick up my laptop and go to this shared location for half the day; I always thought "core hours" meant you were available, not necessarily in the same room, from 9:30 to 4, for instance.
Yes and no.
Core hours are the period(s) when all team members commit to working on the project (and not doing administrative stuff or other projects). For many teams, this will imply being in the same room, but with proper planning and the necessary infrastructure, the team can work well from different locations.
I think what you have is an extension of the "core hours" where you are. The idea of being in the shared location is that ad-hoc meetings could occur as well as possibly being within earshot of various discussions so that you can jump in if it is something where you think your opinion or knowledge would be useful, e.g. why was this coded like that? or why do we have this requirement? kind of thing.
I'd like to think that I'm up to date on the Agile world. In reality I am not. With that being said, I'm not so sure this is an agile concept but rather a convenient way for the team to collaborate. It sounds more like something out of Peopleware.
As goes with any team and trying something new, one, there will be resistance to change and two, the team should really have buy in to the new process and working methodology. The Agile consultant shouldn't just be barking orders of what you need to do. He should also be explaining and convincing you why this is a good thing. If you already think the company has gone "overboard" then I think something is wrong. Agile is a great way to work for a many (but not all) teams and shouldn't evoke a reaction like that
Having core hours makes sense so that there is an overlap for collaboration. Having people work in a more open space, maybe 4 people per large cube instead of 1 per small cube, also helps foster collaboration. At work I can just spin my chair around and there are 2 people right there who can help me out or answer questions. However, trying to force something that is uncomfortable and inconvenient defeats the purpose.
I think it would be better to tear down the cubicle walls and rearrange the cubes to make the evirnonment more collaborative.
Slightly off topic but won't fit in a comment:
Agile is extremely disruptive of a programmers "Normal Practices". The word Agile means you are going to have to adapt to changes, I recommend you try to accept them and not fight, because one of adaptations is to cut out team members that cause disruptions in the team.
A consultant is virtually required for a smooth, quick transition.
If your consultant is doing it right, you should be much more unhappy than you seem. During those core hours, none of you should have your own computer--you should be sharing a group. If things are done right, you should be coding in a "Bullpen" without cube walls (facilitates pairing and general communication).
But there are various levels to Agile, and it's intended to be adaptable. Many programmers have a problem with pairing, so often it isn't forced, or is just recommended.
At any rate, it sounds like your consultant is taking it pretty easy on you guys. Try to drink the cool-aid and relax, it'll all be over soon.