Ask HN: How to apply agile to a team of 5-7 without annoying the talented?

I would recommend the following: Assume you can't get the process right to begin with. Therefore, the most important piece of your process is something that lets you modify it as you go.

Retrospective meetings (where the topic is how the work is getting done, not what is getting done) are a standard and useful way to do this (assuming the results lead to actionable change). The frequency of the retros themselves should be part of your discussion (pick something to start with ("every 2 weeks") and periodically decide if that's the right cadence). Length of sprints, styles of coding, amount of pairing, etc. -- all of these are variable based on the experience of the team and the problem being tackled. Pick reasonable defaults to start with and regularly ask yourselves if those defaults make sense given your experiences.

I could say more, but the above is the base minimum I've found for success across different teams, different problems, different companies. Cheers.

"Assume you can't get the process right to begin with. Therefore, the most important piece of your process is something that lets you modify it as you go."

Honestly, if you aren't doing this, you aren't doing "Agile", in the sense of the Agile Manifesto. If you are getting beat over the head by your scrum master with the "official Scrum process", you're not actually doing Agile. Scrum is an interesting toolbox to pull tools from; if you view it as a proscription, you're not doing Agile. Likewise for the other techniques offered by other people.

When people complain about fake Agile, I believe this is the big error that is being made.

I've done projects where we did 1 week iterations. I've done projects with story points and without. Right now I'm on a project where we're doing one iteration a month. And if you're about to jump up and try to explain to me why that's not "doing it right"... well, that's exactly what I mean. It turns out that for this project it's working great. We didn't start at that rate... we evolved into it when it became clear that 2 weeks wasn't useful for us.

See, my previous projects haven't had much use for the "sprint demo" but it's a critical part of this one, and we were noticing that neither the project team nor the customers were all that excited about the demos every 2 weeks, and we were running the risk of exhausting our customer's patience. This project isn't "customer facing" per se, and the tasks I get in this project aren't the sort where we need to do lots of UI explorations, where we need the demos very frequently to make sure we're going down the right track. Generally we get handend relatively well-defined tasks and our demos are more for convincing people progress is being made, getting feedback about priorities, and ensuring that the customers are happy and aware of what is going on. (The customers in this case are other developers in the organization.)

I offer that as an example of the sort of justification a team properly doing Agile ought to be able to provide for their choices. "Our Scrum book says" is not a reason to do something, or at least, it shouldn't be past the first 3 months.

Amen :-)

Jason's spot on on this one....and what works for one team doesn't often work for others. Hell, sometimes that's the case for individuals (some individuals are not meant for pair programming where they might excel at code reviews instead).

Also, OP mentioned something re: "minimize future modifications to already developed parts". Be aware of the technical debt you're incurring _as_ you develop it. We used to have regular sprints specifically to pay down the debt (one out of every 4 for example).

Thanks for the alert! :)

Retros are my #1 as well. Retros can derive the rest of the changes that need to be made, and if you're doing them right, the team will be making the changes together.

My next two are:

#2 Never say "Agile" again. If you can't explain an idea from first principles without defending it as Agile then you're not ready to promote it.

#3 Never suggest a change that isn't a real solution to an actual major problem. You're only going to lose supporters if you're continually trying to get them to do things that don't help them.

If you do these things, you'll have a much greater chance of success, though the end result might not look anything like Scrum, XP, etc. (and that's okay).

Is there a term that can cover those consensus bullets in my post that is more suitable than agile? I personally may be ignorant on that part.

None of your points are actually particularly necessary for agile. For example, I work on a team that does planning on demand (which is still many times per week) and deployments all day long, so we don't do iterations at all. Check the manifesto: Sprints aren't mentioned. We're definitely agile though.

I suggest you don't use the word Agile at all because everyone has different expectations of what it means and it detracts from good arguments about the right things to do. Agile should never be more important than doing the right thing.

And you can sell your ideas individually if they're worth doing. There's no need for an umbrella term. That will only tie the ideas together and create an all-or-nothing mentality.

I am more like buying ideas tbh. :) Thank you.

