All posts by Mishkin Berteig

Mishkin Berteig is a Baha'i, a father of four, a husband and an experienced Agile consultant and trainer. Mishkin is a Certified Scrum Trainer (CST) with the Scrum Alliance, a certified Master of OpenAgile with the OpenAgile Centre for Learning and a certified SAFe Program Consultant (SPC) with the Scaled Agile Academy. Mishkin has a technical background including a B.Sc. in Computer Science and worked as a Chief Architect reporting to the CIO of Charles Schwab, but gave it up to be more Agile.

IT Project Agility

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

Over the years I have done a number of talks for local chapters of the Project Management Institute.  They have covered a range of topics, but one common theme that comes up over and over is that Scrum is not the best Agile method for delivering an IT Project.  I even published a short video on the topic:

Several years ago, I also published a short article describing what Scrum is good for:

What is Scrum good for?

So… if Scrum isn’t so good for IT project work, then what can bring real agility to IT projects?

IT Project Attributes

Most of my work experience prior to running my business was in IT projects in banking, capital markets, insurance and a bit in government and healthcare.  I mention that merely to indicate that my discussion of this isn’t just theoretical: I’ve seen good projects and bad projects.  I’ve been on death-march projects, small projects and massive projects ($1b+).  I’ve dealt with regulatory issues, vendor issues, offshoring issues, telecommuting issues, architectural issues, political issues, and seen enough problems to understand the complexity of reality.

IT projects have some common characteristics:

  1. Like any project, there’s a deadline and a scope of work and a budget.  These things don’t work well with Scrum.  It’s possible to force them to fit together, but you lose a lot of what makes Scrum effective.
  2. IT (as opposed to, say, tech startups) tends to use more mature technology platforms.  Scrum is neutral about technology, but there are other Agile methods that address this type of technology more effectively.
  3. IT Projects are often not the only thing going on in the technology organization.  In particular, operations and user support add to IT project complexity, and require different “classes of service” than Scrum provides.
  4. The issues that I mentioned above such as regulation, vendors, offshoring etc. are also common attributes of IT projects.  Scrum makes harsh demands on an organization that challenge the approach to dealing with these issues.  The change required to accommodate Scrum may not be worth it.

The Bad News about IT Project Agility

The whole project orientation to IT work is questionable.  It’s just not a good fit.  In most mid- to large-size organizations, IT does two things: it provides technology services to the rest of the organization, and it provides technical product development capacity to lines of business.  For example, upgrading the office wi-fi routers and adding a new payment type to the online customer portal, respectively.  The work of the IT department, therefore, falls into several different categories:

  1. New artifacts that need to be created.  Usually this is the stuff like coding algorithms and other business logic, creating new databases, configuring purchased systems, etc.
  2. Repetitive activities that need to be sustained for a period or indefinitely, or which occur on-demand but at irregular times.  For example, running a nightly batch process or deploying an update to a production environment.
  3. Quality problems that need to be fixed.  Defects and production problems are the obvious categories here, but also quality problems that are causing user confusion or time wastage.
  4. Obstacles to work that need to be overcome.  Often obstacles come from outside the project team in the form of interruptions. Other forms of obstacles can be unexpected bureaucracy, shifting funding, problems with a vendor, etc.
  5. Calendar events that need to be accommodated.  Milestones in the project, particularly regulatory milestones are crucial in IT project work, there are many other types such as all-hands meetings, statutory holidays, hiring or contract end dates, etc.

Of these, only repetitive activities and calendar events fit well into a project perspective.  The others typically have a level of uncertainty… complexity… that makes it very difficult to approach with the project perspective of fixed deadlines and scope.

On the other hand, Scrum only really handles new artifacts and obstacles directly, and quality problems indirectly.  These are the kinds of activities that are the focus of product development.  Repetitive activities and calendar events are anathema to the core Scrum framework.  If I think about this from a scoring perspective, Scrum supports these kinds of work as follows (-5 means totally counter, 0 means no impact, +5 means total support):

Scrum Support for IT Project Work Types:

  1. New artifacts: +5
  2. Repetitive activities: -2
  3. Quality problems: 0
  4. Obstacles: +4
  5. Calendar events: -5

SCORE: +2 – barely positive impact on IT project work!!!

The bad news, therefore: neither a project orientation nor Scrum really cover all the needs of an IT project environment.

