#Zoom Leadership #PMOT #pandemic

There have been many excellent articles written and discussions had around great leadership traits in recent years. The concept of Servant Leadership from the Agile Movement and the excellent writings David Marquet emphasizing the role of curiosity is but to name but two. Many of these discussions have successfully moved the perception of a leader from an authoritarian figure to one of a collaborator/facilitator.

This morning I came across an excellent article on the role of humility in a leader. You can find the article here.

The article made me realize that the new leadership traits we have been talking about are observable traits of humility or being humble. Curiosity, collaboration, listening, vulnerability, patience, seeking opposing viewpoints, and acknowledging mistakes are all driven authentically from humility.

Can you be curious and questioning without humility? Sure, but you are probably just asking to prove you are correct, not to being open to new ideas.

Can you collaborate without humility? Sure, but you are likely to be promoting your ideas with the goal of convincing others.

Can you seek opposing viewpoints without humility? Sure, but you are doing this usually with the goal of proving your hypothesis, not to advance knowledge.

Can you truly listen without humility? Sure, but you are probably waiting on the edge of your seat for others to stop talking so you can once again lead the discussion.

Humble leaders understand that while they may be accountable for the decision, the entire team is responsible for the decision. And making the best decision is a patient process.

Pandemic Zoom/Leadership

Humility in a Pandemic is needed even more. Whether you are having meetings in WebEx, Microsoft Teams, or Zoom everyone is relegated to the same real estate on the screen. The power dynamics of in-person meetings are minimized, offices and titles are less apparent, and charisma makes a journey to Flatland. Technology makes us more equal.

As a result, imbalances in collaboration, talking, listening, asking, and seeking become even more apparent. One thing I have noticed about great leaders in these Pandemic times – they ask more than they state. And they are quiet and listening the vast majority of the time.

In the past, this may have been seen as being passive, but confidence is required even more to be silent, asking, seeking, and then deciding. And confidence is required even more to admit you don’t know, were wrong, or to promote a position raised by someone else. And that confidence comes from humility.

Yes, great leaders still are decisive, but how they get to great decisions are with humility, patience, and honouring their teams.

Please give the article a read. We should all strive to have Angela Merkel’s Intellectual Humility. It is an example of that old adage – “The more you know, the more you know you don’t know everything”

Pride divides the men, humility joins them – Socrates

Advertisement

All I need to know about Management and Leadership I learned from Dungeons and Dragons #PMOT#Agile #D&D

Recently I had the opportunity to play Dungeons and Dragons again. I hadn’t played since I was in high school and didn’t realize how much I missed it. D&D and I drifted away  after version 3.5 and all the advanced rules. I had heard great things about the version 5 so I thought it deserved another look. The thing that really triggered it was a fascinating article about how some middle-aged Dungeon Masters are becoming professional Dungeon Masters.

If you are interested in the article here is link: How to be a professional dungeon master host

Forming the Fellowship

So it turns out that if you work in Information Technology, all you need to form a fellowship is to mention you would like to play D&D. In the space of 15 minutes, I had six people wanting to play, four of them Druids. (Don’t ask me why, Druids were always my least favourite character class)

Before I knew it we had a party formed and were going on our first campaign. Those first sessions confirmed that my Management and Leadership style was indeed formed in those early Dungeon and Dragons sessions in my youth. I was amazed how many similarities there were between a good fellowship and great team.

Shared Vision

So I started off with the typical starting point for all good campaigns – Ye Old Tavern. Unlike my first D&D experience, the fellowship didn’t just accept the fact that we found ourselves in the Tavern. The fellowship spent an inordinate amount of time discussing their backgrounds, motivations, and history that would have brought themselves to this point. The was the first metaphor that applied to all good teams – everyone needs to understand what the shared vision is and why they are there. Only once that is understood can the team take on a new mission and campaign. Unfortunately, most of the time we just group people together and expect they will function as a team or fellowship.

Collaborative Storytelling

When I started to think about playing again I found a book called “Of Dice and Men” that reminisced about the memories of Dungeons and Dragons and told some of the history behind the game. One of the concepts the book introduced to me was that Dungeons and Dragons was so successful because unlike normal games, Dungeons and Dragons involved Collaborative Storytelling. Collaborative Storytelling involves the Dungeon Master creating the genus of the story and then works in collaboration with the fellowship to modify the story to create the best story, outcomes, and enjoyment. The primary thing is to accomplish the quest, but the path or plot may change based on the actions and decisions of the team.

Second metaphor for great teams and leaders. They start out with a shared vision and genus of what they want to accomplish, but the entire team contributes and changes the story as it evolves. Especially key to this is the fact that the Dungeon Master is not separate from the team. He or She doesn’t create an exact plot that the team needs to follow. (Although some Dungeon Masters, Leaders, and Manager do try this approach with very limited success)

For a truly great team, the Dungeon Master, Leader, or Manager must view themselves as a member of the team just playing a different role.

Now that doesn’t mean the Dungeon Master, Leader or Manager makes decisions by consensus. Sometimes they need to make a decision or ruling but they need to remember why they are making the decision. What is the intent of the fellowship or campaign? And most importantly a great Dungeon Master, Leader, or Manager encourages and incorporates team feedback to change the quest and story. It isn’t their story to solely own.

Helping Each Other

And finally the behaviour I notice most in Dungeon and Dragons fellowships is the coming to the aid of each other. It is extremely common for members to heal each other and shield each other from harm. It is the one behaviour I notice in every fellowship I have ever been part of. There is something about the game that really encourages risk taking that benefits others over yourself.

Summary

Perhaps instead of other ‘team building’ activities, we just need to break out the 20 sided die and remind ourselves how we succeed together. Even better, we should all take turns as the Dungeon Master to remind ourselves that the best Dungeon Masters, Leaders, and Managers exists to help the players level up, gain treasure, and enjoy themselves while solving a quest.

 

 

 

 

 

#Agile versus #Agenda – #Rugby versus #Football #PMOT #JIRA #Sciforma #Favre

We were talking the other day about software products that are used to help the execution of projects in either an Agile or Traditional manner. In particular, the discussion was the difference in models used in JIRA versus Sciforma. JIRA follows the Agile or KanBan model while Sciforma follows the Traditional or Scheduled model. The difference between the two models seemed to be grounded in the concepts of whether planning is done in the temporal dimension. (i.e. have we created a preliminary schedule of when activities or tasks would be done and considered dependencies) In fact, you can’t plan in JIRA temporalily without buying add-on components like Tempo-Planner. (Which is probably where they ended up getting the name from)

Rugby versus Football

First of all, when I mention Football I am referring to the American or Canadian version of football. Sorry european and world Soccer fans.

It then became apparent how good of an analogy Rugby versus Football is for Agile versus Traditional.

There were three important observations:

1. 1. 1. Agile isn’t better than Traditional and Traditional isn’t better than Agile. They are fundamentally different games. The methods and objectives are different.
      2. Although both sports have positions and specializations, Rugby players play in 100% of the game (pending injury substitutions), while Football players typically play 50% of the game. This is similar to Football where there is more specilization and subsituting of players.
      3. And perhaps the biggest difference – Rugby is a game more built on flow and reaction, where Football is built more on set plays that are planned and scheduled. (See where I am going with this?)

The point again should be that the games and objectives are different and that one game is no better than the other one.

Agile versus Agenda

My next thought was if we could find a nice, short term for Traditional like Agile that helped to convey the difference between Agile and Traditional like the analogy of Rugby and Football did.

When we look at the definition of Agile, we get:

“relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”

It took me quite a while and lot of research, but I think I finally settled on Agenda. Agenda is a term I don’t believe I have heard used when discussing Sotware Development. When we look at the definition of Agenda, we get:

“a list or outline of things to be considered or done“

The important difference here is that an Agenda is a list with a temporal dimension. In addition, an Agenda is perceived to be an initial plan that is to be modified and added to as agreed to. In fact, the first item usually asked in all meetings that have an Agenda, is if the Agenda needs to be modified.

Perfect. Agenda Software Development. Like Agile Software Development, but with an initial planned schedule, outline, and temporal dimension.

Finally a term that conveys the accurate intent of Agile Software Development with a schedule. And that schedule is to be changed, modified, enhanced, and pivoted.

Yeah, Agenda Software Development. That’s the ticket. And in an Agenda Software Development project where Brett Favre, the gunslinger, is the Project Manager. Yea, that’s the ticket.

 

 

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

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

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

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

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

Epiphany

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

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

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

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

Summary

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

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

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

That’s accountability – Nerd Style.

The Future of #AI Augmented Project Management is misguided #PMOT #Agile

I haven’t read a Project Management article for a long time that spurred me to write a bog entry within 24 hours. I had that experience yesterday after reading The Augmented Project Manager by Treb Gatte. This article provided an introduction to the interesting application of Artificial Intelligence to the Project Management role.

Treb discussing the three areas of Project Management that could be affected by the application of Artificial Intelligence:

• Planning
• Resource Allocation
• Tracking

Planning

Treb discuss the future of AI Augmented Project Planning:

“Imagine if your scheduling bot generates a proposed project plan, based on the aggregated and anonymized experiences of similar sized companies doing the same type of project. Today, we use tools like Monte Carlo to simulate this information. The bot could incorporate real world data, potentially yielding better results.”

Let that thought percolate while we moved onto Resource Allocation.

Resource Allocation

Treb then illustrates the possible future of Resource Allocation:

“For example, your resourcing bot determines that you need a social media expert on your project on April 5^th for two days of work. It searches data sources like LinkedIn and your public cloud calendar to find a list of suitable and available candidates. Three are West Coast of the U.S., one is in Paris and one is in Sydney. It then automatically reaches out to these candidates with offers. If multiple people accept, it automatically manages the negotiation. Once complete, the planning bot is informed, a virtual desktop with requisite software is provisioned, user login credentials are generated and the specific task information is sent to them. When the job is complete and rated as satisfactory, the bot coordinates with your accounts payable system to pay the freelancer. The planning bot automatically updates the plan and pushes the data to the BI dashboards.”

I’m not sure this illustration involves much Artificial Intelligence as it really if just about integrating with existing technologies and platforms – but I digress.

Tracking

And then finally Treb discusses what the future of AI Augmented Project Tracking might look like:

“Project feedback loops on work are awful. The largest challenge is incomplete data, which results from increasingly fragmented work days, limits of the worker’s memory and tools that rely on human input. It is also incomplete as it serves little benefit to the person entering the data.

Workers are overwhelmed with tasks arriving via multiple communication channels and no consolidated view.

Imagine a world where the timesheet is antiquated. Today, we have systems such as Microsoft Delve that know what content you’ve touched. We have IP-based communication systems that know what collaborations you’ve conducted. We have machine learning capabilities that can determine what you’ve discussed and the content of the documents you’ve edited. This week, we have facial recognition capabilities and other features that can track and interpret your movements. Given all of this, why is a timesheet necessary?”

Opinion

Oh boy, where to start? It seems like most of focus of AI Augmented Project Management seems to be on the collection of data that will make the results better.

• “If we have better historical data, we can plan better”
• “If we have better, faster access to resources, we can complete tasks better and faster”
• “If we have better real-time data on tasks, we can report status and adapt better”

The Problem

The problem was all of these perspectives is they seem to be promoting, advocating, and recommending less human interaction between Project Managers and their teams. If we only had AI augmented Project Management, we can go back to our closed doors and avoid the pesky human interactions. Agile Project Managers realize that human interaction is he crucible of project success – AI Augmented Project Management seems to have forgotten that.

Yes, planning is hard.

Yes, resourcing and building high-performing teams are hard.

Yes, tracking and adapting the project is difficult.

But the answer is more interaction, communication, coaching, caring, and collaboration. Not less.

I’ve even seen another article promoting that chatbots could help to get status updates from team members. Oh yeah, that will greatly improve communication of information. Developers will just love getting the impersonal 9:03 am greeting of “What are you planning to do today, what did you complete yesterday?”

Summary

I believe the idea of AI Augmented Project Management will end up on the trash heap with the CASE tools that were going to replace developers in the 80’s, Artificial Intelligence can assist augmenting individual competencies, but not replacing team communication, interaction, and problem solving. Perhaps, there is a role for Artificial Intelligence in reviewing plans and highlighting possible areas of concern regarding scheduling or estimation that a human can review. But the automated  creation of plans, resource allocation, task assignment, and task tracking is misguided.

The idea that worthy Project Manager work is stakeholder management,  but not team collaboration, engagement and communication is wrong.

Software Development is a team sport, and requires collaboration, communication, and engagement to plan, resource, and adjust. The idea that you can broadcast the skills you need and just drop a resource in to do a task and not worry about culture, fit, team dynamics, and personalities is pure hubris. These are people working on complex, nasty problems. They need time to gel, bond, and collaborate.

Sports is frequently identified as an area Artificial Intelligence has helped. Absolutely. Artificial Intelligence can refine skills like throwing a football and shooting a puck. Assisting in team dynamics and planning remains elusive. Coaches still call the plays and adjust plans. Even coaches that leverage technology realize that…

 

Best #Coaching book ever! #TheCoachingHabit www.boxofcrayons.com/the-coaching-habit-book

I must admit when I was strolling through Indigo the other day, I wasn’t looking for a coaching book. In fact, it wasn’t even on my mind. I was there to buy my son a book because he left his copy at school and needed to finish reading the book by Monday. (Sound familiar, parents?)

So while my son tried to find his book, I sauntered over to the business book section and came across this little gem.

Two Reasons

This book is a gem for two reasons; the content is awesome and the author can actually write. I point this out because I usually slog through business books because the content is great, but the delivery is lacking. This book was very different, I picked it up on a Sunday and finished it on Wednesday. The book to easy to read, has great anecdotes throughout, and also a sense of humour to lighten the mood.

Michael Bungay Steiner introduces the 7 questions that are key to a coaching discussion. I won’t go into exquisite detail here as I want you to run out and buy the book. But he starts off with the Kickstart question of “What’s on your mind?” and concludes it with the Learning question of “What was most useful for you?”. I don’t believe I have seen a Coaching method or book that includes a step for reflection and a retrospective. That combined with the question of asking “So what is the real challenge for you?” helps to cut through gossip, complaining, and unproductive coaching sessions/meetings. In short, this book is a must have for every manager and aspiring coach.

You even get a bonus of a brilliant 5 step method of facilitating a Strategy discussion. But I’m not going to tell you what it is, you have to run out and buy the book. There even is a complete set of entertaining videos to complement the chapters and reinforce the learning.

Run, don’t walk to your nearest bookstore or amazon.

 

The #Two traits great #Managers have #PMOT #Coach

Managers and management in general usually have a bad reputation. That is probably  doubly so for middle managers. These roles are usually the first ones identified for job reduction and attrition. Why is this? Truth be told, it is an exceptionally difficult role that not many people excel at. Usually people excel at one aspect or another of the role, but not at all of the aspects.

What makes a great manager?

So what makes a great manager? The manager must be an agent for the decisions and directions that come from above AND be an advocate for the teams that ultimately execute the work. Unfortunately, most managers tend to primarily identify with either agency or advocacy, but not both. Most managers focus their effort on managing the teams, but not managing the executives. Managing-up is one of the most difficult and challenging skills and most also be welcomed by the culture of the organization.

It is a delicate balancing act that experienced managers deftly handle – the right balance of agency and advocacy that promotes high-performing teams both above and below them. If this balance is not appropriate the manager usually defaults to just concentrating on one or the other – to the detriment of both executives and teams.

But when a manager has the right balance, they build credibility with both executives and teams. Once that credibility is built, the managers are then invited in to discussion and designs to influence, contribute, coach, innovate, and inspire both executives and teams.

Two Traits

The two traits that a manager or Project Manager must have to reach this level of proficiency are Business Knowledge and Realization Knowledge.

• The manager or Project Manager must understand the business domain, business strategy, and culture of the organization they are an agent for. Why does the Business Exist? What is the Strategic Plan? Who are their internal and external clients? Who are their competitors? What are their values and principles?
• The manager of Project Manager must also understand the realization domain and implementation processes as well. Whether the realization practice be accounting, engineering, software development, or teaching – the manager needs to understand the work and the profession. How do we implement changes? What professional skills are required? Who are the experts and why? What are the industry-accepted best practices? What are the new methods and technologies on the horizon? What practices are no longer being used?

Only when the manager has both these traits, will they have the credibility to be invited in, contribute, coach, influence, and help to innovate the strategy of the business and the implementation of business initiatives.

This is a not an easy combination to achieve and the lack of the these traits can lead to just ‘paper-pushing’ as the manager doesn’t have the credibility or knowledge to do more. Most times a manager may have one or the other trait and while this is beneficial, true high-performing teams arise when the manager or Project Manager has both.

Our responsibilities as managers is not to just perform administrative duties, but to relentlessly inquire and learn both about the business domain and the realization domain. Only then will the manager be an integral member that makes the executive and team members better by coaching up and down.

#PMO Visual Management Tools #PMOT #Agile

I have now been the Manager of the Project Management Office at the University for Manitoba for over two years. One of the first items I struggled with was trying to determine how to visually communicate the status of the portfolio of projects in a visual, intuitive way. I was a huge proponent of visual reporting and communication from my days as an Agile consultant. A textual or tabular report of the portfolio of projects just doesn’t inform stakeholders easily as to the breadth, depth, and status of the portfolio of projects.

Epiphany

Late one day, I had a discussion with our CIO in regards to how he had seen a radar diagram used as a means to communicate the life-cycle of Infrastructure within an environment. After a short discussion, we had formulated a plan as to how it could be used to display the portfolios of our projects.

We had devised a template to show the following:

• Separate portfolio sections with
  • Projects represented by coloured circles of different sizes
  • Status of projects indicated by circle colour
  • Projects on hold indicated by a diamond
  • New projects shown by a distinct circle icon
  • Size of project indicated by size of circle
  • Indication of a project being over budget by a halo around the circle
  • Project phase indicated by the circle’s proximity to center of the radar
  • Project’s progress indicated by the circle’s overlay to show percentage complete

Results

The Portfolio Radar diagram has been refined over the months. but it is probably the most requested document the Project Management Office produces.

Recently, I have created a personal radar that I use to track my to-do items. Like a lot of managers, I usually have 10-20 items on the go that need periodic attention. These items can usually be categorized into 3-4 “portfolios”. The radar template is much more appropriate than the standard kanban board used for projects as the items can be recurring and of extended duration. Some of them can be standing items which are never really done. The “Personal Radar” is a great diagram for showing which items need to have attention paid to them next week and which ones can wait.

Like the Portfolio Radar, the Personal Radar indicates:

• Separate portfolio sections with
  • Items represented by stickies
  • Urgency of attention indicated by stickie colour
  • Stickie phase indicated by the Stickie’s proximity to center of the radar

This “Personal Radar” for the PMO Manager has been a great assistance to stay of top of multitude of items required in the PMO. The Personal Radar gets reviewed at the start of the week to plan the week and at the end of the week to ensure the items received the attention they deserved.

So far, this is becoming a key deliverable to stay on top of items. An example of the Personal Radar is show below:

Summary

The Portfolio Radar and Personal Radar have been excellent diagrams to use for communication of project status and task management. I’d love to hear your experiences with other means of visual methods for Project Management and personal management.

Student of the Game #PMOT #NHLJETS @srogalsky @MarkScheifele55

As I sit down to author my first Blog entry of 2019, I reviewed my recent Blogs. Although I knew I hadn’t Blogged for a while, I wasn’t aware that I had not Blogged since July 2018. I had gotten quite busy in my new role of Manager of the Project Management Office at the University of Manitoba, but I was unaware just how busy I had become. So one of my resolutions for 2019 is to create a new Blog entry every month.

In hindsight, joining the University of Manitoba was one of the best career moves I have ever made. I have grown immensely over the last 2+ years and learned so much from colleagues both within Information Services and Technology and with external units and faculties. I would highly recommend the experience working in Higher Education. The people are brilliant problem solvers and the problems are complicated and have high impact. But that isn’t the reason for this first post of 2019.

Student of the Game

I was fortunate enough to have worked with Red River College during my career and was honoured to be invited to Keynote the BTM Tech mash-up they were putting on. All I had to do was come up with a topic! I talked about options with the organizers and we discussed presenting on how projects are managed at the University of Manitoba and how the work environment is different between Private Companies, Government. Consulting, and Higher Education. I still wanted something to leave with the students in regards to habits and practices of successful team mates. I eventually landed on a Student of the Game summary at the end of the presentation. I remember talking multiple times with Steve Rogalsky on the concept of Student of the Game, We both had felt it described a set of behaviours that were inherent in all the great team mates we had worked with. Even better I was going to connect it with Mark Scheifele for a Winnipeg Jets connection. I think I had a winner!

So what do we refer to when Steve and I mentioned team mates that were “students of the game”? I came across a great article “How to become a Student of the Game” by Anthony Iannarino. In this article, Tony makes the following three excellent points:

1. Study the Fundamentals
   • The best performers in any endeavor spend a great deal of time studying the fundamentals. They read, study, and practice the basics. The best performers are willing to spend time on the plateaus, plugging away at the basics, even when it feels like they aren’t making any real progress.
2. Make Distinctions
   • Reading, studying, and practicing are what allow high performers to make distinctions. They start to notice things. They notice things about themselves, and they notice things about others. They start to see how tiny changes produce outsized results.
3. Teaching and Learning
   • The highest performers seek out teachers. They know that someone who has already had the experiences and made the distinctions can help them understand their own experiences and make their own distinctions. They’re excited about the prospect of someone facilitating their learning.
   • These high performers also learn by teaching others. The very act of sharing what you have learned takes your mastery to new levels. It means you have to think deeply about the how, what, and why something works.

Mark Scheifele

I then connected the concept of “Student of the Game” with Mark Scheifele and reviewed how Mark is a great example of being a “Student of the Game”

• Selected 7th overall in 2011 in NHL Entry draft
• Sought out Dale Hawerchuk at 17 to seek advice and counsel
• Added Hall of Famer and skills coach Adam Oates to his off-season workouts
• Attended Gary Roberts Summer Hockey Boot Camps every year for 6 years
• Never swears on the ice – Respect for the Game

Summary

I added the connection to Mark Scheifele because of the concept of having Respect for the Game. This is something Tony did not mention but I think is critical for being a Student of the Game. The presentation even allowed me to connect the “Student of the Game” concept to the Agile Principles!

• Continuous Learning
  • Find a Mentor or Role Model
  • Get on Twitter – follow other experts and read
• Reflection
  • Review your work and others to spot opportunities
• Collaborate and Learn from others
  • Review others work and practices
  • We are smarter than me
• No Ego
  • Be respectful of others and their contributions
  • Understand that there are always things to learn and get better at
• Be Brave to be wrong
  • Help to create a safe space to experiment

All in all, I think this presentation touched all the bases and it was very well received. I encourage you to read Anthony Iannarino’s article and watch a Winnipeg Jets game. GO JETS GO!

 

How to #Innovate – an Example

How to Innovate

In my last post, I was stressing how encouraging Innovation is not simply about layering Innovation over existing processes and culture, but how it really is a change management project about changing the culture of an organization. If you missed it, you can read it here.

Reading through the Winnipeg Free Press today, I was provided with an example of how Winnipeg is not really committed to Innovation, but only interested in it.

The Example

So it turns out that the city of Winnipeg, is building a new library named in honour of former Mayor Bill Norrie and his wife Helen. This is a good announcement for something that is really needed. You can read the story here. I listed the CBC link instead of the Winnipeg Free Press because the Winnipeg Free Press has a pay wall. (but that lack of Innovation is for a later post at another time)

I say this is only a good announcement because libraries are always good things and the library will be addressing some shortcomings in other libraries in regards to accessibility, natural light, and outdoor spaces. And it is also beneficial that it will be connected to other facilities and public transportation. But it could have been so much more if Winnipeg’s leaders were committed to Innovation.

I’m reminded of the old joke about how the chicken is only interested about breakfast while the pig is committed to breakfast. Winnipeg is definitely interested in Innovation in Libraries as they have created Maker Spaces among other Innovations at some libraries.

How could they be committed to Innovation you ask? Well I’m glad you asked.

Empowerment

A key factor in Innovation is breaking down the hierarchy of control and empowering others – changing the culture. This involves those in control letting go of their authority. They no longer ‘approve’ the Innovations recommended by others and plan and design in isolation.

How would this look?

1. Libraries are a key service provided by the municipality and would be an area where the city can control Innovation if it was interested. So it seems like a very good example.
2. Define a Library Strategy of what Winnipeg wants to achieve with their libraries. Start with the mandatory items that are legislated like accessibility so it is clear what is non-negotiable.
3. Create working sessions and involve City of Winnipeg Council, City of Winnipeg Administration, Citizens, Universities, Educational Professionals, and children to help to define the Strategy. The only existing Library Strategy I could find was one to discuss whether we should build or lease libraries. That just made me sad. 😦
4. Once we have the Strategy, have the same group define what the short-term and long-term objectives are and how we will measure if we are successful.
5. Once we have the Strategy, Objectives, and Success Factors we can innovate and discuss the features that satisfy the Strategy best. A Library has to be more that just building with books inside. For example:
   1. What is the content we should provide?
   2. Ask the current administration how libraries can be improved?
   3. Ask City Council what their constituents are asking for?
   4. Ask the Teachers what is lacking in the libraries currently?
   5. Ask the students why they study at a Starbucks instead of a Library?
   6. How does the Library change with e-readers? Do we rent e-readers with content? Could we offer books in multi-languages easier this way?
   7. There is a movement to more group spaces in other libraries. Should we dedicate more group spaces?
   8. What other services could be partnered with Libraries?
   9. How do libraries change with Social Media? Do they?
   10. Are libraries next on the cusp of a Blockbuster/Netflix moment? Should we investigate streaming content?

These are just a few ideas. The key is to communicate what you want to achieve and then listen to your clients.

And here is the scary part, implement what they recommend. Majority rules!

That is the scariest part of Innovation. Executives still want to ‘approve’ innovations. A culture of Innovation believes that everyone has great ideas and majority rules. There is no knowing where the great ideas come from, but it is likely to come from those closest to the value.

Usually announcements like this are made once all those things are decided.  Getting everyone involved early and empowering them with real decision making would make these announcements great.

 

How to hire a Chief #Innovation Officer #FTW

Innovation

Innovation. We want to innovate. Everyone tells us we need to innovate. Everyone else is innovating and we need to keep up to them. If we don’t innovate we will be left behind. To this end, many companies are hiring Innovation Officers, Innovation Directors, or God forbid a Chief Innovation Officer. Some companies include Innovation in their name hoping to imply they are innovative just by having that name. Governments are adding Innovation to a Ministers Portfolio name in the hopes that they may generate Innovation. Even in my own city, Winnipeg, they hired a Chief Innovation Officer and are trying to innovate.

Problem

So what is the problem? Surely it is a laudable goal to innovate, improve, and excel? Absolutely it is. The unfortunate fact is that the way people are addressing innovation has very little chance for success.

Why

Innovation processes can’t simply be overlaid on a corporate structure that wasn’t innovative in the past and Innovation will occur. In the case of the City of Winnipeg, a call went out for people to submit their ideas and those ideas would be reviewed by the Chief Innovation Officer, the Chef Administration Officer, Chief Corporate Services Officer and Chief Transportation and Utilities Officer.

Oh boy, where do I start on this one? Lets use bullet points:

• The people at the highest level are talented individuals but probably are not aware of Innovations required throughout the corporation. They are going to miss a ton of great ideas.
• What is the Strategy that Innovation is required to address? What are the objectives? A general call for Innovation will probably generate a lot of wasted time as Innovations are submitted that aren’t a priority and people will wonder why their submissions weren’t chosen. (Unless a meeting is held to do a retrospective on every submission, but my experience is that doesn’t happen in these Innovation Beauty Contests)
• If the Culture of the corporation was not open to ideas in the past, people may be hesitant to submit ideas formally via email. Some ideas may highlight inefficient processes that could implicate co-workers. So people are likely to just not respond. (especially if they would implicate supervisors and managers who hold power over them)

How to Innovate

So how would I create an Innovation Culture?

1. Just that. Realize that it isn’t about generating Innovations in your current corporate structure. Innovation is about a change project to change culture profoundly.
2. Invite people from across the corporation to participate in the Strategy Creation. If that isn’t feasible, at least communicate the Strategy in a meaningful way after it is decided. (i.e. a face to face meetings and not just sending a Strategy document out for people to read)
3. Engage the people who are interested in face to face Innovation meetings where groups can submit, discuss, and shape Innovation ideas with their co-workers. These sessions need representation from front-line staff, supervisors, managers, and executives.
4. Ongoing efforts to create a culture that is a safe culture for new ideas and suggestions. This is important. You can’t have Innovation if you don’t have a culture of Safety. You can’t have an open door for Innovation and a closed-door for everything else.

This would be a start, but it isn’t guarantee. It takes hard work and lots of communication between people and time. But there is no shortcut to Innovation.

Especially hiring a Chief Innovation Officer.

 

 

Is my #PMO #Agile?

I recently presented on Agile Project Management Offices at Canheit 2018 at the lovely Simon Fraser University Campus in Burnaby. The conference was extremely well-organized and had many great sessions. The only complaint I have is that there was no bacon, but that is a small point. 🙂

In putting together my presentation, I had a to think about what makes a PMO Agile? We all know what makes a Project Agile, but how did that translate to the PMO? To further complicate the matter there are different types of PMOs. There are PMOs that deliver templates, those that dictate a methodology, those that provide a Career Centre for wayward Project Managers, and others that try to do all of these things.

I’ve always felt that an Agile Project at its heart does three things:

1. Provides Brutal Visibility
2. Minimizes Inventory
3. Uses the Brutal Visibility and Minimize Inventory to deliver more value

Agile PMO

On first blush, those factors translated pretty well to an Agile PMO. But I still had to ask myself how did the Agile PMO deliver more value? I looked at Agile Projects again and how do they deliver more value? The one word that kept popping in my mind was that Agile Projects use Brutal Visibility and Minimal Inventory to Pivot or change the direction of the project. More important than that, the Brutal Visibility and Minimal Inventory allow the Pivot to be done in ‘an informed manner with limited waste’.

So ultimately I felt Agile Projects or Agile PMOs do three things:

1. Provide Brutal Visibility
2. Minimize Inventory
3. Pivot in an Informed Manner with Minimal Waste

Summary

So for projects, this means Pivoting to allow the scheduling/trading/exchanging of features to deliver the most value.

For a Project Management Office, these means Pivotting to allow for the scheduling/trading/exchanging of projects to deliver the most value. And for Project Management Offices this means understanding the best way to allocate people and budget to the work required. In my expeience, budget is far easier to allocate than people with the team dynamics and role mixtures that are required on a project.

Sadly, most Project Management Offices struggle with Resource Management and manage resources in a series of Excel Spreadsheets that are usually out of date by at least a couple of months. When Project pivot decisions are required, the Project Management Office is guessing at people’s true allocation. More importantly, the Resource Management system usually doesn’t track actual hours that would indicate the leading edge of problems on projects.

To be a true Agile PMO, a Resource Management system must be used where your Resource allocation is current and the ability to Pivot exists every day. We recently implemented a Resource Management solution and the data being generated/captured is just showing how impactful it can be.

Now how many of our Project Management Offices could be considered truly Agile?

You just have to work #here #HigherEducation

Here? Specifically? Well kinda.

But I’ve always said that it is best for an individual to have a breadth of work experience. In the past I have mentioned that I felt it was important for a person to have experience in a private company, a government agency, and a consulting company for a least a couple of years each. Each one of these models operate very differently and distinctly. And the interesting things is that no one model is better than any others. Each model has different drivers and priorities that drive their behaviours.

University

I’ve now found a found category to add to the list – University. University is a bit of a mix between Private, Consulting, and Government, but it also has characteristics present in none of them.

University does have the drive to improve and innovate from Private, the challenges of people coaching and change management from Government, and the lack of direct authority in a Consulting environment where you need to rely on the your skills as a facilitator, negotiator, and influencer.

But at University you need to do three models all at the same time and realize two additional truths:

1. Every Faculty and Department are/can be a company on its own. There are limits to any authority over them so the focus really need to be on bridge-building and selling the benefits of your ideas.
2. University culture is about questioning. But rather than questioning to show their own knowledge, questioning at University are done to make the idea better. While this can be frustrating, once you realize the questions are following the method of Socratic Questioning,  they are easier to accommodate.

Oh yeah, and with the need to facilitate and influence and answer people’s Socratic Questions, things just take longer….

But the solutions and ideas are really better.

 

First deadly sin of #Agile

I’ve always thought that for all that Agile got right, it almost got the same amount wrong. And most of what it got wrong had to do how it distanced the client from the project team.

Surprised?

Remember that although Agile was promoting co-located teams, the clients certainly had a different status than the other members of the project team. I’m still amazed that the Scrum segregation of clients and team members into chickens and pigs is tolerated. The basic premise is that although the clients are interested in ‘breakfast’ they aren’t as committed as the ‘pigs’. This of course is ridiculous and in many projects the clients have more on the line than the development team. But the most disappointing thing is that Agile seemed to inherently promote a hierarchy. Even outside of Scrum, Agile still seemed to confuse who defines value and the project team typically over steps their bounds and decide for the client. For example, the No Estimates movement deems Estimates a waste repeatedly although the only people who can determine what is waste are the clients.

Semantics

Much of this can be tied up in Semantics. The terms of Client, Customer, Business User – all separate.

It wasn’t until we were talking terminology in a more traditional project structure that we decided there was a much more appropriate term:

Colleague – ‘A person with whom one works in a profession or business.’

Or even better, from the Latin collega or ‘partner in office’. Finally a term that does not imply a hierarchy and instills the promise of a partnership working toward a common goal.  All colleagues working to create the highest quality solution to a problem.

Colleagues delivering frequently to minimize Inventory and shorten Feedback Loops.

Now that is Agile.

 

Death of #Agile #PMOT

OK, so maybe Agile isn’t dead yet. But I think it is certainly starting to suffer from the same disease that ultimately claimed Waterfall and other methodologies. As usual, Steve Jobs saw the issues years ago:

Content over process

Process over Content

Once the focus is on process over content, the patient starts to decline. Process is supposed to improve content by providing guidance and predictability. But if the process is followed blindly and no autonomy is given to team members to customize process, we have placed Process over Content. This happened late in the Waterfall days with additional focus on CMMI ranking and achieving other process certifications.

Most troubling is a lot of the discussion is the Agile world lately is about process and not content. We are talking about who is more Agile than whom. We are talking about absolutes as to how estimating is bad and that estimates should NEVER be done. We are talking about absolutes rather than compromises. You are ignoring Content when discussions gravitate toward absolutes. Is it a key indicator that you are no longer evaluating what needs to be accomplished or what value is. The discussion now is darn it, come hell of high water, we will be doing User Stories, with relative estimating, or not estimating at all. And it doesn’t matter what the clients think or what success is.

I know this because people are writing books about absolutes and not about how to compromise.

But Terry, we do listen to our clients you’ll say. We wouldn’t be doing our professional duty if we didn’t promote our preferred approach. We then customize after.

Fair enough. But your preferred approach is all about process and not content. Process enables content, but process is not content. Your focus is on the process….

I’ll let that sink in…

 

A year at University #UManitoba

I have now been employed at the University of Manitoba for over a year now. I’m not sure I knew exactly what I thought it would be like working at a University, but I thought it would be good to reflect on what I have learned over the past year

The first thing that has occurred to me as I look back is that I have never, ever been more proud of where I work. The ability to contribute in some small way to the advancement of education, research, and advancement of the students at the University of Manitoba is truly inspiring. I have always been proud of where I have worked in the past, but most of the time the outcomes assisted large private companies. I just find that isn’t nearly as rewarding as ultimately playing a small part in the educational system.

The University is an environment where ideas are fostered and critical thinking is encouraged. This environment promotes collaboration perhaps more than any other place I have been in. But the University somehow continues to foster collaboration within a structured environment. This should not be minimized, in my experience the introduction of structure usually caused the reduction of collaboration. This is not the case, if anything the structure at the University of Manitoba encourages collaboration and the fostering of ideas. An important factor that contributes to this culture of collaboration is the concept of peer review. Although peer review is commonplace in the research areas, I’ve never been in a work culture where it manifests itself in the entire organization. People actively seek out each others opinion and truly expect feedback and critical review of their ideas that can help to make the ideas better. This ends up making all the ideas the best they can be and helps to make the collaboration enjoyable and without conflict.

That isn’t to say, there aren’t challenges. But a lot of the challenges come from just how large and diverse an organization the university is. Once an issue to identified, the perspective is just focused on what is the best solution is to the issue at hand.

Ultimately, the University of Manitoba is a community and has a culture all its own. I’ve worked in other placing that tried to define their culture and community. I realize now that to have a community and culture you need to have a diverse group of citizens that are all committed to the ultimate goal. For the University of Manitoba, that is education. I also realized that you define culture by thousands if not millions of small, meaningful, thoughtful acts. It is something you can’t create.

I’ve appreciated that the culture of University of Manitoba is defined by millions of meaningful, thoughtful, insightful, professional, and intelligent ideas – repeated.

Oh, and I love working on a campus with historic buildings, green spaces, and co-workers of the same mind…

And geese…. I love the geese…

In #PID I Trust #Prince2 #PMOT

I’ve been using Prince2 as a methodology at the University of Manitoba for almost a year now and I’m quite impressed. As a methodology it is quite good and focuses on the right things. Prince2 recognizes that a project initiated well sets a project up to succeed. There three things Prince2 does during initiation that I feel set it apart from other methodologies.

Project Initiation Document – PID

The PID or the Project Initiation Document is the main initiation document in Prince2. We commonly refer to the PID as a Project Charter on steroids. The table of contents for a typical PID contains the following

• Business Case
• Project Definition
• Product Based Planning
• Project Approach
• Project Governance and principles
• Quality Management Strategy
• Risk Management Strategy
• Organizational Change Management Strategy
• Organizational Capacity Management Strategy
• Project Plan

As you can see from the table of contents, the PID is a much more in-depth document and agreement than the typical project charter. It also more of a strategy document than project charter by getting the project team to discuss and document strategies for Quality Management, Risk Management, Issue Management, Communication Strategy, Change Management Strategy, and Capacity Management Strategy.

There are two sections of the PID that go right to the strength of Prince2

Project Governance

One of the main strengths of Prince2 is the Project Governance and formal Project Board structure. In Prince2, the Project Boards makes all the decisions for the project and is made up of the following three roles:

• Executive – Main sponsor or project champion – typically provides the budget
• Senior Supplier – typically provides the resources for the projects
• Senior User – typically will use the solution operationally when complete

These three roles are unique compared to other methodologies and it really serves the project well to ensure that all decisions are made in a balanced and thoughtful way. The really unique part of the Project Board structure is allowing for a seat at the table for the Senior User. Typically the users of the solutions don’t have a leadership role and only get involved for requirements definition and testing. By getting involved earlier, the Senior User has the ability to guide the vision of the solution. In my experience, this really allows for great value being delivered and fewer subsequent enhancement requests that are required to make the product useable. 🙂

Product Based Planning

Perhaps one of the most valuable Prince2 concepts is the Product based planning. This term refers to the Prince2 focus on what products the project is going to produce. Prince2 has a deliverable named Project Product Description. The Project Product Description is intended to describe the ultimate product that the project will produce. This deliverable helps to focus the project team to describe what project success will accomplish before defining detailed requirements. This process is very helpful and helps to create a shared vision across the project team. Prince2 then tasks the project team to define the interim product descriptions that are needed to ultimately create the Project Product Description. These Product Descriptions could be documents, demos, prototypes, or anything that is created during the project. A Product Breakdown Structure is then created to define the order the products and sub-products are created in. This Product Breakdown Structure is an excellent vehicle to uncover dependencies without having to create a detailed work breakdown structure.

By creating these three descriptions/documents, a lot of clarity is provided to the project team on what will be accomplished, what interim steps and documents are needed, and what order the project team will create them in.

Agile?

Right now, I bet you are wondering just how top-heavy and cumbersome Prince2 is. The real benefit of Prince2 is that these deliverables can be detailed separate documents or a few paragraphs in the Project Initiation Document.

Prince2 has two principles that align it with Agile:

1. If you don’t customize Prince2 methodology then you are doing it wrong. The customization of Prince2 is one of the 8 foundational principles of Prince2
2. Prince2 is perhaps the only Manage-by-Exception methodology I have seen. There is a section in the Project Initiation Document that defines the acceptable tolerances for the project. Only when the project goes outside these tolerances, does the Project Board need to be involved.

So Prince2 formalizes space for the project team to work and not be micro-managed.

Sounds more Agile than Scrum if you ask me…

Can a Project Management Office be #Agile #PMOT #PMO

Can a Project Management Office be Agile? Should it? Can agilist succeed in Project Management Office?

I must admit I had thought that a Project Management Office was one of the most non-Agile entities in an enterprise. I viewed the PMO as a command and control type of structure that primarily just created templates and enforced standards. It turns out that an enlightened PMO behaves much like an Agile coach.

The first two types of PMOs do appear to be very traditionalist. Those first two types deliver limited value to the clients.

PMO Level 1

The goal of this level of PMO is typically standardization and repeatability. The vehicle for this to be achieved is usually templates and standard project deliverables. While some level of consistency is good for projects, these templates and deliverables provide most of their value to the Information Technology organization and not the client. Given that Information Technology should be a service provider to the entire enterprise, this type of PMO is a hard sell to the clients. This type of PMO is also not very Agile as the entire focus is on obedience to the templates.

PMO Level 2

Some time after the PMO Level 1 is set up and projects are still not consistent or standard, there becomes a secondary focus on the Projects Managers themselves. This type of PMO becomes a type of Career Centre to help coach the Project Managers in their career. This type of PMO is starting to recognize that projects and project managers are unique and it isn’t as easy as just defining standard templates. There needs to be more discussions and accommodation with project team members to achieve success. This type of PMO is more Agile, but still limited in the extra value it provides client. Ideally, the extra coaching of Project Managers will deliver more value to the clients, but the focus is still Information Technology.

Thankfully, the last two types of PMOs turn and focus more on the client than Information Technology.

PMO Level 3

The third type of PMO signals an important shift in focus on the PMO. As the enterprise and the PMO grows, it becomes apparent that the PMO is still not returning much value to the clients. As moe and more projects are executed in parallel it becomes harder for the enterprise to keep track of everything. At this level the enterprise requires the PMO to produce consolidated Project Reporting and then soon after Project Resourcing. Now finally the PMO is providing value to the clients by providing brutal visibility as to the status of each project and helping to prioritize the projects, people, and initiatives across the entire organization. There is never enough hours in the day, but the PMO can help by coordinating effort towards the most important activities.

Suddenly, this type of PMO is starting to appear quite Agile. Brutal Visibility and Collaborative Prioritization!

PMO Level 4

The fourth type of PMO continues that shift in focus to providing client value. Now that the PMO has provided Brutal Visibility and Collaborative Prioritization for projects within the PMO, how can that be extended outside the PMO? This is typically done by providing Governance over an idea or innovation intake process. The PMO are the stewards of the process that provides idea and innovation information to a representative committee for approval and prioritization to become projects. Usually this type of PMO is also tasked with providing additional Financial Information that will be required to determine the number of ideas or innovations that can be turned into projects.

This type of PMO finds that an annual process to reviews ideas and innovations and approve potential projects to be too slow and cumbersome. We need to meet much more frequently. Usually these Governance Committees start out meeting quarterly and soon move to monthly Iterations. (See what I did there?)

This type of PMO is becoming more and more Agile by providing Iterative Decision Making and limiting the Backlog of Work.

Finally this type of PMO reports the final outcomes of projects, both Financial and Client Value delivered. As the PMO is now accountable for the project outcomes, the PMO conducts Project Closeouts and Lessons Learned sessions for Continuous Improvement.

Summary

Brutal Visibility and Collaborative Prioritization? Iterative Decision Making and limiting the Backlog of Work? Continuous Improvement?

Can an Agilist succeed in a PMO? Sounds to me like you have to be an Agilist to succeed in a PMO. 🙂

 

 

My #Agile Breakup

So it has been 11 months now since I’ve seen Agile. How has it been? To be honest, I haven’t missed her. I really haven’t. What has been made clear is what Agile is and what she isn’t.

First Date

I guess Agile and I started dating in 2006. We both were interested in each other and then I was able to arrange for Yves Hanoulle to be the keynote at the Software Development and Evolution Conference I was helping to organize in 2011. Yves had a great presentation on the Agile Mindset that was brilliant. I must admit I only realized how brilliant in the last few months. I think I did what many people have done when they encounter an attractive person coming out of a bad relationship. I moved too fast and fell too hard after being with Waterfall for too long.

The Agile I met was a collection of interesting, valuable methods. There was the concept of the Agile Mindset that Yves and others were promoting with wisdom. But I fell into the same trap as many others. I was going to propose to Agile and she would be the only methodology for me. All projects would be Agile. If clients didn’t like my new girlfriend, then they could go elsewhere.

Agile was a Methodology. I was sure of it. I would exclude using all other methodologies while Agile and I were serious. I would create an Agile Methodology by combining methods and practices. I would read and author Agile papers and presentations where we routinely challenged and chastised each other for not being ‘Agile enough’. I looked for the Agile complement for all waterfall or traditional methods. No matter the project, I promoted the Agile method.

For those of you keeping score at home, the PMBOK isn’t a methodology as well. Similar to Agile, it is a listing of processes, procedures, and knowledge that can be applied. But it is not prescriptive and does not provide governance on how to apply the methods and practices. Many companies take the PMBOK components and create their own methodology from it though.

But what about Scrum you ask? I’d say Scrum is an incomplete methodology. Although it does provide a methodology for the iterations on a project, it does lack guidance and governance in relations to the business case and pre-project intake process. Scrum also lacks guidance for the larger portfolio and enterprise governance concerns.

My Agile Mindset

My mistake was trying to take a collection of methods and assume a methodology exists. A larger mistake was then losing my Agile Mindset of constantly questioning the Agile methodology for value. That is my biggest complaint about Agile now. Many proponents seem to have lost the Agile Mindset of constantly questioning the best method to use on each project. Everyone is just promoting more and more ‘Agile’ methods without confirming that the method returns the most value for the clients. See the No Estimates discussion for this. To blindly promote no estimates for all clients does not represent an Agile Mindset.

I was going to say I’m just as Agile now and I was before, but that statement shows a non-Agile mindset – Agile is not a methodology to achieve. Let’s just say, I feel my projects achieve the maximum amount of value for client by using the Prince2 Methodology using Agile methods and practices were appropriate. Everyone I’ve worked with sees the value in Agile methods and are eager to work with them. The concept that you have to buy the entire Agile Methodology to use an Agile practice is misguided.

I mention Prince2 because that is what we use at the University of Manitoba. You could replace it with whatever you use at your company and then search where you could use Agile methods to return more value. The more I use Prince2, the most I think it is one of the best methodologies I have used though. Highly recommended.

Use an Agile Mindset, Agile isn’t about the Methodology it is about getting better little by little.

 

#Spelunking your #Backlog

it all seems so simple on first blush. Process the items in your backlog in priority sequence, rinse, and repeat. What could possibly go wrong?

Simply put if you process your backlog only by one measure of client priority, you are probably missing a lot.

The key comes when your backlog isn’t a simple list owned by one person. Like most issues in Agile, the trick always comes when you need to apply the Agile trappings to an enterprise scenario. When I have a backlog for one project with one owner and one solution, one rating system probably is sufficient. But when we move to an enterprise when we have a ticketing system for 50-60 applications, one rating system probably doesn’t suffice. In that enterprise situation, only going by one rating system probably means that entire applications or departments would be ignored and the systems would stagnate. Departments would become frustrated, write their own Excel and Access applications and create FileMaker Pro applications on the non-standard Macs they purchased.

So what to do?

Go spelunking

Mine the Data. Look for trends. Take a look at the data and see about the work required by:

• Priority
• Size
• Age
• Department
• Technology
• Effort
• Strategy
• etc…

Essentially understand your problems as much as you understand your solutions. ensure that you are not neglecting an area of the backlog. If you totally ignore an area of the backlog, the clients will create coping behaviors to address.

Although they don’t seem important, those small reporting tickets can results in a Data Warehouse being fully replicated if they never get attention. Clients will just copy data off and do the work themselves. Clients are also very reasonable when provided with the rationale between choosing between two competing priorities, but you need to give them some hope. Without that hope they will bypass IT and just do it themselves. And this will cause more work for IT in the long-term.

Recommendation

I recommend you take 80% of your budget and process the highest priority items. But then take the other 20% and ensure that IT is not ignoring departments or strategies entirely. Ensure that some tickets aren’t being left around for years and years. It is certainly proper to process less of these lower priority items, but it is fair to verify that we process some of them.

The #1 characteristic of a great teammate #WinnipegJets #Pavelec

I was watching a recent Winnipeg Jets game when I was reminded about the #1 characteristic of a great teammate.

Connor Hellebuyck was anointed as the starting goaltender for the Winnipeg Jets this year. He had a great season in the AHL last year. He had all of the great reviews as he moved through the various levels of hockey. The Winnipeg Jets had grown tired of Andrej Pavelec and his inconsistent play over the last few years. With Pavelec’s contract expiring at the end of this year, the writing was on the wall that a switch was going to be made sooner or later.

Resiliency

But we saw play from Hellebuyck that was very similar to Pavelec. Inconsistent, with a bad goal given up almost every night. Both goalies also had pure gems of games that could get you hoping of what the future could hold. But when Hellebuyck got pulled in three straight games in January, you saw a difference between the two goalies. And then when Pavelec came up to the big club and started three straight games and won you again saw the difference.

Various radio shows called it something different – ‘timely saves’ was the term most commonly used. Whatever the term, Pavelec may give up the bad goal, but then didn’t give up the next goal. He fought through the shots and kept his team in the game. And his team knew that Pavelec would fight to prevent the next goal and keep them in the game. We was a fighter and it was hard to get the ‘next’ goal on him.

Ondrej Pavelec has Resiliency that Connor Hellebuyck doesn’t have yet. The Winnipeg Jets players know that and due to that, they play better in front of Pavelec because it gives them confidence to play their game. They don’t need to worry about making a bad play, because Pavelec will overcome it if it happens. It is a larger worry making a mistake in front of a goalie where it may open the floodgates. Because of that you hold your stick a bit tighter and ironically make more mistakes.

Summary

Resiliency is the #1 characteristic of a great teammate. That trait in a teammate that they are resolute, plucky, committed, able to rebound and recover. We all make mistakes, but those people who take a shot, dust themselves off and stand tall are the special teammates we all want on our team. Give me a resilient craftsman over a fragile artisan every day.

Another example of Pavelec’s Resiliency is how he took his demotion with class and professionalism. Resilient teammates accept decisions made for the good of the team, confident in their abilities and committed to rebounding and proving themselves when the opportunity arises.

I hope Connor Hellebuyck can build these characteristics. But until then, I’d start Pavelec.

The #Agile Apprentice

I’m not sure why but I watched the Celebrity Apprentice last week. I hadn’t watched the Apprentice probably since that first season. I was quickly reminded as to why I stopped watching it. It is a show that shows all the anti-patterns to having healthy teams and projects. Their idea of the roles and responsibilities of a Project Manager is simply offensive.

The Apprentice Project Manager

So as near as I can figure it, the version of a Project Manager in Donald Trump’s world makes all the decisions, is judged solely by the success of the product and is expected to throw the weak links on his/her team under the bus. There is no mention of building teams, mentoring individuals, or collaboration. In fact, Project Managers are expected to also have the authority to make all of the decisions for the project. In short, Project Managers get to be in ‘charge’.

The Agile Project Manager

This goes totally against the concept of an Agile Project Manager. An Agile Project Manager is a servant leader who leads the facilitation and collaboration for the entire team. I have found that when I am a Project Manager on an Agile project I make very few, if any, decisions. The team members and experts make all of the decisions. The Project Manager usually just decides on how to best share progress and status with the Project sponsors.

Why?

So why then does the Apprentice have this vision of a Project Manager?

I thought about this last night and I believe it is related to what the ultimate objectives are in Donald Trump’s world. In Donald Trump’s world, projects exist to amass individual reputation and fortune. Project’s can leave a trail of bodies behind if the project results in fame and fortune. They do value the client, but as long as the client is satisfied the team members can double-cross each other. If fact, that type of behaviour seems to be rewarded.

This is the opposite of the objective of Agile Projects. The objectives of Agile Projects are to grow as a team and provide value to the client. But teams and projects need to be sustainable and repeatable. Agile Projects go to great length to discuss issues exist with systems, not individuals. We succeed and grow as a team.

Ultimately we need to treat each other with respect. The Apprentice seems to have forgotten this and eventually this pattern is not sustainable. The Good catches up…

Why we need Donald Trump

Republican presidential candidate Donald Trump speaks to supporters as he takes the stage for a campaign event in Dallas, Monday, Sept. 14, 2015. (AP Photo/LM Otero)

We need Donald Trump. We really do.

Full disclosure, I didn’t want Donald Trump to be the President of the United States. I still don’t. But in hindsight, we need him.

If Hillary Clinton got elected, we would have returned to our lives, jobs, suburbs with the silent confidence that everything was good. Society was improving and being more inclusive, race relations were getting better, people were becoming more tolerant, and we finally had the first woman President in the United States. That coming off the United State’s first African-American President had to say something about tolerance and inclusiveness in the United States?

Turns out, maybe the recent Human Rights advances didn’t defeat the enemy of intolerance, but just drove it underground.

Problem is we just had too many young black men losing their lives in almost every large city in the United States. Just like how almost all penitentiaries in Canada have far to many First Nations people. As ironic as it is, Donald Trump will do more to address Black Live Matter than Hillary Clinton ever could. Not because of anything he is going to do, but because we are now more alert and looking for any indications of illegal police actions under Donald Trump. With Hillary Clinton we may have given some benefit of the doubt that will not be given to Donald Trump.

In Canada, Gord Downie undertook a project recently called ‘Secret Path’ to shine a light into the shameful part of Canadian history and what we did to First Nations families and children. As Gord Downie so eloquently put it – “Canada is not the country I thought it was”. Like the citizens of the United States, most Canadians were oblivious to the intolerance and racism that still existed and was driven underground.

Shine a light

Perhaps we need Donald Trump and others like Gord Downie that shine a light on who we still are. Only by shining a light on these uncomfortable areas can we truly address them and get better. Things wont be better in the short-term. We are going to hear things about ourselves and our fellow citizens that we can’t believe. We can’t believe that people still think like this in this day and age. But enough is enough –  it time to bring it out into the light instead of hiding it underground and fooling ourselves.

To Chanie Wenjack, I’m sorry. Sorry you had to suffer and then die alone on that path.

I’m also amazed that the article that reported this tragedy in a national magazine in 1967 was ignored in Canada. We are truly not the country I had thought. Please read the story and share – lonely death of Chanie Wenjack

Summary

Gord Downie is intentionally shining a light to help us be better, Donald Trump is doing it unintentionally. Regardless of the intention, both provide an opportunity to make ourselves better.

#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

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

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

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

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

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

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

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

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 ?

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.