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.

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.

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.

Bad Communication Habits (1 / 3)

1. "To many mind"

-Nobutada: Please forgive, too many mind.
-Nathan Algren: Too many mind?
-Nobutada: Hai. Mind the sword, mind the people watch, mind the enemy, too many mind... [pause] No mind.

[The Last Samurai (Wiki Quote Org.)]

The problem

Communication channels of software teams often starts to wildly swell, because of a poor management. This situation can throw down the cliff any development effort (in-house or product), because of the messy environment generated by it. The problem begins when every team member is able to talk with others inside and outside the team. This means that any stakeholder can talk to any team member and vice versa. You quickly end up with a situation like this (in terms of the amount of communication channels):

Unmanaged communication channels

The solution

You need to find a hub in every group. This is not a difficult task, if you look at Scrum role's definitions  you'll find that such hubs already were designed for us: they are the Scrum Master and the Product Owner. So, instead of having 28 communication channels (7 x 4), you end up with just one! 

Managed communication channels

Why does it happens?

Often in in-house development environments, and some not matured product companies, teams start working without a proper role definition. They instinctively know that each group have a leader but as time passed and problems starts to rise, roles and leadership vanished. Communication gets groggy because of everyone is talking at the same time to each other.

Users starts reporting the same issue twice or more. Two or more developers start working on the same bug without knowing it. No one has the “big picture” of the product / project, because everyone has a little piece of it.

Zooming in ...

To better illustrate the problem, we can inspect the following example: Imagine you are working on a Scrum team composed of 8 people. Your team needs to interact with three others: the Key stakeholders, and two production support teams (A and B); they have 4, 3, and 4 members respectively.

What will happen if all this people starts talking without a proper management? You end up with the following communication channels (from one group to another and withing each one):

Here is a graph to better explain the situation.

And, what about channels withing a group (Scrum team to Scrum team)?

We can not force people not to talk, and even if we could it's a very unhealthy thing to do. As you can see just between Scrum Team's members you could have up to 56 channels. These channels can create information islands. Again we have the answer on our face: Scrum Ceremonies (specially the daily Scrum). Those meetings allow knowledge sharing and avoid isolation and sub-groups.

One problem, when adopting Agile is that people thinks that is just another set of rules to follow and don't think about why the methodology suggest does kind of guidelines. Maybe if we show first the problems and then present the proposed solution they will be more willing to adopt the change.

Agile Maturity Model [Level] Survey

Please take a moment to fill this short survey, when done you can share it with other people using or planning to use Agile methodologies.

Create your free online surveys with SurveyMonkey, the world's leading questionnaire tool.