Day one at Scanagile
Here are some highlights from the first day in Scan-Agile conference.
Mary Poppendieck – Leadership and Self-Organizing Teams – Incompatible or Synergistic?
- Leader’s job is to keep the team from their comfort zone!
Too often – espeacially small – teams are aiming for consensus – leaving out most of the wisdom that individuals have. The leader has to ask unpleasant questions. - What differentiates a team from a workgroup is ‘common purpose’.
A workgroup or committee is a group of people doing work together – but they don’t necessarile have the same goal. A team by definition is a group of people working together towards a shared vision or goal – common purpose. - Teams are dependant on their ability to make good decisions. And good decisions need:
1) Diversity of opinions – all people participate in decision making
2) Independence – team members may not be dependant on each other
3) Decentralization – tema members are needed to have different specializations
4) Aggregation – team must be able to draw conclusion from diverse opinions that come from different expertises - Team need two kinds of leadership:
Competence leadership – like a master teacher who tells you how to play violin
Product champion- like a band leader wo is guiding the whole group - Competence leader assists in specialization while product champion helps in aggregation
- There are two types of management: 1) Mission command and 2) Detailed command
- In agile and lean development, mission command is what we need.
- Mission commanders job (leader) is to
1) State intent
2) Set the tone & tempo
3) Make better people
4) Improve the system - Always consider the cultural aspects of any organization and remember that different countries have totally differnet biases on what’s acceptable and what’s not.
- When reading ANY theory, always consider in what country the author was raised up.
- Lean originates from Japan, Agile originates from US
Jim Coplien – Why Lean and Agile are in conflict, and how to resolve the conflicts
- Scrum is not about some fancy practises
- Even the much touted Nokia test doesn’t guarantee real, suscesful Scrum implementation
- Lean is meant to deal with complicated things while agile is meant to deal with complex things
- Productivity is actually waste! It causes queues and inventories. You need to concentrate on ROI and the flow of value through the whole stream
- Agile is about “doing just enough to get just enough quality” while lean is about “doing the least you can to achieve excellence”
- Irritating fact, that seems amazingly commonly to be surprise: A hope is not a plan.
- Scrum is not about 30% not even 100% of improvement. It’s about 2-3 orders of magnitude improvement when done correctly
Petri Heiramo – Scrum from the customer point of view
- First impressions: weird terminology and a little common ground
- Key benefits
1) Improved communication
2) Better visibility
3) Enabling changing requirements
4) Faster feedback
5) Building quality in
=> Higher ROI - Success and value cannot be managed through cost. Instead, focus on
1) User research&business analysis
2) Competence & motivation of team members
3) Amount of knowledge generated in every iteration
4) Ability to incorporate cost
=> Focus on value - Research is completely different from development. You cannot estimate research.
- Start from the definion of value and aim only towards generating more of it
- Software should not be buyed be spec but by a vision instead.
- Buying on spec causes higher cost, lower value and loss of knowledge between different phases of the project
- You need continuous integration at project level, especially on multi-supplier projects
- Never fix scope on a contract, even if cost and duration are fixed
- Enable changes and early termination
- The finnish acquisiotion law actually do not state you need waterfall. It especially makes it possible to avoid so called “open conduct” and use a “negotiative conduct” instead whenever the nature of purchase is such that the requiremetns cannot be clearly stated beforehand.
Karl Scotland – Five steps to kanban
- Map the value stream
- Visualize it
- Limit work in progress
- Establish cadence (pull system doesn’t need timeboxing!)
- Reduce the kanban tokens
- You need to keep the work flowing, not the workers busy
- Ideally, development of a new feature doesn’t start before customer has paid for it.
- Visualize the work in progress and gradually limit the number of work items in progress
- Ideally the whole team works on a single story all the time.
Ari Tikka – Understanding power
- ‘Power distance’ is an important aspect of everyday life
- It’s easy to be dependant on other people
- The other will take care of me
- I don’t have to decide
=> A tempting trap - Use of power is often constraining the system. There are two types of constraining.
- Productive constraining. Like timeboxing – constrains the time axis
- Bad constraining. Like micro-management that amplifies power distance and adds friction. Or conflict avoidance, which results in weaker decisions.
Bonus Panel – why bother with agile?
The discussion went “a bit” off-topic, but interested discussion whatsoever 
- Agility started from software development, now we need to get higher in the corporate culture
- Agile practises have worked long time, long before agile was a buzzword.
- The only companies that will survive are those capable of changing rapidly
- We are pretty good at looking into the future – but too often forget that the future will not stay the same!
Also, we feel unpleasant to look back into the past – which is where we could learn - Waterfall has itäs place and works in simple projects. Complex projects are where you need something more and agility may work. In chaotic circumstances nothing will survive.
- The biggest mistake we made was to plan year-long projects at the day-level detail.
- The trend is towards smaller teams, where everyone is required to participate in decision making. There’s no room for just hanging around.
Of course, you can follow what is going on on Twitter.