I call it "fast-paced, iterative" software development.

A thousand times this. The retrospective blows all the other elements of $YOUR_FAVOURITE_PROCESS out of the water.

3 things about it: if you do sprints, and they have busy beginnings and endings, then there's no harm in planning the retrospective halfway the sprint instead of at the end. Improvements can be made at any time. Also, if your sprints are weeks, consider making the retrospective bi-weekly, that's usually enough.

Second, don't skip the retrospective. It's never urgent, but it's very important. Every team is different and every situation is different, and no agile book can cover all cases. The retrospective makes you own your process, makes the entire team feel like their opinion matters. It improves both effectiveness and morale. Give it time - especially in the beginning it might last 2 hours easily. It's worth that.

Finally, do the retrospective right. You want actionable results out of it. If it's just a complaining session, you're missing out on its value.

What I usually do is this: I make a poster with 3 columns, :-), :-/ and !. Every team member has to make at least 2 green and 2 red sticky notes, on which great stuff and improvement points are written, respectively. More is OK, less is not. This forces them to really think about what could be better even if on first thought they think things are going pretty OK.

Make every team member put the sticky note on the board in the left two columns and explain what it's about and why it matters. Have people group sticky notes that are about roughly the same thing. Finally, and this is the part people tend to forget, distill a bunch of action points for the third column that will help tackle the problems in the 2nd column. Make these actionable, assignable. You might want to make them tasks in your scrum process, just like programming tasks. Without action points, a retrospective is mostly a waste of time.

If a discussion about one action point is long or very technical (discussions about how to use source control come to mind), ask the people who care about it to discuss it amongst each other present the solution a day later. This works great for distributed teams too ("Problem: the git is becoming a mess. Solution: $NAME makes a Slack channel and presents the outcome tomorrow"). Everybody who doesn't involve himself in that discussion is expected to agree automatically.

You can't improve the process super much in a short amount of time. If you make too many action points, half of them will not get done - people need to make software, too! So if there's, say, >4 real decent problems in column 2, ask the team to score problems and pick the ones with the highest score. One good way is to give everyone 3 votes that they can arbitrarily spread across the problem stickies (multiple votes per sticky allowed). Pick the 4 problems with the most points.

Consider using real stickies and not computer stuff, even if your team is partly remote. Tangible things that you move across a board somehow makes things seem more real, like they matter more.

Good luck!

I agree with parent and siblings that retros are awesome!

Initially, my team started by sitting around talking about work item by work item and other miscellaneous topics. Most of the time, this was cathartic but didn't lead to much change.

Recently, we've had a facilitator lead us through activities to drive toward 1-2 actionable outputs to work on for the next sprint. This focus has helped the team actually improve things with our process.

We've been using http://plans-for-retrospectives.com/ for ideas of the activities. A number of our Agile Coaches have recommended the "Agile Retrospectives: Making Good Teams Great" book (but I haven't read it myself).

The reason process annoys the talented is because it gets in their way. This is usually a result of having process for the sake of process and including things in your process that don't actually benefit anyone.

IMO, it's generally easier to start with minimal process and include things as needed to solve specific problems. What this requires is that you're able to identify problems as early as possible.

The last thing you want to do is come up with a 6 month plan and realize in the 5th month that things have veered far off course. This is why teams break things up into sprints. I'd suggest taking your 6 month plan, and as best as you can split all of the tasks into sprints up front. Focus on your end goal, but break it up into manageable pieces. Don't stick to these sprints either. Typically you'd re-evaluate this plan after every sprint, but there's flexibility for you to do what works.

Then there's transparency and communication among team members. This is why a lot of teams do standups, but don't think that means that your team needs to do standups. For some teams that are already good at communicating and keeping each other informed, a simple chat room may be all you need. This is more common with teams that have worked together in the past and are already comfortable with each other. If your team tends to keep to themselves then look into standup meetings. There's plenty of articles on how to run them, what's important is that everyone is brief to make them quick, and you push deeper discussions into a chat after the meeting so those not involved in those discussions can get back to work.

If you all agree with all of those points then you have more than enough to get started.

The main thing I would add is a way to improve your process (the retrospective meeting, e.g.). That way you can see if you still all agree and make small changes.

In my experience, the best teams use "methodologies" for ideas and figure out what works for them. Without buy-in, nothing works.

This is what I would have said. I've only been a software dev for a couple of years, but by far the most important thing I've experienced is buy-in. Every team I've been on that all understands and trusts our process has been significantly more successful and efficient (not to mention more enjoyable as a dev) compared to teams where members don't understand or agree with why we're doing a-b-c or x-y-z.

I think in order to get to that point of buy-in, you NEED the team to be able to say "this isn't working, so let's throw it out and try something new."

To add to this, I always find that making sure everyone understand the 'why' as well as the 'what' makes a world of difference. My favorite project manager would always ask "do you understand why we do this?" when suggesting/introducing new process, and she maintained a good deal of fluidity in our methodology so that we could adjust as needed. One big thing about Agile is quick iteration cycles - build, test, tweak - and I think that applies just as much to process as it does development.

I see I forgot mentioning how we close our sprints. Thanks for pointing it out.

Hi, I am currently ScrumMaster + Developer, we adopted "Scrum" as we needed it and the process took us more or less one year. So I try to give you some ideas from my point of view.

"A week is a sprint", I think it is to short because of the overhead you gain with Planning, Retro and Review.

"developer and designer achieve at least one goal by the end of Friday" I hardly believe tasks and/or stories can be exactly planned like this, a task with lasts exactly one week suited for the experience of the dev is hardly planable. Also a team commits to the Stories and Features not a single team member, be it a dev or designer

"The one responsible for this task is also appointed to update our weekly change log and schedule board. A single entity/manager comparing the planned schedule with actual development for 6 months is therefore discouraged" We had various ProductOwner in the beginning, it didn't work out, here I think the principle "Design is not a democracy" applies. Let one keep track of it.

"Stories should be prioritized and categorized by their importance and estimated development time" hardly possible because of dependencies. I know some Scrumdefenitions say that Tasks and Stories should be independent but in reality they just aren't.

One more tip, don't forget the review and retro and to put the outcome in the feedbackloop.

Those terms are not laws and they are put together from our collective discretion. I'm glad your feedback directly hit the (ought to be) variables. Thanks for sharing your experience.

If you don't want to use TDD, then that's fine. But make sure that you are not doing TDD for the right reasons.

The reasons to not to TDD are:

1. You don't care about the quality of your product. 2. You don't care about the quality of your code. 3. You don't care if there are any bugs. 4. You don't care if the team slows down month after month. 5. You don't care if the project is late. 6. You don't care if the project fails.

If you _do_ care about any of these things; then you should be using a unit testing discipline that guarantees that every line of production code is covered, and checked, by automated unit tests.

Oh, and make sure you know what TDD is. TDD is NOT:

1. Writing all your tests before you write any code. 2. Slow. 3. Too Low level.

If you think TDD is one or more of the above, then you need to do some more research.

Honestly, the year is 2015, and people _still_ resist the one discipline that can actually make a project come in on time, with high quality, and good structure.

How do you know it's going to be six months if you're doing an agile cycle, and the scope may change? I mean, I assume you're doing agile because the scope isn't defined - but how you can then know when it'll be delivered I'm unsure.

If it's a predefined project with a defined scope, do waterfall. No, it's not sexy, but it works if you're delivering a defined product, and gives you clear interdependency mapping and critical checkpoints to know if you're on track.

6 months defines the ultimate release date. What we are planning is having a product ready in less than 5 with almost all major features and to add as much as we can (without rushing and breaking everything) until the release date.

The good thing is, almost all major features are the ones the team already had previous experiences before. We depend on a good analysis and our experience to be honest.

So - if you've got past experience of these features, and can therefore estimate your time and resource need well, and know what major features are Must have (MoSCoW is your friend), this in my mind strengthens the case for waterfall - as you can accurately (enough) plan out a sane project plan which includes your must haves and has slots for your Should and Coulds which can get pushed out in contingency, and you can then run the whole thing with predictability, predictable budgets, predictable feature sets, and not end up caught short in a mad sprint cycle at the end.