(For more information about Scrum, check out our “Rules of Scrum” page, our “Scrum Diagram” article, and our highly-regarded Certified ScrumMaster learning events.)

Alternatives to Scrum

There are many, but these are my three favourite alternatives: Extreme Programming, Kanban and OpenAgile.  All three of them cover the five types of work more effectively than Scrum.  All three of them are oriented to more generic types of work.  After describing each briefly, I’ll also mention which one is my top choice for IT project work.

Extreme Programming for IT Project Work

Historically, Extreme Programming (XP) emerged in an IT Project context: the famous C3 project at Chrysler.  This approach to IT project work has many things in common with other approaches to agility (which are described in the Agile Manifesto).  XP allows the five types of work as follows:

New artifacts are the core of XP and are usually expressed as User Stories.  This is common to Scrum and many other Agile methods.  These are typically the features and functionality of a system… the scope of the project work.  XP does not make any strong assertions about the size or stability of the backlog of new artifacts and as such can accommodate the project orientation in IT with relatively fixed scope.

Repetitive activities are not explicitly addressed in XP, but nor is there anything in XP which would cause problems if an XP team is required to do operational or support work which is the source of most repetitive activities in an IT environment.

Quality problems are addressed directly with both preventative and reactive measures.  Specifically, Test-Driven Development, Acceptance Test-Driven Development are preventative, and Refactoring and Continuous Integration are reactive.  XP has a deep focus on quality.

Obstacles are not directly addressed in XP, but indirectly through the XP value of courage.  Implicitly, then, obstacles would be overcome (or attempted) with courage.

Calendar events are not addressed directly for the most part with the exception of release planning for a release date.  However, the stuff related to other calendar activities is not directly handled.  XP is less antagonistic to such things than Scrum, but only by implication: Scrum would often put calendar events in the category of obstacles to be removed to help a team focus.

XP Support for IT Project Work Types:

  1. New artifacts: +5
  2. Repetitive activities: 0
  3. Quality problems: +5
  4. Obstacles: +2
  5. Calendar events: +1

SCORE: +13 – moderate to strong positive impact on IT project work!

Summary: much better than Scrum, but still with some weaknesses.

Kanban for IT Project Work

Kanban is different from most other approaches to agility in that it is a “continuous flow” method, rather than an iterative/incremental method.  This distinction basically means that we move packages of work through a process based on capacity instead of based on a fixed cadence.  Kanban asks that we visualize the current state of all work packages, limit the amount of work in progress at any stage in our delivery process, and use cadences only for iterative and incremental improvement of our process (not our work products).

Kanban is much gentler than Scrum or Extreme Programming in that it does not require leader-led reorganization of staff into cross-functional team units.  Instead, we identify a service delivery value stream and leaders manage that stream as it currently operates.

You can read a somewhat slanted history of Kanban here, and a good comparison of Kanban and other Agile methods here.

New artifacts in Kanban are supported, and certainly welcome, but Kanban does not seem to acknowledge the problem of formal complexity (creativity, problem-solving, human dynamics) in the creation of new artifacts.  There are good attempts to apply statistical methods to the management of new artifacts, but their fundamentally unknowable cost/end (undecidable problem) is not really effectively addressed.

Repetitive activities are handled extremely well in Kanban including different classes of service.  Repetitive activities are handled well partly as a result of the history of Kanban as a signalling system in manufacturing environments.

Quality problems are handled similarly to new artifacts: supported, welcome, and even possibly addressed in the cadences of continuous improvement that Kanban supports.  However, quality problems are another area where technical complexity makes proper analysis of these activities difficult.

Kanban relegates the handling of obstacles to the manager of service delivery.  There is no explicit support for strong organizational change efforts.  In fact, Kanban discourages “transformative” change which is sometimes required given the problem of Nash equilibriums.

Kanban works well with Calendar events by treating them as activities with a particular class of service required.

Kanban Support for IT Project Work Types:

  1. New artifacts: +3
  2. Repetitive activities: +5
  3. Quality problems: +3
  4. Obstacles: 0
  5. Calendar events: +5

SCORE: +16 – strong positive impact on IT project work!!

Summary: even better than XP, easier to adopt. (Actually, almost anything is easier to adopt than XP!!!)

OpenAgile for IT Project Work

OpenAgile is an obscure non-technology-oriented method based on the work I and a few others did about 10 years ago.  The OpenAgile Primer is the current reference on the core of the OpenAgile framework.  OpenAgile has been applied to general management, small business startups, sales management, mining project management, emergency services IT, and many other areas of work.  I’m partial to it because I helped to create it!

OpenAgile emerged from consulting work I did at CapitalOne in 2004 and 2005 and work I did with my own business in 2006 and 2007.  A great deal of the older articles on this blog are forerunners of OpenAgile as it was being developed.  See, for example, Seven Core Practices of Agile Work.

The types of work listed above, are indeed the core types of work described in OpenAgile.  As such, OpenAgile fully supports (nearly) all five types of activities found in IT projects.  However, OpenAgile is not just a work delivery method.  It is also a continuous improvement system (like Kanban and Scrum) and so it also assumes that a team or organization using OpenAgile must also support learning.  This support for learning means that OpenAgile does not over-specify or give precise definitions on how to handle all five types of work. Thus, my scores below are not all +5’s…

OpenAgile Support for IT Project Work Types:

  1. New artifacts: +4
  2. Repetitive activities: +4
  3. Quality problems: +4
  4. Obstacles: +4
  5. Calendar events: +4

SCORE: +20 – very strong positive impact on IT project work!!!

Summary: OpenAgile is the best approach I know of for general IT project environments.

Conclusion

Regrettably, I wouldn’t always recommend OpenAgile – there are just too few people who really understand it or know how to help an organization adopt it effectively.  If you are interested, I’d be happy to help, and we can certainly arrange private training and consulting, but mostly I would recommend Kanban to people interested in taking the next step in effectiveness in IT projects.  Please check out or Kanban learning events and consider registering for one or asking for us to come to your organization to deliver training, coaching or consulting privately.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Video Series

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

I have recently published all 16 videos for the Leading to Real Agility series on YouTube.  The videos cover leadership topics including:

  • Organizational Change
  • Dealing with Laggards
  • Leadership Responsibilities
  • and many others…

The videos are short (typically 2 or 3 minutes each) and focus on introducing the basics of each topic.  Further depth can be gained through our Leading to Real Agility one-on-one coaching service.

BESTEIG Real Agility logo - Agile Coach development program


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Review of: Product Mastery – From Good to Great Product Ownership

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

Note: This review is based on an incomplete pdf copy of Product Mastery that was shared with the reviewer, which therefore limits discussion of the book.

Geoff Watts, author of Scrum Mastery, has now released Product Mastery: From Good to Great Product Ownership, published by Inspect & Adapt Ltd. The book contains two Forewards by Jeff Sutherland and Roman Pichler, both masters in the field of Scrum management.

The prose Watts uses is straightforward and provides an easy and intelligent read even for the layman, with graphs and illustrations that illuminate his ideas.

The book is built around the idea of DRIVEN, an acronym Watts uses to discuss the traits and characteristics of a great product owner. The book uses each letter as headings, i.e. D = Decisive, R = Ruthless, I = Informed, V = Versatile, E = Empowering, and N = Negotiable. Each heading offers pragmatic advice into the many responsibilities of being a product owner. I will give a few snippets of some insights that Watts shares.

In the first section, entitled “Decisive,” Watts creates stories and discussion that show how product owners need to have courage and trust themselves and others to make decisions, often with incomplete information. He gives strategies to make the decision-making process easier, such as reducing the number of options a product master is considering, and prioritizing. He cites Edison as once famously saying, “I have not failed. I’ve just found 10,000 ways that won’t work.”

Under “Ruthless” Watts shares a mantra used by product owners: “If the product is going to fail, then I would rather it fail in month 2 than month 22.” In other words, it is better to develop the wrong thing quickly and get feedback, than wait too long in an effort to make sure no mistakes are ever made.

The third section is called “Informed.” Watts includes a quote by Roman Pichler, author of Agile Product Management with Scrum, who told him: “Customer feedback is the basis for ideas. Customer data is the basis for decisions.” Watts then cites the experience of a company that creates mobile games. Rather than ask for ratings or feedback, the company monitors actual usage of their games.

In “Versatile” Watts advises product owners to “remain flexibly firm.”

Under the last heading, “Negotiable,” he outlines games to play when negotiating attributes of a product. In this section Watts makes it clear that product owners need to be careful to not fall into the trap of being a perfectionist. He writes: “The temptation to just add a little extra here or there is very strong; but those little bits here or there quickly add up and can easily lead to significant delays, not to mention an unnecessarily cumbersome product to support.”

Product Mastery is a book that is sure to attract a wide readership as it provides a balance

between vision, direction and execution. Wisely, Watts is not dogmatic in his style. He gives numerous approaches to the items under a product owner’s watch. He writes: “Great product owners know how to find the right middle ground, one with an appropriate balance of data and intuition – and a good measure of courage.”

I personally will be adding Product Mastery to BERTEIG’s book offerings for our Certified Scrum Product Owner attendees.

Product Mastery: From Good to Great Product Ownership (282 pp)

Table of Contents:

Foreward – Jeff Sutherland

Foreword by Roman Pichler

DECISIVE 26

RUTHLESS 64

INFORMED 102

VERSATILE 144

EMPOWERING 180

NEGOTIABLE 222

Be DRIVEN to Be Great 264

Available at https://www.amazon.ca/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=product+mastery

Product Mastery: From Good to Great Product Ownership Mar 1 2017

by Geoff Watts and Jeff Sutherland

Kindle EditionCDN$ 41.94

PaperbackCDN$ 42.18

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management

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

The battle of the organizational change management approaches!

Check out the presentation I did last night at Agile Mississauga Meetup.

20170208 Agile Mississauga Meetup – Change Approach Characterization Model

I describe a model for understanding change management approaches and deciding which ones to use for your situation.  I also look briefly at Positive Deviance and Appreciative Inquiry.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Team Experience – A Team of Coaches and Trainers

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

Two weeks ago I joined a temporary team of Scrum Alliance Certified Scrum Trainers and Certified Enterprise Coaches.  It was a fabulous experience and I hope that I will be able to do it again sometime soon.  We worked together to build real valuable results for the rest of the Scrum ecosystem including reference training modules and in-depth website content, feedback for Scrum Alliance programs, and even some fun videos.

Brock Argue was one of the CECs there, and he has written a great summary of how it felt: The Art of Teaming Part 1.  One cool point he makes:

Introductions were friendly and helpful and as we started getting into the work things heated up…. I got frustrated with the direction of the conversation and I grew impatient with the lack of progress we were making. I’m sure other team members were experiencing similar feelings, and as coaches we understand how difficult team formation can be. Imagine how unsettling this is for a team who isn’t aware of these group growth stages; that they’re unavoidable and healthy to experience.

The stages Brock is referring to are the stages of team development as described by Tuckman: Forming, Storming, Norming, and Performing (and sometimes Adjourning is added on).

Thanks to Robin Dymond, Mark Levison who organized the event and Shannon Carter from the Scrum Alliance who supported the event with her personal presence.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: We are Hiring a Training Sales Person

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

We are looking for a highly-motivated person to help us take our training business to the next level! This position is focused on sales, but includes other business development activities. The successful candidate for our training sales position will help us in several areas of growth including:

  • direct sales of our existing training offerings
  • expand our training loyalty program
  • launch and expand new training offerings
  • expand the market to new locations outside the GTA: Vancouver, Montreal, Ottawa, etc.
  • expand our partner/reseller network

Please check out the full job posting for a Training Sales Person here.  You can send that link to others who might be interested!

BERTEIG World Mindware Logo - Training Sales Person


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Change Can be Fun or Exciting by Mike Caspar

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

This is a good reminder: change can be fun or exciting.

Change isn’t always bad.  To add my own opinion to Mike’s excellent post, change is how we grow.  If we don’t change, that is death.  It is stasis that we should fear!!!

From Mike’s article:

If you are a person who helps others to embrace or live through change (whatever your interpretation of change is)….

… consider the damage you are causing by inspiring fear where it simply may not be appropriate or necessary.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

9 Common Mistakes in Hiring an Agile Coach

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

Nearly everyone is hanging out the “Agile Coach” shingle.  Agile has reached the point where many large organizations are adopting Agile practices.  As a result, consultants and consulting companies are trying to jump on the bandwagon to take advantage of this fad.  Unfortunately, we at BERTEIG are often being called in to clean up after other Agile coaches have made a mess of things.

Here are the most common mistakes that organizations make when hiring Agile coaches.

1. Not Measuring the Results of Your Agile Coach

Agile coaches should be able to measure their results as they work with your teams and your organization. Important measures include performance, cost, quality, time to market, customer satisfaction and others.  If you aren’t measuring results, you can’t possibly know if the money you are investing into your Agile coach is worth it.  Of course, some qualitative measures such as staff satisfaction with the coach are useful too, but quantitative measures are also essential.

2. Not Benchmarking before an Agile Coach Starts

You need to be able to know if an agile coach is making a difference. Knowing where you are starting is necessary.  Having benchmark measurements of important KPI’s will help you to make sure that your agile coach is successful.  Benchmarking is something that your agile coach should be able to help you with, but make sure that you are involved directly!

3. The Agile Coach is Lacking Advanced Certifications

Agile coaches need to have proven their knowledge and experience by obtaining advanced certifications. A “Certified Scrum Master” designation is just not sufficient. At a bare minimum a Certified Scrum Professional (CSP) or Kanban Management Professional (KMP) certification are critical. However more advanced certification’s such as Certified Enterprise Coach (CEC), Kanban Coaching Professional (KCP), or even non-Agile coaching certifications such as Leadership Circle Profile are important to see in a candidate.

4. Lack of Diversity of Agile Experience

An Agile coach must be able to prove having worked with at least Scrum and Kanban methods on more than one team in more than one organization.  However, there are many other Agile methods and techniques, and it is critical to explore the depth of your candidate’s knowledge and experience with those techniques.  Do they know how to do the Agile engineering practices?  Have they used many different retrospective techniques?  What about Innovation Games?  Estimation and planning tools?  If your coach has less than five years of experience with Agile techniques, chances are they don’t have the depth to deal with the complexity of your situation.

5. No Huge Agile Coaching Failures

An Agile coach needs to be able to explain how they have failed to achieve results in at least one case, ideally getting fired as a result. Failure and learning from failure are critical parts of the Agile framework. If an Agile coach can not share with you a significant failure then you cannot trust that they are able to learn from their mistakes.

6. No Systematic Agile Coaching Approach

Helping teams, groups and organizations become more Agile requires systems thinking and systematic approaches.  Organizations are complex (and sometimes chaotic!) – if an Agile Coach does not know how to deal with this complexity, and cannot describe to you their systematic approach, then they probably aren’t going to be consistent in their results.  And if the approach they describe doesn’t seem to make sense to you, you are probably right to give that coach a pass.

7. Missing Clear Agile Coaching Goals

This mistake is a little less common, but it is important enough that it still needs to be mentioned: your organization absolutely must have clear goals for the Agile coaching.  Those goals should be related to both Agility and business results.  Agile techniques are a means to an end.  Lacking clear goals often results in an organization spending far more than it needs to on Agile coaching.

8. Hiring an Agile Coach to do Training

(Or the other way around.)  Coaching and training are two completely separate disciplines!  It is rare to find an individual who is able to do both well.  The systems and techniques of coaching are different than those of training.  Becoming excellent at one, takes many years of focused work.  Becoming excellent at both, takes deep commitment and opportunity.  If you hire an Agile Coach who has good experience, don’t just assume that they can do training just because they have delivered a few talks or made up a slide deck.  Put the same discipline into hiring an Agile trainer that you would put into hiring an Agile coach.

9. Not Letting Leaders and the Agile Coach Work Together

This is probably one of the biggest mistakes of all!  An Agile coach must work with your organization’s leaders to have any hope of helping you with lasting change.  No matter how large your organization, the culture is set by leadership, Agile has a huge cultural impact, and your Agile coach needs to be able to link the two together (leaders and Agile culture).  Even if the Agile coach is “just” working at the team level, a lack of contact with leaders will make the coaching work inefficient, frustrating, and unsustainable.


Your organization deserves the best chance it can have.  Consider contacting us at BERTEIG to help you make sure your Agile coach (or Agile coach candidate) is up to the challenge.   We have a systematic program to develop Agile coaches.

BESTEIG Real Agility logo - Agile Coach development program


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Communicate the Vision for Change

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

Leading an organization to Real Agility requires that you communicate the vision for change throughout your organization.  This video introduces the four key concepts of communicating this vision for change as you and your executive team lead your organization to Real Agility.

The video presents four core concepts:

  1. Continuous communication at every opportunity: every meeting, every phone call, every email, every presentation!
  2. Simplicity of the message: short, jargon-free, concrete.
  3. An emotional component that encourages a change in behaviour.
  4. And urgency!  (A window of opportunity, a competitive threat or an internal problem that needs to be addressed now.)

Leading to Real Agility References

Here are some additional references about how leaders can help their organizations move towards Real Agility by communicating the vision for change:

Please subscribe to our YouTube channel to receive notifications when each new video is published! (There are 15 more videos coming in this series, and more beyond that on other topics!)  You can also find the summary article that helps you find all the videos and additional references here: Leading to Real Agility – Introduction.

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BERTEIG Real Agility logo - leading to Real Agility


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Leader Responsibilities

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

Leading an organization to Real Agility is a complex and difficult task.  However, the core responsibilities of leaders attempting this are simple to describe.  This video introduces the three core responsibilities of the senior leadership team as they lead their organization to Real Agility.

The video presents three core responsibilities:

  1. Communicating the vision for change
  2. Leading by example
  3. Changing the organization

Future videos in the series will elaborate on these three core responsibilities.

Real Agility References

Here are some additional references about how leaders can help their organizations move towards Real Agility:

Please subscribe to our YouTube channel to receive notifications when each new video is published! (There are 15 more videos coming in this series, and more beyond that on other topics!)  You can also find the summary article that helps you find all the videos and additional references here: Leading to Real Agility – Introduction.

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BESTEIG Real Agility logo

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Scrum Team Assessment – Official Launch

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

Hi Everyone,  I don’t do announcements on here too often, but I wanted to let everyone know about the official launch of our new product: the Scrum Team Assessment – an online tool for your team to get a report on how well they are using the Scrum framework… and most importantly, helpful recommendations on how to improve!  This is a fully automated Scrum maturity assessment tool!

The Scrum Team Assessment is based on the years that I and two other coaches (Paul Heidema and Travis Birch) have been working with Scrum and Agile teams to improve business and technical results.  The Scrum Team Assessment is a joint effort that has resulted in a fully automated virtual coach for your team.

The analysis is both statistical and expert-system based.  This means that the report has basic information about how the team is following Scrum, and, more importantly, clear how-to advice to get your team to make improvements.  There are “quick wins” which are easy but will have a significant impact as well as long-term recommendations that are often harder, but will drive your team to a high-performance state.

The Scrum Team Assessment includes a survey of about 100 questions that focus on seven broad categories:

  • The team’s environment
  • The basic Scrum process
  • The Product Backlog
  • Team Membership
  • ScrumMastering
  • Product Ownership
  • and Agile best practices

Every team member fills in the survey to help us generate a valid set of recommendations.

The Scrum Team Assessment is $496/team/use (that’s Canadian dollars).  If you have several teams or wish to obtain an enterprise license, please contact us at sales@berteigconsulting.com or +1-905-868-9995.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Introduction

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

Leading an organization to Real Agility is a complex and difficult task.

Leading to Real Agility is about how leaders including executives and senior managers help their organization achieve great business results and a great corporate culture. This video introduces the topics of our next series of videos.

This is the first video in a series on Leading to Real Agility.

Leading to Real Agility

The following topics will be covered in the video series.  A new video will be posted every two weeks.

  1. Leadership Responsibilities – what must leaders do to inspire change.
  2. Communicate the Vision for Change – how leaders can craft a compelling vision for change.
  3. Lead by Example – the actions of leaders matter.
  4. Change the Organization – the primary work of leaders.
  5. Environment for Change – hindering and helping change.
  6. Real Agility Practices – how do leaders and their staff work?
  7. Choosing a Change Approach – options for changing your enterprise.
  8. Leadership and Culture – what do you need to know to change culture?
  9. Change Adoption Curve – when do people adopt change?
  10. Leadership Time Allocation – a major benefit of improvement.
  11. Handling Resistance and Laggards – leading sometimes means pushing.
  12. Choosing a Pilot Project – some projects are better than others when you’re starting out.
  13. Real Agility at Scale – if you have a big organization.
  14. Organizational Agility – having wholeness and integrity throughout.
  15. Individual Leadership Development – a leader’s personal journey.
  16. Assessing Your Organization – where are you right now?

Please subscribe to our YouTube channel to receive notifications when each new video is published!

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BESTEIG Real Agility logo

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail