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.



References:




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


---------------------
References:

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, 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.
or

- 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

References: