Agile Coach Leadership Traits

scrummaster-agile-leadership-servant-job-description

What is Leadership? 

Three Styles

  1. Autocratic – Has to do with a totalitarian approach to leadership. This is more of an attitude than a leadership style.  This leader demands instant obedience, no discussions from underlings are desired. This is NOT a desirable leadership approach.
  2. Free-rein – The opposite of autocratic. This is more of a “hands off” approach. This is a good approach when dealing with highly skilled and expert individuals (professionals). Some of the more “blue collar” type individuals actually do not desire a free rein approach. They are told what to do and when to do it at work, they almost expect similar treatment at church.
  3. Participatory – Typically the best approach. Group decision-making, multiple leadership. There is, however, a leader at the head.

 Three Components

  1. PersonThe particular personality traits and leadership attributes the leader brings to the table. There are different personality types and individuals will respond differently and accordingly to this personality depending upon his or her personality.
  2. Group – The question is: “What kind of leader does this group actually need?” AM I WHERE I NEED TO BE?
  3. Situation – Leadership is situational. We can take the same leader who was successful in one scenario and place him or her in another scenario and NOT have the same exact results. Happenings may be slower, faster, not at all. Rather than success, failure could be more commonplace.  This could be related to any number of factors: geographical, cultural, social issues, political differences, phraseology, management approaches, leadership styles, etc.

Three Terms

  1. Leader – Really comes down to what a person is. He or she IS a leader. Generally a leader is one who has the ability to influence individuals to follow a particular direction or pursue a particular goal. John Maxwell, “Leadership is influence, nothing more, nothing less.” Leaders are goal-oriented.
  2. Administrator – These are more result-oriented. They strive for order, to correct failures, and operate systems.
  3. Manager – same as administrator.

Leaders inspire people, but managers depend on systems. Managers attempt to adjust to change, while leaders attempt to produce it.

Leadership Check Up Continue reading “Agile Coach Leadership Traits”

Becoming an Agile Coach – Effective Communication Techniques

take-the-power-back-power-to-people

Effective Communication Techniques 

Communication requires cultivation of techniques. It is not something that comes naturally. The number one reason relationships fail is poor communication (leads to massive misunderstanding).

Five Conditions to meet for effective communication:

  1. Desire – you must want to be effective. It really must be a consuming passion. Love for coaching and teaching should drive you to desire excellence.
  1. Understand the process of communication – the three aspects of communication MUST be understood and appreciated. We use words, but we also use imagery and gestures. We also receive data back from listeners. What seems so easy is really a very trying art and science. But this can become quite easy once we appreciate the process of communication. We are dealing with needs, emotions, feelings, and realities. These are serious issues and we must take them seriously.
  1. Master the basics – three basic skills
    • Connecting with the listeners
    • Conveying information in ways they can understand it
    • Checking responses (interest levels and connectivity is seen in body language)
  1. Dedication to Practice – It’s time tested. Which means you won’t be a rockstar on day one.
  1. Patience and Persistence – time is our friend. We will get better. There is simply no way it cannot happen if we follow the first four conditions. Self-evaluation is of tantamount importance.

How do I get people to pay attention to me?

We all want attention. We thrive on it and want more of it.  It is human nature, but it is also an enemy of the Agile communicator. Why? Because we want to draw people’s attention, not to us, but to the potentially life-changing affects of being agile…

The first law of communication is audience attention. You must get their attention.

Three techniques for getting and keeping attention:

  1. Pay attention to others and they will pay attention to you. Work the crowd. Don’t simply appear. We must be the right person, at the right place, at the right time. We speak truthfully to needs, fears, hurts, and on practical and relational matters. In the speaking event, the listeners are our top priority, not us or even our message..
  1. Overcome the stiff competition for attention. People are no longer getting the personal touches they desperately need. We are closer physically than ever before, but fail to connect with most people. Ever notice the service attendant at the drive-through window? Ever notice how people will not acknowledge each other in elevators? People tune out or “filter” people out of our lives or environments. This makes communication very difficult.
  1. Be interesting! Build messages in creative ways! Push yourself beyond your self-created limitations. People come to speaking events prepared to “turn on the filters.”

5 tactics to improve communication Continue reading “Becoming an Agile Coach – Effective Communication Techniques”

Ideas on Managing Distributed Teams Using Agile [3/3] – Review and Conclusion

globalization-agile-distributed-teams

Things to be followed by Distributed team in Sprint review meeting:

  • Keeping Track of the Stakeholder Comments -During the sprint meeting, the distributed team needs to capture these comments so the Product Owner and the development team can decide which ones they will act on.
  • Effects of Distance – The facilitator of a distributed retrospective needs to understand the cultural differences in the team. SM needs to understand how different cultures interact when they want to change something
  • Or have issues they want to talk about that can help the facilitator encourage participation from all team members.
  • Release Planning –The number of Sprints to map out and use with “Look ahead Planning Technique” will depend on Sprint length, dependencies, and needs of the teams involved.
  • Engaging Stakeholders – At enterprise level environments, to address the diversity of data by the Scrum team, the PO can help identify which customers are representative of different markets.
  • Resolving Blockers – The SM should create a list of blockers and assign them to team members or managers. The SM should also ensure the team is burning through the blocker list.
  • Handling New Requests in the Middle of a Sprint – In Distributed Scrum, it becomes mandatory that the team commits to sending requests through the Product Owner(s), who will decide the priority of the request in the Product Backlog.
  • Demos May Provide a False Sense of Completion – Add a DRAFT watermark on any screenshots or to use data that is clearly not real, to avoid false sense of completion to the stakeholders. Setting Expectations – The facilitator, for distributed teams, should talk to the team ahead of the first retrospective and explain the expectations for the retrospective.
  • Remote Demonstrations – Network Delays and Poor Performance – Distributed Team should test their tools ahead of time to be sure the distributed meeting will run smoothly, without network poor performance

The team can also consider making the recordings available for download before the demonstration meeting and discussing them through a teleconference.

Understanding the Team Members’ Personalities

Team have a different combination of personalities, and the facilitator of the retrospective needs to understand the personalities of team members to lead the meeting effectively.

  • Teleconference Meeting – Distributed teams with overlapping work hours should use a teleconference call to the same phone number every day to hold their Daily Scrum meetings.
  • Videoconference Meeting – The main advantage of this approach is that team members get to see one another, so there is less nonverbal communication loss. Dealing with Defects – Distributed team may want to consider creating a user story with a certain number of story points in the Sprint to deal with the problems, OR, they can set a priority for the maintenance tasks as per the customer log OR create a subteam to focus only on handling these issues during the Sprint OR depending on the skill set of the technical support team team to make the necessary code changes
  • Services May Vary by Location – Set up a single machine with a standard configuration that everyone uses during the demonstration meeting. Before the start of the meeting, distributed team members can access the machine (remotely or locally) to bookmark links, set up scripts, and do a quick dry run of their presentation.
  • Respecting Cultural Differences – SM needs to make sure cultural difference should not be taken lightly during the retrospective meeting in distributed teams
  • Managing Dependencies within the teams – Agile teams will not try to account for every possible dependency at the start of the project, but will look ahead two or three Sprints to ensure that teams are ready to deal with dependencies, using INVEST model
  • Gaining Commitment – With a distributed team,team members who are sensing that other team members have unspoken issues need to take responsibility for drawing attention to the issues to SM because of this, the SM needs to rely on the whole team to take responsibility for ensuring good communication.

Approaches to Handling Time Zone Issues

