Tag Archives: agile

There ain’t no bad requirements

Uncategorized,

The Bad-Requirements Mea Culpa

I often take part in conversations on the topic of “bad requirements”. Typically a project manager starts complaining about how poorly one feature was developed. Maybe the feature went out very late, or it might be because of an abnormally big amount of bugs, or whatever problem that you can imagine (or remember of). Sooner or later in this conversation, the PM starts thinking that something went wrong because of him. And inevitably he ends up blaming his requirements.

It is very easy to blame the requirements; and the more precise they are, the easier it is to find that they are bad. I remember of a particular story of a website that should have been released in three languages, but the Spanish contents were not ready yet. It was decided to open the site in French and English only. Instead of explaining the problem when describing was needed, the PM in charge wrote something like “Hide the Spanish flag”. Very precise, and very incomplete. The developer did not ask any questions and actually hid the flag using CSS. The Spanish site was still reachable and got on top of Google searches with Lorem Ipsum contents.

Nevertheless we should not blame the requirements. If you recognize yourself here I’ve got a good news for you : there ain’t no bad requirements. 

Conversations

In the Agile world, the word “requirements” has been considered harmful and is now viewed as a monster that should be avoided at any cost. I profoundly disagree with that because, once again, “requirements” is just a word. The truth is even Agile practitioners use requirements, and this is because we need a way to express what we need to do with the product. Sorry my fellow agilists, but the truth is that user stories are functional, user-centric, goal-driven requirements.

Requirements, whatever the form you use, are not bad in essence. They are just tools. Like any other tools they can be used correctly or badly. But on the contrary to other tools that can be hard to master and very error-prone, requirements are quite easy to use if you remember what their real purpose should be. If you write requirements in stone and never talk about them whatsoever, you are running into big troubles. But whatever how you write them, if you use requirements as a conversation igniter, then you’re good.

Let’s go back to the example above about the Spanish web site. The real problem is not that the requirements were to hide the flag. No. The problem here was that the PM did not explain the purpose of what he needed, and that the developer did not ask. So the real problem is the lack of a good conversation, as simple as :

– Why do you want the flag out ?
– Well, the Spanish contents are not ready yet. We don’t want the Spanish site to be visible.
– Hum… Okay, maybe we should make sure the site not reachable at all, and set up a redirection just in case we forget something.

Tada! You’re done. No user story, no weird template or framework whatsoever, but only one thing : a conversation. A requirement is a tool which purpose should be to enable a conversation so that the best possible options are chosen, but there is no bad requirements, only bad conversations.

 

 

Definitions are harmful

No dogma,

Yesterday I attended an amazing talk by Stéphanie Walter at DevFest Nantes. In this talk she presented a series of very “lean” tips and tricks about web design and how to organize the whole process from wireframing to development “the hard way”.  I don’t usually write about webdesign…and this is not going to happen today neither, but something in her talk caught my attention.

At a moment near the end of the talk, Stéphanie described an iterative, incremental process where quick feedback loops allow quick reactions, avoid big re-works, induce a better collaboration and a better communication between everybody and allow creating better design, better user experience, … in opposition to the usual process implemented at her company. After the talk, someone asked “Would Agile help you?” and she answered something like “We tried once but it failed. We designed and developed each part of the site one after the other, but the developer missed some opportunities to make more common CSS and had to rework many things after the fact, etc.” I must say I was very surprised because

  1. what Stéphanie described sounded totally Agile to me. She talked about incrementally creating the design, about very Lean-like ways to avoid wasting time, about better collaboration, etc. So the question was very bizarre to me because she was definitely there already.
  2. She answered no!

Actually this is not the first time I hear or read something like “Agile won’t work for us : what we do is [some kind of definition of Agile]” and I really don’t know what to do about it. I’m not even sure that we should do anything about, apart from being aware of the phenomenon. This is just a funny fact : applying our “Agile” definition failed, let’s drop it completely and go back to our Agile practice.

This whole thing reminds me of a question a colleague asked me some time ago. The team I work in used to practice Scrum, but we improved a couple of things, making us get away from theoretical Scrum and move to a more “kanbanish” process. Since I am supposed to be the Kanban guy, my teammate asked me if we were “doing Kanban now“? I said “Why do you care? Do you really need a new religion?!” Maybe that was a bit a condescending answer, but my point was that we did not need a definition of what our way of working had become. I really wanted to avoid inhibiting improvement initiatives by saying “we are doing method FooBar now”

I think that as long as people feel free to make improvements, as long as they think they are inventing something, then they will keep on improving. But if they happen to reach a point where they recognize something that has already been described, something that has a definition, a concept, they will stick to it and stop inventing. People tend to stop “thinking”, they tend to stop trying things when they “hit” a known, comfortable word.

That is why definitions are harmful : they are very static, very…defined. On the contrary improvement, changing things, is not defined, it’s moving.

 

Indian Planning Poker

#NoEstimates,

When I first heard of estimating work items – let’s call them stories – with Story Points I was like “WOW!! That’s amazing!! No more question about how long it will take! Just estimating the relative effort, it really is a good idea!”

Then I discovered Planning Poker, and again was amazed by how it can solve Asshole Driven Development issues (me being the asshole most of the time). I immediately decided to apply it with the team I was in charge of. We did ONE session, and everybody agreed that we were wasting our time. Yet we learnt a couple of things then:

  • We could easily treat small stories, the ones worth 1 or 2 points
  • We could not easily decide about big stories, and almost always decided to break them into smaller stories

All around the Web you’ll see that people recommend not to use the bigger cards of your planning poker deck, and to only keep the 1/2, 1, 2, 3 ones or so.

So we decided to give a try to T-shirt-size estimates, which was basically like keeping only 3 cards in our deck : S, M and L. We did ONE session, and everybody agreed that we were wasting out time. Yet we learnt a couple of things then:

  • We could easily treat small stories, the S-sized ones
  • We could not easily decide about big stories, and almost always decided to break them into smaller stories

Now here is the thing : we had a product to build and we wanted to now how long it would take to build some of the pieces of it (we are not discussing why here). We realized that we could not give any (accurate) estimate to answer that very question unless the pieces were small enough.

So we decided to always work on small-enough pieces of work. Obvious.

Now if for some reason you believe that you need estimates, what you can try with your team, during your next Sprint Planning Meeting, is a session of Indian Planning Poker. You actually only need one card in your Planning Poker hand: the thumbs-up card. Stick the thumbs-up card on your forehead if the story is small enough, or as small as usual, and not if not…and tell me about the results.

Post-Agile : Software Development As A Service

#NoEstimates, , ,

Maybe a new way of working for post-agile organisations

I wrote most of this article long ago but decided to keep it as a draft until recently. I actually thought that was more of an utopia than of a real, possible thing…but this changed after I watched Neil Killick’s talk on #NoEstimates.

I’ve been practicing software development in a Kanban team for several years now, around a single product. A first observation I want to make here is that current “Agile” way works fine with long-term projects, at least if :

  • you build a stable team
  • you slice the work into small SMALL pieces of work
  • you try to keep the work items of the same size, asking simple questions like “Is this work item as small as usual?”
  • you limit work in progress at every level of your process
  • you get rid of “expert” effort estimates and use historical data, statistics and probabilities instead (possible because you built a stable system thanks to the first 4 points)

When I speak to people working in web agencies or other kinds of software development shops, they often tell me it’s not going to work with small projects, when teams must work on several projects at a time, for several customers. They also tell me about contracting problems : how to be Agile – and what are the benefits of it – when dealing with fixed-scope kind of contracts?

