Great little presentation on Retrospectives… and a bonus download!

If you are a ScrumMaster or Coach or Project Manager or Process Facilitator of any kind, I encourage you to become a master of Retrospectives.  I just happened upon this great little set of slides and presentation notes about Retrospectives by a couple of people, Sean Yo and Matthew Campbell, done a couple months ago.  Very helpful with some practical information, some great links… I strongly recommend checking it out.  My only concern is that they limit the scope of retrospectives too much.  I have a list of topics that I think can and should be considered in a retrospective:

  • Technology / tools
  • Work space / physical environment
  • Corporate culture
  • Corporate standards and policies
  • Teamwork
  • Work planning and execution
  • Skill sets
  • Interpersonal dynamics
  • External groups
  • Personal circumstances and needs
  • The process you are using

 

This list comes from a presentation I used to include as part of my Certified ScrumMaster course.  (Now, in my course I teach three specific methods of doing retrospectives as part of an in-depth simulation exercise.)  Here is a PDF version of the Retrospectives Module.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Back to the Basics: Coding and TDD

I’ve been working for the past year on building the Scrum Team Assessment (yes, you can still go get it for your team :-) ).  I’ve been doing all the work on it personally and it has been great fun.  The best part of it has been that I’m back into coding.  And, with that, of course I have had to take my own advice about Test-Driven Development and the other Agile Engineering Practices.  But it hasn’t been easy!

I’m using PHP for the web front end, and Python with OpenERP for the back end.  My testing tools include Selenium for Acceptance Testing and PHPUnit for unit testing.  And… nothing yet for the Python back-end.  This is still a sore point with me.  Normally, I would find the back end TDD process easier… but OpenERP has been a HORRIBLE BEAST to use as a development platform.  Well, I might exaggerate a bit on that, because it is really just the complete lack of well-written API documentation and sample code.  Which is funny, because there are tons of open-source extensions for OpenERP written.  Anyway, I don’t want to complain about it too much, because in many other ways it is a fantastic platform and I wouldn’t easily switch it for anything else at this point.

Back to testing.  Last week, a client using the Scrum Team Assessment found a bug… and it was one of those ones that I know made them consider not using the tool anymore. Fortunately, our contact there has the patience of a Redwood, and is helping us through the process of fixing the system.  How did the bug happen?

Because I didn’t do _enough_ TDD.  I skimped.  I took shortcuts.  I didn’t use it for every single line of code written.

<Failure Bow>

The question for me now, is “why”?  Fortunately, the answer is simple to find… but solving it is not as easy as I would like.  I didn’t follow my own advice because I was learning about too many things at the same time.  Here’s what I was learning all at once over a three week period in December when I was doing the real heads-down development work:

  1. PHP and PHPUnit
  2. Python
  3. OpenERP (APIs for persistence and business logic)
  4. RML (a report generation language)
  5. Amazon EC2, RDS and Route 53
  6. Some Ubuntu sys admin stuff
  7. VMWare Fusion and using VMs to create a dev environment
  8. Postgresql database migration
  9. Oh, and refreshing on Selenium

Like I said, FUN!  But, a bit overwhelming for someone who hasn’t done any significant development work since 2006-ish.  As well, because of learning about so many things, I also didn’t have a good setup for my development, testing and production environments.  Now I have to clean up.  Finally, I also forgot about another important Agile Engineering practice that is used when you have lots of intense learning: the Architectural Spike.

I have to make sure that I take all that I’ve learned and create a truly good dev and test environment (because that was a huge hinderance to my work with both Selenium and PHPUnit).  And I have to take the time to learn to do the testing in Python (I would love suggestions on a good unit test framework)… and go back over that code, even though most of it is simply declarative of data structures, and make sure it is well-covered by unit tests.  Ideally, I might even consider throwing some code away and starting from scratch.  One possibility I’ve considered is to get rid of PHP entirely and build the whole system with Python (I’d love some thoughts on that too!)

Why am I doing all this?  Well, I really think that the Scrum Team Assessment is an awesome tool for teams that maybe can’t afford a full-time coach.  It certainly isn’t a complete replacement, but I’ve poured my knowledge and experience into it in the hopes that it can help a bunch of people out there do Scrum better… and more importantly, create great teams that produce awesome business results and where people love to come to work every day.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Agile Estimation with the Bucket System

I have added a pdf download of this article about Agile Estimation with the Bucket System.  It’s just a handy, nicely-formatted document that can be used for quick reference.  It is now part of the materials I give out for my Certified ScrumMaster training classes.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Leadership Transformation Team

Leadership IconOne of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track.  This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team.  This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.

The very first thing, of course, is to establish who should be on the Leadership Transformation Team.  There are six major categories from which the team must find representatives:

  1. The Executive Sponsor, for example the CIO
  2. Business Management, for example an SVP of Sales or Product Development
  3. Process Management, for example the head of the PMO or Compliance
  4. Technology Management, for example VP of Technology or Development
  5. Human Resources, for example a Director of Staff Development and Training
  6. and Apprentice Agile Coaches / Agile Champions

In total, the number of people on this team should be no more than 12, but smaller is better.

Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:

  1. Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
  2. Lead by Example: use of an Agile approach to run the Leadership Transformation Team’s work – we recommend OpenAgile for the process, but Kanban may also be used.
  3. Empower Staff: focus on removing obstacles by making structural changes in the organization, helping staff master standard Agile processes and tools, and eventually, creating innovative Agile approaches customized for the organization.

This leadership support is a critical success factor for an Agile Transformation.  One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation.  This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation.  At a high level, these include:

  • Hiring, performance evaluation and compensation
  • Reporting relationships
  • What to do with project managers, business analysts, testers and certain middle managers
  • Key metrics and processes for measuring progress
  • Technology and physical environment
  • Vendor relationships and contracts
  • Compliance, regulation and documentation

Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.

One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates.  If something is part of their three core responsibilities, it must be handled directly by the members of this team.  Therefore, the team members need to allocate a significant percentage of their time to the effort.  Usually 20% is sufficient to get started.  The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.

See also our article about the Recommendations component of the Real Agility Program.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Planning Game for Agile Estimation

I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing.  The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book.  There are also two links added at the end of the article.  One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Start of a True Team

I wrote this article for our Real Agility Newsletter, but I wanted to share it here too, just in case some of you don’t get it.  I think this is important to share because it gets to some of the deep values of Agile and good teamwork.

- – - – - – - -

The team really is important. Last month I wrote about love. This month, I’ll write about commitment. Our team has gone through some extreme tests this last month. Commitment kept us together.

Our business has been through crisis before. In the second half of 2005, my own financial mis-management led to near-bankruptcy for the business and for myself personally. My dear long-suffering wife and business partner, Melanie, kept things under control as we recovered. In late 2009 the Great Recession hit us hard and we had to cut our staff back to just Paul and myself by laying off three talented friends and cutting work to a loyal subcontractor. That was incredibly painful for everyone involved. A similar crisis occurred again in late 2011, although it wasn’t as severe. In September last year, our projections were showing a looming crisis… but we narrowly averted any layoffs when a smaller consulting deal closed and one person was let go for unrelated reasons. We still needed more work, and in late fall we were expecting to close three important deals.

In January we knew we were in trouble. Business was not booming. In fact, those three important deals had fallen through with nothing obvious on the horizon to replace them. Our office management was in a shambles with two recent changes in staff and very little continuity. Our accounts receivable had several items that were waaaay overdue. We were starting to dig deep into our operating credit with no obvious way to climb back out. The partners, Paul, Travis, Melanie and I started to talk about serious stuff: deep layoffs. We were worried we may even have to cut all the way back to just me doing work (mostly CSM classes) – a staff level we haven’t seen since 2007!

Two weeks ago, the four partners had an emergency weekend meeting after our early February attempts to build sufficient immediate cash flow failed. We consulted for over four hours around a single question: what should we do? Our projections were showing us running out of credit in just four weeks, our business development pipeline was almost empty and the few things in it were clearly long-shot deals, at least in the timeframe we needed. It seemed almost impossible to avoid deep layoffs. Our love for each other seemed almost irrelevant to the crisis, despite the depth of our feeling.  The consultation was difficult and filled with despair.

My memory for exact words is poor. I remember concepts, relationships and feelings. During that weekend consultation, one thing really stood out: we started to talk about commitment. We talked about what it would mean to be committed to each other and to the business vision of transforming people, process and culture. Most powerfully, we talked about the commitment of our newest employee, Nima, who seemed determined to go to the ends of the earth, to the very last moment to help us all succeed. As we talked about commitment, we came to our most powerful decision: sink or swim, we are all in this together to the end.

After that critical point in our discussion, we set some goals, determined some important activities, and decided to go literally day-to-day in deciding if it was time to wrap up the business. And, strangely enough (I say ironically), we decided we needed to shorten our planning cycle from a month to two weeks, increase the discipline of our team’s interactions to bi-daily check-ins, create a detailed set of dynamic plans for the two weeks, and have a review meeting at the end of the two weeks. Sounds a bit like an Agile team, doesn’t it?

What happened? Well, we’re still around. We’ve closed enough business that our projections are now showing us staying in a steady state financially for the next three months. That’s a dramatic turnaround from just two weeks prior. We aren’t going to run out of credit. In fact, we now have enough prospects that we expect to be extremely busy in just a couple more weeks. Our end-of-cycle review, which happened on Friday, was still difficult. There is still great uncertainty about many things. But the one thing that is crystal clear, strong as steel, and deep as the deepest ocean is our commitment to each other to succeed together. We are a true team.

- – - – - – - -

If you have similar stories to tell, I would love to hear them!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

A Conference Call in Real Life (youtube)

I’ve started to show this video in my public CSM classes (see sidebar for scheduled courses) as part of the discussion about why co-location for Agile teams is so important.  The video is a humorous look at what conference calls are like.  Probably the most notable part of it is the fact that on a conference call you can’t see people’s body language and facial language which are important cues for efficient communication:

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Two reviews of SAFe (Scaled Agile Framework)

SAFe (Scaling Agile Framework) is gaining in popularity.  Ron Jeffries recently attended a SAFe training session and has written a great review.  I particularly like what Ron says about the idea of being properly Agile:

SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.

SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.

 

Neil Killick seems to have even stronger opinions about SAFe, and is quite direct about them.  I like what he says in one of the comments on his blog post:

So you can go the SAFe path or the Scrum and Agile path. All you need to do i[s] figure out how big a cliff you want to deal with down the road.

I don’t personally have any experience with SAFe so I won’t make any big claims about it either way.  However, I do appreciate that the popularity of SAFe, like the popularity of Agile/Scrum* will probably lead to studies showing modest qualitative improvements of 20% to 40% increases in productivity.  Is this just the Hawthorn Effect at work?

When I help an organization with Agile principles and methods, I hope and expect dramatic measurable improvements.  Sometimes this results in people losing their jobs.  Sometimes this means people have nervous breakdowns.  It can be very painful in the short term.  SAFe, by it’s very name, seems to be anti-pain.  That doesn’t bode well.

Here are a few other interesting links to information about the Scaled Agile Framework:

Has SAFe Cracked the Large Agile Adoption Nut? – InfoQ

Unsafe at Any Speed – Ken Schwaber

Kanban – the anti-SAFe for almost a decade already – David Andersen

* There is no such thing as “Agile/Scrum” but that’s what lots of people call Scrum when they don’t do Scrum properly.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

User Stories and Story Splitting

In Scrum and other Agile methods, a common way to manage feature requests is with User Stories.  I’ve been teaching people about User Stories and doing workshops with teams for a long time.  Out of that work, I’ve created a very simple PDF User Stories and Story Splitting reference sheet that might be handy.  Please feel free to download it and share it.  This document is something that I explain in-depth in my Certified Scrum Product Owner training seminars.

There are a number of sites out there that include some details that are left out of the reference.  Please see, for example, “Patterns for Splitting User Stories” by Richard Lawrence.  See also the great foundational article on “INVEST in Good Stories” by Bill Wake.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Agile Coaching Patterns Wiki

Coaches for Agile teams and organizations is a growing profession.  I’ve been coaching for a long time, and I’ve used/invented/learned-about many different techniques or interventions for coaching in the context of Agile teams.  I have recently started a Wiki to capture some of this information.  (Originally, I was hoping to write a book, but I don’t have the time to do it on my own or even to coordinate a multi-author effort.)  This is an open invitation to participate in the wiki.  I won’t make it fully open (like wikipedia), instead, it will be by invitation.  Connect with me on LinkedIn and mention you would like to contribute, and I will set you up with an account… and then you can go nuts :-)  If there end up being several contributors, I’ll make a block on the front page for links to contributors and/or their organizations.

Check out the Agile Coaching Patterns wiki.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Update: Real Agility Staffing

Check out our updated website: Real Agility Staffing – Connecting Great People to Great Companies in an Agile Way!  If you are searching for a job, or even just thinking about your career possibilities, please fill in our survey about your skills and experience.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Reminder: Real Agility Staffing – Online Survey

Real Agility Staffing Logo

Quick reminder about the launch our new business: Real Agility Staffing – Connecting Great People to Great Companies in an Agile Way!  If you are searching for a job, or even just thinking about your career possibilities, please fill in our survey about your skills and experience.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing Real Agility Staffing

Great news for those out there in the Greater Toronto Area and Southern Ontario: Berteig Consulting Inc. and three additional partners have launched our new business: Real Agility Staffing – Connecting Great People to Great Companies in an Agile Way!  If you are searching for a job, or even just thinking about your career possibilities, please fill in our survey about your skills and experience.  We have two initial open positions for senior agile practitioners related to quality and software development.  Let us know if you are interested or know someone who is.

Eventually we hope to grow to other geographical regions so if you are outside the areas I mentioned, please feel free to do the survey to let us know about your existence :-)

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Certified ScrumMaster one of the top paying certifications of 2014

Interesting list here on Global Knowledge (a certification and training vendor (just like Berteig Consulting :-) ) ).  CSM is #6 in pay at $107,396 (is it really 6 significant figures of accuracy?  Wow!).  Anyway, it is cool to see the CSM cert on such a list since I’m one of a small number of Certified Scrum Trainers.  If you’re interested in coming to one of my classes and getting this certification for yourself, please check out my course listings in the sidebar on the right here on Agile Advice.  There’s many in Canada, there’s some in the US and there’s some in China.  Hopefully see you at one of them sometime soon!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Pragmatism, Fundamentalism and Transformation – the Three Modes of Scrum

Most organizations don’t get the potential benefits of Scrum.  In fact, I would guess that out of all the people who have come through my Certified ScrumMaster or Certified Scrum Product Owner classes, fewer than 5% have gone back to their organizations and seen the 4 to 10 times growth in productivity that Scrum can enable.

Why?

Pragmatism – Arrogance and Defeatism

Pragmatism as applied to Scrum is the approach of taking only the “good things that are possible for us” from Scrum and using those in a team or an organization.  This might mean doing the Daily Scrum meeting, but giving up on many of the obstacles raised there because they are too hard to overcome.  Another common example of this is creating a team of technical people who contribute time to the Scrum Team and possibly to other priorities instead of the idea of creating truly cross-functional teams with all members fully committed to the Scrum Team.

This pragmatism often results in some benefits: better communication among team members, shorter feedback loops with users and customers with the team, or a stronger focus on business value for the scope being worked on by the team.  It might amount, in practical terms, to a 15-25% productivity improvement.

But, really, it sucks, and it’s not Scrum.

For teams and organizations that are new to it (three years or less), this is like an individual going to a dojo to learn Karate and, after the first session, telling the Sensei, “hey, this was really interesting but I can’t stretch that way so I’m going to do the kick differently – don’t worry, it’s better than what I did before – let’s move on to other things that I can do!”.  In other words, it’s arrogant and defeatist.  Regrettably, a lot of arrogance and defeatism goes by the much more palatable label of pragmatism.

You can’t make up what you want to do and call it “Scrum”.  Scrum has a definition (which has changed somewhat over time) and if you do something different from the definition, please call it something different.

But please, don’t mistake my comments for a call to…

Fundamentalism - Inoculation Against Scrum

It’s less common, but some people go here.  They learn Scrum the one true way and decide that come hell or high water, they will make their team do it that way!  Scrum this way is rigid and cultish.  Nevertheless, done this way, Scrum can still have some (temporary) benefits, similar to the pragmatic approach.  The challenge here is that it’s not usually sustainable and the people who participate in this type of Scrum are often “immunized” against it.  They’ve had a bad emotional experience with Scrum due to the inflexible, intolerant approach to implementing it.  Justifiably, those people don’t want to repeat the negative experience and so they actively avoid Scrum or even bash Scrum publicly.

It really is a process very much like how our antibodies work in human health: we are exposed to a microbial disease which itself may temporarily succeed in propagating in our body, even long enough to get us to infect someone else.  But after our immune system fights it off, we are ready for the next attack, will recognize it and repulse it far more quickly so that it can’t spread.  Trying to spread Scrum by doing it as an invasive take-over of an organization is very likely to cause the same sort of reaction among the people in the organization.  And anyone who comes along a little while later, even with a much more appropriate way of doing Scrum will likely be quickly rejected by the long cultural memory of the Scrum antibodies!

So where does that leave us?  There really is only one option for doing Scrum, allowing it to flourish, and getting amazing long-term results:

Transformation – The True Potential of Scrum

Remember that Scrum is based on the values and principles of the Agile Manifesto, and that Scrum itself has five values:

  1. Commitment
  2. Courage
  3. Focus
  4. Openness
  5. Respect

Taken all together, these values and principles constitute the spirit of Scrum.  They are the belief system.  They are the energy behind the framework.  This means that as a team uses Scrum, it must recall these values and principles and try to put them into practice through Scrum.  Not just the team, but the team’s stakeholders also need to be aware of these values and principles and also try to put them into practice.

For example, if you are a functional manager for someone who is on a Scrum Team, it is tempting to ask that person to do work that is not actually part of the Scrum Team’s plan. This is a distraction and causes both the individual person and the other Team members to lose focus.  Losing focus delays or prevents the creation of a high-performance team.  Therefore, as a functional manager, it is much better for you to “cover” for your subordinate, not distract them, and in every way allow that person to focus on their work for the Scrum Team.

Transformation doesn’t come just from adopting a set of values and principles, nor does it come from using a framework of processes and artifacts.  Transformation requires love and passion.  Transformation occurs when all the members of the Scrum Team, and their stakeholders start to develop intense personal bonds and become passionate about the potential of using the Scrum tool.

I really like the “hammer analogy“.  When you first use a hammer, you will likely find it annoying and painful to use.  You hit your thumb, your muscles get tired, etc.  But after getting better at using it, you start to see its potential: the hammer is an elegant, effective tool.  In a small way, you love the hammer, in part because of the results you can get with it.  Perhaps you have experienced this if you have ever tried to finish an unfinished basement: after you successfully put up your first stud wall, you think, “wow, I love doing this.”  That sense of accomplishment gives you the passion to continue to use the hammer.  So it is when using Scrum…

you allow Scrum to transform you and your organization not the other way around.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail