Category Archives: Collaboration

Leave a legacy

Leave_a_Legacy

Have you ever wondered what people are saying about you at your last job?  No, not what your contacts say they are saying about you – but waht is really being said.  Think about it, what did you do, or didn’t do, that would lead people to bring up your name.  In a nutshell, that’s your Job Legacy.

I like to think I’ve left a legacy at each job I’ve been at, some probably more positive than others, but a legacy none-the-less.  To leave a legacy you have do something that is lasting and memorable – something where people will go – “Remember when Tim…”   In the end why do you work?  I know it’s because you need money and benefits and blah, blah, blah…but really if you knew you had to leave your current employer in 24 months – what would you do differently to leave a legacy?

Oh, boy, that changes perspective a little doesn’t it.   If you’re in HR like me – please don’t believe that developing a process, or making a process better, or launching a new system, is going to have you leave a legacy.  People will remember the process or the system – but they won’t remember You.  Also, don’t think making a “big change” like instituting casual friday, or changing your compensation philosophy will work either – the leaders get credit for those things.  Wow – now it becomes a little harder, right?

So, how do you leave a legacy at your job?

Here’s what I think – there are a few ways:

1. Be so damn good – that it causes people pain or fear when you leave.  If a year after you left, people are still calling you for help from your old organization, you left a legacy.  If you think the company can’t go on without you, then you leave and you never hear from them again – you didn’t leave a legacy.

2. Build such strong relationships, that they become life-long professional relationships.  I get calls at least once per year to come work for someone I worked with perviously – not to go back to a company – but to come to a new company a peer or leader I worked with, is now working at.

3. Do something so stupid, it becomes part of the company culture.  I ran a department at one company and had 5 people report to me.  It was a department I started from the ground up, and we ended up saving a very large amount of money for the company.  I told my SVP that my 5 reports all needed more money, or I was going to look for another position.  He said thank you, I’ll take that as your resignation.  I don’t think he really got how negotiating worked! But I’m sure no one at that company has ever pulled that tactic again.

In the end we all choose whether or not to leave a legacy.  I’ve worked with thousands of people who were content not to leave a legacy – but I always tend to be pulled towards those who do want to leave a legacy.  There’s something about people who want to be great at what they do – there like magnets – they pull others to them that also want to be great – and pretty soon you have a pretty great team.

So, you have a choice – what is your legacy going to be?

————————————————————————

Excerpt from Tim Sacket Project

Advertisements

The Shock Therapy according to Scott Downey

The SHOCK THERAPY RECIPE

In order to cut standard Team Discovery or Novice Leadership bootstrapping times by 50% or more, the following steps were used at MySpace when orienting the teams into a proper Scrum posture. These steps can be easily implemented by an experienced coach.

For a novice ScrumMaster, failure to implement these steps will consistently incur the cost of poor velocity and quality. The results here can show the novice ScrumMaster which are the important features of Scrum that must be implemented to guarantee high performance. Novices will have to do their best to convince teams to follow best practices. For teams in this paper, the ScrumMasters had enough experience and management support to enforce the right practices and the leadership capability to get the teams to cooperate.

A. Lay the Foundation

Novice Leadership and Team Discovery approaches at MySpace and Jayway allowed the teams to become distracted by new terminology, roles and artifacts. In the absence of strong, experienced leadership, most teams spent their formative months focused on aspects of the framework rather than on delivering value to the customer. They also under-emphasized or failed to implement critical elements of the Scrum Framework, which sets them up for limited success at best.

These mistakes often led to a measurable initial reduction in value delivery rather than the expected increase that drove the decision to implement Scrum. To avoid this pitfall, the Shock Therapy coach, Scott Downey, fully enforced the complete Scrum Framework for teams described here. Scott found it was critical at the outset that the entire team participate in training so that everyone had the same

understanding of goals, mechanisms, definitions, and responsibilities they will share going forward. Teams in this study have participated in an internally developed Introduction to Scrum course that covers the Twelve Points of Scrum as well as the most impactful environmental factors of the MySpace technical and organizational structures. Until the Scrum Product Owner, Scrum Master, and entire Delivery Team participate in training, no further steps are taken to bootstrap that team.

B. Stabilize the Environment

The legitimate degrees of freedom in the Scrum Framework are often confused with Framework elements themselves. This can lead to accidental, dysfunctional hybrid models. Having a strong, experienced, and empowered coach is critical to getting teams functioning quickly and realizing the benefits of Scrum. To achieve this, the Shock Therapy Coaches at MySpace and Jayway take many of the legitimate degrees of freedom off the table by providing an additional but temporary structure that could be viewed as a “Default Profile” for new teams. Through practice and demonstrated proficiency, teams earn the right to change these Default Profile settings (but never the Scrum Framework).

Before changes in the Default Profile could be made, the teams in this study were required to complete three consecutive, successful Sprints, demonstrate a 240% increase in Velocity, and have a solid business reason to make a change that was agreed to by all team members.

Default Profile rules were applied consistently for the MySpace teams in this paper. At Jayway the same conceptual approach is used with minor variations.

  • Set Sprint Length The Shock Therapy Coach decides Sprint Length. Shorter Sprint lengths are recommended to facilitate more rapid inspect/adapt cycles. All teams in this study used one week Sprints.
  • Set the Definition of Done The Shock Therapy Coach provides an initial definition of Done that should be applicable to 80% of the work the team will pursue. Our initial definition of Done includes, at minimum:
    • Feature Complete
    • Code Complete
    • No Known Defects
    • Approved by the Scrum Product Owner
    • Production Ready

Although approval of delivered work is the domain of the Scrum Product Owner, during the Shock Therapy experience, the Coach must also agree that the work has met the agreed state of completion or s/he, too, can reject the work and direct it back to the Product Backlog.

  1. Strictly Filter User Stories – Only properly formed and supported User Stories are allowed into the Sprint by the Coach. Improperly formed Product Backlog content is rejected by the Coach on the team’s behalf before the Planning Meeting.
  2. Sprint Backlog Items – Sprint Backlog items are accepted at the highest level of granularity that passes the INVEST mnemonic [2]. At no point are cards broken into a list of tasks in pursuit of a task list alone.
  3. Only Estimate in Story Points – Estimation is in Story Points only. No estimates in Hours are ever solicited or tracked, and team members are discouraged from thinking of tasks in terms of time.
  4. A Physical Scrum Board Must Exist – A physical Information Radiator is designed by the Coach and serves as the focus of the daily 15-Minute Stand-Up Meeting. The simplest board with the minimum number of columns is recommended. Teams in this study used boards that displayed only Product Backlog, Sprint Backlog, Work In Progress, and Done. No “Waterfall” columns (e.g. Design, Dev, QA) were allowed. A physical board will be maintained even if software tools are used to provide visibility to remote locations.
  5. Respect for Team Meetings – A penalty for tardiness or unexpected absence from any team meeting is agreed to and enforced by the team. It applies equally to all team members, regardless of rank, role or excuses.
  6. The Sprint Planning Meeting will be 10% – the Sprint Planning Meeting will be 10% of the Sprint length in duration, and will include Sprint Review, Retrospective, Product Backlog Presentation, Estimation and Commitment of the Team.

C. Building Muscle Memory

During the Sprint, the Coach needs a singular focus on adherence to the Scrum Framework and Default Profile rules. It is best that s/he not be distracted by feelings of ownership over either the Product or the code. S/He must prevent multi-tasking, enforce working in priority order, encourage collaboration on the highest priority, and maintain the Scrum Board until the Team takes these things over, which usually happens naturally in the first several Sprints.

The Coach must constantly explain both rules and rationale used to derive advice or correction. As an example, when a lower priority card completes and the team member asks for more work, the Coach should not just advice, “Take the top item from the Product Backlog.” Rather, s/he should step them through the logic. “Can you help expedite any card that is already in progress? If not, can you work on any of the committed cards that are not yet started? If not, is there a better way to redistribute work across the team based on your availability right now? If not, retrieve the highest priority item from the Product Backlog and commit only to as much as can be completed by the end of the Sprint.”

It is important to engage the team in problem solving rather than always solving the problems yourself, as a Shock Therapy Coach. When the Coach notices someone multitasking, a team member not paying attention during the meeting, an Information Radiator that is not moving properly, or any other systemic or behavioral sub-optimizations, s/he should ask the team if they notice anything happening that should not be happening. Ask them to find and correct the defects and be available to help them if they begin to fail.

D. Seek Your Exit

At no point during Shock Therapy can the Coach become personally involved or vital to the team’s success beyond the bootstrapping experience. The Coach must not take on any fundamental tasks or fill in for any missing team members. It is critical to remember that the purpose of a Coach is to create self-sufficiency within the team. S/he must not become a foundational element of it and should seek to relinquish authority, leadership, and artifacts as soon as the team demonstrates an ability to absorb them.

Re-establishing Communication on a Stalled Project

Five Steps to Success

Any study on project failure will list poor stakeholder communication as one of the top three reasons for a project’s demise. This brief case study discusses the steps I took to revive project stakeholder communications and move a group of stakeholders from intense distrust to frequent (and pleasant) collaboration.

Background: This web application redesign project for the military had petered to a low level grind, characterized by tersely worded emails, accusations and entrenched opinions. Project status meetings were held monthly, and sometimes skipped. There were no other recurring communications.Following please find key steps I used to shift this group to collaboration.

Step 1: Perform a Gap Analysis on As-is and Should-be Communications

The PMBOK version 4 now includes a Stakeholder Management Plan, which should be used by every PM. Many of us PMs were already doing something similar with the communication plan. The key here is to recognize that the PMBOK does have tools that, when used, will actually help you. I used the Communication Matrix and RACI chart to scope out all the stakeholders Just the process of interviewing stakeholders to fill in the RACI chart surfaced mis-conceptions about roles and responsibilities that proved to be the source of many an argument.

Step 2: Use Your Ability to be Impartial as Long as You Can

When you are a brand new PM on a contentious project, you have a window of opportunity in which you are perceived as impartial; you just haven’t had time to form opinions yet. Use this time to your advantage. I decided to talk to the customer, the armed forces personnel, first. I wanted to understand how they perceived my team before my team could influence me. I knew from my stakeholder review in Step 1 that their experience with each other was based on the lack of clear role definition from the start. I also used this time to clearly understand the client’s perspective on scope, time and cost.

Step 3: Establish Credibility by Responding to Your Action items Right Away

After my initial set of meetings with stakeholders, I came away with a list of action items. These became my priority. In an environment where trust has been broken, it takes many demonstrations, over time, to regain trust. But you can start off on the right foot by simply responding quickly. Distribute meetings notes right away, do what you say you’re going to do, but do it sooner than expected. If you can’t do it, communicate why and explain when you can.

Step 4: Set up Recurring Meetings Right Away

The first thing stakeholders are going to do when they stop trusting each other is to stop meeting. My job as PM was to get them back in the same room again, stay calm and not take sides. The first few meetings were not stellar. But, I knew that the point is that they actually get face time, even begrudgingly, on a recurring basis.

Step 5: Don’t Get Sucked into the Vortex

In stalled projects, people can behave badly. They will say things that are hurtful and don’t move things forward. Many times I made the conscious choice not to get sucked in. I knew that it took history for negative feelings to develop, and I didn’t have that history. As the new person, I had to be impartial and mature – at times it was a huge struggle to do so. When problems do surface, focus on the problem, not the people. Shift the group to problem analysis, not people analysis.

Result: Within six months of recurring meetings, reestablishment of credibility, slowly introducing proper roles and responsibilities and keeping my mouth shut when I wanted to scream, this group of about 20 armed forces personnel, civilians, and contractors have become re-energized, meeting weekly for a Change Control Board that is effective and collaborative.


The author Michiko Diby is a collaborative, goal-oriented professional with an excellent track record of leading projects in both the public and private sector. Ms. Diby is Principal with SeaLight, LLC www.sealightllc.com a consulting firm she founded to provide project conflict resolution services. She is a leader in the Washington, DC Project Management community, serving as PM for the 2007-2009 International Project Management Day, and 2008 AVP for Community Outreach. She holds a Project Management Professional credential (PMP) and a MS in Conflict Resolution. Ms. Diby can be reached at mdiby@sealightllc.com

Tips on Running your meetings

Establish Meetings to track your deliverables (requirements, tasks, etc…)

Prioritize and put your agenda as visible as possible (Send your agenda prior to the meeting)

Suggested weekly meeting or Monitoring:

  • Mondays – Checkpoint Meeting (what are the requirements that your team would be delivering for the week)
  • Tuesday to Thursday – if there are issues and concerns that team wants to raise, use this window; let your team resolve what was raised during the meeting. EMPOWER them to think and be a problem solver.
  • Fridays – Status Reporting based on the deliverable requirements for the week

Make your meetings short and fun.  Dont just dwell on the teams deliverables.

Talk to them and make the meetings light.

Standup Meetings

Implementing standup meetings or in scrum – daily scrum meetings should be not be too serious about the roles of its participants in the chicken and pig roles because if your team falls under this misconception then you become a slave of the concept.

Remember collaboration is a key.

The Scrum Master should be master of your of interaction – he/she must be sensitive and listen to his team.

The team should know what to do after each daily scrum meetings. PDCA is key – Plan/Do/Check/Act.

Macro Management in SCRUM

Still I cannot get over it…. yesterday I was able to finish the training for SCRUM Master but it just keep rubbing in.  It seems that the trainors of SCRUM is saying to me that SCRUM is the only methodology that practices MACRO Management in a project.

If in any case you are a project manager in any industry may it be IT, Software, Hardware, Construction, etc…. this is a trait of a good project manager if one would macro manage and still knows what is being done by your teammates.  A good project manager is not just command and control but he listens a lot.

I have been in the IT industry for quite some time now and I believe that a PM or any lead should have the following traits:

  • A good listener
  • is Proactive
  • inspire a shared vision
  • provides Win-Win Solution
  • has the trait of a problem solver
  • has team building skills
  • can influence people even if he has no title
  • has the ability to delegate tasks
  • is cool under pressure
  • has self-mastery on what he/she do
  • has integrity
  • and a good communicator