That’s why I’d like to describe my hopes for a post-agile world, hopefully solving the issues above, by describing the kind of practice I’d like to see emerge in the years to come. I call it Software Development As A Service. It goes like this:

  • The team implements some kind of Agile/Lean principles so as to get a stable process, like what I succinctly described above.
  • We consider the team as a whole, a system converting customer money into customer business value at a (statistically) predictable rate.
  • The customer and the shop agree on some sort of Service Level Agreement based on lead time distribution for the given team. Transparency is compulsory here.
  • The contract becomes a fixed-cost contract

So I guess that post-agile really is about customers becoming agile too, and embracing the fact that software development is partly made of uncertainty.

If you have any thought on that, feel free to leave a message here or on twitter.

How good are your estimates?

#NoEstimates,

uroboros
An Agile iteration often goes like this, whatever the framework you are familiar with:

  • the product owner prioritizes the backlog of work items (features, epic, user stories…)
  • the team gives estimates for the top of the backlog, using story points, ideal time, actual time…
  • the team and the product owner agree on what will be done
  • the team actually does the magic
  • the team shows what has been done, and we compare with what was expected

Among any other thing, we often compare the estimated velocity, the number of story points the team thought they would tackle during the current iteration, with the actual velocity, the number of story points the team actually managed to sweep away.

By doing so we try to learn two things:

  • how fast the team goes
  • how accurate its estimates are

Pretty logical indeed : we compare expectations with what actually happened… but… WAIT A SECOND! What are the facts I am talking about? ESTIMATES? I am trying to calculate the speed of the team relying on the very estimates which I am trying to know the accuracy, and this accuracy cannot be computed otherwise than by comparing with the actual speed of the team!

BAM!!! Your head just blew up! You are a uroboros!

Now the good part, because I know that some of you still have their head rather intact. I hear you say “We don’t need to know how accurate the estimates are, we just need to know that they are always the same, based on the same scale“…and you are absolutely right. If the team always estimates work items the same way, we can easily monitor its velocity.

Now say that our team velocity is 20 story points per sprint. The backlog is full of user stories estimated at 1 or 2 story points, but one of the stories is worth 19 points. What are we going to do with it? We are going to break it into smaller stories : there is too much uncertainty, too much risk with such a big story, even if the team could theoretically handle it. Ideally we would break it into 1-point or 2-point stories, because that’s the kind of story the team is used to working with.

If we go a little further, we will realize that what we really need in order to calculate the team velocity is that every story is almost always of the same size, whatever the size, even if our intuition tells us that the smaller the stories are, the better our calculations will be.

So we stop estimating user stories with story points – or whatever – and ask the team a simple question : is this story small enough? or better is this a standard story?

A the end of each iteration we just count the number of stories done and do our math…welcome to the #NoEstimates world!

How long will we fail?

#NoEstimates, ,

I was talking with a new member of my team about a new project’s first feature. The feature is kind of a prototype for the application, a full-stack slice of the application meant to get quick a feedback on some initial design choices. When my colleague asked me:

How long will it last?

I immediately answered:

I don’t know : how long do you think we will have to go back on our choices before we eventually get to a satisfying design? When will we be satisfied of our best bad idea?

I can’t remember the last time I have seen a developer satisfied of its first draft, or an architecture being satisfying right from the start.

The work of a developer is rather similar to the work of a writer. I recently heard French writer Bernard Werber saying that, before he can send a new book to its publisher, he must rewrite it entirely several times. He was saying that he rewrites the book without using previous versions : he remembers about interesting parts and can easily get rid of less interesting ones.

Developers follow the same approach : the first thing is to find an answer to a specific problem, which is telling a story in a way. When the problem is solved, which might not be done with the first try, developers deal with the style : is the story a little bit too long? is it easily readable? are all these characters really necessary? should we split this paragraph? etc. This is called refactoring.

So if we ask Bernard Werber to tell us how long it will last to write his next book, he will certainly answer that he cannot answer. At best he could try a pragmatic approach : “For 8 of my 10 last books I had to rewrite them at least 15 times but never more than 18 times. Moreover writing a book once never takes more than X months. We could then estimate that there is 80 % chance that I finish my next book between FOO and BAR.” Who would blame him?

Nevertheless nowadays people keep asking estimates to knowledge workers – developers. It might be story points, ideal days, or even month/man or real days. The developer must hazard himself into the dark art of crystal ball divination : he must first analyse the feature, estimate the development time of what he just imagined, predict how long it will take to get to a satisfying result – which may mean finding a better idea and implement it, predict interruptions, waiting times, bugs, perform a risk analysis, etc. It would be easier to roll a pair of dice.

I think this is the main difference between Lean and Agile Software Development : pragmatism. Making random estimates is pure waste of time, and taking decisions based on those estimates (alone) is a major risk for the project. That’s why leanists and kanbanists prefer statistical approaches and modelisations : taking decisions based on facts. Thus I should have answered something like:

Before you get in the team, the cycle time of 85% of the features was less than 8 days, and less that 12 days for 95% of them. In my experience, I can tell you that the first feature of a project is always longer than any other. Now that you are in the team, considering the fact that we must teach you how we work, we can say for sure that it’ll be even longer than usual. Nevertheless, it is impossible – I mean statistically – that it takes more than 14 days.


This post is an adaptation of http://matthiasjouan.fr/combien-de-fois-penses-tu-te-tromper/

Sticky notes do not make Kanban

Kanban and Lean Software Development,

I am often surprised to read or hear that many people think they are using a Kanban board when they stick notes on a wall. They say “We represent each stage of the process by a column and drive notes from left to right to represent work progress : a Kanban board.” This is frequently the case with Scrum teams, and you can find plenty of articles on the Web entitled “Using a Kanban board to deal with impediments” or saying things like “The main difference between a Scrum board and a Kanban board is that a Scrum board is reset after every sprint.” I’m sorry to disappoint you but sticky notes do not make Kanban.

The main confusion is due to the fact that the sticky notes we use on the board are not kanban “cards” (or just kanbans). Indeed, the sticky notes are usually used to represent work items, tasks, user stories, etc. Those work items travel through the boar. On the contrary kanbans represent the need to move work items. In a Toyota-like environment, they are messages meant to ask people before us on the process chain that we need them to refill the inventory, to produce more pieces.

So what about Kanban in software development then? Where are those famous kanbans if not the sticky notes? Let’s take an example to make this clear : a Scrum team of 5 people, 1 of them is a tester, 4 are developers. To take advantage of everyone’s specialty, they decide to change the classical Scrum board and process ( to do – doing – done) into to do – dev – test – done.

revisited scrum board

After a couple of sprints they notice a flaw with their process. Indeed, although everything goes fine most of the time, it happens that stories are easy and quick to develop, but hard to test. When this happens developers push many stories into the testing stage, the tester starts too many tests, plays too many scenarios at the same time and misses important defects, or cannot finish anything at all.

During a sprint retrospective, the team reminds itself one of the most important things about Agile : work must be completed (or done or whatever you call it). They realize that they cannot let work pile up into the “test” column and suggest several solutions. The first solution is to hire another tester, but this is impossible and would be unnecessary most of the time. The second is to implement a one-piece flow : the team swarms around a single item at a time, but it seems hard to implement and maybe a bit too extreme. Nevertheless the idea behind the one-piece flow looks good : limiting the work in progress to make sure that things are done. We could say that the tester cannot test more than one item at a time while the 4 developers can develop 2 items at once, as we practice pair-programming, plus a small buffer to improve flexibility. But how to do that : if developers push items into the test column there will be more than one item at a time sometimes. The solution : a pull system. The resulting board looks like this:

revisited scrum board with kanban

Developers will pull work from the TODO stage and the tester from the DEV DONE stage…and this board is a kanban board.

Still cannot see kanbans on this board? This is because kanbans are virtual. Here are the the two main ingredients that make kanbans appear on the board:

  • Focus on demand. The team has committed to providing a list of items during this sprint. To provide those items, they must be validated (the “test” column). To be tested, items must be developed (the “dev” stage). This is what makes a kanban system be a pull system based on need. Kanbans represent this need. There is no work without a kanban.
  • Limited-size inventory. To avoid piling up half-done work we need to limit WIP. Kanbans represent the availability of an empty slot to put a work item in.

