#NoEstimates motivations

I thought it would to be interesting to discuss the motivations behind No Estimates rather than the argument as to whether they are required or not. The motivations due go some insight into why they are being provided as an option after all. As I see it there seem to be three primary motivations behind No Estimates:

We don’t want to be wrong

IT professionals are first and foremost caring people who honestly don’t want to let people down and have to inform them that they were mistaken. In this case, it is much easier to not have to give them an estimates which we know is probably wrong. No one ever likes to have the meetings where we need to request weeks of additional effort and thousands of additional budget. The business may think that IT doesn’t care as the dollars are not from the IT budget, but IT really does take these overages seriously and hate to make these requests.

We feel that estimating itself is a waste of time and effort

We also have been on projects where estimating has gone horribly wrong and estimates were way too detailed. Excessive time was spent on estimates in the thought that additional analysis would result in more detailed estimates and a better project plan. IT has learned that estimates should be less detailed, but still those memories seem hard to forget.

We feel bad estimates will led to bad projects and poor quality

Finally, we feel that once given, estimates will be imprinted on the clients and everything else will be sacrificed in order to abide by the estimates. Weekends, personal time, quality, documentation, everything will be sacrificed so we can meet the vastly inaccurate estimate provided at the start of the project when we knew so little.

Let us agree

So let us first agree that all these reasons are valid and noble reasons. We may disagree whether Estimates are valid, but I doubt believe there can be any disagreement that the motivations behind the No Estimate movement are true and valid.

The night #Canada cried

hug

August 20th, 2016. The night where Canadians will remember exactly where they were for the last Tragically Hip concert. To call it a watershed moment like Paul Henderson’s goal would be unfair. Paul Henderson’s goal uplifted the country, Gord Downie singing “Grace, too” broke our collective hearts. Even though the cancer diagnosis happened in the past, it really took this concert to make the situation real.

It wasn’t supposed to end this way. The Tragically Hip were ‘the’ Canadian band. Not overly successful outside of the country, humble, polite, meaningful, and important. Full disclosure, I was always more of a Rush fan, but there I was crying over Canada’s loss in a friends back yard, listening to the music of a generation of Canada.

I loved that the hip were from a small town, I loved that the lyrics in the songs were from Canada throughout the years, and I loved the fact that the Tragically Hip were always different.

If anything August 20th, 2016 was Canada’s JFK moment. Suddenly our collective hearts were ripped out and we were left to wonder about where do you go from here. And just like JFK, Canadian’s were gathered around the country watching history being written.

Even worse, there wasn’t a person we could despise. Just a nameless, faceless disease that had taken millions before.

Thank you for the bravery, music and words Gord. Thanks for reminding us about what being Canadian really means.

Farewell my friend

Today is a sad, sad day. After 16 and a half years I have to put down a long time companion. One that has been to California, Alberta, Wisconsin, Montana, and many places in between. I first met her on an April day many years ago and she was a perfect match.

But now I can just see the age creeping up on her. She is slower and doesn’t have the same get up and go. She tries to keep up, but ultimately she just falls behind the other SUVs. I just don’t have the heart to keep on applying duct tape to the rust spots.

Yep. I’ve got to let my Pathfinder go.

This wouldn’t be so hard if she didn’t still drive nice and start every morning. She and I have been through thick and thin. That vehicle has seen me through the last 17 years and 3 girlfriends and 2 kids and 1 wife. For those of you counting at home, those 3 girlfriends were before the wife and 2 kids. 🙂

So how cruel am I?

I’m now driving the Pathfinder to Mazda, Ford, and Hyundai dealerships to test drive other cars. Jesus, how callous and insensitive can I be? I’m such a bastard.

I only hope one day she can forgive me. If it is any consolation I am sure to trade in the next SUV just like I’ve done to the Pathfinder. And I’ll do it sooner, with no regrets.

Goodbye my dear, we will always have California.

Confessions of an #Agilist – Agile is dead #Pasunashi

Businessman at fork of stone pathway in water

So I’ve recently taken a job as the Manager of a Project Management Office, and I have a confession to make:

Agile is dead. I’ve seen the body.

All about perspective

When you are on the receiving end of funding, Agile makes perfect sense as it is optimizing the individual project. I give 10 projects $200K and they will deliver the best value they can individually. no problem.

But when I am on the sending end of funding, did I select the right projects? How do I decide which ones to select? If two fail, then what does that do to the company’s bottom line? Could I have used those people on more important projects? How do I justify how I selected the projects?

The Good News

The good news is certain things from how Agile lived his life has been incorporated. Iterative planning and execution is alive and well, as is User Story Mapping, and automated testing, and specification by example. A lot of the Agile practices have had a profound impact on the Software Development methods used. In some places, even Pair Programming is alive and well.

The Bad News

Sadly, the entire patient could not be saved. Now this is for a corporate environment and one that has more freedom than most corporate environments.

No Estimates is dead, Pure flow is dead, no design is dead.

Why? Predictability is king. There needs to be some business case for every project. it doesn’t have to be extremely detailed, but some analysis and design needs to be done. Some recommendation needs to exist for what the solution will look like and what the potential costs and benefits would be.

Profound

See the point isn’t about doing the project right, it is about doing the right projects. Any practice that doesn’t help us to pick the right project isn’t Agile, it is PasunashiPasunashi is Japanese for ‘Without Path’.

Selecting projects without a path and executing them without a path is not something I feel comfortable recommending.

But really Agile is not dead because once we pick the right projects, we can do them in an Agile manner and according to “Pasu ika” – Following the Path…

 

 

 

Why #Goalies make the best Project Managers and Leaders #PMOT

Penney_History

I was driving with my brother back from a family event and we started talking about the upcoming Jets and Flames hockey seasons. After some speculating on free agent signings, we started to talk about the qualities of good Project Manager and Leaders. That balance good leaders have between being persistent and committed and being able to admit a mistake and change course. There is a whole continuum of leaders that give in too quickly and some that never give in at all. What makes once person able to move on quicker than another?

We agreed that while we aren’t sure where those points are for every situation,  but we did agree on one thing. If you have been a goalie, you will find that point easier than other people. Here are the five reasons your next leader or Project Manager should be a goalie.

Goalies know they can’t win by themselves – focus on the project

No matter how good a goalie is, they can’t win games by themselves. This helps immensely to keep egos in check. They know they need forwards to score goals and defenceman to help keep goals out of their own net. More than any other position, you are brutally aware on how the entire team is needed.

In addition, your role as a Goalie is to give the rest of the team confidence as well. The rest of the team should not have to worry about bad goals in our own goal. Our team should have the freedom to challenge and rush when the opportunity arises.

Goalies know that the focus needs to be on the wins and not the goals. It is about the project and not the tasks.

Goalies know you can’t win them all – look forward

Goalies are perfectionists in their craft and in all things except having a good memory. Goalies are also extremely forgiving with their teammates and their mistakes. This provides an interesting dichotomy. I am a perfectionist until that pucks is in the net, then I need to be able to wipe the slate clean and move on. Usually there is a quick re-evaluation process and then you need to move on. This requires a short memory and a good amount of confidence.

Even more, Goalies understand that the games is made up of 20-30 mini-games and they need to be ready for the next one. You can’t get too high or too low.

Bad decisions and mistakes are part of the game. Everyone makes them so it doesn’t make sense to spend a lot of time on persecuting the guilty. Fish the puck out and move on….

Goalies know about perfect shots or deflections – don’t over plan, over analyze

You can have the perfect angle and sometimes a shot is going to beat you or is going to be deflected. That is just life and it is no ones fault. Good Goalies spend minimal time looking backward and almost all their time looking forward.

This also help Goalies to not over plan. People can over plan or over analyze because their believe it will increase the chances of success. Goalies realize that even if you spend two weeks working on something, a deflection is still likely. Rather than spending all that time planning, spend time on how you will recover because you know a deflection is going to happen.

Goalies realize communication is the key – communicate

For those of you that haven’t been on ice level, Goalies are probably the chattiest players on the ice. Always chirping our information to the defencemen – ‘time’ , ‘left’, ‘right’, ‘point’, ‘DUCK’

Goalies realize the key is rebound control – deal with issues immediately

Goalies and Project Managers and Leaders realize that issues happen. What they all realize is that it doesn’t matter how or why the issue arose, just how can we get it resolved. Having an issue is not a bad thing, booting the issue around in front of the net for 3 or 4 shots is a bad thing and will lead to a goal.

Find the issue, locate the issue, cover the damn thin up a get a whistle.

Goalies guide projects to where they want them to go – minimize risk

When I played a lot, I had a great glove hand. My brother had great lower body reflexes. So what did we do? We showed more or less to influence the shots to go to our strengths.

Similarly, a great Project Manager or leader will guide the project to where he knows the project is prepared. He or she will know the high-risk areas and compensate for those areas. I always used to hug the stick side post.

Summary

But Terry, you say, ‘I’m not a goalie, does that mean I can’t be a Project Manager?’

Not at all. But if you are a good Project Manager, it means you probably would be a good goalie. 🙂

Everything I know about Project #Risk I learned from Brett #Favre #PMOT

** FILE ** Green Bay Packers quarterback Brett Favre looks to pass the ball after falling down during the second quarter of their NFL football game in Green Bay, Wis., in this Sept. 10, 2006 file photo. Brett Favre has decided to retire from the NFL after 17 seasons. FOX Sports first reported Tuesday March 4, 2008 that the Green Bay Packers quarterback informed the team in the last few days. (AP Photo/ Morry Gash, file)

God I loved watching Brett Favre play. Sometimes.

Other times he just frustrated the heck out of me. You really had to admire the man’s commitment and desire though. He was fully bought into the team’s success. He was going to do whatever he could to ensure the team won. Even more, I got the sense that he believed that the team would win. I got the sense that he was surprised each and every time he got to the end of the games and the score on the scoreboard went against the Packers. He had all the traits you absolutely love to have in an athlete. And he had all the traits and habits you hate to have in a Project Manager.

Project Risks

I don’t think I’ve been on a project where we have managed risks well. I don’t think I’ve seen a project where risks are managed well. Everyone understands what needs to be done but for whatever reason, the risk meetings aren’t followed up on after that first risk workshop. I started to wonder again why that would be. Everyone understood the reasons behind the risk workshops and even on projects that weren’t overly busy we didn’t seem to go back and revisit risks. We even created new risk deliverables. We had risk heat maps and risk radars! And then we created them once and never really went back to review them or recreate them.

So the question is why? Why are we so bad at following up on something that most people agree is very valuable?

Just like Brett Favre, we just didn’t feel there was a lot of risk.

Be the Ball

Good project teams ‘become the project’ at some point later in the project schedule. I don’t mean they physically become the project, but they become vested the project’s vision and success. Project team member’s want the project to succeed and want the clients to realize the benefits. In this way team members become the project and lose some of their objectivity. When project team members become the project they first thing that happens is that they believe in the project, the second thing that happens is that they believe in each other. Eventually this can result in decreased formality, diminished reporting of issues and risks as the team doesn’t want to be adversarial and also they believe the issues will sort themselves out. In this way, as your project team gets stronger and becomes the project, they lose their objectivity.

Annnnnnnd before you know it you are chucking up a 70 yard bomb with 2:00 to go instead of just running out the clock.

More and more companies are now resourcing external Project Managers that are only on board for a short period of time. I believe this is trying to address the issues that can be caused by Project Managers becoming too comfortable in the client environment. Similar to the project team, this familiarity can cause issues to not be raised and decreased formality as the project managers believe more in their team mates and the clients.

Question

So the question remains. How can we reap the benefits from increased relationships to the Project Manager without losing objectivity? One way to attempt this is to use consultant Project Managers and only have them to a short period of time. I’m not sure if this is optimal though as new Project Managers have to learn the business domain and organization and just when they are up to speed they need to be swapped out. With every new Project Manager there is ramp up and learning time and with every departing Project Manager we lose valuable project and client knowledge.

