atman hb summary seminar #2 17.09.2010. challenges 2 atman project 9/17/2010

ATMAN HB summary seminar #217.09.2010

Challenges

2

ATMAN project9/17/2010

Product mgmt

Project portfolio mgmt

Project mgmt

Iteration mgmt

Daily work

From strategy to daily work and back again (not established)

Business mgmt

3


4


Too much multitasking and task switching• "The longer you have been in the company, the more

people ask you (to do) things"• Ignoring resource allocations

– Feelin' a bit queasy (3)

• Optimizing efficiency with respect to parallel work– Feelin’ a bit queasy (3)

• Number of ones own responsibilities– Feelin’ a bit queasy (3)

• Amount of parallel work in general– Ouch, it clearly hurts (2)

5


Insufficient resources

• "Too much stuff in parallel with several product lines"• Sufficiency of resources


• Impact of busyness to work quality – Feelin’ a bit queasy (3)

• Pipeline pushing– Feelin’ a bit queasy (3)

6


Lots of small stuff that originates from many different sources• "There are strange 'nippelijuttuja' [details] people

sometimes use their time on"• Target spending levels


7


Specialized knowledge

• Cascading effect of resource changes– Feelin' a bit queasy (3)

8


Lack of effort estimation and slipping schedules • "We should also understand what is left, not just what

has been done“• "Effort estimates are hard to make"• Activity progress status reporting


• Ongoing activities are behind schedule– Feelin' a bit queasy (2,5)

9


• ". . . , but where do answering questions to customers and similar stuff go?"

• Development activity type separation in practice– Feelin' a bit queasy (3)

The amount of effort spent on unplanned and unscheduled activities is not known nor managed

10


Try this

11


Strategy Deployment by Team Workshops• Each team gets the task to figure out what the strategy

means for their work– A senior management representative can facilitate the group

work and explain the thinking behind the strategy– Emerging strategic issues will surface during the discussion

• Each team presents their findings/ideas to the others– Enables learning from the other teams– Even senior management may get new ideas based on this

12


There are ”Portfolios” on every level

Product and project portfolio• Product/Service offerings• Product development projects• Epics

Release portfolio• Features and stories

Iteration portfolio or team portfolio• Stories and tasks

Personal portfolio or daily work• Tasks

13


Technical excellence as a prerequisite for agility/speed• Technical problems increase thrashing and slow down

new development with unanticipated problems• If we don’t know that it is done-done and it really works,

how can we even define a measure of progress?• Technical practices from eXtreme Programming are still

valid (and are especially helpful in multi-team projects)– Continuous Integration (and testing)– Automatic unit testing, TDD (and today also BDD)– ...

• Lean principles suggest that it is much cheaper to ”stop-the-line” and fix a bug immediately

14


Utilising Cadence

• Iterative and incremental, time-boxed software development is a form of cadence (rhythm) and has been around (officially) for 20 years

BUT• You can also use it for scheduling your personal calendar to

help you get uninterrupted work time– E.g. Daily scrum is a form of this (every day, same time)– In a similar fashion, schedule

• Intra/infra ”Resident” Service Desk• Q&A availability for knowledge sharing• Meetings (it’s actually more efficient to schedule meetings on-cadence

than on-demand, you can always skip the meeting, if there is nothing on the agenda)

15


Feature teams vs. Pooling resources• Feature teams are great...

– ...if skill and knowledge is equally distributed (=everybody is a guru)...

– ...but if there is a bottleneck skill, Flow thinking suggest pooling the bottleneck resources

• Typically different amounts of the bottleneck skill is needed in different teams at different times

• Pooling (or centralisation) helps in coordinating for the variability of demand to achieve better system flow

• Flexible (T-shaped) resources should also be fostered– E.g. Cross-training

16


Contrain Work-in-Progress to control cycle-time and flow• Do less in parallel to achieve more

– Faster cycle-times (with less queing time) increase the total throughput and flow of a system to create more value

• WIP purging– When WIP is high, purge low-value projects

• Control WIP by shredding requirements– Flexible requirements (also known from agile SW development)– Continuous planning probably required, which can become a bottleneck

• Control WIP by flexible resources– T-shaped people (deep in one skill, broad skill base)

• Pull them to emerging bottlenecks and queues

– Maximising resource utilisation minimises capability to react

17


Examples of WIP constraints

• Limit the amount of completed code that awaits testing• Limit the amount / time horizon of detailed planning• Limit the number of active projects in the pipeline

18


Scrum-of-Scrums for many things

• Normal Scrum-of-Scrums– Progress and impediments– Could benefit from participation of others than SMs

• Process improvement S-o-S– SMs discuss practices for improving processes– Knowledge transfer between teams

• Business S-o-S– Product Owners and/or Business Owners discuss emerging

issues and impediments– Could facilitate better continuous planning

19


Thank you!

20


atman hb summary seminar #2 17.09.2010. challenges 2 atman project 9/17/2010

Documents