Business Analysts, Public review of BABOK Guide Version 3 open!!

business-analysis-babok-version-3

International institute of Business Analysis (IIBA) today announced the public review of Business Analysis Body of Knowledge (BABOK) Guide version 3 (V3) is open until July, 11th 2014.

Business Analysis experts, practitioners and enthusiasts from across the world participated in creating the updated version. Many of these individuals volunteered there time to shape the future of business analysis profession.

It takes a great deal of commitment, experience and patience for such efforts to go from concept, planning, initiation to making it open to Public review.

I have experience in such a globally distributed effort for Project Management Institute’s (PMI), PMBoK Guide 5th edition project and have high respect for members contributing to make a difference to their profession.

If you are involved with profession of business analysis or know someone on your team (regardless of being an IIBA member), I suggest to get involved:

1. Further your knowledge of Business analysis
2. Use your experience to validate or refine the content
3. Gain knowledge from the experts by just reading through the BABOK

All details regarding the effort are at:
http://www.iiba.org/babok-guide-v3-public-review/index.html

After all volunteering is rewarding experience, personally and professionally. I am sure current IIBA members can gain some continuing education benefits!!

Being an Agile Coach – Making Effective Decisions

change-ownership-agile-decisionsMAKING EFFECTIVE DECISIONS

Decision-Making is obviously one of the major functions of the Agile coaching process.

Myths of Decision-Making:

  1. The higher up the decision is made the better it is. So, if the President makes the decision it is obviously a better decision than a decision made by a Vice-President. This is not better because we will be moving back to centralization where one person dominates everything. Decisions tend to naturally go up the organizational chart eventually anyway.
  1. The longer we consider a decision the better the decision will be. This is not always the case. But decisions can grow stale and stagnate if dwelt upon too long. The more complex the issue, though, typically more time needs to be allotted… not to think… but to experiment!
  1. A good decision made late is better than a mediocre decision made early. A decision that will really benefit a team needs to be made early rather then last minute. Precious time is often wasted in the lollygag scenario. Time factors often dictate that a decision must be made. And even if the best decision is not made, at least a decision was made in time.

Causes of Ineffective Decision-Making:

  1. The lack of clearly-defined goals and objectives. People don’t act because they don’t know which direction to go. Decisions can’t be made to do things that haven’t been previously decided to do.
  1. Insecurity of position or authority. Decisions are postponed because the leader  is afraid of the possible consequences.
  1. Lack of information – no alternative seems clear OR all alternatives seem viable.
  1. Desire to retain the status quo or simple fear of change – there is comfort in the comfort zone. But still, because things change and the team needs to develop and change as the market changes.

The Problem-Solving Process of Decision-Making:

Decisions are made, typically, to solve problems:

  1. The orientation to the situation – we get familiar with the background of the problem. Analysis, experience, training, skill, and administrative intuition are helpful in determining the truth of the situation.
  1. The identification of key facts – we will never have all the facts but we can get the facts that truly identify the reality. Utilize effective questioning. We want to ask “open” questions that will give us information rather than a simple yes or no. Carefully sift through the information and deduce logically
  1. The identification of the major problems in the situation: Look for the causes of the effect that have been seen or demonstrated. Why are things happening the way they are? What caused this issue? Again, carefully sift through the information and deduce logically. Get insights from others who can give information from another perspective.

Often, the unique situation you are in requires you to do a lot more research and problems solving to help leaders make good decisions… At the end of the day though, I would suggest, always taking an empirical approach. Experimentation is key. The more you experiment… the more you can learn quickly!

Being an Agile Coach – Dealing with Conflict

conflict-agile-fingers-pointing

The word “conflict” tends to stir up emotions in corporate America. Few companies want to find themselves in conflict. Most employees will view conflict as a bad thing and something to be avoided at all costs. But some conflict can actually be healthy. The reality is that disagreements do not have to turn into fights. We can keep our differences in check if we have a few basic understandings regarding conflict. Conflict occurs when two or more people with mutually exclusive viewpoints attempt to solve a problem.

Two kinds of Conflict (healthy and unhealthy)

Conflict is unhealthy when it negatively impacts the company or team by hindering or limiting their ability to do productive work.

Conflict is healthy when the opposite occurs. When conflict is viewed and handled appropriately.

We know conflict is unhealthy when:

  • People no longer calculate their remarks to edify or change others. Instead, they plan their remarks (often unconsciously) to hurt, demean, defame, or even destroy another
  • People begin to question whether their relationships can weather the storm of difference
  • People feel rejected by those who were once considered friends
  • People feel they have no control and the odds are against them
  • The pain of the competition is greater than the exhilaration of the challenge
  • People make accusations, and it seems that “others” want to destroy or split relationships down the middle.
  • People use words that have violent connotations

Conflict is healthy when:

  • The people involved feel confident they can manage the differences
  • Those involved adhere to firmly to decision-making processes authorized by the team and working agreements of the company
  • People operate within the specifically stated, generally understood rules of appropriate behavior in the company
  • People cooperate in the process suggested by the leadership

Reactions to conflict

  • Conflict is wrong.

Some individuals believe that conflict is always wrong. The mindset is that people in a copmany should be in agreement and live in harmony. They become nervous when team members express differences of opinion. They “lovingly” try to encourage people into one opinion. The attitude does not acknowledge that legitimate differences can exist among different people.

  • Conflict is an opportunity to exercise power.

Some people view any discussion as debate and any issue as a time to win at any cost. These people get their thrills in the competition of the moment. Winning the issue is oftentimes far more important than the issue itself.

  • Apathy (this doesn’t involve me)

Some people do not care much about the outcome of the issues involved. The apathetic spirit comes from several sources including burnout, fatigue, stress, a defeated spirit, or a different set of priorities.

  • Personal affect (this does involve me)

Some people do have a considerable stake in the outcome. These often include the leader, staff, board members, managers, and other directly involved individuals. People often believe that the outcome will affect their reputation and/or their feelings of self-worth. Oftentimes the emotional involvement clouds an individual’s reasoning and judgment surrounding an issue.

  • Conflict might split a company

Some people become nervous when any disagreement occurs in a company or team because they believe it will divide the team needlessly. These individuals many have vulnerable feelings left from past conflict that was handled in a hurtful way. Whatever the reason, they tend to sweep all controversial issues under the rug and hope they go away. They would rather stay in a bad situation than risk the unknown.

Responses to Conflict Continue reading “Being an Agile Coach – Dealing with Conflict”

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

User Stories – Tackling team commitment through “leftovers”

Happy New Year @gile$cout readers!

Be it teams new to Scrum or ones that have been practicing scrum for a while, one of the common problems they face is: User stories carrying over multiple time boxes (sprints/iterations). The team simply can NOT finish the story and it drags on..and on..sprint after sprint.

As a member of ever growing agile community, I am subscribed to many discussion groups. Recently, one such discussion Can’t get to done, roll-over every sprint on Scrum Alliance Google Group caught my attention.

Leftovers-SADiscussion

The origin of the problem can be at many places like: Ambiguous requirement(s)/stories, Stories not sliced enough, Business owner/PO availability, Technical road block, Team member availability etc. One of the common cause is “over commitment”.  I’d like to share my recent experience about this specific problem and how I was able to address it.

Setting: Most of the team members were new to scrum/agile. 3 Sprints into the product development, our team was continuously moving more than a couple of user stories from sprint to sprint. Apart from the obvious problem of inexperience with user story creation and splitting, there was a zest in team which was leading to over commitment.

Having failed to try and discuss that problem in retrospectives, I had to wait for around 3 sprints to validate my assumption. (Yes, we progressed into creating better stories and got a little better at slicing them). After 3 sprints, I decided to try something different – I created a new backlog item “Spillover” stories for the next sprint. Since Thanksgiving was approaching people started talking about Turkey dinners and thus the “leftover” turkey sandwiches and all sorts of leftover recipe discussions were making rounds in office and internet. That inspired me to use the term “Leftover” stories.

At every daily standup, we would discuss about the “Leftovers”. And as it happens in every household, there came a day when the team got bored with leftovers. One of our developers broke the silence saying, “..I don’t like the term leftover/spillover you are using..”. The developer was concerned that the task board was not doing justice to the status of work completed in that story. That was the opportunity, I was waiting for.

We agreed to finish the standup and then discuss the issue. With everyone from the team present there, we looked at the stories, work history, capacity of every team member and turned the discussion into a retrospective. Everyone agreed that we had gotten better at describing the user stories, creating supporting documents/design/User interface. The team then realized given the time box, we were biting more than we can chew. For the first 3 iterations, we all were ignoring the fact as the team was forming, storming. It WAS a team commitment (or “lack of” to say NO to the product owner) issue.

This experience touched many aspects of the team’s operation, but mainly addressed the commitment issues. We do have some scrum certified team members but until we practice, fail, inspect-adapt and repeat the cycle, we are not being true to agile values and principles. It was a wonderful experience for me and the team and we all have made adjustments since then.

Many other scrum/agile experts offered excellent advice/response to that thread on Scrum Alliance Google group. I shared this story very briefly. I was delighted to see @RonJeffries responding to my response on the group as “Nice!” Made my day! [blackbirdpie url=”https://twitter.com/RonJeffries/status/268815166001532929″]

http://xprogramming.com/index.php

[blackbirdpie url=”https://twitter.com/Bendre/status/268790235276652544″]

Thanks to @WoodyZuill for encouraging me to create this post out of a twitter conversation! [blackbirdpie url=”https://twitter.com/WoodyZuill/status/282132950387138560″]

If it helps, here are some of my User Story related valuable reads. I know it’s time to update that list! I am eager to hear your comments and stories.

Becoming a Certified Scrum Trainer – CST

[I was recently asked what my journey to become a CST was like. So like an Agile blogger, I told them to wait for it to post on AgileScout.com 🙂 ]

The path to becoming a Certified Scrum Trainer (CST) is one of the most arduous yet rewarding experiences I have ever gone through (and I spent 7 years in Master’s programs!). It has not only stretched me, but brought about a greater understanding of “mastery” of a craft, that, no matter how good you ‘think’ you become at something, you can always improve, become better, learn more, and grow as a person.

The day you stop learning is day you become ineffective in your work.

My CST Journey

I began my journey to becoming a Certified Scrum Trainer back in early 2009 when I began my investigation into the process and started collaborating with other CST’s about co-training opportunities. This was a time when the CST application process was evolving (and still is) and the requirements and application process wasn’t fully fleshed out. I, at the time, had been in my 8th year as an independent Enterprise Agile Coach and felt like the CST was the right way to go. I had completed my Certified ScrumMaster designation and my Certified Scrum Professional designation previously.

In early 2009 I had my first co-training opportunity with a fellow Agile coach. They went very well. I was stoked. I was excited. I had gotten a great review and was given priceless advice on how to become better. I felt like the CST was fast becoming a reality. I flew out to meet my 2nd co-trainer and we trained together. Another great workshop. I felt great… Then:

  • Client work picked up.
  • Timing just wasn’t working out.
  • Work-life balance just wasn’t what it used to be.

A full year later, I still had yet to co-train with other coaches and trainers. My client list was full, my schedule was so tight that it became apparent to me that I may not be able to finish this race due to scheduling conflicts and overall timing not to mention funding from the CFO of my house (wife). I was burnt out, tired, and a bit frustrated.

It was all about the timing. It just didn’t seem to work. So what did I do? I made the tough choice to lighten my client load (OUCH! SCARY!) so I could open up opportunities to co-train. I made the time available, I reached out to friends and fellow Agile coaches for time slots, and I invited Agile coaches to come train with me at my client sites. I patiently prayed that the opportunities would come… and they did.

After a full 3.5 years I completed it… The road to becoming an official CST was complete… but the journey forward has just begun. YES!

[Peter Saddington Training on ScrumMaster Roles]

On Co-Training Continue reading “Becoming a Certified Scrum Trainer – CST”

Getting back online: Agile, PMI, Volunteering and Me

*** Disclaimer: I am an active volunteer with PMI’s Agile Community of Practice as one of the 5 official leads. Views expressed here (and related future posts) are my own and not an endorsement by Project Management Institute ® (PMI) or Agile Community of Practice (CoP) leadership team.***

If you know me, I have been pretty active (as a volunteer, lead and contributor) in PMI + Agile space. I volunteer as:

  • PMBOK® Guide 5th edition – contributor (engagement just wrapped up)
  • PMI Atlanta Agile Interest group – Program Manager for Agile Interest Group
  • PMI Agile CoP – Knowledge Management lead

These opportunities have allowed me to connect with lots of people – amazingly talented, some famous agilists, practitioners and gurus. There’s a common thing we all share – desire to learn coupled with the passion to share!

I have learnt a lot, have actually got hands on experience (tools, technology, principles, practices etc.),  mentored a lot of people and I am still enjoying the journey!

What do we share? Knowledge. Of course about Agile, primarily.

I have seen a lot of questions that follow an agile presentation or discussion, ranging from:

  • What is Agile?
  • Where do I start? (There are so many places to start with)
  • What is different at Agile CoP? (from other valuable sites, groups and resources)
  • What does a Project Manager do in Agile projects?
  • What is PMI’s – Agile Certified Professional (PMI-ACP®)  certification? Is it for me?
  • Whom do we trust as good training companies?
  • What are good books, blogs, sites to start/continue building my knowledge about agile?

and many such questions. Continue reading “Getting back online: Agile, PMI, Volunteering and Me”