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

Advertisement

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?

 

 

 

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

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.