Keeping the JIRA team on track: Five techniques we use to boost both speed and quality
•Télécharger en tant que PPTX, PDF•
0 j'aime•1,155 vues
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Keeping the JIRA team on track: Five techniques we use to boost both speed and quality
Similaire à Keeping the JIRA team on track: Five techniques we use to boost both speed and quality (20)
Plus de Atlassian
Plus de Atlassian (20)
Keeping the JIRA team on track: Five techniques we use to boost both speed and quality
- 2. Keeping the JIRA team on trackFive techniques we use to boost both speed and quality 2 Paul Slade JIRA Dev Manager, Atlassian
- 4. #1 Paper Prototyping 4
- 5. #1 Paper Prototyping 5
- 6. #1 Paper Prototyping 6
- 8. Design fast. Design cheap.7
- 9. #2 Tight Teams 8 Early 2009 Late 2010
- 11. Skills exchange
- 13. Evolve features
- 15. Team Leads still code
- 16. Fast
- 17. Cohesive
- 19. Change teams around – not that often
- 20. Autonomous teams go faster12
- 22. JIRA 4.0+ shifted to the user experience
- 23. Bring in QA specialists and we had the perfect stormImage by opensourceway
- 24. #3 Scaling QA 14
- 25. #3 Scaling QA 15 Only 5 issues can be waiting for a Quality Review Developer On Test - DOT
- 27. Quality is everyone’s responsibility16
- 29. Inner loop speed
- 30. Grease and oil change
- 32. Blow off some steam
- 34. Let your teams run a de-frag over their processes and tools19
- 35. #5 Ship 20% time Use their product and customer knowledge Devspeed keeping devs super effective Trained to make calls Called 20% time Sounds awesome 20
- 36. #5 Ship 20% time Not good enough 8-10% time Solo projects Ambitious? Stall at 80% done! 21
- 37. Ship 20% time 22 = +
- 38. Wrap up Paper protoyping Tight teams Scale QA 23 Dev speed 20% time is a team effort
- 39. “From paper to product… #summit11” 24
- 40. Thanks, Surely there is time for questions… 25
Notes de l'éditeur
- Thanks for joining me here today, I realise I have competitionThe JIRA team are an unruly bunchTeam made up of the old guard and the young gunsThe old guard – reliable, seasoned campaignersThe young guns – learn as much as they can to knock the old guys of their perchMy role in this menagerie?Push the old guard to step outside comfort zone, Encourage young guns, absorb wisdom, challenge status quoTry and keep the team at the edge of chaos,Yet deliver the quality you guys expectWhy are we all here today?Besides working up a thirst for tonightI want to present to you some strategies we use to control and encourage this great team’s unruly behaviour
- Before we start on techniques let’s talk team evolutionI joined a team of around 12 people in October 2009Just after the JIRA 4.0 releaseOver the last couple of years the team has grown by almost 300%.We have welcomed greenhopper to the fold.We have welcomed a several front end specialists. We have welcomed designers, QA specialists and we have welcomed many a java dev.At the same time as getting bigger we are getting faster.In the last couple of years the time between major releases has dropped by over 100 days. These days we hover around 3 major releases a year.If we are getting bigger and faster. How do we ensure we keep up the quality? This what the 5 techniques are all about. That balance between speed and quality.
- This first technique is about speed.View Issue page in JIRA 3.13.5, One possibility for how we envisaged the view issue page after JIRA 4.1How long to arrive at this design option?It took 3.5 months to get here.Big changesNew visual language Lots of designer and founder time\\Once we got here we had to introduce this to most of the dev teamImplementation didn’t hit full swing for another month.Many other parts of JIRA needed a similar visual redesign. No way we could afford to spend 3+ months for each design effort.We knew tackling the JIRA Admin UI in JIRA 4.3 and JIRA 4.4 . We needed a way to iterate over design options faster.Needed a way to involve more to the dev team - bring the dev team on the design journey.
- We tried a technique called Paper prototyping.Bring whole team together to tackle a particular user interaction problem.Good example – from JIRA Admin UIConfig is being shared across multiple projectsChange will effect multiple projectsWe paired people up into teamsuse cardboard, overhead projector sheets, scissors, glue, tape, lots of pens to construct interactive designs very quickly.Easy to create dialogs, menus, buttons, easy to show animations, hovers, elements being disabled.Important aspect - timeboxTeams get 5 mins to create a design, then each team has 5 mins to present their design.Funny to watch people grab dialogs, menus, etc from other designs in real time as they demo’ed their design.Group Critique, pick favourite elements, we carry those forward into the next iteration. We would iterate 5 or 6 times. Designs started converge With this technique , we producing designs at a great rate, they were very cheap to create and they got the whole team involved in UX design process.
- And here are some of the results.Actual implementation has moved beyond the paper prototypes but importantly the whole team was part of that evolution.With this design immersion – noticed developers did not have to run back to the designers for every small decision. Even most hardened java dev had a new appreciation to how create an awesome user experienceAnother big win - Because devs were so involved - designs had to pass the “is this technically feasible test” very early.Most importantly we had speed. We moved from paper prototypes to mockups that connected to live JIRA data in a matter of weeks.
- If in your teams user interface design takes a long time and it happens in a bit of a vacuum, away from developers, then I recommend you give paper prototyping a go.TRANSITIONPP is a technique has only been used by a couple of teams in JIRA. That implies that we have some teams that do UX heavy features and some that do not.Next we will explore some of the changes we have made to JIRA to how are organised.
- Demonstrate the dramatic growth in the JIRA team over last couple of years.The small, intimate sessions at the local bar are long gone.We are actually bigger again than this 2010 picture indicates.Can anyone guess 2010 picture is all about? Heard of Josh Skinner? Come grab me at the bar. Smaller - centralized made sense. Communication overheads were lower, decisions were more consistent. Grew - centralized decision making - slowing us down. Past we formed teams around feature work - existed for a release. This much structural change – lowered team cohesion - slowed us down.Obviously - change - what was the right team shape?Let’s look at some of our teams - forces that shaped them – things they have in common.
- First up are the Ignite team and the A-team.Mix of front end specialists (javascriptdevs and HTML/CSS guys) and java all-rounders. Keen paper prototypers - are affectionately referred to as the “colouring in teams”.When creating these teams - conscious decision not to lump all out front end specialists together.Front enders and java devs as close together as possible - knowledge sharing and skills exchange. Good about this – front enders can fix their tests, java devs - creating well designed javascript - diagnose most CSS problemsTeams do the features that have a large user interface component – view issue, issue navigator, dialog, Admin UI.So team - owe their existence - increased investment in the JIRA user interface. Example of – a structure - aligns with product roadmap themes.
- Contrast - two colouring in teams - Dream team and engine room team exist because - JIRA is on the maturity curve.Dreamteam -evolve existing features - tackle requests that you guys raise in jira.atlassian.com.Dreamteam -generalists. Skills necessary to deliver features end to end. Have deep knowledge of JIRA’s business rules – our JIRA historians.Engine Room – hard core Java devs. New services, Common component upgrades, performance, scalability, API, health of JIRA code baseFor the last year - Engine Room has been delivering features like Embedded Crowd and more recently User timezone support – BUT - exist as a response to our large complex code base.
- In your quest for speed – teams may be organised differently - things that teams have in common – I think make them successful.Autonomous - own their own backlog - decentralised technical and priority decisions as much as possible.Team leads - people management responsibility – scalable approach to ensuring people are happy.Expect - Moved best people into Team Lead positions – took time to for them to adjust to coding less. Question remained – how much can they code? Best guideline we have – cannot commit to stories in current sprint.Led to the emergence of Black Ops – teams leads tackling work that is not time critical and while in progress will not stop shipping. Many support enhancements are black ops, classic in 4.4 - expose SOAP services via JaSON-RPC.Teams act more accountableTeams trust each other more, watch each other back, they are more cohesiveTeams instinctively understand their strengths and weaknessesSelf organising - tailor their development process - some variant of SCRUMWhat we have then - structure we can scale as the JIRA team continues to grow..
- We have looked at why we have the teams we do in JIRAcharacteristics make those successful teams – things to look when structuring your teamsTRANSITIONSmall teams, running fast.I imagine it is a challenge for you guys as much it is a challenge for our teams – regularly meet sprint commitments without compromising on quality.Let’s talk about how QA has evolved in the JIRA team
- Hard to believe!! Few years prior to JIRA 4.0 - no user experience focus.Busy making JIRA a feature rich issue tracker – UX complex - inaccessible to all but the most frequent user.With JIRA 4.0 and 4.1 we got the UX theme rolling.To implement our 4.1 view issue changes - Deal with tech debt in front end codeBattle cross-browser variability - previously had not impacted us.We were cautious at first – I am sure you agree – 4.1 release shows this. What we tackled in 4.1 we tested thoroughly – with the help of our expanded QA team (to 2 people that it). End of 4.1 the JIRA user experience quality bar had been raised significantly. We had a team determined to make any JIRA UI changes as polished as possible.Enter the JIRA 4.2 release – teams had grown - more ambitious -UX features.More work in progress - more stories were being pushed to QA.QA were getting further behind. Bugs raised for old stories. Excited by how 4.2 features were shaping up - dev team further forward. QA tested – raised more bugs - bugs not fixed - bug pile grew – we had the perfect storm.
- By middle of the 4.2 release we were pushing a huge pile of bugs ahead of us.When we thought we were approaching the end of 4.2 we were actually approaching the middle.Done 14 weeks of feature development, what followed was 14 weeks of bug fixing and polish.We had let things get out of control. Expected with 2 dedicated testers and around 20 developers. All thesmall issues were addingup to a overall crappy experience and nobody wanted that.Wallboards counting down bugs, Spreadsheets tracking bugs raised and completion ratesAll in an attempt to predict a release dateFrankly it was a very frustrating, painful periodWe needed to change something.
- Needed to force new story work to stop - needed was some back pressureNumber of bugs - natural back pressure – not raised quicklyenough, old storiesNot enough people doing what our QA specialists do – needed to distribute testing.**** starting in JIRA 4.3 we created a new role - Enter the DOT – the developer on test.Easy right, when issues reach the Quality Review step inwflow, devs (different to original) perform the manual quality review. More easy than it sounds. Easy to assume someone else will do DOT’ing. Take the emotion out of the decision to DOT. Need a constraint on the system.We borrowed - success - using Kanban to run our bugfix or maintenance work. **** So we put a limit on the number of issues - waiting for Quality Review at any given time.Immediate results – Devs less emotional about dot’ingSharp drop in the number of open bugs.Less stories rejectedQA specialists – less testing – more coaching.No more crazy spreadsheets – more predictability.While story velocity went down – good thing - previous was really an illusion. Teams really started meeting their sprint commitments, the product was shippable at the end of each iteration, things became more predictable and team motivation went right up.
- We had set out to solve a quality problem and we had solved a speed problem along the way. It was a simple yet significant change for the JIRA team.TRANSITIONWith these changes teams started meeting their sprint commitments more regularly.Better at adding new features to JIRANew features means more tests and a bigger build.Let’s look next at how we face this challenge
- Let’s switch back – topic speed .Talk about developer effectiveness.Last topic - DOT-ing and QA - forgiven for thinking that manual testing is all we do. Not true at all - in JIRA we have unit tests, functional tests, selenium 1 and selenium 2 tests, javascript unit tests, performance tests and tested platform matrix tests. Lots of testing - we constantly battle to drive down the CI feedback time on Bamboo - sit at around 40-50 minutes and we are not happy. Slow us down big time.large codebase - Maven 2 to manage our dependencies. Combine these two - stretching the IDE to its limits. Too much IDE scanning and indexing slows us down too.Only two examples of things that significantly impact to our developer effectiveness.Hands up if you have similar struggles?For us the Devspeed sprintis a chance for the team to fight back. It like a grease and oil change that we do at the end of each release.It presents a great opportunity for devs to get refactor that ugly bit of code or that flakey test. Devs can clean the house and set the table in preparation for the next release.
- Devspeed sprint very motivational for the team.It is all about variety. It is also a chance to fix the things that really tick them off. We play the SCRUM game with Devspeed. We have a backlog in GreenHopper. We choose a different developer to plan, prioritise and run each devspeed iteration. It’s a great chance for devs to flex their scrum master muscles.
- Remember that this is just another aspect of our quest for more speed.If you start a devspeed program then make sure is it easy and quick for devs to capture their hassles.Collect a lot of dataLet you teams get into a rhythm of regularly defraging their processes and tools.TRANSITIONWe have spent a lot of time talking about team level techniques.With all this focus on teams how do we ensure individuals can be surprisingly awesome?
- Final topic for today I see as the ultimate accelerator.It is a process that has been in place at Atlassian for a couple of years now.Developers use the product knowledge, customer context,usability awareness - gained from techniques like paper prototypingIt is where developers are audacious in the projects they tackle because they have an effective toolset and development environment around them. This is courtesy of initiatives like dev speed.This is where developers choose what they want to do – from scratching a technical itch, adding a feature to an existing product, or creating the next big thing. Prioritisation and decision making comes easy - devs learn in their tight, autonomous teams helps.At Atlassian, like many other places, this is called 20% time. Who has 20% or has something equivalent where they work?If you do, you know how hard it is to get right, if don’t here are some tips to make it work.Developers spend 20% of their time on a project of their choosingSounds awesome. Think of the speed of delivery. A huge number of projects going on across the organisation, a constant stream of features landing on products – odd new product idea popping up too.Does it really work out this way?
- Given the massive investment in 20% time - in my opinion it is not working well enoughFor a start 20% time is not really taken, it is more like 8-10% time. Due to the pressure to create feature-rich releases – but can’t 20% time help that?Projects are generally not that ambitious. The number of left field things is low.Projects are typically solo venturesWorst of all most projects stall at 80% complete. Not done enough to be included in a product - they get retired and the developer moves on to something new.This is a killer right? All this potential to increase speed, all this developer motivation and inspiration is being wasted. The worst outcome is that developers loose faith in the 20% process, they stop dreaming up projects and they stop participating.For those of you who have 20% time, I wonder if you have seen these things tooWhat did we do about this?
- Our focus has been simple – it is all about delivery, about shipping 20% projects to customers.First we raised the visibility of 20% projects. did 20% time during a sprint – must demo at showcase.During these demos the projects are vetted by the crowd – there is a certain amount of peer pressure to make progress. People also enlisted help in their projects.Next - need a plan to get the project into trunk - every demo session you need to explain the work remaining before the project can go into trunk. Finally projects - a soft landing when they hit trunk - shift from being a solo venture to being a feature adopted by the team. They need to go through the same DOT’ing and the same polish. Early days of implementing these changes - a significant increase in the number of 20% projects being shipped. Here are some examples for 4.4HTML Email templates – Sean hated the current emails on iphone– team effort to get into trunk.Editable custom field options – Trevor (like you) was frustrated by this. Great blitz testing and verification by whole team to get this shippable.Recent occurrence of product managers not putting stories on the backlog because they were relying on a 20% project landing – not sure yet how I feel about that!!If you are starting 20% then remember visibility of projects and working as a team to get projects shippable is key.
- We have talked about lots of stuff today.Really the underlying theme is the quest for a balance between speed and quality.We have talked about how paper prototyping gets us from a desire to improve the UX , through mockup, to implementation much faster.Tight, autonomous teams really speed you up. Scaling QA - making quality everyone’s responsibilityMaking time for devs to eliminate their hassles, about making the inner loop as fast as possibleFinally we talked about effective 20% time and we recognised that 20% works best the team matches the efforts made by the individualIf I had to summarise the JIRA team’s development ethos, trust your instincts, be crisp and courageous in every decision you makeand strive to surprise customers with JIRA’s awesomeness.