
Ask HN: How to apply agile to a team of 5-7 without annoying the talented? - diegoperini
Hi HN,<p>Our startup company is about to initiate a 6 month long development cycle for a mobile app project which will be published in Turkey next year. The team consist of back-end and front-end engineers as well as UI&#x2F;UX designers with at least 2 years of experience.<p>It is arguable that there is a supreme approach that our product will benefit most but we are eager to know our options and be able adapt ourselves.<p>We&#x27;ve done some research on how to apply scrum to our process and although in many cases, the guidelines seem beneficial, some of us argued that a plan driven scrum or some merge of scrum and waterfall may suit us better. TDD is not an option.<p>There are a few points we all agree which are:<p>- A week is a sprint in which each developer and designer achieve at least one goal by the end of Friday, unit tested and pushed to master branch in the end.<p>- Every member of the team at some point have to be given the chance to monitor the other without interfering with their work. This will help us track whether we are falling behind or some estimations that are done incorrectly or not. The one responsible for this task is also appointed to update our weekly change log and schedule board. A single entity&#x2F;manager comparing the planned schedule with actual development for 6 months is therefore discouraged.<p>- Meetings should be short but also informative enough for the team to boot a single sprint.<p>- Stories should be prioritized and categorized by their importance and estimated development time.<p>- At least some sort initial plan (not a draft but a real one) is necessary to minimize future modifications to already developed parts. The requirements are not likely to change unless our technology stack suddenly meets a major update in its components.<p>We may have studied our lessons but a kind commenter may and should suggest any methodology if he&#x2F;she finds it more suitable for our case.<p>Thank you!
======
yanowitz
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.

~~~
jerf
"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.

~~~
jander
Amen :-)

------
lojack
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.

------
loumf
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.

~~~
rbshadel
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.

------
Bouncingsoul1
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.

~~~
diegoperini
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.

------
unclebobmartin
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.

------
madaxe_again
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.

~~~
diegoperini
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.

~~~
madaxe_again
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.

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

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

------
URSpider94
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.

------
mping
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.

------
demian
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.

------
aerovistae
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...

------
Haegin
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...](http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf)

------
skybrian
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.

~~~
diegoperini
Most definitely necessary.

------
brookside
_TDD is not an option._

Curious. Why?

~~~
diegoperini
Please see my answer to jander. :)

------
mch82
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.

------
pnathan
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.

------
kethinov
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.

------
erikb
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.

------
makeitsuckless
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.

~~~
diegoperini
Very helpful. Appreciated!

------
sheepmullet
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)

------
mch82
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.

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

~~~
HeyLaughingBoy
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.

~~~
jander
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.

~~~
anthonybsd
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.

~~~
crdoconnor
>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.

~~~
jander
> 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...](https://medium.com/@davidihunt/tdd-and-
complexity-1bbd5ca51ee7)

~~~
crdoconnor
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.

