Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Agile coaching exchange 24th september update on 30th september – john coleman

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Prochain SlideShare
The art of execution
The art of execution
Chargement dans…3
×

Consultez-les par la suite

1 sur 9 Publicité

Agile coaching exchange 24th september update on 30th september – john coleman

Télécharger pour lire hors ligne

More Agile changes for Scrum are either based on "just do it", Kotter style change leadership, Senge style change evolution, Cohn style rollout, Larman/Vodde style rollout, or Schwaber/Sutherland style rollout. Scaling models also get considered. Indeed there are many theories, but usually from two schools of thought. There may be another.

There is a lot of psychological research to suggest that as humans we are highly influenced by the crowd and by "social proof" from people we respect. So, often we imitate them. This explains why mindset shift gets reversed after people sleep on our coaching and why coaching needs repetition/refocus.

John Coleman shared ideas on Agile behaviours. Let's say it's an interesting twist of psychology, change theory, and what we need to do to make good Scrum and other agile methods "go viral" in the enterprise.

Enter the Chalfont Project, Leandro Herrero and Viral Change (TM). And we have an Agile angle from John Coleman. But to be clear, there is only one version of Viral Change(TM) and one must be licensed by the owners of the method to use it. Contact the Chalfont Project or associate companies for more details.

The catch with the exercise in this slide deck is you need to pick 5 or less non-negotiable behaviours per method. Maybe some are missing?

Wouldn't it be wonderful if as well as principles & values, that the Agile Manifesto also had behaviours, as in things that people do at a basic level?

More Agile changes for Scrum are either based on "just do it", Kotter style change leadership, Senge style change evolution, Cohn style rollout, Larman/Vodde style rollout, or Schwaber/Sutherland style rollout. Scaling models also get considered. Indeed there are many theories, but usually from two schools of thought. There may be another.

There is a lot of psychological research to suggest that as humans we are highly influenced by the crowd and by "social proof" from people we respect. So, often we imitate them. This explains why mindset shift gets reversed after people sleep on our coaching and why coaching needs repetition/refocus.

John Coleman shared ideas on Agile behaviours. Let's say it's an interesting twist of psychology, change theory, and what we need to do to make good Scrum and other agile methods "go viral" in the enterprise.

Enter the Chalfont Project, Leandro Herrero and Viral Change (TM). And we have an Agile angle from John Coleman. But to be clear, there is only one version of Viral Change(TM) and one must be licensed by the owners of the method to use it. Contact the Chalfont Project or associate companies for more details.

The catch with the exercise in this slide deck is you need to pick 5 or less non-negotiable behaviours per method. Maybe some are missing?

Wouldn't it be wonderful if as well as principles & values, that the Agile Manifesto also had behaviours, as in things that people do at a basic level?

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Publicité

Similaire à Agile coaching exchange 24th september update on 30th september – john coleman (20)

Plus par Orderly Disruption (16)

Publicité

Plus récents (20)

Agile coaching exchange 24th september update on 30th september – john coleman

  1. 1. VIRAL CHANGE™ CONSIDERATIONS FOR AGILE IN PRACTICE  Viral Change™ from Leandro Herrero of the Chalfont Project  Let’s map out the highly influential, highly connected trusted people – a small group of great people can do great things. Let’s ask them for help!  Let’s agree non-negotiable behaviours for each method on an imaginary method continuum  Let’s accumulate memorable & transferable stories of good behaviours for “people like me”  Our influencers will lead by example and provide “social proof” for imitators  Backstage leadership  Formalized informal community with no limits on tools to use  Let’s be clearer about Iterative and Agile methods for people who need that clarity
  2. 2. FOOD FOR THOUGHT ON EXAMPLE BEHAVIOURS- SHOULD WE USE VIRAL CHANGE ™ Are these the ones? Are there more? Which would be non-negotiable? Of those, what stories are there for “people like me”
  3. 3. WATERFALL BEHAVIOURS - WHICH BEHAVIOURS ARE NON-NEGOTIABLE? ARE THERE MORE?  Use fixed price, fixed scope, fixed date contracts. Unfix quality.  Build & maintain credible, competitive, and affordable plans  Comply with controls  Consider mandatory deliverables  Consider approach given risk & scale  Consider business readiness/change  Seek guidance before scaling  Try to understand – ask why?  Good dependency management  Good supporting function engagement  Working in silos & perform handovers.  Get everyone to work in one room to recover from / avoid failure  Document everything up front  Business case, Plans, Task break-down  Requirements. Designs  Risks, issues, dependencies, assumptions  Tests including end to end & non-functional  Do latest Baseline? If so, when is the latest?  Everything is a must have  Manage change through change control –“out of scope”  Manage budget  Implement practises as per PRINCE2/PMBoK  Business people perform user acceptance tests  Review regular formal status reports –RAG  Heavy governance model  Risk based testing  Discover security/usability/performance bugs during pre-go-live hardening phase  Quality is measured by the number of prioritized defects from testing before go/nogo & the number of issues post go live  Manage the risk register – have mitigating actions and owners & follow up  Report earned value  De-scope or move date/cost if in trouble  Exert high energy and overtime towards the end  Perform “conference room pilot testing”
  4. 4. “DO WHATEVER” BEHAVIOURS  “success theatre”, data-free zone  “Low ball” project risk  Use fixed price, fixed scope, fixed date contracts.  Tell vendor to “be Agile” or to do our custom method w/o training  Build & maintain hopeful plans; the team needs stretch goals  Dodge controls  Escalate to get interfering QA folks out of way  Big bang  Dodge controls  Only care about getting across the line.  No dependency management – escalate instead  Little / no supporting function engagement  Disrespect, unhelpful behaviour  Measure perceived effort, not results  Document something up front  Vague plans, risks rot on risk register  Poor functional requirements. No NFRs, late designs only because we have to  Tests planning only “independent” testing  Deal with today’s emergencies first – watch the optics  Rely on heroic efforts to save the day  Absorb every change – we’ll do it!  Go significantly over budget or deliver nothing within budget  Business people perform user acceptance tests  Review regular formal status reports –RAG  Use a lightweight governance model  Start testing late and take longer than expected  What’s a hardening phase?  Quality is measured by the number of defects from testing before go/nogo & the number of issues post go live. It doesn’t matter, we’ll fix the bugs in production.  Manage the risk register – have mitigating actions and owners & don’t bother following up  No one remembers the business case  Move date/cost if in trouble, several times  Exert high energy and overtime for months  Over-stretch boundaries of risk-based testing
  5. 5. (DELIBERATELY) SCREWED UP SCRUM BEHAVIOURS WHICH BEHAVIOURS ARE NON-NEGOTIABLE? ARE THERE MORE?  Seek feedback, be willing to learn  Credible, competitive, affordable plans  Phone call / IM chat / f2f chat / white board  Implement top-drawer, laser focused & urgent dependency management  Use focus factor / velocity with ideal day estimates – remember there is no ideal day  Try to understand – ask why?  Negotiate ways of working for all concerned  Collaborate actively every day  Iterations begin and end on a regular rhythm, beginning with good planning, ending with a good look back  Have IT PM and business PM (Product Owner)  IT PM rules but business PM is still central to proceedings  Plan for working demonstration every iteration & measure results  Routine requirements / design look ahead with all concerned  Root out & unravel complexity  Act & think like you trust the team  Have a team focus, business & IT  Team members work full time on project  Baseline latest when, if at all?  Use change control for change if everything has already started  Use prescribed ALM tool in the intended manner  Comply with controls  Ask mentor for help  Participate in formalised informal community
  6. 6. SCRUM + TECHNICAL EXCELLENCE – WHICH BEHAVIOURS ARE NON-NEGOTIABLE? ARE THERE MORE?  Un-fix scope – everything cannot be must have  Good enough is good enough  Seek feedback, be willing to learn  Phone call / IM chat / f2f chat / white board  Implement top-drawer, laser focused & urgent dependency & issue management  Use focus factor / velocity with estimates  Try to understand – ask why?  Negotiate ways of working for all concerned  Credible, competitive, affordable plans , even when priorities change - be urgent about that  Product Owner and team manages a list of all the things to do, called a product backlog;  Product Owner prioritizes value and Solution Architect prioritises risk.  Product Owner prioritizes 3 weeks ahead of sprint, and does last minute tweaks before iteration planning  Sprints begin and end on a regular rhythm, beginning with good planning, ending with potentially shippable increment & lessons learnt  Collaborate actively every day  Product Owner (a business PM) rules  Practise technical excellence, whichever school you’re in (TDD dead/not dead, and there is always agile testing)  Perform routine requirements / design look ahead with all concerned – requirements for next sprint are INVESTable, with user roles discovered, and NFRs elaborated  Learn skills – Have a team focus, business & IT  Root out & unravel complexity  Be as professional as you can be with the work, while being as nimble as possible  Let’s make everyone feel like we’re on one team  Act & think like to trust the team  Team members work full time and don’t change  Baseline latest when, if at all?  Use product backlog item substitution to handle change.  Comply with company rules& legal regulations  Don’t scale, but if you must, consult help  Measure delivered business value  Overtime for sprint commitment and no more  Consider business readiness & IT readiness  “Use your brain” , less scripting more testing  If you must, breakdown tasks for this sprint only
  7. 7. LEAN KANBAN DEVELOPMENT – WHICH BEHAVIOURS ARE NON-NEGOTIABLE? ARE THERE MORE?  Use a kanban system daily  Visualise workflow hourly/by the minute  Stop starting, start finishing  Use T&M / PAYG contracts only until we have good data for predictability (cycle time)  Pull one item at a time  Experiment with work in progress limits  Respect work in progress limits, tune as necessary  Let’s help each other out  Try to understand – ask why?  Forecast based on cycle time + 2 standard deviations  Improve collaboratively  Do “Iterationless development” once you get into a rhythm  Use expedite swim lane for exceptions & watch out for abuse
  8. 8. LEAN START UP BEHAVIOURS 1 OF 2  Validate ideas through 2-4 week build measure learn cycles  Have short ideation to focus on ideas  Projections are full of uncertainty. Take a leap of faith.  Use “innovation accounting”.  Experiment to innovate. MVPs often result in bad news. Take risks. Tune MVP in next cycle if persevering  Have short execution periods to avoid distracting ideas  Deploy as often as possible, e.g., many times per day  Focus on absolute Minimum Viable Product from one cycle  Only build max 80% product until idea validated – early adopters prefer this  Don’t focus on quality until ideas get validated – after all, what is quality if we don’t know the customer yet?  Customer interaction over white-boarding / strategising  Change direction or strategy if idea is invalidated (pivot)  Use a different brand to avoid long term damage to corporate brand  Drop invalidated ideas even if it means losing customers who are using them  Try to understand – ask why?
  9. 9. LEAN START UP BEHAVIOURS 2 OF 2  Split testing to validate additional features or improvements or reduced functionality; stop guessing - understand cause and affect  Opinions about priorities are guesses  Use Actionable, accessible and auditable metrics - use cohort based reports. 5 to 10 actionable metrics in standard report for all experiments  Monitor metrics and customer reactions during experiment and abort if necessary  Failure is a pre-requisite for learning  Innovation accounting leads to quicker pivot  Just in time scalability  Beware of engine of growth Paid, viral or sticky growth  Pull the andon cord - stop the line  Continuous deployment  Pull, don't push  Customers often don't know what they want, hence figure out what we need to learn and work backwards; formulate a hypothesis that we want to test.  Be accountable  Practise the five whys (taking a systems view) and avoid the curse of the five blames. To that end, be tolerant of all 1st time mistakes and don't allow them to happen twice.  That said, Make a proportional investment  Help each other out!  Keep handoffs and approvals to absolute minimum - it's a lean startup!  Someone must have a personal stake in the outcome - a shusa, or chief engineer who decides everything. Create an island of freedom, an innovation sandbox to support that and protect the organization  One team oversees whole experiment e2e  No experiment can affect more than a specified % of customers

×