Long-Term Vision, Short-Term Process
•Download as PPTX, PDF•
3 likes•1,917 views
One of the criticisms we’ve all heard about the Agile methodology is that it encourages mediocrity. It clouds our long-term vision with small-scale “quick wins” and forces us to focus on gradual improvements on an unambitious existing product. This talk aims to dispel this myth by distinguishing the difference between vision and process. The truth is that Agile does not stifle creativity, it does not prevent us from looking further into the future. I’ll give real-world examples of ways teams can continue to foster their long-term ambitions whilst maintaining a process which focusses on the here-and-now.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Long-Term Vision, Short-Term Process
Similar to Long-Term Vision, Short-Term Process (20)
Recently uploaded
Recently uploaded (20)
Long-Term Vision, Short-Term Process
- 1. L O N G - T E R M V I S I O N , S H O R T - T E R M P R O C E S S A G I L E U X 2 0 1 5 , S Y D N E Y Jake Causby @jakecausby
- 2. T H E R E ’ S A C L E A R D I F F E R E N C E B E T W E E N V I S I O N A N D P R O C E S S I T D O E S N ’ T H A V E T O B E T H I S W A Y !
- 3. I D E O : T H R E E L E N S E S O F H U M A N C E N T R E D D E S I G N
- 5. I S N ’ T A G I L E A L L A B O U T T H E H E R E - A N D - N O W ?
- 6. V A L U E " R E S P O N D I N G T O C H A N G E O V E R F O L L O W I N G A P L A N " T H E A G I L E M A N I F E S T O S T A T E S
- 7. I S N ’ T T H A T A P L A N ? L O N G - T E R M V I S I O N
- 9. V I S I O N ≠ P L A N
- 10. — W I L L U N I T E T H E T E A M — G I V E D I R E C T I O N — I S N O T P R E S C R I P T I V E A G O O D V I S I O N …
- 11. P A I N T T H E T O W N R E D ! W E W A N T T O …
- 12. S O H O W D O W E F I N D T H E T I M E T O C R E A T E O U R V I S I O N ?
- 14. T I M E - B O X I N G V A L U E A G I L I T Y O V E R A G I L E
- 15. B R E A K I T D O W N , B O B B Y B R O W N H O W I S T H A T A G I L E ?
- 16. 6 S T E P S T O C R E A T I N G O U R V I S I O N S O H O W D O W E D O I T ?
- 17. A L I G N W I T H " T H E B U S I N E S S " S T E P 1
- 18. T H E R I G H T P E O P L E S T E P 2
- 19. A D E D I C A T E D S P A C E S T E P 3
- 20. F R A M I N G S T E P 4
- 21. S T A R T G E T T I N G Y O U R H A N D S D I R T Y S T E P 5
- 22. O U T P U T S W I T H L O N G E V I T Y S T E P 6
- 23. T H E V I S I O N W I L L F A I L I F I T ' S Y O U R V I S I O N — I T N E E D S T O B E T H E O R G A N I S A T I O N ' S V I S I O N ! R E M E M B E R : Y O U C A N N O T D O T H I S B Y Y O U R S E L F !
- 24. I S I T R I G H T ? W H E R E T O N O W ?
- 25. V A L I D A T E ( O R I N V A L I D A T E ) W H E N Y O U A S S U M E …
- 26. A R E L I K E C H E E S E A N D C R A C K E R S A G I L E A N D L E A N
- 27. C O N S T A N T L Y R E A S S E S S A N D R E A L I G N M A I N T A I N
- 28. C A R V E O U T “ D E S I G N T I M E ” L A R G E R T E A M S C A N :
- 29. M U L T I - S T R E A M S M A L L E R T E A M S C A N :
- 31. C O L L A B O R A T E W I T H “ T H E B U S I N E S S ”
- 32. D E S I G N A R T E F A C T S E N A B L E U S T O A L I G N F A S T E R A N D E A S I E R
- 33. S U C C E S S F U L A G I L I T Y R E L I E S O N T W O T H I N G S …
- 34. W E ’ R E A L L I N T H I S T O G E T H E R O N E : T E A M W O R K
- 35. T H E R E ’ S N O S U C H T H I N G A S B E S T P R A C T I C E , O N L Y “ B E T T E R P R A C T I C E ” T W O : C O N T I N U O U S I M P R O V E M E N T
- 36. V A L U E " R E S P O N D I N G T O C H A N G E O V E R F O L L O W I N G A P L A N " R E V I S I T :
- 37. “ I T I S N O T T H E S T R O N G E S T S P E C I E S T H A T S U R V I V E , N O R T H E M O S T I N T E L L I G E N T , B U T T H E O N E S M O S T R E S P O N S I V E T O C H A N G E . ” — C H A R L E S D A R W I N F A C T : C H A N G E I S I N E V I T A B L E
- 38. T H A N K Y O U ! A G I L E U X 2 0 1 5 , S Y D N E Y Jake Causby @jakecausby
Editor's Notes
- One of the criticisms we've all heard about the Agile methodology is that it encourages mediocrity. It forces us to focus on small-scale "quick wins" and gradual improvements rather than working on our strategic long-term vision.
- It doesn’t have to be this way.
- You may have seen this before, but if we take a look at IDEO’s lenses of HCD… Desirable: What do people desire Feasible: What is technically and organisationally feasible Viable: What can be financially viable …We can see that they purposefully state you should start with the Desirable lens when building a product. Agile does tend to be more focused on the feasible and viable lenses, which is why you need to start with the desirable lens and ensure you’re thinking bigger picture.
- I recently returned from a two-year contract working in London. I have equity in a business over there that was in the process of building some software for their internal staff. This was ok, but if we just kept plugging along incrementally and never looked to the future we would never have identified the massive opportunity we've ultimately decided to chase.
- Isn’t Agile all about the here and now?
- Nowhere in the Agile Manifesto, or in the Agile Principles does it say you shouldn't thinking long-term. It does however say, you should value "responding to change over following a plan".
- Ok, so let's look at this a little closer. What is a plan? Isn't that what we're trying to create when we think of the long-term vision? Don't we work out where we'd like to go and then formulate a plan for how to get there? For anyone who’s ever tried to follow a plan you’ll know that plans often either run over in time or budget, or both!
- Frequently this is because when you're estimating time and budget you have very little insight into the complexity of the intricate details of a project. Scope-creep is a another major component of why things don't run to plan; the temptation is always to add just this one more thing to the plan.
- VISION ≠ PLAN
- It should frame your objectives as a business in the context of the customer. It should loosely describe a target-state in terms of the goals it will facilitate or enable. It definitely should not dictate how it should be achieved.
- For example, it might be your company's vision to paint the town red. It doesn't dictate which building you paint first, whether you use rollers or brushes, or which brand of paint you should use. The method should be flexible.
- The easiest way to do this is obviously to find the budget and resources to branch away from the Agile Train and do a whole vision piece external from that rhythm. That's a completely valid approach and many orgs do this successfully, but…
- …many of us are not able to take this approach. The engineers need feeding! So how can we do it a little more pragmatically?
- I'm not a big fan of Agile for Agile’s sake. I see far more value in agility than following the rules of Agile with a capital A. If we look at agile as a way to force us to try and define the VALUE we plan on delivering in the short term; the next sprint, or the next release, then we can use this framework to our advantage. This "value" does not necessarily need to directly impact the customer at the point of completion of the task. That said, you should still be able to attribute the value that you plan on bringing to something that will end up being valuable to the customer AND is in line with your vision.
- If you can break down the tasks into small chunks (ideally somewhere between 4 hours and 4 days) then you can slot these tasks into your agile process without having to have a big whinge about never getting the time to think bigger picture. You just have to plug away at it and make sure you manage expectations with the wider team about how much of your expected velocity you're going to spend on vision and how much you anticipate spending on the here-and-now design work necessary for delivering working software.
- 6 steps to creating our vision
- First of all we're going to need to align with "the business". It's not an insignificant amount of work and if we don't have this it's going to be really difficult to justify the time and effort. Ask them to help with the topic and scope of the vision so they have buy-in.
- Then we're going to need the right people to contribute; a mature Customer Centred Design culture, in-house Customer Centred Design skills, a bold business owner and engaging storytellers.
- Then we're going to need a dedicated space; a decent sized office or a large wall which we can dedicate solely to the vision exercise.
- Grab all our existing research, insights and experience maps and start formulating a couple of high-level snippets that frame the whole project; Who are we designing for? What are the key insights? What are the key design principles the team should follow? What’s the business objective? Who are the stakeholders?
- Start mapping, sketching and designing. Use scenarios, customer journey mapping, UI mockups. We want to try and look far enough into the future to not get tied down by existing technical constraints, but not so far that flying cars are a part of it. Usually somewhere between 12 to 24 months is ideal. We need to make this polished and engaging enough to get people excited about the direction, but not get bogged down too much in the details.
- There's no point in doing all this work if it's just going to be ignored or forgotten about. The key outputs of the vision piece are artefacts that continue to enable teams to make decisions which ultimately allow the organisation to align and move towards the vision. Outputs could include a Customer Experience Promise (CXP), storyboards, or even a prototype or video. Anything that tells a great story about the direction you're headed. From a customer point of view: what will it look like, what will I be able to do, and how might it make me feel?
- We need to make sure we're regularly sharing what we're doing with all stakeholders. Talk it through. Get feedback. The vision will fail if it's YOUR vision. It needs to be the organisation's vision! You cannot do this by yourself.
- Once you have a vision, in all likelihood it will still contain a couple of underlying assumptions and it will need evolving over time. Our job as UX professionals is to highlight those assumptions and validate (or invalidate!) them.
- How do we do this? We need to identify what it is we need to learn in order to validate an assumption. Then you need to figure out the quickest and easiest way you can learn "that thing" and schedule it into a sprint. Fostering a culture that thrives on learning and experimentation will bring real value to customers sooner.
- Ok, so this is where it overlaps heavily with the lean methodology, but seriously, Agile and Lean are like cheese and crackers and I don't think you can have an effective Agile UX practice without also being Lean. It just makes sense.
- Still, once all this in place you're going to need to regularly reassess and realign to your vision. This becomes even more important on larger teams where it’s more difficult to maintain a shared understanding.
- When I was in San Francisco last month for Interaction 15, I made a point of talking to as many people as possible about the things their companies do to make sure they are thinking about their long-term vision. Companies like Spotify, Google, Twitter, Amazon, Ebay, Rackspace and more locally Atlassian, all have regular design-focused events such as "Design Weeks" or "UX University" or "Design Summits" where all the designers come together to immerse themselves in the design strategy and help workshop and tweak the vision going forward.
- At AlchemyTec I didn't have the luxury of being able to devote large chunks of time to the vision, so I had to divide my time into a couple of different streams of work; one that addressed our long-term vision and one that focused on the here and now requirement of delivering working software.
- A rough breakdown of the time I spent working at AlchemyTec would look something like this: 30% UI design, 20% Execution: working closely with engineers to fill in the gaps of delivered designs, 20% Learning: testing and researching and 30% Vision: creation / re-assess / re-align. Most people underestimate the amount of time that actually goes into the vision bucket. This is where you and your team get on the same page with a shared understanding of the direction you're headed. It frames everything you're working on. It does depend on the business and the team though, you’ll have a better idea of the ideal breakdown than anyone else.
- At AlchemyTec, a couple of key people on the product team would have a regular monthly session with the CEO. It usually went for about 3 hours. We'd discuss our vision, priorities and how releases were being received in the wild. He'd tell us all about the market opportunities that he was identifying and we'd spar on the whiteboard. It was not uncommon for priorities to shift around as opportunities arose. Sometimes our vision would shift slightly – but more interestingly – each time we realigned, our vision would became clearer to all of us collectively.
- We all create artefacts such as personas, business process flows, service design blueprints, affinity diagrams, story mapping, prototypes etc. These all speak to the importance of alignment of your team. I'm definitely not just talking about the design team. Engineers, Product Managers, Researchers, and any other immediate stakeholders are all part of the picture and they all need buy-in. A light-touch artefact that explains vision and is kept up to date when that vision shifts is a good start, but nothing achieves alignment better than face to face collaboration.
- For me, successful agility relies on two things:
- 1) TEAMWORK. Make sure you're always open and honest with your team and always strive for alignment. Share what you're struggling with. This leads to trust, and when you have trust you can cut the bullshit and move forward together. Your team mates will support and work with you, just as you will do with them, to find a solution to everyone's struggles. The most successful teams have that "we're all in this together" attitude. This is one of the reasons why it's so important to hire the right people.
- 2) CONTINUOUS IMPROVEMENT. Every team is different, every business is different. There's no such thing as best practice, only better practice. If you don't take a step back every now and then to assess what is working, what's not working and what you could try differently, your process will always be broken and you will continue to struggle with the things that are not working. You need to be very strict about making time to do formal retrospectives. This is where the true gold for continuous improvement is discovered.
- Before I finish up, let's just go back to that phrase in the Agile Manifesto: you should value "responding to change over following a plan".
- It’s exactly the same for organisations. This is one big reason long term PLANS can fail. Your vision will likely evolve over time as you learn more about your customer's exact needs or as you respond to the competitive environment. There's nothing wrong with this. Your organisation has the advantage if it's able to respond to this change. The key to this is constantly QUESTIONING and LEARNING. The more you learn, the more likely your evolving vision will be on target.
- Thank you!