Monday, November 12, 2012

Monday, November 5, 2012

Monday, October 29, 2012

About Corporate Wallpapers

Recently at work, they imposed a new domain-policy to force a corporate wallpaper (background) for everyone's workstation (desktop). I haven't noticed  it until my password expired and I ended up doing a reboot, when all new policies were applied by the log-on script. After this, my wallpaper was changed to a corporate image (the most recent advertising campaign); of course I was immediately upset.

After calming down myself, I began to wonder why they do this? Later I discovered that some days before the company sent an official email memo explaining the whole thing. They said that the wallpaper will be changed automatically whenever a new advertising campaign gets released.


Not totally bad

I must admit that this kind of policy is understandable when you have your staff visiting clients and vice versa. 

If you'll be in direct contact with clients your workstation (Desktop or Laptop), becomes a reflect of the corporate image (as well as your dress and physical aspect). 


But...

But why you should apply that kind of policies to all your staff?

For me, and almost the 90% of my co-workers, this is a nonsense because we never get in touch with our clients (the end users of the applications we work on). We have some internal clients (administrative staff), but they are just another employee; the difference is that they belong to the business people. Even more, we usually show our work in a test server and all applications are web-based. So nobody is looking at my desktop background in the 99.99% of the time. Then, Why to force a corporate wallpaper?

My only guess is that employees are so poorly identified with the company values and campaigns; that they must force us to look every piece of advertising to change our mind. In contrast, I've seen some  employees, from other organizations, changing not only their desktop background with the  company's latest promotion, but also their phone's screens have the same the same background.


Instead of

Instead of that sort of manipulation, I think that companies must always pursuit a sincere motivation on their collaborators. That way they'll become brand-evangelists in a volunteer manner; and there is no better salesman that the one who, truly, believes on the product.


Samples

I did some Google-based research, and found one example of each point of view: the ones who are in favor of "Corporate Wallpaper"-like policies and the ones who don't. You can tell, by their title, which is which:
There seams to be a strong interest for system administrators to enforce Corporate Wallpapers. Take a look at this stats from search results:
  • "How to force a corporate wallpaper": About 75,000,000 results (0.34 seconds)
  • "corporate wallpaper policy": About 11,000,000 results (0.33 seconds)

From the top 10 results of the first search I want to highlight a "winner":
"One of the things that is unique to us is the fact that we change our desktop wallpaper across all computers as needed.  Unfortunately, ... users change their own wallpaper to something else ...  Once the users change this to something else, we were unable to force the windows wallpapers to change on the computers. 
Not until I did a bit more digging and research.  Now, ..., we force it to do so based upon a login script." (from How to Force Windows Wallpapers to Change)
People responsible for applying that kind of policies seem to be very proud of it; but no one is looking at the psychological effects of those decisions.

Phrase of the Software Craftsman 006


"Code should be composed in such a form as to make it readable by humans."

Sunday, October 28, 2012

Tips when changing job

For most people, changing a job is a matter of money or power. You move if the new company offers you an attractive compensation package. Or, you move if you are just a worker and there you will be managing / leading others. Also you have others that look for the state of the art tools and methods; they will move to a new job if they find that there are using the new stuff. In summary we have three buckets; one big for the ones looking for money, another for the ones looking for power, and the last one for those state of the art addicts.

As you mature on your career, and life, you start to value some others aspects. Suddenly the money pass to a second place. Also, if you are good on what you do, there is no need to be a manager or leader in order to increase your incomes. You start looking at your company management philosophy, things contributed by your team (to you) and vice versa, turnover ratio, physical aspects of your work-space among others. All those variables lead to the fundamental question: Is this a good place, for me, to work?


