#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.

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.

Turn the Ship Around by @DavidMarquet Book Review #agile #pmot

“Turn the ship around” by David Marquet is a rare gem of a book. It is one of those books that come around once a decade. The book is very well written, provides a lot of lessons that you can apply to your situation, and is very entertaining to boot. In his story of how David Marquet turns around the Sante Fe, we can see similarities to companies, jobs, and teams in our own situations.

It is an inspiring story how one can turn the leader-follower model and turn it into the leader-leader model, even in one of the most seemingly hierarchical situations in the world, the military. I’ve read multiple books now that dispel that myth. I think the military probably gets a bad reputation of being hierarchical, but to survive has probably adapted more and quicker than perhaps any other industry.

Mistake Monitoring

There are many things that you can take away from David Marquet’s book based on what you are experiencing and what problems are foremost in your mind. For me, I was thinking about the challenge of making project reporting more lean and valuable.

So when I read the section lamenting that monitoring in the Navy was just focused on preventing errors and mistakes but not at getting better or more efficient, I immediately saw  parallels with project reporting. I was thinking the same thing about our project reporting. We report about whether the project is yellow or red and what problems we have encountered, but we rarely if ever discuss how we became more efficient or got better on the project. If we are lucky, we discuss those items in the project or iteration close outs. Many times, the items are small improvements and many times they don’t get shared outside of the project team.

It got me thinking, how can we monitor and focus on efficiency improvements on our projects? As Marquet mentioned, the bar is set quite low if success is measured by the absence of errors and mistakes. If success is just based on meeting budget and schedule, are we really trying to improve and get better?  Why wouldn’t team members just provide large estimates so that they were deemed a success. Where is the focus on continuous improvements and wanting to get better? I want to do more on my projects than just avoiding mistakes.

I don’t have answer for where this will lead and what we are going to monitor and share. But thanks to David Marquet we are asking the question to our teams and trying to determine how we can set the bar higher and get better and more efficient on our projects. Maybe that is a good place to start, to say finishing a project on time and on budget is not enough and to ask the stakeholders what other goals and objectives should this project have? And then overall, what goals and objectives should the Project Management Office have?

I’ll report back in a future blog on what we have tried and what have worked.

Project Manager’s #1 Challenge #PMOT

risk-vs-reward1-e1330209788902

One thing that has always perplexed me on projects is how poorly we as Project Managers and project teams manage risk. All of us have the initial Risk Management meeting and try to capture the risks and mitigations required. But even in that first meeting, we fall short in identifying and planning how we are going to address the risks on the project.

Why?

At one time I had thought it was just because we as Project Managers got busy with the work on managing the project and forgot about scheduling follow-up Risk sessions. But that wasn’t it, even when the Risk items were incorporated into weekly status reporting, the effort and attention paid to risk management was just ceremonial. There was something else at play.

I was working on another long project and we were discussing the challenges with the issues and risks encountered. In a retrospective we discussed how we managed the issues and risks looser and looser as the project executed. We did this as we became more comfortable with the client and they became more comfortable with us. Unfortunately new players came onto the project later and changed characteristics of the project. This changed the issues and risks but we were not managing them as formally as before as we became comfortable with the issues, risks, client, and the project.

One person summed this situation up perfectly. “On projects it is natural for the project team to become the project. This eventually happens with the Project Manager.”

This is where the lack of formality and process can be a problem for the Project Manager and the project.

Become the Project

“Become the Project” – sounds rather Zen-like doesn’t it?

Become the Project to me means that you have somewhat lost your objectivity and like the rest of the team you are thinking in a positive and trusting manner. You start to expect issues to be resolved very soon, that risks will not happen, and that if things happen we will address them as one homogeneous team. Well it turns out that perspective is valuable and required by some of the team members as they are working through deliverables, the Project Management and leadership need to be careful to not fall into this lack of formality.

So what to do?

What can we do? As much as we say not to do it, it is human nature. Trust will be built up and used after working with the same people for months and years.

This is where your Project Management Office or Deliver Management Team needs to help your project team by providing the independent 3rd party or sober second thought perspective. The Project Management Office or Delivery Management Team’s role is not to own the risks and issues but to facilitate the review and consult on them as an independent 3rd party. In this way, we ensure the review happens and we make decisions based on all the most current data from the project balanced with objectivity and experience.

Ultimately you want your team and Project Manager to be the project, we just need to add a check and balance to ensure issues and risks aren’t overlooked.

Would you like fries with your McApplication? #NoEstimates

There is a great difference between a fine meal and McMeal. The fine meal typically has been crafted with years of experience and training by chefs around the world. The McMeal is put together with years of experience based on what people want at 1:30 am in a drive-thru. The fine meal also places forethought as to how the components work together and play off of each other. With McMeals and other fast food meals, you are left to your own devices as to what you would like combine together at the last possibly moment.

Software Development

Similarly, Software Development can create solutions on which great experience and effort is expended determining how the components fit together or we can slap the functionality together for a McApplication. Agile can and has been guilty of creating too many McApplications over the years.

User Story Mapping

User Story Mapping is a great tool, but unless it is followed up by some analysis and design work to architect the solution, we are just visually drawing the new McApplication. While the concepts of delivering in iterations and visually planning the iterations is extremely valuable, jumping into delivering without architecting the overall solution is misguided and sub-optimizing.

If your first project work is cutting code after you have created a User Story Map, you are well on your way to creating the next McApplication.

We always need to remember we are professionals committed to creating, designing, and delivering the best solution to a business problem, Sometimes this may involve providing counsel to clients on why some stories should not be done, why some stories should be done later, why some stories need to be done now, and why some stories that they haven’t thought of need to be added.

Client priority rules the day of course, but if we just do what the client identifies without providing our expertise, we are no longer professionals. We are just order takers.

To avoid being just order takers we usually need to do some detailed analysis on what a story means and how it needs to be implemented. Just capturing the highest ‘placeholders’ to discuss functionality means you are creating your architecture as you go along. Yipes.

NoEstimates

Which brings us to #NoEstimates.

No Estimates does not focus on creating a better solution. No Estimates has been created so that the project can be forecasted. It proposes nothing to help create a better solution to a problem. Even worse, when No Estimates is followed to the letter, it can even absolve the team of project leadership duties.

No Estimates proposes that we will just work on what the client wants, when the clients wants it and we will stop when the client wants to. It overlooks a key responsibility of project teams to save the client from themselves with our experience and expertise. Agile sometimes seem to shy away from tough discussions that should happen early on projects. Some projects should never start.

Agile proponents forget that not only should code to tested early and often, but incorrect client concepts should also be. If we are taking direction on a client priority that we know is wrong and will result in a lesser solution, and we haven’t done everything we can to change their mind, then we are not Agile.

No Estimates proponents will probably state that all those things should be done on a project in addition to No Estimates, but by not putting design and architecture front and centre it is clear they primarily value forecasting.

Due to this, the type of solution you will get out of a No Estimates projects will probably be a McApplication rather than a fine meal and you’ll probably be hungry for a new solution before long.

Solution Leadership and healthy adversarial discussions over difference in opinions is not valued highly on No Estimates projects. The focus is on  forecasting and doing whatever the client want to do next….

Would you like Fries with that?

 

 

 

What a Project Manager does #PMOT

I often get questioned by my kids on what exactly I do in my job. I tell my kids that I am a Project Manager and I work on teams that create web sites but that still seems to not convey ‘what’ exactly I do on a daily basis. Then last weekend I had an experience that I was able to point at to show my kids what I do at work. So what was that experience?

Building one of those metal storage sheds.

Construction

Turns out it was my wife’s idea to get a metal shed. We needed to get it to store bikes and softball gear in it. I’m usually the person to put these types of items together but this time we had a lot of things going on during the weekend so my wife got our two nephews to help. Things were going well and the floor got put together well. The shed started to take shape with the walls and frame being put together. The top frame went into place as did the middle frame that re-inforced all of the walls.

Looking back this probably was the early part of development projects where everything is going swimmingly as components haven’t been integrated and tested yet. But very soon, we were going to experience our first integration test.

Testing, Testing, 1-2-3

I hardly provided any assistance during the development, like a good Project Manager. Just let the team go. But then I was starting to hear some frustrated tones from the back yard. The last panel on the back yard wasn’t lining-up. No matter what they did, the screw holes were a centimetre apart.

They finally came in complaining about the stupid shed kit and I came out to see if I could help. I walked around and looked at the instructions and asked them to describe how they put it together and how they had tried to fix it. I checked the schematics and then they noticed that in one corner the two pieces were not flush against each other like the other three corners.

We then tried to line up the panels but the screw holes were still half a centimetre apart. sigh.

Back to the drawing board.

We then walked around the shed inside and out looking for something else that was out of line. By now we had the experience that one corner or side was probably larger than another. My nephews got the idea to measure all of the sides and sure enough one of the braces was too long. We shortened the brace and the screw hole lined up perfectly.

Summary

Over dinner that night I said to my kids that what I did on the shed was exactly what I do at work. I help project teams plan, but most importantly I help them resolve issues. Most of the time they resolve the issues themselves, I just facilitate the process.

I’m not even gonna talk about how hard the roof was to get on….

Doctor’s Notes and a broken system

We recently had a news items here is Manitoba where an NDP member of the Legislature introduced a private members bill to remove the stipulation to require a Doctor’s note until you have been away for greater than 6 days. Seemed to me like a totally reasonable request. It also occurred to me how broken the system must be if someone thought getting a Doctor’s note was a good solution initially.

It appears that the Doctor’s notes were required to try to address unwarranted absenteeism. The problem with this policy is twofold:

  1. By forcing potentially sick employees outside and into a Doctor’s office you are potentially increasing the severity of their sickness and increasing the chance they will infect others.
  2. If they are unable to acquire a sick note because they lack a family doctor or have had too many sick notes, they will probably come to work and make more people sick. This in turn will result in point number 1.🙂

Ultimately at the end of the day, you will need to trust your employees. If they are not engaged they possibly could take unwarranted sick days that could impact the business. But you know what? That impact would be minor to the impact to the business when they ARE at worked and not engaged. They could waste more time than during their unwarranted sick days. (especially when you factor in other employees they are also distracting)

When you are thinking about designing solutions to the problems, ensure you are treating the problem and not just the symptom. In this case, playing hooky is not the problem. It is just a symptom of being not engaged and not feeling valued.

BTW, increasing the procedure to only require notes over 6 days isn’t fixing things either. Spend the effort to talk to people and understand what they would like to do at work. What makes them feel like they aren’t working? What gives them a sense of satisfaction? What makes the day fly by for them?

How would they recommend getting employees more engaged?

You might be surprised at the answers you get. At the very least, just asking the question increases their engagement and probably starts the process to reducing absenteeism.

Brooks Laich #Leadership and #Winning

Brooks Laich can be on my teams anytime. In one of the cruelest turns of fate, Brooks Laich was traded from the Washington Capitals to Toronto Maple Leafs on February 28th. If he wasn’t traded, he would have been demoted to the Washington Capital’s American Hockey League team to try to get some salary cap relief. One way or another, Brooks Laich was not going to be able to compete for a Stanley Cup for the team that he lived and bled for over the last 12 years.

And then Brooks Laich who had been a Washington Capital since 2004 was suddenly gone.

My Brooks Laich story – March 22nd, 2013

I was lucky enough to sit beside Brooks Laich’s relatives at a Winnipeg Jets game three years ago. They had made the trip out from Saskatchewan to see Brooks play. Two adults and two kids were there all decked out in Brooks Laich jerseys and there were the most friendly, honest, and polite people I have ever sat beside.

They made such a good impression I couldn’t help but clap when Brooks Laich opened the scoring at 12:10 of the first. Ever since then I have honestly cheered for the guy.

February 29th, 2016

So Brooks Laich was looking like he would finally get a chance to complete for the Stanley Cup after 12 years and then he wakes up in Toronto a day later. I thought he would be crushed and I am sure that he was. No one could ever tell from how he carried himself though.

All I heard from him in his first media interview was how happy he was to join the Maple Leafs and about the great young core they have in Toronto.

I don’t need to see Brooks Laich name on the Stanley Cup. I already know he is a winner.

Code Monkey Club #KidsCoding

monkey

Code Monkey Club

Well I am back for my second year of holding lunch session with kids at River West Park teaching coding. I learned quite a bit from my first year and I’ve changed the offering a little bit. In my first year. I created the exercises in MineCraft. This was both good and bad. Good as it immediately got kids engaged with the exercises, but bad because the kids were more focused on doing things in the game instead of learning about coding. I got a lot of feedback that the kids loved the sessions but the kids then wanted to learn how to build entire worlds in MineCraft and create videos on YouTube. Clearly, I needed to think about this a little differently.

Code.org

The white knight for me were the excellent resources that are available for everyone on code.org. The exercises illustrate programming concepts and fundamentals and are available for everyone to use. They leverage existing games/themes like Flappy Bird, Star Wars, and MineCraft.

The best part is the interface that code.org has where the kids can drag and drop logic blocks and then see the results in playing the game immediately. The interface is ideal for getting kids excited and receiving positive feedback on their work. Even better, my kid’s school had already done some of the basic exercises so they knew the interface.

If you are interested, you can find the exercises at the following link

What I add

I’ve just had one session,  but so far the content allows for the kids to learn more and be more engaged! I get to spend less time managing/troubleshooting exercises and more time assisting the kids with the exercises. Since the kids have already taken some of the basic exercises, I am also able to focus on the exercises that reinforce/introduce more advanced programming fundamentals. This allows me to add insight and details on what is really happening behind the scenes with the program.

So I think this is a great set of exercises, but we will see as we work through them. But so far, they are engaging the kids more, teaching them new concepts, and allowing me to add detail and insight were appropriate.

And I think we are still having fun!

 

Does #Google hate #Agile

I came across this post about how Google thinks Agile development is nonsense by Michael Church. You can check out the article here.

Where to start?

Ok, lets start at the beginning. It appears Michael Church has made the leap that Agile is Scrum and Scrum is Agile. That is quite the leap and one that I disagree with. I myself have had a couple of posts on why I don’t believe Scrum to be an optimal method. Of course, I would never say Scrum is nonsense.

What else?

“It’s a culture of terminal juniority. Product development and architecture aren’t the programmer’s job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level “user stories”. This is OK for a junior who’s learning the codebase and software engineering principles and may appreciate the guidance, but anyone with more than 5 years of experience is going to find it to be a dissatisfying way to work. There is no place for an actual senior engineer on a Scrum team.”

I would say that Michael has never been on a well-run Agile team and doesn’t understand User Stories. User Stories are designed to include Architecture issues and deliverables. Certain frameworks like Disciplined Agile Delivery actually formalize this role as well. The two-week limit doesn’t need to be adhered to like a commandment. Some exceptions should be made. For someone who has worked at Google like Michael, his lack of Innovation seems to be adhered to solely for the sake of the article. If the Scrum process doesn’t fit, change it. I find it hard to believe Google doesn’t innovate like this elsewhere.

“It’s aggressively short-term, by design. These methodologies are designed for scrappy, unproven consulting firms that need to bear down and pass their first high-profile project. In that context, they probably work– at the expense of technical debt and tired workers.”

Not sure where Michael gets this opinion. If anything, Agile is the one framework that is focused on sustainable pace and ensuring that technical debt doesn’t get built up and people don’t work excessively. User Stories are not just for user functionality, technical debt gets added there as well to ensure it is addressed as part of the sustainable process.

“It has no regard for the programmers’ career needs or desires. See the points above about Agile’s short-term orientation. Now, people are willing to give up their career goals to pitch in on a short-term crisis, for two reasons. First, if it’s genuinely important to the firm, then it does help their career to do so. Second, a story of having solved a genuine crisis under time pressure can be a career booster. Saying, “I was in the War Room and had 20 minutes each day with the CEO” means that you were important and valued. Saying “I was on a Scrum team” means “Kick me”

Wow. Again Agile is the one movement that talks about respecting people and having people choose what they work on and where their career is going. The concept that Agile is only for short-term crisis mode is a falsehood that Michael can’t seem to let go. And trust me, just being in the same room as a CEO doesn’t mean you were important. It sometimes means he doesn’t trust you.

“It’s micromanagement. User stories and backlog grooming are there to control what the engineer works on. The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking. The story points are there to track productivity (in some superficial, inaccurate way). The talk of “removing impediments” is code for “spotting slackers”. Even for people who have nothing to hide– even for people who’d be strong performers in a more sane, relaxed, progress-over-rapidity organization– a surveillance state is an anxiety state. It sucks, and if you’re good at what you do, it’s insulting to have to justify days and sometimes even hours of your time, and to be jerked around if these estimates are even slightly displeasing to the “product owner”

Absurd. Again the developers pick what they work on so there is more control that someone assigning tasks in a traditional project. Michael, I think thou dost protest too much.😉

“At identifying low performers, it has an unacceptably high false-positive rate. Let’s not kid ourselves. The reason “Agile” is so popular is that it carries this mythology of spotting low performers immediately– in two weeks instead of over months– and giving objective cause to fire them. (Agile/Scrum is, in essence, a permanent PIP.) I’ve heard it put this way: “use Scrum to spot your Scum.”

OK, I think we will leave it there as subsequent points are along the same line. I have never heard of anyone promoting Agile as a means to spot low performers.

I’m not sure what the motivation is for Michael writing this article, but I do know three things:

  1. Agile is not Scrum
  2. Michael has not been on an Agile team and would benefit from that context before writing on something he does not know about. Me writing on how Google teams are organized similar the Lord of the Rings Fellowship would be equally as uninformed and wrong.
  3. The article reads almost like a ‘shot across the bow’ of Agile being used at Google. A warning to not use it or bad things will happen with developers leaving. A good dose of Fear, Uncertainty, and Doubt.

Hate to break it to you Michael, but with Google promoting code thousands of time a day, you are already very Agile! I recommend reading about other Agile methods and suggest changing Agile methods to suit your needs. I know Google has the ability and track record.

BTW, the client engagement and customer focus of Agile may just have avoided that whole Google+ thing…

Just Sayin’

#Agile Team building by Gary Doer

It was very nice to read a story in the Winnipeg Free Press about former Premier Doer completing his tour of duty as ambassador to the United States. You can find the story here.

Gary Doer

Anyone who knows me knows I am a pretty apolitical beast. There are components I love in every political party’s platform. Truth be known, I am more a centrist than anything. Why then would I say that Gary Doer taught me how to build Agile Teams?

I always saw Gary Doer do three things to build consensus and relationships.

  1. Find commonalities first

Ex-Premier Doer is an accomplished team builder. He perhaps understood people and the power of a metaphor to bring people together better than anyone. Instead of trying to specify a solution or tell people what to do, Gary Doer usually found a metaphor or story that allowed people to get excited about the problem and solution. This metaphor then allowed each individual to interpret the metaphor and find commonality on their own. Many times I witnessed ex-Premier Doer find the only commonality that existed between the two sides and used that commonality to build a bridge to a solution. Usually this resulted in metaphors that were grounded in Hockey or Beer.🙂 Both are sure to be winners north of the 49th parallel.

      2. No Ego

Gary Doer also had the charisma and modesty to be self-effacing and have a friendly conversation on the issue. He really understood that all progress comes through building relationships and that authority is lost once you have to use it. Never once did I see him upset or rankled, directive or flustered, he was always even keel and building bridges. This lack of Ego really did allow people to understand that he truly was interested in your position and he cared. He also understood he couldn’t just tell you what to do and usually had a suitcase full of facts to share with you.

      3. Walk the middle of the road

Then when it came down to the issue, Gary Doer was always able to walk the middle of the road and not appear overly partisan. (Maybe I have this view because I like the middle of the road)🙂 But whatever the reason, Gary Doer was an expert in building compromises and solutions in the middle of the road. On a team, you usually have to walk the middle of the road. If you always swing to the extreme of one side of the team, you will eventually lose the other parts of your team.

Summary

I wish Gary Doer all the best in his next challenge. If he needs a new challenge, the political scene in Manitoba could always use another good person.🙂 Or I could always use a good Agile Project Manager.

#Scrumbled #Agile or #Disciplined #Agile

So I attended a Scrum session last week that was presented by Steve Porter. Excellent session that discussed many of the misconceptions or myths about Scrum. I came away wondering why I don’t profess to believe in Scrum. I honestly do follow many of the Scrum rituals, but I always seem to not be able to follow them completely. The processes I use always seem to be a Scrum-but implementation. I do Scrum except for this customization, I do Scrum except for this circumstance. Many of the myths we reviewed also seemed to be focusing on small misconceptions of what Scrum is. Not the large issues that could really derail a project – this frustrated me.

For example, we discussed whether the iteration planning should be 4 hours for a two-week iteration. My response is that it is nice to have a guideline, but things will take as long as they take. Sometimes we need to change based on the team and the stories.

Honestly

To be honest with you, the one thing that has always bothered me about Scrum is the amount of time, effort, and care that focuses on the rituals themselves. There tends to be great detail in how long meetings should be, how long iterations should be, what a Product Owner should do, and what a Scrum Master should be. Early on for Agile projects, I think this type of direction can be quite helpful. But Scrum has always struck me as being overly precise and prescriptive. In many situations I would prefer a loose guideline that would provide me options as to how I could structure a project. It really feels wrong to try to control an Agile project to the extent the Scrum process does. I would much rather just allow my team to customize the process as they see fit.

One thing that resounded with me after reading “Creativity, Inc.” was the comment that to nurture a creative culture, we need to “hold loosely onto goals and firmly onto intentions”. If you allow me some creative license, I believe this can be translated to than we need to “hold loosely onto rituals and outcomes and firmly onto values”

Stated in this way, it becomes clear to me why I struggle with Scrum.

It always seems to me that Scrum places rituals ahead of values. Instead of focusing on values and discussing a variety of approaches, Scrum doesn’t spend enough time discussing values and spends more on the details of rituals.

To me it seems we have Scrumbled/Scrambled what Agile should focus on.

What to do?

Recently I’ve become more aware of Disciplined Agile. I believe it has great value that is not found elsewhere in the Agile Ecosystem:

  • A Decision Framework that provides a structure on how an Agile project can sit inside the Enterprise and doesn’t just focus on the Software Development Team
  • A Decision Framework that allows for the customization of the Agile project process based on the readiness of the Enterprise and project team. Disciplined Agile supports the following Agile processes:
    • Agile Delivery
    • Lean Delivery
    • Continuous Delivery
    • Exploratory
    • Program Management
  • A Decision Framework that provides a prioritized list of rituals/deliverables to use though out the project
    • This allows for the project team to choose and adapt to what fits best in each circumstance
  • A home for an Architecture Role on the leadership of an Agile Project
  • A Decision Framework that provides the right focus for lightweight models/documentation through out the project

I’ll be focusing on Disciplined Agile over the next few Blog posts. It has great promise in helping Agile take that next step into the Enterprise.

5 Books that changed the way I think

Over the years I have been lucky enough to find books that have profoundly changed the way I perceive the world and the way I think. I usually know when I have found one of these books when I read the book over and over. This is a list of those top 5 books in chronological order of when I read them. I’ve also included how I became aware of the book.

  1. Lord of the Rings – John Ronald Reuel Tolkien

Like most young adults I was a bit of a grazer when it came to reading. I was reading enough at school that I really wasn’t looking for books to lose myself in outside of school. And then I found Lord of the Rings. Funny enough, I actually stopped reading the first time in the Council of Elrond chapter. The book didn’t really grab me up to that point. The second time I read the book I made it past that chapter and I was hooked. I think I have read the book at least 6 times now. The book really taught me how important stories and the stories behind the stories are. In many ways Lord of the Rings taught me how to also be thoughtful. Great Book.

I became aware of Lord of the Rings just from other students in my classes. Funny enough, my brother was not a Lord of the Rings fan. I remember he was a fan of the Dune series. I think this was a generational thing,

2. Godel, Escher, Bach – Douglas Hofstadter

I still remember spending weekends cycling to the park and reading this 700 page tome on formal systems. This is perhaps where I really fell in love with Computer Science. This was probably the height of being a geek as well. For the love of me, I can’t remember how I became aware of this book.

This book really did teach me how to analyze and create formal systems and in many ways how to code. It also caused me to think at a higher level about intelligence and consciousness. Great book to think about big thoughts.

3. Zen and the Art of Motorcycle Maintenance – Robert Pirsig

One of the books I first spotted in my brother’s library. I picked it up and was hooked immediately. Zen taught me the beauty of introspection and thought. It also taught me to be respectful of people who may have psychological issues. This book explained the emotion and heartache of mental issues as I read. I found the entire book and story fascinating. To this day it probably is my favourite book and the first one I reach out to when I have spare time. Robert Pirsig’s second book Lila is equally good.

Under the covers the book also spoke to me a lot on Quality and what quality is. This has been very helpful in my work life.

4. Iron John – Robert Bly

The second book I spotted in my brother’s library. The perfect book for a man in his 30’s to read to find guidance on the changes a man will experience growing up. A great book that balanced embracing what it means to be a man in the face of much bashing of masculinity in the 90’s. This book gave me great confidence. Perhaps a little too much.

5. Epistulae morales ad Lucilium – Seneca the Younger

I think I found this book when I kept on seeing Seneca being quoted in other books. This is a philosophy book composed of letters from Seneca. I loved how the letters were grounded in reality and in actual stories. This combined with the Stoic philosophy really spoke to me and resonated with my beliefs. I found more confidence in aligning myself with the Stoic principles as I went through some challenges at work in and my personal life.

Best Work Book

The best work books I have read comes down to a choice between two:

  1. Beautiful Teams

Beautiful Teams is a wonderful book with each chapter describing a situation and how a team was structured to help address the situation. Great book with a lot of real world examples of what great teams can do.

2. Leading Geeks

Awesome book providing insight on how leading Software Development professionals is different from leading anyone else. A must read for any Software Development professional. Even if you are not leading other geeks, chances are your manager will have read this book!

Is #Innovation an Empty Word?

Many times on projects and presentations I hear both the empty words and principles and also the full words. I’ve always struggled to determine the difference between the two. I’ve listened to people state that their success is all about ‘their people’ and I’ve come away on one occasion believing them and on another occasion feeling that they didn’t believe their own words.

So what is the difference?

A phrase used by Ed Catmull in his book “Creativity, Inc.” defines the issue perfectly.

The Handle and the Suitcase

It is up to the individual to remember that it’s okay to use the handle, just as long as you don’t forget the suitcase.”  -Ed Catmull, Creativity Inc.

Ed Catmull shares a visual in his new book, Creativity Inc. where he asks us to imagine an old, heavy suitcase whose well-worn handles are hanging by a few threads. He describes the handle of that suitcase as those defining principles and phrases we use and promote.  He then shares how, the suitcase represents all that has gone into the formation of the phrase: the experience, the deep wisdom, the truths that emerge from the struggle.

To me this affirms that one cannot promote and encourage without context. And that context can really only be gathered through experience and commitment. In a sense the person needs to be a practitioner and supporter. In many cases I was probably sensing that people I didn’t believe didn’t have the context or the suitcase in what they were presenting.

Catmull shows the disconnect that can happen.  Too often, we grab the handle and – without realizing it – walk off without the suitcase.  What’s more we don’t even think about what we’ve left behind.  After all, the handle is so much easier to carry around than the suitcase.

This is key. If you aren’t committed to the entire principle, the suitcase is the first to go. As Catmull says, the handle is easy to carry by itself. This is happening recently with Innovation. People promote Innovation and then discuss how organizations can inject structure into the Innovation process. These methods or structures most of the time are the antithesis of Innovation. Methods and structures can go against an Innovation Mindset.

Catmull then continues to what I think is a brilliant way to restate the issue: “I often say that managers of creative enterprises must hold lightly to goals and firmly to intentions. What does this mean? It means that we must be open to having our goals change as we learn new information or are surprised by things we thought we knew but didn’t. As long as our intentions – our values – remain constant, our goals can shift as needed”

So saying we are committed to Innovation is hollow. Saying we are committed to the values of creativity and growth and empowerment and having a culture that encourages those will generate many more Innovations than an Innovation framework. Our commitment to values is critical, not a commitment to a framework.

 

