In February, two of our very own Atlassian Confluence developers, Anatoli Kazatchkov and Edith Tom, hosted a live webinar sharing agile best practices for software development that they’ve learned over the years. They talked about:
- Spiking new features and running shorter sprints
- Running frequent demos, dogfooding, and shipping frequently
- Empowering developers, open communication, and continuous improvement
- Using Jira and Confluence for Agile software development
The webinar was a huge success for the team. It was the first ever hosted by the Confluence development team, and over 900 people attended!
Watch the recording, share it with your team
If you’re interested in agile software development or how Atlassian builds software, this webinar is must see. Enjoy!
How do you know you’re doing Agile right?
Even though we like to tease and use the phrase “doing agile right”, there is no “right” way to do agile. If you want to measure the effectiveness of what you’re doing, then ask yourself:
- Are you shipping the right thing to customers?
- Are you shipping on time?
- Are you shipping frequently?
- Are you learning from each release?
If you answer ‘yes’ to the questions above, it doesn’t matter what exactly you’re doing because it’s ‘right’ for your team. Sure, there are agile practices to help enable us to achieve these things, but following these practices religiously and regardless of the outcomes misses the point.
How did you communicate to your developers the change to agile, and what did you do to facilitate the adoption of an agile process?
We did two things to set the team up for success during the transition:
- We chose a small, low-risk project
- We presented a list of process changes and asked the team to prioritize what they wanted to try, at their own pace
It was important that the team believe in the initial changes so that we could persist until the benefits were realized. Our early successes then helped to drive adoption of the remaining changes.
Can you explain ‘spikes’ a little bit more? How do you implement spikes so that there isn’t a huge amount of overhead?
Spikes are designed to mitigate technical risk by revealing ‘unknowns’, helping us to:
- Find problems and potential complications early in the development cycle
- Estimate more accurately
- Define scope better upfront instead of having to deal with changes midway through the project
The most important guideline is that we’re not aiming to produce a working feature:
- Plan the spike by creating a list of questions to answer
- Prioritize the list and time-box the spike
You mentioned you record all of your conversations in Confluence. How often do you look into your conversation history and when does this come in handy?
It’s not so much that we record our conversations, but the majority of them happen to take place within Confluence, or over Hipchat.
We have blueprints to guide our conversations during meetings, retrospectives, project status updates, and while gathering requirements or making decisions.
Having our discussions automatically structured and indexed comes in handy for:
- Ramping up new team members
- Understanding technical decisions in related projects
- Support readiness when the feature ships
Interested parties such as our technical writers and support engineers can also watch relevant content to be notified of changes, and can follow conversations as they happen.
As developers how important is it to understand how the product works from a technical and business perspective? Should developers be SMEs on the product they develop?
Not everything can be defined up-front, and developers often need to make small decisions during implementation.
To make informed decisions, it’s crucial for developers to understand:
- Why and for whom a feature is being developed
- The customer’s point of view
- Past decisions – technical or otherwise
Developers own their work and eventually progress towards being subject matter experts for their product, but maintaining open communication with architects, designers, and product managers is typical.
How can you encourage a ‘self-organizing’ team? I find my team treats the Scrum Master as the manager/leader, and does little without her driving it.
Instead of having a scrum master, we’ve introduced a ‘feature lead’ role within the team. The feature lead is a developer who works closely with the product manager and designer to define and prioritize work for the team.
We also have a list of responsibilities that rotate on a monthly basis, to distribute knowledge and bring fresh perspectives to each task. These responsibilities include:
- Running planning meetings
- Running retrospectives
- Reviewing slow-moving issues on our Jira Agile board for process improvement opportunities
- Investigating failures in our automated builds
In addition to these formal responsibilities, we find that certain tools help to create a self-organizing team:
- We always assign actions to someone on the team using tasks
- Meeting notes and retrospective blueprints make it easy for anyone to run a meeting
- Having a Hipchat room and Confluence space for the team allows everyone to contribute to the discussion without prolonging meetings
Can you address how your teams balance out maintenance/support issues with your development effort?
We’re constantly fine-tuning our process, but right now we follow these rules:
- All known issues are fixed before a feature gets shipped
- Any exceptions to the above rule require explicit consensus from the team
- Every feature has a 90-day warranty period – discovered bugs are treated with high priority and usually scheduled in the next sprint
- Every team allocates a representative to complete a rotation on a dedicated bug fixing team – this team fixes non-warranty bugs prioritized based on our bug fixing policy
You said that your Vietnam team also struggled with lengthy planning meetings. Why, and how did you solve that issue?
We believe they struggled to keep planning meetings and sprints short due to a simple misconception – that in contrast to a waterfall process, agile sprints mean committing to work that:
- Is less defined
- Has less of a time buffer
We found that introducing planning poker and story points quickly reduced the length of planning meetings:
- Tracking sprint velocity helped to shift from a mindset of ‘commitment’ to ‘forecast’
- If everyone agrees on an estimate, no discussion is required
- If not, discussion is useful and focused around pitfalls and complexities that may have been overlooked
How did the QA team members transition to Agile? How did their day-to-day involvement in projects change?
At Atlassian, our QA engineers play the role of quality ‘assistance’ instead of ‘assurance’.
Having everyone take responsibility for delivering quality allows the QA team to scale and also complements the agile development process.
For our QA engineers transitioning to agile, changes in their day-to-day involvement include:
- Attending sprint planning meetings and daily stand-ups to be involved in stories before development starts
- Training developers in exploratory testing and other practices to ensure quality
- Helping to organize blitz tests for risky features
- Pairing with developers to create testing notes for stories
You can read about a day in the life of a QA engineer and more in our Atlassian QA blog series.
How do you deal with the risk of making the product unstable by deploying frequently?
We use Bamboo to test the product at every stage of the release pipeline to catch issues as early as possible. Automated builds run against feature branches, production branches, and each of our staging environments.
We also take a few other approaches to ensure that quality is shipped:
- Teams conduct blitz testing for riskier features
- Product teams use an instance updated with every passing build
- Instances updated every few days are used company-wide
- The Jira issue collector plugin is installed on all our dogfooding instances to encourage bug reports
- We use feature switches to turn functionality off until it is ready for customers
- We allow soak time after code is deployed to each environment
Want to learn even more about agile?
We’re very passionate about agile at Atlassian. Take a look at our learnings on our Agile microsite. We cover everything from Scrum and Kanban to delivery.