We're running a retro on agile––now it's your turn! #RetroOnAgile Edited

Julia Dillon Atlassian Team Jan 09, 2018

Hey, Atlassian Community! My name is Julia and I'm part of the Jira Product Marketing Team. We're currently running a campaign, #RetroOnAgile, to reflect with our users on past software development experiences in order to define the future of software development. 

To take part in our #RetroOnAgile campaign, we'd love if you answered one (or all!) of the following prompts:

  1. What's one thing you like about your agile software development?
  2. What's one thing you wish you could improve?
  3. In an impossibly good future, what would your software development process look like? 

Post your responses here and be sure to follow the #RetroOnAgile tag via Twitter. 

 

 

2 comments

I'll get this started.

Several users have suggested the renaming of sprints.   To what?

Relays . (Do you have another suggestion?) 

If enough people agree, Jira should consider this. It's not a technical feature, it's about how developers work and how we build sustainable healthy software teams. 

  • Sprinting conveys a singular focus on speed. Relay focuses on team speak and successful handoffs. #systemsthinking @#devops . Not.... 

ops.jpeg

  • Sprinting is exhausting. Relays get the best from all but build in time for reflection and recovery. 
  • Sprinting focuses on the finish line. Relays focus on the finish line and the collaboration critical to getting there. 
  • Sprinting treats developers like machines to be optimized and measured above all. Relays treat developers as part of a team collaborating for efficiency, speed, and outcome. 

It's a nuance and one easily ignored, but for those of us who spend m-f sprinting, it makes a difference.  

Here's the issue. https://jira.atlassian.com/browse/JSWCLOUD-16544

 

2) What's one thing you wish you could improve?

How we do things by reflecting on how others do it.

There just isn't enough information from start-to-finish on how to use Jira and Confluence on an Agile project.

I don't want to know how to use Jira or Confluence, I want to know how to best apply these tools to run the Agile project.

I can then pick the the areas that have the most pain and look at how we can change our processes make improvements.

Or if I am completely new, just apply the `Atlassian Way (tm)` and have some chance of not needing to rework the process because Jira/Confluence doesn't allow me to work that way. Ideally the information would include why its done that way so people can make informed decisions.

Ian Buchanan Atlassian Team 5 hours ago

Barrie,

At the risk of sounding defensive, I would say Atlassian doesn't document such a thing because we don't ascribe to the notion of "best practice". Inside Atlassian, there's isn't just one way of doing things that is best for all teams. Teams use practices and tools that work best for them. Outside Atlassian, the "no best practices" sentiment is also common. The idea is that Agile teams are adaptive to their unique situations. And when it comes to tools, remember the Agile Manifesto, "Individuals and interactions over processes and tools."

That said, I understand your overall sentiment as, "How do I start using Confluence and Jira in such a way that I don't make decisions that I'll regret later." For any of our products, the condensed answer is to start simply. I'll try to provide some examples, but maybe there are others in the community who can also speak from experience.

For Confluence, it's really hard to go wrong. Confluence is mostly free-from content, so it is easy to change later. Collaboration flows most naturally when people use Confluence in it's "default open" mode. Trying to create many Spaces early on, with many different permission schemes impedes sharing and creates unnecessary administrative burden. Once a Space is created for an Agile team, let people document what they value. When you have both products, the Product Requirements Blueprint is a great way to start leveraging integration.

For Jira, it's more tempting to try to model all kinds of process detail in the product. I prefer to start new Jira projects, with out-of-the-box defaults, putting practices before tooling. When there's missing information, I use labels for a while. If the habit catches on with the team, then consider custom fields. Even with a custom field, I generally prefer to avoid limiting choices with drop-downs (because many sets turn out to be slowly changing dimensions), or field restrictions like required. Again, Jira's "default open" model is about broadcasting information, not just collecting it.

Workflow is one of the most important aspects of Jira. The key is to remember there are real human implications. If a team doesn't have an agreed upon "flow" maybe it's better to start with a physical whiteboard for rapid iteration over the board layout. This can be an important step to make sure everyone on the team has a say in how they work together, before an admin codifies it in Jira.

Obviously, there's more to learn. Atlassian's site "The Agile Coach" has many great articles that balance our values, internal practices, and what works best with our products. And there are some more specific tutorials that bridge Agile to Confluence and Jira. For that matter, this community has a rich thread of Agilists sharing their own stories.

Comment

Log in or Join to comment

Stay in touch

Be the first to know what's trending on Atlassian Community