Edge of Chaos | Agile Development Blog

Today I’ve read two interesting posts: The Cost of Code by @unclebobmartin and Code as a Cause of Project Failure by @DocOnDev. They discuss various arguments to prove that all projects fail because of code. The main argument is that if code is free and light-fast to change, project can’t fail. OK. But this case is rather extreme and obviously impossible. We don’t live in a world with hyper-space jumps, teleportation and free medicine (unfortunately). In real life code costs a lot and it will be true in the next decades for sure, so this argumentation proves nothing. In ideal world there is no such thing as code. In ideal world you have a solution in seconds without computers, software and other complicated things. So I don’t buy this idea. Code is not the main reason for projects failure in reality.

Code is not free. Code is expensive. We do not sell source code though, we sell solutions. If it is possible to create a solution without source code, it would be fantastic. Let’s take an industry that handles tangible objects. Automobile industry does not sell carbon and metall — it sells cars. It sells a solution to transportation problem. Teleportation is an ideal solution, but we can’t teleport nothing but electrons, sadly. We buy cars to get from point A to point B. We buy a solution.

Code != Solution

I think the main problem with projects is that they provide either bad solution or no solution at all. Nobody buys stagecoaches these days, since there are more efficient solutions. If a project does not solve anything, it will fail. If a project solves something, but  in a nasty, unusable way, it will fail. You can create an absolutely beautiful architecture with the cleanest code in the world. You may have 100% test coverage, complete separation of concerns, flat hierarchies and methods without boolean arguments. You may have all that beauty, but still fail miserably if the program does not solve user’s problems efficiently.

You may argue that with clean code you can refactor it fast and change everything. C’mon, it will be a full re-write if it solves the wrong problem. Can you fix a stagecoach to make it a true competitor of a car?

On the other hand, if a projects solves a right problem, but with some issues, clean code is very important. You can’t adopt fast without it. You can’t change things and react to people demands.

Don’t get me wrong, I believe that clean code is an important thing, but it is not the most important asset in software development.

There are various ways to support agile team retrospectives. We’ve used all of them, so let me share our experience.

Cadence (usual retrospectives)

If you have iterative development like Scrum or XP, it is very convenient to run usual retrospectives meetings. For example, with 2-week iterations you have such meetings every other week, discuss issues, what worked, what not, brainstorm solutions and new things. We’ve tried mood boards, various formats for issues gathering and for action items tracking. We’ve tried a whole lot of things in 2 years. In general, it worked. But then we switched to Kanban and somehow retrospective meetings faded out…

Is there a better way to improve development process?

Stop-the-Line

We tried to apply stop-the-line practice. It states that as a mistake or malpractice is discovered all responsible people should immediately hold a meeting to resolve/prevent this specific problem. There were several stop-the-line events, but this practice did not survive. Why? There are two main reasons.

1. It is very disruptive. People are working on various unrelated tasks and are in the flow. Suddenly they should switch to a problem resolution brainstorming. Many people don’t like to do that.
2. It may take too long. Sometimes the problem is very hard and it takes much time to find a good solution. People impatiently drink coffee and want to get back to work.

So we dropped stop-the-line practice and replaced it with a pure pull system.

Pull / Issues Board

Issue Board is a very simple concept with 3 basic rules:

1. Every person in a development team can write a problem or a new idea he wants to discuss on a whiteboard (Issues Board).
2. There is a limit of 3 problems on the board.
3. When there are 3 problems on the board, we have a retrospective meeting right after a daily meeting.

We have been using this approach over the last several months and I like it most. It leaves off some problems both of the stop-the-line approach and the cadence approach. First, if there are no issues or ideas, there’s no need to have a meeting :) Second, no interruptions, since daily meeting is interruptive by itself, so it is just natural to have a retrospective meeting right away.

If you have other approaches to retrospectives, go ahead and share them!

In Part I I’ve described 5 mistakes in agile adoption, this part has 5 more.

6. CST Knows Everything

Certified Scrum Trainer is not a God. Yes, he knows a lot and has a decent experience. There is a high chance that he may be a capable person to help with agile adoption, but only help. He may know nothing about your domain, about your unique situation and about root problems of your organization. If you rely solely on CST and delegate agile adoption to him, it will fail.

Everything should start from the culture and people. It means everything should start with you. You should share agile values and support CST with all the passion and force you have to make agile adoption a success.

7. Functional Departments Should Survive

You are starting a new agile project. Design manager delegated one designer to the team, but refused to re-allocate his desk. QA Manager delegated several testers, but refused to re-allocate them. Developers sit together, but all the other team members are separated by walls. Sounds familiar? Most likely there is no cross-functional team there, and agile adoption will suffer. 

There are absolutely no reasons to keep functional departments and functional teams. People should work together as a team whenever it’s possible. Definitely, when you have testers in US and developers in India, it is hardly possible. But it is just plain dumb to NOT have cross-functional team if everybody sits in the same building.

Cross-functional teams have so many positives, and no negatives. With cross-functional teams you improve communication, reduce functional competition, simplify problem solving, enable ad-hock process improvements and creativity. Again, there is NO reason to work with old traditional functional teams.

8. We Can Live Without Customer Feedback

Agile is mostly about fast feedback. Feedback from customers is the most important. If you build something with wrong methods, that’s bad. But if you build a wrong thing, that’s just terrible. Why? You will have to throw it away later. Regular (and fast!) feedback from customer is like a sailing direction in a bay with reefs. You constantly correct the course based on wind change and other factors. Customer is the most valuable team member and should be treated accordingly.

Extreme programming recommends to have customer on-site. While this is a great tip, it is rarely practical. Still, you have customer available remotely all the time to answer questions and communicate about a product. If you can’t have feedback in a reasonable amount of time, agile methods will not work. You may build a technically perfect product, but yield zero customer’s satisfaction in the end.

9. Self-organization is Easy

Scrum heavily advertises self-organization. Complexity theory has something to say about it as well. Self-organization is based on a set of (simple) rules, non-linearity and interactions between agents (in our case between people). As a Scrum Master you should just set some (widely known) rules, protect the team and expect the team to self-organize. Right? In reality it is not that simple and no, it will not work out. I’ve never seen self-organization working with just a set of rules.Self-organization in a software development team needs more, it needs leadership. I believe that self-organization can’t happen without leadership.

Pure self-organization assumes that a leader will emerge. That’s not happen frequently, in many cases team will stagnate and fluctuate around mediocrity without a leader. Leader sets a vision and pushes team to the right direction. Leader empowers confidence, passion and self-reflection. This leads to self-organization eventually. 

What happens when leader leaves the team? In most cases it falls back or degrades slowly. This is a clear sign that self-organization was not there. True self-organized team will keep its values and progress without a leader.

10. False Goal (e.g. Customers asked us to be agile)

If you have a customer who insists on agile process for his project, you should praise Heaven for this gift. Use this chance as a turning point for agile adoption.

Unfortunately, many companies just try to “emulate” agile adoption with a desire to get this contract. They send some people to CSM courses, purchase an agile project management tool and apply Scrum superficially. They do all that without deep goals and culture change. They do all that without passion. They do all that with a false goal. Almost inevitably there will be the following symptoms:

• Sprints fail. Always.
• No commitment. 
• Scrum Master assigns people to user stories.
• Testing phase in each sprint.
• etc.

The result of “false goal” agile adoption is failure and a long-term disappointment with agile software development.

I encourage you to share another mistakes in agile adoption!

They did it again. Companies are making the same mistake during agile adoption over and over again. We’ve made some of these mistakes as well. If by any chance you see something familiar in the list below, read on and find out why it is a mistake.

1. Start With a Tool

It is not always bad to start with a tool. If you want to dig a pit, you most likely want to find a shovel first. You can dig manually, without a tool, but it will take enormous amount of time.

Agile development is something different. A tool will not provide immediate effect and will not solve most of the problems by the mere fact of its existence. Moreover, you will put effort into tool adoption, shading more important goal — agile adoption.

We encounter this mistake quite often. People come to TargetProcess web site, register for a trial, install the tool and try to use it. They start to ask questions and it’s getting clear that they have no experience in agile development neither agile process established. Sometimes they don’t know what a Burn Down Chart is and how to use it. Sometimes they know nothing about iterative development. It happens. The only piece of advice we can give is to get rid of the tool and dig deeper into agile domain: become familiar with basic concepts and try some process with simplest tools like whiteboard and sticky notes. Then decide whether you need a more sophisticated tool.

2. Start With a Process

Starting with a tool is obviously a bad idea. Most companies start with a process. It is a less serious, but a more common mistake. So you read about Scrum, it looks easy initially. You apply all Scrum practices and after some sprints see that development somewhat improved, but not as drastically as expected. Excitement goes away and process degrades.

What are the reasons? Why has it failed? Most likely people didn’t get the core values of agile development. Process is the mechanics, while values are the core of any agile adoption. The first thing any company should do before trying any process is to focus on agile values such as: communication, collaboration, feedback, trust and passion. It is nearly impossible to apply a good development process if you compromise any of these values. As an agile champion you should enforce these changes. Sometimes these are company-wide changes, sometimes team-wide changes, but still it is absolutely required to apply them.

The fastest way to adopt agile is to start with people and culture. I can’t stress this enough. And it is quite obvious! But why so many companies (including ours) have made this mistake? It is blazingly hard. You will have to change culture, and that will be met with a resistance. You will have to change people and most likely you’ll have to fire some of them. It is a hard and complex process, there are not so many people in the world who know exactly how to apply it. Most of us have no such experience and skills, so we fear this change. We try to start with something easier, something we know. We try to start with a process, with a tool, or with hiring an external consultant (which is good, but not enough). We should fearlessly start with the hardest but the right thing.

Agile manifesto is very deep indeed. If you read it carefully and set the principles as a cornerstone of agile adoption, you will success eventually.

3. Development Practices Are Enough

Extreme Programming is a very cool agile software development process. I think it includes Scrum. Many people may disagree, but in general if you do XP fully, you don’t need Scrum. Interestingly, that developers tend to apply technical practices like TDD, Continuous Integration and even Pair programming, but pay less attention to such things as communication, integral team, having customer on-site and retrospectives.

Why is it like that? Developers are techies, and techies like technical stuff, while often disrespect social stuff. Many of them are introverts, they don’t like meetings, they don’t like to chat with people extensively. They do like to communicate about technical things and do that with passion. However, communication with customer is not about Clojure or fancy lambda expressions, it is about business. It’s business problem domain, and it’s not that interesting for them.

Again, agile is more about people and less about technology. Many practices are focused on people. Pair programming makes for more communications between developers. Customer on-site makes for more communications with end user. Retrospectives boost communication about team, processes, etc. It is absolutely required to apply practices that focus on communication, adoption and fast feedback. It is absolutely required to pay more attention to people, improve their skills, improve technical excellence and shift mindset.

4. Scrum is Enough

Is it possible to adopt agile without technical practices at all? No, it is not. However, it is a less severe mistake than the previous one. If you apply Scrum right, you will inevitably decide to try some technical practices at a retrospective meeting.

The true mistake will be to rely on Scrum solely as a process that will solve all the problems. It can do that, but only if you are open-minded and willing to try various things: from pair programming to BDD. Best coaches believe that Scrum should be adopted in tight pack with XP technical practices. This is a good advice to follow.

5. CSM Knows Everything

Certified Scrum Master is not a demigod. Yes, he has some basic knowledge about Scrum, but in many cases that’s just it. He may have no hands-on experience neither strong theoretical background. He should not act as a PM and prescribe what to do and what not to do. Team should decide. The only real things SM should care about are teams impediments and meta-process. By meta-process I mean a set of rules/procedures that allow team to reflect and improve existing development process.

Common manifestation of this mistake is phrases like “I insist we should change iteration duration from 1 month to 2 weeks” or “I strongly believe we should keep doing code reviews”. It might be that he is right, but it does not matter, the language speaks for itself. There should be no “I” in SM phrases, there should be “We”. Otherwise agile adoption will fail. If SM doesn’t believe in team, the team as such will not gel and will degrade eventually.

Read Part II for last 5 mistakes.

Agile software development is a cooperative game. At least Alistair Cockburn thinks so. I share his opinion and want to dig deeper. There are two words in the definition: game and cooperative. Let’s open the dictionary (isn’t it a silly trick to start a post?):

Game

Ha! Now it is clear why luck is important in software development at least. There are 2 more serious and interesting words in this definition: play and skills.

Let’s skip the details and go right down to the real meat. I have a theory. It is very simple, but my short experience proofs it. Here it is:

Why is that? Well, because software development IS a game. There is no elegant formal proof for this theory (so far, I am drafting it), but I have some in-vivo observations and some ideas behind.

Let’s take a non-cooperative game like table tennis. What do you need to do to play table tennis really well? Just 3 things:

1. Like table tennis.
2. Like to win.
3. Train to sharpen your skills.

If you are a decent player, you already have 2 very important skills for software development:

1. Know how to set goals and how to reach the goals (and what does it mean). In table tennis the goal is to win. In software development the main goal is to create a working software. You can directly apply your passion and feelings toward this goal. You are good at table tennis, why not be good at programming? It sets a goal-oriented mentality and helps a lot.

2. Know how to improve and maintain your skills and why it is important. I bet you knew nothing about top spin and dirty tricks as you stood by the table first time. I bet you knew nothing about OOP looking at first lines of code in your life. But you mastered the top spin. And you got OOP eventually. It is all about learning. Games help to set a learn-oriented mentality and that is huge.

I know a person who is equally great at various games: from Quake 3 and chess to table tennis. I believe he will become a great software developer. And I know people who don’t play games (almost), and I don’t think they will really rock sometime.

Now let’s dissect another word.

Cooperative

Mutual assistance and common goal are nice phrases. Cooperative brings team into the game and it makes huge (really HUGE) difference. You may play games and be a real star, but you may just suck at team games. There are people who are great software developers, but poor team members. They can hack alone and create nice staff, but can’t maintain communication with the other team members, don’t like to assist and pursue their own goals only.

Now imagine that you like to play software development game. You know how to win. You like to help others if it leads to a win. You are sure that your teammates will help you when needed. You share the common vision with the team. How cool is that? Do you want to work in such a place?

Now it is obvious that

It means you can (should?) play basketball, or football, or water polo, or whatever as a team to improve your cooperation as a team. It helps team to jell. It helps people to know each other. It helps leaders to emerge and lead the people. It helps to find people who don’t care. I understand that it is hard to find a game you all can play, but it is worth trying.

Disclaimer. Every rule has exceptions and sometimes you come across great software developers who don’t like games (and sport) at all, but I am curious enough to know what are they good at apart from software development? Maybe they write poems? Or maybe they paint like Monet? Are there parallels between art and software development? It is an interesting topic indeed.

Many interesting posts and discussions about Scrum and Kanban published last weeks. Someone even called this a war :) I don’t think it is a war, but some posts indeed may drive such feeling.

• Ken Schwaber bashed Kanban. “I was told that Kanban is frequently used when an organization cannot readily adopt Scrum. Many of Scrum most difficult aspects are then sidestepped. Managers are still in charge of telling people what to do. People can be interrupted at any time. People are still work in functional silos, preserving the jobs of functional managers. People are not allowed to work in containers, sharing skills and knowledge to bring complexity into solutions – instead they are worked on a pull (more sophisticated than push) production line.”
• Karl Scotland discusses Scrum and Kanban difference as Intentional vs. Implementational approaches. Interesting perspective in fact. Karl thinks that Kanban can be used with Scrum to reveal even more problems in development process.
• David J. Anderson posted the most rational article about Scrum and Kanban difference. I like it a lot. Some phrases are true gems: “Kanban is not a project management or software development lifecycle method. It is an approach to change management – a framework for catalyzing change in an organization.” and “Kanban uses a WIP limit as a change agent and Scrum uses commitments. This is a fundamental difference in approach.” David also posted some reflections later with interesting thoughts about anarchy and science.
• A year ago Tobias Mayer didn’t believe that it is possible to use Kanban at all. “I fundamentally disbelieve that there is any such thing as a “value stream” when you are working in a complex environment, in a creative process, building new products or generating new ideas.”

