7 ms·

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

41 points by diegoperini 11y ago

Hi HN, 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/UX designers with at least 2 years of experience. 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. We'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. There are a few points we all agree which are: - 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. - 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/manager comparing the planned schedule with actual development for 6 months is therefore discouraged. - Meetings should be short but also informative enough for the team to boot a single sprint. - Stories should be prioritized and categorized by their importance and estimated development time. - 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. We may have studied our lessons but a kind commenter may and should suggest any methodology if he/she finds it more suitable for our case. Thank you!

demian 11y ago
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.
skybrian 11y ago
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 11y ago
  Most definitely necessary.
brookside 11y ago
TDD is not an option. Curious. Why?
- diegoperini 11y ago
  Please see my answer to jander. :)
jander 11y ago
"TDD is not an option" and yet,at the same breath ".. unit tested.."? I'm puzzled, care to elaborate the logic behind your statements?
- mlpinit 11y ago
  my understanding: instead of driving by writing tests first, they first write the implementation and then they test.
  - philbarr 11y ago
    And definitely if the team agree they don't like TDD, don't force it onto them. In this situation at least.
    - jander 11y ago
      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.
      - jakubp 11y ago
        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)
        crdoconnor 11y ago
        >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.
loumf 11y ago
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 11y ago
  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.
- diegoperini 11y ago
  I see I forgot mentioning how we close our sprints. Thanks for pointing it out.
yanowitz 11y ago
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 11y ago
  "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.
revmoo 11y ago
- Don't do daily stand-ups. Daily stand-ups are the dumbest thing to come out of Agile. Issues that need resolved should be addressed when they come up, not tomorrow morning. - Don't play games with estimates. Higher-ups think they can use them as leverage to micromanage or increase productivity. In the end, software is done when it's done, even if that doesn't fit inside a sprint. Don't mess around with stupid things like planning poker. You should not spend very much time on your backlog either. Run through it before each sprint, plan what needs done, and estimate those items. Don't waste a ton of time on this process. - Don't adhere strictly to the SCRUM/AGILE concepts. A true agile development process is common sense and simple. Spend time working on the product, not on your Agile process. - Don't hire Agile consultants.
makeitsuckless 11y ago
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 11y ago
  Very helpful. Appreciated!
lojack 11y ago
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.
Bouncingsoul1 11y ago
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 11y ago
  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.
madaxe_again 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      What if the product, once released, will keep being improved with continuous development for at least 2-3 years?
      - 11y ago
henryk_ibsen 11y ago
Deadlines don't work in software, "Waterfall" is a straw man that no one intentionally does, and "Agile" without alienating talented people is impossible because talented people want to set their own course, not haggle for story points. Use open allocation instead, but be honest with everyone about the constraints on the project and the ramifications (e.g. project failure and possible harm to the business) if the project isn't done right. It may surprise you, but people will do what you need them to do. Under open allocation, people are generally looser around man-struation deadlines (i.e. some executive will man-struate if this deadline is missed) but they're more likely to dig deep and hit hard deadlines that actually matter, because they're empowered to work on the important stuff without having to haggle for story points or justify it in some interminable backlog grooming meeting.
aerovistae 11y ago
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 11y ago
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/waterfall.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...
pnathan 11y ago
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.
mping 11y ago
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.
URSpider94 11y ago
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.
erikb 11y ago
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.
mch82 11y ago
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.
mch82 11y ago
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.
mch82 11y ago
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.
sheepmullet 11y ago
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)
kethinov 11y ago
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.
unclebobmartin 11y ago
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.

HeyLaughingBoy 11y ago

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 11y ago
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 11y ago
  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 11y ago
    >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 11y ago
      > 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-1bbd5ca51ee7 https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51e...
      - crdoconnor 11y ago
        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.
crdoconnor 11y ago
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.
rbanffy 11y ago
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.
- HeyLaughingBoy 11y ago
  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.

skrebbel 11y ago

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!