Agile is great if you've got a weak scope, or an unlimited budget, or all the time in the world - but in the scenario you describe, waterfall would be the model I'd apply.

What if the product, once released, will keep being improved with continuous development for at least 2-3 years?

Then you do agile. It's very suitable for maintenance mode or continuous enhancement.

Some comments:

* Design and architecture tasks are stories, just like development tasks are. Definitely put in stories to develop a product architecture up-front, and do them in the first sprints. Don't just start building stuff without a plan.

* One story per week doesn't sound like enough. Either your stories are too big, or you need longer sprints. A common rule is that no story should take more than two days to complete; if it's bigger than that, then it gets broken down into two or more smaller stories.

* The main benefit of Agile/Scrum in my mind is that it provides a built-in measure of progress, as well as feedback on the quality of your estimates. There's no need to have team members monitor each other (other than pair programming and code review) -- for each sprint, you should plan how much you are going to do, execute it during the sprint, and then review whether you got done what you said you would. If not, then you need to revisit either your estimation (points per story) or your velocity (points per sprint). If you don't do this, then you're not really doing Agile.

Ultimately, if you do this rigorously (architect the product up-front, capture your stories at the start of the program after you have the architecture, spend time sizing your stories, and rigorously track completed work at each sprint review), you will get a MORE ACCURATE prediction of when you will finish the project than you would if you had planned via waterfall. If you have a fixed ship date, you can then take the choice to triage stories, based on the amount of work you know that you can get done.

Imho agile has a few points that everyone hits, sooner or later. Agile is about finding flaws and managing in a way that's beneficial for the product being developed. A corollary is that it should lead to a better process, thus leaving everyone happy.

This is what I find out happens all the time:

- in retrospective, everyone can easily pick the problems within a sprint - very short sprints burn alot of time in meetings - product owners always try to introduce features at the middle of the sprint, make sure they don't do this - it is of foremost importance to a) define a fixed number of features/items at the beginning of each sprint, and b) commit to ONLY that, unless critical bugs appear. Another corollary is that to shield developers, there should be a single point of contact between product owners and devs. better yet, ensure that devs dont get to discuss things with product owners during the sprint dev time - definition of 'done' is also extremely important. make sure that everyone is on the same page, you can even define a checklist and apply it to your issue tracker. Example: done means code pushed and reviewed by another person, tests for the feature, and any other item that should be necessary for you - estimations are crap unless the process is running smoothly. If you're doing agile correctly, either the process is smooth or you are always fixing problems in the process.

If the devs are talented, any dev can implement a feature in a reasonable amount of time. What I think agile brings to the table is a set of methodologies for a team to consistently implement features that are the most valuable to the product owner.

Optimize for two variables:

* User Validation or Knowing You Are Building The Right Thing: data flows, ui design, modes, triggers, and so on

* Tech Validation or Knowing You Are Building The Thing Right: unit tests, performance tests and so on.

Focus on selling the devs on this idea.

The rest of the process formalities can be negotiated.

EDIT2: Be careful to include all the dependencies required to fulfill the UV and TV, like scope management in UV. Every part of the process must be justified either as critical for UV or TV.

Jesus, why is the font so light on the post? HELLO, HN SITE ADMINS, are we seeing the same thing? Is this easily legible to you?

You have the power of CSS, wield it...making text darker is not a time-consuming site adjustment...

Waterfall isn't a real methodology - it was originally coined as a term to use to describe the existing anti-pattern that most software development teams used at the time [1]. Merging it with another methodology is like saying "we'll do this other thing, but worse, because we don't really want to change our ways".

[1]: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...

I would suggest making it an explicitly temporary experiment. Say you're going to do it for a couple weeks, and then see how people like it and ask which parts the team would like to keep.

Most definitely necessary.

TDD is not an option.

Curious. Why?

Please see my answer to jander. :)

