Why #athletes make great #Project team members #PMOT #DnD

I was attending a Manitoba Coaches meeting last week we were discussing the topic of Emotional Intelligence in both leaders and teammates. Emotional Intelligence is usually discussed in conjunction with the ‘soft skills’ that people have.

Emotional Intelligence is usually defined as “the capacity to be aware of, control, and express one’s emotions, and to handle interpersonal relationships judiciously and empathetically. ”

There are four fundamental aspects of Emotional Intelligence : Self-Awareness, Self-Management, Social Awareness, and Relationship Management.

Although Emotional Intelligence can be augmented through training and education, there is the acknowledgement that some people have a propensity to have high Emotional Intelligence. The usual Nature/Nurture discussion arose and it was agreed that Emotional Intelligence is usually built through the relationships that people have in their early years.

Epiphany

It was discussed that people who are Emotionally Intelligent are proficient at:

• Collaboration
• Communication
• Accountability
• Independence
• Teamwork
• Leadership
• Problem Solving
• Critical Thinking
• Listening
• Conflict Resolution
• Managing their Emotions

I had an epiphany that team sports is one of the few things that provide consistent, repeated, and evolutionary experiences in most, if not all, of the characteristics listed above that Emotionally Intelligent people excel in. Team mates experience and grow in all of the proficiencies listed above due to the nature of team sports and shared purpose.

In particular, team sports are one of the few activities where peers hold each other accountable, manage conflict, problem solve, manage their emotions, and take turns leading in their own way.

Summary

Team sports are critical not only for physical and mental health, but also project health. Great project team mates have usually been great team mates previously in all sorts of sports.

The lesson? If your children want to be developers, sign them up for Hockey, Baseball, Basketball, and Volleyball. Their future team mates will thank you later.

If they really don’t like sports of any kind, get them to play Dungeons and Dragons. And the computer D&D games don’t count. They need to sit down with friends and learn how to co-operate and deal with looking each other in the eye when they betray or disappoint each other.

That’s accountability – Nerd Style.

Advertisement

My Pride and Joy Project

I came across a blog by Liza Wood on her pride and joy project. You can read her excellent post here.

It made me think about what my pride and joy project would be for me.

I consider myself very lucky to work on the projects I have worked on. I am constantly amazed by the excellent teammates I have been lucky enough to have worked with. I started to list off the projects I have worked on and two projects seemed to set themselves apart:

1) Agile Delivery of a new Parks Reservation Service. You can read about this project here.

2) Providing Data to Investors Group Advisors

Three things

As I reviewed these two projects, there were three things that they both had that made them something that I was very proud of.

1) There was a great challenge that was solved by the team – both projects were difficult and challenging in different ways. And both projects solved those problems through the hard work and dedication of the entire team. And by entire team I mean business and technology teammates together.

2) There was a great amount of learning – both projects required a huge amount of learning. This learning was both for myself and the entire team. These two projects probably resulted in the most advancement of my knowledge throughout my entire career.

3) The people on the project were awesome – This is closely related to the second point, but it deserves a point of its own. The people on these projects taught me so much, but they were also so proficient in what they did that is was a pleasure just to work beside them. There was a sense of camaraderie that we were all there to solve a problem. There were many great memories of late night, laughs, frustrations, and broken builds.

The Project

Ultimately, I choose the project where we provided data to Investors Group Advisors. The project was actually much more than this. It was an entire infrastructure project of rolling out laptops and a download process to 4,500 Financial Advisors. In 1997. 17 years ago….

The project would be less of a challenge today but back in the mid 90’s we were implementing cutting edge technologies. I was on the database team that defined and loaded an Oracle Operational Data Store. I was in charge of a small team that loaded the Oracle database and we worked hand in hand with another small team that extracted the data from Legacy systems. Although there are many toolsets now that can help with these Extract, Transform, and Load processes, the landscape in the 90’s was quite different. So we wrote our own. from scratch. And we had the easy part of the project. The application team that was building the laptop application in Visual Basic was really working on some challenging components…

I chose this project instead of the other one due to one important factor, I developed.

Don’t get me wrong, I love Project Managing. But there is a certain sense of accomplishment and gratification working together with a team and developing software functionality that addresses a business need. I know Project Managers do this as well, but from a distance. The ability to be one of the few that directly authored the solution, was, well awesome.

And that is why the current project I’m working on with be my favourite project once it is implemented. I’m coding again and there is no feeling like it.

 

#Agile Product Management vs. #Agile Project Management

I think the time has come where the Agile proponents (myself included) need to be very clear on whether they are speaking from an Agile Product Management or Agile Project Management point of view. Some of the more controversial posts on Agile Practices seem to be aligned very well with Agile Product Management, but perhaps somewhat less so with Agile Project Management.

How do I define the two?

Agile Product Management : Typically the project team is producing a product. A product can be defined as a solution that either is being sold to multiple clients or has the potential to be sold to multiple clients. The time horizon for the work and decisions are more future thinking and longer term as value is always based on increasing the potential for multiple sales.

Key indicators: Stakeholders include end clients and product company team members that are not part of the development team. There may not be a formal contract or Statement of Work.

Agile Project Management : Typically the project team is producing a solution to address a specified business need and address a business case. Many of the decision may need to be tempered to ensure the project team can make current commitments. Focus is less on future thinking and more on current commitments. (although not totally ignoring the requirement to have the solution to flexible in the future)

Key indicators: Stakeholders include end clients and project team members. There is a formal contract or Statement of Work.

Agile Product Practices

The practices that are somewhat more aligned more with Agile Product Management than Agile Project Management are:

• Minimal documentation outside of User Stories and executable Test Cases
• Absence of formally defined  scope
• Absence of estimation of scope

Although these practices can be minimized or eliminated for Agile Product Management, it is not realistic to expect the same for Agile Project Management. When working with clients on Agile projects, there are certain constraints that clients operate under that may not allow for these Agile Product Practices to be used.

I believe we need to start separating our Agile Practices into the two camps to start to discuss which practices work best in each. If we don’t do this we risk having Agile Product Management that isn’t as Agile as possible, and Agile Project Management which takes on excessive risk by trying to apply practices that may not be the best fit.

My perspective is always more on the Agile Project Management style as that is the circumstance I encounter the most in the engagements I have.