Announcement: PMI Chapter Talk – The Agile Enterprise

Learn more about transforming people, process and culture with the Real Agility Program

On Tuesday Dec. 2, Mishkin Berteig will be speaking about The Agile Enterprise and the five different approaches to implementing Agile at the enterprise level.  The talk will also include some details about two frameworks used at the enterprise level: SAFe (Scaled Agile Framework) and RAP (Real Agility Program).

This talk is hosted by the South Western Ontario chapter of the PMI.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Tips to Start Agile in a Hostile Environment

Learn more about transforming people, process and culture with the Real Agility Program

Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally.  In some cases, management may even be hostile to the concepts and practices of Agile methods.  If you are interested in Agile, you don’t have to give up hope (or look to switch jobs).  Instead, here are some tips to start using Agile methods even in hostile environments.

Regular Retrospectives

Some Agilists claim that the retrospective is actually the key to being Agile.  In some ways, this is also the easiest practice to introduce into an organization.  Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“.  These are retrospectives that can be done in 15 minutes or half an hour.  Try to do them with your team weekly.  If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting.  If you are “just” a team member, you might have to get some modest amount of permission.

So why would it be good to do a retrospective?  Because it’s a high return-on-investment activity.  For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning.   Here are a couple more articles about the importance of retrospectives:

What’s an Agile Retrospective and Why Would You Do It?

What is a Retrospective?

Practice-by-Practice

Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start.  Myself, my first formal Agile environment, I started with the Daily Scrum.  Another time less formal, I started with Test-Driven Development.  In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months.  This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders.  This is the practice-by-practice approach.  Start with a simple Agile practice that you can do without asking anyone for permission.  Make sure it is a practice that makes sense for your particular environment – it must produce some benefit!  If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start.  If you are more business-oriented, then maybe consider user stories or one of the Innovation Games.  If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.

It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another.  If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.

Stealth Project

Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy.  This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”.  This is an opportunity to do Agile.  Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.”  There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support.  In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it.  Don’t talk about it.

The “just do it” approach requires that you have some influence.  You don’t have to be an influencer, but you need connections and you need charisma and you need courage.  If you don’t have at least two of those three, you shouldn’t try this approach.  You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works.  Here are a few comments on Stealth Methodology Adoption.

Co-Conspirators

There’s nothing like working with a band of rebels!  If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work.  Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans.  Of course, you need to actually execute some of your plans.  Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.

But, like any rebellion, you really need to trust those you work with in these early stages.  Lacking that trust will slow everything you do possibly to the point of ineffectualness.  Trust means that you have, for some time, a formal vow of silence.  Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.

Read “Fearless Change”

I can’t recommend this one enough!  Read “Fearless Change” by Mary Lynn Manns and Linda Rising.  This is a “patterns” book.  It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use.  Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent.  Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.

Don’t Call it “Agile”

This isn’t really a “tip” in the sense of an action item.  Instead, this is a preventative measure… to prevent negative reactions to your proposals for change.  The words “Agile” or “Scrum”, while they have their supporters, also have detractors.  To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names.  Use another name.  Or let your ideas go nameless.  This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”.  By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.

A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”.  Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.

Get Some Training

Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program.  It’s a 40-week program that takes about 12 hours/week of your time for coursework.  The next cohort of participants starts in June 2015 and we are taking deposits for participants.  This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Timeboxing, Lateness and Character

Learn more about transforming people, process and culture with the Real Agility Program

I just finished reading a great rant about being on time by Greg Savage.  It got me thinking a bit.  I’ve been involved with Scrum and other Agile methods since the mid-90’s and in that time, my perspective on time has changed considerably.

saving time clock

I used to be the guy who was always late.  And it was a completely selfish behaviour.  Meetings, outings, even weddings.  I just couldn’t believe how “uptight” people were about time.  But gradually, over a period of about 5 years as I became more and more aware of the underlying philosophy of Agile, my perspective, and more importantly my behaviour, changed: I started being on time.  For everything.  Even if it meant doubling my travel time buffer.  Even if it meant sleeping 3 hours instead of 8 hours.  Even if it meant missing a meal or a drink or a personal to-do item.

Time is the only resource that, once spent, we can never get back.

Scrum and most other Agile methods respect this implicitly in their time-boxed iterations and meetings.  But people on Agile teams often need time to adapt and change their behaviour.  In many ways, timeliness (starting and finishing meetings on time) is a critical component of the Scrum value of Respect.

Timeliness is also related to our understanding of planning.  The Horizon of Predictability is short in most work environments.  Maybe a week or two.  If you dis-respect the tkmeboxes of the Agile process, you are jeopardizing your ability to effectively use the horizon of predictability.  Even the Daily Scrum, normally time boxed to 15 minutes each day, can through abuse of time, cause long-term ramifications in product development planning.

But really, I like Greg Savage’s point better than all the practical stuff: being late is rude.  Period.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Certified Scaled Agile Framework Program Consultant (SPC) – Mishkin Berteig and Travis Birch

Learn more about transforming people, process and culture with the Real Agility Program

I’m happy and proud to announce that both myself and Travis Birch have passed our SAFe SPC test after our training in early October.  This means that Berteig Consulting will start offering a number of SAFe related training sessions both publicly (on World Mindware) and as in-house.  We are also experienced in large scale applications of Agile and SAFe is a great framework to have in our toolkit along with our Real Agility Program.  If you are considering using Agile at scale or if you are having trouble with making Agile at scale work effectively, I hope you will contact us.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Rant about Commitment – One of the Scrum Values

Learn more about transforming people, process and culture with the Real Agility Program

The voting for re-introducing the five values of Scrum into the Scrum Guide is heating up with some great discussion (debate?).  One person, Charles Bradley is providing some interesting arguments about why “commitment” should not be included or even changed to a different word.  I have posted a response.  I strongly believe that the word “commitment” is the right word.  Here’s the first paragraph of my response:

Hi Charles, although I appreciate your concerns about the word commitment, there is still huge support for adding the five values back to the Scrum Guide, including using that “bad” word. I would like to present to you an argument for the use of the word commitment by telling a story.

 

A long time ago I had a really good friend….

 

Check out all the discussion on the five values of Scrum and please comment or vote (or both!)


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail