Know How: Digital Thinking
•Download as PPTX, PDF•
0 likes•428 views
Know How is a programme designed to take organisations working in the arts, cultural, heritage and creative industries sectors on a journey towards placing design and digital thinking at the heart of what they do. In this presentation, as part of the THINK module, Mathew Trivett, Creative Producer behind Broadway's Near Now programme talks about Project Management methods like Scrum, User Story Cards, MoSCoW & Kanban that play a vital role in developing digital products & services. http://knowhow.nearnow.org.uk/about/the-programme/
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Know How: Digital Thinking
Similar to Know How: Digital Thinking (20)
Recently uploaded
Recently uploaded (20)
Know How: Digital Thinking
- 2. DIGITAL THINKING #knowhow15@nearnow | @broadwaycinema
- 11. ROLES Product Owner Responsible for the overall vision of the product / project. They work with the development team & scrum manager to define the vision & the core features. Scrum Master Think of this person as a process facilitator, they do not have any authority within the team. Responsible for translating the vision between the product owner & team. Their core role is removing any barriers to the development team working. Development Team The development team is comprised of a mixture of skills and work through features of the vision, delivering them incrementally. #knowhow15@nearnow | @broadwaycinema
- 12. WHAT DOES A DEVELOPMENT TEAM LOOK LIKE? #knowhow15 Developers Designers Backend Developer Engineer UI Designer Service Layer & Clear Signage Frontend Developer Architect UX Designer Interior Design, what is the quality of the space? Fullstack Developer Engineer & Architect Digital Designer Like the full stack developer, Mix of Experience Mobile Developer Transport Designer Interaction Designer Improve engagement with the space Hackers & Creative Technologists @nearnow | @broadwaycinema
- 13. #knowhow15 USER STORY CARDS @nearnow | @broadwaycinema
- 14. #knowhow15 USER STORY CARDS A method for defining features & user needs: > the person using the service (actor) > what the user needs the service for (narrative) this describes the person’s main interaction > why the user needs it (goal) @nearnow | @broadwaycinema
- 15. #knowhow15 TITLE As an / a [the actor] I want to [what is their narrative] so that I can [what is the goal]. @nearnow | @broadwaycinema
- 18. M MUST Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. S SHOULD Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary. C COULD Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit. W WOULD Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. #knowhow15@nearnow | @broadwaycinema
- 19. Show me the Money Mobile Banking App - Features Spec MUST have a secure login system. MUST allow customers to check their balance. SHOULD allow customer to move money between their accounts. SHOULD allow them to pay bills or edit direct debits in app. COULD allow them to set savings targets and track their progress. WOULD allow them to attach photos to transactions with their friends to say thanks for buying me that coffee. #knowhow15@nearnow | @broadwaycinema
- 21. High Priority Low Priority TO DO DOING DONE TEST / REVIEW / SHIP Your list of to do items for the sprint or working block. As you work through the things you take one item from the to do list and put it in the Doing Bin, limiting the work you are doing at any one time. Once it’s done, it goes in the Done Bin. This is an optional Bin. Think of it as a holding bay for review before you put out your work in front of its audience. If it is not complete, To Do items are added back into the first bin until it is complete #knowhow15@nearnow | @broadwaycinema
- 22. #knowhow15 WHAT DOES THIS ALL LOOK LIKE IN PRACTICE? @nearnow | @broadwaycinema
- 24. #knowhow15 THIS IS BORING SHOW US SOME COOL TECH STUFF! @nearnow | @broadwaycinema
- 25. # k n o w h o w 1 4#knowhow15 Mathew Trivett Producer, Near Now Broadway @mathewtrivett m.trivett@broadway.org.uk
Editor's Notes
- I’m going to being to unpack one of the terms Sarah referred to in her overview of the Know How programme yesterday.
- Agile refers to a group of project management and software development methodologies. They are an approach to managing projects that are operating in a volatile market place & recognises change as an inherent aspect of developing innovative products whether that is software or a new gallery exhibition. Agile methods provide a way to manage projects where the outcome of what you are creating & how you are going to create it is not immediately known but emerges overtime.
- This graphic is a representation of what is so call ‘Traditional’ project management or software development. It is also often called Waterfall or Cascade software development. Where perhaps each of the boxes represents a different team and the requirements are passed down the cascade at each stage. It often involves a lot of up front planning & sign off processes before it gets passed on to the next stage in the production process. Whilst this can be a useful approach in some circumstances it can be responsible for stifling creativity and risk taking. Furthermore, what happens if you get to the Deployment point and it turns out that no-one wanted your idea in the first place, or perhaps whilst you are building your idea someone else releases a competing offer or even you get to testing and a new law means that you can’t launch until you’ve met a legal requirement.
- In Agile methodologies like Scrum, the full team will work together through all these stages in a time-boxed chunk of work called a ‘Sprint’. Rather than necessarily describing the intensity of work, it describes running through a speedy iteration of the production cycle. Shorter bursts of productive work mean that a business can better pivot and respond to change. Product Backlog - This is a rich feature list that breaks down the vision of a project into manageable and workable chunks. Sprint Planning - In a sprint planning session, taking insights from previous sprints the full project team come together to plan what of the Product Backlog they feel they can complete or is most valuable in the forthcoming sprint. Sprints - A Sprint is a time-boxed period of work where the team work together collaboratively through the sprint backlog. Sprints can last from 1 week up to 4 weeks and are book ended with two other workshop / meetings. A sprint planning session and a sprint review. When using Agile methods, it is important that Sprints are kept uniform in length. Often the development of a project will require more than 1 sprint. Daily Scrum - Think of this as a huddle. Each morning the team will come together to quickly update one other on 3 key things. + What they worked on yesterday. What they plan on work on today. What might be getting in the way of them being able to work effectively or calling out for certain support or resources. At the end of a Sprint, the team will come together to have a sprint review where they will demo or share their work with project stakeholders and perhaps customers. Additionally as a team they will reflect on their effectiveness at working and whether any changes could be made to their working style or whether they need further resources. Each sprint is intended to result in an outcome that could potentially be shipped to customers or an audience for feedback and to take this feedback into planning for the next iteration.
- Here are some graphs that describe some aspects of the different approaches between Agile Project Management approaches and so called Traditional / Cascade / Waterfall project management approaches. In this chart you can see that in a Traditional Project Management approach as you get closer to release or launch the cost of change dramatically ramps up. Going back to the start and changing the nature of the project at launch would be a disaster. In Agile methodologies, change is built into the the project management approach. After each sprint cycle the product is launched in iterations and feedback from this launch is fed into planning for the next sprint.
- As you can see in the Traditional Project Management Approach there is a lot of up front cost put into planning, it might involve consultants or bringing in specialists and the planning costs gradually tail off over time. In Agile approaches the team is perpetually planning in each Sprint cycle and taking their knowledge back into planning the next iteration.
- A lot of us have experienced this in the past, you are preparing for a big event, exhibition or product launch. As you get closer to the release date, everyone is pulling all nighters trying to get the ship in order for the big day. In Agile methods, the work intensity does fluctuate with each sprint cycle and in fact increases over time but it doesn’t involve people trading a kidney to get your idea out the door.
- In Traditional PM approaches, customer value and business value is delayed until the very last minute when you send your idea out into the world. At this point all you can do is cross you fingers and hope people like it. In Agile, the team starts delivering customer & business value as soon as possible in order to get feedback & bring revenue into the company. Through the lifecycle of a product, they continue to build on and deliver value.
- Lastly, this graph describes the knowledge accrued against a development. Knowledge accrued here both refers to knowledge of what you are building and how you are going to build it, it also refers to knowledge of your customers needs and knowledge of the marketplace. Of course in Traditional PM, a lot of that knowledge is set down at the planning phase but often there are a lot of assumptions about what is needed and this can change quickly. In Agile methods, the team is always looking to bring new knowledge and insight into the team including customer need, marketplace, knowledge of what and how.
- Product Owner Responsible for the overall vision of the product / project. They work with the development team & scrum manager to define the vision, the core features & release strategy. Scrum Master Think of this person as a process facilitator, they do not have any authority within the team. Responsible for translating the vision between the product owner & team. Their core role is removing any barriers to the development team working and creating customer value. Development Team The development team is comprised of a mixture of skills and work through features of the vision, delivering them incrementally.
- Within a development team, in particular in developing digital products the team needs to be made of both specialists and generalists. This table describes some of the typical roles within a digital development team and uses the analogy of creating a building to describe their different skillsets. So how do all these people talk with one another and work effectively?
- User story cards are a way of capturing the key requirements of something from a customer centric point of view and in plain English.
- They typically feature 3 Main components: • the person using the service (actor) • what the user needs the service for (narrative), main interaction • why the user needs it (goal)
- A user story card is written on a card, usually an index card and has a clear structure with placeholders for the different components of a good user story.
- Looks like this. For more information see: https://www.gov.uk/service-manual/agile/writing-user-stories.html
- MoSCoW is another framework for defining the features & requirements of a project or digital product. It is one way you can begin to shape a brief for development, it focuses on detailing & prioritising deliverable features of something you’re working on.
- MoSCoW is an mnemonic for Must, Should, Could & Would have features or aspects of your project. Each requirement should be written in plain English starting with the relevant priority word.
- Here is an example of MoSCoW in action.
- Developed by Toyota to maintain high production performance & control production line logistics. + Focuses effectively managing work in process (WIP) and avoid flooding the production process with excessive work until tasks have been cleared. + Supported by task & project management tools like Trello
- In it’s simplest form it is composed of a series of bins that describe the status of a task within a production process. Items at the top represent high priority tasks or features, tasks further down represent lower priority items. As you burn down through tasks within a Sprint or working block, To Do items filter from Left to Right and from To Do to Done or Test.
- http://www.nearnow.org.uk