So are you gonna tell us where those f***ing kanbans are? They are the difference between the WIP limits (aka the maximum size of the inventory) and the actual number of work items (aka the size of the inventory). We don’t usually represent them explicitly, but I have already seen boards on which WIP limits are not numbers but actual slots. What is important here is that kanban boards are not just about visualizing work items, they are an impressive tool to visualize resource availability, help identifying bottlenecks, help manage risk, improve predictability, etc.

In short, a kanban board is not a board with sticky notes representing work items, it is a board where is represented a demand-focused pull-system with limited work-in-progress. Sticky notes are not required.

EDIT (3 Jan 2013) : Mike Burrows just posted a very good, very complete article on this subject here. He gives an interesting value-based introduction to Kanban instead of the classical sticky-notes-based description.

Slack Time : A try-learn-improve catalyst

Kanban and Lean Software Development, Uncategorized, , , , ,
kaizen

In my opinion, a software development actor – by actor I mean a company, a team, a PM, a developer, the PM’s dog – starts being Agile and thinking Agile when he realizes two things. First that the customer – or product owner – cannot detail all the requirements and all the features at the beginning of the project, and will probably change his mind anyway. Second that software development is a creation activity (craftsmanship), not an engineering activity.

Once he realizes that, he begins to feel confident in the fact that some things cannot be streamlined and plan-driven from the start, that there is no such thing as a recipe to make a good software, and that both the requirement part and the pure development part are somehow made of try-failure-try-success cycles. So we try and experiment. If you are developer you might want to try and build your own set of best-practices that fit your current situation. If you are a project manager you might want to try to improve the process by making some small adjustments in a try-and-learn format. In short you stop being dogmatic, you stop thinking in terms of plan-and-apply and begin to believe in try-learn-improve.

This new try-learn-improve culture is basically what Japanese people call kaizen, which is kind of a buzz-word these days. The whole Agile thinking is based on the concepts behind kaizen : improve what you are doing every day, step by step, little by little, from the inside, each time the environment changes, etc.

At the highest level this is now a no-brainer: we stop trying to deliver the whole value – the whole product – at once but deliver it little by little, adding value at each step and gathering feedback as quickly as possible, allowing a quick learn-and-improve loop. Scrum, for example, completes this loop on every sprint through a review with the stakeholders and a retrospective with the team.

At a lower level, however, things are not so obvious. Of course people know that there might be some improvements to do. If you ask a developer, she might give you a list of two or three things that should be improved. Same for a tester. But they just can’t make those improvements. They just don’t have time. And because they don’t have time, they cannot complete the try-learn-improve loop. Why? Because their project managers try to hunt slack time down, believing in the 100%-utilization dogma.

There is a misunderstanding here, a confusion between “a good process utilizes all the resources at 100%”, which is questionable, and “utilizing all the resources at 100% makes the process good”, which is definitely wrong. And project managers that continuously try to maximize resource utilization are wrong. They are running after a symptom, a consequence of what they really seek. Metaphorically having a fever does not make you having flu.

If you are a Kanban-aficionado like me, you already know that limiting the work in progress can help us getting the process under control and ensures that things will end up being done. We are not going to start a hundred things at the same time without completing them. But WIP limits serve another purpose : creating slack time. When someone is “blocked” because of WIP limits and cannot do regular work he has to do something else, which can be about improving its own work, thus completing his own try-learn-improve loop, or, if you believe in self-organized teams, improve the current flow by helping unblock the bottleneck, or even improve the whole process if possible.

But even if you don’t practice Kanban, you should still try to create slack time, thus creating room for improvement. The main advantage of creating slack time with work-in-progress limits instead of scheduling it is that it might create opportunities for improvement right away. For example, a developer who cannot do regular work because the testers are overburdened might work on test automation improvement, etc.

As a final note, you are invited to read (and sign) Pawel Brodzinski’s Slacker Manifesto. You might also want to watch the video of his talk at LKCE2012 that deals with the subject.

A Bug Tracking Story

Uncategorized, , ,

I’ve been working at Ve-hotech for years now. I first started being a developer and then moved to a project manager position…and as far as I can remember the tracking of bugs has always been a problem. The problem is not actually the bug tracking itself but to find a way to handle bugs when you cannot solve them as quickly as they get reported by end users (yes, we’ve been through pretty tough times…)

A classical approach for handling an important amount of bugs is to use a web-based bug tracking system. This is a pretty convenient way to centralize all the reported issues. The business stakeholders can then sort the bug list and prioritize it, allowing the team to pick up the next more important issues and solve them.

Although this approach might be compulsory when dealing with hundreds of bugs or when the team is not collocated, it surely is a pretty big overhead when the number of bugs is thin and the team and product owners are working at the same place.

Understanding that nobody really wanted to use a web interface for managing bugs, that the redmine instance we were using was beginning to get out of sync, and as we were moving to Kanban, I decided to morph the bug tracking system into a physical, visual, post-it driven bug backlog. Imagine a 2-meter high sheet of paper covered with little, yellow sticky notes – 80 or so.

The goal of this bug wall was to ease the work of product owners, since they could see everything at once and select the defects they wanted the team to solve more easily. New issues were added into a special area of the wall so that stakeholders could identify them and decide where to place them on the wall – and when to put them into the Kanban flow.

There were three main drawbacks with this bug tracking implementation :

  1. The team – the people who know about the technical part – was not much involved into the prioritization/evaluation of bugs criticality
  2. There was no simple way to get a whole-picture view of the product stability
  3. Who can possibly sort 80 sticky notes?

To solve these problems, the boss (I wish I have thought of that first but…) came out with the idea of using a sort of criticality matrix.

We could actually dramatically improve how bugs were handled using two criteria:

  1. Intrinsic severity : Does this bug jeopardize users’ data? Does it happen all the time? Is it highly visible? On the contrary is it only a highly improbable situation? Maybe we could not even see it by ourselves? etc. We decided that four levels of criticality were enough, each one having its own set of criteria.
  2. Technical impact : How the team feels about this issue. Is there any identified risk? Is the fix difficult to implement? Do we need to rewrite an important part of the product? Do we even have a clue about how to debug this? etc. We don’t need any precise measures or calculations here. A simple gut feeling will do.

So the current implementation of the matrix is a 2×2-meter grid with horizontally the intrinsic severity, from A to D, and vertically the team feelings : 

As you can notice the first line is special. Bugs that cannot be quickly evaluated go there and need special attention as basically the team do not know where it comes from.

In the above example the two bugs in [A/???] are highly critical and must be dealt with as quickly as possible since, for example, they happen all the time and threaten user’s data, and the team don’t know at all how to solve them. On the contrary the four bugs in [D/:-)] are likely to be very improbable bugs that would be very easy to solve with no real impact on the rest of the product. There is no emergency to treat them.

As we wanted to have a global stability indicator, we affected each row and column an arbitrary coefficient : A=20, B=10, C=5 and D=1; ???=4, : -)=3 etc. In the above example, each [A/???] bug is worth 80 points (20×4) whereas [D/:-)] bugs are worth 1 point each. The above matrix can thus be estimated : 20*(2*4 + 2*2) + 10*(1*4 + 4*3 + 2*2 + 1*1) + 5*(1*4 + 4*3 + 4*2 + 2*1) + 1*(2*3 + 1*2 + 4*1) = 592

This approach facilitates decision making about scheduling while providing a good visualization and an easy-to-understand stability indicator. It can also break the last silo that might still exist in an Agile organization : the one between product owners and teams.

Do you use a visual tool for bugs with your teams? How do you prioritize them? Go share your experience and answer this follow-up question in pm.stackexchange.com

Nietzsche on Agile Software Development

Not serious, , ,

DISCLAIMER

What you are about to read is almost completely wrong. I’m obviously not a philosopher so don’t hold it against me please. This is also a huge shortcut of what Agile really is, and what values it really relies on. It also features a couple of myths and commonplaces about Agile and non-Agile thinking. In fact this article is a joke.

Background

Before the Agile era begins in the mid-1990 early-2000, software development methods was essentially copied on age-old methods from industry or architecture. The common belief was that the biggest the requirements are, the better the end-result will be, and the more details we have before we start, the better the design will be. So before coding actually starts, projects had to go through several specification-validation loops. When the requirements were eventually accepted and the design finally validated, the documentation mass could be transmitted to the development team which had to “do it”. So the thing was as follows:

No need for good developers as long as the process is followed scrupulously.

…that was a mistake, and Friedrich Nietzsche warned us about it long ago.

der Wille zur Macht

An important component in Nietzsche’s philosophy is what we usually designate as “Wille zur Macht“, the will to power. Nietzsche believes that the number one driving force of human beings is his will to power: the will to reach the highest position, the will achieve more, the will to have control on things we do, on things that surround us.

Earlier, Arthur Schopenhauer identified the will as being the driving force of all things, especially the will to live. In Die Welt als Wille und Vorstellung, he defines will as the kernel of everything. Will can be found behind every desire, every expectation, every wanting.

Nietzsche, who were influenced by Schopenhauer, precises that this particular will that drives human beings is the will to power, not only the will to live.

In the posthumous book Der Wille zur Macht, Nietzsche write:

My idea is that every specific body strives to become master over all space and to extend its force and to thrust back all that resists its extension.

The problem with pre-Agile methods

Pre-Agile methods emphasize processes, documentation, specifications and requirements. This over-usage of pre-coding documentation is meant to force developers to code in the exact way that the architect want them to code, theoretically ensuring that the result will be what the architect designed; and what the client wanted provided that the architect followed a same set of rigid methods and processes.

In industry this kind of reasoning can possibly work if workers’ field of action is restricted to the bare minimum. The problem with software development is that the field of action of developers cannot be restricted in such a way that they only have to put a screw in a piece  metal. Software development is not an industry, it is a craftsmanship, and this includes some creativity. According to Merriam Webster a craftsman is “one who creates or performs with skill or dexterity especially in the manual arts“.

You cannot restrict a graduated man with a high skill level into following scrupulously a huge specification and architecture document. His nature, his will, will struggle, fight for more space. The guy will start thinking : “Hey!? What the f*** is that? This architecture is just a non-sense!”, “I would have done better”, “Ok, they want me to do that, I will do that…but it’s completely dumb” or even the famous “It’s not a youngster like him who will teach me how to do my job”. Will needs space…and responsibilities.

The Agile way

The Agile manifesto reads as follows:

We are uncovering better ways of developing
software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,

Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

The most important part here is “Individuals and interactions over processes and tools”.

The Agile philosophy is based on the principle that people are more important than processes, and grant them with more responsibilities, give them more space. Now developers have enough room for their will to expand. They can interact directly with the client, their team is self-managed, there is no heavy architecture adopted without the team consent, they are responsible for designing the application at a code level, including the OOD, etc.

Clearly the developer becomes the center of a project…but this does not mean anarchy. This means responsibilities. There is no way to hide behind a project leader : the team has committed itself. The code must be clean : someone else is coding in this part tomorrow. We have rules to follow : not the ones from an enterprise architect but the ones the team has given to itself.

Conclusion

In the 19th century, Nietzsche already knew that individuals were the center of all things. He knew that the will is almighty, that the will to power is what drives people, that people need more responsibilities, need to be considered as what they are, need to become better than what they used to be, need to achieve things. This is what Agile methods do by placing people in the center and considering developers as what they are : craftsmen.

…Ok I’m out.

References And Readings