Subscribe: You'd think with all my video game experience that I'd be more prepared for this
Added By: Feedage Forager Feedage Grade B rated
Language: English
agile  developers  development  don  extreme programming  extreme  make  people  problem  programming  scrum  software  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: You'd think with all my video game experience that I'd be more prepared for this

You'd think with all my video game experience that I'd be more prepared for this

Agile, Lean, Kanban

Updated: 2017-10-14T17:15:13.805+11:00


Single Prioritised Input Queue


Problem Context

There are multiple sources for requests to do work which leads to unclear priority OR a de facto prioritisation approach based on who shouted loudest most recently.

Most things seem to take too long to complete which leads to more direct requests to individuals to expedite work.

People doing the work are frustrated by the inability to focus on anything as interruptions are constant.


Move all requests to a single input queue with a common prioritisation method - no requests are processed unless they come from this queue.

The prioritisation method may or may not allow explicit expediting but it will be a common policy, not a backdoor request.

Expected Consequences

  • People making requests who were used to jumping the queue may feel disappointed
  • Average lead time will drop and become more predictable
  • People doing the work will feel more focus and satisfaction

Agile encourages developers not to think about the future?


Does Agile encourage developers not to think about the future?

You Ain't Gonna Need It

The argument against Premature Generalisation is that a lot of bloated software designs come from well-intentioned software designers attempting to prepare for anticipated needs, just in case.  Instead, you remind yourself that You Ain't Gonna Need It, that the carrying cost of more complex code will be greater than any anticipated future cost of change AND that a simpler design is always easier to modify to address an unanticipated design need than a complex one.

In other words, don't anticipate any specific future but be ready for any future.  See Kent Beck's Rules of Simple Design.

I will accept that this doesn't really work without the discipline of simple design.  Hence, issues with Flaccid Scrum.

What's the simplest thing that could possibly work?

There was a slogan in Extreme Programming called "Do the simplest thing that could possibly work."

It came from a pair programming episode with Ward Cunningham and Kent Beck:
So when I asked, "What's the simplest thing that could possibly work," I wasn't even sure. I wasn't asking, "What do you know would work?" I was asking, "What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen, instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it. If it needs to be more we can make it more. Our problem is we've got nothing."
Asking the question "What's the simplest thing that could possibly work?" is about focus; it's about trying to focus on the essence of a problem rather than try to solve every problem at the same time; it's about dealing with the blank page problem in programming.

Does Agile encourage developers not to think about the future?

So it seems that the Agile community is encouraging developers not to think about the future.  Well, not exactly.

There's nothing wrong with thinking about the future per se.  The problem is to allow thinking about that future to distract from what you need to deal with right now.  The problem is acting upon that future prematurely.

The Agile approach is to not anticipate any specific future but be ready for any future by keeping the design simple.

Agile is just throwing stuff together as quickly as possible?


Is Agile just throwing stuff together as quickly as possible?

The older version of this was some variant of "Extreme Programming is just hacking" or "Extreme Programming is just cowboy coding".

In essence, the suggestion is that Agile is equivalent to "Code and Fix" or "Cowboy Coding".

Kent Beck describes the heartbeat of an Extreme Programming episode in response to the "Why is XP not just hacking?" question.  Paraphrasing for length...
  1. Pair writes next automated test case to force design decisions for new logic independent of implementation.
  2. Run test case to verify failure or explore unexpected success.
  3. Refactor existing code to enable a clean and simple implementation. Also known as "situated design".
  4. Make the test case work.
  5. Refactor new code in response to new opportunities for simplification.
Does this reasonably sound equivalent to "throw stuff together as quickly as possible"?

Granted, not every Agile team has this kind of technical discipline.  Hence, so-called Flaccid Scrum and the advocacy of Two-Star Agile fluency.

Also, granted, that sometimes one should throw stuff together quickly when the purpose of the exercise is to test an experimental concept.  For example, "spiking a solution" or an initial MVP.(image)

Learning Agile Software Development the Hard Way


1. ReadRead one or more of the following:Extreme Programming Explained: Embrace Change by Kent Beck (If you're up for it, read both the first and 2nd edition).The Art of Agile Development by James Shore and Shane Warden.  A lot of the book is freely available here but if you like, I'm sure they'd appreciate it if you bought the full book.The Agile Samurai by Jonathan Rasmusson.(FREE) Explore Don Well's site: Extreme Programming: A Gentle Introduction.(FREE) Read the Scrum Guide.2. Participate in the communityJoin a local user group. currently dominates.  I'd suggest also finding or setting up a local Lean Coffee.Follow Agile people on Twitter.  My handle is @jchyip.  There's an old 2012 list of "The Top 20 Most Influential Agile People".  Probably a reasonable group of people to start with.Subscribe to Agile blogs.  There's an old 2011 list of "The Top 200 Agile Blogs".  Probably a reasonable place to start.3. Learn and practice the craftLearn about User Stories and User Story MappingRead User Story Mapping by Jeff PattonLearn Test Driven Development (TDD)Read Test Driven Development: By Example by Kent BeckRead Refactoring by Martin FowlerPractice TDD and Pair  ProgrammingPractice using Code Katas.  Alternatively, look for similar language-specific exercises for your particular programming language.  For example, Ruby Quiz.Find or setup a Coding Dojo.  This seems to have become more rare so instead...Join or host a CodeRetreat.Learn about testing in the Agile contextExplore Brian Marick's old Agile testing site.Learn about Continuous Integration and Continuous DeliveryRead Continuous Delivery by Jez Humble and Dave Farley.Write about what you are learning3. Learn the big pictureRead about the Agile Fluency ModelRead Patterns of Enterprise Application Architecture by Martin FowlerExplore Lean Software DevelopmentExplore Kanban for software developmentRead Kanban & Scrum - Making the Most of Both by Henrik Kniberg and Mattias SkarinRead Kanban by David AndersonExplore Lean StartupRead The Lean Startup by Eric RiesDo The Lean Launchpad online course Participate in a Lean Startup MachineWatch Spotify Engineering Culture videos (Part 1) (Part 2)Attend conferences.  I recommend smaller, local, not vendor-focused conferences rather than the massive ones.  Open Space conferences tend to be good if you get the right crowd.  YOW! / GOTO / QCon tend to be good.  Lean Kanban conferences tends to be good.4. Explore the less knownRead Crystal Clear by Alistair CockburnRead Agile Software Development by Alistair CockburnRead Lean Product and Process Development by Allen C. WardRead The Principles of Product Development Flow by Donald G. Reinertsen [...]

Water spider Agile coaches, not water strider Agile coaches


In Lean Manufacturing there is a role called mizusumashi or "water spider" which is nominally someone who fetches material for operators on a line.  Jon Miller has a good blog post clarifying misconceptions about this:
"The Water Spider position is often confused with a simple material handler or an entry level “go fetch” person. Far from it, the Water Spider needs to be thoroughly familiar with the materials, tools and methods of the process they are supporting."
In other words, the Water Spider cannot be effective in supporting a process, unless s/he is thoroughly familiar with it.  Unlike water striders that only skim the surface, we want water spiders that can go deep into a process if necessary

John Shook wrote about his annoyance with people downplaying focus on working on the work in order to focus on changing culture (aka "ways of thinking"):
"You may be able to create wealth through a variety of business models or ways of thinking. But if you want to create real value, and jobs that value people, you must think hard about how your people are working every day. That’s because the essence of lean thinking is about the WORK. Lean means working on the work: the value-creating work that occurs on the frontlines of your enterprise."
So about Agile Coaches...

I see a similar problem with a potential over-emphasis on "culture" and "management behaviour" independent of insight on the actual work that needs to be done.  That is, water strider Agile coaches.

I submit that an effective Agile coach will be more like a water spider, able to go deep if necessary to support how people work.

Of course, we must acknowledge the breadth and depth of knowledge involved in modern software development. It would take a lot of time of effort to become a water spider, but I'll still suggest that this is the right True North to set.(image)

Designing a build pipeline is about impatience


When I'm designing a build pipeline I'm primarily thinking about my impatience.

How long am I willing to wait to get feedback?  Given how long I'm willing to wait, how confident am I about the quality of the feedback?

I'm not so concerned with whether it's a "unit test", an "integration test", or whatever.  My criteria is not based on what type of automated check is in the build stage so much as how long the automated check takes.

For example...


Solutions that DO help with "large, complex projects" in the enterprise


As I posted earlier, "large, complex projects" in the enterprise tend to suffer from problems of alignment and overconfidence.I also posted typical "solutions" that don't work.Here are some solutions that help:Conquer, then divide"In XP, we don't divide and conquer. We conquer and divide. First we make something that works, then we bust that up and solve the little parts." Kent BeckSetting aside market risk, the riskiest part of "large, complex projects" is whether all the various parts actually work correctly together (aka integration).The typical approach most "large, complex projects" is to build separate pieces with separate teams  that they then attempt to integrate.  This tends to cause multiple failures.A better approach is to start with an integrated solution, focusing on resolving the key integration points, using a single, highly skilled team, and ONLY when the critical integration issues are resolved, work out how to scale up to multiple teams.Have regular integration checkpointsSetting aside market risk, the riskiest part of "large, complex projects" is whether all the various parts actually work correctly together (aka integration).Problems associated with delaying integration is so common that it has its own name: "Integration Hell".The larger, the more complex, the project, the more difficult and expensive it is to have regular integration checkpoints.The larger, the more complex, the project, the more essential it is to have regular integration checkpoints.An integration checkpoint means choosing one or more end-to-end capabilities and synchronising all teams to deliver it at a common point in time.Milestones on "large, complex projects" that are not integration milestones are mostly theatre and a waste of time.Reduce accidental complexity"Accidental complexity relates to problems which engineers create and can fix... Essential complexity is caused by the problem to be solve..." No Silver Bullet, WikipediaLarge, complex projects, as the name suggests, are complex enough without adding additional, unnecessary complexity.Essential complexity reflects what is inherent to the problem to be solved.Accidental complexity reflects how we choose to solve the problem and is typically related to technology and organisational design choices.For example, that different customer segments may be using your product for different purposes is essential complexity.  That the product is split into N modules because you had N departments working on it is accidental complexity.  That your mobile product feels like a desktop product because you wanted to reuse your desktop UI is accidental complexity.Reducing accidental complexity comes down to choosing the right language, tools, design approach, and organisational structure for the problem at hand, not the problem you used to have.General themes of solutions that do work:Addressing the critical aspects of uncertainty firstAddressing inherent uncertainty with regular feedbackNot making the situation even more complex with additional constraints [...]

You don't need Agile, just get rid of the deadweight developers?


Do we need this Agile malarky if all we need to do is get rid of all the "deadweight developers"?This question implies two other questions:Does an Agile approach improve less-skilled developers?Should we even bother improving less-skilled developers?Does an Agile approach improve less-skilled developers?Back in the day, there were questions about whether Extreme Programming (XP) was really only for highly skilled developers and less-skilled developers required more heavyweight approaches like the Rational Unified Process (RUP).Ralph Johnson (co-author of Design Patterns) described his experiences teaching software engineering at the University of Illinois where the students had both XP and RUP projects:"...they do not have the experience to design anything reasonable. If they try to follow RUP, the time spent designing is totally wasted. When they follow XP, they get test cases to run, producing horrible code at first. They don't make rapid progress, but they make progress. After a few months, they start to realize that their code is lousy and then reading the refactoring book helps them a lot. By the end of the year, they have working code and have become much better programmers. So, my experience is that XP is especially good for novice programmers. It only asks them to do things of which they are capable. RUP can work if you have an expert who is trying to lead a group of novices, but if you don't have an expert then it will not work.This is not to say that RUP works better than XP if you have an expert leading a group of novices."In other words, XP is designed to use concrete feedback to develop skill.  I'm not as confident about other Agile methods and less-skilled developers.Okay, so let's say you accept that given less-skilled developers, an Agile, or more specifically, XP approach would help improve their skill.  There is still an open question of why you should bother improving their skill instead of just cutting the "deadweight developers" loose.Should we even bother improving less-skilled developers?There's a well-known response from W. Edwards Deming on how to deal with "deadwood employees":"Were they dead when you hired them? Or did you kill them?" (via Dealing with Deadwood)In other words, how much of the low performance of the developer is less a reflection of the individual and more a reflection of a broken surrounding system.Most "poor developers" I've met have had poor teachers and a poor supporting environment.  The question is, why should I design a system that only works with people who can compensate for being in an inferior system?  I would suggest that this is reflected in poor diversity and difficulty in finding people.When thinking about this topic, I tend to remember the story of NUMMI where the worst of the worst GM plant became the best in GM in about a year, with pretty much the same people, by adopting the "team way of working" (aka Toyota Production System).Workers who could reasonably be considered the worst kind of deadwood all of a sudden becoming examples of the best way of working.But we're not manufacturing cars.  Surely there is minimum level of sheer intellectual capability that not everyone has.I can accept that.  There are developers that perform better than others.  That's empirically true.Where I split ways is what the response is for developers who are not currently performing at the same level.  The best performer is the standard.  However, if you are willing to learn, we should be willing to teach.  If you are not willing to learn...There are also problematic consequences of believing in this idea of "deadweight" even for high performers.Believing too strongly that there are some developers that are deadweight and others that a[...]

You don't need Agile, just let the developers do what they think is right?


Do we need this Agile malarky if all that really matters is letting developer do what they think is right?

This is a popular variant of "Agile is fundamentally just..." and is similar to "Agile is just for programmers", differing only in not wanting to identify with "Agile".

Let's work through the reasoning.

When building something effectively, how do you know what is right?

In order to know what is right, you need to understand both the problem space (What problem are we trying to solve? What forces are in play? etc.) and the solution space (What options do we have? What trade-offs are in play? etc.).

Nominally developers have the best understanding and insight into the solution space.  "Let the developers do what they think is right" implies that understanding the solution space magically means that you understand the problem space.  This doesn't make any logical sense.

One-way communication from developers to product owners / managers is as illogical as one-way communication from product owners / managers to developers.

Bringing perspectives together in order to gain understanding and insight of both problem and solution space does make logical sense.

Doing what you think is right is ineffective if you have no justifiable reason for those beliefs.

See also Lean Startup.(image)

Agile is for extroverts?


Is Agile for extroverts?

And given most programmers are introverts, is Agile just stupid?

Given that I'm an introvert and most people I've worked with are introverted, I find this question weird every time it's asked.

As long as you are building things for other people, you cannot be effective unless you engage with those people to understand the problem to be solved.  As long as you do not have perfect focus and infinite perspective, you cannot be effective unless you learn to work with other people in a close, collaborative way.

I will acknowledge that engaging with people in this way might initially feel uncomfortable.

But I'll suggest that you should be more interested in being effective than not being uncomfortable.  If  you can't make that shift, then yes, Agile is not for you.

Agile is not sustainable?


Does Agile produce a working environment that is unsustainable?

Extreme Programming (XP) originally had an explicit practice called "40 Hour Week", which eventually became "Sustainable Pace".

Part of this was because of an intent to make software development humane; part of this was because people were interested in what was actually effective and not what just looked effective.  Working excessive, unsustainable hours is not effective.

As Ward Cunningham said, in response to a request to get a team to work more hours: "We would if it would help."

There are other practices that address sustainability:
I will acknowledge that there are some things that may seem like they are designed to increase unsustainability:
  • The use of the word "sprint"
  • Daily stand-ups
  • The continuous flow approach of kanban
  • Continuous Delivery
All the principles and practices designed for increased pace and speed can easily lead to unsustainability if you hold a particular mistaken assumption.

The mistaken assumption is that Agile encourages a one-way communication where a Product Owner tells a development team what to do rather than a n-way collaboration between everyone because that's just a better way to do software development.(image)

Agile leads to technical debt?


Does Agile lead to technical debt?

The phrase "technical debt" was coined by Ward Cunningham in 1992.  Ward is known for a few significant things: wikis, CRC cards, and influencing Extreme Programming (XP).

XP was by far the dominant "lightweight methodology" when the Agile Manifesto was created.

So it seems rather odd to suggest that Agile leads to technical debt.  All the talk about technical debt came from Agile people.

Here's Ward talking about the history of "technical debt":
allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="" frameborder="0" height="266" src="" width="320">

Here's a couple articles by Martin Fowler on technical debt:
Ward and Martin are signatories of the Agile Manifesto, which makes sense because they participated in creating it.

It's really ironic that people today might believe that Agile leads to technical debt.

But I can understand the belief.

XP is no longer what people typically think of when they think "Agile".  There has been a shift to Scrum and Kanban and management issues in general.  I can understand that people exposed to Flaccid Scrum might believe that Agile equates to poor technical practice.

The more controversial, though unoriginal, claim would be that XP practices lead to technical debt.  In other words, claiming that the community that developed and embraced the concept of being mindful of technical debt advocates practices that lead to it.(image)

Product Owner and Scrum Master OVER team members?


Do Product Owners and Scrum Masters outrank team members?

This is an odd belief as there is a strong tendency for people within the Scrum community (where the Product Owner and Scrum Master roles come from) to talk about Servant Leadership which seems to be the opposite of outranking team members.

As an aside, I've never really been a fan of "servant leadership".  Instead, I like the idea of Host Leadership.

Extreme Programming used to distinguish Customer Rights vs Programmer Rights (and then eventually Managers and Testers wanted in on that action) in order to clarify accountabilities and essentially balance power.

I wonder whether being explicit about rights like in earlier Extreme Programming would address the problem of people misinterpreting the roles of Product Owners and Scrum Masters.

But there's a reason why rights aren't really discussed that much anymore.

The point is not a fight for power and rights but rather how to work together as humans for a common goal, aka Whole Team.(image)

Waterfall is just a strawman?


Is waterfall just a strawman used by Agile evangelists?

"strawman" implies that waterfall is not a real problem, that it no longer exists in the modern world of software development.

I don't really know how to respond to this except to suggest to look a little closer at how most IT organisations actually work.

But perhaps it's just a problem for "enterprises" and not "startups" and Silicon Valley?

There are two extremes that lightweight methodologies were a counter for:
  1. Waterfall
  2. Code and fix
Enterprises tend to have the first problem; startups tend to have the latter.

Neither waterfall nor "code and fix" are strawmen within enterprises as they typically have examples of both.

Waterfall is not a strawman but is probably not the problem you're facing as a startup.  That problem is either code and fix and/or the so-called "engineering-driven company" which is why Lean Startup was invented.(image)

Agile is just for managers? OR Agile is just for programmers?


Before "Agile" and even in the early years, when the dominant "lightweight methodology" was Extreme Programming, there were a lot of complaints that it was too focused on programmers and ignored the concerns of other roles and the "realities" of management.

As Agile hit the mainstream with the dominance of Scrum and the rise of Kanban and SAFe, the complaints seem to have shifted to be about how Agile was just for managers and seen as a management fad.  Ironically, there are even complaints now that Agile doesn't focus enough on programming.

A fundamental idea of Agile was and is to bring people together.  The somewhat clumsily worded version in the Agile principles is:
"Business people and developers must work together daily throughout the project."
DevOps is a natural evolution if we ignore the clumsy wording and realise the underlying concept of bringing people together.

Agile can't be just for programmers OR just for managers OR just for any particular group or perspective BECAUSE the insight is that you can't deal with problems effectively by taking only one perspective. (image)

Agile is fundamentally just...


Is Agile fundamentally just X (where X can be any one trait)?

For example is Agile fundamentally just...
  • ..."violent transparency"?
  • ...getting smart people together and getting out of their way?
  • ...removing the gap between developers and customers?
  • ...inspect and adapt?
  • [insert your version here]?
I've seen too many failed Agile teams and situations to be that naive.

Sociotechnical systems are complex.  For a complex system, there is no "fundamentally just" one particular thing.

I have argued that Agile can be generated from just a handful of key concepts (rather than 12).  For example:
I can't say for sure that I'm right about any of these attempts, but I'm quite confident in saying that I'm sure there is no one concept that generates all of Agile AND that there is no one trait that fundamentally represents all of Agile.

Agile was invented by consultants to make money?


Was Agile invented by consultants to make money?

This question has two parts:

  1. Was Agile invented by consultants?
  2. Was it invented to make money?

If you look at the authors of the Agile Manifesto... it sure does look like a lot of consultants.

Let's think about this.

Was there a problem that Agile was solving?  If no, then it's more likely it was invented just to make money.  If yes, then it's more that problem-solving is a way to make money.

The predecessors of the aggregate "Agile" brand were known as "lightweight methodologies".  The name gives you a hint that they were being compared to "heavyweight methodologies", typically at that time, associated with excessive UML and the Capability Maturity Model.  I would argue that this indicates the "lightweight methodologies" were invented to solve the problem of "heavyweight methodologies" and therefore "Agile" being an aggregate brand of "lightweight methodologies" was invented to solve problems, not as a blatant ploy to make money.

So why would anyone believe that Agile was invented by consultants to make money?  I don't believe that it's simply due to cynicism.

One of the problems of the mainstreaming of Agile, and specifically the growth of certifications, is the corruption of easy money.

The needle was closer to "solve problems" in the early days of Agile or really before the brand "Agile" was invented.  I will grant that this needle has moved toward the "make easy money" side of things.

However, I don't grant the idea that "Agile was invented by consultants to make money" is factual.

"Lightweight methodologies" were an honest expression of what people thought was better.  That core is still real.  Apologies for the rest of the crap.(image)

Why the especially terrible "Agile" you hear about is misled and wrong


There have been claims of the terribleness of Agile from the birth of the Agile Manifesto in 2001 and before then, when it was more the terribleness of Extreme Programming.Because of this, most of the "new" arguments you hear are not actually that new but typically reflect the same misunderstanding (whether accidental or deliberate) of what XP / Agile is about.  This is not to say that all new arguments have been made before nor that every argument whether old or new is completely devoid of merit.  However, it's rather tiresome and perhaps not too useful to respond to the exact same objections that have already been answered.To that end, let's try to capture some of the patterns of misunderstanding and explain why they are misled and wrong.Patterns of Agile misunderstandingAgile is just some new fad.Agile was invented by consultants to make money.Agile is just X (where X can be any one trait).Agile is just for managers OR Agile is just for developers.Waterfall is just a strawman (implying that Agile is not solving any real problem).Product Owners and Scrum Master outrank the team members.Agile leads to technical debt.Agile is not sustainable.Agile is for extroverts while most people in software are introverts.You don't need Agile, you just need to let developers do what they think is right.You don't need Agile, just get rid of the deadweight developersAgile is just throwing stuff together as quickly as possibleAgile encourages developers not to think about the futureAgile is the new Waterfall [...]

Agile is just some new fad?


"Agile is just some new fad" might have been a reasonable objection in 2001 but it seems less reasonable after more than a decade.Let's look a little closer at the history...When all the lightweight methodology people got together at Snowbird in 2001, Extreme Programming (aka XP) was by far, the most popular approach.  XP was born when Kent Beck was asked to rescue the C3 project, a payroll system replacement at Chrysler, in 1996.  I first heard of XP in late 1998 on comp.object, (back when Usenet was still a thing) which led me to Ward Cunningham's Portland Pattern Repository (aka the first wiki) and Ron Jeffries' (imagine current version with late 1990s web aesthetics).  So Extreme Programming has been around for close to 20 years.The Portland Pattern Repository has a pretty good summary of the timeline.There is more in the History of Extreme Programming.  For example, the emphasis on unit testing (not yet test-first) came before C3.  And you can see a lot of ideas leading to Extreme Programming in Ward's Episodes pattern language of competitive development submitted to the Pattern Languages of Programming conference in 1995.Now one might argue that Extreme Programming is no longer the face of Agile but take a look at slide 22 on one of Eric Ries' early presentations on Lean Startup in 2008:The current face of Agile, which I'd argue was primarily caused by its certification program, is really Scrum.  Scrum started before XP in the early 1990s; XP borrows structural elements from Scrum.  I am less familiar with Scrum origins but from what I understand it was derived from multiple projects in the early 1990s, one of which was developing Quattro Pro at Borland in 1993.  The more official description, and I think the first mention of "Scrum", was presented at OOPSLA in 1996. So Scrum has been around for close to 20 years or more.If you look even closer, it gets yet more complicated.Ward and Kent worked together at Tek Labs, formerly the R&D labs at Tektronix.  I'm guessing this was in the 1980s given their paper introducing Class-Responsibility-Collaborator (CRC) cards was presented at OOPSLA 1989, and by then they were both working elsewhere.  The claim is that they rediscovered pair programming when they worked at Tek Labs, so the XP-style pair programming has been around for probably over 35 years.In 2003, Craig Larman and Victor Basili wrote an article for IEEE Computer about the history of iterative and incremental development which walks the path starting from Walter Shewart's emphasis on short PDSA cycles in the 1930s to modern Agile methods.  The evolution of development towards iterative and incremental has been happening for around 80 years -- Agile is simply the latest expression of it. [...]

Thoughts on "mission" OR why "mission" != "mission statement"


The purpose of exploring "mission" is to provide enough and only just enough guidance to support independent action.

Too little guidance leads to confusion and unaligned action; too much guidance undermines autonomy and creative initiative.

What needs to be known for a mission?

  • Context
  • Intention
  • Constraints
  • Implications
What needs to be communicated?  Any of the previous items that are non-obvious for the particular organisation, team, individual

The simpler the context, intention, constraints, implications, the more likely that a one-line mission statement is sufficient.  If you assume that a one-line mission statement is not enough, you'll be right in the vast majority of cases.

Because of the problem of false understanding (we believe we understand each other but actually don't), the important part of mission is not the mission statement but rather the dialogue to validate shared understanding of context, intention, constraints, and implications.  A mission statement might be an input to trigger this dialogue AND/OR an output to remind of that dialogue.

Context, rationale, and overview of Story / Impact Mapping


Small batch software development is goodThere are many advantages to working in small batches in software development:Faster feedbackProblems are localisedReduced riskGreater pressure and practice to reduce overheadSee The Principles of Product Development Flow for moreNaive small batch software development is not quite so goodThere is also a significant disadvantage when small batches are done naively: disconnection from overall purpose.Jeff Patton described this phenomena using the metaphor of a tree versus a bag of leaves:In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations. After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag - then cut down the tree.The "bag of leaves" approach to backlogs is a context-free prioritised list of work items, that is, the naive, and I'd argue typical for Agile novices, understanding of "backlogs".  Although it nominally reflects a small batch approach, the "bag of leaves" discourages connection with underlying rationale and purpose, and therefore undermines autonomy.Where I propose 5 attributes that indicate an effective approach to defining small batches in software developmentInstead, a more effective approach goes beyond work broken down into smaller pieces.  A more effective approach...Highlights overall intention in the form of goalsHighlights the logical relationship between goals and the work items that need to be doneVisually represents goals, work items, and relationships in order to expose potential disagreement or misunderstandingIs designed to be done in a collaborative wayIs iterative, that is, it does not require full completeness at the startThis is how I describe Story / Impact MappingBoth Jeff Patton's User Story Mapping and Gojko Adzic's Impact Mapping are (mostly equivalent) answers to naive approaches to defining small batches in software development (aka creating backlogs).  This is how I would describe how to do it:Note: This process should be iterative.  It is only presented sequentially because that is easier to understand.  It is not necessary, nor advised to try to fully complete every step in order.  Instead, start with what you have and jump around and revisit steps as useful.1. Identify GoalsWhat are you trying to accomplish?This should be something observable and therefore measurable.  For this reason, I like the term "impact" given that it implies something that is observable.  However "goal" is more familiar to most people and I generally don't like introducing new jargon unnecessarily.There may be more than one goal.2. Identify Roles and ActivitiesWho has to engage in some Activity to achieve the Goals? OR What Activities need to be done by someone to achieve the Goals?I generally prefer starting with Activities but in practice, this tends to be a very iterative process.Note that Role is distinct from Person.  The Person may play other Roles that don't have anything to do with your Goals but rather their own Goals.  This typically means that you will need to add additional Goals that need to be supported.3. Identify CapabilitiesWhat needs to exist in order for the Role to do an Activity?A Capability may not ne[...]

From "make it work, make it right, make it fast" to "rules of simplicity"


"Make it work, make it right, make it fast" is Kent Beck's formulation of a design philosophy of the "Unix Way".

You can see this in his subsequent formulation of the 4 rules of simple design:

  1. Passes all the tests ("make it work")
  2. Contains no duplication ("make it right")
  3. Expresses all the ideas you want to express (aka reveals intention) ("make it right")
  4. Has no superfluous thoughts (aka fewest elements) (aka minimises classes and methods for OO languages) ("make it right")
What's missing in the newer design guidance is the equivalent of "make it fast".

"Taylorism"? I don't think that means what you think it means...


There's a tendency for people in the Agile community to throw around the word "Taylorism" as a synonym for evil.

It's worth remembering how work was seen before Taylor and "scientific management":
  • Work is not worthy of study
    • If you miss quota, you're incompetent... dock pay; if you beat quota, you must have been sandbagging previously... dock pay
  • No rest breaks
  • Workers are all the same
  • Improvements only benefit owners
Some of the ideas advocated by Taylor were significant improvements:
  • Work is worthy of scientific study
  • People should get rest breaks; fatigue exists!
  • People are different, which means some will be better suited for some work over others
  • Workers should benefit from improvements, not just owners
The problem with Taylorism really comes down to one assumption, that workers are lazy and dumb which means managers need to design how they work.

This is the key difference between Taylorism and Toyotaism (aka Lean):
  • Taylorism: Managers are the scientists
  • Toyota / Lean: The people doing the work are the scientists