Short Reach 32
I’m always trying to find newer, better, shorter, more powerful ways to explain what Agile is about. I suppose I’m some kind of obsessive about expressive power and economy.
Finally I decided that Agile, as I understand it today, is about the short reach.
It seems to me that all of the agile practices are about shortening our reach, the distance in time-and-space that one leaves an assumption, decision, or line of code untested and unconfirmed. All the practices seem to follow this one rule.
- The customer/analyst is keep in the same room, in the same short reach.
- We feed back the iterations to the customer/analyst so that his every decision has a shorter reach.
- We do iterations to ensure our planning has short reach.
- We keep our teammates very close, in the same room, so that it’s a shorter reach to them.
- The test is written first, so that implementation has shorter feedback on correctness.
- We compile/test frequently because our code time should have a short reach.
- We pair so that our code is instantly vetted through a peer. We don’t pile it up and review it after the tests pass.
- Our planning is based on “yesterday’s weather”, data collected a very short time ago.
- We don’t plan the team structure and the assignments, we self-organize so that tasks are waiting for the shortest time possible.
- We talk face-to-face, not across chat and email and official company documents.
- Tell-dont-ask and the Law of Demeter guide us in keeping the reach of our objects very short.
- We use unit tests to exercise a class directly, and we isolate with mocks to reduce the reach of our tests through the system.
- Shared code ownership means that the guy sitting behind your keyboard has all the permission he needs to do excellent work, even if it impacts existing design.
- Test-first development means that the guy who makes a change knows very quickly whether his change is safe or not. He doesn’t have to wait until the week before integration when the “real” tests are run.
Where does Agile run into logistical or operational difficulties? Wherever a long reach is required or imposed. Where an organization chooses to continue in waterfall-style management, where the team is distributed among managers with appointed “point of contact” and “official channels”, and where the developers are not placed in a common work area agility is very difficult.
I’m not saying that agile techniques can’t work for large companies, but that is an area where a lot of experts are trying (maybe succeeding) to extend the agile techniques and where the average “agilist” finds challenges. When it works, it is almost certain it will be because someone has found a way to shorten the reach of the teams so that all they need to know is never more than a few seconds or minutes away.
At least that’s my half-baked observation of the day. Let me know if I’m wrong here. Or if I’m more right than I think I am.
Very interesting and simplistic observation. I like it! I too like to find good and simple ways to express what agile is all about.
I’ve just finished an article, written toghether with Martin Jul (www.Ative.dk), about the adoption of Agile methods in Denmark and I would have liked to use some of your insight in the conclusion, because it’s so simple that anyone should be able to understand it. And ease of understanding is one of the core principles (even if not defined as such) of Agile Development.
As usual an exciting read – thanks! Jan
Just to make myself clear: I meant simplistic in the positive sense of the word. Maybe “simplistic” isn’t the right word to use, but english is not my native language. Hope I didn’t step on anyones toes :-).
I like this simplistic view, but I fear that it only makes sense to those who have already practiced agile in some part. I wonder if this would seem so powerful and simplistic if I read it two years ago without any real understanding of agile.
I only point this out since your initial thought was explaining what agile is about.
So… this might work as a explanation for a team that is struggling through adoption and is questioning if they made the right decision… but I don’t think it helps sell agile to someone who needs it but doesn’t understand why.
Yeah, that’s a good catch. It’s a great thing to say to the converted, but to the outsider it doesn’t mean as much. On the other hand, maybe it can help me to structure the argument about why a short reach is better than a long reach, and how it helps me to work more certainly than a big, long guess.
It’s not enough to stop, but maybe it will at least help when playing the “two things” game.
Your last observation, that it might be good for a team that is struggling, might be the most useful thing on this page.
I’ve been reading about “Getting Things Done” and there seems to be a connection there. You close any ‘open loops’ so that you know what the ‘next action’ is. You act immediately on anything that will take less than 2 minutes. You don’t particularly prioritise unless a context demands it. But it is effective in keeping things moving. It also keeps you honest and not overwhelmed.
I think the emphasis on tests is like asking ‘what is my next action?’, both for developer tests and customer tests. It gives me a sense of calm confidence.
I love you consciese and clear answer to the “Why Agile?” question. Here are a number of additional arguments I’m using in my presentations about Agile:
1. When talking about Business Application development the worst thing that could happen to a software vendor is to deliver a technically perfect system, which nobody needs. Sometimes such systems could be even harmful for the would be automated business process.
2. The computarization era of existing mature busness processes is over. Now we a building new systems, which do not exist yet and nobody have a clue what they should be. I’m comming from the digital TV industry and it’s very and sometimes painfully clear that requirements in the normal sense just do not exist anymore.
The only effective remedy known today for the two problems mentioned above is a short feedback loop. For that the Agile approach is unsurpassible.
On the other hand we do not have any proven record of effective application of full agile (not some practices, but the whole process) for system software development. We are not aware about operating systems, databases, middleware or compilers developed this way. Some interpreter based systems (Smalltalk, Ruby On Rails) were and are developed in an incremental way, but I still doubt if anybody would claim them to be classical XP or SCRUM cases. “Know which software are you developing and adjuts your process accordingly” seems to be a useful guideline.
This notion of “short reach” rings a particular bell with me: the idea from lean about reducing cycle-time through “single-piece flow”, namely that when we start doing something we finish it completely.
From a lean perspective what you are describing is that for a feature in our backlog we look at the “value stream map” – the different steps to implement it. This is called the present state. Then “short reach” is all about optimizing the process.
If we have a lot of “waste” (the lean definition for the opposite of “short reach”) we will see that the feature gets stuck – it is blocked from completion by waiting for the customer to clarify the requirements, for walking to another building to talk to the database team, waiting for testing to check it (for the lack of up-front testing), waiting for the developer to remove the bugs found (the waste of defects) etc.
This is the present situation. Following lean tradition we now draw a “future value stream map” where we rearrange the steps that add value into a sequence where a feature can go from started to completed without any unnecessary delays. We also remove all the steps that add no value (for example, if we put the customer and the development team in the same room we take out a lot of the need for bureaucracy, if we fix bugs when we find them we don’t need complicated bug tracking systems and change procedures etc.)
So from this perspective your list of “short reach” items are a set of refactoring patterns from getting from a bad “present state value stream map” for a poor/waterfall software development process to a much improved agile process.
If you want to dive into the details the definitive authority on for lean software development is the Poppendiecks. They were here in Copenhagen earlier this week
I’ve also blogged about lean on our blog, Ative at Work if you want my take on lean and its relation to software development.
If you want to dive into the details the definitive authority on for lean software development is the Poppendiecks. They were here in Copenhagen.
So from this perspective your list of “short reach” items are a set of refactoring patterns from getting from a bad “present state value stream map” for a poor/waterfall software development process to a much improved agile process.
Thank you for your submit. I practically passed your post up in Bing but now I?¡¥m glad I decided to quit and obtained to browse via it. I?¡¥m certainly more informed now. I?¡¥ll share yours with some other guys I understand. LOL.
very good. Thanks
Okey oynamak hiç bu kadar zevkli olmadi. Online ve 3 boyutlu okey oyunu oyna ve turnuvalara sende katil.
This comment has been flagged for moderator approval.
Hi, I found your post really helpful. Thanks for posting such informative content. Keep posting.
You have a very nice and motivating posting style, it makes me read your articles with great interest.
posting style, it makes me read your articles with great interest.beats by dr dre beats by dre sale
Don’t climb up mountains, do not know the day; No, and I don’t know of the valley to thick; Don’t slap him learn, do not know to his ignorance.
Thank you for posting. Waiting for updating. Discount brand Men sport suits from China at on line store
thanks for share with us
Excellent post. I merely came across your site and wished to say that I have really loved reading through your blog posts. Any ways I’ll be subscribing for your feed and I hope you post again soon.
austin bible church
This girl is really good looking but nasty. However, she has some talents. That’s why people still love her.
Corporations are challenging existing business models as they seek ways to speed innovation, focus on their core competencies, and scale to capitalize on opportunities and outpace competitors.
Vielen Dank für den Austausch dieses Wissens. Hervorragend geschrieben Artikel, wenn nur alle Blogger angeboten das gleiche Gehalt wie Sie w?re das Internet ist ein viel besserer Ort. chanelLedertasche chanelGeldboerse
. I had really impressed with this blog and the great technology is visible in this website. Thanks a lot for providing the amazing articles are display in this blog. Interesting info is visible in this blog Program Coordinator Job Description|Hospital Administrator Job Description|Cook Job Description|Registered Nurse Job Description
Here can be recognised
I have searching for information and finally this blog is very good and the nice designed.
really great post i think that this is a nice way to work.
The public may not have known what the messages meant, but it helped pay for them. The skywriting stunt was supported by city and state public funding, according to the High Line’s website. MTS Convertitore MTS Convertitore Mac
This site has providing the lot of valuable info is visible in this blog and the new things are display in this blog. Thanks a lot for providing the number of posts are display in this blog.
Slewing ring is also called slewing bearing, some people called: rotary support, swing support. English Name: slewing bearing or slewing ring bearing or turn table bearing, slewing ring in the real industrial applications is very wide.
the new things are display in this blog. Thanks a lot for providing the number of posts are display in this
Excellent site, keep up the good work my colleagues would love this. The information of your site is precisely excellent, and your blog design is Simple good.
Well. Though I am not a good application developer. And I need do more hard work to improve myself. When I come to here. I know that I have come to the right place to learn something I need. Thanks for your good advice. And I will do the practice as possible as I can. Thanks.