Thursday, July 17, 2014

Sprint Retrospective vs Lessons Learned (a generalization).

Whenever I make a post of this nature, I get a bit nervous. The reason is that some of the information presented is based on generalization.

I expect that some readers will use some "concepts" from the Agile Retrospective during facilitation of Project Management Lessons Learned.  As Project Managers learn more about Agile Values and Principles and working in smaller increments, the distinction will become less obvious. 

The chart below is as a comparison only. For those that are looking for a starting point, I hope this will get you started in your discussions.

Sprint Retrospective -  At the end of each Sprint, the Scrum Team meets for the Sprint Retrospective. The purpose is to review how things went with respect to the process, the relationships among people, and the tools. The team identifies what went well and not so well, and identifies potential improvements. They come up with a plan for improving things in the future. All Scrum meetings are time-boxed. The recommended time box for the Sprint Retrospective is one hour per week of Sprint duration.

The Scrum Team improves its own process, always remaining within the Scrum framework.

Source: The Agile Atlas

Project Management Lessons Learned [Output/Input]. The learning gained from the process of performing the project. Lessons learned may be identified at any point. Also considered a project record, to be included in the lessons learned knowledge base.

Source: PMBOK, PMI (Project Management Institute)

Sprint Retrospective (for the team) Project Management Lessons Learned (for the company)
Focused on the Team and their Environment (and organization) moving toward Agile Values and Principles

Focused on "project" learning. Not geared toward improved agility

Immediate in nature

Historical in nature

Team based learning

Project based learning

Intended to remove impediments through immediate action if possible

A "project record" designed to document processes and procedures to repeat actions in future projects

Intended for the team to improve, and ask for help with system or environmental changes

For the Organization or Leaders to decide how to avoid problems in the future

Radiate information related to impediments and improvements needed

Record information with the intent of using that information in future projects

Focus on being SAFE (generally private, especially at first)

Emphasis on reporting and diagnosis vs. "being safe". (generally public)
May be simply to solve inter-team member problems

Not designed for improving team relationships

Celebration of Success

Celebration of Success

Celebration of Learning (known to some as failure)

Build processes to avoid future failure

At the end of EVERY Sprint (cycle)

Typically at the end of a project before the team is split up

Continuous improvement culture

Batch based improvement culture

Designed to "play the game"

Focused on "keeping score"

Focused on building team member trust

Focused on avoiding future failures

Focused on building organizational trust

Focus on future controls

Supports the concept of allowing the team to "self-direct"

Focus on changing controls for future projects

Provides "we need" type information... People focused

Provides "Company will change" type information... Process focused

The chart is presented in such a way as to show the difference of "intent", not to be prescriptive about application or to imply one is correct or not.   However, with the intent of moving toward an agile culture, intent is important to consider. 

An example;

From a Retrospective.  "The team is continually struggling with getting access to the Production Unix Box.  Please fix this for us so we can work more effectively in the next Sprint".

From a Lessons Learned. "The team struggled with Unix System Access which effected their performance."

A Sprint Retrospective is focused on allowing the team to "play the game" and not about "keeping score".

"Status" comes from an observation of the results of the retrospective and how they were handled in the organization.

An example might be "Has this problem stopped hindering the team?").  This focuses the organization on removing impediments to team growth and self-organization instead of creating procedures to be followed.

It is expected that what worked for one team might not work for another. Therefore, it's best to solve a teams impediments "in the moment" and learn from how the organization changes to solve them.

If you would like to keep reading about Sprint Retrospective concepts, check out the following post....  agile42 - Retrospectives that Rock

Consider reviewing these differences in your environment to determine if you are getting benefit from your Sprint Retrospectives and following their intent.

Mike Caspar
Passionate About Agile


Sprint Retrospective -

PMBOK, PMI (Project Management Institute)
Project Management Lessons Learned -
agile42 -

Sunday, June 1, 2014

Learning to think with a test-driven mindset. A website example.

This post is a continuation of a theme I call a "test-driven mindset". I have tried to make this as non-technical as possible yet still convey the concept.

I recently found a potential problem on one of my sites caused by a Windows to Linux conversion. 

I downloaded my site from the code repository. Then, when I started up my local web server and did some browsing.. Everything looked good..... at first.

When trying it on my mobile device, something was wrong... The main page had no formatting. I didn't know what the problem was but realized it was related to CSS (styles) somehow.

The Play! Framework developed site has code that automatically detects a desktop or mobile device user and provides a different looking site (including CSS).

How I created a software based automated test and fixed the potential problem using a "test-driven mindset"....

In Code / Manual or Research

Launch a server in the test framework and set myself to be a mobile-device (set my user-agent header to Android)
Connect to the home page
Try and find the <link rel="Stylesheet" type="text/css"> and read that in
Wait... this is tough and a bit cumbersome....
I could write some code to try and figure out what the CSS is but it would be a lot easier if the page was easier to test. I wonder.. Is it "legal" in HTML5 to put an "id=" on a <Link> tag?
Five minutes of research.. yes it is.
Write a Test to try and find "id=cssMain"
The test immediate fails (of course). (This is the idea)
Re-write the web page to add "id=cssMain" to the <Link> tag.
The "id=cssMain" test passes
Now.... I can easily find the CSS selector for the test
Let's read the "href=" (for non technical people, this is the location to find and get the style-sheet")
Try to open that location and if everything works out, I should be able to get a text file that has the words "html, body" (this is a convention I have for style-sheets in my sites).
I do get an error (as expected).
Let's see if I can clear this error up.  Now, it is obvious to me that the problem was caused by the Windows to Linux migration.

The existing Windows machine(s) did not care about case-sensitivity. The new Linux environment does.
The webpage was specifying "casparMobile.css" when the file on the drive was called casparmobile.css"  (The capitalization did not matter in Windows).
I chose to rename the file from casparmobile.css to casparMobile.css (a personal preference).
Then, the entire test passes.  Yeah!

The final Automated test now runs before check-ins (plus other tests of course)....
  • starts up a test server
  • sets itself to mobile
  • requests the home page
  • finds the css selector by Id
  • gets the href setting from the tag on the page
  • tries to get the specified style-sheet and then confirms it's what is expected in the file.
After committing the code to my code repository, my Continuous Build and Deploy Server will re-run all the tests in the background and auto-deploy and launch it for me to my cloud hosting provider.

I hope this real life example helps to work toward a "test-driven mindset".

Mike Caspar
Passionate About Agile


Wednesday, May 14, 2014

Consider Circle of Influence and Circle of Control for Retrospectives

This post is related to a Scrum ceremony called the Sprint Retrospective and how it might relate to your team.

There is no reason the information could not be appropriate to any team which identifies impediments as part of a continuous improvement process or cycle.

That being said, here goes...

In Scrum, at the end of each Sprint, a cross-functional team gets together and reflects on their situation and how to improve it. Sometimes this involves self or team-improvement and sometimes this involves identifying and communicating external impediments.

As mentioned in a previous post, Scrum exposes problems, it does not fix them. Often, internal and external impediments become visible as a result of the Retrospective.

In the book, The Seven Habits of Highly Effective People by Stephen R. Covey, he introduces the concept of "Circle of Influence" and "Circle of Concern". The suggestion is that to become more effective people, we should focus on those things that are "Under Our Control" (not other people or things but ourselves!).

The implication is that we should not try to directly change our Circle of Influence, but we should put that energy into our Circle of Concern in the way we do an act. We can increase what we "influence" indirectly.

To demonstrate this concept, I have created a diagram I call the Team Influence Surface Area Chart. To read the chart, do not focus on the size of the Circles of Concern(control) but on their interaction or "surface contact" with other circles. This is where influence exists.

Consider the following two before and after charts....

In the following chart, you will see the team has worked on increasing it's Circle of Concern by adjusting and working on what they personally can control (their work, their habits, their skills, etc.)

As a result, the team has a greater area of influence "surface area" on other circles.

Note also that before the Circle of Concern grew, there was little influence on the "Green" external circle. Now there is.

This greater surface area allows more exchange of ideas and knowledge. Think of this as being similar to "Osmosis".

As with all conceptual models, there are errors with the chart. For instance, the chart does not currently show changes in the size and location of the Circle of Concern of the other circles. This is highly unlikely in a complex human system. The chart just demonstrates the concept.

I have included a link to the charts in presentation format. they are licensed as Creative Commons.  Please feel free to share them, keeping the original attribution.

A reality of Scrum (or any other framework) in a large organization is that a team often identifies impediments (problems) that, if fixed, would significantly improve their ability to deliver. 

In theory at least, managers and/or leaders would receive this information, and simply "fix it" right away. 

Even the most aggressive large organizations take time to make some changes. 

Does this mean the company does not want to change?


It just means it's hard for them right now.

I have seen a situation where a team continually focused on the same external impediment as the result of their Retrospectives. Due to this, no other growth or learning was happening in the team (where it was under their control). When the company eventually fixed the impediment, they were shocked to find the team had made no improvements in the interim.

If your team is doing this, consider that can make the situation worse. This effect is compounded should the change for the organization be difficult and is politically challenging. 

As changes  happen by the request of the team, it is important for the team to be improving at the same time so that the challenges feel "worth it" to those being effected. 

Put a different way, this has to be good for the team and the company. They are a unified "system" after all.

After introducing this idea to the team, consider asking "Hey, do you want to use this information and focus on something that's under our own control for a few Retrospectives.  We all know this is a big problem, but there must be many other things we can work on that are under our Control. such as ...(fill your own list in here) ..  Are we OK to just accept this impediment and work on something we can fix while the company works on the other impediments for us ? ... What do you say?".

I am by no means suggesting you silence your team about external impediments. I just ask that you let them know about "Circle and Influence" and "Circle of Concern" and use that knowledge to their advantage. 

I will admit, I am sometimes nervous about this approach. In some companies, the "impediment" actually won't go away without the team constantly bringing it up. That is a very different discussion.

Most importantly regarding this topic; please, allow your team to decide for themselves.

As coaches or leaders, it is our responsibility to educate. Consider teaching your teams about this concept and maybe you'll find they not only deal more effectively with negative external factors, but they can also start to focus on "self-improvement" as they wait for the company to make needed changes on their behalf.

Worth a thought at least.

Mike Caspar
Passionate about Agile


Sunday, March 30, 2014

Consider the ability of your Stakeholders to come to your Sprint Review or Demo before declaring it.

As many of you know, the Sprint Review or Demo is a fundamental part of the Scrum Framework. This "inspect" and "adapt" for the product is paramount to the ability to adjust and move forward.

If you are facilitating the discussion about when your review is going to be every Sprint, consider the stakeholders and their ability to show up for your review before making that decision as a team.

In my travels, I am often faced with a team that is trying to decide on the day and time of the week to finish off their sprints and do demos.  There is much written about the day of the week, morning, afternoon, over the weekend, etc.  There are many discussions related to what next; The Retrospective and how the retrospective timing is very important to a team's ability to grow and get better.

Consider that the Sprint Review is the one time that the Scrum Process specifically interacts outside the team with different parts of the business. 

The reality today is that if you are trying to follow Scrum in an enterprise, you will likely not fit perfectly into existing corporate systems.  

There are two approaches you could follow;

- Abandon the fundamentals of Scrum with the fixed cycle that is so important to its' rhythm.

- Stick with Scrum as intended and strive to find a time that works best for most of the people.  

Simply declaring "We are doing Scrum and stakeholders have to show on Friday's at 4:00 PM to see our demo or they don't care about us or our product" doesn't seem to me to be considering Scrum's Values..  Respect for starters.

Scrum is a Framework that helps to build Trust in the Organization.  The team has the ability to self-organize.  Think about this comment. It is also possible for a team to self-organize themselves into an antagonistic and confrontational part of the business.

There are many other considerations for the Sprint Review or Demo that relate to team dynamics, building of trust, feedback loops, transparency of progress, etc. A quick internet search will help guide you in that way.

If you are like me, you may have been asked to help a team determine a Sprint Length. Part of that decision includes deciding what day the Review will be and if it will be in the morning or afternoon.

I strongly encourage that you have an open dialogue with your teams about when your stakeholders actually can show up for the review.  If you are in an enterprise this can be even more challenging.  

When a team sets a review day and time that has no basis on the reality of their stakeholders being able to come, it is hard to say later "the business doesn't support us. They never show up for the demo".

I have included an example of where teams can go wrong. 

You need to focus on keeping the same day and time every sprint or you will lose much of the benefit of the "heartbeat" of Scrum. 

Consider the following scenario;

A team with one week Sprints decides to have Planning on Monday mornings and the Review/Demo on Friday afternoon at 4:00 PM.

Sounds OK right?

In an Enterprise, Fridays are typically the day that the following happen;
  • Executives and Managers are in meetings giving their "weekly status reports".
  • Managers are doing the "golf thing" as a part of their jobs
  • Leaders are networking at pubs
  • People are off early on Friday's due to "summer hours" allowing them to leave at noon on Fridays.
  • the list goes on ... 

Scrum is hard enough to do already without the added complications of not considering the implications of the selected time for the Review or Demo. It is important.

I believe in helping teams to consider what will allow them to be the most successful in their environments.

The reality is that many teams are in non-perfect environments and should do whatever they can to stick with Scrum as designed.

Team dynamics can be changed by the team's interaction with people "around the edges". Learn from that and do what you can to not have to change the basics of the Scrum Framework.  

At a minimum, it doesn't make sense to have your review at the EXACT time your Primary Stakeholder has no choice but to be in a weekly meeting in a remote office.  Doing so shows lack of respect for them and frankly, for yourselves.  You are practically guaranteeing that you are not going to get what was intended for this important Scrum ceremony.

The Sprint Review or Demo is your Primary opportunity to show your progress to stakeholders so they know real status and can be part of the process.  It is in fact, the intended time to do this.

I do not advocate changing the days due to an occasional scheduling conflict. Remember; you cannot please everyone all the time.  That is not the intent.  

If you are in a new environment, you have the ability to find out a bit about the corporate cycle before choosing your review date.

If you are in an environment that is struggling to get stakeholders to your review, ask yourself if you have chosen an impossible day of the week for this ceremony.

Please, for the sake of your team(s)....

When considering when your Sprint will end, 
think of the ability of your stakeholders 
to actually show up once in a while!

Stakeholders are people too.  They don't want to let the team down either.

If you are fortunate enough to be in an environment where everyone comes together to see the review and demo as part of what is going on normally in the company, then this won't apply to you of course.  

However, if you are in a "transitioning" or "imperfect" environment, ... have the discussion.

Mike Caspar
Passionate About Agile


Monday, February 17, 2014

Who says we are not high-performing?

"Let me help you to achieve high-performance" the coach says.

"Who said we are not high-performing?" is the response.

Since 1989 when I started to build my first team, I have experienced some huge variations in performance and quality. I mention these two factors specifically for a reason; Having one without the other isn't really high-performance is it? This is of course my take on it.

When we determine if a Agile team is high-performing or not, are we clouding that decision based on our own view of the world?  Is it appropriate?  On the other hand, Is it appropriate to ignore our past experiences?

With almost every transformation or adoption comes a point where a team starts to declare. "We are high-performing". Others in the company do not agree.

The difficulty is related to the reality that people see through different "lenses". We all have experiences that shape our vision of the truth.

Stephen Covey writes in his book "The 7 habits of highly effective people",
Valuing the differences is the essence of synergy-the mental, the emotional, the psychological differences between people. And to key to valuing those differences is to realize that all people see the world, not as it is, but as they are.
I have worked with teams who truly feel that in their context, they are high-performing, while others see "mediocre". Who are we to take that away from them?  Perhaps they worked hard to get where they are.

I believe that motivated people can truly accomplish great things. To me, helping them find that extended reality is part of my job. My experience tells me it's possible.

The thing is... That is "my vision" of the world. I admit that as a person I can have pretty high-expectations of people. It's partly my upbringing and skills. It's part of my driving personality toward excellence.

My view of the world is also biased by the fact that I have worked with some truly exceptional people. Because of that, I tend to see unlimited potential in others. I feel blessed to have seen what can be done with the right mindset.

Consider; What happens if the people I am working with are already 200% or 300% more effective than they were a year ago, or simply since I started working with them.

What if they already have gone well beyond what they knew in the past and are consistently delivering value? When do those people have the right to call themselves "high-performing"?

Is it when some chart says so?  Is it when some manager says so?  Or worse... is it when I say so.  Gees...  I hope not.

I believe that high-performance is an attitude, not a number.

 It is a desire to improve,
a desire to push oneself beyond your abilities, 
to constantly learn new things,
 and to work toward mastery in the delivery
of value to the customer.

The following principles clearly state what is important in an Agile context and should be factored into the determination of high-performance for an Agile Team.
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Continuous attention to technical excellence and good design enhances agility.

If a team is delivering large amounts of code but is not addressing the above concepts, are they high-performing? 

If the team cannot "continually deliver valuable software" because the code is so badly written that even the smallest changes make the team fear any changes, are they high-performing?

If the team works fast but never pays attention to "technical excellence and good design", are they high-performing?

Too often, I see a quest for Story Points or a manager pushing to meet a "fixed schedule" without the most important discussion taking place.  "Are we delivering real or lasting quality to the customer"?

Realize that the concept of "high-performance" depends entirely on the people, organization, culture and how much "Agility" is embraced.

For me at least, no Agile team can call themselves high-performing if what they create doesn't serve the client's current and future needs. That to me is just "doing work quickly"... A sad substitute for actual high-performance.

Remember, in some cases; your teams may already consider themselves high-performing.  They likely see through a different "lens" than you do.  Treat them like human beings and realize they may have already achieved what they consider to be their nirvana. 

I have experienced some extremely technical team members who are masters at their skills... Yet, what they deliver to the customer is just horrible. I have also worked with what would be called a "mediocre" skill set but what they have delivered, the customer truly enjoys. I ask you... Who is the better performer?

Double check your determinations about "high-performance" and ensure you are not factoring your own "view" before determining if a team is a high-performing Agile team. 

Keep it simple; use the manifesto. It may show you which teams truly are high-performing and which ones are not. The results may surprise you and show that your "personal lens" is skewing your decision.

Mike Caspar
Passionate About Agile


The 7 habits of highly effective people 
The Agile Manifesto

Sunday, December 15, 2013

Lean Start Up versus Entrepreneurial Spirit

Something has been bothering me for a while about the Lean Start-up revolution that seems to be happening. It's not so much about Lean Start-up but of some of the interpretations I have been hearing from peers.

My inquisitive nature and desire to constantly learn keeps me asking more.

The intent of this post is not to disparage a movement that clearly has business value and at a minimum asks people to be responsible for their decisions and not to over-create before receiving feedback.  

Actually, my goal is to support that movement as a good approach to initial product development by asking some experts in the field to openly consider the effects on Entrepreneur Spirit. This open dialogue to me can only add credibility.

One part of Lean Start-up that I have been hearing regularly is that you are "trying" something out before investing too much money into it.  This is a natural evolution of some of the concepts we work toward on a regular basis. For instance, the idea of "not following a plan" from the Agile Manifesto, or the experience of a constant feedback loop.

Some people have been telling me that a sort of "market trial" is done to see how people will react, and if the response isn't good, the start-up is stopped as being unmarketable and then terminated.

This has been a new "change" I've heard as an evolution from something that used to be about receiving early feedback and making appropriate adjustments. I used to hear about "delivering what people want".  That has recently changed in tone to "killing something before it starts".

Please consider that it might not always be the right thing to do to simply kill an idea because of initial feedback. I am "nervous" about the notion of allowing initial "market" feedback to negatively effect Entrepreneurial Spirit.

From what I have read and from peers I have spoken with, it is more about creating as little as possible to get initial feedback to decide what to do next. Awesome! 

I know that Lean Start-up is so much more, but just as in the Agile movement, there are "versions", I am concerned about an ongoing interpretation of using it to "determine start-up viability".

I think if this was the only approach in our history, we would not have many things that exist today;

Penicillin, the telephone, and the airplane are ideas that immediately come to mind. The way some people are approaching Lean Start-up as a "kill a product after feedback", these inventions would have never continued into reality.

I wonder, with this interpretation, would we have stopped making progress as a society? Imagine if this approach was used for Galileo or DaVinci's ideas?

As much as I appreciate the concept of non-waste, I am concerned that people will "blindly" follow a framework that (from some recent explanations I have received) appears to discourage risk-taking at the onset.

I believe that entrepreneurial vision should not be ignored.  Many entrepreneurs are willing to lose it all for their dreams and to give them a go.  
Please, do not try to take the entrepreneurial mindset from our society! 

If an entrepreneur did not have the willingness to risk it all "on a hunch or belief", that same entrepreneur would have a hard time helping other people to share their passion. This blind ambition and drive are an important part of life.  Without that drive and only "facts", it would be hard for an Entrepreneur to be willing to risk as much as they do.

Perhaps, instead of trying to avoid the risk of failure, we should focus on making it safer for this type of person to take risks. This is after all part of the philosophy of embracing agility. We value failure and learn from it. Actually, we encourage it to some extent.

I learned a long time ago that "fear of loss" is one of the greatest anti-motivators to innovation. 

Needing to test all your hypothesis first and ignoring your vision to what seems to be sort of a "group think" exercise.  People who blindly follow this idea will be left short of true innovation. I do not believe this is the intent of Lean Start-up.

I would be sad to find that no one ever risks anything anymore as we move forward. Instead of removing all risk, let's focus on helping people to work together to share in the risk or make it less painful for those that have risked and lost. I admire the person who is willing to lose everything for their dream.

Shared failures are important to life and evolution.  

I have done things that I know a Lean Start-up only approach to my ideas would have told me would never work. I know this for sure! Against all odds (and advice), I have been fortunate to have lived in a massive house in the country contrary to what I was told by initial market suggested would happen. I have also lived in my car for the same reason.

Ask yourself...

"Do I know anything in the market today 
that others would have said will never sell?".

Although I find the concept of Minimal Viable Product to be paramount to removal of waste and absolutely value the prospect of early and constant feedback, I have a personal problem with using the initial feedback to totally kill an idea. 

Please, let's not turn this truly awesome idea (and the intent of Lean-Start-up ) into something that kills creativity and innovation by accident.

I personally couldn't live with myself if I never failed at anything. It keeps me alive and improving. 

Also, there is the inevitable reality that an entrepreneur will likely just ignore us all anyways and do what they think it best in light of the information that's out there.  The reality is that this might all be moot anyway :->

Let entrepreneurs be entrepreneurs! We need them....

Especially the ones that are willing to fail no matter what others tell them!

Mike Caspar
Passionate About Agile

Wednesday, December 4, 2013

Project Manager as a Team member in a matrixed Enterprise Organization

