17.1 Schedule

Our schedule for the 17.1 Agile Dialogs based on our theme:

For getting to the organizational Agility you want, which works better: an intentional transition defined and pushed by the management of the organization or a co-created approach among those impacted?”

0800 Registration

0830 Welcome

0845 Opening Reflective Question

What choices do you allow people to make as they transition to the use of an Agile approach?

0900 Your Transformation Stories
Describe your successes in Agile transformation?
How did you plan for this success?
By what yardsticks are these measured?
What do we do when we have a failure when we expected a success? (Small or large)

1015 Break

1030 Agile Transformation/Adoption Approaches
How do we get people to try out Agile practices? In what ways do we coax them?
How much time are they allowed to take to make changes in the way they work?
How do we measure progress in our Agile transformation? In what ways do we allow this to reflect on the individuals in our organization?

1145 Lunch

1300 “Off the Rails”
Based on your plans and measurements, how do you determine if your approach is not working out? What do you do?
What interventions do you do?
What effect does your interventions have?

1415 Break

1430 “What do you hear?”
Now that we have identified the how we achieve success, how we approach change, and what we do when things aren’t going well…
For approaches that are establishing an approach for everyone to follow in the organization’s transformation, what do we hear from people that indicates people (managers or working level) aren’t on board?
For approaches that allow everyone a say in how they will approach the organization’s transformation, what do we hear from people (managers or working level) when things aren’t progressing as they feel it should?

What entrenchments in position happen? What side effects does this cause?
When we have helped people move on, what caused that to happen?

1545 Break

1600 Assumptions
What assumptions are we making for people desiring to pull towards working in an Agile manner?
What assumptions are we making that cause us to think giving them a push towards working in an Agile manner will help?

1700 Retrospective + Networking Happy Hour Hour

1830 or so: Dinner plans for further conversations can occur as desired 🙂

Advertisements

16.1 Theme “For getting to the Agility you want, which works better: a defined, intentional transition or a co-created approach?”

Under this theme you will find information about the unconference – the schedule, theme description, registration information, et cetera. Once the unconference has finished, this is also where you will find the proceedings from it.

Exploring the Second Agile Dialogs Theme

You have probably seen that this Agile Dialogs’ topic will be

“For getting to the organizational Agility you want, which works better: an intentional transition defined and pushed by the  management of the organization or a co-created approach among those impacted?”

This has a lot of implications to explore:

Will your transition be pre-planned phases of improvement? Or will it be emergent in nature?

How will the people in your organization participate in the direction your Agile transformation will take? What decisions are in their control? Do they get any say?

Where is the origin for the desire to change? Is this a top-down initiative or a bottom-up? Or is it some mix?

What is driving your desire to make this transition to using Agile approaches? How well has this been communicated or socialized within your organization?

Do your people need to be pushed a bit to make the change? Would they pull their way into making the change happen?

How much resistance has been occurring? How have you been overcoming it?

This is just some of the directions this topic could take in our schedule, based on a World Café style set of discussions.

Retrospective Results

Below are the results of the post conference retrospective.  Some of these are self-evident, but a few were discussed in some amount.

Slide1

We discussed how recording as a podcast may impede conversations and open dialog. People may not be as willing to state items if they were taking a view contrary to say an employer they have.

We also discussed the idea of inviting additional experts; while people were reached out, we want open dialog and if 1-2 people come in that are felt to be anointed in the area, that may again stifle open conversation.

Lastly we also discussed about having a statement of resolution; Agile Dialogs isn’t about trying to find one ending conclusion, but simply to allow each side to discover more about the other side. Having a conclusion would make it more like a debate as opposed to dialog.

The Next Agile Dialogs

Towards the end of the day, we explored other possible topics and then gathered input on what may be good candidates for the next Agile Dialogs unconference. The call for people to join us may not exactly reflect the way these are worded. the number behind each is the number of votes it received. (Those with no numbers received no votes.)

Imposed vs Invitational Agile (Transformation) – 5

Pairing/Sharing Work/Swarming – 4

Leader as Servant, Facilitator, Controller, or Overseer? – 3

Does Colocation Matter? Is it feasible? – 3

Agile Assessments and Maturity – 3

Kill the Performance Review – 2

Approaches to Scaling Agile – 2

Hierarchies vs Other Organizational Structures (or are Hierarchies of Humans Natural?) – 2

What is “After” Agile? – 1

Games? Gasification? Good or Bad for Work? – 1

Dangers of Having Experts – 1

Titles Matter: “Master”, “Owner”, “Resources” – 1

Promise & Peril of the Various “DDs” – TDD, ATDD, BDD

Certification vs Learning; Which Certifications (if any) Are Ideal?

Introverts/Extroverts – Does it Matter?

Organizational Culture/Structures That Enables Dysfunction to Thrive

Change Agents vs Change Resistants

Agile: Strategy or End-Game?

Assume Agile or Understand Agile?

Managers: Hindrance or Enablers?

Release Planning – Necessary?

 

Learnings

ideas_lightbulbSince we didn’t have anyone on the extremes, we elected to explore the learnings a bit differently as a group.  We formulated two similar questions on informing one side what they could learn from the other side. Originally we planned to break into the two camps people indicated they leaned towards, but since we didn’t have that division, we adapted the questions to explore each side.

What would you tell a “Proestimates” person they can learn from the “No Estimates “crowd?

Remember, these are learnings that may be helpful, we’re not asking you to give up your need to estimate for any length of time, though there is a request to try dropping them at least once and see what is like with your team.

  • Estimates have a cost. Make sure the value is greater than the cost.
  • Have you assessed if your estimations actually provide value?
  • Treat estimates (of value in particular) as a hypothesis
  • A team gets more self-organized gradually, so estimates will increase in both accuracy and precision over time and yet also become less necessary
  • Estimation does not encourage sharing of risk between parties (it provides a scapegoat mechanism)
  • Estimation creates longer feedback cycles
  • The very way estimation is done matters, and some ways can turn people off to it.
  • Not estimating does not mean not planning/No estimates ≠ No planning (you change the focus of what you talk about)
  • Question assumptions
  • I don’t care if the project ends tomorrow (invokes a head in the sand attitude – the estimate produces false confidence of project necessity)
  • Effective measurement systems can improve estimates (and reduce the need for them); estimation can reduce the desire to improve the measurement system
  • Keep estimating, but ensure it is really the right level of fidelity and not overkill
  • Stay focused on working software
  • Delivering working software is more fun than doing so with estimates – try it before judging
  • It’s OK to acknowledge you don’t have perfect knowledge
  • Know alternatives to answering questions other than just estimates
  • Ask WHY you are estimating/Question WHY you are asking for or providing estimates
  • Reducing the time to estimate can give you more time towards delivery
  • Devolution is real, meaning estimation is not a necessity under all circumstances, don’t stay stuck in the past

What would you tell a “No Estimates“ person they can learn from the “Proestimates” crowd?

Remember, these are learnings that may be helpful, we’re not asking you to take up doing estimates, though as you’ll see estimation gets a bad rap due to other issues in the system.

  • The conversations that take place during estimating can help a team arrive at a shared understanding of the work
  • Don’t discards value that can come from estimates and the estimating process
  • Estimates can drive learning of a shared understanding of a task
  • Estimations make teams be better prepared for clarity and visibility
  • You need to do something to set goals/expectations
  • Estimates are scapegoats for other organizational dysfunctions (such as their misuse)/don’t throw out estimates and keep broader organizational dysfunction
  • Estimates can show many different things that could be amiss in a team/organization
  • Points, time, & $ are not the only things we estimate
  • The right estimation gives/makes better release planning
  • Lots of implied estimations occur
  • Many of our assumptions (e.g. what is most valuable) are intuitive estimates
  • Unless you measure how will the team manage?
  • Measure more
  • Focus more on testable hypotheses if not estimating

What Assumptions Do We Make When We Don’t Estimate?

inverted_flight_attitude_indicatorNext up in the 4th session, what assumptions are we making when we decide to skip estimation?  This produced some interesting results and likewise we realized that some assumptions are the same between the two, though there were some subtle differences in how they get worded. Like before we explored the first set then discussed those we felt had significant difference.

  • That we know enoughto do the right thing
  • The team gets more value from starting work sooner
  • That our work is emergent in nature
  • We can commit to a high level objective versus a detailed plan
  • We know the value of what we’re building or have a testable/measurable hypothesis of value
  • That what we are doing is actually not some form of estimating
  • Underestimating that is just another easy one, but not
  • Heroics are a given (to get the work done)
  • The estimates are wrong or don’t provide value

  • We can deliver working software frequently
  • Estimates are wrong so why bother
  • We have a collective sharing of the risk (with the business or person hiring us)
  • We can properly measure progress or ROI
  • That dependent items can identified just in time (timed w/our release)
  • We don’t need to help someone else understand why they should spend their $|£|¥|€|rubles
  • There are our limits to our knowledge (and we don’t always know those limits)
  • That we don’t need them
  • We’ve defined the system into a predictable state of behavior
  • We need to discover what we need to do
  • The team understands what the highest priority work is and can make a plan without estimation