I think Ken is wrong. His arguments against Lean and Kanban quite ridiculous. Sure there is no intention to treat software development as a factory and apply lean manufacturing principles blindly. Of course there are people who will try (or already tried) that and fail. But vast majority of lean community in software development do understand the difference and working on concrete practices. Lean philosophy is great, but tools and practices can’t be taken from manufacturing directly.

Pull system is more complex than Push? C’mon!

David has wise arguments and perfect position. I think Kanban will be more popular than Scrum in long-term perspective, but it will take time. Visualization is a key thing to manage complexity, and software development is a complex system.

“You can’t apply Scrum without an external expert”
“You can’t apply Scrum without a Certified Scrum Master”
“You can’t apply Scrum without XYZ”

You can replace Scrum with any other buzzword. Is it really necessary to have an agile coach on board to join agile camp? Is it really required to send someone to CSM courses and delegate Scrum adoption to this brave knight in a shiny armor? I believe it is not the only way to go, and there are 2 reasons that support my vision:

1. I did not attend any courses, conferences and other events, but I did learn agile and became an agile expert.
2. We implemented agile process in our company without any external help.

To me it looked (and still looks) natural to improve development process internally. It was an ad-hoc agile adoption  in our company. There was no defined structure, but on-going learning. People have been reading books about agile development which I recommended. I’ve been making some presentations about agile history, main processes and so on. People have been reading articles and discussing new ideas. It worked out, finally. Even with such an unstructured approach you are able to set up an agile company. But are there better ways?

Agile Coaches

What’s wrong with external coach/trainer/consultant? Nothing, actually. You pay someone to teach you. You pay someone to inject agile culture into your company. You pay someone to get it faster.

The problem is that this process is so slooow. It is inevitably slow, because all the mindset changes are slow, and you can’t speed them up greatly. My estimate is about 1 year as a minimum (no proof, sorry, just personal experience). You can’t absorb all the agile spirit in a shorter period of time (maybe some geniuses can, but they don’t need coaches anyway). I do believe that a good agile coach can speed up agile adoption, but not as greatly as often advertised.

OK, so changes are slow. It is absolutely required to manage the change over a long period of time. You can’t setup something, run it for a couple of iterations and leave. There is a high chance that development team will degrade and slip back to old-and-oh-so-known practices quite fast. It leads to several possible conclusions:

1. If you hire agile coach, it is better to have about 1 year contract.
2. If you hire agile coach for just 3-6 months, setup internal learning/change process as fast as possible.

The main idea of agile adoption is a paradigm shift. People should change their habits, rituals, working patterns and activities. It is SO hard! Some people just can’t accept it and leave the company. The goal of agile adoption is to change mindset of as many people as possible and let rock-hard minority go.

So why I personally don’t like the idea to hire someone who will teach us agile? It immediately puts our intelligence to question. Are we really not able to learn ourselves? Can’t we read some books, discuss them and try, for example, Scrum in a single dev. team? If we want to hire someone, to me it looks like we’ve already given up and can’t do anything cool without external help. It looks like we got exhausted and now need a power recharge. It is similar to an external CEO hired in a desperate attempt to save company.

Don’t get me wrong. Agile coach can help greatly. But I don’t buy the paramount idea that development team can’t go agile without external help.

Problems and Solutions

I like challenges and like to solve problems without external help. What I like is a full team involvement and participation. It is so cool when people discuss problems and generate solutions. If I ever hire an external consultant, it will be a person who will teach how to solve problems. Problem solving is the MOST IMPORTANT skill (can I stress it more?) for any good developer/tester/designer/you-name-it.

Here I see a major flaw of Scrum as a methodology (so far?). It does provide a framework, but it says nothing about problem solving. OK, you should have a retrospective meeting every other week. You should identify problems, generate ideas and write action items. You should execute action items and retrospect in 2 weeks. Sounds good. But HOW to identify problems? HOW to generate ideas? Scrum says nothing about that, but I believe this should be the core of any agile process.

That is why I pay more and more attention to lean and other problem solving techniques like 5 Whys, TRIZ, etc.

Knowledge From Within

There are various ways to ignite the team and solve problems internally, but you can’t solve problems effectively without knowledge. Study Groups could be the most promising way to educate people. To be honest, we did not try it. As I mentioned, we did not have any structural approach so far, but intuitively came to something similar to Study Groups.

Study Group is a small group of people (4-6) that have cadence sessions e.g. weekly. There’s no distinct leader, they rotate with every session. People should be really interested in the domain. For example, if you have Study Group to learn TDD, all the members of the group should be passionate about TDD learning and actively participate in discussions.

Why I think Study Group should work? First, there’s no Boss inside. People can freely discuss various problems without pretending that they know everything. Second, there is a clear focus. You should not form a group with a goal to solve all the development problems, instead it is better to form groups to study UX, study TDD, study Scrum, study Lean. Once again, Study Group is not a problem solving technique, but it helps to educate people. And it is absolutely clear that educated people will generate better solutions faster.

Here is the nice summary about Study Group. And here is the list of other learning methods that every agile team should pay attention to.

Kai Gilb started a series of posts that challenge Agile Software Development. Part 2 is about creativity and “how well” focus in software development. While I agree with the problem, I strongly disagree with the solution. Kai recommends to write requirements (the format he uses doesn’t allow me to call it “user stories”) in a form that does not contain solution:

Developers Are Not Product Owners

Then developers should creatively find the ways to implement this requirement, to invent the solution and to solve the “how well” puzzle. We’ve got a huge problem here indeed. Most developers can’t invent solutions at this high level. They can create beautiful architecture and build the quality in. They can write tests upfront and use powerful tools to speed up development. They can do many things, but often they can’t invent a “how well” solution that will make customers happy. Why?

1. Most developers know nothing about User Experience (and don’t care).
2. Most developers can’t create usable design.
3. Many developers barely know a problem domain and in any case don’t want to dig into much details here.

In short, most developers are engineers (so far?), so what Kai proposes will not help. It is just a theoretical solution to “how well” problem. It’s the same like trying to grow 4 hands and 2 heads to double your productivity (well, sacrificing beauty maybe…)

In Scrum Product Owner is responsible for writing User Stories. It means he should invent solutions and care about “how well” thing.  I don’t see a significant problem here. Of course, it’s great if developers are interested in requirements handling and solutions investigation process, but if they are not, Product Owner can do that alone or with special people who care. Who they can be?

Those people are UX specialists. They know how to solve “how well” problems effectively. They know many things about design patterns and all new trends in interfaces. They like to explore problem domain and talk to customers. If you have such people among developers — you are SO lucky! But often this is not the case.

We, at TargetProcess, try to instill UX culture into development process. We started in August, now it’s February and I can’t say we’ve had much success. Sure there are significant improvements, but to be honest most developers are not so interested in UX staff, they like BDD, DDD, C# and SOA more. I expect it will be a long process that will take years. And our company is quite small. I can’t even imagine an effort for such a radical shift in a huge company.

Broad Requirements Are Not Testable

I wonder how you can write BDD scenarios for broad requirements as Kai suggests. How the hell can you test anything, if you don’t have any clue on how it should work? So broad requirements can’t replace user stories obviously. They can live in backlog, but developers should deal with concrete requirements that are testable right away.

I can agree that you can split backlog in 2 parts. The first small part contains detailed stories that can be put to development asap. The second large part contains broad requirements without solutions. That might be a good idea. But we should clearly separate UX phase and Development phase. During UX phase we should solve “how well/how cool” problems, and during development phase we should solve technical problems only (with some corrections in “how well” for sure if required).

P.S. Kai, I hate gray text on gray background in your blog. It is not user friendly.

I read Agile development grows UP article written by Mark Lines. It has quite a strange taste… Is it an attempt to advertise new methodology? I hope it is, otherwise Mark is completely missing the point and agile development trends.

I want to review the article. Just can’t resist, sorry.

Many of us don’t have the benefit of co-location, where the entire team works in close proximity (ideally in the same room), with the user representative present at all times to answer questions

Sure we all know that a co-located team is better. It is not a surprise that consultants advise to co-locate team members. If you need to win the race, it is better to drive BMW M3 than Ford Focus. There are so many discussions around distributed agile this year. There are so many ideas and experience reports on how to implement agile remotely. Agile works in remote teams.