Or as Catmull adds, words like quality and excellence are misapplied so relentlessly that they border on meaningless.  Managers scour books and magazines looking for greater understanding but settle instead for adopting a new terminology, thinking that using fresh words will bring them closer to their goals.”

 

 

 

 

Creativity, Inc. and #1 reason why projects struggle

I just recently finished reading Creativity, Inc by Ed Catmull. It is undoubtedly one of the best books I have ever read. The book provides a history of how Pixar came about and how Pixar has managed to maintain their culture of creativity and innovation. There are many poignant lessons that I took away from the book, but perhaps the one that resounded the most was the use of what they termed the ‘braintrust’ team.

BTW, I hate the term Braintrust – I would rather just use a term without any implied hierarchy.

Braintrust

The concept behind the Braintrust team is that it is a team made up of their most senior writers and creative minds that can help to review the status of the movies on a regular basis. The objective behind these meetings are that these senior team members have a wealth of experience they can pass on to the team currently working on the movie on how the movie might be missing the mark.

There are a couple of simple rules:

  1. The feedback is not personal and it given in the spirit of making the movie the best in can possibly be.
  2. The feedback does not include the solution to the perceived issues and the Braintrust team has no authority to get the team to implement a certain solution.

The goal of the Braintrust is to highlight opportunities and then let the movie team determine the best solution. Questions may be raised in the next Braintrust review if nothing has been done since the last meeting, but there is no direction that they give the team on how problems should be solved.

Why?

Why do I like this model? On many projects I have been on we have tried to have some level of review and governance to help the project teams. But like many other people I know we have always struggled to get to the real issues that the project is encountering. Our checkpoints just didn’t highlight the areas of concern. So what was Pixar doing that we weren’t?

One thing I thought initially was that Pixar had their Braintrust be a team of 4-5 people. This is ideal as it brings a wealth of experience and also balances the project team and Braintrust out in terms of numbers. I think when an entire project team reviews their project with one person, the difference in numbers could allow for a pro-project point of view. This is not done intentionally, but could lead to the dismissal of ideas just due to the difference in numbers.

Culture

The project culture at Pixar is profoundly grounded in their culture. It can be summed up simply as:

“Projects are expected to struggle, a project running smoothly is not a goal”

Let’s think about that for a second. Management’s job is not to limit risk but to build the ability to recover. Management is doing their job when their teams are able to solve problems. I haven’t found this perspective in many software shops. In Software Development companies the goal is to have a smoothly running project.

This is quite different that the traditional approach where we have project checkpoints and see our role as management to try to solve the problems the team have and get the project to run smoothly again.

This approach frees the team up to be creative and try new approaches knowing management doesn’t view problems as some fault of the team. Pixar understands that the project team must become the ‘project’ they are working on to be able to achieve the objectives of the project. The downside of this is that the project team then loses some of their objectivity to be able to achieve the objectives of the project. The Braintrust can then assist in that regard to provide an unbiased view to help the project achieve all of the project’s objectives.

Summary

I think the Braintrust model has a lot of promise. I hope to try something similar in the future. If you haven’t yet read Creativity, Inc, do yourself a favor and pick it up.

Oh yeah and what is the #1 reason project struggle? They struggle because they are supposed to. Having a project without struggles means the project probably didn’t do much that was new or different or complex. Have a lot of those projects and your company isn’t moving forward any more.

Why I love coding

Recently I was asked by my wife to look into creating a little application to create a schedule for a softball season. I had done a bunch of coding within SQL, but hadn’t used a true programming language for quite a while. Most of my experience was with procedural languages and not Object Oriented languages. To be honest, I’ve always felt that Object Oriented languages are a bit bloated and that functionality might not be required for all solutions. I feel this is one of those solutions.

So I tried to search out a new procedural language I could play with. When I went to University and was gainfully employed, I was using procedural languages. Pascal, Fortran, Cobol, Natural, and C were familiar to me. After doing some searching I eventually I found Go. It seems to have the right mix of formality and informality that I was looking for to code this type of solution. My requirements were also pretty basic to just do some calculations and generate pretty basic output. So I started to install the tools and I started to code.

Enjoyment

I really enjoyed the process of coding and the joy was not unlike my son and how he enjoys playing Minecraft. It was all about being able to create things.

When I code, I take great pleasure is being able to essentially create a mini-model of the world and to be able to get that world to operate like I require. It is a bit of a kick to be able to control exactly how the computer program runs and what behavior gets executed. Even if that something is rudimentary like a Fibonacci sequence or generating prime numbers. Being able to duplicate a structure from the real world is fun, challenging, and provides a real sense of accomplishment.

Of course I’m remembering only the good times of my relationship with coding. Like any old flame, I’m sure I am forgetting those long nights arguing for hours about an improperly typed variable that caused a strange bug. But I am going to try to see if some of that old spark remains.

On the plus side, the IDE interfaces make all the languages look young and robust. How could I resist?

How #Empathy is fixing #Canada

I’ve talked about how Empathy is so important in understanding client needs in the past, how Empathy is important to understand what a client really requires and needs. The other side of Empathy is understanding what your team requires.

Ultimately, Empathy results in Prosocial behaviour. Prosocial is a term I only recently came across. Let’s quickly review the definition from Wikipedia:

Prosocial behavior –  “is a social behaviour that “benefit[s] other people or society as a whole, such as helping, sharing, donating, co-operating, and volunteering. Obeying the rules and conforming to socially accepted behaviors (such as stopping at a “Stop” sign or paying for groceries) are also regarded as prosocial behaviors. These actions may be motivated by empathy and by concern about the welfare and rights of others”

Ultimately this describes team behaviour and client service focus that we like to see in our project teams.

Canada

My country has always prided itself with having a good global conscience. But really until the last little while we have not shown ourselves to be empathetic at home. Let me call attention to a couple of recent news items. The tragedies of missing and murdered aboriginal women is the first item. For the longest time, the media and the majority of Canada have spent a lot of our efforts trying to state why this is someone else’s problem. We haven’t really empathized with the problem. We have hidden behind the fact that the situation was created by our ancestors and not us. In short, we felt comfortable doing nothing unless we were directly responsible. Myself included.😦

Let’s review the definition of Empathy again:

Empathy – “is the capacity to understand or feel what another being (a human or non-human animal) is experiencing from within the other being’s frame of reference, i.e., the capacity to place oneself in another’s position.”

We haven’t truly put ourselves in the shoes of the aboriginal families and really felt their pain. Recently we are starting. Canada has become outraged that this is happening and everyone has demanded as a whole that this be fixed now. Finally we have exhibited Prosocial behaviour and demanded that this is fixed even when it will result in no personal gain. In some way we are demanding change that will even hurt us by taking money and attention away from other priorities. But we understand that it is the right thing to do. Maybe we are finally gaining some true Empathy.

A similar occurrence has happened recently with the Freedom Road that is finally being built to address a long-standing injustice committed against Shoal Lake #40 First Nations who were isolated by the city of Winnipeg building an aqueduct in 1915. How it took 100 years for our community to become Empathetic and outraged at this situation is unbelievable. But at least now it is being addressed. Finally we have become empathetic and are being Prosocial with our demands from our politicians.

We can even see this recently with our neighbours from the south. For the longest time the United States were content to also determine excuses as to why the number of murdered black men were not a problem. Everyone investigated the victim’s past history, looked in their behaviour that night, and also said much of the violence was black man on black man so certainly there is no racism issue. Finally the United States is demonstrating Prosocial behaviour and also demanding that something be done to address these issues.

The truth is until large groups are willing to be Prosocial and take a stand on issues, they will never be addressed.

In retrospect, the majority of Canada was not empathetic to the massacre at École Polytechnique. 28 people were injured, with 14 Canadian women losing their lives that day. We grieved and mourned, but we didn’t truly empathize and demand action. The best we could muster in the past was Sympathy. We certainly have been sympathetic in the past but finally it seems Canada is learning how to be empathetic.

I see an interesting similarity with the Muslim people and countries around the world in relation to terrorism. Although people are sympathetic with the impact of terrorism, we haven’t yet reached an Empathy with the victims and seen Prosocial behaviours. Once we see those Prosocial behaviours, I have no doubt that the situation will greatly improve. Even with the recent tragedies in Paris, there is could be more we could do.

And I don’t believe building walls like Mr Trump proposes is a Prosocial behaviour. If anything, that is an Antisocial behaviour. By Prosocial behaviour I mean that we would see people independently organizing instead of assuming that it is only the Police’s job to stop terrorism.

Summary

Pretty heady topic for Christmas Eve, but it does relate back to our teams. Our high performing teams always are the ones that manage themselves and work together for the greater good and not just for what they need to individually accomplish. We are getting there. Nice to see our world is as well.🙂

 

Stop just #Innovating , start #Empathizing

innovative

There I said it.

Everywhere you go today, the focus is on Innovation as a verb. You must Innovate. There are Innovation Frameworks out there that define a framework on how you can generate Innovations at your work and personal life if you follow a process. Some of these frameworks are openly available while some are proprietary. There are even geographical areas that are designated with the Innovation titles to hopefully instill the belief that Innovation happens there before anywhere else. And then there are the individuals that have Innovation in their titles and seem to be somewhat responsible for Innovation at their companies.

Are we Innovation-ed out?

While the focus on Innovation and those Innovation Frameworks are valuable and can produce ideas and innovations, you shouldn’t stop there. The additional focus needs to be on why you are innovating. What pain or gain are you trying to achieve. Traditionally if your gain is just to make more money, then the life of your Innovation will be short lived. How do we then generate long lived Innovations?

Outcome

Innovation is an outcome rather than an action. I’m not sure how we got to the place where Innovation became an action and not an outcome. In some ways that is tantamount to changing for the sake of change. Let’s look at the definition of Innovation:

: a new idea, device, or method

: the act or process of introducing new ideas, devices, or methods

So what is missing? Well it seems like all I need to do is introduce anything new or different and I’ll be innovating. It could even be something worse.

The traditional definition of Innovation does not have any focus on value of the Innovation. This is a problem.

Action

OK Terry, well if Innovation is an outcome and not the action, what is the action that creates Innovation?

I’m glad you asked.🙂

First off the actions that create Innovative outcomes need to be client value based and not company based. If those actions are based on value, then the Innovations will also be based on value. If we don’t base Innovations on value we really will be changing for the sake of change. Some of these changes may be home runs, but others might be duds.

In business, value is defined and determined by the client. As much as we think some product or service has value, it only really has value when the client agrees to pay something for it.

So really the only methods that can result in Innovative outcomes are those that maximize client empathy and client understanding. Only with that understanding can we understand what changes will be innovative and result in more value for your client. At the core the Innovation needs to take away a client pain or provide a client gain.

If you need to be Innovative, seek to understand your client better.

Turns out those guys like Luke Hohmann, Clay Christensen, and Alex Osterwaldner were onto something.

But please stop only using Innovation frameworks to be innovative and generate innovations. Throwing a bunch of ideas at the wall to see if some stick is time-consuming and wasteful. If you focus on understanding your clients the Innovations will follow.

If you want to be Innovative, gather true Client Insight and Empathy.

Basketball Systems Thinking #Agile #systemsthinking

So my kids are playing Basketball in addition to playing Hockey this year. My son is 10 and my daughter is nine. They are quite similar players in both sports. My son could take it or leave it, while my daughter is a spark plug and high energy in both sports.

The interesting thing is they do not keep score in Basketball for both of their age groups. Even more interesting, this has had very little impact on my daughter, she is still the high energy spark-plug she has always been. My son, on the other hand has been de-motivated. He certainly is less motivated to give his best without the possibility of ‘winning’ the game. His behavior is not greatly different, but I certainly noticed it enough to have a conversation with him.

I thought it was quite interesting to note how a system change affected my son more as he was extrinsically motivated while my daughter was affected less since she was intrinsically motivated. She just loves the game and competing, no matter if someone wins or not.

Parents

The big change though was how the behavior of parents changed. Totally gone was the aggressive behavior of yelling at their children and the referees. I even caught myself almost challenging a call and then not following through at it would not affect the outcome. Without keeping score, the outcome is totally about being kids enjoyment and helping the kids to get better.

I’m not sure if the model would ever translate to Hockey as goal scoring is much less frequent in Hockey. Because you score 6 times in an average Hockey game versus 90 times in a typical Basketball game, the focus on scoring becomes much more intense.

It is interesting to see how a small change in a system affected the parents behavior so radically.

Something to keep in mind as we set up systems at work.

Top two rules of Performance Reviews – How to not make them a Candy Scramble

Just like everyone else I have had many great performance reviews and a couple of stinkers. I had a bit of an epiphany during an Empathy session at Protegra that clarified why some reviews go well and some go very badly.

First things first though. I’m finding these sessions at Protegra on “Empathy” and “Giving and Receiving Feedback” extremely helpful. I’ve been in the industry for over 25 years and this is the first time anybody has understood that Empathy and the process of giving and receiving feedback is an acquired skill. In many ways it is similar to estimating.

No Performance Reviews!

Many people are proposing that we should simply do away with performance reviews. I would propose that performance reviews are like estimates, they are not inherently evil. Could they be used for nefarious purposes? Sure, but almost anything can. I think if you follow the two rules of Performance Reviews you will find the reviews become much more useful and positive. When Performance Reviews are a negative experience it is usually due to what bad managers or leaders do with the review. Yea, kinda like estimates.🙂

The two rules

The training provided a great hierarchy on feedback which I found really helpful. There are essentially three types of feedback:

Appreciation – Informal, personal feedback on how someone is doing or has done something recently, Focus is usually just on the past.

Coaching – More formal but still personal Feedback on how someone has done something recently. There also is the added focus of coaching for the future as well as acknowledging the past.

Evaluation – The most formal of the feedback types. This is the performance review. Like coaching the focus is both on the past and the future, but there is also an additional component of ranking or evaluation to some standards of the role or competencies.

Rule #1

The types of feedback need to be provided by the same person in the order listed. I can’t expect to evaluate someone if I don’t have a relationship that has already involved providing Appreciation and Coaching Feedback. But yet, this is exactly what a lot of large corporations do! The manager is expected to gather and provide feedback sometimes with limited direct experience with the individual. This can lead to misinterpretation and incorrect emphasis being placed on some feedback received from others. In many cases, anonymous feedback is also incorporated with no personal context to allow that  information to be used appropriately. This is the Performance Review equivalent of a Candy Scramble.