For a team your size, anchor your scrum process in software configuration management using either GitHub or GitLab. Use the issue tracker to manage "user stories". Use milestones as "sprints". Use issues assigned to milestones as "sprint backlog" and issues unassigned to specific milestones as "product backlog". Take advantage of the ability to drag and drop sort issues to keep your backlog prioritized.

I would suggest reviewing the Spiral/Whirlpool development lifecycle. Agile has a lot of nasty micromanagement issues that start coming into play in its usual implementation, but the root idea of iteration is good, as you are aware. Combining iteration with thoughtful planning is a strength of the Spiral model.

Whatever you do, it will be important to review the situation after 6-8 weeks and make modifications based upon experience.

I'm so often amazed when I see posts asking how to apply agile/scrum. The real question to me is why apply agile/scrum?

What specific problem is it solving for you? Or are you just doing it because everyone else is?

If it's the latter, then you probably don't need it.

And in your case, I suspect if you're worried the talented folks would be annoyed with agile/scrum, it's because it might not be necessary process after all.

If you want to go the Scrum way you seriously need to filter in the hiring process for people who can believe in it. People who don't believe in it will be hard to convince. E.g., for them the Retrospective is not a chance to optimize the process, in their eyes it's another meeting that they couldn't avoid and the meeting itself is a burden in their eyes.

In general, I would strongly recommend starting with doing Scrum strictly by-the-book, even though it may hurt initially. Don't try to tweak the process too early, or you are likely to fall back into bad habits. (You will very much need everyone's buy-in for that, which includes the acceptance that it may be a bumpy road.)

To be clear, I'm not a great believer in Scrum as such, and certainly not part of the "if it doesn't work you're doing it wrong" school.

However, I have found Scrum by-the-book to be an excellent way of very quickly identifying every obstacle that stops you from being truly Agile, because it simply doesn't allow you to sweep inconvenient truths under the rug.

Scrum makes every weakness and dysfunction painfully obvious. What you do with that can then be your choice (including ditching Scrum because it doesn't match your needs, which is perfectly valid), but at least it will be a choice, and not something that "just happens".

And whatever you do, do not skip the Retrospective. When it comes to building a functional team, that's the most important part, everything else is just a crutch. Basically, putting 7 smart and motivated engineers in a room and having them review their own processes every iteration will most likely also get you there.

Very helpful. Appreciated!

A few pointers:

1) Implement changes to your existing process slowly.

2) Make sure each bit of process you add solves a real problem your team is having. E.g. If your team knows the domain, the clients, and the product, then having a committee decide on task priority is counter-productive.

3) Retrospectives are key (they enable 1 & 2)

The customer demo, where either working software or wireframe do design solutions are shown to the customer and team to get feedback, is the single most important aspect of agility. Demo every one to two weeks. Demo to confirm success, uncover issues, and build trust.

"TDD is not an option" and yet,at the same breath ".. unit tested.."? I'm puzzled, care to elaborate the logic behind your statements?

my understanding: instead of driving by writing tests first, they first write the implementation and then they test.

And definitely if the team agree they don't like TDD, don't force it onto them. In this situation at least.

Assuming they have a solid and reasonable argument against it and not just hand-waving and throwing toys out of the pram :-) . In which case, if they do, I would love to see it.

The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD? Because arguments against can be really simple and reasonable: "it's a risky change that will slow us down without obvious upsides", "we don't like to change, it's effortful, and stressful", "we don't have the skills to do it" etc. And that can be told of ANY change of any process/routine!

So what would you say to a team of developers if you wanted to persuade them to do TDD? (or to a manager who has influence on them)

>The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD?

Arguments don't work. You need to build the tools that let your developers actually write sensible tests (i.e. tests which mimic user stories).

Once the tools are there the process becomes fairly natural and the upsides become obvious.

Some people call this BDD. It doesn't really matter what it's called, but it's generally a faster and less risky approach to programming.

> I do not like broccoli. And I haven't liked it since I was a little kid and my mother made me eat it. And I'm President of the United States and I'm not going to eat any more broccoli.

Some people just don't like broccoli. You can force them to eat it, but they'll end up resenting you.