Active Project Assurance

What we are implementing is a concept that has been around for a while – Project Assurance. Lately Project Assurance has taken on the form of Project Checkpoints were we get together and sing around the campfire. I jest but the weekly conference call checkpoints without everyone having the knowledge or the context of the project are not very useful.

Usually the call goes like this:

You: Got any issues?

Me: Nope.

You: OK, talk to you next week

What we are proposing here is quite different.

Active Project Assurance involves a third-party facilitating ongoing sessions with the project team to provide that objectivity while encouraging the Project Manager to continue to build relationship with the project team and clients. In our case the Project Management Office participates in the Project Initiation activities and then facilitates the Project Retrospectives and Project Risk workshops. We can then provide Project Assurance to objectively review the project while still allowing the Project Team to be the project. Without the enhanced project team and client relationships, the Project Management Office does not have biases for issues and risks. Both of those still scare the heck out of the PMO.

This allows the Project Management Office to have enough context to actually consult on the project and also allows the project teams to become more informal and build relationships that ultimately benefit the project.

And maybe we can stop the odd pick-6 while we are at it.

#Three Deadly Sins of Software Development #agile #hubris

hubris

In my experience, I have encountered three deadly sins in Software Development. Project teams can overcome almost any problems if they don’t fall victim to these three deadly sins. Unfortunately we seem to have progressed through these deadly sins throughout the years as we get more and more experienced in Software Development.

Technology-Centric

Our first deadly sin was the sin of being technology-centric. The first aspect of this was the behaviour in the 1970’s where Information Technology professionals had a belief that they knew what was best for clients and would essentially decide for the clients as to the specific type of functionality delivered. I can remember early on when we still gathered requirements from the users, but we sought no validation on the design or interface. We as professionals know best in regards to how those components should be designed. Even our terminology set the stage for the principle that the business was not informed enough to make decisions on their own. They were only ‘users’ after all. Information Technology professionals would create the system and the business could simply ‘use’ the system we created. Nothing more.

The second aspect of being technology-centric came after we begrudgingly accepted that the business were more than just users and should validate the system design and interfaces. OK, we will let you control that aspect, but Information Technology Professionals will control the selection of all the technology and patterns that lie beneath the interfaces. All of those technology choices must remain with the Information Technology professionals and it would be beyond business users to provide input on technology and patterns selected. Information Technology Professionals will decide on all architecture without collaboration.

Thankfully we now understand that if a technology or architecture is truly better, that should result in more value for the client early and often.

Methodology-Centric

Shortly after being technology-centric, we flowed right into the methodology-centric phase. Alright Mr Client, you define the requirements and value that the project will deliver, but we will define exactly how we will deliver the project. This started out by defining a very specific process for the Waterfall Software Development Methodology, but has evolved throughout the years to be equally specific and constraining processes for hybrid and Agile Methodologies.

In short, any methodology that a project follows without customization for a client, project team, or project is flawed. I’ve always thought how curious it was that Agile proponents once freed of the shackles of Waterfall were so eager to put Agile shackles on every project they saw.

Topology-Centric

And the final deadly sin is one that is a bit recent to the dance, topology-centric. I use topology-centric to refer to the desire by Information Technology project teams to be embedded at a very senior, strategic level for the project. Many times the Information Technology solution can be made better if Information Technology Professionals can work together on the business problem and not just the solution. It is ironic that early on Informational Technology was trying to limit the access the business had to Information Technology components of the project and now the business is in charge to limiting the access Information technology has to the business components of the project.

The more things change, the more they stay the same.

To be clear, the deadly sin is not to that Information Technology is denied access, but rather that Information Technology demands that they should be granted access by default.

Summary

Information Technology Professionals have to remind ourselves we are a service and need to embrace the servant leadership in all aspects of project delivery.  We as Technology Professionals only encounter these deadly sins when we think we know better than the clients. If we avoid these types of Information Technology Hubris, our projects have a much better chance of success.