Thursday, August 27, 2015

Courageous Leadership to help their students using Scrum

I recently had the opportunity to get together with a great group of people at Blueprint Education as a volunteer to help out their leadership team.

They are passionate about helping students to achieve their full potential through self-empowerment and self-responsibility and have been working with John Miller from Agile Classrooms to introduce a Scrum approach to education in their classrooms.

The focus is on a feedback driven approach to learning goals. The roots of this approach come from Scrum and are based on the Agile Manifesto (modified for education of course).

To learn more about this approach, start here...

As part of this type of change at the school, or in this case, many schools, understanding and knowledge of what the students are going through was important to the leadership at Blueprint.

The leadership team appreciated that to truly help their students work in an agile way, they will benefit greatly by experiencing and living the values of the agile manifesto and using Scrum themselves.
The best way for the leadership team (Principals, CEO, COO) to help the students work in an agile way is to experience Scrum with Agile Values and Principles themselves.

As sessions proceeded, I made a point of always asking … “What can we learn from this? How does this affect students?’, how can we apply this to our situation?

What is the learning we could share with others?
Early on, this drawing appeared on the wall of the leadership team room…. The leaders realized that for them to embrace this approach of working, they would need to change a primary focus as educators.

They would have to become great at coaching with less focus on teaching.  This, as you might imagine could be problematic for the traditional educator.   

What would this realization mean to them?

A workshop facilitated by the Principals for themselves revealed that the Retrospective (part of the Scrum Framework) would require them to reflect on their own leadership style on an ongoing basis.

This supports the Agile Principle …

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly..


More details about this specific session can be found here..

Scrum’s simple approach of limiting work in process through the application of a timebox and creating focus is impressive. By embracing the timebox with cross-functional teams, people  learn to re-organize and collaborate to deliver potentially deliverable value in small increments where feedback is possible.

To educators, this can mean that the student (or team of students) can establish their own objectives for learning over a fixed period of time, focus on that learning and then obtain feedback on how they might adjust their learning patterns for the next cycle.

To realize their ability to work cross-functionally, we did an exercise using a Skills Matrix approach originating from the OpenAgile Framework.

What are the skills necessary to operate and grow our company and schools as a leadership team?
The leadership team at Blueprint Education grouping their ideas about the needed skills for their team.

The results looked like this...

The team decided on these for their definition of the quadrants for each skill...

All 4 quadrants means you can teach this.

Completed Skills Matrix

This exercise served several purposes including (but not limited to)..
  • It allowed the team members to recognize each other’s skills and strengths and from whom they could learn more.
  • It helped the team recognize that they do in fact have the skills necessary to take on almost any goal in a cross-functional way.
  • It allows individuals to recognize where they might grow their skills to help the team and the organization.
Over time, we’ll learn more about the wonderful things happening at the school(s). 

By example, this video was the creation of the teachers and leaders at Hope High School in Phoenix Arizona. They worked together as a team to discover a shared vision for their school…

If you are interested in learning more, I encourge you to reach out to John Miller or the Blueprint Education folks.  Of course, I'd also be glad to help as well.

More to come...


John Miller & Agile Classrooms -
OpenAgile Institute -
Skills Matrix - OpenAgile -

Sunday, August 9, 2015

WebStorm by JetBrains and chai assertion library code warnings easy adjustment

A technically oriented post today.

Re:  Webstorm undefined function or method warnings when using the chai assertion library for javascript and nodejs.

I spent some time recently working on a new nodejs module (meta-confirm)  and wanted to share a few bits of information I learned in the process as a result of hours of searching and experimentation.

I'm just giving back to the community for the next person who is struggling to find a quick, easy answer to this situation.

The problem: While creating a test using chai assertions, you get the message "Undefined function or method  x() ". In this example: " Undefined function or method contain()".

Undefined function or method contain()

The same issue exists for many of the assertions (not just .contain)

To fix this code completion warning in Webstorm 10....

  • Files  - Settings  - Languages and Frameworks  - Javascript - Libraries

  • Download


  • Change the drop selection from Official Libraries to Typescript Community Stubs

 Official Libraries

Typescript community stubs

  • Find chai and select Download and Install

  • Enable chai-DefinitelyTyped 

  • Now, your code checking in Webstorm will recognize the syntax of the chai expectation library.

Notice that the .contain no longer shows as an undefined function or method warning.

Mike Caspar
Passionate About Agile


chai assertion library
chai TypeScript community stub
WebStorm from JetBrains

Tuesday, August 4, 2015

Ask Why. Then sit back and watch the magic happen.

I recently had the pleasure of spending some time with Blueprint Education and Hope High School in Arizona. They have some courageous and amazing teachers who are working to inspire students to make better choices and be champions of their own learning. 

I was reminded again of the power of individual contribution to team goals and the amazing things that can happen when you let others lead the conversation.

We played a game designed to iterate over cross-functional team goals and to learn about each other's skills. 

Instead of me facilitating the follow-up discussion (retrospective), I asked one of the principals who was there if they would be willing to facilitate for their team.

I started by simply asking them.....

"Why do you think I just did this exercise with you?"

"What was the purpose?"

Then, I just sat back and let things happen.

Wonderful conclusions happened from the Principals and the rest of the Leadership team.

Define Objective

  • Reflect on Leadership Style to look for ways to empower Staff to Run w/Goals
  • Live the Learning
  • Less Rules: More Creativity
  • Knowing When to Release the Reins
  • Team Progress Allows more opportunity for Innovation & Risk Taking

I had not planned on taking them to this place, but was amazed they came here. It was far more than I had hoped for or could have planned for.

This is why I love to use this approach. 

As a facilitator, if you can find ways to allow self-expression happen instead of trying to decide on outcomes yourself, the results can be amazing.

Next time you choose a session or a game, consider asking "Why did I choose to share this particular learning with you?"......

Then sit back and watch the magic happen.

Mike Caspar
Passionate About Agile


Blueprint Education
Hope High School

To learn more about Agile in Schools, start by following @agileschools

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.