Troubleshooting Agile

It's Episode 9 of the Troubleshooting Agile podcast! This week we're discussing Agile Principle 7: "Working software is the primary measure of progress."

Some of the topics we cover are:

-The importance of "moving past the 'phase model' or the 'percent-of-budget model'" in measuring progress.

-How Burn-Up/Down Charts simplify and optimise the process of measuring progress by assigning value only to that which provides value to the customer.

-And how they also build trust between the business and software development sides of a company by delivering regularly.

-The dangerous pitfall of taking Agile Principal 7 too literally and finding yourself toiling away in a Feature Factory.

-How to avoid this pitfall by motivating your team with Type Y Management - perhaps taking inspiration from Star Trek's Jean-Luc Picard - and focussing on Business Outcomes.

-That an unexpected outcome of focussing on 'working software' is often less software. 'But the software you end with, you know works. And you know it matters.'

**

LINKS:

-The 12 Agile Principles - http://agilemanifesto.org/principles.html

-An extract from Alistair Cockburn's brilliant Crystal Clear: A Human-Powered Methodology for Small Teams on Earned-Value and Burn-Charts

- http://alistair.cockburn.us/Earned-value+and+burn+charts

-Mary and Tom Poppendieck's brilliant book on Lean Software Development - https://www.amazon.co.uk/Lean-Software-Development-Agile-Toolkit/dp/0321150783

-John Cutler's blog on how to tell if you're working in a Feature Factory - https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2

***

We'd love to hear any thoughts, ideas or feedback you have regarding the episode.

You can email us, here:

Tweet us, here:

twitter.com/TShootingAgile

Or find our website, here:

troubleshootingagile.com/

Also, here is a link to our iTunes:

itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

If you have a moment, please like, subscribe and share with your friends. We really appreciate it.

In Episode 8 of Troubleshooting Agile it's Agile Principle 6: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

A few of the things we discuss:

-The pros and cons of different communication channels.

-Looking at Alistair Cockburn's book "Agile Software Development", why micro-gestures and physical interaction make face-to-face communication so much richer.

-Why we need to remember that "a Story Card is a promise for a conversation".

-The origins of CRC Cards back in the 90, and their real value as a conversational tool and in building a shared understanding.

-How effective communication also increases the effectiveness of isolated reflective thought.

-How to apply this principle effectively to distributed and remote teams.

-"Don't measure your software productivity by linear feet of documentation on the shelf."

***

LINKS:

-Chapter 3 of Alistair Cockburn's Agile Software Development: http://alistair.cockburn.us/ASD+book+extract%3A+%22Communicating,+cooperating+teams%22/v/slim

-Alistair's Richness of Communication graph: http://alistair.cockburn.us/get/2287

-Alistair on coining "A story card is a promise for a conversation": http://alistair.cockburn.us/Origin+of+user+story+is+a+promise+for+a+conversation

-CRC Cards: http://www.extremeprogramming.org/rules/crccards.html

-Jeff Bezos's Management Tool for Self-Discipline: http://blog.idonethis.com/jeff-bezos-self-discipline-writing/

***

We'd love to hear any thoughts, ideas or feedback you have regarding the episode.

You can email us, here:

Tweet us, here:

twitter.com/TShootingAgile

Or find our website, here:

troubleshootingagile.com/

Also, here is a link to our iTunes:

itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

If you have a moment, please like, subscribe and share with your friends. We really appreciate it.

This week, in Episode 7 of Troubleshooting Agile, we discuss Agile Principle Number 5: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Talking points this week include:

-Why perceptions of this principle differ immensely depending on whether your adopt Theory X or Theory Y.

-Directed Opportunism - and who used it better, General Clausewitz in 1870 or Darth Sidious a long, long time ago.

-How trusting your team and recognising the ingenuity inherent within all employees creates psychological safety that motivates your staff and advances your business.

-Different ways to deal with an unyielding Theory X-er.

-How to recognise when it's come down to a case of "change your organisation or change your organisation."

And finally, can you can think of a good Theory Y boss/environment depicted in TV or Film? (think corporate Mr Miyagi)

Let us know down below, or Tweet us @TShootingAgile and we'll give your ideas a shout out in an upcoming episode.

***

LINKS:

-The 12 Agile Principles: http://agilemanifesto.org/principles.html

-Stephen Bungay's 'The Art of Action': https://www.amazon.co.uk/dp/B01HPVHLHG/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

-The LEAP Institute: http://dramador.com/the-leap-institute/

-Niels Pfläging's blog, 'Why we cannot learn a damn thing from Semco, or Toyota':

https://vision.haufe.de/blog/en/why-we-cannot-learn-a-damn-thing-from-semco-or-toyota/

***

We'd love to hear any thoughts, ideas or feedback you have regarding the episode.

You can email us, here:

Tweet us, here:

twitter.com/TShootingAgile

Or find our website, here:

troubleshootingagile.com/

Also, here is a link to our iTunes:

itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

If you have a moment, please like, share and subscribe. We really appreciate it.

In Episode 6 of Troubleshooting agile we talk about the Fourth Agile Principle: 'Business people and developers must work together daily throughout the project.'

Some of the topics discussed are:

-Why this is the only principle containing the word MUST.

-How to easily overcome a principle which at first sight can appear impractical to implement.

-What business people can do that developers can't.

-The importance of customer proxies in bridging the communication gap between departments.

-How this speeds everything up and helps developers maintain their flow.

-As well as motivating teams, through trust and inclusion, in a way that can spark innovation.

-Eating your own dogfood

***

LINKS:

-The 12 Agile Principles: agilemanifesto.org/principles.html

***

We'd love to hear any thoughts, ideas or feedback you have regarding the episode.

You can email us, here:

Or send us a tweet, here:

twitter.com/TShootingAgile

Or you can find our website, here:

troubleshootingagile.com/

Also, here is a link to our iTunes:

itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

Please like, share and subscribe.

In episode 5 of Troubleshooting Agile we discuss the Third Agile Principle: 'Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.'

Evolution in our thinking, since the Agile Manifesto was written back in 2001, makes what was once considered 'shorter timescales' seem laughable now, but, when retrospecting, 'working software frequently' remains one of the core agile disciplines. But, as Squirrel and Jeffrey highlight through various client stories, it is far from easy to implement continuously.

We hear where, why and how so many companies fail to fully employ this principle, and Squirrel and Jeffrey discuss some interesting techniques to overcome common problems - from slicing up elephant carpaccio to employing continuous integration with nothing more than a rubber chicken.

*We apologise for a few sound difficulties at the start of the episode with Jeffrey's mic. Stick with it and they soon pass.*

***

Squirrel and Jeffrey have told us which common obstacles they regularly witness that prevent organisations from delivering working software frequently. Now we want to hear from you guys on the matter. You can leave your answers in the comments below, you can email us at [email protected], or you can find a poll on our Twitter feed @TShootingAgile.

What are the obstacle for your organisation to delivering working software frequently?

1. The tech team aren't offering to do this, or don't know how.

2. Customers (external or internal or both) don't know it's possible or how to use it if offered.

3. Both 1. and 2.

4. Neither - we already deliver frequently!

***

SHOWNOTES:

-Agile Manifesto Principles - http://agilemanifesto.org/principles.html

-Continuous Delivery, by Jez Humble and David Farley - https://martinfowler.com/books/continuousDelivery.html

-Continuous Delivery - https://continuousdelivery.com

-CITCON - https://citconf.com

-James Shore's blog: "Continuous Integration on a Dollar a Day - http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html

-Alistair Cockburn's blog: "Elephant Carpaccio" - http://alistair.cockburn.us/Elephant+carpaccio

***

We'd love to hear any thoughts, ideas or feedback you have regarding the episode (or regarding anything else for that matter).

You can email us, here:

Or send us a tweet, here:

twitter.com/TShootingAgile

Or you can find our website, here:

troubleshootingagile.com/

Also, here is a link to our iTunes:

itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

If you feel like liking, Sharing and/or Subscribing, we'd really appreciate it.

In this episode Squirrel and Jeffrey discuss the Second Agile Principle: ‘Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.’

We hear how the principle is closely related to Lean Startup and Minimal Viable Product, and how, at its core, it is about understanding and learning from one’s environment as quickly and as often as possible.

This reminds Squirrel of the OODA loop, the decision cycle developed by military strategist and US Air Force Colonel John Boyd, and he tells us a story about fighter jet dogfights in the Korean War.

Jeffrey also tells us a story, about a startup he started way way back in the first dotcom bubble in 1999, which brings to mind another military lesson that ‘no plan survives contact with the enemy.’.

Finally, we hear examples of common errors witnessed over the years, such as refusals to fully embrace the Second Agile Principle in favour of misguided efficiency and an often irrational attachment a plan.

***

SHOWNOTES:

-The 12 Agile Principles: http://agilemanifesto.org/principles.html

-The OODA Loop: https://en.wikipedia.org/wiki/OODA_loop

-Lean Startup: https://en.wikipedia.org/wiki/Lean_startup

***

We’d love to hear any thoughts, ideas or feedback you have regarding the episode (or regarding anything else, for that matter).

You can email us, here:

Or send us a tweet, here:

twitter.com/TShootingAgile

Or you can find our website, here:

http://troubleshootingagile.com/

Also, here is a link to our iTunes:

https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

If you felt like liking, Sharing and/or Subscribing, we’d really appreciate it.

In this third episode of Troubleshooting Agile, Squirrel and Jeffrey take a look at the first of the 12 Agile Principles: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” As Jeffrey point out, this principle contains so much that it "could have been an agile manifesto in itself.”

Squirrel and Jeffrey both tell stories about previous consulting experiences to highlight where clients have failed to fully deliver on this vital principle in the past, and how businesses can troubleshoot various common problems that arise.

Show Notes:

- The 12 Agile principles: http://agilemanifesto.org/principles.html

- “The Goal: A Process of Ongoing Improvement”, by Eliyahu M. Goldratt: https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp/0566086654/ref=sr_1_1

- CITCON website: http://citconf.com/

We’d love to hear any thoughts you have about this Agile Principle, or about the podcast in general.

You can email us, here:

Or send us a tweet, here:

https://twitter.com/TShootingAgile

Also, why not Like, Share and Subscribe. We’d really appreciate it.

In episode 2 of Troubleshooting Agile, Squirrel and Jeffrey look at what to do when you've adopted good agile practices but are not seeing good business outcomes; how the most beautiful kanban board on earth doesn't necessarily mean results; and why the 12 agile principles work as a form of feedback and a great guide.

Shownotes:

- Jeffrey's 2008 blog post – https://blog.jeffreyfredrick.com/2008/11/08/searching-for-an-agile-core/

- The 12 agile principles – http://agilemanifesto.org/principles.html

- Chris Matts's blog – https://theitriskmanager.wordpress.com/2015/04/19/communities-of-need-community-of-solutions/

Why not let us know what you think on Twitter @TShootingAgile https://twitter.com/TShootingAgile

In this week's podcast Jeffrey tells us a story about the dangers of blaming human error in the workplace, and we discuss root cause analysis, the blameless postmortem approach and how these are essential components in building productive systems and a great agile team.

Normal Accidents – http://bit.ly/2CtawMg

http://troubleshootingagile.com/