Sarah Goff-Dupont

Agreed. I use Trello to keep track of what needs to get done and when. Lots of good choices out there for helpful apps like these :o)

Wow! I'm so glad this was valuable for you. Do give Robin's book a read. He goes far deeper on this stuff than I can in a short article, and the spy stories are fascinating.

Glad you enjoyed it!

Woot! Thanks for reading, Blake :-)

Wouldn't it be great if that was how the world worked? I reckon software/product teams have the best shot at this since their deliverables are fairly consistent. Not from a technical standpoint, perhaps. But at the end of the day, you're designing, building, testing, deploying, and supporting something. So the job roles needed to make it happen are largely the same from project to project.

For other disciplines, the deliverable might vary wildly. Take HR, for example. One project might be rolling out a new tool for managing employee benefit elections, so you'd want a person or two from IT to be on the team. The next project might be a social media campaign around recruiting, where you'd pull in designers and marketers.

I suspect the "Hollywood effect" will affect every team to some degree for many years to come. If we're intentional about getting new teams off to a strong start (and patient enough to invest a little time in this!), then the "storming" and "norming" phases are smoother and shorter. That's been my experience, anyway.

Thanks for reading, Christophe!

Glad you dig it!

You bet! There's a link at the bottom to download all the images as a single infographic – you might enjoy that, too :o)

Yay! Thanks for reading.

Sure, but please include a link back to the original post: https://www.atlassian.com/blog/announcements/new-atlassian-slack-partnership :-)

The two methods aren't all that different, in truth. For our teams, the big "ah-HA!" moment wasn't so much in parsing tasks into must- should- and won't-have. It was in getting multiple teams to articulate and agree on what their collective North Star is before getting into nitty-gritty prioritization discussions. That and a few other nuances spelled out in the article. Thanks for reading!

Hey guys! I too feel that you can easily use TestNG exclusively and have all your needs covered (and then some). Its ability to co-habitate with JUnit is most useful when you are first introducing it - no need to take the plunge and do a full switch-over just to try TestNG out. Ultimately, switching over 100% will make for easier maintenance in the long run. But for teams with thousands of tests using JUnit, it's a bit project to go in and flip the contents of your assert() statements around. So co-habitation removes that (rather significant) barrier to entry.

Thanks for reading!

Hey guys! I too feel that you can easily use TestNG exclusively and have all your needs covered (and then some). Its ability to co-habitate with JUnit is most useful when you are first introducing it - no need to take the plunge and do a full switch-over just to try TestNG out. Ultimately, switching over 100% will make for easier maintenance in the long run. But for teams with thousands of tests using JUnit, it's a bit project to go in and flip the contents of your assert() statements around. So co-habitation removes that (rather significant) barrier to entry.

Thanks for reading!

Agreed, Shannon. Unit tests are a great sanity-check, but most bugs live in the integration points between different modules of your application - or integration points between you and a 3rd party service/app. Viva la integration tests! And we still need skilled QA engineers to identify those places and put their creative-thinking skills to use imagining & writing tests for the ways they will get exercised. (...and abused, as you say.) Yes, integration tests take longer to run, but that's where test multi-threading and/or parallel-running test jobs really save the day. My team was able to reduce a 30-minute job to 8 minutes this way.