Pair programming i.e. 2 programmers sharing 1 keyboard is an expenditure most management will not endorse

It’s a very strange argument. Many managers will not support continuous integration, iterative development and BDD. It does not mean that these practices are bad. Context is everything. In some companies and on some projects pair programming will increase productivity. While on other projects there will be no benefits or even degradation. How many agile coaches insist on pair programming and say “You are not agile without PP”? Not many. It is wrong to spread this argument to the whole agile community.

Delivering a system without moderately detailed requirements (beyond User Stories) is not acceptable for testing, writing training materials, and production support purposes.

C’mon! User stories can be VERY detailed. For example, you may use BDD-style user stories format and write many cases that will describe functionality in some format, that can be directly converted to unit tests! It is an incredible thing, to be honest.

Fixing architecture as you go (i.e. refactoring) without some initial architectural design is not appropriate for large-scale enterprise systems

Most people in agile community believe that it is required to spend some time on architecture. Again, it is so context dependent. If you create a simple application, one day may be enough to nail down all important decisions. If you create a complex system, it may take several months. Common sense is a critical factor here. There is always a danger to over-architect things and working software is the best proof of concept.

Also something called “emergent architecture” is being developed. I like the idea and maybe it is a right direction.

Most projects are not completely independent and cannot be built in isolation. Dependencies and integrations with other systems are required and require some co-ordination.

Agile adoption is spreading rapidly and indeed there are no common/standard approaches to solve this problem. But I believe it will be resolved during agile enterprise adoption (and we already stepping into this phase).

Organizations usually have some governance practices in place (such as PMOs, ISO, CMMI) that necessitate a level of bureaucracy and documentation

Does it all mean that PMO, ISO and CMMI are good and we should give up and follow the rules? Agile community tries to fight bureaucracy and I personally love that. Documented process means NOTHING for success of software development project. In 90% of cases it holds you in the spider’s net and blocks creativity. There is NO software development without creativity. Wake up, Mark.

We live with these standards, but we should fight them.

Deploying software to users every 1 or 2 weeks is usually not practical in most organizations. Just migrating software through development, test, system test, user acceptance, production environments is a major undertaking. Having many projects trying to do this in parallel on a weekly basis simply isn’t feasible.

This argument is so common… and “not practical in most organizations” is a truly masterpiece. Any statistic data? Did Mark try to deploy anything outside the enterprise-scale Java mastodon applications world? Many SaaS services do painless weekly updates. Some services do painless updates on a Daily basis! It is unbelievable, but I like that. Customers like that!

Mark promotes OpenUP methodology (based on Unified Process). Only advantages in the post, no disadvantages or context at all. Folks, I think it is a so long-awaited silver bullet! Finally it is there! Let’s bury Scrum. Let’s bury XP. Let’s burn Kanban and all the other processes that spark agile movement. God bless the OpenUP silver bullet. Amen.

I’m digging into Lean Manufacturing and it’s so interesting to learn manufacturing history and its trends. There are so many parallels between manufacturing and software development. Of course they are not direct, but a curious mind can draw them quite easily. Let’s take Cellular Manufacturing as an example.

Cellular Manufacturing is a workspace organization technique. The main principle is to organize production of a single product in a small dedicated unit (cell) that consists of several people and several workstations. The benefits are surprisingly huge:

“The result is very fast throughput. Communication is easy since every operator is close to the others. This improves quality and coordination. Proximity and a common mission enhance teamwork.”

It is a significant improvement over the functional space configuration, when you have large queues and long transition time.

Now, if we think about software development, it is becoming clear why distributed teams have problems and why functional departments will not survive in the near future.

Cellular manufacturing applied to software development directly leads to cross-functional teams that work on a single project. Cell is a single team that has its own inventory and cross-trained people. Expanding it further, it means that developers should be able to do testers’ job, and vice versa.

From lean perspective, managers job is to setup cells configuration efficiently. It is not required to track individual work, but to track cell work instead. It brings process optimization to a higher level and powers system thinking.

It is really amazing how much we can extract from lean manufacturing and adopt this knowledge to software development…