Scaled Agile Framework: I Learned about Weighted Shorted Job First (WSJF)

Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items.  The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.

Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done.  Scores therefore give a sequence to jobs.  The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”.  The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.

In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners.  The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.

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

Scaled Agile Framework: I Learned about ROAM

The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM.  The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning.  ROAM stands for Resolved, Owned, Accepted, Mitigated.  The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them.  These risks are then place on a visible grid that has each of the four categories marked.  In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning.  Cool!

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

Agile Manifesto and Enterprise – Rant and Rave (Session Proposal)

I’ve proposed a session called “Agile Manifesto and Enterprise – Rant and Rave” for the Toronto Agile Community’s conference “Toronto Agile and Software“.  The session is based loosely on my earlier article “The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization“, as well as some of the things that I do in the 2nd day of my Certified Scrum Master training session.  If you are thinking of coming to the conference, I would greatly appreciate your votes or feedback on my session proposal!

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 Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization

When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:

  1. The Agile Values and Principles – These describe the culture and, in the Agile Manifesto, are the definition of the word “Agile” as applied to software development. I didn’t write the Agile Manifesto so I don’t get to re-define the word Agile.  To give an example: in the manifesto it says “The best architectures, requirements and designs emerge out of self-organizing teams.”  As a former enterprise architect at Charles Schwab, I struggled with what I saw as incredibly wasteful up-front architectural activities when I knew that developers would (sometimes) ignore my glorious ivory-tower plans!  Therefore, if you are still doing up-front architecture and forcing your teams to comply to that architecture, you aren’t Agile.  Therefore, as an individual, a team or an organization, you need to make a conscious decision to “BE” Agile or not… and if you decide not, then please don’t call yourselves Agile.
  2. The Agile Toolkit – There are many hundreds of distinct tools in the Agile toolkit including Scrum, OpenAgile and other “large” Agile methods, as well as the Planning Game, Product Box, Test-Driven Development and other “small” Agile techniques.  Any group of people trying to BE Agile, will need to use dozens or even hundreds of different Agile tools.  I call them tools because the analogy with construction tools is a very good one.  Scrum is like a hammer.  But you can’t do much with just a hammer.  Scrum is a great, simple tool.  But you always need other tools as well to actually get stuff done.  All the tools in the Agile Toolkit are compatible with the Agile Values and Principles.  Even so, it is possible to use the Agile Tools without being Agile.  A Scrum team that never gets together face-to-face is not an Agile team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  (Video conferencing doesn’t count.)
  3. The Agile Organization – When you start using a tool, there is a learning period.  We start by being conscious of our incompetence and as we persist, we become competent… but it isn’t natural or habitual yet.  Eventually, with continued use, we become unconscious of the tool.  IDE’s and version control are like this in most organizations: we don’t even think about them!  But getting through that initial stage requires us to change; to develop new skills.  This process usually requires discomfort or pain (including psychological pain).  An organization attempting to BE Agile and to use many of the tools in the Agile Toolkit will need to make many changes and often these will be difficult.  For example, incorporating the Product Owner role from Scrum into your organization requires new role definitions, new performance evaluation practices and criteria, new compensation systems, new communication and reporting mechanisms, new authority and accountability processes, etc. etc.  All of the changes required are about creating Enterprise Agility throughout the whole organization, beyond just software or IT.  These extensive changes are often started in a very ad hoc manner, but at some point they need to become systematic.  This is an important decision point for executive management: are we going to be Pragmatic about our Enterprise Agile adoption, or are we going to be Transformative about our Enterprise Agile adoption.

All of this is summarized in this graphic:

The Agile Framework [PDF]

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

Project Lessons Learned vs. Sprint Retrospective – 17 Points of Comparison

Another fantastic article by Mike Caspar: Sprint Retrospective vs. Lessons Learned (a Generalization)

Mike says:

Consider reviewing these differences in your environment to determine if you are getting benefit from your Sprint Retrospectives and following their intent.

 

Here are a few other Agile Advice articles about Retrospectives.

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 Three Fundamental Principles of Agile Estimation – The Third One Will Surprise You!

You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation.  This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques.  The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved.  There are three fundamental principles of Agile estimation:

Principle One: Collaborative

Agile estimation methods are collaborative.  This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort.  Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates.  Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.

Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem.  Teamwork and groupwork are based on this concept.  This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.

The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person.  This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort.  This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders.  Another way of stating this principle is that no individual can be punished for a bad estimate.

Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated.  This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.

Principle Two: Relative Estimation

Imagine you are shown a glass bottle with some water in it.  You can see the water sloshing around.  Someone asks you, “how much water is in the bottle?”  You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.”  Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity.  In both cases, you are doing a relative estimate of the amount of water in the bottle.  You are comparing the amount of water to a known quantity.

Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?”  If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum.  You have no basis for comparison.  You might take a wild guess, but it is just that.  Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is.  But those cases are, again, relying on our inherent ability to see relative differences.

So instead of ignoring this capacity, in Agile estimation techniques, we leverage it.  When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work.  The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units.  For example, it is common to use “points” when estimating the effort for Product Backlog Items.

When doing relative estimates it is very important to ensure we are comparing “apples to apples”.  Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done!  If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.

This last point is subtle, but important.  If you have already done something, you know much more about it.  If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it.  By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.

It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).

Principle Three: Fast

In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates.  Whoa!  Why is that?  Because estimation is waste.  You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building.  Therefore, both Agile and Lean concur: do your utmost to eliminate that waste.  There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)

In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast!  Really fast!!!  Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.

There are really only two modestly good reasons for doing estimation in an Agile project or product:

  1. Estimates provide simplified information to the Product Owner to allow him/her to make sure the Product Backlog is ready for the next Sprint (ordered, refined).
  2. Estimates allow stakeholders, including the team doing the work, to generate high-level common understanding and expectations without dwelling on details.

As a business stakeholder, one can do a simple mental exercise.  Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?”  Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results.  If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).

Bonus Principle: We Suck at Estimating

Most people doing estimation in traditional project management try to measure in units like person-days or dollars.  There is no doubt that these units are useful if you can get good estimates.  However, most of the people doing estimation are fundamentally and irredeemably bad at it.  How do I know?  Because they are not wealthy… and have thereby proven that they cannot predict the future.  If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth.  Given that, it is fruitless and wasteful to try to get better at estimating.  Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now.  Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.

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

Agile Scam – Abusive Comments… What To Do?

This is “my” blog – I write most of the articles, and it is owned by the business in which I am a major partner.  I recently was reviewing comments in the moderation queue and came across this “gem”:

This man is a scammer, agile snake oil only 600, what a bargain. Filthy scamming piece of crap, he’s probably stupid enough to believe his own s**t too.

I’m assuming this person, who is anonymous, is upset either about something I said here on this blog, or possibly something that I (or one of my colleagues) did while we were working with one of our clients.

Several months ago, I was also made aware of a posting about Berteig Consulting (and myself) on Ripoff Report.  I’m not going to link to it, but I will quote it here:

Our company undergoes Agile transformation. Our management decided to hire Berteig Consulting

- a bunch of charlatans spending hours talking absolute nonsense.

They promise sky rocketing performance because they teach us to ( than follows a great number of words with no meaning). We must reflect in Buddish manner, talk to each other, discuss obstacles, be truthful, play stupid games,…. They charge company big money for waisting employees time for endless meetings and providing us with useless information.

Honestly, these sorts of comments make me a bit sad, a bit down.  But here’s what I think about them.

The Agile “Scam”

Let’s make sure we know what we are talking about.  Agile is defined in the the Agile Manifesto.  If you aren’t familiar with it, please take a look.  Basically, the purpose of Agile is to find better ways of building software that are based in practice.  In other words, by people actually building software, and sharing their knowledge, experience and the values and principles that helped them do what they did.

The thing about values and principles is that they are a bit like axioms in formal logic: you can’t prove them.  They are a starting point.  So, if you read the Agile Manifesto and you happen to think that

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

is “Buddish” (whatever that is, presumably Buddhist), and that being “Buddish” is bad or useless, then that is certainly your right.  I can’t prove that this principle of the Agile Menifesto is “right” or “correct” or “always the best thing evar.”  But I like it.  I think it’s good.  I believe in it.  So I guess I am stupid enough to believe my own s**t.  Except that it’s not my own.  I didn’t write the Agile Manifesto.  But I do fully support it.  And, without exception, I think that if work environments tried to put in place the values and principles of the Agile Manifesto, the world would be a (slightly) better place.

So is it a scam?  Well, if it is, I’m being scammed too.  I work crazy long hours, and although I make a decent living, I’m certainly not getting rich off this Agile thing.  When I think of a scam, I think of “get rich quick” or “lose 20 pounds in 20 days” or those sorts of things that promise unbelievable results with little or no effort.

Unfortunately, Agile isn’t like that.  Here is how I think of three Agile methods:

  1. Scrum: incredible results at the cost of incredible pain.  This is kind of like I imagine detox.  An organization is near death and needs to be revived so extreme measures (Scrum) have to be taken.  Requires significant outside help.
  2. OpenAgile: good medium-term results that require significant investment.  This is kind of like making a conscious change from a poor diet with lots of junk food to a good diet: takes discipline, but do-able with good encouragement and support.
  3. Kanban: modest long-term results with relatively low effort.  This is like deciding to change only one thing about your health at a time even if you have lots of health problems.  Lots of small wins accumulate over time.  Doesn’t require much outside help.

Of course, my descriptions of these are _vast_ simplifications for the purposes of discussing the Agile “scam”.  Do professional sports teams or Olympic athletes need coaches?  Probably most people would agree they do need that outside help.  Is coaching sports teams or athletes a “scam”?  Nope.  Not all coaches are good, certainly, but coaching is an essential (sometimes difficult) investment to get to that level of high performance.

Bad Agile

Of course, not all Agile transformations or adoptions are good.  The Agile Manifesto is not easy for most people, teams or organizations to truly embrace.  One of the most common problems I see is that an organization believes that it can have distributed or remote team members and somehow have effective communication among those team members.  This is just one simple example that comes directly from the Agile Manifesto:

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

I guess, technically, the Agile Manifesto doesn’t out-and-out say that a team must be co-located, but boy-oh-boy does it ever make a difference.

And yet, doing radical collocation is damn hard for most organizations.  So lots of organizations try to adopt Agile techniques without collocation.  And, mostly, their results suck.  Or they try to do collocation, but totally botch it.

Any given principle or value of the Agile Manifesto has its own challenges.  And so most Agile implementations are distant echoes of the incredible results that some rare organizations achieve when they really get Agile.

My Track Record

As a consultant, coach and trainer, I sometimes wish that I could say that I have never failed, that I have never given bad advice.  That’s because in complex human systems, it is very very very hard to sort out cause and effect relationships.  If one of my clients fails to have a dramatic transformation is it because:

  • I gave bad advice?
  • Someone at the client subverted the transformation effort?
  • An executive didn’t support it enough?
  • Market forces destabilized the transformation?
  • The organization’s culture treated Agile as an invasion and fought it off?
  • Agile just wasn’t “right” for the organization?
  • Agile wasn’t adopted soon enough?
  • etc….

On the other hand, I couldn’t very well be a coach, consultant or trainer if I didn’t have a clue.  My colleagues, Paul and Travis (who are named in the Ripoff Reports article), and others whom I have worked with (Nica, David, Mike, Deborah, Christian, another Mike, Allistair, Holleh, yet another Mike,a Michael, and another Michael (wow!), Garry, Jim, Mark, Mary, Sanjiv, yes even another Michael, Julien, Brenda, Derek…) are all smart, experienced, sincere, helpful people… who all know what it takes to produce good results.

The “Secret” Essence of Successful Agile

And, strangely, the essence of it is encapsulated in just a few basic basics:

Truthfulness (vs. hypocrisy, lies and deception)

Collaboration (vs. competition or individualism)

Service to Others (vs. greed and apathy)

and, ultimately, love between people.

So.  To those two people who felt they needed to spew out their hatred, their pain, or whatever it is that they are suffering from, I encourage you to contact me directly.  My email address and phone number are public.  I can’t promise to solve your problem, but I will give you love and whatever help I can extend.

 

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

Sometimes I Just Need to be Pedantic

Here’s an article that just drives me nuts: Using Agile Scrum to Manage Developer Teams. The problem I have with this article is that it is just crazy bad in its use of language and ignorance about the fundamentals.  Here are some examples:

Agile Scrum

This is not a thing.  Agile is a philosophy of doing software development.  Scrum is a particular instance of Agile.  Saying “Agile Scrum” is kind of like always saying “furniture table” instead of just “table”.  It shows a pretty fundamental gap in the writer’s knowledge.

As with any software development lifecycle (SDLC) framework…

Scrum is definitely not an SDLC.  Scrum is a framework (and the author uses the term correctly a little earlier in the article) but is deliberately missing most of the details that would make it an SDLC.  It is designed to be incomplete instead of complete.  SDLC’s are meant to be complete solutions for delivering software.  Scrum shows you the gaps and exposes the problems you have delivering products but doesn’t tell you how to fill in the gaps and solve the problems.

Next, the article mis-quotes Scrum.org by incorrectly capitalizing Product Owner and Scrum Master.  And in some sort of ironic error, puts “Scrum master” in quotes.  Yikes!

The conclusion of the article about when you might choose not to use Scrum is also a bit mis-guided.  There are lots of organizations successfully using Scrum in highly regulated environments: medical, banking, government, etc.  Some of them are even my clients!  I would be happy to provide direct references if needed.

Finally:

Does your team work remotely? Despite advances in video technology and online collaboration tools, the requirements for structured daily contact makes Agile Scrum tough to implement successfully for virtual teams.

Yes, remote work is bad with Scrum.  But it’s also just plain bad.  Don’t do it if you can avoid it.  All that Scrum does with a remote team is show you just how bad it really is.

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

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

Reflections on Agile Business Leadership

From push system to pull system thinking

One of the disconnects holding teams back the most in an organization embarking on an Agile transformation is the lack of will and perhaps understanding of vision on the part of the business. The required shift in thinking is from a “push system” to a “pull system”. Historically and still culturally, most organizations, even those claiming to be ‘Agile’ are very much push systems. The business folks in client services – VPs, Directors, sales people, etc. seem to make time (deadline) commitments to clients on behalf of teams and then the teams are given the deadlines to finish the work. Sometimes, the deadlines are decided on in consultation with particular individuals on the teams and very rarely, if ever, with the actual teams themselves. In any case, the fact that the business is almost entirely deadline-driven is the centre of the push system. Deadlines push or drive everything else. Deadlines are fixed and often considered non-negotiable. Deadlines are a taboo subject – it is considered a waste of time to even discuss them because they just don’t and won’t ever move. The general attitude is that if we try to move deadlines, we put the entire business at risk because our clients will drop us and turn to one of our competitors who claim to be able to promise and keep deadlines. If we lose our clients, we lose business, we lose money and it potentially puts us all out of jobs. What this exposes is not only a push system driven by deadlines, but a culture that is actually driven by fear. The not-so-implicit message is that if you miss a deadline, you might lose your job, so you had better do whatever it takes to not miss the deadline. Or else. Push and pull systems and mentalities are like oil and water – they don’t mix. In Agile, there is no place for fear of failure. Rather, teams must be allowed to fail (miss deadlines) and learn from their failures (plan better).

Why quality, not time/cost or scope is non-negotiable

The “make the deadline or else message” is couched and clouded by other talk. The main excuse is to blame the client, as noted above. “That’s just the way our clients work, the way the market works”. Of course, such an excuse contains a kernel of truth. Without a true understanding and embrace of Agile, the idea of not meeting deadlines and the perceived consequences can be truly scary. Generally, there is an understanding from the business that the productivity of teams may drop somewhat as they progress through the storming stage. What this translates into is a difficult discussion with clients around delayed delivery. It is tolerable in that it is temporary. “Once the teams get up and running, we can go back to meeting our deadlines, and even be able to deliver early because Agile is supposed to be faster.” But the benefits of truly adopting Agile are much more powerful than this.

Understanding the true business value of Agile

What needs to be understood is the true business value for investing in Agile processes and practices – how it may add cost and time to the initial development Cycle, but how it saves both the business and the client tremendously on technical debt and support long-term. This needs to be understood and championed by the business in order for the organization to become liberated from its enslavement to the push system mentality. At the heart of such a mental liberation is the wholehearted adoption and commitment to the Agile/Lean principle that quality is non-negotiable. The investment in Agile processes and practices is essentially an investment not only in quality, but in continuous quality improvements towards the goal of being able to frequently deliver products of increasing relevance and quality (value). The ability to ship frequently allows for sustainable growth. All of this is made impossible by the deadline-driven push system mentality/culture of fear.

The urgent need for slack

One of the first things that a team needs in order to focus on continuous quality improvements is slack so that it can learn to learn. The first goal of the business leadership should be to facilitate scope and deadline slack for the team. This goal should also be fully and visibly championed by the business leadership. In order to develop the capability to facilitate slack, the business needs to gain knowledge around the purpose and importance of Agile processes and practices and be able to articulate a strong business case for them. The business leadership needs to develop the skill of educating the team, management and business leadership on the long-term benefits of an Agile transformation – the transformation from a push system to a pull system. The key stakeholders and business leaderships need to possess the courage to engage in difficult conversations with management and clients who may be upset by the short-term pain of delays and missed deadlines and protect the team from continued attempts to push work into the team. Perhaps above all, the business leadership needs to develop an attitude of learning – a humble learning posture that allows for the setting aside of preconceived notions, fears and prejudices around what it means to be a good business leader. A leader possessed of this posture demonstrates a learning attitude by stressing first and foremost the importance of creating slack for the team to learn to learn. It is a common pitfall for inexperienced business leaderships and stakeholders to expect Agile to provide solutions for their push system woes, woes that include the broken trust of clients from consistently broken (unrealistic, dreamt-up) deadline promises and the crippling effects of technical debt (the fallout of the former – when scope, time and cost are fixed, quality is compromised).

If the business leadership, with the support of the Process Facilitators and the Transformation Team, is able to foster the organizational will to create slack for the teams, then the teams will have the space they need to truly focus on continuous quality improvements. This is a critical milestone on the path to realizing the true, measurable benefits of Agile. Although the support of others is needed, the business leadership is in a unique position benefitting from an intimate relationship with both the needs of the business as well as the daily life of the team.

Why the business leadership needs to own the process

The first way that the business leadership creates slack for the teams is by championing the process. In OpenAgile, like all other Agile methodologies, there are key features of the process the purpose of which are to give space for new teams to begin to make the often seemingly inconsequential, yet ultimately critical first steps towards continuous quality improvements. One of the most obvious of these features is the Agile team meetings. In the early stages of team development, organizational understanding and will, the OpenAgile meetings (particularly the Reflection and Learning aspects of the Engagement Meetings in OpenAgile) can easily be discounted as an obstacle preventing the team from getting the “real work” done. What is often forgotten under the pressure of deadlines is the fact that in order for a team to be able to learn to make continuous quality improvements, it needs to develop the capability of systematic (frequent & regular) inspection and adaptation of the way that it works. It is easy to save on the short term pain of perceived non-negotiable deadlines (meeting deadlines at all cost = success) by compromising on investing in the process, especially when the team is still learning to learn and the effectiveness of the meetings is not yet apparent. When the team and the organization have an expectation of Agile as something that fits into the push system and allows for a team to function better within such a system, it can be hard to understand how spending time in a kind of meeting that the team doesn’t seem good at yet can be of any value. This is where the business leadership needs to stand firmly behind the process. The team needs the meetings – the space to reflect, learn and plan – in order to learn to become more effective at making continuous quality improvements – a critical feature of an effective pull system. Without the meetings, the team will never develop this critical capability and as a result, will never become an Agile team. Instead, the team will revert back to getting the “real work” done with all of the quality problems crippling the organization and which led to the decision to adopt an Agile framework in the first place.

Why the business leadership should care about burn-down

Another key feature of the process for the business leadership to understand and champion is the concept of burn-down as represented by the burn-down chart of an Agile team. Agile doesn’t care about how much work the team gets done. It assumes that the team is doing valuable work and getting things done – in other words, that the team is managing itself and working towards its goals and commitments. There are no tools in Agile for an individual, least of all the business leadership, to measure and manage how much work the team is getting done. Agile acknowledges the reality that real (sustainable) productivity cannot be forced on any team. Instead, a team grows its productivity at a sustainable pace when it is given enough slack to do so. The team makes a plan at the beginning of the Cycle based on what it understands about its capacity, works towards that goal throughout the Cycle and hopefully delivers valuable results at the end of the Cycle. By learning to apply the process of continuous improvement, quality and productivity go up hand in hand. That is the essence of the pull model. Through all of this, the team manages “how” it gets work done. The productivity of a team can be measured, but the burn-down chart is neither an appropriate nor effective tool for measuring the productivity of a team. Instead, burn-down provides one specific measurement and ONLY this one measurement: WORK REMAINING (in order to achieve the goal/commitment of the current Cycle). It does not and cannot tell you how much the team got done and even less so the whys and hows of the output and productivity of the team during the Cycle.

So what is the purpose of burn-down and why should the business leadership even care? If it can’t be used as a tool to measure the productivity of the team (in other words, if it can’t be used to manage the team) then what importance can it possibly have? These are typical questions of teams and individuals that are coming from a traditional project management, i.e. command & control, i.e. “push” system mentality. Understanding the purpose of burn-down depends on the ability to make the shift from the push system paradigm to the pull system paradigm. In a push system, burn-down is nice but somewhat irrelevant. For an organization committed to an Agile transformation (towards a pull system of self-managed teams) it is an invaluable launch pad for powerful conversations that live at the heart of continuous quality improvements.

Commitment to the business requirements come from the Agile teams

When a team decides on a plan for a Cycle of work, the plan is a commitment. This is a critical step in the Agile process. It is only after a unanimous commitment from the whole team that the team begins to work on the plan. If any individual team member feels hesitant about the work in the plan, tasks and potentially even Value Drivers should be removed until everyone is comfortable making a commitment. When the business leadership is telling a team what the plan is, then it is not the team’s plan and therefore it cannot be a team commitment. This is not only an inappropriate use of authority, it is also breaking the Agile process. Moreover, when a plan and therefore a commitment is forced onto a team, the team cannot be held accountable for failure. Worse yet, the team will never learn to plan. If a team is not able to plan, then it is not able to make commitments. If the team is overwhelmed by an overly-ambitious, management-forced plan, it will not learn to evaluate its capacity and apply that knowledge to long-term planning and project estimates. It will not learn to make meaningful quality improvements and reflect on its progress. It will not learn to self-manage or self-organize. The purpose of burn-down is to establish commitment velocity. In other words, the amount of work that the team can truthfully expect to complete during the Cycle when it is making the Plan. The difference between the number of tasks in the Cycle Plan and the number of tasks remaining at the end of the Cycle gives the team its commitment velocity. Commitment velocity is always based on minimum historical velocity. The team uses commitment velocity to make a Cycle Plan containing no more than the number of tasks represented by its commitment velocity. This allows the team to spend just the right amount of effort and time on planning and allows the team slack to focus on the truly Agile work of learning and continuous quality and process improvements. Over-planning, especially when it is wedded to over-committing or even worse, non-committing (a common push system mentality pitfall forced onto teams by the business leadership) leaves the team in a state of dependent on daily micro-management and can completely halt the progress of a team. Not to mention that this is a flagrant violation of Agile values (truthfulness, responding to change over following a plan) and principles (sustainable development). Such compromises to foundational Agile values, principles and processes may produce desired results in the very short-term, but the long-term costs can be crippling to teams and organizations. The wasteful activity associated with team dependency on micro-management is what often leads organizations to the accumulation of technical debt that places them in dire competitive disadvantage and desperate need for Agile transformation in the first place. If an organization misses out on this golden opportunity, teams can become demoralized and innocuous to the Agile practices and the promise of an Agile transformation can quickly erode.

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

Leaving your title at the Scrum team room door and pick up new skills!

Each member of an organization has a title or designation that may reflect their responsibilities or profession.  These titles may include BA, Tester, Developer, QA, PM, and others.  It is normal to be proud of our accomplishments, achievements and titles.  Unfortunately in a Scrum team these titles can limit the individual and adversely effect the team.  These same titles can label the individual as that role (example – as a tester) and only that role.  Within a Scrum team we certainly need the skills, knowledge and abilities that come with that title/role, but we do not want to limit that person to being viewed as only that role.  Each of us is the sum total of our experience, education, values, upbringing and history.  All of this is of value to the team.  We should encourage every member to fully participate on the team, to willingly share their expertise, to contribute to non-traditional tasks and to feel they are valued as a complete person rather than a specifically titled individual.   So if the goal is to leave your title behind, then it is implied you can also pick up other skills.
So how can this be accomplished.  One way is a Skills Matrix.   This is a chart that can be posted in the room to identify the skills needed and the people on the team.   On the left column you list all the team members.  Along the top you list all the various skills you need on the team.  Then each person reviews their row, looking at each skill, and then identifies how many quadrants of each circle they can fill in, based on the range below the chart.  The range is from no skills through to teach all skills in a given column.  After filling the columns and rows, now the work begins.  By using pair programming (an extreme programming method) and other methods like self-study and taking additional courses, the team member can begin to learn other skills.  The objective is to have at least two persons on each team who possess each of the skills at the level of performing all the tasks of a specific skill.  The goal is not to have every one do everything but to have a least enough people with specific skills to cover sicknesses and vacations so that required tasks are performed.  This is a method to capture the full extend of each person’s current knowledge, skills and abilities and expand on it.
Skills Matrix
Since they are hard to see, here are the labels for the number of quadrants:
0: no skill
1: basic knowledge
2: perform basic tasks
3: perform all tasks (expert)
4: teach all tasks
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 Rules of Scrum: What is Scrum and Why is it that Way?

I am starting a new series of brief articles that go through the details of the Scrum process, artifacts and roles.  These articles will be one or two paragraphs each and will have a razor-sharp focus on the fine structure of Scrum.  I have found that many people know the broad strokes, but are often missing important details.  I hope you find these articles enjoyable and informative.

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

Another Great Article by Mike Caspar

Many of you have heard that Scrum does not solve problems… it just exposes them!  Mike Caspar has written a great in-depth article about why Scrum exposes problems (and why this is good!) with lots of great examples.  I like his concluding remark:

Scrum does not have answers for not following Scrum.

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

Awesome Agile Article about the Retrospective

Glen Wang, a former student of mine, has written another fantastic article about Scrum called “The Retrospective: Know Yourself and Adapt to the World“.

I love Glen’s philosophical take on things!  This article is strongly recommended to any ScrumMasters, Process Facilitators and Agile Coaches out there!

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