The following idea is based on experience in several non-perfect matrix environments where the concept of complete organizational change could take many years (or never happen).

Does this mean we should simply give into the environment or should work with the existing culture and environment?

I am not recommending any changes to the way Scrum (or your Framework of choice) works, but am opening up an "idea" for people to consider.

I was recently chatting with someone about the role of a Project Manager in an enterprise Scrum roll-out.

Firstly, let me say that having a Project Manager "run" a Scrum Project is something I do not feel comfortable with if the organization is trying to work towards Agility. Let's get that clear right now. That being said, I've helped some organizations (large matrix ones) to introduce Scrum into their environments (including values and principles, not just process) and Scrum has worked out well for them.

I still hear from team members that have yearly votes about continuing with Scrum as part of their internally created process.  They work their own way and continue with Scrum, don't have PMs running their projects, and decide for themselves how they will organize and work. The organization has made sufficient adjustments to allow this to continue.

In Scrum we build a Cross-Functional team of people who can deliver a potentially deliverable working increment.  What if the organizational structure does not support this?

Do we bang our heads against the wall, or worse (in my opinion); just capitulate and change the framework immediately because our jobs as coaches are on the line?

Yes, we are trying to change the way things get done.  However, in an enterprise, this takes time.  What is not often discussed is that the original organization changes slower than the agile teams will.  This will clearly create conflict. 

Remember, this slow organizational change is likely part of the "Why" you are there in the first place. See my post about "Why" here.

The Agile manifesto says "People and interactions over processes and tools".

Well, let me remind everybody....  Project Managers are people too!

They have some very unique personality traits and skills that can benefit their teams (especially in Matrix organizations).

So, let's keep this post simple;

What would happen if a Project Manager was on a team as a Team Member using their unique skills and abilities to maneuver, build relationships in the matrix organization?   The team will have tasks that involve things like "Get marketing to review the content".  It's not really an obstacle for the SM to deal with.

Remember, the Project Manager (in a traditional organization) has the "keys" to be able to visit marketing in the first place.

I have worked with a team having a PO, SM, and simply "Team members".  One of those team members was a "person who was a Traditional Project Manager in their past life" who has the rights and privileges in the organization of a Project Manager.

For some of you, you may say "No, everything has to change".  I say, Yes, ideally, things will change over time. To just say "All project managers must go", is removing a very important skill-set and personality type (I'm not talking about filling out charts) that will be missed in an organization in transition.

To expect the organization to just "click the switch" and have other parts of an enterprise org respect the role of the SM immediately is not likely to work effectively.

In the scenario I describe, the SM, PO and Team all work together (as expected).  In a matrix org though, the PM could be a team member and add REAL VALUE during a transformation.  In the process, the PM would also learn some new skills and ways of thinking which could benefit them, the team and the company in the future.

You could still be following the Scrum framework (it is not specifically defined as to who can be on a Scrum Team, just that they need to be able to deliver an increment and be a self-directed team).

This of course would be transitional, but I may be realistic to expect it to be YEARS in the making as the organization changes to not need the traditional PM role as much and as walls and silos are broken down.

Not realizing there needs to be a half way to me at least seems like you are setting up your transformation to fail right from the start.  Enterprises don't just turn on a dime. This is why they need a way to "transition" to a new way of thinking.

So, consider an experiment; What if you just did Scrum the way it was designed and allowed the Project Manager to take on tasks on behalf of the team as a full-fledged member of the team.  They would not have the ability to assign tasks. They would however be extremely helpful and not feel like an outcast.

As long as you are considering the Agile Manifesto and guide yourselves by Scrum's values, you can't go wrong.  Scrum's values are...
  • Commitment
  • Courage
  • Focus 
  • Openness
  • Respect
As you consider this idea...

Remember, Project Managers are People too!

Mike Caspar


WHY are you trying to work towards Agility post - Link here
Agile Manifesto -
Scrum Values -