#leadership by not swearing


It is one of those terms that there are a million different interpretations for. Similar to quality. For me, Leadership has always come down to five main abilities. Rather than me describe them, here are five quotes that I feel capture the essence of the five abilities.

1) Ability to Inspire

If your actions inspire others to dream more, learn more, do more and become more, you are a leader.

2) Diplomacy

Diplomacy is more than saying or doing the right things at the right time, it is avoiding saying or doing the wrong things at any time.

3) Ability to always remain calm in the face of pressure

In a controversy, the instant we feel anger, we have already ceased striving for truth and have begun striving for ourselves

4) Courage to listen and accommodate

Courage is what it takes to stand up and speak; courage is also what it takes to sit down and listen.

5) Ability to create a Shared Vision of success and influencing the team to travel there together. Never directing or telling.

If you want to build a ship, don’t drum up people together to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea

Why am I mentioning this?

In Canada, there has been two recent occurrences of politicians using profanity recently. Some people have spoken out against this while others have respected their ‘passion’ and how they respect leaders with ‘passion’. I feel we must be careful to not confuse a lack of decorum, control, and restraint with passion. The ends do not justify the means. Just because we believe our cause to be noble, does not allow us to use any means necessary to be used to achieve it.

One more thing

One thing not mentioned previously about leadership is the commitment to the team. Besides the Shared Vision of success, I feel leaders also nurture a Shared Vision of the team. They nurture individual and team growth as the team creates the solution. At the end of it, the team has created a solution and a greater team.

In a controversy, the instant we feel anger, we have already ceased striving for truth and have begun striving for ourselves

As leaders, if we let ourselves be angry we have essentially put ourselves in front of the team. And the truth.


Agile Project Estimate Guarantee

Over the last few days I’ve noticed more discussion around the concepts on whether Agile teams should estimate or not. This includes my latest Blog on the subject:

User Story Points versus User Story Hours

Yesterday I read the following Blog post on the 5 reasons you should stop estimating User Stories:

5 Reasons why you should stop estimating

Given the amount of attention this blog has garnered, I felt I needed to provide an opposing viewpoint. The Blog post was very interesting and compelled me to write as I think these discussion points are missing one crucial factor. To summarize, the blog post proposed that these were the 5 reasons why we should stop estimating User Stories:

1)      Estimating User Stories is a waste and the time can be better spent elsewhere

2)      The estimates will be used for blame and cause the team to focus solely on the deadline

3)      Don’t give estimates as these are promises that are hard to keep. In the end they are going to be incorrect anyway.

4)      Don’t put additional pressure on the development team and cause them to compromise quality to make the deadline. (similar to #2)

5)      The estimates may cause a shift in the project’s priorities due to the fear and uncertainty of large items.

What struck me was what was missing from these reasons for not estimating, namely the client. None of the reasons explained why estimating User Stories created less value for the client. And really isn’t that why the project exists?

Estimates, who gets to decide?

The Client does. Sometimes when reading about Agile principles, I fear we are losing that perspective and we are deciding for the client what has value. The reason I believe in Lean so profoundly is that it provides the focus on why we are doing Agile practices. It helps to ensure that we understand the why of what we are doing at all times.

Let’s review the Blog points:

1) Estimating User Stories is a waste and the time can be better spent elsewhere

Whether estimating is a waste is something that only the client can best decide. Estimating is just another project activity that the client will determine if it is required.

So far every client I have worked with have required estimates at some level or another. Whether or not we think the time is best spent elsewhere is immaterial. The client defines value and the value in their value stream. So far, every client I have worked with has found value in estimates as they need to decide whether the initiative satisfies the business case and whether they can acquire the required budget.

2)  The estimates will be used for blame and cause the team to focus solely on the deadline

The fact that estimates can be or may be used for blame is more a comment on a dysfunctional system than a comment on estimates. If estimates can be used in this manner, I would imagine any other deliverable could also be used in this manner. I believe it is the role of a good project leadership team to ensure this doesn’t happen. Not producing estimates is treating a symptom, not the problem.

3) Don’t give estimates as these are promises that are hard to keep. In the end they are going to be incorrect anyway.

Estimates are hard, so let’s not do them. They are going to be incorrect anyway. Let’s just wait until they are actuals and then we can report them and we will have eliminated our risk. But whose risk are we referring to? We have just transferred all of the risk from the project team to the client.  If we are professionals in our craft of Software Development, shouldn’t we be able to provide our expert assessment on the situation? If not, why should the client trust us?

4) Don’t put additional pressure on the development team and cause them to compromise quality to make the deadline.

My opinion on this one is similar to #2. This is more a comment on a dysfunctional system than a comment on estimates.  The comment implies that the team will sacrifice quality to meet an estimate.

This sounds like another instance of treating the symptom and not the problem. If a project manager is holding the team to estimates and not engaging the client with new ideas, then the Project Manager is probably not the right fit. If the client is doing this, well that is certainly the client’s call. It is after all their solution. Quality for the client may be meeting the deadline.

5) The estimates may cause a shift in the project’s priorities due to the fear and uncertainty of large items.

Valid point. But I think this is the correct behaviour. Large stories will shift the priorities because of the perceived large risk they entail. This I believe is consistent with the principles of Agile to take on these large tasks early to minimize risk and learn fast/fail fast. I don’t think this is necessarily related to estimating. In fact, this is a reason why we need to do estimates. Estimates will ensure we identify the large epics as high risk items and address them early. This will help us to fail fast. If we do not estimate, we may leave these this stories as a lower priority and they will be done later and possibly cause project rework.

Next Steps

One critical benefit about providing an estimate to the client is that it completes the commitment cycle. Typically clients commit budget and teams commit to an estimated solution vision. This estimated solution vision is at a very high level that identifies the features and interactions between the features. It is not big requirements or design up front. But the team should have an understanding of the solution vision before starting or the potential is that excessive rework may be required after a considerable amount of work has already been completed.

In short, preparing that estimates forces the project team to understand and envision the entire solution because we are now committed.

Typically Planning Poker sessions produce estimates, but the real by-product is the consolidated solution vision that the entire team, including the client, has after the session. (In addition to the prioritized User Stories) That is the real value. Not producing estimates leaves the project in much poorer state.

The Guarantee

Why do we believe so strongly in this? Because we focus on the end state or the ultimate Solution. By focusing just on the Software Development process and activities you can Sub-optimize and although the Software Development process can be better (however you define better), the overall value of the project can be diminished or possibly no longer apply. Not producing estimates is one example of potentially many where having a focus just on the Software Development process may adversely affect the raison d’etre of the overall initiative.

Just like outsourcing the act of Software Coding can result in less than optimal solution elsewhere in Software Development, not estimating a Software Development projects can create a less than optimal solution for the entire initiative or business.

Protegra believes so strongly that Agile projects can be successfully estimated that we have an offering to guarantee scope and budget with our clients when we are able to execute Custom Software Development Projects in our Lean and Agile Methodology. It is something we have been doing now for over 10 years.

Agile Team Building – Apollo 13

We were talking the other day in my new project team about various team building activities. It was mentioned that some people have not seen Office Space, so this is spurring an impromptu screening to alleviate this oversight. 🙂 We then talked about other team-building activities that our teams at Protegra have done. They ranged from innovation games, to magic eight balls to cowbells. Fascinating discussion as I was not aware of how each and every team found a different and valuable way to build their team.

I mentioned that the team building I wanted to try on the next project was a movie that inspired me on leadership, team work, and problem solving. That movie was Apollo 13. Fantastic acting and storytelling, but I was enthralled of the enormity of the problems and how they solved them. Now to be fair, there are some aspects of the problem solving that wasn’t Agile. (Such as being overly directional and Smoking. Did everyone smoke back then?)

But there are five lessons I take away from that movie than can inspire any team:

1) Manage and Lead by end state

Throughout the movie after the accident happened, the problems were always presented to the team in the form of end-state objectives. We need to get those Astronauts home safe and sound. It was up to the team to determine exactly how to do that. It wasn’t about telling them what tasks to do. It was about stating the objective and letting them use their expertise.

But Flight Director Gene Kranz was always there to guide the discussion if they started to digress on what if scenarios and things outside of their control. Very aligned with Agile to empower your team to solve the problem and having the Project Manager just guide the process.

“Let’s work the problem people. Let’s not make things worse by guessing”

2) Have your client co-located!

Boy, bet you didn’t see that one coming! I think the major success factor was they had Ken Mattingly to assist them in testing how they could power up the Command Module successfully. (Ken Mattingly was the Astronaut that did not fly due to a suspected case of measles) Classic example of having a client co-located. Ken Mattingly was a pilot that knew all the requirements to fly that spacecraft home and the conditions they were under. And in a true moment of genius he refused to use any item that they themselves did not have on board. He even requested that the environment in the simulation Command Module set to the exact light and temperature they were encountering on board. This was critical to ensure that his solution was a solution that would hold up. Without this co-located client insisting to operate in the true working conditions, I’m not sure a solution would have been found. It also raises an interesting point that your co-located client needs to be a decision-maker, expert in the business domain, and an expert in how technology will be used on the front line.

3) Create an atmosphere of safety to allow people to contribute

Although Gene Kranz (Played by Ed Harris) was a strong cup of coffee, the environment they operated in was still one where everyone could offer their opinion and challenge opinions. Good teams find a way to create and maintain this atmosphere so that ideas are cultivated and grow. The sessions they had to solve the problems had almost everyone speaking up and offering ideas.

4) Care about the success of the Project. Take it personally

Gene Kranz had the following quote when asked about the possibility of losing Astronauts by the media:

“We’ve never lost an American in space, we’re sure as hell not gonna lose one on my watch! Failure is not an option.”

This quote has always stuck with me. Although some may say it is easier to be passionate in a situation where lives are at stake, I always find the best teams have found a way to have their team members genuinely care about the success of the team AND the success of the client and take it personally. This care and concern needs to be encouraged on projects and although all team members need to nurture this, it sometimes falls on a couple of team members set an example. These do not need to be your leaders on the project. In fact it is better if they are not people in the leadership roles.

5) Lead by Attitude

All through the movie Gene Kranz was unwavering in his confidence to the team even though I am sure he had internal doubts. This allowed everyone to have confidence in what they were doing and just ‘work the problem.’ Without this confidence, valuable effort may have been spent elsewhere on things that didn’t help to solve the problem. I think one of the most valuable things a leader can do is to lead by attitude and ensure the confidence of the team is high.

Check the movie out if you haven’t seen it…

Goldilocks and the three Project Managers

At Iteration 1 of the Agile Winnipeg User Group we were doing the Agile ball game exercise. I won’t go into details here, but details can be found on Boris Gloger’s Blog by following this link:


For this exercise we appointed one person to be an observer for each team. This observer watched the proceeding and then made comments in the retrospectives. At the end of the session, it was subtly postulated/proposed that the Project Manager in Agile could actually be fulfilled by playing this observer role.

That statement bothered me for a while. I am not a proponent of a directional Project Manager, but I do believe they offer more value than just observing, So here we are with the three bears analogy:

The first Project Manager – Too hot

Well, we all know the first Project Manager was too hot for everyone’s liking. This first Project Manager is indeed the directional, traditional, micro-managing Project Manager we see in our past experience. This Project Manager is the Military Leader that is leading all team members by defining the plan at a very discrete level and then directing the individuals to execute that plan. This Project Manager is not at the Military General level as they typically do not contribute towards strategy. They only execute the plans that have been previously decided as the realization of strategic objectives.

This analogy works well  as it fits well with the traditional Project Manager not being concerned with value. They don’t have the extended awareness of value because they were not involved in the strategy creation. All they know is to execute what has been previously decided.

The second Project Manager – Too cold

The second Project Manager is somewhat too cold for my liking. Given that we have swung away from the traditional Project Manager for very valid reasons, I think we have thrown the baby out with the bath water. By labelling the Project Manager as merely only an observer, we have missed out on a great opportunity. I think it is a delicate balance to retain the additional value that a Project Manager role typically brings while still creating an atmosphere where a team can self organize.

But what are these skills that a Project Manager uniquely has more so than others? Well I am glad you asked. I would argue that a Project Manager has these additional competencies:

  1. Confidence to question – to ask why and to seek justification
  2. Comfort in conflict/Negotiation – to negotiate in the case of disagreement
  3. Workshop Facilitation – to facilitate all workshops
  4. Process Steward – to create the right process with the team and then govern the process

The third Project Manager – Just right

So if a Military Commander is too hot and an Observer is too cold, what is just right?

A True Agile Project Manager – The Referee

But wait, isn’t this just an observer? I would suggest that the observer was not required to have these other competencies. How does the Referee analogy provide this value you ask? Please indulge me by letting me use the analogy of an National Football League(NFL) Referee.

Foremost, the Referee is a student of the game and has contributed to the rules of the game. The Referees have detailed domain knowledge of the process (Rules of the game) and I would argue they also have domain knowledge of what the Offence (Technology), Defense (Business Domain), and Special Teams (Requirements) are trying to achieve. The Referee now can let the teams play the game (Self-Organize and deliver scope), but challenge the play when individuals over step any rules that everyone has agreed to. The Referee then is an expert in conflict resolution and facilitation.

For experienced teams, the Referee probably provides less guidance than he or she does for new teams. Once teams have worked together, they really manage the project themselves and require little guidance.

Ultimately, the Referee should be a former player. This will grant the Referee Domain Knowledge and allow him or her to challenge the play at all times.

In fact, I would argue that an Agile Project Manager must be a current or former player. Thoughts?

My final comment is something that anyone playing sports can probably attest to. I would estimate that 90% of a GOOD Referee’s time and effort is not spent calling infractions, but rather encouraging proper behaviour while the game is being played. Now that fits into the role of an Agile Project Manager!