Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Activate Agile 2014 : roles, activities, behaviours in Agile Projects
Similar to Activate Agile 2014 : roles, activities, behaviours in Agile Projects (20)
Recently uploaded
Recently uploaded (20)
Activate Agile 2014 : roles, activities, behaviours in Agile Projects
- 1. Inside My Role Kim Ballestrin, Dean Cornish, Megan Dell, Nish Mahanty
- 2. Introduction ● Roles ● Activities ● Behaviours & lessons learnt ● Summary
- 3. Roles ● Developer ● Tester ● User Experience (UX) ● Business Analyst (BA)
- 4. Development in Agile Teams
- 8. Why be an Agile dev? Accelerate your learning curve Fast feedback Benefit from a learning culture More varied, more fun
- 9. Testing in Agile Teams ● The role is different from a traditional project ● More like an analyst ● Builds thinking into the story requirements ● Still tests, however assumes the feature already works ● Focuses on Positive, Alternate and Negative path ● Looks for corner cases
- 10. The day in the life: Tester ● Checks story wall for next task o Collaborates with BA on stories o Collaborates with Devs on testing features o Exploratory tests ● Reports results ● Builds/maintains test automation ● Manages time effectively (more often than not- only 1 tester)
- 11. Who is a tester? ● Difference between checking and testing ● Testers are mischievous folk ● Professional trouble makers ● Take delight in breaking things ● Protects the customer from seeing bad things by discovering them first ● “Everything is possible”: it just might be really hard. pic3
- 12. Quality and the Team ● Quality is the team’s responsibility ● The tester is more of an SME ● Not the owner of quality ● Things are changing now with UX. ● Meet Megan! pic4
- 13. User Experience (UX) in Agile Teams More than just a pixel pusher! 1. Information Architecture 2. Interaction Design 3. Usability Engineering 4. Visual Design 5. Prototype Engineering
- 14. User Experience (UX) in Agile Teams ● Customer feedback ● Think holistically, work iteratively ● Be an active team member ● Take responsibility ● Regular check-ins with product owner ● Challenges ● BA x UX
- 15. Business Analysis in non-Agile Teams
- 16. Business Analysis in Agile Teams
- 17. Activities ● Standups and Retrospectives ● Technical Practices ● Discover and Ideation
- 18. Standups & Retrospectives ● Daily team meeting ● Energetic ● Focussed ● Help others ● Speak up ● Fast feedback loops ● Opportunities to improve ● Stop doing ● Start doing ● Continue doing
- 20. Technical Practices Test Driven Development Continuous Integration DevOps Continuous Delivery Emergent Design
- 21. Discover/Ideation ● Short duration ● Start development quickly ● Faster feedback from real Customers in the market
- 22. Behaviours & lessons learnt
- 23. Key Behaviour – be open to Learning ● Take on tasks that others are not keen to do ● Breadth of experience across roles
- 24. ● Test and Learn or experimental approaches inform good decision-making ● Clarify your hypothesis before starting the experiment Key Behaviour – be open to Learning (cont.)
- 25. Key Lessons from my career Keep Learning Be comfortable with being uncomfortable Do what you are passionate about
- 26. Key Lessons from my career Set yourself measurable goals Be flexible and ready to try new things Don’t be afraid to speak up Be honest with your employer about your long term ambitions
- 27. Information Technology ● Outcome is the result ● Learning is assumed ● Self learning assumed ● Your path is unique to you ● Rewards are typically intrinsic ● Teamwork + social skills ● Unlimited streams of work
- 28. How you work is important ● Don’t just do, ask why. ● Respect ● Results + outcomes ● Versatility ● Working smarter not harder ● Many different types of work eg. facilitation vs coding.
- 29. Managing your career ● Your career = your responsibility ● Companies will have an interest in it ● Some will help you develop it ● Some may even influence it ● Your manager’s career and your’s can be different. ● New career opportunities are always around ● Keep your interview skills and resume up to date ● Know your worth pic5
- 30. Find a good mentor ● Mentors can give you objective feedback ● Help you to navigate complex situations ● Can let you know about possibilities you didn't know existed. ● Don’t have to be official
- 31. Model Effective people ● Be aware of others and how they work. ● You’ll work with people who’ll blow your mind. ● Try it out. Make mistakes & learn. ● You’ll never be the same as them. ● You will develop your own style. ● Be courageous
- 32. Continuous Improvement ● Always be learning ● Seek feedback regularly o “3 things I can improve on” o “Did well, not so well, improve on” ● Learn from everyone. ● The hardest things learned are sometimes the best. Dean pic 7 image: http://www.intropsych.com/ch07_cognition/07learningcurve.jpg
- 33. Summary ● You can do anything ● What you’re doing at first is not likely to be what you’ll be doing in 15 years… ● Your job/role doesnt define you.
Editor's Notes
- The role is different from a traditional project in that we build in quality from the start Doesnt take changes that havent already been tested eg. unit tests, interface tests and perhaps even functional tests built on their own test cases they created during analysis The tester is a niche player in the sense they think creatively about how to destroy the software so it works for the customer
- Checks the wall, could be working with a ba on the acceptance critiera/tests, could be performing manual testing or exploratory testing, could be working on test automation 1 tester is common on an agile project, but often to as many as 6 devs. If you’re not proactive you can easily become a bottleneck- that’s why we work with the BA early in analysis- that way our contribution is done where is most effective- the learning is shared with everyone
- Software testing is about destroying, not checking. Checking is easy- finding corner cases and alternate paths is far harder and rewarding. Testers like to break things, they’re great problem solvers. The buzz comes from discovering really hard to find things, or even calling out a likely issue early and building it into the requirements, then discovering later that really helped the customer. Testers seldom ever say something is impossible, the thrill is the hunt for making it happen. It is a job for doers.
- The tester is an SME, not the owner. This is a key difference in roles between Traditional and Agile teams. Traditional teams- it is completely common to blame the tester. In an Agile project, the whole team is responsible for what gets through to the customer. Lead into Megan on UX
- More than just a pixel pusher! User Experience is a pretty broad job, covering all aspects of the way a person experiences your product. Technically the five areas are classified as Information Architecture (the way information is structured), Interaction Design (ensuring something is easily understood), Usability Engineering (making sure something actually works), Visual Design (the way something looks and feels), and Prototype Engineering (what we think the product is going to be like - a prototype). The trick to making this work in Agile is letting go of the traditional mindset of doing your piece of work for your client and then presenting it to them, or handing it over to a different department to then create the perfect solution that you’ve spent months researching and testing with customers. You need to think about all of the tools in your UX bag, and use the right one for the task at hand.
- Customer feedback An important part of the UX Designer’s role is getting feedback from customers. Then iterating based on the customer feedback. Through this process you learn where your design works well, and where it needs tweaking. This is great for Agile - it means the team can build the areas that we know will work well for customers, while the other parts are still being worked out. It also means that you can be thinking holistically but work iteratively. Don’t do everything up front and throw it over the fence. An example is working out interactions - design on an as-needed basis and work with development as much as possible to minimise waste. You don’t want to be prototyping every little interaction. Do just enough to confirm it is right with customers, and then get it into dev! Be an active team member - being a constant voice in the development lifecycle helps keep the UX vision in line - help sanity check with the testers - certain ceremonies are really helpful to focus the UX work and to flesh out details with developers and testers, which takes the pressure off the individual having to know every single thing upfront Take responsibility - be ready to pair with the product owner and BA during acceptance Regular check ins with product owner - regular check-ins with product owners on priorities, as well as the trends in customer feedback that the UX Designer is hearing Challenges - greatest obstacle is having the team go the final mile to deliver a great experience, not just create something that passes all tests and ticks the requirements boxes - we’re not there to ‘skin’ the user interface, a big challenge can be this impression of the UX role and helping the team realise we are more than just pixel pushers while the developers builds whatever UI they deem appropriate BA x UX The UX role is complemented by the Business Analyst, frequently pairing to work out the best solution to a complex workflow. But where they differ is the Business Analyst is typically the one thinking about all the other things involved or required, where the UX person is more thinking about the customer experience, ways to simplify, layout of information, and so on. The BA can really help keep the UX person grounded and make sure the solutions being designed are feasible.
- MEGAN The stand up is essentially a daily team meeting. It’s held standing up to keep it short… sounds simple, but there is much more to it than that. The stand up helps set the scene for the day. It should give you a hit of energy, not suck the life out of you. After a stand up the whole team should feel clear and focussed on the work they’re going to do that day. The stand up brings together the team to raise any blockers, things that are affecting their ability to get work done. It also gives the team a sense of the body of work being done by the entire team. It also means that problems are shared and the team is helping one another. When you’re involved in a stand up, think of these things - and feel empowered to raise it with the team if you don’t think the stand up isn’t being as effective as it could be. Retrospectives
- NISH
- MEGAN
- industry is about outcomes. Knowledge is just expected to be there to achieve the task. The outcome is what is important. Knowing someone and not delivering the outcome is rarely acceptable. All the while you need to also to be an effective communicator. Intrinsic as in eg.completing a challenging task, being given more responsibility
- So we can see that there are some differences, but there are also some similiarities Now, if it would be ok- I’d like to take you through some observations and learnings I’ve had over the last 15 years. No doubt you’ve got lots of questions - so I’ll do my best to try and advise you on some things I wish I’d been told. When you start out as a grad, chances are you’ll be given many tasks to do, my advice is to ask why you’re doing something then approach it with a “can do” attitude. Understanding why arms you to understand whether you’ve actually met the reason for doing the task. Working smarter seems obvious, but it isnt always. Sometimes you have to step back from a situation to understand that there are many tasks that add little value- its hard to do when you’re focused. Keep in mind “working hard” is different per role, facilitation is as hard as programming.
- We are seldom ever taught how to manage our career, it is something we learn through trial and error. Here are some pointers.
- Why a mentor? Mentors can often: see things you cant have experience you dont or is just impartial and objective When I think about what makes a good mentor: Impartial Objective Honest Trustworthy Skilled at something Experienced Patient
- Notes;
- Always be learning Seek feedback even when things are going well, badly- they are all useful. If you do it often enough- people wont actually notice when you fail. They’ll just see course corrections! Sometimes the hardest learnings are actually the best for us- hard though it may be.
- You have no limits, you can do anything you want, but it is upto you to make it happen. If you find yourself a in a role you don’t enjoy- do something about it. Your role may be a BA, a DEV a TESTER but that doesnt mean that is who you are. Because you were a tester yesterday, doesnt mean you are today. In one agile team I was on, we looked at what we did as 7 of us and calculated that if it were a traditional project- we would have had 36 different job titles.