Edge of Chaos | Agile Development Blog

We live in the age of added value. It’s everywhere. Value-added services, value-added products, value-added goods etc. etc. etc.  Actually, so much value has been pumped up in our life, that it’s even strange that this value is not protruding from us like clothes from an overly packed vacation suitcase.

If we take a closer look at the back side of added value, a huge surprise is waiting there. The example I find most notorious is cell phones. What if I want a simplistic cell phone with NO Internet, no camera, even no voice mail, just live calls and SMS?  You’ll never ever find such a phone.

I bet that a phone manufacturer who stops the rush for more new features, would make a fortune in an instant selling the “new frugal” cell phones. In this case, the added value is content which comes from Internet, capabilities to exchange content. Why should someone want a phone with Internet?  My word, very soon we will see such phones on the market. The niche for them is already there. Here’s why:

More content and more various channels to produce and exchange content is now commonly presented as added-value. Hence, a communication device which happens to be a humble phone is supposed to deliver this value. But as we’re oversaturated with content, no buzz is a huge deal. The luxury of focusing on one thing at a time is something that only a few can afford. Besides, it’d be very frugal (frugal is actually the new buzzword to buy a phone for a reasonable price, and sell used iPhone to some geek. Oh, pardon me. It’s all about iPads now

There’re plenty of such examples. Another one: the added value of having a car means lack of natural movement, the necessity to pay for gym etc. It actually brings along the whole array of more added value  goods and services that turn out to be not of added value but of less value, since you pay for what you could do naturally.

Take organic products. Now they’re added value. 100 years ago who could have thought that something natural adds value? Now it’s a rollback. What is simple and natural costs more, but has less value compared to the original added- value concept for the matter, and the cycle goes on and on.

And we’re nailing it down to our favorite: project management tools. Versatility and too many features now have bounced back to the simplistic Kanban board.

It looks like it’s time to not only practice lean production, but to produce lean products. Gaining focus requires focused tools, one way or another.

Yesterday Google alerted me about a review of TargetProcess  by Boris Gloger. I started reading this review and I couldn’t believe my eyes. How could Boris Gloger, such a respected Scrum trainer, overlook some important features of an agile tool he’s reviewing?

Writing reviews  is a very responsible task. It only seems that web can tolerate all. There’s no censorship, no security checks on whether the info in a review can be trusted or not. Reviews are about knowing all the facts. Only when you make sure that you know all of the subject matter, then you can write a review.  I’d never stand up as a guru and claim - my people, I’m your guru, I know all about this tool -  and then - ooops.. - I’ve got some essential flaws in my knowledge of this tool.

Now, let’s see what Boris Gloger overlooked. Comments on Boris’ page do not work(!!!), unfortunately.

Target Process is a tool created by Target Process Inc. to manage agile process. They can support Scrum, Extreme Programming, Lean and others. The tool have a good set of features and some nice ideas to speed up the addition of data for your project. They also provide a Eclipse and Visual Studio add-in so each developer can see their to-do list right on the IDE. If you like to try it for yourself there’s a 30 day free trial available.

Ehm.  TargetProcess comes for free not only as a 30 days trial. It’s free for small agile teams up to 5 people. It’s our humble donation to the growing agile community. Boris, it’s a fully functional free copy with free updates and subscriptions for agile teams of 5.

The “Features” works like an Epic or Theme for your stories and if don’t care for that it can be totally skipped. If you’d like to use it’s possible to determine an estimation and priority for the features but it really doesn’t make much sense to me.

The Features DO work like Epic or Theme and you can rename Features to Epics or Themes or any other name of your choice. The names are completely customizable and it’s up to you which name to choose.

I’d prefer to see something simpler like tags for the stories.

What??? We’ve got tags for user stories and for all the other entities! We’ve got bundles of tags. Tags board. Tags are powerful tools for categorization and filtering, so if I were a certified Scrum Trainer I would have quadruple checked before making such a blunt statement about no tags in any agile tool.

We talk about estimating feature so, of course we can estimate stories also. That’s the first problem i think the tool have, it’s only possible to estimate using time units, ideal or not. That’s no mentions to story points at all, this miss, pushes Target Process to field of time tracking tools, which is not a good thing.

Wrong, wrong, wrong. You missed the point with story points. They’re there, and you can choose between ideal time units and story points. This bold statement of no user story points in TargetProcess pushes you, Boris, to field of shallow reviewers that do not take enough time to study the agile tool they’re reviewing, and then spread this distorted knowledge to their students on Scrum trainings.

Target Process is supposed to work with different agile models, so they use the term iteration instead of sprint.

Foul and a miss. As I already mentioned, one can customize terms and rename the term “iteration” to “sprint” or whatever. TargetProcess is supposed to work with different agile models, so we’ve made our terms and processes completely customizable.

On the Taskboard there’s an awkward choice, there’s only two columns available Open and Done, where’s the WIP ? It’s on another tab Kanban Board, I really don’t understand why they went that way, but it’s no good at all.

Ugh. I really don’t understand how Boris could have overlooked such essential part of TargetProcess as customizable states and processes flow.  Two columns Open and Done on the task board are available for dummies. For advanced reviewers, all the states they want are available. Users can introduce as many states as they need to their development process, and they can give any names to those states. Kanban Board states are customizable as well. It’s no good at all that our honorable reviewer missed this..!

It’s hard to say what I think about Target Process, they had good ideas, like the shortcut flows, but really bad ones like the Kanban Board. Overall the tool is ok but not very intuitive, could be more polished on the user experience, and of course the common problem of too much focus on time tracking hurts a lot.

Boris, I promise you will not be that hurt as you take a closer look at TargetProcess. You seem to have some special inkling with too much focus on time tracking, that’s why you see it where there’s no special focus on it. Time tracking in TargetProcess is just in the right amount, no less, no more. IMHO, it’s rather less of it, than more.  As for user experience - draw the curtain… look in here

Recently I’ve read a very interesting post by Anna Forss called “Stupidity of the Team”.  While Anna concludes, that it’s healthy to introduce diverse opinions and invite opposing minds to dissolve the like-mindedness of homogeneous teams, I think there’s one important nuance that shouldn’t be overlooked.

Let’s think:  teams exist for some purpose. To resolve some goals. If it’s a small product development company - then this team exists to develop a product. Permanent rebels are not welcome in any group - because what they do with their rebels, argues, drawing attention to themselves - they blur the focus of the whole purpose why team exists. Of course, a team will naturally outcast this person.  Next, if a team is bombarded by controversial opinions and judgments, they will spend all their time evaluating and thinking if this is right or wrong. They will get busy sticking tags on new opinions instead of focusing on their work - and they will inevitably lose their focus.

Life in a small development team can be compared to living in a sheltered reality, with it’s particular culture. An isolated sheltered reality will not last for long if it’s completely isolated, so emerging on the surface for a gulp of fresh air is really needed.  As a member of a small team - can you remember when the opposed rebels and opinions really did help? When they triggered something that the team would not have thought by themselves? Well, of course, if someone comes up and says - “your UI is bad” - then another person comes up and says - “your UI is bad” - then you start thinking that it’s indeed something wrong with it. You’ve got this signal from outside world. You work on it. Basically, you know what you should work on. The outsider’s opinion has accomplished it’s task - the outsider’s opinion can now go, because you’re not interested in hearing variations of one and the same opinion.  You get to work, and you work to develop a nice new UI.

There’s no need to focus on outsider’s opinions and pay too much attention to them. Outsider’s opinion is just a trigger to team’s actions - it’s not something that the team should busy their brains with all the time. In a way, diversity of opinions may be even harmful. I guess that’s why we’ve got leaders - authorities who tell the crowd “THIS is your Holy Grail”.

My conclusion is: healthy vaccination with opinions opposing a team’s culture is  good. But don’t overdo with them. Too many opinions will not increase collective intelligence for this team’s specific purpose, they will blur it.

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.

Books by Edward Tufte are a piece of art. I’ve been savoring them to myself for a while, and now I decided to share some sketches and criticism inspired by Tufte’s high art visual designs.

Commonly, designers represent visual information by scarce means of 2D realm: screen and paper. Our universe is 3D (if not 5D, 6D or whatever more dimensions), but people got used to squeezing  images into 2D flatland.  Even rock paintings of pre-historic humans have their touch of 2-D abstraction and symbolism.

Our universe is not just 3D. It’s dynamic 3D. Paper is static (paper planes are exceptions). That’s another limitation of 2D.

Limitations are great. They motivate designers to find solutions. The more limitations - the harder it is to find a solution. Good designers love difficult tasks, since they view them as great opportunities to put their brains to use. Bad designers do not want to use their brains - they want to use templates.

The image below is a template solution for a weather map. View from above.  Let alone template thinking, the representation of this template is poor.

The appalling hint of white shade is a helpless attempt to compensate inadequate color selection for numbers.  What do you think of blue numbers on blue background? You hate that, to say the least of it. What’s the message of these pseudo-3D grey circles? Are they some grey moons? Or cavities  in the designer’s brain?

Now let’s take a look at the Euronews channel weather map.  One may think that this map represents the effects of global warming and Australia is completely hidden under water now. Also, what do those bold numbers show? Probably the depth of the ocean in this area. In meters. Or in miles? But the area is still lit by sunshine, which instills some hope.

As a contrast, here’s a weather map from a Japanese daily, beautiful in its simplicity.  This is the same Japan as on the first weather map above, only from the ocean perspective.  This map provides 0°C и 10°C  isotherms.  You see fine clouds on this map. The map shows sun movement.  OMG, it shows stratosphere! And it’s nothing more than just a weather map from a daily newspaper  - but created by a good visual designer.

Of course, Japan is well-suited for such a nice graphical representation. But you gotta have guts to catch and use this ocean perspective, instead of helplessly surrendering to boilerplate view-from-above weather maps imposed by paper sheet or screen limitations.

Bringing together agile philosophy and software development outsourcing has been one of the hottest topics over the last decade.  Lots of blog posts, discussions in social networks — people try to figure out for themselves if it’s at all possible to align agile methodology with the existing reality of outsourced projects.

How can vendors who practice agile gain new customers? How can customers as newly-converted adepts paste their vision of agile thinking on their existing outsourcing partners?

First of all, let’s look back into when and why actually did it all start with IT outsourcing. Manufacturing outsourcing existed since long ago, but IT offshoring only started at the end of 80’s - beginning of 90’s. Companies jumped at the opportunity to save bucks and use cheap labor not only for producing goods, but for producing software. So, the main point is that from the very beginning outsourcing has all been about saving money. No other notable motivation - just saving money and using cheaper labor.

Next, along comes agile manifesto. People start seeing that the waterfall approach  they’ve been using with their outsourcing vendors is not that good after all.  Fixed price contracts do not guarantee real value (Scott Ambler writes very well on that in this article). Next, the more labor is outsourced to some country, the higher are the costs, so the main point for outsourcing which is cost savings makes no sense any more.

There’re other even deeper-lying consequences. On the one hand, the country which outsources - or businesses in this country not the country itself - they save bucks but lose in the long run as they do not grow their own engineering minds, let alone all the problems that you have working with remote teams - yes, we have all this telecom in place, but nothing ever will replace face-to-face communication. If you often go on business trips to the outsourced destination to talk to your team - again, it’s more costs.  On the other hand, outsourcing makes a dangerous long-term impact on the recipient economies as well.

But the point is not about how bad or good outsourcing is.  Vendors have written an array of blog posts on how to align agile and outsourcing - and that’s natural - they want to keep going, so they do everything to back up their point of view proving that agile goes well with outsourcing. This might work true in some cases.

The companies that outsource on the other hand - they have legacy outsourcing teams. They need to get going with them as well, to stand up to all the funds already invested in their outsourcing center/provider.

So with all this outsourcing in our hands - what do we do?

As an agile outsourcing vendor, you should be ready to invest lots of time and effort to educating your new customers on the value of agile and to building a solid relationship. This might be a very difficult task since some people just don’t want to get educated and prefer to stick to good old fixed price bids, logging and billing for gazillion of change requests, lack of communication and other “joys” of classical outsourced development.

As a company with established outsourcing facility, you’re better off. But perhaps you could be even better off if you started this relationship not with an overseas company, but with a guy next door at least.

Anyway,  you are where you are - so you would need to work with your outsourcing partner to practice the agile approach, since at the end of it all work with agile methodology brings real value, as opposed to counting short-term waterfall pennies and losing long-term gain.

We’re all tied together by things we do. Projects we work on, conferences we go to as a whole team, even bugs we fix together, problems we solve together. Insights we share together.

Some people call it team spirit. Some people call it good collaboration. In any case, this is the light of live communication and talk between people.  My deepest belief after all is that no matter how sophisticated telecom stuff gets our days, there’s nothing more valuable - and ROI-generating as well - as the real talk.

I was perplexed the other day as I saw the phrase  - “we’re trying to maximize our face time with them” - this was said about some guys from an off-site location visiting the main office. My first thought was - so the rest of the time they work  is their a** time? As obviously software guys spend most of their time sitting on their derrier?? Though of course it’s worth a praise that after all they’re still trying to maximize the face time..

As hype is the statement that with globalization you could get the best software developers out of anywhere in the world, as eternal is the truth that to produce people need to REALLY collaborate. This goes for software, for any production.  So it’s not about picking up people as vegetables on the market - even if it’s a huge market. People are more than vegetables. They need live communication to feel alive, to collaborate and to be productive (for those who want to count figures, you can sit down now and compare the monetary value of pure programming skills  - with no communication skills at all).

I’m not saying that we should all go local in our quest for best products and profits. But what I really see is that people are squeezing their way to follow some of agile communication practices using telecom. As a proof, look at hot discussions at LinkedIn agile groups, and Jean Tabaka’s observations on the reasons of agile adoption failure.

Blasphemy to the religion of remote/distributed teams - but the picture is slowly starting to get clear for me:  it really takes good skills to balance the equilibrium of infrastructure and management to activate collaborative agile work in remote teams. Meaning 5 here, 7 there, 6 elsewhere - as one team.

Is it possible to trust without seeing each other? I doubt there’re teams who are absolutely OK with remote customers/product owners etc. I even suspect that waterfall can be the best solution for remote teams-customers that haven’t developed enough trust to each other. If anyone has real-life stories to prove that I’m wrong, speak up.

“Are we agile?”, “How agile are we?”, “Are we more agile than they are?” Honestly, I am getting tired of these questions. Why do you care? Will it make you happier when you are able to tattoo “100% agile” on your body? Is it a goal to be “agile”? Definitely not! All agile tests are just a garbage. All efforts on agile process certifications/assessments are useless.

There are so many factors influencing software development process that make impossible any certification. Your company is special, you have special people in the development team, you have special conditions, rules, and other external factors. CMMI, PMBOK, and other heavy approaches do not help to build legendary team. They only may help to build an average team and eliminate some quite obvious mistakes in the development process.

The right question to ask is: “How can we be more productive as a team?”. It is your project. It is your team. You have goals to improve team productivity (”Done-Done” stories in a period of time), create outstanding software and make customers happy. Agile Tests that answer question “Are we agile?” shift the focus to the wrong direction.

Look, if your team has to pass an Agile “test”, they will focus on passing it. That is a plain dumb goal and a waste of time. Let’s say a manager reads about a famous agile test and sets the goal to pass it. Development team, as a complex adaptive system, adapts to the rules and environment. It will change development process and apply practices to pass the test as effectively as possible. However the team’s productivity may suffer. Why? Simply because the test is too general and can’t be applied to any team. Remember, your team is special.

Let’s take Scrum and famous Nokia test. The first question is “Describe your iterations” and the worst answer to the question is “We do not use iterations”. Well, it is a Scrum test and Scrum insists on having iterations (sprints). But what if your team works more effectively without iterations? What if your team implements “by-feature” using Kanban? What if you have a large project and long iterations are a relief? What if your team holds retrospective meeting and decides to use iteration-less development? Hey, you will fail your “agility” test! Will you be less agile? Why do you care? You will be more productive, that is what you need.

Another example. Third question in Nokia test is “Describe your requirements at the time an iteration starts”. The best answer according to Nokia test is “We have good user stories tied to agile specifications as needed”. What the hell agile specification is? I don’t know such a term. Is it “just enough” documentation? Is it executable specification? Who knows… Maybe your team is fine with just user stories and produces great results. But you will receive less points on the test.

The only good “test” I’ve ever seen is from exceptional Alistair’s book. It contains seven properties of successful Agile development projects. Even in this very broad test some properties may not improve your productivity. So I can’t imagine how it is possible to create general test that will work for all teams/projects/environments/etc. It is as achievable as perpetual motion machine…

Anyway, my point is to focus on real goals and throw away fake goals to pass an agile test, be “100% agile” and “agilier” than the team in a next cubicle.

Here is the very good quote:

From my readings of the literature on Japanese management practice, the focus appears to be on the “hows” and “whats” rather than why something should be done. Although there is some mention of “why”, this appears to be almost incidental. This may be a result of the cohesive nature of Japanese society, the lack of industrial conflict that was endemic in the UK and many other Western countries, or a product of Japanese management thinking.

I do agree. We often fall into a set of practices, tools and “how-to” solutions. We often take Scrum, or XP, or any other process and apply it in hope to solve all the problems. We don’t so often ask “why” indeed. Why we need to change our software development process? It is very important to develop a “need for change” message for your team, your product, your company.

Today David Longstreet posted a comment in our blog with a link to the article with agile criticism. He mentioned that he doesn’t like agile. It is always interesting to check opponents arguments, so I’ve read the article.

I should say that I was really disappointed. The article contains general speculations and almost no concrete comparisons. Common agile principles were disconsidered with strange comparisons and conclusions.

I can’t resist from providing some quotes and my thoughts:

“Agile proponents believe discipline is not necessary and inhibits productivity.”

This only phrase clearly shows how author is incompetent in agile software development. What the hell “discipline is not necessary”? How it relates to Extreme Programming where discipline is a KEY to success XP adoption? Extreme Programming is hard to adopt since it do require high responsibility and discipline to write all that unit tests, do refactoring, do daily meetings, track progress each day. If you’ve tried to release something useful and usable each month you know what kind of discipline it requires.

“Agile proponents believe documentation is an overhead cost and should be reduced or eliminated.”

Documentation should be just enough. Large teams need more docs, while small teams can work almost without documentation. The main goal is to build and deliver working software. Nobody wants working documentation if software is a crap.

In fact, would you turn over 200-300 thousand dollars to have your home constructed using the same principles advocated by Agile or Xetreme programming. The answer of course is no.

What a dull example! What should I do to change color scheme on my web site? Yes, change several css styles. It will take 5 minutes. What should I do to change color of my house? Yes, buy several gallons of paint, take brush and spend next few days on that task. Changes in software are rather easy, changes in constructions are hard.

Look. If the building company may build 1 room, 1 kitchen and 1 bathroom ready for leaving within 1 month and then tell me that I may move into the house right away, I don’t mind! (if they can build and decorate other rooms, cellar, garden, etc. without disturbing me). But building companies do not have such technologies. Software development companies have! That is the difference. The comparison above is pointless.

“Architects actively gather requirements and they study their clients.
On the other hand, software developers passively gather requirements and often don’t have a clue about their customer or their business.”

Such software development companies will die pretty soon. No way. Agile development is all about customers needs and business value delivery.

“Unfortunately the bulk of Agile software methods deal with coding techniques and testing. Those organizations that spend the least amount of time in coding are those organizations with the highest productivity and quality levels. It does not matter what you make if you spend more time testing than you did making something you have a problem. Testing should never be more than 50% of any project. In the future programming will become like welding, carpentry, and plumbing is today. The most prestigious professionals in the construction industry today are architects and the same will be true for software.”

What about SCRUM? What about all these agile principles that focuses on productivity and quality? Unfortunately software industry is not in the phase to create products without coding. Model Driven Architecture (MDA) maybe promising approach, but not mature yet. So we have to code, sorry. What it means? We should optimize coding and increase productivity or invent better approach (like MDA). Why building companies still can’t grow a house from a seed? I want to by a small 200 square metre house in my hypermarket packed in a nice small box!

“The primary reason why it is difficult to apply measurement to software organizations is because software organizations are chaotic. Every single time a development project is done it is done differently. [...] In other words, the entire process is just a mess.”

Similar projects should be done similarly. Different projects SHOULD be done differently. Period. Agile strives for defined process that will evolve and adopt to any project. There is a deep misunderstanding of agile principles and ideas.

I don’t know the reasons why the author wrote the article, but it is unprofessional. It does not show agile disadvantages, but looks like desperate attack on agile positions.