Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Aina Alive: Personal Productivity with Scrum & Kanban

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 27 Anzeige

Weitere Verwandte Inhalte

Ähnlich wie Aina Alive: Personal Productivity with Scrum & Kanban (20)

Weitere von Edunomica (20)

Anzeige

Aktuellste (20)

Aina Alive: Personal Productivity with Scrum & Kanban

  1. 1. Nov 11 Personal Productivity with Scrum & Kanban 9 am
  2. 2. Is Agile only for Software Development? •Define ‘Working software’: The term ‘working software’ can be used to symbolize any project deliverable and does not have to be solely software. This may include designing prototypes, cost-benefit analysis or recruiting a new team. •Define ‘Customer’: The customer can be your product or services customer as well as all the other stakeholders may directly or indirectly impact the initiative. Moreover, selecting the appropriate Product Owner is very important. •Define ‘Done’: Collaborate the stakeholders, sponsors, and Product Owner to identify what serves as ‘done’ for each story or deliverable. For example, it can be just implementation or implementation plus approval from a certain authority. •Measure Business Value: Asses the business value of the work involved using defined metrics. These metrics can be used for measuring factors such as risk mitigation factor or total savings. •Expect the Unexpected: Projects are meant to undergo various changes throughout the project development lifecycle. This can be the project scope, process to carry out an activity or the goals in general. Munshi recommends going for shorter iterations, joint workshops, continuous reviews as well as consistent and transparent communication.
  3. 3. If we think about it, the end product of agile teams mustn’t be code. Practices
  4. 4. Being Agile also means to be prepared for the unknown, be aware of black swans, react fast, act proactively, look into the future, keep up with trends, experiment, fail fast, learn continuously, be awesome
  5. 5. Lonely Planet legal team case • KEY BUSINESS CHALLENGES FACED BY LEGAL AFFAIRS • 1. The legal team was commonly working late, sometimes until midnight. This was beginning to cause burnout and frustration. Working across multiple time zones supporting London and San Francisco offices did not help this! • 2. Job satisfaction was waning, with few of the improvement ‘project’ ambitions identified in the annual off-site planning session ever achieved in the face of day-to-day demands. The backlog of work to be done was substantial, and a weight on their shoulders. • 3. Some of that work backlog involved significant changes to document structures (eg contracts and work orders) to cope with an increasing adoption of agile methods of working across the whole Lonely Planet enterprise, with many old contracts obsolete in a ‘trust, time and materials’ world. • 4. A good deal of the legal team’s work was found to be generated by ‘failure demand’ (as John Seddon terms it) where rework on a detailed contract written without all the parameters of the deal known (eg too early) meant abandonment of much of the work produced, for another document structure entirely. For example, it is fruitless to iterate a profit-share based partnership agreement into an outsource agreement. • 5. The ‘drop-in’ nature of demand from internal clients, and the general assumption that lawyers sitting quietly at their computer screens were not really doing anything productive, so could apparently be interrupted, was highly frustrating. • 6. Frequent task swapping was the stock in trade of the team’s approach to managing multiple priorities. • 7. The lack of transparency of priorities of work being done by the team led their clients to generally assume they were not working on anything as important as their need for a non-disclosure agreement or contract review. An internal survey suggested they were sometimes perceived as a blocker, rather than a partner or valued advisor for the business people needing legal support. • 8. The productivity of two retained external legal services suppliers (a small generalist firm, and a large specialist group) was low, with little work actually farmed out – it was easier to just ‘get on with it’ and have the internal team members do it themselves by working late, rather than briefing and supervising a partner’s work. • 9. The costs were not managed holistically – internal staff resistance to engaging the external partners was based on the false perception that the internal lawyers were free of charge, whilst the external lawyers cost cash. • 10. Internal clients would commonly provide deadlines for work that were ahead of the real deadlines, in order to force prioritization of their contract over other people’s work. Similar exaggeration of deal value was also evident, to get work prioritised. • 11. The professional ethics and standards of lawyers is a natural source of perfectionism, which is not well suited to fast-moving environments where an internal client may come to them for advice and service at an early stage in their process (ie not knowing all the facts). This also leads to rework. • 12. There was not universal support for the work priorities of the team being advertised on a board like an agile board in a public place – there was a perception that would compromise their position as advisors to the multiple internal clients. This provided an interesting cultural constraint to the adoption of agile. • http://lunatractor.com/not-just-an-it-thing-our-book/lonely-planet-legal-affairs-smart-people-lean-work-practices-innovation/
  6. 6. Lonely Planet legal team case The most notable components of systems thinking, lean and agile that were implemented include: • The team’s entire workload is represented on a single whiteboard. This has resulted in greater respect for the team’s ability to carry a diverse and heavy load, keep it prioritized and deliver value in a weekly iteration with an element of continuous delivery of value – there is no ‘release’ as such. • The initial exercise to ‘out’ all the hidden demand resulted in 2 whiteboards completely wallpapered in backlogged projects and tasks of a myriad of types. • A new style of agile board had to be invented – recognisable to IT practitioners as having a backlog; a ‘blocked’ section; an ‘in progress’ section; testing (document with client); and ‘done’ columns; while allowing for individual lawyers having specialised skills (eg international law, digital contracts), each team member owning their prioritized backlog and daily work list. • The team analyses productivity through a shared system of sizing work – an agile tool based on ‘points’ of effort per a card. The team use a Fibonacci sequence for sizing work, and calibrate against known pieces of work, allowing for variance around the difference in time taken that will occur if an expert lawyer picks up that card, versus say the Paralegal. • Work is tracked all the way to it turning to cash. Cards stay on the board while they are back in the hands of the LP party who requested it, as well as the third party. Blockers to executing the contracts or agreements are monitored by whoever worked on that card. The team uses a questioning approach akin to the ‘5 whys’ of Systems Thinking to understand the root cause of any delayed work. • The team has a daily standup at 9:30 to discuss the day’s work and evaluate any new priorities. This takes around 15 minutes. The standup thoroughly reviews the do- ability of the remaining days of work given the output to date that week. • Other teams requiring legal work now bring their cards/stories to the Legal Affairs board – leaving a placeholder card back on their originating agile board. These are fed into the board by the team from a ‘daily news’ section at the left side – mostly weekly (but sometimes daily) by re-prioritising other tasks. • Prioritisation by business value is largely delegated to the Legal Affairs team, who act as the trusted broker for the many business stakeholders. The transparency of their priorities on the board helps this considerably. • The board has an element of Kanban in that work in progress (WIP) is limited by the size of the column for each team member (after running for a year, cards now conform to a more regular size in points), and the 1-week backlog ‘box’ as well. Stories have evolved to being of similar size, but there is still variation.
  7. 7. Define the Task (https://clickup.com/blog/scrum-personal-projects/) Business Task: Provide clear requests to my website designer Home Task: Clean and organize my kitchen Personal Task: Request a new credit card
  8. 8. Create a Backlog List • Business Task: In order to provide CLEAR requests I need to research lots of websites; identify what I want for mine, prioritize by MoSCoW • Home Task: You can divide cleaning and organizing the kitchen into smaller tasks. Those might include dividing the kitchen into sections, eliminating trash and setting aside items for donation, building new storage shelves, purchasing storage containers, putting everything away, and a detailed clean and polish • Personal Task: This might request endless wait calls on a line with your bank; preparing documents with the secure information in advance etc
  9. 9. Sprint Planning • Business Task: I might decide to set up 2 week sprint to provide a high-level research; identify what mandatory items I have on my website, consult with the developer, got feedback, keep working on details (like text) while she works on a high level design. • Home Task: I decided to have a one-week Sprint to divide my kitchen into three sections and triage one (dividing all objects into keep out, store away, trash, or donate) each day. After spent another 4 days donating stuff. • Personal Task: I decided to have a one-week sprint to call the first time, get questions from the bank, identify the best day/time to call another time, get all information needed, call again.
  10. 10. DAILY SCRUM SPRINT REVIEW RETROSPECTIVE
  11. 11. Differences of Scrum & Kanban Scrum Kanban Timeboxed iterations prescribed Timeboxed iterations are optional. Can be event-driven instead of timeboxed Team commits to a specific amount of work for this iteration Commitment is optional Uses Velocity as default metric for planning and process improvement Uses Lead time as default metric for planning and process improvement Items must be broken down so they can be completed within 1 sprint No particular item size is prescribed Estimation is prescribed Estimation is optional Cannot add items to ongoing iteration Can add new items whenever capacity is available Prescribes 3 roles Doesn’t prescribe any roles A Scrum Board is reset between each sprint A Kanban board is persistent
  12. 12. Bruce Feiler: Agile programming -- for your family https://www.ted.com/talks/bruce_f eiler_agile_programming_for_your_ family
  13. 13. We should remember that agile practices are a great hammer, but not everything is a nail. – Przemysław Gochna, PMO PPM Solution Architect
  14. 14. 12 Principles of Agile Methods Customer Satisfaction Welcome Change Deliver Frequently Working Together Motivated Team Face to Face Working Software Constant Pace Good Design Simplicity Self Managing Reflect & Adjust
  15. 15. Q&A

×