Aina Alive: Personal Productivity with Scrum & Kanban
Global Online PMDay 2022 Autumn
Website: www.opmday.org
Youtube: https://www.youtube.com/channel/UCeHtPZ_ZLZ-nHFMUCXY81RQ
FB: https://www.facebook.com/edunomicaone
5. 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.
6. If we think about
it, the end
product of agile
teams mustn’t be
code.
Practices
8. 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
10. 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/
11. 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.
14. 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
15. 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.
19. 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
20. Bruce Feiler:
Agile programming --
for your family
https://www.ted.com/talks/bruce_f
eiler_agile_programming_for_your_
family
21. We should remember
that agile practices are a
great hammer, but not
everything is a nail.
– Przemysław Gochna,
PMO PPM Solution
Architect
24. 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