What is a good place to work?

  • How flat is their structure? Typical employee to manager ratio, for our industry  is between 8:1 and 10:1 (one manager every 8 to 10 workers). But when I talk about a flat structure, I'm not looking at the first level managers ratio. Is about how tall is the chain from them and up. The more levels in the management chain, the more bureaucracy you'll have. Also the company ability to conform organic teams is very important. Imagine that you start working in a new project involving 3 or 4 groups (and of course their leaders); this can put you in a cross fire coming from each manager try to control or imposes his ideas. A really organic team, must not suffer for those political issues; and if so that is an indication of how immature are those managers.
  • Team's social interactions: A very simple, but accurate, gauge of the company's people-oriented traits is the social interactions among team members. The more informal interactions (celebrations, meetings, chats, parties, events, etc.) you notice in a team, the more good is that company in keeping people happy. Of course, you could find a very united team inside a non people-oriented company, but those are the exception. Usually when people are unhappy, they tend to use their free time to be as far as possible from the job (and coworkers).
  • Turnover ratio (1): High turnover rates creates an inexperienced work-force, this leads to more mistakes and low quality products. Also a constant and high turnover creates the perception that the company is always about to sink; and nobody wants to wait until the last moment over the Titanic, right. More about the importance of measuring the employee turnover here.
  • Career path: Low turnover is associated (not only), to a career path policy. If the company has a well established training program, employees don't try to go away so often. Also a career path program indicates that the company is concerned about your growth. Its main focus is not on taking advantage of your knowledge, and later replacing you as a depleted resource (BTW, Do you like the term "Human Resource(s)"? I like better "People" or "Staff"). 
  • Size matters: How big will be your monitor? (Couldn't say it better than here). How fast will be your new workstation? How many GB will you have? You have to pay very close attention to the resources the company allocates on workstations, for their workers to feel comfortable. These details are an indicator of how much the company cares about the people. If they prefer to save a few bucks and put people to work on low-performance PCs, and small monitors, that company don't deserve your collaboration.
  • Other environmental issues: 
    • Respect for the Intimacy Gradient (2) (pattern #127, from A Pattern Language: Towns, Buildings, Construction. [Oxford University Press, 1977]). You need to have place(s) to work alone, in small groups, in big groups and also public (social) areas. All these different intimacy levels, must be located in a way that no group or persons interrupt others. One key indicator that a company does not respect the Intimacy Gradient, is the factory-like disposition where all desks are places in a grid with just little, or none, division. With such a disposition you can not work alone (because of the surrounding noise). Group work just causes more noise. This point, naturally, connects with the next one ... 
    • Noise level: what is the average noise level on your future work-area? This is a very subjective aspect, but is well know that we, brain workers, can't do a decent work without the proper concentration. Noises affect directly your capacity to concentrate. 

Summary

Next time that you start looking for a new place to work, take all the previous variables into consideration. Ask for a visit to their installations. Find, at least, one person inside that you know; and another that you don't know; have an informal chat with them about the company. Later compare their versions.

Ask your future manager / leader what are the training policies of his organization (if any). Ask if he has the turnover rates for the last 6 month. Try to gather as much information as you can about your future team social interactions. Finally, with all that information in place, take your decision.

Please note: With all this, I'm not saying that money, new tools and technology are not important. They are, as well. But we tend to forget about the mentioned topics, and just focus on our new salary and that  new toy we will be playing with.



(1) Turn Over Ratio: A simplified formula to calculate the turnover rate is: for any time period get (I) Avg employees and (II) How many people left the company; then divide II by I and multiply by 100.

(2) Pattern #127 - Intimacy Gradient:
Conflict: Unless the spaces in a building are arranged in a sequence which corresponds to their degrees of privateness, the visits made by strangers, friends, guests, clients, family, will always be a little awkward.
Resolution: Lay out the spaces of a building so that they create a sequence which begins with the entrance and the most public parts of the building, then leads into the slightly more private areas, and finally to the most private domains.

Wednesday, October 24, 2012

Coding Dojo @DR 003

Below you'll find all details of the Coding Dojo @DR 003 meeting. Please comment on this post with your opinion or concern on any topic. 

This time we'll be practicing with a Kake format (see Little Coding Dojo Intro for a details on each format). We have an open discussion on Google Moderator (http://goo.gl/wKgwu) to select the Kata to be used. Please go to that URL and vote up for your favorite problem(s). We need at least one PC (laptop) on each team, so bring yours; it might be needed.

Newbies, please check the following references before the next meeting:

I  -Event URL:  http://goo.gl/dkNdT

II -Katas Pool
Go to Google Moderator series http://goo.gl/wKgwu, select your favorite problem(s) or add new ones. We'll pick the one(s) with more votes.

III-Expected attendees: 15 to 20

IV -Expected duration: 3:00 hrs. (3 hours)

V  -Agenda
  1. Inform next session date: 1 minutes
  2. Share moderator link to decide on a Topic for next session:  1 minute
  3. Form groups (3 to 5 members each): 8 minutes
  4. Kake Work (Code!): 120 minutes
  5. Each group shows their solution: 16 - 32 minutes (up to 8 minutes each)
  6. Retrospective. What went well? What was interesting? What was frustrating?: 15 minutes


This section will be filled after the event.

VI  -Next event URL: http://goo.gl/BRDR4

VII -Next event date: Tue, Nov 13, 6:30 PM - 9:30 PM

VIII-Actual attendees: 12

IX  -Actual duration: 3:00 hrs.

X   -Worked Katas:
SQL string generator

XI  -Retrospective 

What was frustrating?

  • This time nothing but the poor level of detail of the selected Kata for some of the attendees. 
What went well?
  • Everyone feels this format (Kake) was more fun than others.
  • All groups work, with different levels of detail, the problem and achieve a solution with its set of tests.
What was interesting?
  • We "taste" a little of new languages.
  • We saw different approaches of solving the problems maid possible by using different tools.
Next meeting agreements:
  • We will be rotating the 3 formats (Prepared - Randori - Kake).
  • The next format is Prepared
  • 3 of us must prepared a Kata (one each). Actually we have 4 candidates +Daniel Paniagua, +Eduardo Burgos, +Rafael George, and +I
  • Each prepared Kata will last from 30 to 45 minutes.

XII -Action Points
  • Confirm availability of the presenters.
  • Confirm Kata's themes and duration.

Monday, October 15, 2012

Phrase of the Software Craftsman 004


"Before you start refactoring, check that you have a solid suite of tests. These tests must be self-checking."

Wednesday, October 10, 2012

Coding Dojo @DR 002

Below you'll find all details of the Coding Dojo @DR 002 meeting. Please comment on this post with your opinion or concern on any topic. If you haven't read this post, please read it to gain a better understanding about this event.

For this second meeting, I want to emphasize points 3 and 4  of the Agenda. First we need to give a solid an clear introduction to the Coding Dojo Topic (meeting formats, objectives, and rules). Also is  almost mandatory for everyone to understand the TDD cycle and to see, in practice, a solution build using TDD. On the last meeting we noticed that people were unaware of the meeting format and objectives, although several references were given. So, if this is your first meeting; or you have not read the following references, please do it before the next meeting:


I  -Event URL:  http://goo.gl/ykQWe

II -Katas Pool
We must select (see point 5 of Agenda), one or more Katas to practice on each Dojo session. The following list is an extract of some easy Katas, please review each one to be informed when making your decision. You'll find more Katas at this blog Code Kata's Page.

III-Expected attendees: 15

IV -Expected duration: 3:00 hrs. (3 hours)

V  -Agenda
  1. Decide on date for next session: 5 minutes
  2. Decide on a Topic for next session: Just TDD (0 minutes)
  3. Coding Dojo and TDD introduction: 15 minutes
  4. Code! PreparedKata by Lorenzo Solano (Roman Numerals): 30 minutes
  5. Pick a / some Kata(s) for this session: 10 minutes
  6. Code! RandoriKata: 45 minutes
  7. Mid-session break to discuss how things are going: 10 minutes
  8. Code some more: 45 minutes
  9. Retrospective. What went well? What was interesting? What was frustrating?: 20 minutes


This section will be filled after the event.

VI  -Next event URL: http://goo.gl/2iOTD

VII -Next event date: Tue Oct 30

VIII-Actual attendees: 11

IX  -Actual duration: 3:00 hrs.

X   -Worked Katas:
Roman Numerals (prepared), and Word-wrapping (randori).

XI  -Retrospective 

What was frustrating?

  • Low focus on the problem at hand, participants were talking during the hole meeting about other topics.
  • Too much noise.
  • Some of the attendees were not on time.
  • Some people think that we need more "real" problems. By real they mean problems more like the ones we faced every day at work. Also they mention less-algorithmic problems.
  • Definitely, we need and external keyboard and mouse.
  • Allocate enough time for each problem, so we don't have stop and unfinished solution. 
  • Plan to have a meal.
What went well?
  • In general this meeting was, by far, more organized than the previous one.
  • We cover all points in the agenda.
What was interesting?
  • Was interesting to new ones.
  • We have knowledge sharing.
Next meeting agreements:

  • We'll have a Kake format.

XII -Action Points

  • In the future, we won't put more than one meeting format for a dojo session, to ensure that we have the time needed to work on problems.
  • For the next meeting, we need to define an "expert" on each programming language to be used on the Kake meeting. 

Monday, October 8, 2012

Phrase of the Software Craftsman 003

"[...] spending time keeping your code clean is not just cost effective; it's a matter of professional survival." 

Wednesday, October 3, 2012

Agile Atlas


Agile Atlas (see the About Page)

If you are new to Agile, and related methodologies like Scrum, here is an online "Atlas" or Dictionary about all those topics. Below is an extract from the About section explaining, in summary, the site's purpose.
The long-range purpose of this site is to provide an “encyclopedia” of information about Agile and related methods. Although the site is presently supported only by the Scrum Alliance, it is not intended to be a Scrum-only site in any way.

You'll also find valuable articles (@ http://agileatlas.org/articles) related to Agile and Scrum, like this one:
Scrum - a Bird’s-Eye View: A quick overview of Scrum - Agile Project Management

Enjoy It! 

Monday, October 1, 2012

Coding Dojo @DR 001

Below you'll find all details of the first Coding Dojo @DR meeting. Please comment on this post with your opinion or concern on any topic. If you haven't read this post, please read it to gain a better understanding about this event.

I  -Event URL:  Kodisto Dojo @Google+

II -Katas Pool
We must select (see point 5 of Agenda), one or more Katas to practice on each Dojo session. The following list is an extract of some easy Katas, please review each one to be informed when making your decision. You'll find more Katas at this blog Code Kata's Page.

III-Expected attendees: 21

IV -Expected duration: 3:25 hrs. (3 hours and 25 minutes)

V  -Agenda
  1. Decide on date for next session: 5 minutes
  2. Decide on a Topic for next session: Just TDD (0 minutes)
  3. Coding Dojo and TDD introduction: 20 minutes
  4. Code! PreparedKata by Rafael George (String Calculator): 30 minutes
  5. Pick a / some Kata(s) for this session: 10 minutes
  6. Code! RandoriKata: 40 minutes
  7. Mid-session break to discuss how things are going: 10 minutes
  8. Code some more: 70 minutes
  9. Retrospective. What went well? What was interesting? What was frustrating?: 20 minutes


This section will be filled after the event.

VI  -Next event URL: http://goo.gl/vQ5Xk

VII -Next event date: Thu Oct 18 2012

VIII-Actual attendees: 11 (from 22 confirmed; No-Show 11)

IX  -Actual duration: 4:00

X   -Worked Katas:
Just String Calculator, see retrospective to know why.

XI  -Retrospective (If I forgot something, please comment to let the point registered)

What was frustrating?

  • Use a moderator: Discussions took to long, and some of then were pointless. Also we try to talk all at the same time.  
  • Respect the Prepared Kata format: We should be listening and looking at the techniques (TDD) presented with the prepared and respect the point of view of the person doing it. If someone does not understand a given step, the expositor must explain it; but that does not imply that both, the expositor and the attendee, must agree on the actual decision. The requirement is "not to move forward if someone does not understand the last step".
  • Respect the Agenda: no one respected the agenda, we end-up by working just on one point of it.
  • Respect the meeting schedule: only 4 (of 11 participants) arrived at the expected time.

What went well?

  • Everyone stick to the usage of the technique (TDD) moving the focus away from resolving the actual programming challenge. 
  • We cover all Test Scenarios of the problem.
  • We add more Test Scenarios to the solution.

What was interesting?

  • When is OK to stop the Refactoring step (of Red-Green-Refactor / RGR cycle)? or Is OK to do Early Refactoring?
  • It's OK to put a little of "sugar" on the syntax of the produced code (by using more readable names or by encapsulating standard's API calls with private methods), in order to increase the legibility of the code?
    • Those in favor defend the legibility to decrease the maintenance cost, and to increase the  code understanding.
    • Those against say that the average developer must understand the code. And also that if we add too many methods we'll end-up with a large call-stack, making it harder when debugging.
  • It's OK, or not, to do early optimizations?
  • When to add more test scenarios? 
    • Most attendees agreed that we must complete the original requirements first, and then add more scenarios to shield our code. 

Next meeting agreements:
  1. Next meeting subject: TDD
  2. Next meeting language: Java
  3. Next meeting format: Randori
  4. Place: <TBD>. Go to the Google's Event for more details.
  5. Other programming languages options: C#, Ruby, and Python. Withing the attendees were at least one person with enough experience using each language.

XII -Action Points
  1. Modify the next agenda to include an introduction to the Technique to be used (TDD, BDD, etc...)
  2. Modify the next agenda to include an explanation of the type of meeting we'll have.
  3. Include an early step to read the agenda to participants so everyone is on the same page and  respect it.
  4. Upload the code of the Kata to a public location (github, bitbucket or similar), so everyone can review it.
  5. Test the video recording software before starting with the Kata to ensure it's working as expected.

Phrase of the Software Craftsman 002

"Refactoring changes the programs in small steps. If you make a mistake, it is easy to find the bug."
-Martin Fowler (Refactoring)

Sunday, September 30, 2012

Kata Diphthong and Hiatus

Advice for all Katas: 

  • Try not to read ahead.
  • Do one task at a time (the trick is to learn to work incrementally).
  • Always use TDD if the Kata is suitable for.

Diphthong and Hiatus

For this Kata try different approaches:  regular expressions, word position traversing, brute force (dictionaries and alike), etc.

Base data and Definitions

Please note that all rules and definitions conform to the Spanish language's rules for Diphthongs and Hiatuses.

This is the classification of vowels in Spanish:
  • Strong (open): a, e, o
  • Weak (close): i, u
The following files contain a listing of words containing different types of Diphthongs and Hiatuses:
The above files will be referred from DF-1 to DF-4 (Data File One to Data File Four).


A Diphthong: Refers to two adjacent vowel sounds occurring within the same syllable. 
E1: Create a DiphthongFinder class with a method boolean analyseWord(string word); use the DF-1 to test your code. If you pass the word "caotico" and "aurora" it must output true.

Diphthong classes: 
  • Two different vowels of the same type (refer to this type as homogeneous)
  • One weak (close) vowel and one open (strong) vowel (refer to this type as heterogeneous)
    • Falling: Strong first Weak second
    • Raising: Weak first Strong second
E2: Modify your code to distinguish between Homogeneous and Heterogeneous diphthongs; extract words from DF-1, DF-2, and DF-3 to conform your test cases. If you pass the words "triunfo" and "coagular" it must output Homogeneous. If you pass the word "hielo"  it must output Heterogeneous.
E3: Modify your code to distinguish between Heterogeneous diphthongs (Falling and Raising); extract words from DF-1DF-2, and DF-3 to conform your test cases. If you pass the word "harapiento" it must output Raising. If you pass the word "país" it must output Falling.

Extended Definition and the Acute Accent ( ´ )

A Diphthong: Refers to two adjacent vowel sounds occurring within the same syllable, one vowel must be weak (close), no matter their order; if and only if, the weak (close) does not have the acute accent ( ´ ). 

An Homogeneous Diphthong must be composed only of weak (close) vowels.
E4: Now the DiphthongFinder.analyseWord(string word) must indicate that the word "caotico" is not a Diphthong (because 'a' and 'o' are both Strong or Open).  The word "aurora" is a truly Diphthong but not and Homogeneous one. The word "triunfo" is an Homogeneous Diphthong because it has two weak vowels. 
E5: Now if you pass the word "país" instead of returning Falling, it must indicates that this word is not a Diphthong because the weak vowel (i) has the acute (í), becoming a strong one; so we have two strong vowels.
Hiatus: Any word containing two consecutive vowels, but that can't be considered a Diphthong is an Hiatus. In other words: any word with two consecutive strong vowels, or an strong vowel with a weak one with an acute accent is an Hiatus. According to the RAE (Real Academia Española), two adjacent strong vowels do not conform a Diphthong as they are part of two different syllable.
E6: Extend your code to also identify Hiatuses. Pick words from DF-4 to add more tests.


Do you want some more?
Consider the following observations, later change your code to support the new specifications:
  • As the "h" in-between vowels does not produce sound, it does not block Diphthongs formation. The word "ahilar" is an example.
  • In Spanish, the "y" at the end of a word has the same sound as the "i", so it can conform Diphthongs. The words "hoy" and "muy" are two examples. However  the "y" at the beginning or middle of a word remains as a consonant and can't conform a Diphthong.
  • An Hiatus Simple is one formed of two different strong vowels.
  • An Accentual Hiatus is one formed of one strong vowel and one weak, but accented, one.

Thursday, September 27, 2012

Phrase of the Software Craftsman 001

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
-Martin Fowler (Refactoring)

Tuesday, September 11, 2012

Coding Dojo @DR, Gathering

"Raising The Bar"
If you reach this post without any prior knowledge about Coding Dojos, please refer to this entry; then come back here.

Proposal

Short and sweet:
     To start a series of Coding Dojos here in DR.

Please note the word series, I'm not talking about a one time event. I'm taking of a recurrent event (or events) for us to practice our craft, to learn from others, to teach others, to have a playground where we can try new things or concepts. In summary, to Raise The Bar.

My proposal is to have a Coding Dojo event every two (2) month, the first weekend of the corresponding month; specifically on Saturday Morning. If this gathering gets enough attention, then we could start on Sat Oct 06, 2012. As the maximum expected duration for any coding dojo session is of about 3 hrs., my suggestion is to start at 9:30 am, that way if we reach the three hours limit we'll be ending by 12:30 p.m.

Types of Katas for each meeting

As RandoriKatas are more "fun" and collaborative than PreparedKatas, I propouse to have a cycle of 1 PreparedKata every 2 RandoriKatas: Randori - Randori - Prepared - Randori - Randori - ...; but this is just a suggestion.

What we need?

First and more important, we'll need people. Coding Dojo, and all Agile practices characterize for being a collaborative effort. So we need you to join and participate. If you are interested, add a comment to this post, or send me an email. If you are offering one or more of the necessary resources (see next paragraph), please indicate that too.

Second, we'll need resources: some PCs / laptops, a digital projector, a meeting room. Its very easy to find some, 2 or 3, decent computers; the projector is a similar effort, but the showstopper here is the meeting room. We need a room with enough space for 8 to 10 people, with an air conditioner or a good ventilation system. So anyone with the means to get one please add a comment with the details. Finally, a must for that place is to have an UPS or backup generator.

Why?

As the Manifesto for Software Craftsmanship states, Software Craftsmen (us), must come to value:

Not only working software,
     but also well-crafted software
    Not only responding to change,
         but also steadily adding value
      Not only individuals and interactions,
           but also a community of professionals

        Not only customer collaboration,
             but also productive partnerships

        But what is the meaning of each practice? Lets review each one...

        Well-crafted software

        • It is the same as Compact, Elegant and Clean Code
        • It requires the usage of Design Patters
        • It has Comprehensive Automated Tests

        Steadily adding value

        • We must achieve an Emergent Design
        • We must, continuously, Refactor our code
        • We must have a Comprehensive Automated Test suite, and more important we must Respect it

        A community of professionals

        • We must learn from each other
        • We must teach to each other
        • We must have respect and trust

        Productive partnerships

        • We and our clients must have trust, understanding and mutual goals
        • We must enhance the communication process with executable specifications

        So, this is a call for you to take the responsibility of your craftsmanship and start practicing all required skills.

        Monday, September 10, 2012

        What is Coding Dojo


        This is just a quick reference of what is a Coding Dojo; to go deeper please refer to this source.

        Definition

        A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in Deliberate Practice in order to improve their skills.

        Premises


        • Acquiring coding skills should be a continuous process

        Characteristics


        • Non-competitive, collaborative, fun environment
        • All skill levels are welcome
        • Safe to try new ideas

        Requirements


        • Meeting room with enough seats (typical attendance varies between 5 and 20 ?)
        • At least one PC or laptop
        • A digital projector ('beamer')

        Total event duration

        From 2hrs 30mins to 3hrs.

        Who started the movement? 

        Dave Thomas, here you have two valuable resources:


        Sunday, September 9, 2012

        Bad Communication Habits (2 / 3)

        2. Inverted channels priorities

        Background

        I've seen many teammates taking to each other using an inverted priority for the following channels:
        • Phone
        • [Direct] Conversation
        • Emails or other text-based channels
        Any time a person is involved within a negotiation (requirements, specifications, bugs reports, ...); that person will prefer to talk all others involved with the most formal channel in order to protect herself and document all agreements.

        So they, try to send all details first in a written form (email or similar); if that does not help they try with a phone call, usually a conference call for others to listen and be witnesses. Finally, if that does not help; they try with a direct conversation or meeting.
        image/svg+xml email phone conversation

        This approach is not effective for two things
        1. The main focus, the intention behind, is to cover all possible future problems resulting from misunderstandings. The intention is to have (collect), evidences for future blame.
        2. We always get better results, in terms of time and quality, with personal interactions than with any other communication channel.

        Managing this problem

        To manage this problem, we can use some practices:
        • Always honor your promises: if you talk, face to face, with anyone and agree upon something; but later you do not honor your word that person won't trust you in the future. This situation will lead your teammates to collect evidences any time they need your help with something; so they can blame your later when you fail.
        • Prefer, always, the inverse order (conversation, phone, email): if possible try to start any interaction first in person; then by phone and using emails if no other channels were available. If you constantly do this your teammates will start to change their style (at least when interacting with you). Remember to observe the first practice.
        • Structure your interactions: if you start requesting to everybody that they should meet with you personally, some people can argue that you are just too far away and that they prefer to call or email you. Also, they can argue that this approach consumes too much time. The answer to these reactions is to schedule your interactions. If you constantly receive request for changes, manage to have a meeting every X day of your release cycle.

        If you can follow these 3 practices, you'll have better agreements; you'll increase the confidence of your teammates (about you); and finally, you'll invest less time in interactions that do not lead to an easy understanding.

        Today's mood I


        Random thoughts, resources and information that I think are useful in one way or another ...


        Story of Stuff

        EN (Original) http://youtu.be/9GorqroigqM
        ES http://youtu.be/mUMESPBJlQo


        Story of [Bottled] Water

        EN (Original) http://youtu.be/Se12y9hSOM0
        ES http://youtu.be/9ICFp-7RgS4


        Where Good Ideas Come From

        EN (Original) http://youtu.be/NugRZGDbPFU
        EN (ES subs) http://youtu.be/o_QTFPdnrjY




        Born to Learn

        EN (Original) http://youtu.be/falHoOEUFz0
        ES http://youtu.be/I8hKSzv_rRw



        Monday, September 3, 2012

        Effective Practices for Applying Agile: Key points


        Almost two months ago (July 2012), the GAO published a report called: "Effective Practices and Federal Challenges in Applying Agile Methods". Where they list 32 Agile Adoption best practices identified by evaluating the agile implementation on several organizations. In this post I want to highlight several Key-Points found within the report. 

        Motivation

        Why GAO Did This Study
        Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011. However, long-standing congressional interest has contributed to the identification of numerous examples of lengthy IT projects that incurred cost overruns and schedule delays while contributing little to mission-related outcomes. To reduce the risk of such problems, the Office of Management and Budget (OMB) recommends modular software delivery consistent with an approach known as Agile, which calls for producing software in small, short increments. Recently, several agencies have applied Agile practices to their software projects.  

        Recommendations

        Because your time is valuable, here you have the GAO's recommendations, after that I'll talk about some key points to be noticed on this report.
        What GAO Recommends
        GAO is recommending that the Federal CIO Council, working with its chair, OMB’s Deputy Director for Management, include practices such as those discussed in this report in the Council’s ongoing effort to promote modular development.

        Modular [Software] Development equals Agile Software Development within this context.


        10 key practices, found in all (5) federal agencies evaluated


        1. Start with Agile guidance and an Agile adoption strategy.
        2. Enhance migration to Agile concepts using Agile terms, such as user stories (used to convey requirements), and Agile examples, such as demonstrating how to write a user story.
        3. Continuously improve Agile adoption at both the project level and organization level.
        4. Seek to identify and address impediments at the organization and project levels.
        5. Obtain stakeholder/customer feedback frequently.
        6. Empower small, cross-functional teams.
        7. Include requirements related to security and progress monitoring in your queue of unfinished work (the backlog).
        8. Gain trust by demonstrating value at the end of each iteration.
        9. Track progress using tools and metrics.
        10. Track progress daily and visibly.

        Sprint (Iterations) expectations: 90 to 120 days

        A common release cycle, for Agile projects, is a Quarterly one (every 4 month). The OMB's expectations are between 90 (approx. 3 months) to  120 days (approx. 4 months). The actual Agile practices can fit this recommendations without much effort.
        For example, the Office of Management and Budget (OMB) recently issued guidance that advocates the use of shorter delivery time frames, an approach consistent with Agile. ... Specifically, OMB’s June 2010 memo on IT financial system reforms and the December 2010 IT management reform plan 5 encourage modular development with usable functionality delivered in 90 to 120 days.

        Agile approaches used (see Appendix IV: Federal Project Profiles)

        • 4 of 5: Scrum
        • 1 of 5: Iterative with some Agile practices

        Costs (see Appendix IV: Federal Project Profiles)

        This cost profile is based on the 5 projects evaluated by GAO, values are expressed in millions of US dollars (USD$)
        • Minimum:      6.60
        • Average:      82.18
        • Maximum: 192.30
        So, next time someone asks Can Agile be used on large projects?, you can say with no doubt Yes!

        Not an easy road (see Federal Challenges in Applying Agile)...

        14 challenges were identified while performing this report, below is the complete list organized in four topics: Organizational Commitment and Collaboration, Preparation, Execution, and Evaluation. To expand each topic please refer to the GAO's report.
        Organizational Commitment and Collaboration 
        1. Teams had difficulty collaborating closely
        2. Teams had difficulty transitioning to self-directed work
        3. Staff had difficulty committing to more timely and frequent input
        4. Agencies had trouble committing staff  
        Preparation
        1. Timely adoption of new tools was difficult
        2. Technical environments were difficult to establish and maintain
        3. Agile guidance was not clear
        4. Procurement practices may not support Agile projects  
        Execution
        1. Customers did not trust iterative solutions
        2. Teams had difficulty managing iterative requirements
        3. Compliance reviews were difficult to execute within an iteration time frame 
        Evaluation
        1. Federal reporting practices do not align with Agile
        2. Traditional artifact reviews do not align with Agile
        3. Traditional status tracking does not align with Agile 


        The full 32 practices list

        Please find the full list in the first entry of this series: 

        Effective Practices for Applying Agile, from the GAO's report 12-681


        Here is a list of 32 practices and approaches identified as effective for applying Agile to software development projects. This list is based on an analysis of practices identified by experienced Agile users. The analysis, and resulting report, is product of the U.S. Government Accountability Office (GAO), the report can be found here "Effective Practices and Federal Challenges in Applying Agile Methods".

        The second entry of this series contains several key point extracted from the GAO's report.

        The list of 32 practices 

        I. Strategic Planning


        1. Strive to be more Agile, rather than simply following Agile methods and steps. This approach encourages adoption of the philosophy, or mindset, rather than specific steps. This is also referred to as being Agile, or having agility versus using it.
        2. Allow for a gradual migration to Agile appropriate to your readiness. Migration steps might include combining Agile and existing methods, conducting pilots, and preparing technical infrastructure.
        3. Observe and communicate with other organizations implementing Agile. For example, those starting to use Agile can consult with others who have more experience, including academic, private sector, and federal practitioners.
        4. Follow organizational change disciplines, such as establishing a sense of urgency and developing a change vision. A clear vision of change helps staff understand what the organization is trying to achieve. Another organizational change discipline is communication strategies.
        5. Be prepared for difficulties, regression, and negative attitudes. This approach reinforces that Agile is not painless and users may backslide to entrenched software methods.
        6. Start with Agile guidance and an Agile adoption strategy. This practice advocates having these elements in place at the start, even if they must be copied from external sources.


        II. Organizational Commitment and Collaboration


        1. Ensure all components involved in Agile projects are committed to the organization’s Agile approach. This practice encourages organizations to ensure that everyone contributing to a project understands and commits to the organization’s approach. This includes those working directly on the project and those with less direct involvement, such as those providing oversight.
        2. Identify an Agile champion within senior management. This practice calls for someone with formal authority within the organization to advocate the approach and resolve impediments at this level.
        3. Ensure all teams include coaches or staff with Agile experience. This practice stresses the importance of including on each team those with direct experience in applying Agile. While training is helpful, hands on experience helps the team members learn and adjust.
        4. Empower small, cross-functional teams. Empowered teams of 7 to 18 people decide what to deliver and how to produce it. The teams should not over-rely on one member’s skills.

        III. Preparation


        1. Train the entire organization in your Agile approach and mindset, and train Agile practitioners in your Agile methods. For example, managers must understand the approach so that they know how it will affect them and teams need to know the specific steps of an iteration to conduct it properly.
        2. Ensure that subject matter experts and business team members have the required knowledge. This practice stresses that staff involved in fast-paced iterations must truly be experts in the  processes being automated in that iteration in order to reduce delays. For example, a team member representing financial customers must be fully familiar with the needs of those customers.
        3. Enhance migration to Agile concepts using Agile terms and examples. For example, use terms like user stories instead of requirements, and Agile Center of Excellence instead of Project Management Office. Provide examples, such as one illustrating the small scope of a user story to teams writing these stories.
        4. Create a physical environment conducive to collaboration. A common practice is to co-locate the team in a single room where they can continually interact. Other ways to enhance collaboration are to reorganize office space and use tools to connect remote staff.
        5. Identify measurable outcomes, not outputs, of what you want to achieve using Agile. An example of this practice is creating a vision statement of project outcomes (such as a decrease in processing time by a specific percent in a set time), rather than outputs (such as the amount of code produced).
        6. Negotiate to adjust oversight requirements to a more Agile approach. This practice notes that teams may be able to adjust oversight requirements by using frequent, tangible demonstrations to gain the trust of reviewers and investors, potentially reducing the need for more formal oversight documents.
        7. Ensure that the definition of how a story will be determined to be done is comprehensive and objective. Comprehensiveness includes defining what constitutes a finished product (i.e., packaged, documented, tested, and independently verified). Objective means measurable or verifiable versus subjective judgment.
        8. Make contracts flexible to accommodate your Agile approach. Contracts requiring waterfall-based artifacts and milestone reviews may not support the frequent changes and product demonstrations in iterations, and may inhibit adoption.

        IV. Execution


        1. Use the same duration for each iteration. An example would be establishing that iterations will be four weeks each within a release to establish a uniform pace.
        2. Combine Agile frameworks such as Scrum and XP if appropriate. Disciplines from different frameworks can be combined. For example, use project management disciplines from Scrum and technical practices from XP.
        3. Enhance early customer involvement and design using test-driven development. Test-driven development refers to writing software code to pass a test. This practice maintains that involving customers in these tests helps to engage them in the software development process.
        4. Include requirements related to security and progress monitoring in your queue of unfinished work (backlog). Including activities such as security reviews and status briefings in the backlog ensures their time and cost are reflected and that they are addressed concurrent with, and not after, iteration delivery.
        5. Capture iteration defects in a tool such as a backlog. This practice calls for queuing issues so that they are resolved in later iterations. For example, lists of unmet requirements generated at end-of-iteration demonstrations should be queued in the backlog for correction in a future iteration.
        6. Expedite delivery using automated tools. For example, tools can track software modifications, and compliant development sites or “sandboxes” help customers conceptualize the software in an environment that meets architectural and security standards.
        7. Test early and often throughout the life cycle. The theme of this practice is that testing during software code delivery instead of after delivery reduces risk and remediation costs.

        V. Evaluation


        1. Obtain stakeholder/customer feedback frequently and closely. For example, feedback is obtained during the iteration and at its completion at an iteration retrospective. This practice was linked to reducing risk, improving customer commitment, and improving technical staff motivation.
        2. Continuously improve Agile adoption at both the project level and organization level. This practice invokes the discipline of continuous improvement, meaning always looking for ways to improve. For example, improvements can be made by adding automated test and version control tools, and enhancing team rooms. These issues can be tracked in project and organizational-level backlogs.
        3. Seek to identify and address impediments at the organization and project levels. This practice encourages organizations to be frank about identifying impediments so that they can be addressed.
        4. Determine project value based on customer perception and return on investment. This practice recognizes that tracking progress only against cost or schedule criteria set before the project began could lead to inaccurate measurement of progress if, for example, major changes in scope occur. Instead, Agile encourages customer feedback as one measure of progress. Comparing solution value to the cost of the solution is also a gauge of success.
        5. Gain trust by demonstrating value at the end of each iteration. Progress can be tracked using tools and metrics such as burn-down charts and velocity, which can be automated, and by success indicators such as “customer delight,” and reduced staff stress and overtime.
        6. Track progress using tools and metrics. This practice includes demonstrating key requirements in early iterations, and showing customers that requirements in the backlog are delivered and not forgotten.
        7. Track progress daily and visibly. This practice stresses that status is checked daily and publicly. For example, a progress chart is posted openly in the team’s workspace, with timely revisions to reflect ongoing feedback.

        Subscribe to our mailing list

        * indicates required
        Email Format