Distributed Teams can use four different methods to deal with distributed Daily Scrums where the team has members with no overlap in their work hours, as follows:

  • Daily Scrums through documentation
  • Liaison approach
  • Alternating meeting times
  • Share the pain Disruptions at the Team Member Level – Handling Stories the Team Cannot Complete During the Sprint – Before working toward the solution, the team first needs to identify the work they need to do to complete the story through meetings between team members or with the Product Owner.
  • Asking for Comments Before the Retrospective Meeting – What Went Well and What Can We Improve?
  • Ask the team for comments about issues or problems they noticed since the previous
  • Sprint retrospective and summarize them for team discussion. The result is still an action plan and a list of behaviors the team needs to change or continue in the period until the next Retrospective.

Risks

During the Release Plan, the PO will want to identify the risks associated with the project and teams, when possible, the mitigation plan for each of them Note: No one should interpret silence as agreement. Team members should phrase questions in a way that needs a verbal response to improve the understanding within the team. Precautions to be taken while conducting Distributed Scrum meeting

  • Increased distraction – Background noise can be distracting on a teleconference so teams should chose a room to conduct the meeting.
  • Handling Blockers During the Sprint – In the large scale enterprise transitioning to agile, the SM needs to hear from Distributed Scrum Team members who are facing blockers and dealing directly with inhibitors will help increase the velocity of the team over time, as well as the velocity of other teams as they transition to Scrum.
  • Provide Questions to Focus the Discussion – In distributed setup, team members respond to a set of questions developed or selected by the team. The purpose is to focus on a few issues and address them effectively instead of trying to address a lot of issues and address them poorly.
  • Coordinate Multiple Product Owners of different teams – Product Owners meet regularly to discuss Product Backlogs, dependencies, and links between and boundaries between user stories w.r.t. different teams
  • Release Plan Check or Update: Enterprise Scrum Teams often begin providing tasks for high-priority user stories before the Sprint Planning meeting. All team members discuss the tasks because it helps with communication for distributed and scaled teams and provides opportunities to find better ways of completing the user stories. Silence on a teleconference is not a commitment.
  • Keeping the Team Engaged – Possibly the best way to stay engaged and to make sure that others on the team stay engaged is: Awareness. Build awareness of what the team is working on.
  • Advertising. Advertise for collaboration.
  • Attack blockers. The team and SM should strive to fix all blockers within one hour of the Daily Scrum
  • Responding to Questions During the Sprint – For enterprise product development, the PO should look for ways to match representative stakeholders with the teams’ working hours and to be available during that time as well. For applications the team is developing for a specific client, the Product Owner may not have the flexibility to choose stakeholder representatives available during the full working day of the client.
  • Discussing Reported Issues – During their retrospective, the team reviews the reported issues and, if others feel strongly enough, the team addresses them, creates their action plans, and log them as actions they will revisit in follow-on Sprint retrospectives to evaluate their success.
  • Facilitating the Meeting – In a distributed environment, as individuals come into the call, they will identify who they are. The SM calls each person and asks for their response. They may respond in the order they arrived at the teleconference or the SM may choose to call on each person
  • Sharing Time Zone Challenges – One approach to help manage such cases is to make sure that distributed teams in different time zones are fully self-sufficient and the team spreads the work to minimize dependencies.
  • Managing Time Effectively – Limit the discussions to a limited set of issues, it is important for the team to agree, this is the right set to be talking about in the meeting. The meeting facilitator may want to keep a window of time open for unplanned issues that come up during the retrospective.
  • Invest in Smarter Development – Test automation and continuous integration help agile teams to complete user stories within a Sprint, working together or for distributed teams.
  • Taking Daily Scrum Notes – Helps the distributed team members to overcome language problems, plan and learn. Chat Tools & Wiki help distributed teams to do Daily scrums.
  • Continuous Integration – Continuous integration is the key to delivering stable, high-quality code consistently and quickly, which results in reducing time to market for any distributed agile team Release Retrospectives – The team talks about the project, and then defines and records the milestones in the project like initial training, team formation, Stand -up Meetings, start of development, middle of release, deployment etc.

Coordinating Agile and Non-Agile Teams

Making sure the non-agile team is aware of the priorities of the agile teams and keeping dependencies visible can help to prevent blockers between the teams. Scrum of Scrum can solve distributed team road blocks, future dependencies, commitments to other team members, issues with integration, and other points that impact one another.

  • Reports Any Build Failures to the Team – Allows the Distributed team to know the current state of the code in the integration branch of the source control system, generating a notification email for build success or failure.
  • Face to Face Collaboration –SM should reduce the amount time spent each day on project setup tasks, which will extend the duration of the project startup tasks and enables to build trust and relationships needed in distributed development efforts.
  • Reduces the Risk of Integrating Code – Continuous integration ensures a build runs regularly and allows the distributed team to identify integration issues earlier when they are less costly to fix. This practice helped the team to identify design problems and avoid introducing defects in scenarios we did not cover. These smaller testable deliverables allow the team members testing the feature to start their work in parallel with the development.
  • Establishes Greater Confidence in the Product – When developers are doing the unit testing of their code, they should also create automated unit tests as continuous integration certifies every build, developers can make changes with more confidence and the entire team can remain in sync with the latest build.
  • Reduces the Time to Find Integration Issues – Developers receive the build status by email, so they can see and fix problems. The next time the build runs, the build status changes from fail to pass automatically.
  • Improves the Efficiency of the Team – Distributed Teams efficiency can be improved by automating once and then reusing as much as possible. This removes human error, provides consistency, and frees up people to do higher-value work.
  • Builds Can Run at Different Frequencies – Setting up the hourly build helps the distributed team to know about a failure closer to the time of the code integration, and team members can take action on it earlier.
  • Test Automation – To streamline the testing and help the distributed team to get as much done as possible within a two week Sprint, teams should automate time-consuming manual processes where possible
  • Dedicated Automation Teams- The developers in distributed teams should tell what is ready to be automated to allow testers to closely couple with the product. And other testers in the distributed team doing manual executions and informs their highest-priority items for automation as well.
  • Identify High-Value Automated Tests – Testing installation and configuration of the operating system, regression tests, as well as acceptance into testing tests all have a high rate of return because the distributed should often repeat and in different environments.
  • Automate What Is Stable – Automated test cases should be created for parts of the project that are stable will help teams improve their effectiveness and avoid rework.
  • Test-Driven Development – For distributed teams, if someone is working on code written by a developer in another geographical location, having the built-in documentation in the code helps reduce their dependency on the author and enables them to work with the code faster. Working directly with the source code provides a common language for the developers and removes languages barriers.
  • Helps Reduce the Time to Fix Defects – By using such tests and fixing the area where the problem is occurring, the developer in distributed teams can save the time needed to create a full build, start the application, get to the right place, and test the fix manually.
  • Helps Improve Code Quality and Provides a Safety Net for Changes – As the distributed team should write the unit tests first, providing test coverage for all or most of the code, thus, provides an early defect detection process where developers can improve the code knowing the existing set of tests will detect any problems.

Conclusion

Distributed team needs to go for mandatory training to run into full fledge agile teams so that they could understand the potential impact of making the change. Although the project teams are undergoing through while adjusting to be a distributed agile teams, it becomes more important for them to understand and adhere to Scrum, rather than immediately thinking that Scrum needs to be changed.

I believe that collaboration becomes very important in distributed teams as they collectively responsible for delivering on their commitments. One important key to having success in managing distributed team is to have a high commitment level from all team members, and the best way to get that is to give them ownership over how they will work.

Another key to embrace self-managed distributed team is valuing the entire team and not having an “us versus them” atmosphere between different Scrum Teams on the project. The best ways to build relationship within teams is to find ways to share the pain of being a distributed team, to get to know each other as people, and to foster frequent, quality communications between team members.

Another way to introspect the distributed team management is to use their Sprint Retrospectives to see what they are doing and how they are communicating is working for them; when they need to adjust, they should do so as fast as possible.

I must say the teams with members distributed across sites can enhance code ownership and improve autonomy essential to team self-organization. Automated communication of Product and Sprint backlogs throughout the organization combined with upward reporting of teams’ status to management can tightly align the team distributed teams together.

Ideas on Managing Distributed Teams Using Agile [2/3] – The Retrospective

globalization-agile-distributed-teams

Retrospective Timings :

To be effective and timely, distributed teams should call joint retrospectives as soon as possible after having their own team meeting. Depending on the no. of teams involved in a joint retrospective, teams may want to limit the number of participants from each Scrum Team to keep the meeting productive.

  • Team Composition – Teams >=9 people should consider geographic closeness and proper distribution of skills as well as team size so as to build self-organizing teams
  • First level of Sprint Planning – The PO, SM will use a screen-sharing tool to display the vision, sprint goal, user story, the estimates the team provided, and the acceptance conditions for the user story.
  • Answering the 3 questions: Team members should communicate information that brings value to others on the team. They should also try to identify team members that can help them resolve their issues.
  • Documentation helps to Overcome Distance: Because of language barriers, distributed teams often need more written documentation than collocated teams. Another approach is to record the demonstration before the meeting to allow the developers to create the recording at their own pace in the language of the meeting or to have a fluent speaker speak over the recorded demonstration.
  • Hold Joint Retrospective – The Distributed Teams working together will conduct their individual
  • Sprint retrospectives at the end of each Sprint and then will conduct a joint retrospective.
  • The benefit of this approach is that it promotes communication between the various teams involved in a project
  • Individual Scrum Teams should aim to have the lowest distribution level possible encouraging feature teams over component teams.

Dealing with Incomplete Stories

The PO takes the impact of dependencies into consideration when reprioritizing the Product Backlog due to work the team did not complete during the Sprint, highlighted in Scrum of scrum Coordinating the Team on a Daily Basis – Priorities can change daily. The Daily Scrum meeting provides a daily synchronization point for the team and allows them to revise their plans regularly. Using the Right Tools : In a distributed environment, tools and good practices can help team members communicate more effectively, but it is more important to make sure the tools the team introduces will help them get the job done.

Scheduling for Teams with Overlapping Work Hours – Make sure all team members of distributed team, regardless of the time zone, can complete their work and prepare for the demo within overlapping work hours.

Larger Retrospectives

Distributed team members can reflect and comment on release quality and capability. The team talks about the project, and then defines and records the various milestones within the project to improve on or continue in future releases.
Enterprise planning tools for distributed team members, PO & SM to develop more than one feature to address a single solution so as to disaggregate the higher-priority features into user stories that can fit within a Sprint.

Checking Estimates from Preplanning Teams

In scaled environments where teams send representatives to help with preplanning, it is important
the teams who are going to be doing the work revisit the estimates

Committing to the Team

Team members are making a verbal commitment to their team when they state what they are going to do today, creating an opportunity for the rest of the team to confirm they met their commitments yesterday.

Valuing the Whole Team

SM should focus on an “us” versus “them” attitude in the distributed team, due to more delays in communications & fewer opportunities to work together Scheduling for Teams with No Overlapping Work Hours.

Alternate meeting time

The distributed team holds one Sprint Review meeting during the normal workday for part of the Scrum Team and holds the other Sprint Review meeting during the normal work hours of the other part of the Scrum Team.

Building Trust

SM needs to develop a sense of trust and honesty with one another, which in turn will lead to a wider degree of openness.

  • Single Backlog for Multiple teams – The different skill sets in the team needs to deliver user stories that are available across each distributed location
  • Separate Backlog for Multiple teams – The Scrum teams work independently from one another and have their own individual Sprint backlogs, but the Sprint dates are the same marking their interdependencies and risks in the Sprint preplanning sessions or in a Daily Scrum of Scrums.
  • Reviewing Changes Based on Stakeholder Feedback – The team would review changes made since the preplanning meeting, and the PO would confirm the priorities of the Product backlog.
  • Verifying Progress – Tasks not opening and closing regularly are an early sign the team may be going off track. Team members not showing regular progress may be facing outside distractions the SM should reduce or remove.
  • Transparency – Distributed agile teams should use project management tool to identify tasks that are open, in progress, and completed so everyone is aware of the current status.

More on the Sprint Review and Conclusion next!

Ideas on Managing Distributed Teams Using Agile [1/3] – Introduction and Ceremonies

globalization-agile-distributed-teams

Today the businesses are shifting to emerging economies due to reduced business operations cost and easily available workforce, like Russia, China, India, Philippines etc. If I put it more precisely, tomorrows business would be more virtual and distributed with distributed as its key element. Hence forth, the need for better managing the teams, using right tools and process become critical day by day for any enterprise company.

Shift and Need of having Distributed Agile Teams

  • Globally distributed teams reduce costs
  • Reaching Market more quickly with the “follow the sun’ Model
  • Distributed Teams Expand Access to New Markets
  • Acquisitions as a result of consolidation resulting in companies working together to integrate their business
  • Expanding for Innovation and Thought Leadership
  • Telecommuting gives options to communicate with their teams more effectively
  • Collaboration Tools – Improved tools for distributed communications and server-based, multiuser tools for product development are removing barriers, and more teams view distributed collaboration as an alternative.

Handling Distributed Agile Teams

Distributed teams heighten the need for clear, timely communication between sites. You might be thinking of some questions as the complexity increases with distance as time zones, language barriers, and cultural differences get in the way, let me resonate it for you:

  • Are distributed teams difficult to manage?
  • Are they failing to meet some expectations?
  • Are they having trouble working as a team?
  • Is team morale a problem?

Agile can’t fix every problem, but it can bring them out into the open where the team can evaluate and correct them. Agile puts challenges under a magnifying glass. As the image under the glass grows larger, they scream for attention, and your team’s performance will improve after they address the challenges and correct dysfunctions. Continue reading “Ideas on Managing Distributed Teams Using Agile [1/3] – Introduction and Ceremonies”

Why It’s So Hard to Hire Great People

google-team-science

Google admitted that its infamous brainteasers — e.g.: “How much should you charge to wash all the windows in Seattle?” — are awful at predicting who will be a good employee.

Your reaction might be: um, FINALLY. And, sure, thinking about windows-per-housing-unit isn’t the most direct way to assess engineering skill or creativity. But Google’s flawed strategy was the answer to another brainteaser: What’s the best way to hire great employees, anyway? People are complicated, organizations are complicated, matching people and organizations is complicated, and it’s extremely difficult to predict who will be brilliant and who will be a bust.

“Years ago, we did a study to determine whether anyone at Google is particularly good at hiring,” Laszlo Bock, Google’s senior vice president for people operations, told LinkedIn. “We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess.”

Brainteasers didn’t matter. Colleges didn’t matter. GPAs? Yeah, those didn’t matter, either. The ability to hire well turned out to be utterly random for everybody…

Frankly, this is why understanding culture is so important. Google could have used something like TeamScience to help them:

– Understand their unique team culture
– Then hire the right cultural fit to their teams

Makes sense right? We already know that it makes sense… but most companies don’t take the time to do a cultural survey.

[HT: The Atlantic]

Agile Habla Aqui?

Agile doesn’t speak English, Spanish, or Martian. It just speaks efficiency and speed to market. Here’s how to implement agile across languages.

As agile grows in popularity, many businesses are finding that one of its greatest gifts is its common vocabulary. Other methodologies often struggle to communicate across different languages, processes and cultures. But by working from a foundation of mutual understanding based on a shared language, agile prevents misperceptions, delivers the customer’s vision and accelerates time to market – all by implementing some simple yet highly effective practices.

So how does this common language of agile development work? While smart vendors and customers will make an effort to work with culturally compatible teams, the effort to synchronize expectations and processes can’t stop there. Teams from different regions, backgrounds and companies will still need to reach out and create a synchronized language.

The five agile practices below can help teams work across their differences to ensure a smooth, streamlined project cycle.

Provide real-world examples of what we mean

Effective agile teams will find a way to work around an unavoidable truth: we all define words and concepts differently. We come from different backgrounds, some of us speak different languages, and all of us are influenced by sources such as former training, bosses or projects. As a result, our viewpoints and definitions can vary widely, which can quickly lead to erroneous assumptions on a project. By using real-world examples to accompany our agile terminology and directives, any guesswork is eliminated.

Let us look at the following scenario. We recently entered a new software development domain. There is usually “shorthand” that has developed among team members when they have worked shoulder to shoulder for a long time. In this particular case, our customer’s team has worked together for over 15 years. So the terms used while expressing requirements in user stories are clear to them. For us as an external developer it would have been easy to misunderstand the meaning of that shorthand. However, the real-time interaction required of agile allows us to overcome such deviations due to misunderstanding in just a matter of hours.

Implement a framework like CMMI or SCRUM

On one project I found myself in Mexico with an extremely diverse team. Engineers, developers, economists and government workers all played different roles on this project, and everyone was focusing on a different piece of the puzzle. The viewpoints and ideas clashed to such an extent that I really doubted we could hit the project deadline or meet the customer’s goals. Yet in the end we did deliver a successful product – and it was because we implemented a framework that helped everyone understand and carry out their specific roles. The magic of implementing the right framework is that it defines parameters, institutes clear communication and spells out the right processes and directions. Putting a framework in place at the start helps dispel any confusion over priorities and roles down the road.

Define the literal language

This is absolutely necessary in a time-boxed iterative process. The reason is obvious; if we’re working with 14-30 day development cycles, even a slight misunderstanding can lead the project disastrously off course in a very short time. Once again, remember that we all bring different understandings to a project.

done-not-equal-doneThis is never as evident as it is with the word “done.” Generally, a team’s Definition of Done (DoD) is aimed at bringing a standardized quality to meeting client demands and making success repeatable throughout the project. But the standards themselves can differ from team to team. One team might decide that all coding, testing and peer review must be completed, before it can be called done. Another team might decide to split their DOD into additional levels of Done Done and Done Done Done. Still another might have adaptable DoD depending on the project type. To make sure that everyone is on the same page at every point in the project cycle, precise definitions are critical so take the time to develop them and ensure all team members use them.

Think of it like building a house

In the United States, you often pay for your house long before you move into it, since the house has to pass certain inspections and is only considered ‘move-in ready’ after those inspections. In another country, on the other hand, you might move in before construction is officially complete and then keep working on it while you’re in residence. Such different practices and expectation can easily lead to a misunderstanding – so you can see why it’s vital to clarify the meaning of our words.

Stay focused on the promise to the customer

True, a lot of businesses like to talk about their “promises” – but when it comes to agile, this isn’t just empty talk. Accountability is woven into every fiber of the agile model, while teams keep the customer’s needs in mind at every stage. The Promises Triangle aligns customers, providers and workers by ensuring the workers are both informed of the promise to the customer and empowered to fulfill it. The purpose of this diligent accountability? Avoiding a common pitfall of waterfall model, where the Requirements Document begins a promise that eventually winds through non-technical staff who then add in unrealistic promises – a process that often leads to disappointment in the final product.

Prioritize frequent communication and feedback

Agile cycles are built around user stories – first by gathering those stories, then prioritizing user needs, then deciding what can be delivered within the designated timeframe. Teams also constantly solicit and incorporate feedback to maximize customer satisfaction. On a practical level, this means that customers must be prepared for frequent interaction and able to deliver clear feedback, while vendors must be able to explain how element X affects element Y in a way their customers will understand.

Overcoming different backgrounds and conflicting expectations is important in any business endeavor – but in agile development, it’s absolutely critical for a successful product. By implementing thoughtful and effective strategies to align efforts, teams can eliminate potential missteps and fulfill their promises to their customers. In the end, it doesn’t matter what languages and backgrounds teams bring to the table – by following the above practices, everyone will be speaking the shared language of agile.

Guest post from Tiempo Development, which provides cloud-focused companies with a powerful, integrated platform of services that transforms the way their products are developed, deployed and supported.

Peter Saddington Session on the Science Behind High Performance Teams #agile2013

Dear Peter,

Thank you for being a part of Agile2013. Following is some information about your session.

  • Number of attendees at the beginning of your session: # 170
  • Number of attendees at the end of your session: # 170

We asked attendees to indicate whether they would recommend your session to their peers:

  • Yes (Green): # 120
  • Maybe (Yellow): # 3  ***CANT PLEASE EVERYONE*** 🙂
  • No (Red): # 0

 Thanks,

Agile Alliance Team

=========
Had a great time! Thanks Agile Alliance!

=========
Below is the scribd version:

Action & Influence – The Science of High Performance Teams Teams Agile2013 Peter Saddington FINAL

Only You Can Prevent Agile Pandamonium

It’s no surprise that VersionOne wants software teams to use an agile development tool. Preferably theirs. Now they have an ally… and these videos are so LoLs!

Meet Agile Panda, one mischievously destructive giant panda who has very little patience (ok who are we kidding?… NO patience) for those still using notecards, Gantt charts and whiteboards to track their projects.

Robert Holler as PandaAgile Panda’s sole mission is to find agile teams using manual tools and destroy shit around their office – just to prove a point that having a centralized agile project management tool is the only way to go. Of course if you do use old-school agile tools, you’re not likely to see this creature blowing something up in your office. Or nailing you point-blank in the crotch with a paint gun.  But you do risk creating pandemonium (or is it pandamonium?) without that centralized visibility.

I found this series entertaining. Looks like VersionOne has posted a few episodes so far; I’m looking forward to what Agile Panda jacks up next!

Check out the “Agile Pandamonium: Say Yes to the Tool” series on YouTube at http://www.youtube.com/watch?v=mEFSzPxFMkg&list=PLgtht2Pp8VhZM8iCNd0NUxy7mImbEkWGd[Oh yeah, and I did hear that some of the VersionOne employees involved in filming these things actually got called into HR for the stunts they pulled inside the building! So if you get even a tiny chuckle from these, make it worth their penalty and share the link!]

version-one-pandaAgile Panda on Twitter@StopAgilePanda

On Facebook at Agile Panda

Staying Agile Webinar – The Notes – High Performance Teams via Mentoring

If you missed last month’s webinar on How to Grow High Performance Teams Through Mentorship by Peter Saddington, we have attached the audio and slide deck below. Enjoy!

A few problems came up when recording, but we were able to save the audio.

$9.99 Apple Store Promotion! Get The Agile Pocket Guide Book on Sale! @ibookstore

apple-store-agile-pocket-guide

It’s here on the Apple Store: The Agile Pocket Guide. It’s right there in the “Learning Business Skills” brick on the main page, in conjunction with the Apple WWDC conference.

It is a two week Apple promotion dropping ebook prices to $9.99 starting 6/4 and running through 6/17.

Would love a tweet about it!:

The Agile Pocket Guide is now only $9.99 in the @iBookstore for the Apple #WWDC2013 – http://ow.ly/lHo6F

There are lots of other books on sale too… here are the other books at the promotion!:

Main Promo Link: https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewRoom?cc=us&fcId=657275399&id=27829&mt=11&ls=1

agile-store-the-agile-pocket-guide-peter-saddington

A Personal Touch @JerryWeinberg @donaldegray

the-secrets-of-consulting

Having been a fan for so long of Jerry Weinberg’s work, I obviously took the opportunity to get something personal from him. His writing has so greatly influenced how I operate as a consultant and if you ever spend more than a couple hours with me, you’ll probably hear me quote him at some level.

Thanks a bunch Jerry. Even though the Law of Raspberry Jam is alive and well… coupled with the Weinbergs’ Law of Twins… sometimes statistical outliers do occur. Count me to be one of them.

Also, thank you Don Gray for being a great colleague, mentor, and friend. Oh, the client’s we’ll encounter together!

 

Transforming Your Business with Agile Culture [Guest Post]

Agile Team Structure

These days almost everyone is familiar with the benefits of Agile methodology. Marked by collaboration, self-managing teams and real-time response to customer feedback, Agile has evolved beyond buzzword status to become a pillar of the technology landscape. Its advantages are just as well-known: customer-oriented solutions, accelerated product release and cost savings, just to name a few.

The rewards are so remarkable, in fact, that some innovative companies are using the Agile paradigm to transform their business culture. My own business has done just that, and we are consistently meeting the goals we set out to accomplish. By applying the same Agile methodologies to drive business strategy and execution, many businesses – ours included – have achieved breakthrough results.

A Shift in Culture

So how do Agile businesses differ from traditional corporate cultures? It starts at the top. Many companies govern through a Command and Control management style that cascades instruction down a hierarchy. Communication and feedback are limited and slow-moving; rather than harness the expertise of the organization, the company acts on the judgment of a few, resulting in ineffective decisions.

Agile companies, on the other hand, operate with the flexibility and high performance of Agile development teams.  Because operations rely more on collaboration and communication, decisions and solutions are more accurate and effective. Employees are provided with their roles and the tools they need, then empowered to be self-managing.

Agile Business In Practice

You’re probably wondering exactly how Agile culture gets practiced on a day-to-day basis.

  • Daily meetings. Just as with Agile software development, brief and daily huddles should answer three questions. What did you do yesterday? What will you do today? What is your main impediment? To ensure thorough communication, huddles should occur first with managers, then with teams. These meetings reduce email, identify potential problems, and clarify any changes necessary for successful execution.
  • Focus on removing impediments. Agile developers tend to focus on identifying roadblocks and removing them. The same approach here can address and resolve impediments before any negative impact can occur.
  • Goals. Agile development teams start out with their end game in mind, and aren’t afraid to envision impressive products. Agile professionals should do the same, and set major goals. For us, we created a big hairy audacious goal (BHAG) so that we had something to work toward. We had traditionally grown at 60 percent year-over-year but applying Agile to our business strategy has helped us position to reach our BHAG of 100 percent year-over-year growth.
  • Strategy. Working hand in hand with goals is strategy; smart Agile experts identify their desired outcome and draft a plan of how to reach it. Agile companies do the same thing by plotting a path to their goal, then empowering teams to execute that strategy throughout the company.
  • Success as a starting point. Demonstrating success right off the bat can motivate the rest of the company. Start with a department, give them an agile project with an isolated workflow, and then promote the success of that project to everyone else.
  • Self-managing teams. In Command and Control mode, you have an authority who controls and micromanages every project detail. In Agile culture, self-managing teams control their own destiny. On a practical level, this means your people must be trained and given the tools to be successful. Then you supply them with the task to be done and the timeframe, and let them execute.
  • Service. Agile teams pinpoint and prioritize “user stories” that highlight what they want to accomplish in a given time period. Once identified, the team owner assembles a cross-functional team that has the required skills to accomplish the project.  These teams self-organize and manage in way that they can accomplish the work in the require time period and produce world class service.

 

Roadmap to Revolution

As you might guess, adopting an Agile business culture can involve a learning curve. I considered it a control+alt+delete to the way we did business and still believe that you can’t dabble in applying Agile to your business strategy – you have to fully commit. The below tips can help you some avoid pitfalls. 

  • Be flexible. As the manager, it might feel unnatural to take on a non-management team role. But it’s important on agile teams to perform whatever work is needed at that time to succeed.
  • Establish and keep a rhythm. For our business, we set up daily, weekly, monthly, quarterly and annual operations to ensure we had a thorough and well-executed plan. Your rhythm might be different, but it’s important to identify what your company needs, put that rhythm in place and stick to it.
  • You might not be developing software, but you do need a SCRUM Master, who is accountable for removing impediments so the team can deliver on their goals and deliverables. Make sure you have someone on the team who knows both the framework and the subtleties.
  • Give your team the tools for success. Team-oriented culture can benefit from tools like cloud platforms that facilitate collaboration and communication.

Embracing Change

Transforming your business with Agile methodologies requires a full commitment. This is a complete system overhaul, and leaders who adopt only half-measures will see inefficiency and poor returns.  But a full dive into Agile will bring the enhanced communication, empowered teams and faster execution that Agile is known for – and once you’ve experienced it, you’ll never want to go back.

Cliff Schertz is the founder and CEO of Tiempo Development, which provides cloud-focused companies with a powerful, integrated platform of services that transforms the way their products are developed, deployed and supported. For more than 25 years, Mr. Schertz has been leading and growing successful technology service companies, enabling his customers to achieve superior performance, high customer satisfaction and profitability.

Learn more about how to understand your culture using TeamScience.

3 Tools for Feeling Less Lonely when You’re Working Remotely [Guest Post]

Depression_02

[Guest post by Walter Chen] – In response to our post on depression and developers.

Developer depression is one of the most important issues that our community needs to address that no one is talking about.

The problem is often made even worse by the prevalence of remote work in companies that don’t recognize the risk of loneliness. Developers working virtually with their teams experience social isolation resulting from the diminished professional and personal interaction with your colleagues that you get from going into the office. And that literally can kill you.

A review of research published in 1988 found that “social isolation is on a par with high blood pressure, obesity, lack of exercise or smoking as a risk factor for illness and early death” . . .

Even without indulging in unwholesome behaviors, . . . loneliness can impair health by raising levels of stress hormones and increasing inflammation. The damage can be widespread, affecting every bodily system and brain function.

Via the New York Times, Shaking Off Loneliness

Fortunately, even as technology, in enabling virtual work, facilitates an accompanying loneliness, it can just as well help us be less lonely as we work remotely. Here are 3 tools that make remote work less lonely and lead us toward making remote work what it should be: awesome.

  1. iDoneThis

Chris Savage, CEO of Wistia, told me that iDoneThis helps his company of 20 feel like it did when it was just 4 people sitting around a table.

That tight feeling of camaraderie comes from a shared knowledge on the team of what everyone is working on, feeding the sense that the team is rowing together in the same direction. And this is essential for distributed teams.

iDoneThis makes syncing up very simple and lightweight. iDoneThis emails everyone on your team every day to ask, “What’d you get done today?” Just reply. The next day, everyone gets an email digest showing the team’s accomplishments from yesterday — which gets everyone on the same page, aligned, and ready to go.

It takes the pain out of a daily standup for remote teams, which is a common source of friction. When people have to wake up at weird times and when Skype drops the call over and over, people get frustrated. iDoneThis provides a remedy because it works asynchronously over email.

For entrepreneurs, like Laura Roeder, who’ve built million-dollar businesses with happy and healthy remote teams, iDoneThis is an essential tool “to create a cohesive team where work is recognized and valued,” which is vital to combating the sense of isolation and being out of the loop that so often accompanies remote work.

  1. Sqwiggle

There’s no substitute for face-to-face conversation when it comes to fighting loneliness. In fact, psychologist Frieda Fromm-Reichmann defines loneliness as “the want of intimacy,” and talking with another person in real-time and seeing their face conveys a far greater sense of intimacy than text on a screen.

Sqwiggle is a video chat app that gives you the immediacy of being in the same office and the intimacy of face-to-face conversation while you’re working remotely. This is a browser-based video chat app that you leave on while you work. Unlike Skype and Google Hangout, you don’t have to initiate a call to talk, and unlike text-based chat, you can actually see the faces of your teammates.

Everyone on your team keeps Sqwiggle running in the background all day while you’re working. To speak with someone, all you have to do is click on their face in the browser. Instant connection with no dialing or inviting, and you can simply start talking.

You can use chat room services like Campfire or Hipchat with your team to maintain some degree of social sanity — but for actually, you know, seeing your team, and looking at their lovely faces, and talking like humans should, nothing really fits the bill.

Via TechCrunch, Sqwiggle Makes Working Remotely Less Lonely, More Awesome

  1. Turntable.fm

Turntable isn’t a productivity tool at all. It’s actually liable to make your team less productive in the short term — but over time, I’ve seen firsthand how it helps people working remotely feel connected through music, which is a boost for long-term productivity.

On Turntable, each person gets their own cartoon avatar. When you join the same room, which is like a virtual nightclub, you all hear the same music chosen by the room’s DJs. Anyone can be a DJ, and the DJs take turns playing music from their own personal collection or from the service’s wide song selection. If you’re enjoying a song, just click a button — your head will start bopping and the DJ will receive a point. There’s a chat feature to talk about which songs are your favorites.

It’s surprisingly fun and provides a way to express yourself through music. Exploring and discussing your colleagues’ music tastes is a great way to get the sense that you’re hanging out together. One of the biggest casualties of remote work is not only professional interaction around work itself but the missed opportunities to grab a beer after hours and chat on a social level.

Getting to know your colleagues as individual human beings is one of the most powerful sources of connectedness, a key to happiness with work. Feeling like you’re on the same boat, visually interacting with each other, and having a bit of fun all add to that all-important human connection.

Developers and Depression – Killing our Knowledge Workers

This presentation, by Greg Baugues:

“I am a developer, and I have Type II BiPolar and ADHD. It’s not something we talk about, but BiPolar, depression, and ADHD runs rampant in the developer community – they tend to correlate with higher intelligence. Many of the symptoms of this conditions make for great developers, but also cause incredible damage. We recently lost one of our co-workers because of untreated mental illness. I want to share my story – and let people know that it’s okay to talk about these things, that it’s nothing to be ashamed of, and how to get help, and how to help those around them.” – Greg Baugues

If you have 20 minutes, it’s worth listening to. As a developer I fully understand this. I remember the brilliance of some of my peers… and before my studies in the social sciences, I do remember once or twice wondering whether they were brilliant not just because they were awesome, but in addition, they might have a mental condition…

It does make you wonder… or at least it makes me wonder even more… whether our (often) terrible environment of busy-work and the insanity of hustle bustle at work heightens the mental condition… in other words, makes it worse.

Are we killing our brightest knowledge workers?

WordPress and Pictures [PressGram Kickstarter App]

pressgram-iphone-app

I know there are more than a few Agilists who are bloggers among us and even more than enjoy taking pictures of their families, friends, their work, and maybe even their food on occasion (admit it, you do it).

Well, if you’re a blogger then there’s a chance you’re also using WordPress, which is what we use here on AgileScout.com – and we’re always looking for neat implementations that help keep more pageviews and more eyes on the content and community we have here.
Pressgram, a recent Kickstarter project that connect filtered photos directly to WordPress, is doing just that. If you’re a fan of taking photos and blogging about them but also in growing your own business and brand around content, then Pressgram is something that you may want to back.
There are some strong business cases as well as creative control that are worth a second.

UK Government – What Agile Looks Like

[The following is from: https://www.gov.uk/service-manual/agile/what-agile-looks-like.html – What is so amazing is that this is a government website… yes. A GOVERNMENT website. I copied it here because I was so stunned… this is great stuff. Almost like Barack Obama telling us to do Agile]

what-agile-looks-like-gov-uk

Agile is a liberating way of working. It does not preclude the use of existing skills and knowledge. But it does require teams, users and stakeholders to adopt new ways of working together.

This short guide lists a few of the behaviours common to agile projects that support successful delivery and learning.

Understand your users

Real people will use your product

Prioritise features for them over everyone else – including your big, scary stakeholders, and seek their feedback early and often. Really listen to them. Even when they tell you things you don’t want to hear or disagree with. If possible, use data from real people using your product to influence the direction of the project. Your focus on the user should be relentless.

“What do you want next Friday? What have we learned last week?”

A sprint backlog, coutesty of http://www.flickr.com/photos/psd/

Iterate often. Build something focused on the next most valuable user need and show it to them; listen to their feedback and improve it. Keep doing this until you have something so useful that they would not be without it.

It perhaps sounds like over-simplifying the complexity of software development and project management, but at its heart this is what agile development is all about: “What do you want next Friday?”

The process of delivering incremental, production-ready software allows a team to deliver value to their users and stakeholders regularly. It shortens the feedback loops that might otherwise have been longer using a waterfall methodology. An iterative delivery cycle also forces the team to think about what the most important features are to deliver next and focuses the mind on useable software.

At the end of each delivery cycle, or sprint, teams should run aretrospective to review ‘what worked, what could be improved’ in the next sprint.

The software and the team continue to learn through delivery and iterate and improve throughout the project.

Small, agile teams

The unit of delivery is the team

Small teams of between five to ten people are often more productive and predictable than larger teams. Forget man-days and think about the team as the unit of delivery.

A good team includes members with all of the skills necessary to successfully deliver software. A fully-functioning team has three key roles embedded into them, usually full-time:

Product Manager – responsible for delivering return on investment, usually by creating products that users love. The team delivers the Product Manager’s vision.

Delivery Manager (a.k.a. Scrum master or Project Manager) – is the agile expert that is responsible for removing blockers (things slowing a team down). They also usually act as a facilitator at team get togethers.

Team member – Self organising, multi-disciplinary team that delivers prioritised user stories. Responsible for estimation.

You help each other and work together toward delivering your sprint goals. It’s common to encourage team members to pair. It sounds counter-intuitive to have two people work on one thing, but this is not so. Working together closely produces better software solutions, promotes better quality controls and spreads knowledge across the team.

A good team can estimate their output, or velocity, very effectively and consistently. This allows for much more accurate planning.

Fail fast

Failing, so fix it!

Releasing little pieces of code often improves quality and visibility and reduces cost to market, but using agile techniques does not guarantee success. You can still fail! What agile methodologies do allow you to do is to spot problems earlier and resolve them.

Here’s a few examples of how:

  • releasing working software to your users often allows you to get feedback quickly and hear or see what they think. If the product is wrong you can easily change direction and iterate.
  • if your software is rarely released to production you are not demonstrating value to your sponsor. You run the risk of creating a “too-big-to-fail” service that isn’t fit for public consumption but must be released anyway. That means another press headline! Ship! Ship! Ship!
  • if your teams’ velocity is consistently volatile, beyond the initial 4-6 sprints, then this is indicative of something that needs fixing. Perhaps there is hidden complexity or poor estimation.
  • Test Driven Development (writing tests in code before you develop the features) has a wealth of metrics that highlight quality issues early. Establish what these are early on, baseline and monitor throughout the project.

Don’t be afraid to fail or experiment. Learn to fail, and create a culture that learns from failure.

Continuous Planning

Planning session

It’s a myth that you don’t plan on agile projects. The freedom of agile projects does not come free: you have to plan. You just plan differently and continuously.

Agile planning is based as much as possible on solid, historical data, not speculation. The plan must continuously demonstrate its accuracy: nobody on an agile project will take it for granted that the plan is workable.

Typically teams plan together, usually on at least two levels:

  • at the release level, they identify and prioritise the features we must have, and would like to have by the deadline.
  • at the iteration level, they plan for the next features to implement, in priority order. If features are too large to be estimated or delivered within a single iteration, they break them down further.

These plans are usually reviewed after every sprint and adjusted based on “the weather yesterday”, new facts and requirements that will inevitably be uncovered along the way.

Bad smells

Do go here!

Teams new to agile should be wary of these familiar situations and reactions to doing things differently. They have a bad smell about them and undermine your project and its chances of success.

  • Your team is not full time. If your core team of product manager, scrum master, and key members of your multi-disciplinary team are not on the project full-time and spread over many projects then expect difficulties. The team is the unit of delivery and you need focus. Push back on managers and stakeholders if this is happening.
  • You don’t have a dedicated team area. Your team should be sat together, preferably in your own room, with space on the walls to draw ideas and stick up cards and post-its. As the project gets going, consciously ‘hack the environment’ to create a working environment conducive to team working. You might upset a few people and challenge some long-standing working practices. But this is so, so important, and really should not be a big ask.
  • There’s no continuous integration environment. Start right: with a continuous development environment. If your teams are not insisting on this from the outset then you’ve probably got the wrong team. So much about iterative software development is contingent on the ability to continuously deploy and run automated tests as you do.
  • You have a separate QA department. If your team’s attitude to quality is to throw the software they’ve developed over the wall to a QA department, then they’ve not got the right attitude to delivering production-ready software. You need to embed a quality culture into the team.

This is by no means an exhaustive list, but these are most common things to watch out for.

VersionOne – 7th Annual State of Agile Survey

version-one-state-of-agile-7th-2013

Time to jump on it. Find the results here.

Some facts from the 2012 State of Agile Survey include:

  • Those who plan to implement agile for future development projects increased from 59 percent in 2011 to 83 percent in 2012
  • The number of respondents using agile practices across 5 or more teams grew 15% (from 33% in 2011 to 48% in 2012)
  • 35% of respondents worked in a company that had distributed software teams
  • On average, respondents used between three and four different development tools, with a handful having used as many as 15

The seventh annual “State of Agile” survey was conducted between August 9, 2012 and November 1, 2012 and collected responses from 4,048 agile practitioners. Sponsored by VersionOne, respondents were recruited from dozens of software development industry channels. The data was then analyzed and prepared into a summary report by Analysis.Net Research.

Atlanta ScrumMaster Training – Action & Influence Growing the Atlanta Market

In Atlanta, GA news:

Action & influence, Inc. announced today that they are hosting more Certified ScrumMaster (CSM) and Certified Product Owner (CSPO) courses in Atlanta due to increasing demand. As the only company in Georgia to have a local Certified Scrum Trainer, Peter Saddington, they want to bring even more value to the Agile community and local Atlanta companies who want to leverage Agile or Scrum to bring quicker development value to their software and services. Having a local CST gives Georgia companies a great advantage, as their employees can attend local courses without incurring the costs associated with travel. Peter Saddington is one of the 140 Certified Scrum Trainers in the world and about half of them reside in the United States. Peter Saddington is the first CST to reside in the state of Georgia. Saddington says, “Our local clients who are looking towards Agile and Scrum have greatly enjoyed having a local trainer who can service their needs without flying in another trainer from out of state. Most of our clients in Atlanta have private courses for their entire development teams and organization.”

You can quickly find local Atlanta Certified ScrumMaster classes, http://atlantascrummaster2013.eventbrite.com/and sign up as an individual, team, or company.

According to one of Action & Influence’s students, Mike Rucker, who recently took a Certified ScrumMaster course in Atlanta said, “I was very pleased to find a local group that offered such a wide choice in class days and times. It was very easy to find a class that fit within an already busy schedule.”

Other testimonials of Action & Influence, Inc. classes:

“Peter’s mastery of the subject matter coupled with his excellent presentation and communication skills made for an outstanding learning experience.” – Jim Olwine from Atlanta

“Peter REALLY did change my life. He provided such great instruction on Scrum and the duties of a ScrumMaster. He gave lots of clarity on my career direction. Great job!” – Aletha Hill from Atlanta

“VERY INSPIRING. [Peter Saddington] is one of the best instructors I have ever seen in my life.” – Parveen Yadav from Atlanta

“I can honestly say that the ScrumMaster class has changed my view on software development, and breathed welcome fresh air into some tired sails. I am genuinely looking forward to the second half of my career now, with hopes to embody in my work all that Peter laid out in the class and the skill set of a true servant leader in the technical world.” – Mike Rucker from Atlanta

[HT: PRWeb]

Developers Should Outsource Their Job to Other Developers #LOL

A recent article from The Register was frickin’ hilarious. PERIOD. Snippets below:

A security audit of a US critical infrastructure company last year revealed that its star developer had outsourced his own job to a Chinese subcontractor and was spending all his work time playing around on the internet.

The firm’s telecommunications supplier Verizon was called in after the company set up a basic VPN system with two-factor authentication so staff could work at home. The VPN traffic logs showed a regular series of logins to the company’s main server from Shenyang, China, using the credentials of the firm’s top programmer, “Bob”.

“The company’s IT personnel were sure that the issue had to do with some kind of zero day malware that was able to initiate VPN connections from Bob’s desktop workstation via external proxy and then route that VPN traffic to China, only to be routed back to their concentrator,” said Verizon. “Yes, it is a bit of a convoluted theory, and like most convoluted theories, an incorrect one.”

After getting permission to study Bob’s computer habits, Verizon investigators found that he had hired a software consultancy in Shenyang to do his programming work for him, and had FedExed them his two-factor authentication token so they could log into his account. He was paying them a fifth of his six-figure salary to do the work and spent the rest of his time on other activities.

The analysis of his workstation found hundreds of PDF invoices from the Chinese contractors and determined that Bob’s typical work day consisted of:

  • 9:00 a.m. – Arrive and surf Reddit for a couple of hours. Watch cat videos
  • 11:30 a.m. – Take lunch
  • 1:00 p.m. – Ebay time
  • 2:00-ish p.m – Facebook updates, LinkedIn
  • 4:30 p.m. – End-of-day update e-mail to management
  • 5:00 p.m. – Go home

The scheme worked very well for Bob. In his performance assessments by the firm’s human resources department, he was the firm’s top coder for many quarters and was considered expert in C, C++, Perl, Java, Ruby, PHP, and Python.

Further investigation found that the enterprising Bob had actually taken jobs with other firms and had outsourced that work too, netting him hundreds of thousands of dollars in profit as well as lots of time to hang around on internet messaging boards and checking for a new Detective Mittens video.

Bob is no longer employed by the firm.

Value of Certification – Spring Cleaning

certificates-certification-of-completion-throw-away

 

It’s spring cleaning time. Time to clean out the closet and get rid of stuff that is either taking up space, not used, or just not worth keeping around.

I came upon a fully loaded packet of tons of certifications, broken out into 3+1 categories:

  1. Personal Development (3 certs, ranging from Public Speaking to Business Process Improvement)
  2. Software Development (7 certs, ranging from Business Objects to Microsoft stuff)
  3. Software Development Management (7 certs, ranging from PMI-ACP to Scrummy-type stuff)
  4. Undergrad and Graduate Degrees (4 diplomas, CompSci, Counseling, Education, Divinity)

It’s funny. As I’ve accumulated a ton of paper. But it made me think. What’s the value?

In a overly-simplistic view, certification means I’ve done what is necessary to ‘complete’ a set of requirements. 

It could be said that they don’t prove anything. And you would be right. For hiring purposes, they are basically used to filter candidates. But that doesn’t mean they’ll actually be able to do the job (with excellence).

For me, part of my spring cleaning is to continually provide excellent value to my clients and customers. To grow our business to the next level. Certification, at this level, has no real significance.

It felt very good to trash those papers (sans the degrees).

What do your new years resolutions / spring cleaning look like for 2013?

The Friend Disclosure Agreement (FriendDA) – Love it.

notfriendsI believe that any ‘independent consultant’ or type of individual is an entreprenuer. It takes guts, gumption, and desire to go off on your own and build your own brand and take on all the risk. It’s scary and rewarding at the same time. Like driving 140+mph on a motorcycle. It’s scary but thrilling at the same time (not that I’ve ever done that…).

Entrepreneurs also have great ideas… good entrepreneurs share those ideas with others to get feedback. Sometimes though, you need a bit of a Non Disclosure Agreement to keep things kosher. How about a ‘lite’ version?

Found one.

www.friendda.org – Love it. Perfect for using when you have an idea to share with others. Some highlights (italics mine) below:

FriendDA

This agreement is entered into this ___ day of ___ 20__ by and between _____________ (hereinafter “The Advisor”) and _____________ (hereinafter “The Keeper of the Idea” or “I”) regarding information The Keeper of The Idea is choosing to share with The Advisor (hereinafter “The Idea”).

WHEREAS I possess a bright idea that I am choosing to disclose to you, The Advisor, with the mutual understanding that you are my friend and that you will not screw me.

Manners of screwing include, but are not limited to:

  1. Adapting some or all of The Idea for your own purposes.
  2. Choosing to share some or all of The Idea with those who are not bound to this agreement.
  3. Failing to do your best to protect The Idea.

This is a “warm blanket” agreement with which, by requesting your agreement to it, I am helping myself sleep at night by placing a small amount of formality on the sharing of The Idea. I believe The Idea will only improve as a result of having solicited your honest and clear feedback.

Term

The term of this agreement shall continue until The Idea is no longer confidential.

Breach

This agreement has absolutely no legal binding. However, upon breach or violation of the agreement, I will feel free to do any of the following:

  1. Curse you under my breath.
  2. Publicly disclose the manner of your screw-i-tude.
  3. Write about your transgressions in ALL CAPS.
  4. No longer consider you a person with whom I can share my ideas.

Sharing

Sharing of some or all of The Idea with third parties may occur provided that you have cleared this with me and the third parties agree to the principles of the FriendDA.

Termination

Termination of this FriendDA can be executed by either party, but don’t be a douche.

You are acknowledging and agreeing to this disclosure by reading it. If you find any part of this agreement uncomfortable or confusing, don’t sweat it. We’ll talk about something else.

*lol

VersionOne Launches Full Suite of Agile Visualizations in Winter Release

This is pretty interesting stuff. See the video below:

Easy Visualizations Streamline Problem Identification and Collaboration

ATLANTA – January 22, 2013VersionOne, recognized by agile practitioners as the leader in agile project management tools, today launched a comprehensive suite of agile visualizations in its Winter 2013 product release focused on enabling teams to more easily identify problems and collaborate.

“Visualization is becoming increasingly important in better understanding complex relationships.  In the context of agile software development, our suite of visualizations can really help teams understand rapidly changing relationships and dependencies occurring during the software development lifecycle.  With our Winter 2013 release, we’ve taken the next major step in simplifying project collaboration and making sure everyone on the team understands the impact their work is having on the overall program goals,” said Robert Holler, president and CEO of VersionOne. “This makes it much easier for teams to achieve their goals in a more holistic manner.”

VersionOne’s new visualizations help users identify impediments in their agile processes. They make it easier for users to understand and manage complex work item relationships and dependencies. Project dependency diagrams help team members see schedule anomalies, helping them to sequence work within a release. Additional improvements for Enterprise Edition include enhanced cross-project visibility for epics and streamlined epic breakdown, simplifying agile portfolio and program management.

For more information about the Winter 2013 product release, visit here.

Agile 2013 Reading – Agile Estimation at It’s Best

agile-estimation-2013-book-reading

Agile Estimation Like My 2013 Reading Project

I have over 20 books that I need to read (re-read) this year… and I just bought about 7 more (in the mail) that will be hitting my doorstep in the next week. Every year I try to read at least 2 books per month. This year, due to my backlog, I pretty much have my entire reading backlog ready for 2013. While I was putting my book-stack together, something occurred to me… how all this reading… while a good plan… might not get done. And, according to previous experience and history, often it’s not. Sounds like a “failed project” correct? You’re absolutely right. Let’s break it down for a second.

Product Backlog

  • 28 or so books
  • All different sizes and lengths
  • Different material… but some can be grouped into a “theme”
  • The product backlog will change over time (as I add books or even remove book priorities)

Product Goal

  • To complete my total reading of at least 24 books (2 per month) for the year
  • While the goal is set, I know that priorities will change

Planning and Estimation

Let’s be honest for a moment here:

  • I’ve read about 7 of the 28 books or so but I haven’t “recorded” how long it took me to read them (heads down reading)
  • The other books, I have no idea how long it’ll take, with interruptions, flights to catch, quiet hotel nights, etc, etc.
  • I know I need to move towards the goal, but since the majority of the “work” (reading), I’ve never done before, it would be foolish to “estimate” how long it’ll take for each unit (book) of work.
  • I know that I need to just execute. Learn, see how long a book takes, affinity estimate, or compare against other books, inspect, adapt, and review towards the total completion goal.

I know that only through the act of EXECUTION and LEARNING will I truly know or understand my “capacity” for work and ability to complete the work “on time.”

We’re terrible at estimation. You do not “know” because you have never done.

Let me repeat that:

“You do not know (the estimate of anything), because you have not done it (before).”

Consider the massive implications on your work and business:

  1. The business asks you up front for estimates on work you’ve never done before.
  2. You take a guess and hope for the best.

What a terrible existence to have!

We cover this a lot in our workshops and classes, but the main point is: We need to have opportunities to execute, learn, and grow. Only through experience will we be able to better give estimates. Find opportunities to execute, try, and learn. If your company doesn’t allow for experimentation, you will never have innovation.

Have a great kaizen 2013 my friends! Learn learn learn!