Tag Archives: productivity

Agile coaching, coaching, culture, focus

The Perils of Meeting-Driven Culture

Leave a comment

Does your organization have a meeting-driven culture? Not sure? Ask yourself how much time you spend in meetings. Are they effective? Search the Internet and you’ll discover that we spend way more time in meetings than we’re comfortable admitting. The Harvard Business Review claims that the figure has doubled in the last 50 years.

The designers of Scrum recognized this and deliberately kept the formal meetings to the bare minimum. It adds up to around 12-15% if you use the entire time box. Contrast this amount to many organizations and you will discover that Scrum is quite efficient.

Many organizations I’ve consulted for don’t have deliberate rules on how to conduct meetings. They’ve allowed the meeting culture to evolve on its own. As such, meetings are not very productive.

However, practising Scrum doesn’t automatically make you immune to this meeting burden. Teams still operate within the same office and with the same people. Scrum and Scrum Masters can help teams have better meetings.

Here is a typical example of the transition from meeting-driven culture. I was coaching a Scrum team and worked in the team room alongside the development team. On several occasions (over several weeks) I asked the team to review the product backlog and make estimates. They brushed it off and refused to do this work. Instead, they did this at Sprint planning, despite complaining that it made the session long and exhausting.

I wondered if the ‘familiarity’ of the team room discussions made the backlog work appear less important. So I created a meeting outside the team room and sent an invitation via Outlook. Everyone accepted.

I kept the meeting as a regular occurrence, and the backlog review work got done ahead of Sprint planning. The team was much happier.

Why did this work? It succeeded because the organization had a meeting-driven culture—that is, planned events sent a signal that important work requires a meeting. The extra meeting clearly wasn’t necessary, but it succeeded.

This exercise helped me realize that organizations have so many meetings because they have few ways to engage.

Many office cultures don’t promote face-to-face meetings. Could it be the desk arrangement? They don’t value the serendipity of impromptu meetings. In the absence of frequent, short, high-quality meetings, people are forced to meet in rooms away from their desks.

If you see this meeting-driven culture in your organization, it’s likely an expression of what it values. Improving it will require discussions on what you value more. Shall we plan a meeting?

When I train Agile classes (Scrum, Kanban), I ask the attendees to make a list of activities that they can start right after the class. Number one on that list is co-location. That is, move your team to the same space so that they are sitting beside each other.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Links to Agile Info

Sleep and Productivity – Sustainable Pace

Link Leave a comment

Good article on sleep and productivity – you need at least 6 hours per night to not fall into a vicious cycle of lower productivity leading to longer work hours, less sleep, and then lower productivity.

The Agile Manifesto asks us to work in such a way that we can maintain our pace indefinitely.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, How-To Apply Agile, Reference Information, Scrum, XP and Lean, Theory of Agile

Pitfall of Scrum: Assigning Tasks

7 Comments

Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!!  It is better to wait for someone to step up than to “take over” and start assigning tasks.

Assigning tasks can be overt or subtle.  Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”

In the Scrum Guide, a partial definition of self-organizing is given:

Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

A more formal definition of the concept of “self-organizing” can be found here:

Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.

The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.

What If One Person Isn’t Working?

People who are managers are often worried about this.  What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing?  Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.

Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.

Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs.  Assigning tasks doesn’t make a person more productive.

What If There is One Task No One Wants to Do?

Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!

There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.

And, of course, there’s always the Sprint Retrospective!

Why Self-Organize – Why Is Assigning Tasks Bad?

Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.

Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees).  Even if this is true, it is still easy for a person to take offence.  However, most of the time it is not true.  People know themselves best.  People are best at assigning tasks to themselves.  And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.

The ScrumMaster and Assigning Tasks

The ScrumMaster plays an important role in Scrum.  Part of this role is to encourage self-organization on a team.  The ScrumMaster should never be assigning tasks to team members under any circumstances.  And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks.  If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening.  The ScrumMaster needs to be constantly aware of the activity on his or her team.

I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Agile Engineering, How-To Apply Agile, Scrum, XP and Lean

Scrum Data Warehouse Project

4 Comments
May people have concerns about the possibility of using Scrum or other Agile methods on large projects that don’t directly involve software development.  Data warehousing projects are commonly brought up as examples where, just maybe, Scrum wouldn’t work.
I have worked as a coach on a couple of such projects.  Here is a brief description of how it worked (both the good and the bad) on one such project:
The project was a data warehouse migration from Oracle to Teradata.  The organization had about 30 people allocated to the project.  Before adopting Scrum, they had done a bunch of up-front analysis work.  This analysis work resulted in a dependency map among approximately 25,000 tables, views and ETL scripts.  The dependency map was stored in an MS Access DB (!).  When I arrived as the coach, there was an expectation that the work would be done according to dependencies and that the “team” would just follow that sequence.
I learned about this all in the first week as I was doing boot-camp style training on Scrum and Agile with the team and helping them to prepare for their first Sprint.
I decided to challenge the assumption about working based on dependencies.  I spoke with the Product Owner about the possible ways to order the work based on value.  We spoke about a few factors including:
  • retiring Oracle data warehouse licenses / servers,
  • retiring disk space / hardware,
  • and saving CPU time with new hardware
The Product Owner started to work on getting metrics for these three factors.  He was able to find that the data was available through some instrumentation that could be implemented quickly so we did this.  It took about a week to get initial data from the instrumentation.
In the meantime, the Scrum teams (4 of them) started their Sprints working on the basis of the dependency analysis.  I “fought” with them to address the technical challenges of allowing the Product Owner to work on the migration in order based more on value – to break the dependencies with a technical solution.  We discussed the underlying technologies for the ETL which included bash scripts, AbInitio and a few other technologies.  We also worked on problems related to deploying every Sprint including getting approval from the organization’s architectural review board on a Sprint-by-Sprint basis.  We also had the teams moved a few times until an ideal team workspace was found.
After the Product Owner found the data, we sorted (ordered) the MS Access DB by business value.  This involved a fairly simple calculation based primarily on disk space and CPU time associated with each item in the DB.  This database of 25000 items became the Product Backlog.  I started to insist to the teams that they work based on this order, but there was extreme resistance from the technical leads.  This led to a few weeks of arguing around whiteboards about the underlying data warehouse ETL technology.  Fundamentally, I wanted to the teams to treat the data warehouse tables as the PBIs and have both Oracle and Teradata running simultaneously (in production) with updates every Sprint for migrating data between the two platforms.  The Technical team kept insisting this was impossible.  I didn’t believe them.  Frankly, I rarely believe a technical team when they claim “technical dependencies” as a reason for doing things in a particular order.
Finally, after a total of 4 Sprints of 3 weeks each, we finally had a breakthrough.  In a one-on-one meeting, the most senior tech lead admitted to me that what I was arguing was actually possible, but that the technical people didn’t want to do it that way because it would require them to touch many of the ETL scripts multiple times – they wanted to avoid re-work.  I was (internally) furious due to the wasted time, but I controlled my feelings and asked if it would be okay if I brought the Product Owner into the discussion.  The tech lead allowed it and we had the conversation again with the PO present.  The tech lead admitted that breaking the dependencies was possible and explained how it could lead to the teams touching ETL scripts more than once.  The PO basically said: “awesome!  Next Sprint we’re doing tables ordered by business value.”
A couple Sprints later, the first of 5 Oracle licenses was retired, and the 2-year $20M project was a success, with nearly every Sprint going into production and with Oracle and Teradata running simultaneously until the last Oracle license was retired.  Although I don’t remember the financial details anymore, the savings were huge due to the early delivery of value.  The apprentice coach there went on to become a well-known coach at this organization and still is a huge Agile advocate 10 years later!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Links to Agile Info

Link: Healthcare.gov website could have shipped in 1/2 the time and saved billions

Leave a comment

A colleague of mine, Robin Dymond, posted this great video about Scrum and healthcare.gov on Youtube.  It is a fantastic summary of Scrum and is well worth the 20 minutes to watch.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Announcements, How-To Apply Agile, Professional Development, Scrum, XP and Lean, Theory of Agile

Announcing: The Real Agility Program

Leave a comment

Real Agility Program LogoThe Real Agility Program is an Enterprise Agile change program to help organizations develop high-performance teams, deliver amazing products, dramatically improve time to market and quality, and create work environments that are awesome for employees.

This article is a written summary of the Executive Briefing presentation available upon request from the Real Agility Program web site.  If you obtain the executive briefing, you can follow along with the article below and use it to present Real Agility to your enterprise stakeholders.

The Problem

At Berteig Consulting we have been working for 10 years to learn how to help organizations transform people, process and culture.  The problem is simple to state: there is a huge amount of opportunity waste and process waste in most normal enterprise-scale organizations.  If you have more than a couple hundred people in your organization, this almost certainly affects you.

We like to call this problem “the Bureaucratic Beast”.  The Bureaucratic Beast is a self-serving monster that seems to grow and grow and grow.  As it grows, this Beast makes it progressively more difficult for business leaders to innovate, respond to changes in the market, satisfy existing customers, and retain great employees.

Real Agility, a system to tame the Bureaucratic Beast, comes from our experience working with numerous enterprise Agile adoptions.  This experience, in turn, rests on the shoulders of giants like John Kotter (“Leading Change”), Edgar Schein (“The Corporate Culture Survival Guide”), Jim Collins (“Good to Great” and “Built to Last”), Mary Poppendieck (“Lean Software Development”) Jon Katzenbach (“The Wisdom of Teams”) and Frederick Brooks (“The Mythical Man-Month”).  Real Agility is designed to tame all the behaviours of the Bureaucratic Beast: inefficiency, dis-engaged staff, poor quality and slow time-to-market.

Studies have proven that Agile methods work in IT.  In 2012, the Standish Group observed that 42% of Agile projects succeed vs. just 14% of projects done with traditional “Bureaucratic Beast” methods.  Agile and associated techniques aren’t just for IT.  There is growing use of these same techniques in non-technoogy environments such as marketing, operations, sales, education, healthcare, and even heavy industry like mining.

Real Agility Basics: Agile + Lean

Real Agility is a combination of Agile and Lean; both systems used harmoniously throughout an enterprise.  Real Agility affects delivery processes by taking long-term goals and dividing them into short cycles of work that deliver valuable results rapidly while providing fast feedback on scope, quality and most importantly value.  Real Agility affects management processes by finding and eliminating wasteful activities with a system view.  And Real Agility affects human resources (people!) by creating “Delivery Teams” which have clear goals, are composed of multi-skilled people who self-organize, and are stable in membership over long periods of time.

There are lots of radical differences between Real Agility and traditional management (that led to the Bureaucratic Beast in the first place).  Real Agility prioritizes work by value instead of critical path, encourages self-organizing instead of command-and-control management, a team focus instead of project focus, evolving requirements instead of frozen requirements, skills-based interactions instead of roles-based interaction, continuous learning instead of crisis management, and many others.

Real Agility is built on a rich Agile and Lean ecosystem of values, principles and tools.  Examples include the Agile Manifesto, the “Stop the Line” practice, various retrospective techniques, methods and frameworks such as Scrum and OpenAgile, and various thinking tools compatible with the Agile – Lean ecosystem such as those developed by Edward de Bono (“Lateral Thinking”) and Genrich Altshuller (“TRIZ”).

Real Agility acknowledges that there are various approaches to Agile adoption at the enterprise level: Ad Hoc (not usually successful – Nortel tried this), Grassroots (e.g. Yahoo!), Pragmatic (SAFe and DAD fall into this category), Transformative (the best balance of speed of change and risk reduction – this is where the Real Agility Program falls), and Big-Bang (only used in situations of true desperation).

Why Choose Transformative?

One way to think about these five approaches to Agile adoption is to compare the magnitude of actual business results.  This is certainly the all-important bottom line.  But most businesses also consider risk (or certainty of results).  Ad-Hoc approaches to Agile adoption have poor business results and a very high level of risk.  Big-Bang approaches (changing a whole enterprise to Agile literally over night) often have truly stunning business results, but are also extremely high risk.  Grassroots, where leaders give staff a great deal of choice about how and when to adopt Agile, is a bit better in that the risk is lower, but the business results often take quite a while to manifest themselves.  Pragmatic approaches tend to be very low risk because they often accommodate the Bureaucratic Beast, but that also limits their business results to merely “good” and not great.  Transformative approaches which systematically address organizational culture are just a bit riskier than Pragmatic approaches, but the business results are generally outstanding.

More specifically, Pragmatic approaches such as SAFe (Scaled Agile Framework) are popular because they are designed to fit in with existing middle management structures (where the Bureaucratic Beast is most often found).  As a result, there is slow incremental change that typically has to be driven top-down from leadership.  Initial results are good, but modest.  And the long term?  These techniques haven’t been around long enough to know, but in theory it will take a long time to get to full organizational Agility.  Bottom line is that Pragmatic approaches are low risk but the results are modest.

Transformative approaches such as the Real Agility Program (there are others too) are less popular because there is significantly more disruption: the Bureaucratic Beast has to be completely tamed to serve a new master: business leadership!  Transformative approaches require top-to-bottom organizational and structural change.  They include a change in power relationships to allow for grassroots-driven change that is empowered by servant leaders.  Transformative approaches are moderate in some ways: they are systematic and they don’t require all change to be done overnight. Nevertheless, often great business results are obtained relatively quickly.  There is a moderate risk that the change won’t deliver the great results, but that moderate risk is usually worth taking.

Regardless of adoption strategy (Transformative or otherwise) there are a few critical success factors.  Truthfulness is the foundation because without it, it is impossible to see the whole picture including organizational culture.  And love is the strongest driver of change because cultural and behavioural change requires emotional commitment on the part of everyone.

Culture change is often challenging.  There are unexpected problems.  Two steps forward are often followed by one step back.  Some roadblocks to culture change will be surprisingly persistent.  Leaders need patience and persistence… and a systematic change program.

The Real Agility Program

The Real Agility Program has four tracks or lines of action (links take you to the Real Agility Program web site):

  1. Recommendations: consultants assess an organization and create a playbook that customizes the other tracks of the Real Agility Program as well as dealing with any important outliers.
  2. Execution: coaches help to launch project, product and operational Delivery Teams and Delivery Groups that learn the techniques of grassroots-driven continuous improvement.
  3. Accompaniment: trainer/coaches help you develop key staff into in-house Real Agility Coaches that learn to manage Delivery Groups for sustainable long-term efforts such as a product or line of business.
  4. Leadership: coaches help your executive team to drive strategic change for long-term results with an approach that helps executives lead by example for enterprise culture change.

Structurally an enterprise using Real Agility is organized into Delivery Groups.  A Delivery Group is composed of one or more Delivery Teams (up to 150 people) who work together to produce business results.  Key roles include a Business leader, a People leader and a Technology leader all of whom become Real Agility Coaches and take the place of traditional functional management.  As well, coordination across multiple Delivery Teams within a Delivery Group is done using an organized list of “Value Drivers” maintained by the Business leader and a supporting Business Leadership Group. Cross-team support is handled by a People and Technology Support Group co-led by the People and Technology leaders.  Depending on need there may also be a number of communities of practice for Delivery Team members to help spread learning.

At an organizational or enterprise level, the Leadership Team includes top executives from business, finance, technology, HR, operations and any other critical parts of the organization.  This Leadership Team communicates the importance of the changes that the Delivery Groups are going through.  They lead by example using techniques from Real Agility to execute organizational changes.  And, of course, they manage the accountability of the various Delivery Groups throughout the enterprise.

The results of using the Real Agility Program are usually exceptional.  Typical results include:

  • 20x improvement in quality
  • 10x improvement in speed to market
  • 5x improvement in process efficiency
  • and 60% improvement in employee retention.

Of course, these results depend on baseline measures and that key risk factors are properly managed by the Leadership Team.

Your Organization

Not every organization needs (or is ready for) the Real Agility Program.  Your organization is likely a good candidate if three or more of the following problems are true for your organization:

  • high operating costs
  • late project deliveries
  • poor quality in products or services
  • low stakeholder satisfaction
  • managers overworked
  • organizational mis-alignment
  • slow time-to-market
  • low staff morale
  • excessive overtime
    or…
  • you need to tame the Bureaucratic Beast

Consider that list carefully and if you feel like you have enough of the above problems, please contact us at tame.the.beast@berteigconsulting.com. or read more about the Real Agility Program for Enterprise Agility on the website.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Reference Information

Book List for Enterprise Agile Transformations

2 Comments

Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them.  This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent.  Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.

I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization.  It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile.  It is about urgency and need, and about a recognition that Agile is better than not-Agile.  If you aren’t in that situation, this is not the book list for you.

Culture

These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture.  Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.

The Corporate Culture Survival Guide – Edgar Schein

Beyond the Culture of Contest – Michael Karlburg

The Heart of Change – John Kotter

Management

This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments.  These books all touch on culture in various ways, and build on the ideas in the books about culture.  For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.

Good to Great – Jim Collins

The Leaders’ Guide to Radical Management – Steve Denning

The Mythical Man-Month – Frederick Brooks

Agile at Scale

These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.

Scaling Lean and Agile Development – Bas Vodde, Craig Larman

Scaling Agility – Dean Leffingwell

Lean Software Development – Mary and Tom Poppendieck

Supporting

These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.

Toyota Talent: Developing Your People the Toyota Way – Jeffrey Liker, David Meier

Agile Retrospectives – Esther Derby

Continuous Delivery – Jez Humble, David Farley

The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.

The OpenAgile Primer – Mishkin Berteig, et. al.

Priming Kanban – Jesper Boeg

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Scrum, XP and Lean, Theory of Agile

Pragmatism, Fundamentalism and Transformation – the Three Modes of Scrum

Leave a comment

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.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Announcements, How-To Apply Agile, Scrum, XP and Lean

Announcement: The Scrum Team Assessment

Leave a comment

Over the past six months we have been working hard on launching a new product: The Scrum Team Assessment.  This tool delivers to you a valuable report full of practical advice on how your team can get better at Scrum… and deliver better results!  It’s like an automated Scrum coach.  All your team members will fill in a comprehensive survey, we collect the results, generate a report – and then we personally review it – and send it back to you.

For more information, please visit our Scrum Team Assessment site.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Reference Information, Scrum, XP and Lean

The Rules of Scrum: I actively seek to help my team mates

1 Comment

A Scrum Team Member is aware of the work that other Team Members are doing, notices if others are struggling with their tasks, and if so, offers to help them.  A Scrum Team Member is not just focused on their own personal tasks.  This help can be offered as ideas, powerful questions, sharing the work of the task, or even offering simple encouragement.  If Team Members are constantly seeking to help each other, this actively contributes to team cohesion, cross-training, and the development of a high-performance team environment.  Of course, if people don’t help each other, then individual Team Members may struggle for a long time without making progress and overall productivity will be dramatically hindered.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
How-To Apply Agile, Links to Agile Info

Seven Essential Teamwork Skills

7 Comments

I’ve been researching teamwork lately.  I just finished reading “The Discipline of Teams” by Katzenbach and Smith which is an HBR summary of their much more substantial book “The Wisdom of Teams”.  I decided that it would be good to be able to describe the essential skills an individual needs to acquire in order to work effectively in a team.  First stop, Google and a search of “list of teamwork skills”.

Strangely, not much turned up on the first page.  The best result is found at “7 Essential Skills for Teamwork” which is a page on a public elementary school web site.  So, here’s my adaptation of their list:

Active Listening

Active listening is a skill that allows a person to completely focus on the communication of another person including both verbal and non-verbal aspects.  Active listening requires the ability to delay thinking of your own responses until after a person has finished speaking.  One simple way of doing this is to echo what a person is saying in your silent internal voice.  When someone says “I think we should build a new gimbal on the widget”, you are saying exactly the same thing in your own mind.  Active listening also requires that you request clarification, often by rephrasing what a person has said and asking if you have understood correctly.  See Active Listening on Wikipedia for more information.

Questioning

Being able to frame and express questions effectively helps us understand and integrate knowledge into our own mental model of the world, or even to modify our mental model.  Asking questions is easy.  Asking good questions is much harder.  We need to use an appropriate set of words and tone of voice so that we do not alienate or offend the recipient of the question.  For example, asking “why did you do that?” will often put people on the defensive since they will assume that you mean you disagree with their actions.  Instead, saying “I do not understand the reason you did that.  Could you please explain it to me?” can be a much more gentle way of getting to the same information.  Here is a great article about Questioning Skills on MindTools.com.

Logical Argument

When presenting an idea or position, being able to logically support it is important to exploring the truth of it.  This includes being able to share your assumptions or axioms, the data you are basing your argument upon, and the logical sequence of reasoning to reach your conclusion.  Being able to avoid fallacious logical methods is also important.  Some great videos about good and bad logical argument forms on Critical Thinker Academy.

Respecting

Showing respect includes acknowledging the fundamental human value of the existence of your teammates, and being able to step back from your own understanding of the world to acknowledge the legitimate nature of the perspective that other people have.  This does not mean that you have to let teammates get away with inappropriate behavior.  In fact, respect for your teammates will allow you to support them in behaving in ways that are in alignment with their fundamental nobility as human beings.  Although somewhat simplistic, I really like this little set of rules about being respectful on wikiHow.

Helping

Offering help and actually following through with real assistance are aspects of helping.  When you suspect that a team member is struggling with something, you offer to help both verbally and with your actions.  This can take the form of offering information, offering emotional support, offering to assist with problem-solving, or actually taking action to do an activity together.  When we help someone, we share their burden.  Although phrased in a rather self-serving way, this article on forbes.com has a great list of ideas for how you can help others.

Sharing

Sharing our knowledge, time, skills or physical resources are all aspects of sharing.  Sharing among team members is focused on those things which will help a team reach its goals.  This is similar to helping except that it tends to be more of a transaction than an ongoing activity.  The transaction is that you give a gift and then the other person uses that gift to meet their needs.  Sharing does not require reciprocity.  If you share something with another person, you should not expect that that person will return the gift at any time in the future.  Strangely, there is very little written about this out there on the internet; a Google search found nothing in over ten pages of search results on multiple search terms with the word “sharing” in them.  If you know of some good reference to go into this in more detail, please, please let me know in the comments!

Participating

It’s probably obvious, but in order to effectively be on a team, you need to participate!  Participation itself is mostly obvious: do work with the other team members.  However, there are also some less obvious aspects of it.  You are not participating when the team is having a discussion, you find it boring, so you check your email.  You are not participating when the team makes a decision and you abstain from helping to execute the decision because you disagree.  You are not participating in a work team when you are mentally checked out because of a crisis at home.  There is some interesting stuff here on wikipedia about Participation.

All of these skills are critical teamwork skills… but there may be others.  Do you think there are other skills missing from this list that are critical for effective teamwork?

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management

What are Ways to Measure Productivity?

2 Comments

One of the most difficult aspects of doing Agile, is to find reasonable, do-able, agreeable ways to measure productivity.  Many organizations don’t measure productivity or only use very indirect indicators.

What do you do to measure productivity and how is it working for you?  If you don’t measure productivity, why not?

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, How-To Apply Agile, Links to Agile Info

Agile Productivity Measures

2 Comments

Scott Ambler has written a couple good articles about measuring productivity with velocity.  Acceleration: An Agile Productivity Measure. and Examining Acceleration.

From what I understand, this is a measure of the effect of agile on the relative improvement over time of a team.  I would beg to differ that it is a measure of productivity.  Productivity is value delivered over time.  If team A is delivering $5/week and team B is delivering $5000/week, then knowing that team A is accelerating faster than team B isn’t terribly important, particularly if the market can’t bear to absorb $6/week of whatever team A is producing.

Measuring productivity is hard.  I would love to hear from people who have tried various means to measure productivity.  I measure productivity in our business, but I can do that because we are small and everything we do has a direct effect on the bottom line.  Does your business run with that transparency?  If not, why not?

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Engineering

ANN: Agile Software Engineering Practices training by Isráfíl Consulting

Leave a comment

Isráfíl Consulting is finally prepared for the first series of its Agile Software Engineering Practices training courses. This series is offered in partnership with Berteig Consulting who are graciously hosting the registration process. Their team has also helped greatly in shaping the presentation style and structure of the course. The initial run will be in Ottawa, Toronto (Markham), and Kitchener/Waterloo.   

Topics covered will include Test Driven Development (TDD), testability, supportive infrastructure such as build and continuous integration, team metrics, incremental design and evolutionary architecture, dependency injection, and so much more. (This course won’t present the planning side of XP, but covers many other aspects common to XP projects) It makes a great complement for training in Agile Processes such as XP, Scrum, or OpenAgile. The overview slide presentation is available for free download from the Isráfíl web site.

The courses are scheduled for:

The course is $1250 CAD per student, and participants receive a transferrable discount of $100 CAD for other training with Berteig Consulting as a part of our ongoing partnership. I initially prototyped this course in Ottawa this December, and am very excited to see this through in several locales. Class size is limited to 15, so we can keep the instruction style more involved. The above schedules are linked to Berteig Consulting’s course system and have registration links at the bottom of the description. Locations are TBD, but will be updated at the above links as soon as they’re finalized.

A further series is planned for several US cities in March, and we’ll be sure to announce them as well.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Links to Agile Info

The Cheaper Talent Hypothesis

Leave a comment

Wonderful article by Martin Fowler that discusses the relationship between individual productivity, cost, team size, time to market and value delivered.  Some very interesting conclusions.  This is critical reading if you are a manager!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 31
2023
Details
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C$7950.00
Apr 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 4
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1795.00
Apr 5
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
Apr 11
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 14
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 17
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Apr 18
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Apr 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 25
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1895.00
Apr 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 28
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 28
2023
Details
Advanced Certified Scrum Product Owner® (ACSPO)
Online
C$1525.75
May 3
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
May 10
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 12
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1100.75
May 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
May 16
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
May 17
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
May 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 19
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 26
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jun 7
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 9
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1610.75
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jun 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jun 20
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jun 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jun 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 30
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 30
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jul 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
Jul 11
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details