Edge of Chaos | Agile Development Blog

I got this insight on lean and agile techniques in military context when reading  “Ideas Made to Stick” book.  The workflow of the military was described there as an example of how important it is to make messages as concise as possible to accomplish tasks.

The evolution of the military strategy with dates and sources is not a subject of this blog :)
With no extra details, here’s the core of the point I’m trying to make:

First the Army’s approach was to make sure that every single action is planned down to smallest details. But, as they found out, “enemy bears no plans”. An unexpected move could destroy the whole set-up so  “all king’s horses and all king’s men” could not make the Army function again. Effectively, I mean.

So, they reverted to something very similar to agile technique of creating user stories – Commander’s Intent. Commander’s Intent is “the commander’s stated vision which defines the purpose of an operation, the end state with respect to the relationship among the force, the enemy and the terrain; it must enable subordinates to quickly grasp the successful end state and their part in achieving it”.

Do you see the resemblance? It’s a replica of lean production principles, only in military, not in civic, context. And it’s exactly like the agile principle of engaging people and encouraging their creativity to achieve one common goal.

I will not go into quoting sources on the web on Commanders’ Intent and military doctrines to find more analogies and similarities in military setup and lean/agile methodology.  I just outlined the idea.

There’s a misconception related to this topic: Some people think that agile works all OK for lazy folks. It’s all about freedom, about looseness, no obligations. Not at all. Agile is less conventional, it does not care about being in the office at 9 am sharp, or about wearing a tight business suit. But agile projects do have their Commanders’ Intent and they require genuine responsibility and engagement from the team – the soldiers.

Now, as  the Army follows agile principles, would you need any better proof on the effectiveness of agile and lean methodology?

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.

January 13/14 is the Old New Year holiday. Seems like today is the latest appropriate time to look back  and recall the most interesting blog posts by TargetProcess in 2009 :)

Based on visitors count, the posts are ranked as follows (descending order):

1. Lean and Kanban Software Development Digest: In May 2009, this digest came along right on time as Kanban adoption started to grow. We’ve been sifting through the Lean/Kanban buzz and considering if Kanban might be a good tool for our development process, so this post has the most valuable findings we’ve made and shared with agile community.

2. Refactoring vs Rewrite: This post is a real train of thought of a Product Owner trying  to make a decision on how to proceed with product development — rewrite or refactor. Can well be used in textbooks for software product management :)

3. Mind Maps: Scrum, Extreme Programming, Lean: Another by-product of our research on agile development processes. The specific value of mind maps is that they help grasp complex things with visual representations.

4. Tale: Deadline and Technical Debt: Once upon a time…  Who could ever expect that the fundamental principles of product management can be outlined in a fairy tale ? :) There we go:  smart Arthur, the cunning king, quest for princess — the metaphorical expression of the danger of technical debt in software development.

5. 5 Wrong Reasons to Apply Kanban. For some reason (no pun intended), 5 wrong reasons ranked higher than 5 right reasons. Maybe it’s just human psychology — to go from “what’s wrong”  instead of  “what’s right” …

6. How We Use Kanban Board. The Real Example:  Once we figured that Kanban process is just the right thing for us and put it in action, we shared this  experience with our blog readers.

7. 5 Right Reasons to Apply Kanban: There they are :)

8. Zero Defects? Are You Kidding Me? : Can this juicy frog be sure that it swallowed the very last bug? This post is a warning against the so-called “zero defects mentality” in software product management.

9. Simple Rules, Complex Systems and Software Development: Complex systems function at their best when guided by simple rules. Look at ants, birds, space rockets and … software development.

10. BDD and User Story Specification: Examples — This post includes some real user story specs in BDD for TargetProcess product. Enjoy and use.

These are the TOP 10 posts  in 2009 from TargetProcess agile blog (click here for more)

Happy OLD NEW YEAR! :)

New Year time is the time when people give resolutions and are particularly enthusiastic about keeping up to their resolve.

One of TargetProcess resolves for this year (another resolve is our roadmap for 2010) is coming up with more blog posts. We promise to keep up feeding  practical and insightful content!

