Tag: Team

Delegation is one of the most important skills. Business analyst team leaders and other technical professionals, managers, and executives all need to develop good delegation skills. There are many rules and techniques that help people to delegate. Good delegation saves money and time, builds people and team skills, grooms successors and motivates people, and leads to successful projects. Poor delegation sucks! Ask any employee. It causes frustration, demotivates and confuses people and teams. It is important to develop good delegation skills.

These 12 rules of delegation should help you out.

1. Delegation is a two-way street. That’s right! Delegation is meant to develop you and the people you work with. Consider what you are delegating and why you are delegating it. Are you delegating to build people, get rid of work you don’t like to do or to create an effective team?
2. To be a good delegator you need to let go. You can’t control everything so let go and trust the people you work with. Hand over those tasks to other people that are stopping you from reaching your full potential.
3. Create a delegation plan. Use a delegation matrix that shows your people and the main task components and how you can develop your people and get the work done. This will help your people understand the expectations being set.
4. Define the tasks that must be done. Make sure that the task can be delegated and is suitable to be delegated. Some things you have to do and others can be done by someone else. Be clear on what the task is and is not. People like clarity when being delegated to. So ensure you are clear. If you are not clear your people will not be and you will be disappointed. Worst, your people will feel like failures. Not cool!
5. Select and assign the individual who should take on the task. Be clear on your reasons for delegating the task to that person. Be honest with yourself. Make sure you answer the question what are they going to get out of it and what are you going to get out of it? Think of it as listening to the radio station WII-FM (what’s in it for them). It’s a good motivator.
6. Make sure you consider ability and training needs. The importance of the task may need to be defined. Can the people you’re considering do the task? Do they understand what needs to be done? If not, you can’t delegate it to them. If resources are an issue, sit your team down and move things around or develop a mentoring-support program that enables your people.
7. Clearly explain the reason for the task or work that must be done. Discuss why the job is being delegated and how it fits into the scheme of things. Don’t be afraid to negotiate points that are discussed when appropriate. Don’t say it is because we are told to do it. For your people to own the task you must own the task. Reframe and rephrase it so you have ownership.
8. State the required outcomes and results. Answer questions like what must be achieved, what the measurements will be, and clarify how you intend to decide that the job was successfully done.
9. Be prepared to discuss the required resources with the individual and team. Common challenges arise with every person and team including people, location, time, equipment, materials and money. These are important concerns and should be discussed and solved creatively. However, sometimes it is simply as it must be done. Be prepared.
10. Get agreement on timeline and deadlines. Include a status reporting feature to ensure things are getting done. When is the job to be done? What are the ongoing operational duties? What is the status report date and how is it due? Make sure you confirm an understanding of all the previous items. Ask for a summary in their words. Look for reassurance that the task can be done. Address any gaps and reinforce your belief in the individuals or teams work. They need to know you trust them.
11. Remember the two way street, well it is most likely a multi-directional intersection. Look around and support and communicate. Speak to those people who need to know what is going on. Check your stakeholders list and make sure you inform them what the individuals’ or team’s responsibility is. Do not leave it up to the individual team member. Keep politics, the task profile and importance in mind.
12. Provide and get feedback for team members. It is important that you let people know how they are doing and if they are achieving their aim. Don’t get into blame-storming. You must absorb the consequences of failure, create an environment where failure is an opportunity to learn and grow and pass on the credit for success. Pay it forward if you can.

Delegation used as a tool develops you and your people. The better you are at delegation the better the people around you and your teams will do. It is part of command skills and should be used to let go and trust in your people. The difference between success and failure is often a matter of letting go and delegating.

Don’t forget to leave your comments below

Richard Lannon works with those people, organizations and enterprises that want to identify what’s important, establish direction and build business skills that will positively impact their bottom line. He can be reached at [email protected], 1-866-559-8126, www.braveworld.ca

In my last post I discussed two misconceptions related to user stories. First was the notion that user stories are static artifacts and the second was that they stand-alone in representing the nuance of requirements. Both of these views are false. In this month’s post, I want to wrap up with two more misconceptions. One is that only a customer surrogate or product owner can write them. The other is underestimating the power of the acceptance tests as a clarifying vehicle for the story.

Anyone on the Team Can (and Should) Create and Update User Stories!

I’ve seen the position of “only the product wner can write stories” taken time after time when I’m coaching agile teams. I’ll enter a Sprint Planning session and we’ll look at the Product Backlog. The team will complain about the backlog not being detailed enough or containing the ‘right’ set of stories. We’ll spend literally hours reviewing them and debating their intent until we run out of time in our time-box and need to reschedule the planning session.

Inevitably these teams point to the Product Owner as being the problem-complaining that they were not prepared.

As an agile coach I always challenge the entire team in these situations. It’s every team member’s responsibility and privilege to write and refine the stories on their product backlog. You see, user stories don’t simply capture ‘requirements’. Instead, they capture all work (let me repeat that) all work that will be undertaken by the team in order to meet the business’s expectations for the project.

Given this, it’s no wonder the product owner (or BA) can’t fill in a complete set of stories. Nor do they have the functional expertise that the team has in areas of software analysis and design, or development, or testing, or converging a product for customer use.

The user stories must be truly owned by the entire agile team. Sure, the product owner will probably spend significant time writing, refining, and ordering them. But consider that to be simply a “seeding pattern”. The stories aren’t truly complete until the team has iteratively refined them together. In Scrum and oft used term for this is – Grooming the Backlog. This is where the team gathers, either as a group or individually, and refines the stories encompassing the backlog.

Underestimating the Power of Acceptance Tests

Much of the focus of writing user stories is on the story-side or behavior-side of the card. Often there is little to no investment in developing acceptance tests (Confirmations) that are placed on the back of the card.

Why is that? My view is that defining test cases is hard for most teams to grasp. It’s sort of an afterthought and not everyone gets the intent or power of acceptance tests. I consider them more important than the user story description, and here are some helpful ways to view them:

• Consider them mini-UAT tests at a story or feature level
• They confirm Sprint Done-Ness from the perspective of the customer and the tester
• They enable testers and BAs on the team to quantify key conditions that the software must meet
• They drive the design and capability of the software; consider them defining the business logic for a story
• They are a collaboration driver between developer(s), tester(s), BA(s), and product owner
• They are either working or not; there is no in-between

There’s quite a bit of debate surrounding how many acceptance tests should be defined for each story. Certainly, they are not intended to exhaustively test the story-so they are not a complete list of test cases. I usually recommend somewhere between three and seven acceptance tests per story as determined by the team. One or two is certainly too few, and 25 clearly too many.

There is also debate surrounding how to phrase the acceptance tests. I’ve seen the following patterns for them across teams’ I’ve been coaching:

• Verify that…”some behavior”
• Confirm that…”again some behavior”
• If I do this…this results
• Under these preconditions, confirm that…”some behavior”

What’s important here, truly important, is not the phrasing, but that you define and confirm acceptance tests on a story by story basis. It drives quality collaboration and quality results within your agile teams.

Wrapping up – I hope I’ve clarified these four misconceptions and ultimately improved your user story writing.

Don’t forget to leave your comments below

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].

There are lots of different types of intelligence. Components can include such things as understanding, learning, use of language, creativity, emotional, and many others. This decade’s intelligence emphasis is cultural. Understanding different cultures is something I’ve always been interested in, but I’m not sure I always exhibited an abundance of cultural intelligence.

Years ago I lived in a South American country, far from my American home. When I first arrived, neighbors brought me welcoming treats ranging from a single mango to elaborate desserts in fancy dishes. After removing the treat, I would wash the plate and return it. Finally someone told me that it was rude to return an empty plate. The custom was to place a return treat on the clean plate. Completely unaware of this custom, I had unintentionally offended my kindly neighbors.

PMs and BAs usually understand that working with team members from different cultures presents unique challenges. Many of us completely oblivious to a particular custom, find that we have inadvertently offended someone on the team. I once managed a project that included several foreign team members working on the software development phase of a large project. I remember reacting with surprise when a team member told me that in her country she kissed her father-in-law’s feet whenever she greeted him. She explained that in her culture this was a sign of respect. This action, which seemed so different from anything I had ever experienced, was the norm for her.

On the same project, another developer rarely completed his assigned tasks on time. When I met with him in a conference room and asked about the missed deadlines, he refused to offer an explanation. During the meeting he appeared uncomfortable, but remained silent. I had mistakenly thought that team members would complete their assigned tasks. It never occurred to me that in some cultures work is completed based on relationships, not simply because the tasks appear on a Gantt chart. I later learned that the conference room meeting had been highly threatening to him, and that he was uncomfortable reporting to a woman.

Culture clashes can occur not just between people of different countries. As a manager I frequently noted what I called the “second company syndrome.” Candidates’ resumes often showed long tenure at the first company worked and a far shorter one at the second. When asked, candidates often said that they couldn’t get used to their new organizations. I heard things like the new organization had “too much process,” or “things were so chaotic,” or “they’re so unfriendly. No one goes out to lunch together,” or “everyone expects me to go out to lunch with them when I really want to eat at my desk and get some work done.”

There are even cultural clashes between business units within the same organization. I’ve worked in organizations where “users” clashed with IT and vice versa. In one organization I heard statements like “I’m surprised the elevator doesn’t automatically stop on the IT floor because of all the polyester worn there.” Or “those dumb users-they don’t know how to define their requirements.” I think it’s important to recognize that there are no “rights” or “wrongs.” Although we tend to view “our way as the right way,” we need to keep in mind that our ethnocentric perspectives can not only cause bad feelings, but can also hinder our ability to get the necessary work accomplished.

So what is ethnocentrism? It’s the “my way is the right way” attitude. It’s applying negative judgment to the way others live, work, and worship. We can recognize ethnocentrism when we hear phrases like, “How weird!” or “How can these people live like that! ” It’s feeling that one’s norms are superior to others.” “At my old company we used to write use cases” implies that writing use cases is the best way to discover and document requirements.” Or, “our systems were implemented almost without defects at my old company.” Or, “on my previous team we used to bring treats on Fridays. I don’t know what’s wrong with this new team-they never seem to want to have any fun.”

Related to ethnocentrism is culture shock, which is what happens to most of us when we live abroad for an extended period of time. The cultural differences become so overwhelming that we can become disoriented and distressed. We can’t wait to return home to what we view as “normal.” I believe that another team member experienced culture shock when she expressed surprise to learn that it is not uncommon for American parents to hug their children. She noted that Americans seemed so cold to her that she couldn’t image them expressing affection to one another.

I find it helpful to remember that new team members (from other countries, regions, organizations, or teams) may experience culture shock to a greater or lesser degree. They may miss their families, the camaraderie of previous teams, the HR policies of a previous company, or the weather, scenery, and customs of their home country. I have had team members experience culture shock on my team, but I didn’t always recognize it. I sometimes made the mistake of taking their distress personally. My tendency was to withdraw, when exactly the opposite was needed. However, I learned that rarely can we go wrong when we go out of our way to build relationships, listen, and offer support when working with team members from other cultures.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]