Last week, in Kosice, Slovakia, the development team from Clearvision were busy building a minimum value product (MVP), using the Atlassian software products as their tool base.
The objective was to showcase collaboration and teamwork by building a brand new MVP within a three-day period. We needed to get going with little effort from an almost standing start, so the easily configurable, cloud-based Atlassian tools, such as Bitbucket, JIRA, Confluence and HipChat, were ideal for us.
At Clearvision, we use the Atlassian tools ourselves in order to be agile in our approach and keep our teams focused:
With a team of 11, made up of seven developers, two testers, one manager and the product owner, the goal is to demo our MVP to delegates at DevCon, which is where Clearvision is launching its eastern European office.
Prior to the event, some pre-planning logistics and marketing were necessary. The team also needed time to prepare – which leads me to brainstorming.
Arguably the hardest task was coming up with creative ideas the team could all agree on. With the team split across Slovakia and the UK, we spent a number of hours before the three-day event laying out our conceptual ideas.
Using Atlassian’s latest addition to its software stack, Trello, easily allowed the team to create post-it notes in order to track ideas. The team could simply log in and add a note prior to the brainstorming session, and it was easy to throw away ideas that weren’t viable, or that the team perhaps wanted to explore at a later date. Trello means there’s a permanent record of our ideas we could refer back to later. Every team member had a voice and a vote, and we collectively brought into one idea in the end.
Using JIRA Software, the team started to lay down the structure of the MVP.
This process started with identifying the core features of our application, which the team obviously considered critical, followed by the “nice to have” features.
Focusing on user stories, the team collectively planned three sessions via Google Hangouts, after which tickets were created with enough acceptance criteria to make them viable. The team needed to mock up the design look and feel, and play back the user stories to make sure the fit was what the team had visioned. Using HipChat to collaborate on our stories really helped bridge the gap between the two offices. Absolutely no emails were used, and every team member could easily review group discussions.
The final session was focused on the “nice to have” elements. While we created acceptance criteria for most of the tickets, some certainly weren’t up to the normal standard, and contained conceptual ideas and thoughts that could trigger conversations during the event.
After the team had created user stories, the discussions turned to estimating. Should we continue as we would normally with story points, or should we adopt an hours-based approach?
Collectively, the team decided to run with hours, as the team knew the underlying technology well, had a limited time frame and could effectively plan what could work in a given default eight-hour window, ticket by ticket. The estimation process took the normal route of group discussions, with the team deliberating all tickets before agreeing on the final estimate.
Once the team knew how long tickets would take, we took the strategic decision to place tickets that required a particular skill set with those with the strongest ability within the team. This is slightly different from our normal approach, as the team is one that embraces continuous learning. Therefore, during a normal sprint, it could be perfectly acceptable to give tasks to developers who are still learning a skill set, in order for the team to grow and become stronger.
At this stage, the team placed the user stories into our backlog, and we created three Kanban boards in JIRA for the sprints. There was one board for each day.
The content for the MVP was stored and distributed using Confluence. The team created a central wiki where all our documentation including architectural drawings, mock-ups, travel arrangements, contact phone numbers and email addresses could be accessed. We also created links into the Kanban boards to JIRA.
We started the day with a warm welcome from our Slovakian colleagues. The team quickly began familiarising themselves with their new environment and equipment, after which we broke into a stand-up, where we referenced our Kanban board in JIRA. We then went around each member of the team and discussed the plan, covering who would be doing what and if there were any blockers before we started work. The team consistently used HipChat and had regular conversations throughout the day, followed by another stand-up after lunch, to make sure everyone was focused and we had no blockers.
At the end of day one (with pizza deliveries in full swing), while many of the tickets were either allocated to test or done, there was still plenty to do. We still had a few challenges! Overall, though, we ended the day where we hoped to be – more or less!
I hope this blog has demonstrated the versatility of the Atlassian tools we use. They’re flexible enough that they can enable all development teams to succeed and be creative, whether they’re working at their normal office base or, as in our case, are in unfamiliar surroundings.
I will post a follow-up blog shortly, where I’ll discuss in more detail some of the issues we faced, technical challenges we had, the main demo to delegates and our retrospective.
In the meantime, why not get to grips with how to achieve performance at scale with JIRA? This white paper will give you everything you need to ensure your teams never get blocked by unexpected downtime or slow response times again!