Since everything around is all about newness at this time, let’s think a little bit of how we approach new tools that we use in our work.  Say, you want an agile project management tool, like TargetProcess, and you’re certain that you know very well how to manage agile projects, so all you need is just a tool that would replicate your model of management.

There you go: you sign up for a trial, you start looking at a tool, you take time to see what and how works in there, you discover that this tool is very customizable, but in some cases the tool does not do things the way you do them.  That’s the point where you can submit a feature request and give up, or that’s the point where you can thoughtfully look at the way you do things and see if probably the tool guides you and allows you do agile project management in some better, more lean, more lightweight way?

Imagine that you have an axe but you’re totally unaware that hammers exist in this world. You’re used to fixing nails to their place with the rear part of your axe, and you have no idea that there’s another tool that allows you to do the same task with the same goal — that is, to put the nails where they should be — but in an easier and more straightforward way.  So, when someone hands you a hammer — you look at it and think — how do I use this thing to fix the nails? This tool doesn’t chop wood at all, it has no blade, no powerful rear part — it’s just a small piece of  iron (remember, you’re a man with no idea about hammers, this might be difficult to imagine :) ) Then someone shows you how to hammer nails. You see that hammer is definitely much better for this task.  A hammer head is well-balanced against its handle and it allows to put nails in place with more control and precision as opposed to a heavy axe head.  Then you understand that this new tool does things in some new way that you haven’t known about before. And you like that new way — you grab the hammer!

Sometimes, however, hammers and axes are mixed into one monster like this one:

axe&hammer

You might choose to go and worship the monster praising its versatility. It’s really a fine line between following guidance of a tool that suggests more practical way of accomplishing your tasks and worshiping functionality of a monster, sacrificing your working process and taking time to learn the tool just for the sake of the tool itself. You do learn something new, but is it worth while to nurture a monster, when you can take hammer for hammering,  axe — for chopping wood, and see if you probably need to add a saw, pliers and drill to your set of tools?

The message is: whenever you need a tool to do whatever you need to do, watch out for monsters eating up your work and effort just to learn how they work.  At the same time be open to looking at things from new, unknown angles and don’t stick to old schemes. Who knows,  maybe the tool you’re trying out right now will help you build your ideal working process.

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.

The concept of deadline has always been one of the sacred cows for any human activity.  Normally, with very few exceptions, what do people do with any project? They set a deadline and think that they will care about meeting this deadline somehow. You can see lots of examples for that in construction industry. Remember, China and the 2008 Olympics. They had a deadline for building Bird’s Nest arena in quite a short period of time. In this case, it was really necessary to meet the deadline since the Olympics was to start on August 8, 2008.

How about software development projects? Product development? With agile methodology?

I think there are 2 options here: agile team does have external pressure for deadline, and the team is free to choose when to release. The main criteria for release is quality as observed in this tweet.

When reading blog posts and articles on lean and kanban (this one for example), I noticed that people are very wary of calling things their names and avoid saying it out loud – DEADLINES ARE CRAP. What matters is the work flow, the quality, the limits of WIP and the Definition of Done. So, if a team has no external pressure, the recommendation is to avoid extra stress by imposing unnecessary deadlines.

There’s no rush for perfection, as they say. But how about external pressure? How about clients who bluntly say — I want this job done yesterday? Frankly, as I worked in outsourcing, I always felt an urge to say to such clients — if you want to have this done yesterday, you should have moved your a** yesterday and select a vendor who you trust yesterday. With custom on-demand projects, clients often fail to understand that meeting a deadline and completing a project on time is the responsibility of both customer and vendor, with customer even more responsible.

So, if you’re with an agile software shop and you have such clients, there are 3 options:

1. educate your clients on deadline concept as above and say bye to them
2. bend over backwards, have stress, and deliver something-not-sure-what on a client’s “yesterday” deadline
3. patiently explain the client that only a part of what they want can be done by their deadline and prioritize work.

The sad thing is that the majority of clients will go elsewhere hoping to “get the job done yesterday”. But if you really are competent, do good work, your reputation will start building up and at the end of it all you’ll get a bunch of devout customers – especially if you work in a local community.