What's wrong in doing things the way you are comfortable doing?

It leads to lots of brittle and highly coupled tests?

It always focuses on the next immediate task which leads to going down a lot of dead ends, and a lot of local optimums that need to be refactored out?

The key benefit is that it helps you focus, even when tired or stressed. You get dozens of small wins/celebrations every hour which is great for your motivation. It also ensures you actually write tests (again handy with tight deadlines and high stress situations).

Does that make it worthwhile? Sometimes. I did a TDD exclusively when I had young kids and it was a great help with my focus. I'd recommend it to new parents, people with sleeping disorders, people in high stress work places, etc.

No TDD != lack of unit testing.

I am a big believer in unit tests, but don't like TDD much. I think it fosters the belief that you can test quality into a product. Testing should be a verification that the rest of your process has resulted in a high quality product. It shouldn't be the means of getting quality into the product.

Hmm sorry, I've never heard of TDD guaranteeing quality of a product. It _might_ mean you've delivered what's been asked of you (along with acceptance testing) but quality? Far from it. And if you're unit testing _after_ the fact, then you're just asking for trouble.

I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things. Overall, if your Sprint defines good unit test coverage as criterion for "Dev Complete" it's more than sufficient.

>I'm in the same boat. TDD might be suited for some narrow cases of development workflows. However, it doesn't do too well for others, and completely poorly for a vast category of things.

I find where it works poorly it tends to just mean you have poor testing tools at your disposal.

Plus, people have a tendency to test things at far too low a level.

> Plus, people have a tendency to test things at far too low a level.

That's usually what drives people away from TDD. A very good approach for this is described at this article by Dave Hunt: https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51e...

He's on sort of the right track but I don't believe this is true at all:

"Some have seen this solution to the shallow test problem and suggested that the ideal scope for our tests to target is the user interface, and to execute all the code in each test including framework and external components like the UI and the database.

Unfortunately the RoI of system testing is too low to do much of this. They’re slow, they’re brittle, they require careful environment setup and teardown, and they’re much more difficult to write and maintain than unit tests."

Slow is okay. It's better to be realistic than fast. You can also throw computing power (which is cheap) at slow. You can't throw computing power at unrealistic.

Brittle means either you have bugs which your test helpfully uncovered for you (e.g. race conditions) or you wrote a buggy test.

"Moreover, testing through the UI for every scenario in your code is just unnecessary"

It's almost always better to loosely couple your tests. It makes it easier to refactor the code that they test.

TDD isn't about fostering the belief that you can test quality into a product. It's just a way of focusing your mind and ensuring your code gets run as early and often as possible so bugs are caught earlier.

FWIW, most people shouldn't be unit testing at all. They should be writing high level automated integration tests.

One nice advantage of TDD is that you don't risk building a hard to test product. Of course, you have to pay attention to what you are testing and make your test cases meaningful.

I agree completely with this.

One of the problems I've seen ith TDD is that the team decides on a metric of minimum code coverage of x%. Now, in order to achieve x, a large number of basically useless tests end up being written simply for the sake of getting the coverage number up regardless of how poorly thought out those tests are.

That's not an inherent fault of TDD, of course. My point is that the mindset that seems to follow it leads to dumb things like that happening.

I believe TDD is not the only methodology where unit tests are allowed.

As far as I know, TDD suggests that the software is planned and driven by many failing test that are coded initially. A cautious developer may prefer building a feature on top of a failed (later to be satisfied) test but we worry that documenting the target product with all the necessary server and client tests may consume too much time initially. Some features that are likely to be postponed for later releases should not allocate our precious time and in the beginning, we may lack necessary wisdom to foresee it.

The other worry is that TDD in its most basic form is still a coding framework which may leave less freedom for the developer to express his/her preferred productive approach. We prefer to apply a framework on how we communicate, keep track of changes and measure our performance. The rest is left for the developer to experiment and find the most effective style for herself.

You don't have to write the unit tests up front for the full app - in fact doing that could be considered going against agility.

The way TDD is usually done is that the developer writes the tests for the feature she's currently working on, before actually working on the feature.