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 a Scrum 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.

Just discussing this in your organization might work for you...

Either way.. please talk about it.


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 - http://agileatlas.org/atlas/scrum#sprint-retrospective

PMBOK, PMI (Project Management Institute)
Project Management Lessons Learned - http://www.pmi.org/Knowledge-Center/Research-Completed-Research/Post-Project-Reviews-to-Gain-Effective-Lessons-Learned.aspx
agile42 - http://www.agile42.com

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

ODP - http://www.caspar.com/PublicDocuments/TeamInfluenceSurfaceArea.odp

PPT - http://www.caspar.com/PublicDocuments/TeamInfluenceSurfaceArea.ppt

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