Many times this is done because the focus is not on helping the individual to grow and get better, but to do annual performance reviews because that is what Human Resources says we need to do.

But if we focus on providing Appreciation and Coaching before we can do any Evaluation, it places the emphasis back where it belongs.

Rule #2

We need to make all types of the feedback a conversation. Again this is where having Appreciation and Coaching feedback sessions will help to make the meetings more conversational. In many large companies you don’t have a discussion with your manager until your performance review. You have no idea what he or she thinks, you get blindsided with feedback, and you say nothing when he or she asks for your thoughts. If you aren’t providing Appreciation and Coaching to your people, you are essentially ambushing them and not building relationships. These managers are usually the same people who remark after someone left that they are surprised and how they never said anything about being unhappy.

If we just have annual reviews without any Appreciation and Coaching discussions, they will never become conversational.

Summary

I found these types of feedback helpful and made it clear where performance reviews have been less than optimal when I had been giving and receiving feedback.

Another component of feedback is to make sure it is specific and actionable. Many times feedback ends up being vague and difficult to understand and incorporate. (Bob, we really need you to show more initiative) If we provide Appreciation and Coaching feedback we will find more specific types of feedback being provided. This is because those types of feedback almost always are grounded in specific examples that have been observed. Then the Evaluation feedback just summarizes what has already been communicated and the Evaluation feedback is less vague.

Of course providing Appreciation and Coaching feedback require time and effort, but the people we work with are worth it.

#Agile’s dirty little secret

I had the kernel of this blog post a few weeks ago. The idea of the blog post grew and crystalized after viewing Dave Thomas’s presentation ‘The Death of Agile’. It is easily one of the best videos I have seen from an entertainment and educational point of view. I really love watching presentations from people who are simply excellent at presenting. It gives you the same pleasure as reading a book by an author who uses the english language effortlessly.

If you haven’t seen the presentation yet, you can view it at the following link.

Dave makes the funny point of how the Agile movement first had to take a verb and turn it into a noun. No small feat to be sure.🙂

Presentation Recap

The first part of the presentation is a tongue-in-cheek view of the past history of the business of Agile. It is a very humourous romp through history. Very entertaining and Dave is such a great presenter you really wonder if he is joking or not. It takes us to get to about the 15:00 mark until Dave lets us in on the joke.

The Heart of it

Dave makes the point that we are taking what was a very valuable set of values and degrading it. Dave then states that it is time to reclaim Agility and take it back. Specifically, “It is time to take it back and deny the people who tell us how to do it”

Hallelujah.

There has been so much talk in Agile lately that unless you are doing some methods with no accommodation, you are not Agile. Not doing User Story Mapping? You are not Agile. Don’t have a true flow process in place? You are not Agile. Still Estimating? You are not Agile. Just doing iteration and mini-waterfalls? You are definitely not Agile and should do the walk of shame.

Agile Definition

Dave then gives us the best definition of Agile I have ever seen. He states that Agility is following these steps:

  1. Find out where you are
  2. Take a small step towards your goal
  3. Adjust your understanding based on what you learned
  4. Repeat

Simple. Right?

The hard part is all of us need to take the Agile Movement back from the precipice of being a noun and make it a verb once again. The Agile Manifesto understood this. Every principle had a continuum and action implied. They never said thou shalt never do Contract Negotiation again, but that we should move towards Customer Collaboration. Implied in that is that we should be always moving, improving, and adjusting.

I’ll go a step further. The Agile Manifesto should have a fifth principle added. The first four are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And I’ll state we should add a fifth

  • Seek to Understand and Coach people over judging and criticizing people

Summary

In short, we need to take a noun and turn it back into a verb. Agile isn’t something to achieve. Agility is a state of mind about constant improvement no matter where you currently are. Some of us are in Texas and some of us are in France just based upon the context of our projects, teams. and clients. We should always seek to understand each other and help to coach them. But always respect where they are first.

This blog post came about by reading Mike Cohn’s blog – “An Interative Waterfall isn’t Agile“.  Instead of judging each other we need to help each other and if some people have just made the step to Iterative Waterfall… well God Bless them..

Are #NoEstimates #UnCanadian ?

playing-hockey-lake-louise

Yep, I’ve come to realize that part of my trouble to rationalize the No Estimates movement is that they are UnCanadian. There are some things that become a part of you when you live and Canada and especially in the Canadian Prairies. Let me explain.

Schedule

As Canadians in the middle of the continent, schedules define our lives. It snows in late October and is bitterly cold December, January, February, and March. If I didn’t have a schedule that let me know spring will arrive in late March I am sure I would go crazy. In many ways, a schedule is the only thing holding our psyche together when we are shoveling 30 centimetres of snow with a windchill of -40. Like how can it possibly snow when it is that cold? We as a nation as obsessed with weather forecasts. If Meteorologists turned up tomorrow and said they were not forecasting anymore beyond today, I would go to some dark, dank corner of my mind in February.

I need a schedule. I need it to give me hope.🙂

Maps

When you live in a country this vast, a map is a requirement. Trust me, the last thing you want to do is get caught in some small town with out a Tim Hortons in the middle of winter. So as a consequence, I have this inherent need to know where I am in relation to where I thought I would be. In all seriousness, getting caught in the middle of winter not making your destination is a matter of life and death. Getting caught out in the elements will get you killed. More than anything we respect the power of nature.

So I think this Canadian life has ingrained on me that I need a map of the projects I work on. I need it to guide me and in some very real way, I feel lost and vulnerable without it.

Soccer

Canada is not a Soccer nation. Never will be. Oh sure we have some very talented players now coming up and we will continue to get better, but Soccer will never enthrall this nation like Hockey. Why? I’d hazard a guess is because part of the charm of Hockey is the combination of the skill, tenacity, and toughness. Hockey is the only sport that has a ‘diving’ penalty – where it is a penalty if you are trying to fake an infraction. Yes, I know that Soccer now has a ‘simulation’ penalty, but if you can’t even label the penalty as something shameful, how committed are you to changing the behaviour?

To be blunt, adopting No Estimates because estimates are hard to do and error prone, seems to be like falling down in the penalty area just to get a free kick. Yes, it might be easier and make projects go smoother for developers, but is it right?

No thanks. I’ll carry on, drink my Tim Hortons, fight through tackles and get better at estimating. I’d rather lose the right way than win on a penalty kick.

Why I hate and love #noestimates

I was watching a No Estimates video that someone tweeted recently and I was reminded why I hate and love No Estimates at the same time. The video in question is a No Estimates presentation by Allen Holub. You can find the video here.

I’d like to review the key points of the presentation and discuss the split personality of No Estimates.

0:20 – “We need to stop doing all estimates, now” – As much as some No Estimate proponents say it isn’t about not doing estimates at all, these extreme statements arise again and again. There much be some kernel of truth that they truly believe in this statement. It seems only when no options are available do they concede that you could do estimates if needed.

0:25 – “Estimation has no value at all” – Not your call. The only person that defines value is the client. If the client determines estimates have value, then the estimates have value.

1:01 – “Estimates are always wrong” – Not true. Many estimates are correct. In fact, I’ve had more correct estimates than incorrect estimates in my career.

2:12 – “Estimation leads to dysfunction. Estimation leads to working endless hours without needing to” – This is just bad leadership. Trust me, if you didn’t provide estimates these bad leaders would find other ways to set up a toxic environment. This is not the fault of estimates.

2:55 – “As soon as you have estimates you can’t have a sustainable pace” – Again bad leadership. Estimates are made to evolve and change. Just like other aspects of Agile, our estimates also need to have short feedback loops so we learn from estimates and then modify the future estimates for the project. It is curious how No Estimates proponents are well versed in Agile, but can only envision doing estimation in a waterfall method. It seems like estimates were the only item on their Agile projects that weren’t Agile. If they considered estimation with short feedback loops, I can imagine they would be less adverse to estimates.

3:06 – “As soon as you have deadlines you have people working 18 hour days” – See bad leadership mentioned above. If this is your environment, don’t blame the estimates. There are much deeper problems.

3:23 – “Your boss asks you how long something will take and you have no idea how long it will take, so you make a wild ass guess” – Really? If you have 3-5 years experience and have no idea how long something will take, you might want to find another career. Now there are some components that if you haven’t done before, you really may not know. But for the most part we are building things where we have some experience building similar items in the past. (I exclude from this Research and Development projects. I have been on these and understand they can’t be estimated easily. But those projects are not common.)

5:00 – “People don’t understand how estimates work” – This I agree with. It does take a lot of effort and communication to manage expectations.

6:12 – “CHAOS Report – Projects are late 80% of the time because of bad estimates” – Incorrect and oversimplification. I have been on projects where we were late but that was caused by people leaving, client needs changing, scope creep, and many other factors.

I really do like some of what Allen says in regards to Velocity, but it seems that Allen doesn’t even want to commit to a steady team velocity if nothing changes. In a sense, Allen proposes committing to nothing.

13:29 – “Estimating Software is like estimating Physics – How long will it take to create a Warp Drive” – This is a ill conceived argument. If you are creating something that hasn’t been done before, I agree you can’t estimate it. 95% of all Software Development is a variation on existing patterns and you can estimate it. Not perfectly, but adequately.

14:46 – “There is a disconnect from the people on the team. The catcher is disengaged and need to be engaged” – Again another bad analogy. The catcher and batter are not on the same team. So no, the catcher doesn’t not need to be engaged with the batter’s ritual. The pitcher’s ritual yes. This analogy is just totally incorrect and as a result, is not compelling at all.

15:15 – “There is no difference is estimating and locking your door 7 times” – I hear this from No Estimates proponents now and then. Comparing estimating to known Psychological disorders is dangerous, insensitive, and unprofessional.

15:50 – “Instead of a year long project, how about a month long project?” – Now we get into the part of No Estimates that I love! Enough about bashing estimation. Let’s talk about how we should shorten the feedback loops and minimize inventory. I would propose that we can also do this when we estimate. It just takes good leadership and management of expectations.

19:09 – “Mentally Deranged” – This is similar to my comment earlier about comparing estimating to true Psychological Disorders. This is just unprofessional and terribly insensitive.

21:32 – “The Business decides what to build and you decide how long it will take” – Agree 100%. Most of the previous bad examples seem to propose environments where the managers determine the estimates. I have never been on a project like that. Every project I have been on has empowered the developers with creating their own estimates. So we have taken 21:32 to get to how estimating can work. OK

22:35 – “Managers just manage schedule” – Great managers and leaders spend less than 10% of their time managing a schedule. The vast majority is working issues and helping to remove roadblocks for the team. Again the concept of manager is the Waterfall manager instead of the Agile Servant Leader manager.

23:25 – Never mind previous point.🙂

24:27 – “Waste is whatever does not put valuable Software into the client’s hands” – Allen changes the definition of waste here to suit his point. Waste is whatever doesn’t provide value, not valuable software. Estimates may still provide value to the client even if it doesn’t create software.

25:48 – “estimates don’t help, because you don’t know you in trouble until later in the project” – Huh? If I have estimates I will get feedback very quickly on whether we are in trouble. Again, this seems to imply a waterfall approach where you are not running iterations that you learn from every week.

30:04 – “counting stories is enough, we don’t need to estimate” – Allen’s point is we only need to make two decisions. Either we kill the projects because the end date is too far out or we can add people. That assumes the only criteria is date. He ignores the fact that the cost of the project may need to be known to ensure it makes money for the company. Killing the project wastes money already spent, adding people increases the cost of the project. As usual, No Estimates is ignoring the need for budgetary decisions.

34:00 – “User Story Map is not a static document” – exactly like estimates. Both are not static documents and they change all the time. But it takes effort and expertise to manage that change.

Summary

As you can see, I disagree with much of the presentation. I align myself with the concepts and principles of No Inventory that you find in No Estimates. I believe that No Inventory is crucial to successful Agile Projects.

The No Commitment and No External Empathy part of No Estimates I patently don’t agree with. Can estimates have adverse effects? Absolutely. But we need to manage those and appreciate why estimates help others in the business and managerial roles. Software Development Projects are there to make the corporation more money. We need to be careful to balance what makes sense from a Software Development point of view with what makes sense from a business point of view.

 

 

 

 

 

Top three reasons why #NoEstimates is not a professional Software Development approach #Agile

In a recent post, I stated that some aspects of the #NoEstimates approach is not yet a professional Software Development approach. I believe it could become a professional Software Development approach, but it isn’t one yet. Some people raised an eyebrow to this statement and rightfully so. When you drop a bombshell like that you certainly should provide rationale and criteria as to how you ended up with that opinion.

Remember that this is also just my opinion, so do with it what you will.🙂

 

Here we go!

1. The proposal and hypothesis should be clear, concise, and consistent

God help me, I really do have problem with knowing what #NoEstimates is proposing. Sometimes it is not doing any estimates – but do then again do them if you need to. Sometimes it is just working on a prioritized backlog and delivering in an incremental way delivering the highest priority items first. I find this ambiguity hurts the #NoEstimates cause more than it helps. If you believe in something, propose exactly what it is and stick to it. A lot of times we really don’t know what you are proposing that we should do. If you firmly  believe no one should do estimates, then say that and stick to it.

2. Don’t just criticize alternative theories

All the great ideas over time were able to stand up without criticizing alternative theories. Einstein never got on a soapbox and criticized Newtonian Physics. He simply proposed a new theory and illustrated why it described reality in a better way. The #NoEstimates proponents are actually hurting the acceptance by calling other methods ‘insane’ and ‘crazy’. It is almost the equivalent of swearing. Swearing is the easy way out of rationally describing your position to convince others of how it is a superior approach. To be clear, I don’t believe that a big-bang waterfall approach is better than Agile. But calling it ‘insane’ is intellectually lazy. I should be able to easily prove that to you. (and I can) Sometimes the discussions seem to resemble political attack ads more than anything else.

3. The facts should be available for peer review

Many times in discussions with #NoEstimates proponents I have seen opponents ask for the established companies that are using the extreme #NoEstimates processes of not estimating at all. Each time I usually get the response that they are soon going to interview them soon and would publish the results. I still haven’t seen any numbers published from companies that don’t estimate at all. So it is very difficult to validate the claims and whether the process would work in other situations.

Summary

In addition to these three characteristics, the inherent value of an approach is how wide the applicability is in the real world. If an approach is only viable in a controlled lab environment, then the approach is of not much use in the wild. For my money, an approach that is only applicable in a product company addressing only a very small share of the Software Development industry.

It probably is controversial, but the #NoEstimates movement has not yet demonstrated the widespread applicability in the Software Development Industry.

My Emotional #NoEstimates post

I’ve had multiple posts in the past where I’ve stated in very logical reasons why I believe in estimates. I’ve been thinking of penning an emotional #NoEstimates post lately. This is it.

Surgery

Recently a close family member underwent major abdominal surgery. As the surgeon said, all abdominal surgery is major. Things went exceptionally well due to the world-class surgeon and tough patient.

But there were two aspects of the event that were very interesting to me from a Software Development point of view:

Estimates

Yep, the surgeon provided estimates. Not just to me, but to everyone participating in the operation. You see, he was using a lot of shared resources that need to be co-ordinated across multiple surgeons and departments. You can’t just operate and then try to plan the next surgery after it is complete. There would be too much down time with critical health care resources. So all the procedures are estimated and scheduled on a priority basis to make the best use of scarce resources.

Complexity

The surgeon’s report was the other eye-opening experience. For all your Software Development professionals that think no other industry is as complicated at Software Development and therefore it is difficult to estimate, I recommend reading a surgeon’s report.

Every minute, there is a surgeon operating somewhere not knowing what he is going to find when he or she opens up a patient. And through their skill and tenacity they estimate the procedures and then do their work in the best interests of their patients no matter what the original estimate was. Just like in Software Development, it isn’t acceptable to not provide an estimate on the procedure. I’m not sure we would have chosen the surgeon if he stated he didn’t know how long the surgery would have taken.

The Emotional #NoEstimates part

We as Software Development professionals need to get over ourselves and lack of professionalism in thinking our industry is unique and we shouldn’t need to provide estimates. Do estimates have negative aspects? Yes, but it is our duty to handle those negative aspects and work with estimates. We need to be brave to offer our commitment and then work with our teams when those commitments may not be able to be met.

When were discussing the surgery, it was dicey as to if it could be done at all. The surgeon looked us in the eye, said that he was confident that he could be done and provided an estimate about the procedure and recovery. From that point on we were one team focused on the procedure and recovery. And when the surgery or recovery went longer we discussed the reasons together.

If we as Software Development professionals don’t provide estimates, I don’t believe we are being true teammates with clients. We are asking more from them than we are willing to give.

For it to be a true #NoEstimates partnership, we don’t need to provide estimates but would only get paid when a feature is implemented in production. If we don’t need to commit to the client, they should not need to commit to us until they want to buy the product. Equal risk for client and Software Developers…

Now how many #NoEstimates proponents would sign up for that?

 

What does #Protegra do?

I work for Protegra. I’ve worked here since July 23rd, 2001. I’ve performed in a variety of roles and worked on many projects for a wide variety of clients.

But many times we continue to get the question; “What do you guys do?” Some people limit us to a Software Development Consulting company. We often hear “I didn’t know you did that?” Other times people remember we like to do projects rather than resource augmentation.

So what does Protegra do?

We are a consulting company with people who endlessly care to find the ideal solution for the true business problem. Protegra endlessly strives to ask whether the proposed the solution is the best one. Is the suggested problem the actual problem or just a symptom? Can the solution be made better? Is this solution an ideal solution? Our focus is always on solution consulting before solution building. In our opinion, many people jump to solution building before solution consulting.

Have you confirmed you have identified the real problem and have identified the ideal solution?

Protegra solves a client’s business problems through the use of Software Enabled Solutions. Sometimes this is greenfield development, sometimes this is package integration, sometimes this may be mobile development.

The difference is in how Protegra does this. And there are three steps or methods:

1) Protegra uses Innovation Games and other methods to gather Customer Insight as to what the current pains and gains are for the client.

2) Protegra creates Empathy Maps to confirm the true problems and jobs to be done and create and propose ideal solutions to address those business problems.

3) Protegra then uses Agile methods to iteratively deliver solutions to remove the business problems as soon as possible in an iterative way.

When have we done it?

  • We have worked with inventors to realize their visions in a software solution
  • We have worked with government to create and propose a job matching solution in joint ownership with First Nations
  • We have worked with government to determine how we could deliver a Campground Reservation solution in 92 days – Parks Reservation Service
  • We have created a state of the art Payroll and Scheduling system with industry partners – Blue Canvas Group
  • We have worked with clients to find funding for ideal solutions though government grants

We’d love to help your company define an ideal solution to your perplexing problems.

 

Custom Software Development is dead

Haven’t you heard? Custom Software Development is dead. No one should have any reason to do Custom Software Development unless you are building a product to resell to clients. The creation of a novel solution created to address a specific client or problem is definitely passé.

Custom Software Development is much too risky. It is much less risky to take an existing product that has been created by an established vendor and just configure it to fit your needs. This is far less risky and quicker.

Custom Software Development is too costly. With our expert outsourced development team in some far way land, we can quickly develop software with inexpensive resources that will do everything you require.

Sound Familiar?

The truth is that Custom Software Development is not dead. Custom Software Development just needs to hire better marketing. For the longest time the product vendors have been selling Fear, Uncertainty, and Doubt about Custom Software Development.

To be honest, the really bad stories of projects going wrong are usually about product implementations. I mean the really bad ones. Not the 100% over budget ones, but the 300%-400% over budget ones with overruns of 10’s of Millions of dollars are usually always product implementations.

Most importantly, all the really terrible experiences of client satisfaction are with product implementations. Although Custom Software Development projects can have schedule and budget issues, I rarely hear that the Custom Software Solution doesn’t meet their needs. (When I say rare I mean like never)

Why?

So why do corporations continue to choose products instead of Custom Software Development? I believe it comes down to four reasons:

1) Corporations place less emphasis on a solution meeting their client’s needs than meeting the budget – This is a sad to say, but the real focus is on delighting the accountants and not the end users and clients. If I had a nickel every time I heard the phrase ‘good enough’ on a product implementation project, I’d be sunning myself on a private island in the Caribbean.

2) Product companies avoid getting into detailed requirements until after the initial sale – This is probably the biggest reason behind product selection. Early on the discussion are high level and it appears that the product is a 70-80% match of requirements. The decision is made to proceed and it is agreed that we will flesh out the detailed requirements during the project. Then during the project, you determine that there is only a 20-30% fit and more extensive work is required. Once that is determined it is far too late to change the approach.

3) Existing Products have inherent credibility and confidence – When faced with questions from boards and executives, the use of a product that is known in the marketplace does provide confidence. It also doesn’t hurt to say to executives you are offshoring development to save money. Both of these facts appeal to our human tendencies to never buy something first and to only buy something on a sale.

4) Corporations lack confidence in Information Technology – Many corporation lack confidence in their Information Technology departments and usually have a few experiences of Custom Software Development that has gone badly. Product Implementations seem to be the solution to both of these issues. Outsourcing the development to an independent Custom Software Development firm seems even riskier.

So what can we do as believers in Custom Software Development?

We can do promote the benefits of Custom Software Development ; You get exactly what you need and have full control over the solution going forward.

I heard early in my career that products are best used for the supporting and expense side of your business and Custom Software Development is best used for the core business and revenue generation side of your business.

If you don’t have full control to delight and serve your clients you probably won’t be in business long.

If you are thinking of making a product decision, ask your self if it involves the revenue side of the business. Then investigate how difficult it would be to materially change the product in the future.

If these change are difficult, your product may only be capable of generating new revenues for the product vendor.

Drunken Sailor #Agile

Recently I was reading about the immense operations the D-Day landings on Normandy were. I believe I had heard that it took over a year or planning just for the event itself. This included many practices and mock invasions.

Here are some numbers, courtesy of http://www.ddaymuseum.co.uk

“On D-Day, the Allies landed around 156,000 troops in Normandy. The American forces landed numbered 73,000: 23,250 on Utah Beach, 34,250 on Omaha Beach, and 15,500 airborne troops. In the British and Canadian sector, 83,115 troops were landed (61,715 of them British): 24,970 on Gold Beach, 21,400 on Juno Beach, 28,845 on Sword Beach, and 7900 airborne troops.

11,590 aircraft were available to support the landings. On D-Day, Allied aircraft flew 14,674 sorties, and 127 were lost.

In the airborne landings on both flanks of the beaches, 2,395 aircraft and 867 gliders of the RAF and USAAF were used on D-Day.

Operation Neptune involved huge naval forces, including 6,939 vessels: 1,213 naval combat ships, 4,126 landing ships and landing craft, 736 ancillary craft and 864 merchant vessels. Some 195,700 personnel were assigned to Operation Neptune: 52,889 US, 112,824 British, and 4,988 from other Allied countries.

By the end of 11 June (D + 5), 326,547 troops, 54,186 vehicles and 104,428 tons of supplies had been landed on the beaches.”

Could Agile be used for a project this size?

The question that went through my mind is whether projects can be too large for Agile?

I would say some project characteristics make the project less suited for Agile, but it isn’t just about size. In fact, the two factors that can make a project suitable for Agile don’t involve size at all.

Perhaps two definitions would help. When I am referring to Agile, I am believe there are two main types of Agile:

Drunken Sailor Agile – This is where there is an un-estimated backlog of user stories and the stories are pulled from the backlog just in time for the next iteration. These projects may not have an overall budget. Frequently these Agile projects align their processes with Flow. This is where No Estimates methods and practices are used.

Budgeted Agile – This is where there is an initially estimated backlog of user stories and a budget for the overall project. It most cases the project also has a tentative schedule on what is expected when during the project. These projects are typically done by large enterprises and companies focused on being profitable.

The Two Factors

1) End Product negotiable – Drunken Sailor Agile works really well when the end product is negotiable or unknown. In those situations, the ability of Drunken Sailor Agile to pivot returns great value. But when the Minimum Viable Product doesn’t differ greatly from the Maximum Viable Product, the ability to Pivot returns less value. Capturing half the beaches on D-Day wasn’t acceptable. It really was an all or nothing value proposition.

2) Predictability/Co-ordination – Drunken Sailor Agile struggles to provide any level of predictability and co-ordination. If you require predictability, you really do need to use Budget Agile with a schedule. In many cases this predictability may not be about when the project is complete. Frequently the solution is so complex and intricate that dependencies between components requires much more predictability that Drunken Sailor Agile provides. The amount of co-ordination required on D-Day would prevent Drunken Sailor Agile from being used. Ships and Aircraft needed to be exactly where they said they would be.

Summary

As you may have surmised, I am not a hug fan of Drunken Sailor Agile. And I think the projects that it can be applied to are quite limited. I don’t think it can work on large projects.

More importantly, I don’t like Drunken Sailor Agile as I think it creates an “Us versus them” atmosphere. We seem to be scared to tell clients when we will be done in case we are wrong. It all comes down to trust and Drunken Sailor Agile seems like we want to be trusted without providing our trust that estimates and schedules will be treated fairly.

I’m still in awe of the co-ordination and trust required for the D-Day operations. Agile has a way to go before we can approach those levels.

 

What is the #Compete Level of your #team ? #Agile

A phrase that is being used a lot north of the 49th parallel is compete level. Usually the term is used to talk about the level of effort by hockey teams. Another phrase that is also used in being ‘hard on the puck’. Basically both of these phrases try to communicate the level of effort that the team is displaying. In Winnipeg especially, losing is OK if everyone is displaying effort. Losing is OK, not trying is not.

Translation to Software Development

So then I started to think about how this translates to Software Development projects. My favourite and best project has always been those where our level of compete is very high. We have been very hard on the puck. We don’t think about whose responsibility that loose puck is, we all collapse on the puck/issue – high compete, hard on the puck.

These are terms very familiar to Agile teams. We have cross-functional teams because the teams can be more reactive to issues. Agile also stresses Client Focus as that focus will usually result in a higher compete level. If we care about the client and their requirements, chances are we will care more and go into the corners to get the puck and resolve issues.

Once you start to form defined roles it is easier to lessen your complete level. Perhaps there is the thought that my zone is back here and it is the centre’s responsibilities to get the puck in the high slot. I’ll just wait back here until the issue is resolved and someone gets the puck for me.

Relentless pressure and effort can overcome most obstacles.

What is your team’s compete level?

My new favourite #InnovationGame – #Agile Science Fair

IG

I was asked to do a session for the Agile Winnipeg User Group and the first thing that popped into my mind was Innovation Games. Innovation Games are a critical piece in Protegra’s offering to gain Customer Insight on all projects. Recently we have used Innovation Games to assist the Winnipeg Chamber of Commerce in creating their strategy. It really confirmed in my head that Innovation Games are the best way to gain Customer Insight no matter what the ultimate end product of the project is.

Agile Winnipeg Users Group

So I was very excited to be able to talk about Innovation Games and try one or two games in the session.  But it many cases, Agile teams have used Silent Brainstorming and parts of Innovation Games already even if they didn’t call  them Innovation Games. I wasn’t sure they would get the maximum value out of the event if I just did the SpeedBoat Innovation Game.

So I thought it would be the most impactful and fun to do the Product Box game. The idea was to do a Product Box on Agile. The objective was to create a Product Box that would let you communicate what Agile is and then try to sell Agile to their imaginary manager who has never used Agile. Fair enough. Seemed like fun

Staples

Ultimately though, Staples would not comply with our devious plans. This had happened once before when Luke Hohmann had presented at SDEC in 2012. Luke had graciously offered to also do a workshop the following day and one of the games we were playing was product box. But when I was looking for the plain white cereal sized boxes that we would use for our game, they were nowhere to be found. Eventually we found some mailing boxes that we could use for the game, but it wasn’t optimal.

So I was hoping that the lack of white cereal sized was only temporary at Staples. Nope. They were nowhere to be found.

They had the same inventory they had before…😦

Science Fair

With one huge addition. They had in stock tri-fold cardboard boards like the ones used for science fairs.

This, I thought, is freaking perfect!

The Game

We started off the session with a few slides on Innovation Games and then got into the Science Fair game. I had purchased stickers, colorful sharpies, and colorful 4″ letters. (Which I thought were stickers. They were merely punch-out letters. But our ingenuous teams managed in spite of me)🙂

I posed to them the situation.

“Your manager knows nothing about Agile, but you know it is the only way to develop software. Use all the supplies to create a poster board to communicate what Agile is and to try to convince your manager choose Agile for the next project”

I then also had purposely bought some animals stickers. I wanted them to use the stickers as Metaphors for Agile. I would ask why they choose a certain animal and what the animal represented about Agile. By doing this, I was using additional metaphors to gain insight into additional aspects of Agile they may not have communicated elsewhere.

The Results

Like all Innovation Games, we had fun and the teams produced projects that were awesome and I had greater insight into what each team thought about Agile.

But I really liked two aspects of the Science Fair game as compared to Product Box.

1) Real Estate – The teams had much more space to use to communicate. This allowed for more messaging and content then I would have had on Product Box. It particularly gave them room to draw.

2) Animal Metaphor – This was a neat twist I thought, but the insight gathered was truly great. Some teams used all the animals to show how teams had to be diverse, some teams used Giraffes to show how visibility was crucial to Agile, and then two teams used multiple reptiles to show how the Minimum Viable Product would be created and enhanced in each iteration.

Summary

It was a fantastic event and I think I’ll try Science Fair again when we need to do Product Box. The additional space allows for additional creative elements in the game. I think I’ll also keep the additional metaphor I used. That provided additional context and insight.

Be careful what you measure #SystemsThinking #Lean #Agile

I was reminded how important it is to be careful what you measure on the weekend. I had to call two call centers and both surprisingly implemented the same Service Level Agreements. Both promised that calls would be answered within two minutes. But surprisingly, both had implemented what I would consider ‘cheats’ to reach those measures.

Both Call Centers would not let calls get through until there were enough people available to guarantee the two minutes response time. Before that people would get a busy signal. I had to call back over 20 times to get a ring tone at one Call Center. They sub-optimized the system!

They were able to say they had two minutes response time because they excluded the hour of my time I kept on re-dialing until I was able to get a ringtone.

This reminded me of Helpdesks that solely measured the closure of tickets. This created the behaviour of Helpdesk analysts closing tickets even if the problem was not fully resolved. They just mentioned that another ticket could be created if the problem still existed. So again, they focused solely on their process, sub-optimized it and the customer suffered.

So be careful on what you decide to measure. In this situation the only measure was a two minute response time. So they changed the system so that they could meet that measure.

They focused solely on a measure that didn’t relate directly to the whole customer service experience. In the end they met their goal and possibly made customer service worse.

Stanford Design School’s Design Methods #WpgIIBA #InnovationGames #Empathy

I attended the Winnipeg IIBA chapter meeting where we reviewed the Stanford Design School’s Design Methods. The presentation itself was quite well done. We ended up splitting into pairs and went through the nine steps in the process. For our session we used the ‘gift-giving’ experience as a situation we could explore with the Stanford Design School’s Design Methods.

The Nine Steps

The Nine Steps in the Stanford Design School’s Design Methods are:

1) Interview – Use your interview skills to discover information about last gift giving experience

2) Dig Deeper – Dig Deeper in your second interview and try to focus on motivations for the gift giving experience

3) Capture Findings – Review the Finding and try to document the needs and insights discovered

4) Define Problem Statement – Define the problem statement discovered

5) Sketch – Draw at least 5 radical ways to meet the user’s need and address problem statement.

6) Share – Share your radical solutions and gather feedback from the user

7) Reflect – Reflect based on the feedback gathered and generate a new solution

8) Build – Build a prototype of your solution physically that the user can interact with

9) Review – Learn from your user playing with the prototype. What worked? What should be changed?

Review

I liked the process. In many ways the process reinforces the principles of short feedback loops in Agile and working in iterations. I have seen similar methods being used in Paper Prototyping and UX Design Studio. These hands on design methods work and engage the user.

Empathy?

I’m not sure if having a separate step to focus on Empathy and motivations result in greater client empathy though. Empathy is a personal relationship. Sometimes a 1-1 interview is a hard place to build empathy. Some users may not feel comfortable sharing their motivations face to face. Some users may not even be aware of all their motivations. Just telling people to interview to determine motivations probably won’t be successful.

So what to do?

Luckily we have the methods of Silent Brainstorming and Innovation Games to help uncover empathy and motivations. Unlike interviewing, these are different methods that allow lateral thinking to get to the motivations easier. I like to say they get you to the ‘why’ instead of the ‘what’

Innovation Games does this by the use of different metaphors. The metaphors use the psychological concept of projection. Projection is the process of people finding it easier to transfer their thoughts and feelings to another object instead of talking about themselves. This was typically done for the first time in Kindergarten when we had Show and Tell. Show and Tell is a great method to learn more about kids and their thoughts and feelings. With Show and Tell, kids will share how the toys makes them feel and not just describe the toy. This helps us get to the ‘Why?’

It is also a great exercise to get kids comfortable with talking in front of other kids as well.🙂

Designing too early?

In fact you may say that by asking what people want without asking them why we may be jumping to solution mode. If we know why, the what could be changed. Maybe the what they asked for is just one possibility.

Next Steps

Shameless Plug – I will be presenting on Innovation Games at the next Agile Winnipeg User’s Group on May 14th. Register and come check out other methods to discover Empathy. We will play 2-3 Innovation Games and hopefully learn about each other.🙂

A new Taxi Cab company in #Madison #unioncab.coop @protegra

With all the recent discussion of the new business model that Uber has introduced, I was surprised to find another company that kinda did Uber before Uber was Uber in my recent trip to Madison, Wisconsin.🙂 (Only Better than Uber!!!)

The Discussion

I was taking a cab from the Madison Concourse Hotel to the Pyle Center at the University of Wisconsin campus. (Go Badgers!!!) The first cab driver was very pleasant and dropped me off very promptly and quickly. I asked him if I could arrange a follow-up cab. He mentioned he couldn’t arrange for himself to be there, but handed me a card that I could call when I needed a pick up. (more on this later)

So I examined the card – Union Cab co-op. Interesting….

The drive back

On my drive back, I asked the second cab driver about the Union Cab Co-op company.

He described the history of how the Union Cab Co-op of Madison was formed. You can find all the details here:

Union Cab Co-op

There is a lot of detail in the article but it is summarized very well in the final two paragraphs:

Today Union Cab has gross annual revenues in excess of $7 million with approximately 230 active or probationary members and 65 cabs. We continue to operate under the principles of the Cooperative movement and maintain a “one-member, one-vote” worker democracy.

We intend to continue to grow, serving the transportation needs of Greater Madison, and providing good jobs at a living wage in a safe, democratic and humane environment. But Union Cab is more than just a business; it is an idea and an ideal. It is one of a very small number of worker owned and operated businesses in America. Some consider us the wave of the future, others think we will be relegated to the scrap heap of utopian idealism. Our Membership will determine which it will be.

My Thoughts

The discussion with my second cab driver/owner was the most pleasant and insightful ride I have ever had. We discussed the history of the company and how he has a voice at the table of how the company is operated. He also mentioned how he has a role to mentor new cap drivers and introduce them to the company.🙂 Then I thought back to Uber. I don’t know for sure, but Uber seemed to be less of a co-operative and more of a private company structure. They may be structured as a co-op, but their website doesn’t give that impression. It seems to be a model where you are more of an independent contractor and are afforded freedom, but don’t share in the control of the company or the profits. They certainly don’t talk about helping and mentoring each other.

I thought back to how co-operatives can be the solution to finding a compromise between private companies that maximize stakeholder profits sometimes at the expense of employees and unions that sometimes maximize union member salaries at the expense of private companies and taxpayers.

Protegra

We at Protegra are also a Co-operative. Everyone Protegran can be a shareholder if they want and can share in the profits. All Protegrans help to decide company direction and strategy. We are 100% employee owned.

I think this co-op model could have promise for many areas in the future. I do agree with Union Cab co-op, I think it is the wave of the future. The control of the company and the profits are shared by the people and not the company or union hierarchy.

Back to the Start

Knowing what I know now, I am even more impressed with the Cab driver who didn’t set up a follow up cab ride on the side. I know I have done this with other private cab companies and their bosses may not have ever seen that fare. I even know situations in Unions where members take extra shifts at the expense of other members.

But somehow this little co-op has build a team where companies and unions have failed. Interesting.

 

When #Lean isn’t enough – #novel

We all know about Lean. At least most of us do. We need to Lean our processes and organizations. We need to make them more efficient and less wasteful. But the problem is that Lean is only for incremental improvements. Given an existing process, how can we make it 5%, 10% more efficient? But the problem is that many opportunities for business aren’t just about incremental improvements in processes, we need to develop the new opportunities and products. Does Lean help with this? Absolutely not.

So what are we to do?

Novel Innovations

It is all about Innovation Games and Empathy Maps. With these tools and methods we can actually build customer engagement and try to develop Novel Innovations. With Novel Innovation we can discover new innovation that deliver new markets and services. No longer are we talking about 5%-10%. Now we are taking with total green-field opportunities that can offer 100%-200% growth. We are suddenly moved from a discussion of cost cutting to growth.

So how do we move from Lean to Novel? By changing our focus from internal to external. Instead of looking internally on how we can help to improve the internal working, lets look externally and see what the clients actually want and will pay for. No longer can we just look internally, incremental improvements are not enough.

If you aren’t looking at your customers. your competitors are.

I can’t stress this enough. Innovation is not an internal exercise. Many innovation frameworks look internally and discuss how to propose and gather innovation feedback internally. Without the involvement of the client and the building of client empathy, it is an unfocused effort that is not likely to succeed.

Summary

Read Innovation Games. Learn how to build Customer Engagement and Empathy.These methods will highlighted Novel approaches that will change your business and create the next generation of the business.

Why I Like #Estimates #NoEstimates #Visualization

There I said it. I like estimates. I like estimating. I think they provide value to my team and the customers. I will attempt to explain why is this Blog post.

1) Estimates make me think through a solution

I liken estimating to the visualization successful sport athletes do. It is the visualization and mental practice of what is likely to happen. Great athletes use this practice to anticipate issues and try to make every game as successful as possible.

When I estimate I am forced to examine project details and technology and think through the deliverables at a detail level and how we would build them. This helps to identify issues early and give the team and client lead time to decide on a resolution. When you discover issues late in the game, your options are limited and client anger usually follows.

If we just start building without doing detailed design and planning, the chance of project issues increase. I agree that you can do that detailed design and planning without estimating, but due to how estimates are used traditionally they result in people doing more detailed design and planning. This is because people know they are used for financial decisions and require some level of certainty. Estimates matter.

Now I don’t subscribe to estimates being used as promises and never being able to update the estimates. In fact, project estimates need to be updated weekly as new facts are encountered. This frequent updating of estimates needs to be discussed and agreed to before the project starts. Clients need to agree estimates are estimates, not promises or actuals.

2) Estimates create a shared understanding

One may disagree on the value of estimates. But I think everyone agrees that the discussions that occur while estimating are invaluable. These discussions create a shared understanding throughout the entire team. Yes I am assuming you are estimating with your entire team. If you are creating estimates for others then you have bigger problems than just estimates.

3) Estimates allow the clients to validate Minimum Viable Product before we start

Although the No Estimates approach and Story Slicing will allow the clients to have input and control over the work as it proceeds, it is still possible to start a project without the ability to complete a Minimum Viable Product with the available budget. Once you discover you can not deliver the required functionality, you may have wasted considerable budget. It is recommended that projects should not be started that have such a small profit margin. The reality is that most Information Technology projects have a small profit margin.

Will estimating Minimum Viable Product provide a iron-clad solution to this? Definitely no, we will estimate incorrectly at times. But as stated in point 1. The process of thinking through the problem does increase the chances of success.

4) Estimates allow Clients to allocate post Minimum Viable Product budget to other initiatives

In addition, the clients may want to allocate some of the post Minimum Viable Product budget to other initiatives and not to wait to see how a project goes just in case the project needs it. Clients are not going to reserve large budgets just in case an Information Technology project need it. Clients have a very limited budget and there are always more initiatives than budget. Allowing clients just to stop projects at any point does not recognize the lost opportunity cost by not starting additional initiatives that could have placed them ahead of their competitors.

One can even say that while No Estimates works well for one project, it doesn’t allow for the discussions and trade-offs required to manage a large portfolio of projects where the clients need to maximize the number of Minimum Viable Products delivered each quarter.

Summary

These are my reasons as to why I like estimates. It should be noted that I don’t recommend doing detailed estimates in any way shape or form. These estimates should be higher-level estimates that are:

1) At a deliverable level

2) Can be updated every week

3) Are created by the developers and clients

Why Customer #Empathy ?

Why should we bother with Customer Empathy? Many time we have seen the results. Either you deal with Customer Empathy or you deal with Customer Anger. It is much more efficient to deal with Customer Empathy when you define an offering than dealing with Customer Anger to fix the offering.

Sadly, most the time Information Technology initiatives are based in what we as Information Technology professionals think the customers want. At best, we have Information Technology empathy – we understand what Information Technology values.

Information Technology Empathy

So what happens when we have Information Technology Empathy? One might suggest that we can improve the cost side of the equation. Perhaps if we have Information Technology Empathy, we can reduce cost and become more efficient. Sadly, many times having Information Technology Empathy may not reduce costs. We may pursue Information Technology goals that may increase costs. And then the customers doubly suffer – we expend budget that makes their lives worse.😦

Many times this happens with Package Implementations. Software Packages are chosen to reduce risk from the Information Technology point of view. (Information Technology Empathy) Frequently the new Software Package reduces the value delivered to customers. Very rarely do you hear about customers extolling the virtues of the new Software Package – at best you hope the Customers don’t lose functionality.

Customer Empathy

Only with Customer Empathy can we improve the revenue side of the equation. If we truly understand what the customer values, we can design new products and services that they are willing to pay more for. Strangely enough, Customer Empathy will also allow us to improve the cost side of the equation. By knowing what the customer values, we can also understand what costs the clients will accept and potentially which areas could be trimmed without affecting customer value.

Summary

Many times we see plans being put in place assuming we know what the customer values. There almost seems to be a hesitation to ask the customers what they want. In this fast-paced world with so many options, be warned. If you aren’t going to ask your customers what they want, someone else will.

Four Information Technology Roles over time #agile #innovation

As I was evaluating the current role of Information Technology in our Industry I looked back and it seemed to be that there have been four distinct roles that Information Technology has played with business over the years

    1) Recording and Reporting 

This role focused mainly on Risk Mitigation. In the early years of computing, there was great value to be gleaned by entering data in a consistent way and minimizing errors. There was also great value realized by then having all the data in one location that could then be reported on to provide key indicators for the health of the business.

Information Technology implemented systems to record the current state or what ‘IS’.

    2) Automation

Soon after Information Technology had implemented solutions to help in Recording and Reporting, focus turned to larger problems like:

1) Automation of workflows/larger processes

2) Scalability

3) Efficiency

4) Availability

I often refer to this as the golden age of computing as we turned the power of the computer to problems that were much easier to scale and make more efficient using a computer rather than adding more people. The benefits were also realized in many workflow projects where Information Technology assisted people in guiding what they were supposed to do in the workflow process. In this phase, the increased computing power was also brought to the forefront to provide processing power that was only dreamed about 5 years ago.

In this phase, Information Technology implemented systems to take business beyond ‘IS’ and towards what business ‘COULD’ do with automation.

    3) Agile

With the Agile Manifesto, Information Technology ushered in the new phase of Agile projects. Now we were focusing not only on the outcomes of the projects, but also HOW the projects were being executed to maximize value. This was done through reducing Cycle Time, Maximizing Client Engagement, and through Visual Project Management.

In this phase, Information Technology implemented project processes that showed how projects should be run.

These first three phases focused on improvement, refinement, assisting the business to get better. We are now on the cusp of the fourth phase where Information Technology helps the business grow.

    4) Innovation

There is much talk about Innovation and how people must innovate, but it remains somewhat elusive. What is clear is that Information Technology has a role to play in helping clients Innovate.

Information Technology is uniquely position to leverage visual tools like Innovation Games, Empathy Maps, Business Model Canvas to provide business the brutal visibility that Information Technology provided previously about the projects in the Agile phase. What is clear is that the trend that Agile started toward visual requirements must continue. Specifications have improved from Specification documents to Use Cases to User Stories to A Business Model Canvas. Each one more visual that the prior.

What is also clear is that asking people what they want and documenting the response in words is a very risky endeavor.

For the first time, Business Models can be captured on one sheet and what-if-analysis can be done like in the first spreadsheet programs to evaluate options and alternatives.

In this phase, Information Technology is analyzing and recommending business processes that show how business can grow.

We won’t just be helping companies to get better, but to be different.

Hang on… This should be fun…

#Minecraft Code Club – Day 3 : An Open Letter to Teachers #mbteachers

Today we had a the third installment of the Minecraft Code Club. We reviewed some network diagrams and talked about how Minecraft works over the Internet. For the most part the kids got the concepts which I was just overjoyed with. We then looked at a couple of plugins and showed how we can modify the plugins to make the computer do whatever we want.

I was hoping to show them how to compile code today, but that didn’t work out. The kids were full of energy on a Monday and we had a bunch of other items that more than filled up all of the time. We will definitely do that next time. I was so happy that the kids remembered the metaphor I used that a plugin was like giving the computer program a needle. A couple of them even asked how you give the program a needle. Good times. We will definitely compile some code next session.

To Teachers

To all Teachers out there, I would like to convey two heartfelt messages:

1) I will steadfastly support reduced class sizes. Being in a class of great but energetic and inquisitive Grade 4’s gave me a little taste of how your days are. You want to help all of them, but there never is enough time. At the end of the session, I believe everyone had fun but I just thought how much better it would have been if I could have got all of them quick answers. At one point I was hopping between 3 tables that were having issues. They were so energetic and I never want them to lose that passion to frustration. I am going to volunteer to have a couple of follow-up days to just answer questions and have some one on one time – they deserve it!

2) I don’t know how you do it! We just worked on the exercises for 30 minutes and I was exhausted. The preparation you must do to be able to engage and inspire kids for an hour or an entire day has got to be considerable. The patience you are required to manage over 20 kids with differing styles and competencies is amazing. I discussed with a co-worker that a consultant can have no better test of their facilitation skills than a class of Grade 4’s.

To my Information Technology co-workers, if you think clients are tough on errors that occur in demos, you should try managing ‘glitches’ with a group of Grade 4’s. They were as demanding as a room full of vice-presidents – probably more so. But they were also more grateful when something did work. So I guess it all balances out.

To all the Teachers out there. Thank you.

#Minecraft Code Club – Day 2 #BoysAndGirls

image1image2

Well today was Day 2 of the Minecraft Code Club. Actually it was Day 1 again for a second group. This time it was for Grade 3’s. I modified the session a little bit based upon the feedback received in the first session and I think it went even better. We increased the Silent Brainstorming activities before we got involved in looking at any code. The kids did their introductory artwork on their favorite Minecraft things but then I also asked them what they wanted to learn. As usual with Silent Brainstorming, I always see ideas I never expected.

Here are some of the things they wanted to learn today:

  • Build a portal
  • Fight an Ender Dragon (I don’t even know what that is!)
  • Ride a pig, cow, and wolf
  • How to make a castle
  • Make a pig fly
  • Make jewels

Difference between boys and girls 

One thing I was fascinated with today was the difference in a session dominated by boys versus dominated by girls. The first session was almost entirely boys, the session today was almost entirely girls.

As the kids worked through the session, I made the following observations:

1) The girls were much more collaborative and social. They went out of their way to make sure other tables were being as successful as they were.

2) The girls were not competitive. They were more concerned about everyone being successful than about being first.

3) The girls were also much more open to ask questions. There was no hesitation to ask questions and to try and get help for what they wanted to do.

I should also say that my son Matthew also helped in the session and he was awesome. Couldn’t have done it without him and I was very proud how he helped everyone. I joked with Matthew he could be a teacher – he just said maybe and smiled.

Grade 3

The other observation I had was that Grade 3 would be the absolute youngest I would do the class with. Although they picked up on items quickly, they did less exploring and problem solving if they lost their way. They still grasped the concepts quickly, but maybe were a little less comfortable in the game and with a computer. They still did review the Java code and picked out the words that made sense to them. They also grasped what would happen if I assigned a large number to length…

They did validate that the model of teaching code to them that I am showing does resonate. When I talked about giving the Minecraft program a needle with our code, they laughed and understood that we were doing something to change a large program. (although we did have to clarify that the needle would not hurt)

In the next class I’m actually going to show them how we give the program a needle… Yes boy and girls we are going to compile code!!!

Good times

#Minecraft Code Camp – Day 1

Well today was day 1 at Minecraft Code club at my kid’s school. I was lucky enough to have a parent council that was crazy enough to listen to my grand design for how I would teach kids coding by looking at Minecraft Plugins. Even crazier, I was going to do this over lunch in three 35 minute sessions.

And I wasn’t going to teach coding by using scratch or any other graphical coding language. Nope. Straight into Java. And DOS commands, did I mention the DOS commands?

And then just for shits and giggles I was going to do in on Windows 8 laptops.

Yep, I’m a glutton for punishment.

Day One

Today was day one. I was going to introduce the concepts of a server, a computer program and look at a plugin to build a house. I had 21 Grade 4 kids in a library with 7 laptops.

It was fabulous.

The kids had all the energy and passion I would have expected. But I didn’t expect the questions on:

  • Can I show them how to do this at home?
  • Can I help them build their own server?
  • Can I help them build the Taj Mahal? (From a Minecraft book) Yes some of them even came prepared with reference material!

We even encountered a bug. Or a glitch as they called it. And they loved every second of it.

I must admit, so did I. Through them I relived the first time in my basement when I typed my first Basic program into my Vic 20. I fell in love. For a kid who couldn’t control much, I could create worlds. Everything was at my fingertips. Suddenly I didn’t feel so small and helpless. I could accomplish anything. Coding and Goaltending gave me the confidence to do anything.

It’s that feeling I want to instill in a few of the boys and girls. Through these lunch time programs we can show what is possible and how to create worlds. Maybe, just maybe, we can create some sparks in a few that will generate a love for coding. Now that would be cool.

Now where did I put that torch?

Innovation Games – Why do I have to keep repeating myself? #SpiderWeb

I’ve been busy recently on a lot of activities and my blogging has suffered as a result. Now that my kids Hockey Seasons are winding down, I find myself having a bit more time. I’m hoping that my pent-up blog posts will become much more frequent in the coming months. One thing that drives my Blog posts is having the time to read. It turns out I usually find the spark for a blog post from an article that I have read.

And that is what generated the idea for this blog post.

I came across an article that listed the following five tactics to “Focus your Business on your Customer”. It seemed simple enough and I was motivated on reading it as I was getting more involved with Business Development. So what were the five tactics? Well, I’m glad you asked.

  1. If you have a Client Relationship Management system or are considering Client Relationship Management System I want you to rethink why you need it.
  2. Tie all of your systems together to create an Integrated Customer Service System.
  3. Provide your customers with a portal to your system.
  4. Write a customer service manifesto that ties together the mission, vision and values of your organization.
  5. Put a new face to customer service if the old one has failed, and failed again.

Oh Boy

The article promised that “Do these 5 things and your customers will love you!”

Why do we need to keep talking about these things? In all the things being discussed, not a single one involves talking to the client! What does the client feel? What are their pains and gains? Do clients really care about your systems or the value they provide?

Why I love Innovation Games

I love Innovation Games for their singular focus on the customer. I adore playing Spider Web to highlight the interactions most of us don’t have with our clients. If you have never played the game, the idea is that you place your name at the center and the people you most interact with in a circle around you. You then draw lines to the people you interact with most frequently. Make the lines thicker for those people you interact with more frequently.

After all this is done, you ask the people to see how many actual clients they interact with frequently.

99% of the time this causes an audible gasp. And we wonder we why have challenges with our clients. We hardly ever talk to them!

When Data Modeling goes too far

One thing I have struggled with when I have created Operational Data Stores is the tendency to create generic tables that promote re-use. I find these are usually tables like Address and Person. In an enterprise environment there may be many applications or Systems of Record that store Person or Address information. There is the tendency when we create the objects in an Operational Data Store to store like information in one table.

Why?

In most cases having multiple Address or Person tables don’t violate any rules of Normalization. It is just a habit of organization to try to have only one table for a certain entity. We probably don’t have a requirement to report on all addresses together? Maybe for Person, but not for Address.

So the question is, Is this over-modeling?

Early in my modeling career I would have thought the question ridiculous. But now, I’m not so sure. If I had it to do over, I think I would duplicate some fields on different tables and leave the objects separate . Is there a problem created by having clients and Sales Representatives in separate tables with the same columns? Certainly the Data Model has more tables but it many ways it is way easier to understand and query. One of the main reasons I would do this is how generic entities can complicate querying and reporting. Although it can provide a more aesthetically pleasing data model, the opposite could be said of the queries that are required to pull information out of the database. And if the queries and reports are more complicated, the same could be said of the Extract, Transform, and Load processes to load the data.

Going forward, I think I will resist the urge to combine similar entities when there isn’t a business reason to do so.

How about you?

When focusing on Minimum Viable Product is the wrong thing to do #Agile #MVP

mvp

There isn’t too many things more sacred than Minimum Viable Product in the Agile circles. Maybe Planning Poker, Automated Testing, and Continuous Integration. But usually Minimum Viable Product is also right up there. What if I told you that focusing on Minimum Viable Product is sometimes the wrong thing to do? Would I be branded a heretic?

Well it is – sometimes.

Client Focus

I sometimes find that we in the Agile community are falling into the old traps that haunted the traditional Software Development Professional – the fact that we know what is best for the client. I see comments like we shouldn’t create any documents or create any estimates because they are waste. Usually these positions are written from the point of view of the Software Development team. But we as developers may define value and waste differently than our clients. We need to understand the context of the project we are in and the situation the client is in and apply our processes accordingly.

For some clients not creating documents may be a waste as they will need to create them for regulatory purposes and it may take them longer to create them after. (In addition to being more error-prone) For some clients, estimates may provide them great value in their forecasting and budgeting process. So while we may think that creating estimates in wasteful, the clients may not share the same view. Ultimately, their viewpoint is the one that matters if we want to be client focused and remain in the service industry.

Our job as Software Development professionals is to provide our expert opinion and highlights the impacts of the decision to the client. If we can’t convince the client of the value of our position, then our position could not have been a strong one to start with.

Our job as Software Development Professionals to to provide all the information to the clients so they can make the most well-informed decision possible. Not to decide for them. Ever.

Minimum Viable Product

So where does that leave us with Minimum Viable Product? How could organizing the project in a way that you could go live during the project be wrong?

Well, what if going live early has no value to the client?

In the diagram above, what if the client definition of value is only realized by being able to transport a family of 5? Being able to structure a project to continue to deliver Minimum Viable Products comes with a cost. If you look at the example above, you can see that so each step up in the viable product chain, we need to swap out some frameworks and functionality for other frameworks and functionality. Structuring a project in this way doesn’t come without a cost.

Now there are many great technical reasons why to want to structure a project focusing on a chain of Minimum Viable Products. They help to address risk and provide lessons learned to improve the product and project as you go along. But don’t assume that it is always what the client wants, needs, or values. In exceptional circumstances, the extra effort to structure a project focusing on Minimum Viable Product may actually be most wasteful that structuring the project in a traditional way.

There might be a series of Minimum Viable Products that could be created to address technical risk, but not to provide any early client value. Perhaps it might be just one prototype early on to address new technology. The important thing is don’t assume it has value for the client.

Summary

We must always remind ourselves that the processes and methods we use must return more value for the client than other options and not just fall into the habit of executing every project using all the Agile tools in the tool belt.

After all, isn’t that what got us in the Detailed Work Breakdown Structure, Big Design Up Front mess before?

 

 

 

A case for Contingency #NoEstimates

It seems like everyone has a different view of the role that contingency should play on projects. While some recommend removing it so as to not inflate the cost of features, others feel it is a critical element in the estimation of the project. Some people feel it is best to hide it away in the features themselves, while others like it explicitly separated for clear communication.

One thing is clear to me after many projects that have gone well and poorly. Contingency is required. Contingency is required to portray a realistic image of how the project will go. While many people try to remove Contingency to not inflate the cost of a project, it actually reflects reality.

Contingency is the cost factor of likely issues that the project will hit based upon the experience of the team and company executing the project. To remove contingency would be ignoring the past.

Even the noble attempt to remove contingency and work solely with feature velocity so that the team and the client can jointly work on the prioritization of features is misplaced. Removing that contingency will change the decisions made by the business early on. Without the contingency , the client may feel that they will get more done and will add more scope. Then once issues start being encountered, it becomes very apparent that the client won’t get everything they need because they added items early on based on the perceived velocity and lack of need of contingency.

For example, Let us say we have 100 features that we need to accomplish and based on the first month we determine we appear to have a velocity of 20 features a month. The project is required to go live in 6 months. This appears to be a solid 5 month project. Early on in the project we encounter 12 features that the client would also like to have. So we add them since we have an extra month. What we find a couple of months in is our velocity is really 16 not 20. (as we encounter some more difficult features) Now we determine we will only be able to complete 96 out of the 112 features we have. Although we are working in priority sequence, there probably are some features that the client can’t go live without.

We have a pickle. All because we didn’t use contingency to reserve budget and schedule based on realities.

To me No Estimates sometimes feels like doing Physics problems without friction. While the equations hold and produce logical results, they don’t reflect reality. And once you add friction to the equations, the change in the results can be quite dramatic. If No Estimates work for you, then you are probably more in the product rather than project space and I’m envious.🙂

But for the most part most of us need to deal with friction.

While No Estimates is intriguing, the removal of the analysis and incorporation of contingency is dangerous and can be deadly. While past velocity is an important factor, future planning and learning from the past is equally important. To manage mathematically based on past history is overlooking one very key factor – prior projects and experience. As we know most of the issues happen later on the projects. Contingency isn’t linear. Planning with only velocity requires contingency to be linear. In reality, we adapt to early velocity and make scope decisions based on that. They when issues hit that require contingency, it is no longer there as we have made decisions based upon what we think we can do based on past velocity.

Summary

Contingency isn’t evil or bad. It doesn’t inflate the cost of a project. If anything, it is the one thing that takes a paper plan and makes it real. Leave it out at your own peril.

#1 quality of a great team mate

Recently I have read a lot of articles and listened to many conversations that seem to place the individual ahead of the team. Frequently when we talk about group activities like meetings, paired activities, working from home, and co-located work spaces, the issue invariably comes up on how some people don’t see value in those activities. Some discussions take it a step farther and the state that people shouldn’t attend/perform those activities if they don’t see the value in them.

I believe we need to be careful that the focus on the individual doesn’t replace the focus on the team.

Meeting Value

I always thought that you get the most value from meetings when you are at the middle of your career. That is when you have enough confidence to speak up and still have a good amount to learn. When you are less experienced, you primarily just sit in the meetings and don’t want to be noticed. Late in your career, you have all of the experience to share but don’t learn as much from the meetings. If anything the value each person gets from meetings tends to look like a bell curve.

It is dangerous to look at meetings in the present and decide they do not have value for you. Perhaps at your current place in your career, they do have much value for you, but they may have all the value in the world for others. They may prevent a major issue for a teammate at a critical point in the project. (or in their personal life) Meetings and collaborative activities are all about communication and helping the team to be as efficient as possible. Many times the meeting will not provide a lot of value to an individual, but then at other times they will be invaluable.

I view working from home in a similar light. I believe it is the most efficient individually for most of us to work from home. We save an hour drive time and sometimes even save the environment from the hot water usage and gas usage to shower and get to work. But for the efficiency gained by one person, we typically have 4-8 others that now can’t just talk to you across the table while drawing on the whiteboard. It is true that technical tools can help to bridge the gap, but there just is no replacement for talking to someone and hearing the emotion and tone in their voice and seeing their face when working on an issue. So again we potentially have a trade-off between the efficiency of an individual versus the efficiency of a team.

So while it is very important to respect individuality, it is important for all of us to remember not to place individual priorities ahead of team priorities.

Now I would never recommend always placing team efficiency over individual efficiency. It is a balancing act that good people and great teams tend to master.

Great Teammates

But I do know that the really great teammates I have had the pleasure working with always think about what is best for the team and not just what is best for them individually. They are always learning and growing and eager to share what they have learned.

In thinking about it, the #1 quality in a great team-mate seems to be generosity. They are generous with their time, their talents, and their priorities. They always balance what they desire with what they know to be best for their team mates.

#SAP, Breaking Data, and Re-enabling #SQLServer Database Referential Integrity Constraints #Microsoft #FTW

Many times as Data professionals we no longer have full control over the quality of data in the source systems. I am discussing SAP in my example, but I could have easily mentioned PeopleSoft, SalesForce, or a number of other purchased solutions. Usually those solutions are purchased and then we are tasked with maintaining those environments and also extracting data from those environments to be incorporated into a Business Intelligence corporate solution.

Our issue is one somewhat of our own choosing as well. We want to enforce integrity and constraints at a greater level than what was intended and specified in the purchased applications. This may be for a variety of reasons including that the business never specified it as a requirement. It may also be that the purchased application was never built to handle that level of integrity.

To be clear, this isn’t a complaint but more a reflection of reality. We as Data professionals are going to receive data that is not as consistent and complete as we as Data professionals want it to be. (I purposely did not state ‘require’ as there could be a discussion of what is truly required) So what are we to do?

The Problem

Typically we end up extracting data from these purchased applications and load them into a consolidated database. This database can be either a relational or dimensional database. We also typically need to cleanse the data we are loading so load the business can report on the data in a clear and consistent manner.

The challenge is what we do with data that we cannot load in a consistent manner. We really have two options; modify the data or reject it outright. Although there are many types of inconsistent data we may need to correct, I will limit my discussion to data that links tables together. Typically we define Referential Integrity or Foreign Keys constraints to ensure that the data to link tables are valid so that reports and queries return correct results.

Possible Solution

When we have more control over the quality of source systems, I usually see the solution embedded in the Extract, Transform, and Load (ETL) solution that extracts and loads the data into a corporate database.  This is because the data issues will be more known, of lesser frequency, and the data issues are things we can correct ourselves. In this type of solution, the Foreign Key constraints are always enabled and the  ETL solution validates all the data values before trying to insert the data in the database. Any errors that are encountered will result in the data being changed or rejected and an error written to a log file.

There are two majors issue with this approach:

1) Performance – The look-up to validate all Foreign Keys row by row can cause the process to run slower. It can eliminate a performant two step approach where some of the fields can be set in a subsequent SQL Update statement. (Depending on the column’s Nullability) It can also prevent the use of some bulk load methods in SQL Server Integration Services.

2) Availability – If major data issues are encountered, the data issues may prevent the data load from continuing and may affect the availability of the database.

Our Solution

Since we are loading data from multiple external providers, we designed a different solution.

Although we have Foreign Key constraints on the entire database, they will be disabled during the load. (and during the week) We will enable them every Sunday to validate the data loaded has not broken integrity rules. If we find we cannot re-enable any constraint, we will email the Data Team informing them of the offending constraint for investigation. If all Foreign Key constraints can be re-enabled, we will inform the Data Team of the success and disable them again.

We could also do this re-enabling nightly if we start to encountered more frequent data errors.

In this manner, we are in a better position to react to data outside of our control and load the data as quickly as possible.

Our SQL Server Solution

A couple of things to note about our SQL Server solution. Frequently I see the solution to re-enable all constraints use the sp_msforeachtable stored procedure. A sample of how to do this is listed below:

EXEC sp_msforeachtable “ALTER TABLE ? NOCHECK CONSTRAINT all”

This solution is virtually useless you can guarantee all your constraints can be re-enabled without failure. If one constraint fails, it will stop the process. Not good.

To accommodate the ability to re-enable all constraints even when errors are encountered we created our own processes to disable and re-enable our constraints using a cursor.

Here is the disable constraints SQL

DECLARE @disable_sql NVARCHAR(255)

SELECT ROW_NUMBER() OVER (ORDER BY o.[schema_id]) AS RowID,
QUOTENAME(o.name) AS CONSTRAINT_NAME,
QUOTENAME(SCHEMA_NAME(po.[schema_id])) AS FOREIGN_TABLE_SCHEMA,
QUOTENAME(po.name) AS FOREIGN_TABLE_NAME,
QUOTENAME(rccu.COLUMN_NAME) AS FOREIGN_COLUMN_NAME,
QUOTENAME(SCHEMA_NAME(ro.[schema_id])) AS PRIMARY_TABLE_SCHEMA,
QUOTENAME(ro.name) AS PRIMARY_TABLE_NAME,
QUOTENAME(rc.name) AS PRIMARY_COLUMN_NAME,
CASE fk.is_disabled
WHEN 0 THEN ‘CHECK’
ELSE ‘NOCHECK’
END AS [ENABLED]
INTO temp_disable_constraints
FROM sys.foreign_keys AS fk
INNER JOIN sys.objects AS o ON o.[object_id] = fk.[object_id]
INNER JOIN sys.objects AS po ON po.[object_id] = fk.parent_object_id
INNER JOIN sys.objects AS ro ON ro.[object_id] = fk.referenced_object_id
INNER JOIN INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE AS rccu ON rccu.CONSTRAINT_SCHEMA = SCHEMA_NAME(o.[schema_id])
AND rccu.CONSTRAINT_NAME = o.name
AND rccu.TABLE_SCHEMA = SCHEMA_NAME(po.[schema_id])
AND rccu.TABLE_NAME = po.name
INNER JOIN sys.index_columns AS ric ON ric.[object_id] = fk.referenced_object_id
AND ric.index_id = fk.key_index_id
AND ric.is_included_column = 0
INNER JOIN sys.columns AS rc ON rc.[object_id] = fk.referenced_object_id
AND rc.column_id = ric.column_id

DECLARE disable_cursor CURSOR for
SELECT ‘ALTER TABLE ‘ + FOREIGN_TABLE_SCHEMA + ‘.’ + FOREIGN_TABLE_NAME
+ ‘ ‘ + ‘ NOCHECK CONSTRAINT ‘ + CONSTRAINT_NAME
FROM temp_disable_constraints

OPEN disable_cursor
FETCH NEXT FROM disable_cursor INTO @disable_sql

WHILE @@FETCH_STATUS = 0
BEGIN

PRINT @disable_sql

EXEC sp_executesql @disable_sql
FETCH NEXT FROM disable_cursor INTO @disable_sql

END

CLOSE disable_cursor
DEALLOCATE disable_cursor
DROP TABLE temp_disable_constraints

And our re-enable constraint SQL:

DECLARE @enable_sql NVARCHAR(255)

SELECT ROW_NUMBER() OVER (ORDER BY o.[schema_id]) AS RowID,
QUOTENAME(o.name) AS CONSTRAINT_NAME,
QUOTENAME(SCHEMA_NAME(po.[schema_id])) AS FOREIGN_TABLE_SCHEMA,
QUOTENAME(po.name) AS FOREIGN_TABLE_NAME,
QUOTENAME(rccu.COLUMN_NAME) AS FOREIGN_COLUMN_NAME,
QUOTENAME(SCHEMA_NAME(ro.[schema_id])) AS PRIMARY_TABLE_SCHEMA,
QUOTENAME(ro.name) AS PRIMARY_TABLE_NAME,
QUOTENAME(rc.name) AS PRIMARY_COLUMN_NAME,
CASE fk.is_disabled
WHEN 0 THEN ‘CHECK’
ELSE ‘NOCHECK’
END AS [ENABLED]
INTO temp_enable_constraints
FROM sys.foreign_keys AS fk
INNER JOIN sys.objects AS o ON o.[object_id] = fk.[object_id]
INNER JOIN sys.objects AS po ON po.[object_id] = fk.parent_object_id
INNER JOIN sys.objects AS ro ON ro.[object_id] = fk.referenced_object_id
INNER JOIN INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE AS rccu ON rccu.CONSTRAINT_SCHEMA = SCHEMA_NAME(o.[schema_id])
AND rccu.CONSTRAINT_NAME = o.name
AND rccu.TABLE_SCHEMA = SCHEMA_NAME(po.[schema_id])
AND rccu.TABLE_NAME = po.name
INNER JOIN sys.index_columns AS ric ON ric.[object_id] = fk.referenced_object_id
AND ric.index_id = fk.key_index_id
AND ric.is_included_column = 0
INNER JOIN sys.columns AS rc ON rc.[object_id] = fk.referenced_object_id
AND rc.column_id = ric.column_id

DECLARE enable_cursor CURSOR for
SELECT ‘ALTER TABLE ‘ + FOREIGN_TABLE_SCHEMA + ‘.’ + FOREIGN_TABLE_NAME
+ ‘ ‘ + ‘ WITH CHECK CHECK CONSTRAINT ‘ + CONSTRAINT_NAME
FROM temp_enable_constraints

OPEN enable_cursor
FETCH NEXT FROM enable_cursor INTO @enable_sql

WHILE @@FETCH_STATUS = 0
BEGIN

BEGIN TRY
EXEC sp_executesql @enable_sql
END TRY

BEGIN CATCH
PRINT ‘ERROR–>’ + @enable_sql
FETCH NEXT FROM enable_cursor INTO @enable_sql
CONTINUE
END CATCH

FETCH NEXT FROM enable_cursor INTO @enable_sql

END

CLOSE enable_cursor
DEALLOCATE enable_cursor
DROP TABLE temp_enable_constraints

Conclusion

This solution has provided us the flexibility to load our data as efficiently as possible and validate our Foreign Key relationships on a recurring basis. It also minimizes the chance that our load process will stop mid-stream. Did I mentioned this is a key requirements as we are loading data into the Data Warehouse every 60 minutes?🙂

I was initially concerned with how long it would take to re-enable the constraints, but it only takes 75 minutes to re-enable 616 Foreign Key constraints on a 1.1 Terabyte database. Thanks Microsoft!

Now that we have this process we also plan to use it on large software deployments just to ensure to major data issues were introduced with the deployment as well.

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.