Sunday, July 5, 2015

Do not create unnecessary fear and animosity with Development Managers

During agile transitions, the Development Manager often feels like an outcast.

I'd like to present an important discussion to have with Development Managers, especially the ones that go out of their way to help and not hinder.

Most Development Managers have their positions because they know something about development. I have yet to find one that does not care about the people that work with them (or for them). They have usually built relationships with those they work with.

Assume the following scenario for discussion purposes;
  • The Development Manager is openly supportive of the changes to occur (and is sincere).
  • Support is both top-down and bottom-up.
  • A coaching team is put together to help (some external, some internal coaches).
  • It has been decided (let's just assume for a good reason), the company will be using Scrum.
Cross-functional teams are formed and the people will go through the Tuckman model of Team formation: Forming, Storming, Norming and Performing.  

The Development Manager is encouraged to allow the teams to grow organically. He understands that a high-performing team arises from a group of people working hard to solve problems on their own. 

Image "Team" by Dawn (Wills) Manser under a CC 2.0 license

As teams grow, they build confidence and seem to become self-contained, and almost insular to some. This is normal and is not a sign of dysfunction. This simply indicates that the team is starting to have  self identity. They are starting to act as a team. This is a good sign.

Eventually, the team will mature to a point where they realize they need outside help to act effectively in a larger organization.

Something is happening.. The Development Manager is starting to feel disconnected from the team and the work.  

As the teams become more effective, the Development Manager feels more loss.

Put yourself in the position where (through all your good intentions), you no longer feel you have relationships with the people that used to report to you. 

Consider the agile value "People and Interactions".  

Ideas for Coaches and Scrum Masters

If you are coaching, once the team has achieved a certain level of self-awareness and autonomy, remind them that the Development Manager is a person and...

There is No rule in Scrum or the Agile Manifesto  that says "team members may not talk to a manager". 

I have coached several pre-existing teams coached by others, that have been very happy to learn this. Do not assume this is known.

Potential discussions with Teams:
  • Thank the Development Manager for the support. 
  • If you have trust with the team, ask them if they would like to invite their manager to their next team lunch or get-together.
  • Next time the team needs help, consider asking the Development Manager for an idea! 
  • Be inventive. I've seen all kinds of interesting things.  One of the coolest was a manager who was brought in as an SME by the request of the team for a strange product the manager had worked on in in the past. This helped to create a feeling of contribution and trust.

Discussion with the Development Manager:
  • Talk about what the manager should expect and how the team will evolve. 

  • Do not simply assume that a manager new to Scrum or Agile will know this if they have never experienced it. 
The team will "come back to them" as they mature.  The manager needs to know they will still have personal bonds with their peers in the future. 

This feeling will pass as the team realizes it needs others to succeed in the organization. 

Scrum Masters or Coaches have an important responsibility here; To recognize this as a time to build bridges. Hopefully you have been spending time teaching and coaching servant leadership to the Development Manager so they can provide the appropriate guidance and support. 

When I'm with an account, I find it respectful to explain to the Development Manager that there is a natural evolution for a team, and they should expect some sense of personal loss at first.

Awareness is always a better approach than surprise. Surprise creates fear and animosity. 

Development Managers can enjoy learning new skills, or new approaches to leading and working. However, they are unlikely to be in such a frame of mind if they feel like outcasts. 

Consider the importance of transparency and openness about team evolution, and that it makes no sense that all the skills and knowledge of the Development Manager should be ignored or dismissed.

A Development Manager who knows and understands this natural evolution of teams will appreciate the knowledge. This is a far more desirable approach than an unnecessary feeling of loss.

Mike Caspar
Passionate About Agile


Saturday, May 30, 2015

WHY are we making this change?

I had a conversation this week that reminded me about a topic from the past.

Someone I know was working with a team who had written some code to change part of a system without having any understanding as to the purpose of the change.

The team was simply told what to do and that was "the end of the discussion". (literally).

I did some digging and found an old post on the subject.

It's strange that such an old message is still valid today.

It's a bit wordy (something I've hopefully improved since then). :->


Saturday, January 17, 2015

Let them Know. You can't just flick a switch.

I made a post today over at the agile42 blog.

A snippet...  "Consider letting people know when you are changing your approach, some might appreciate knowing that you intend on doing so."

Here's the link of you have some interest...

Mike Caspar
Passionate About Agile

Tuesday, November 11, 2014

Can you just stop?

Lately I have found myself in conversations about how and when projects stop and transitioning a team to allow them to work on the next project.

This generally happens when we're discussing the work "not done" as it relates to a project. It sometimes comes up as it relates to "gating", and in some cases as it relates to year-end performance reviews.

I recently read some agile42 slides presented by my peer Dave Sharrock. The slides can be found here

The presentation talks about the need for quick feedback loops to gather information.

This got me thinking..  How do corporate systems actually DEAL with this information!.

From the Agile Manifesto....

Simplicity--the art of maximizing the amount
of work not done--is essential.

This phrase often comes up when we talk with team members and Product Owners about the concept of minimizing scope in a specific story, not "gold-plating" and discussions about emergent technology. We often discuss YAGNI (you aint' going to need it). and other such terms with teams.

But what about the enterprise reporting systems, motivation systems, H.R. systems, Project Management Systems, and Gating processes?

Let's talk about a potential situation that might happen and can make agile transition difficult. It may come from my past ;->

Here's the scenario.....

  • You are trying to "switch to agile" from a "waterfall" environment.
  • There are Gates involved and people have spent hundreds of hours completing them to start work on the project.
  • You have started the "Big Project" (whatever that means to you)
  • A team is formed (or if you are lucky you even have one that is ready to accept a project).
  • Before you started the "agile" path, initiation of projects took from 3 months to 1 year to complete.
  • You start a really amazing team and get stakeholders involved by bringing them to Sprint Reviews (all that stuff you are supposed to do from an agile perspective).
  • 3 Sprints in you manage to get the actual eventual users there and they say... "Why are you guys working on this?  Our stuff has already changed so much we will NEVER use this".

In your company....
  • Can people bring this up without fearing for their jobs?
  • Would people force the project through anyway because of a Gate or Process?
  • Can you consider Value Delivery instead of Work Performed as the driver of your determination process?
  • Do you have the ability to change path (pivot) based on empirical evidence? 
  • Can you stop when you are no longer delivering value and let your team move on to the next most valuable project for the company or client?
  • Could you quickly change to something that will be valuable to your clients that they are desperate to get?
  • Do you have a mechanism to measure value delivery instead of time spent or progress toward a plan?

Ask yourself ... Does your system allow adjustment so that the team can deliver the next most valuable thing to the organization or does it make that difficult for the people involved.

Consider talking with a great agile coach or company to figure out what you might do next in this situation and how that might be done in your organization. I am of course partial to coaching as an appropriate route.

However, just discussing this in your organization might work for you... Either way.. please talk about it.

My next post will likely be over at agile42's blog. Since my peers at agile42 seem to keep asking and pondering the same type of stuff, it only makes sense for me to start submitting content over there.


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