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.

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

Announcing: New Course Offerings!

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

BERTEIG Provides World Class Training For Agile Teams & Organizations

Join the BERTEIG team for Training in the GTA and throughout Canada.  Register for an upcoming class near you!

Imagine that you could learn the secrets to high performance teams, management and organizations! Double your productivity! Dramatically improve quality! Create great working environments! Delight your customers! Our Learning Events give you the tools and practices to transform your team and your organization. Whether you are a team member in a small startup or an executive in a Fortune 500 organization, we have something for you. Learn about the performance-enhancing methods of Scrum, LeSS, Kanban, SAFe and others!

Types of Training

Scrum Alliance Registered Education ProviderCertified ScrumMaster (CSM)Certified Scrum Product Owner (CSPO)Certified Scrum Developer (CSD)Certified Scrum Professional (CSP)
Large Scale ScrumScaled Agile FrameworkReal AgilityProject Management Institute (PMI) Registered Education Provider

See our complete schedule of Learning Events!

Earn PDUs! Earn SEUs!

BERTEIG is a Registered Education Provider with Scrum Alliance and Project Management Institute. Our training courses qualify as professional development units for IIBA, OpenAgile Institute, and others.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Skills Matrix for Launching Teams – Presentation

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

Here is the set of slides from my presentation on the use of the Skills Matrix to help launch Agile teams.  This was first presented at AgileTO in March 2016.

20160316 Agile TO Meetup – Skills Matrix [pdf]

And the video on YouTube:

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Self-Driving Cars and Code Test Coverage

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

Mike Caspar has another thought provoking article, this one about self-driving cars and code test coverage.

Personally, I don’t want to let a vehicle drive me where the developers have been pressured (or the developers have decided on their own) to write code without tests…. I am just thinking about my future and I don’t want this topic to come up when it’s far too late for myself, family or friends.

Dear reader: if you have anyone connected to the auto industry and self-driving vehicles, please share Mike’s blog post!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The New Scrum Guide: The 5 Scrum Values

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

Ken Schwaber and Jeff Sutherland have just announced the new version of the Scrum Guide!  The only change is the addition of two paragraphs about the five Scrum values:

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and builds trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

The Scrum Guide is the sole and official definition of Scrum.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Breaks Between Sprints Indicate a Problem

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

This post is a follow-up to an earlier article: There Are No Breaks Between Sprints.

Breaks between Sprints indicate a problem. Usually such breaks are filled with planning activities including research, requirements gathering, design & preparation, negotiations & approvals and the problem is threefold:

  1. Such plans are based on conjecture (risky and not compatible with Scrum) rather than empiricism (less risky and compatible with Scrum). Those activities are most beneficial when diligently performed by skilled inspectors at the point of the work. The four formal events within each Sprint provide the team and stakeholders adequate opportunity for inspection and ensure that decisions are being made in light of the up-to-date product increment and with respect to current user needs and market conditions.
  2. Breaks between Sprints often include activities which do not add value to the product or are entirely unrelated.
  3. Breaks between Sprints defer the delivery of value because the work performed does not result in potentially-releasable increment of “Done” product.

To correct this problem it is important to identify whether any of the effort spent between Sprints is adding value to the product — that is, which activities effect the form, fit, or function of the actual product. If determined to not be value adding, stop the activity entirely — it is waste. If determined to be value adding then the work ought to be part of their Sprints and the Scrum Team may decide that either the activity should be represented and ordered in the Product Backlog, or should be represented in the team’s Definition of Done.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Promotional: Video About our Agile Training

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

BERTEIG offers agile training for Certified ScrumMaster, Certified Scrum Product Owner, Certified Scrum Developer, Leading SAFe, and more.  This promotional video gives you a glimpse into the classroom for these fantastic events.

Find out more on our BERTEIG / WorldMindware course registration site.

Note: all prices in Canadian dollars.  Most courses are delivered in the Toronto area, but we also come to you to deliver training upon request!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Certified LeSS Practitioner with Craig Larman

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

In just a few weeks we will be hosting Craig Larman here in Toronto as he facilitates the first-ever-in-Canada Certified Large Scale Scrum Practitioner training!  Large Scale Scrum (LeSS) is about de-scaling.  In simple terms, this is about using Scrum to make the best possible use of the creativity, problem-solving and innovation abilities of large numbers of people, rather than getting them stuck in bureaucracy and management overhead.

Here are the details of this unique learning event:

  • Date and Time: April 11-13 (3 Days), 2016 – 9am to 6pm all three days
  • Location: Courtyard by Marriott Downtown Toronto, 475 Yonge St. Phone: 416-924-0611
  • Price: $3990.00 / person (that’s in Canadian Dollars – super great deal if you are coming from the US!)

Check out the full agenda and register here.

Here are some quotes from previous attendees:

“It was inspiring to discuss Large-Scale Scrum with Craig Larman. The content of the course was top-notch.” – Steve Alexander

“The delivery was outstanding and the supporting material vast and detailed.” – Simone Zecchi

“The best course I have ever been on. Totally blown away.” – Simon Powers

Certified Less Practitioner BadgeToronto is a great place to visit (I know many of our Dear Readers are from the United States) – don’t hesitate to consider coming in for a weekend as well as the course!

Register now! (Goes to our BERTEIG / World Mindware learning event registration site.)


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Refactoring: 4 Key Principles

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

I believe in refactoring.  The Agile Manifesto holds that

The best architectures, requirements and designs emerge from self-organizing teams.

The quality of our software systems depends on refactoring.  In fact, I believe that the only way that an organization can avoid refactoring is by going out of business.  Maybe I should explain that.

Refactor or Die

Heart Monitor Flatline - Refactoring or DeathEvery software system that we build is inside a dynamic environment.  The organization(s) using the software are all in a state of constant change.  The people using the software are also constantly changing.  Due to this constant change, every software system needs to be adapted to the environment in which it is used.  Most of the time, businesses think of this constant change in terms of new features and enhancements – the scope of functionality that a system can handle.  Less commonly, businesses think of this change in terms of the obvious external qualities and attributes of the system such as performance or security.  But almost never does an organization, from a business perspective, think of the invisible qualities of the software system such as simplicity and technical excellence.

What happens when the business does not recognize those invisible qualities?  I’m sure almost every software developer reading this can answer this question easily: the system becomes “crufty”, hard to maintain, bug-prone, costly to change, maze-like, complex.  Some people refer to this as legacy code or technical debt.

The longer this state is allowed to continue, the more it costs to add new features – the stuff that the business really cares about.  It is pretty easy to see how this works – for someone who has a technical background.  But for those without a technical background it can be hard to understand.  Here is a little analogy to help out.

Imagine that you set up a system for giving allowance to your kids.  In this system, every week your kids have to fill out a simple form that has their name, the amount that they are requesting, and their signature.  After a few weeks of doing this, you realize that it would be helpful to have the date on the form.  You do this so that you can enter their allowance payments in your personal bookkeeping records.  Then you decide that you need to add a spot for you to counter-sign so that the paper becomes a legal record of the allowance payment.  Then your kids want extra allowance for a special outing.  So you add some things on the form to allow them to make these special requests.  Your accountant tells you that some portions of your kids allowance might be good to track for tax purposes.  So, the form gets expanded to have fields for the several different possible uses that are beneficial to your taxes.  Your form is getting quite complex by this point.  Your kids start making other requests like to be paid by cheque or direct-deposit instead of in cash or to be paid advances against future allowances.  Every new situation adds complexity to the form.  The form expands over multiple pages.  Filling out the form weekly starts to take significant time for each child and for you to review them.  You realize that in numerous places on the form it would be more efficient to ask for information in a different way, but you’re not sure if it will have tax implications, so you decide not to make the changes… yet.  You decide you need your own checklist to make sure that the forms are being filled out correctly.  A new tax law means that you could claim some refunds if you have some additional information… and it can be applied retroactively, so you ask your kids to help transcribe all the old versions of the form into the latest version.  It takes three days, and there is lots of guess-work.  Your allowance tracking forms have become a bureaucratic nightmare.

The forms and their handling is what software developers have to deal with on a daily basis – and the business usually doesn’t give time to do that simplification step.  The difference is that in software development there are tools, techniques and skills that allow your developers to maintain a system so that it doesn’t get into that nightmare state.

For a more in-deth description of this process of systems gradually becoming more and more difficult to improve, please see these two excellent articles by Kane Mar:

Technical Debt and Design Death

Technical Debt and Design Death: Part II

Ultimately, a software system can become so crufty that it costs more to add features than the business benefit of adding those features.  If the business has the capacity, it is usually at this point that the business makes a hard decision: let’s re-write the system from scratch.

I used the word “decision” in that last sentence.  What are the other options in that decision?  Ignoring the problem might be okay for a while longer: if the company is still getting benefit from the operation of the system, then this can go on for quite a while.  Throwing more bodies at the system can seem to help for a bit, but there are rapidly diminishing returns on that approach (see The Mythical Man-Month for details).  At some point, however, another threshold is reached: the cost of maintaining the operation of the system grows to the point where it is more expensive than the operational value of the system.  Again, the business can make a hard decision, but it is in a worse place to do so: to replace the system (either by re-writing or buying a packaged solution), but without the operating margin to fund the replacement.

In his articles, Kane Mar describes this like so:

It’s pretty clear that a company in this situation has some difficult decisions ahead. There may be some temporary solution that would allow [a company] to use the existing system while building a new product, [A company] may decide to borrow money to fund the rewrite, or [a company] may want to consider returning any remaining value to their shareholders.

In other words, refactor or die.

Refactoring and Business

Refactoring and Business Success - Growth ChartIn the Scrum Master and Product Owner classes that we teach, this topic comes up frequently: how does the business account for refactoring?  How do we “govern” it?  How do we make good decisions about refactoring?

There are a few principles that are important in helping to answer these questions.  All of these principles assume that we are talking about refactoring in an Agile team using a framework like Scrum, OpenAgile, or Kanban.

Refactoring Principle One: Keep It Small

Refactoring is safest and cheapest when it is done in many small increments rather than in large batches.  The worst extreme is the complete system re-write refactoring.  The best refactoring activities take seconds or minutes to execute.  Small refactorings create a constant modest “overhead” in the work of the team.  This overhead then becomes a natural part of the pace of the team.

Not all refactoring moves can be kept so small.  For example, upgrading a component or module from a third party might show that your system has many dependencies on that module.  In this case, efforts should be made to allow your system to use both the old and the new versions of the component simultaneously.  This allows your system to be partially refactored.  In other words, to break a large refactoring into many small refactorings.  This, in turn, may force you to refactor your system to be more modular in its dependencies.

Another common problem with keeping refactorings small is the re-write problem.  Your own system may have a major component that needs to be re-written.  Again, finding creative technical means to allow for incremental refactoring of the component is crucial.  This can often mean having temporary structures in your system to allow for the old and new parts to work harmoniously.  One system that I was working on had to have two separate database platforms with some shared data in order to enable this “bi-modal” operation.

Refactoring Principle Two: Business Catalysts

When is the earliest that a refactoring should be done? Not whenever the technical team wants to do it.  Instead, the technical team needs to use business requests as catalysts for refactoring.  If the business needs a new feature, then refactoring should only be done on those parts of the system that are required to enable that feature.  In other words, don’t refactor the whole user interface, just refactor the parts that relate to the specific business request.

Again, there can be exceptions to doing this… but only in the sense that some refactorings might be delayed until a later date.  This is tricky: we want to make sure that we are not accumulating technical debt or creating legacy code.  So, instead, we need to allow the technical team to refactor when they detect duplication.  Duplication of code, data or structure in the system.  A business request might impact a particular part of the system and the team sees how it might be necessary to refactor a large swath of the system as a result.  But, the cost of doing so is not yet justified: the single request is not enough of a catalyst, and the team can also choose a simple temporary solution.  Later, the business makes another request that also implies the same large refactoring.  Now is the time to seriously consider it.  It is now a question of duplication of another simple temporary solution. The business may not be happy with the extra expense of the large refactoring so the principle of keeping it small still applies.  However, the technical team must also be willing to push back to the business under the right circumstances.

Refactoring Principle Three: Team Cohesion

Teamwork in Agile requires high levels of communication and collaboration.  In refactoring work, teamwork applies just as much as in any other activity.  Here, it is critical that all members of the team have a unified understanding of the principles and purpose of refactoring.  But that is just the first level of team cohesion around refactoring.

The next level of team cohesion comes in the tools, techniques and practices that a team uses in refactoring.  Examples include the unit testing frameworks, the mocking frameworks, the automation provided by development tools, continuous integration, and perhaps most importantly, the team working agreements about standard objectives of refactoring.  This last idea is best expressed by the concept of refactoring to patterns.

The highest level of team cohesion in refactoring comes from collective code ownership and trust.  Usually, this is built from practices such as pair programming or mob programming.  These practices create deep levels of shared understanding among team members.  This shared understanding leads to self-organizing behaviour in which team members make independent decisions that they know the other team members will support.  It also impacts research and learning processes so that teams can do experiments and try alternatives quickly.  All of which leads to the ability to do refactoring, large and small, quickly and without fear.

Refactoring Principle Four: Transparency

In many ways, this is the simplest refactoring principle: the team needs to be completely open and honest with all stakeholders about the cost of refactoring.  This can be difficult at first.  Another analogy helps to see the value of this.  A surgeon does not hide the fact that care is put into creating a clean operating environment: washing hands, sterilizing instruments, wearing face masks and hair covers, restricted spaces, etc.  In fact, all of those things contribute to the cost of surgery.  A surgeon is a professional who has solid reasons for doing all those things and is open about the need for them.  Likewise, software professionals need to be open about the costs of refactoring.  This comes back to the main point of the first part of this article: hidden and deferred costs will still need to be paid… but with interest.  Software professionals are up-front about the costs because doing so both minimizes the costs and gives stakeholders important information to make decisions.

The challenge for business stakeholders is to accept the costs.  Respecting the team and trusting their decisions can sometimes be very hard.  Teams sometimes make mistakes too, which complicates trust-building.  The business stakeholders (for example, the Product Owner), must allow the team freedom to do refactoring.  Ideally, it is continuous, small, and low-level.  But once in a while, a team will have to do a large refactoring.  How do you know if the cost is legitimate?  Unfortunately, as a non-technical stakeholder, you can’t know with certainty.  However, there are a few factors that can help you understand the cost and it’s legitimacy, namely, the principles that are described here.

If the refactoring is small, it is more likely to be legitimate.

If the refactoring is in response to a business catalyst, it is more likely to be legitimate.

If the refactoring is reflective of team cohesion, it is more likely to be legitimate.

And, of course, if the refactoring is made transparent, it is more likely to be legitimate.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Perfect Agile Tool – 12 Key Features

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

The Perfect Agile Tool doesn’t yet exist.  In my training and consulting work, I often have strong words to say about electronic tools.  Most of the tools out there are really bad.  Unfortunately, JIRA, the most common tool, is also the worst that I know of.  (Actually, the only tool worse than JIRA for an Agile team is MS Project – which is just plain evil).  Some Agile tools do a bit better, but most fall far short of a good physical task board (information radiator).  I am often asked to evaluate and / or partner with tool vendors to “bless” their products.  Here is what I am looking for before I will consider an outright endorsement of such a tool.

Features for a Perfect Agile Tool

This list is roughly organized in order of features which do show up in some tools to those which I have never seen or heard of in tools.

1. Skeumorphism: Cards and Wall

The tool should display the current work of an Agile team in a way that is immediately recognizable as a set of note cards or PostIt’s on a physical wall.  This includes colours, sizes, etc.  Most people will type to enter data so fonts should be chosen to mimic hand-printed letters.  Every aspect of the display should remind people of the physical analogue of the tool.

2. Live Update

As team members are using the tool, all updates that they make should be visible as immediate updates to all the other team members including typing, moving cards around, etc.  There is no off-line mode for the tool.  In fact, if the tool is not receiving live updates, it should be clearly disabled so that the team member knows there is a problem with the information they have displayed.

3. Simple or No Access Control

Most Agile methods strongly de-emphaisize or even disallow traditional roles and encourage self-organizing teams.  This means that fine-grained access control to different features of the tool should be eschewed in favour of extremely simple access control: everyone can do anything with the tool.  (It actually helps if there is no “undo” feature, just like there’s no easy way to erase Sharpie written on a note card.)

4. Infinite Zoom In/Out

When you are using cards on a wall, it is easy to see the whole wall or to get up close and see even very fine details on a single note card.  Although it does not have to be literally infinite, the wide and tight zoom levels in the tool should be at least a few orders of magnitude difference.  As well, the zoom feature should be extremely easy to use, similar perhaps to the way that Google Maps functions.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

5. Touch Device Compatible

This seems like a super-obvious feature in this day and age of tablets, smart phones and touch-screen laptops.  And it would take the cards on the wall metaphor just that extra little way.  But very few tools are actually easy to use on touch devices.  Dragging cards around and pinch to zoom are the obvious aspects of this feature.  But nice finger-drawing features would also be a big plus (see below)!

6. Size Limit on Cards

For techies, this one is extremely counter-intuitive: limit the amount of information that can be stored on a “card” by the size of the card.  It shouldn’t be possible to attach documents, screen shots, and tons of meta-data to a single card.  Agile methods encourage time-boxing (e.g. Sprints), work-boxing (e.g. Work-in-Process limits), and space-boxing (e.g. team rooms).  This principle of putting boundaries around an environment should apply to the information stored on a card.  Information-boxing forces us to be succinct and to prefer face-to-face communication over written communication.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

7. Minimal Meta-Data

Information-boxing also applies to meta-data.  Cards should not be associated with users in the system.  Cards should not have lots of numerical information.   Cards should not have associations with other cards such as parent-child or container-contained.  Cards should not store “state” information except in extremely limited ways.  At most, the electronic tool could store a card ID, card creation and removal time-stamps, and an association with either an Agile team or a product or project.

8. Overlapping Cards

Almost every electronic tool for Agile teams puts cards in columns.  Get rid of the columns, and allow cards to overlap.  If there is any “modal” behaviour in the tool, it would be to allow a team member to select and view a small collection of cards by de-overlapping them temporarily.  Overlapping allows the creation of visually interesting and useful relationships between cards.  Cards can be used to demarcate columns or groupings without enforcing strict in/out membership in a process step.

9. Rotatable, Foldable, Rip-able Cards

Increase the fidelity of the metaphor with physical cards on a wall.  Rotation, folding and ripping are all useful idioms for creating distinct visual cues in physical cards.  For example, one team might rotate cards 45 degrees to indicate that work is blocked on that card.  Or another team might fold a dog-ear on a card to indicate it is in-progress.  Or another team might rip cards to show they are complete.  The flexibility of physical cards needs to be replicated in the electronic environment to allow a team to create its own visual idioms.  Among all the other features I mention, this is one of the top three in importance for the perfect Agile tool.

10. Easy Sketching on Cards… Including the Back

Cards should allow free-form drawing with colours and some basic diagramming shapes (e.g. circles, squares, lines).  Don’t make it a full diagramming canvas!  Instead, allow team members to easily sketch layouts, UML, or state diagrams, or even memory aides.  The back side of the card is often the best place for more “complex” sketches, but don’t let the zoom feature allow for arbitrarily detailed drawing.  Lines need a minimum thickness to prevent excessive information storage on the cards.

11. Handwriting Recognition

With Siri and other voice-recognition systems, isn’t it time we also built in handwriting recognition?  Allowing a team member to toggle between the handwriting view and the “OCR” view would often help with understanding.  Allow it to be bi-directional so that the tool can “write” in the style of each of the team members so that text entry can be keyboard or finger/stylus.

12. Sync Between Wall and Electronic Tool

This is the most interesting feature: allow a photo of cards on a wall to be intelligently mapped to cards in an electronic tool (including creating new cards) and for the electronic tool to easily print on physical note cards for placement on a wall.  There is all sorts of complexity to this feature including image recognition and a possible hardware requirement for a printer that can handle very small paper sizes (not common!)

Key Anti-Features

These are the features that many electronic tools implement as part of being “enterprise-ready”.  I’ll be brief on these points:

No Individual Tracking – the team matters, not who does what.

No Dependency Management – teams break dependencies, tools don’t manage dependencies.

No Time Tracking – bums in seats typing doesn’t matter: “the primary measure of progress is working software” (or whatever valuable thing the team is building) – from the Agile Manifesto.

No Actuals vs. Estimates – we’re all bad at predicting the future so don’t bother with trying to get better.

No Report Generation – managers and leaders should come and see real results and interact directly with the team (also, statistics lie).

No Integration Points – this is the worst of the anti-features since it is the one that leads to the most anti-agile creeping featuritis.  Remember: “Individuals and interactions [are valued] over processes and tools” – from the Agile Manifesto.

Evaluation of Common Agile Tools

I go from “Good” to “Bad” with two special categories that are discontinuous from the normal scale: “Ideal” and “Evil”.  I think of tools as falling somewhere on this scale, but I acknowledge that these tools are evolving products and this diagram may not reflect current reality.  The scale looks like this, with a few examples put on the scale:

Perfect Agile Tool evaluation scale with examples

Plea for the Perfect Agile Tool

I still hope that some day someone will build the perfect Agile tool.  I’ve seen many of the ideal features listed above in other innovative non-Agile tools.  For example, 3M made a PostIt® Plus tool for the iPhone that does some really cool stuff.  There’s other tools that do handwriting recognition, etc.  Putting it all together in a super-user-friendly package would really get me excited.

Let me know if you think you know of a tool that gets close to the ideal – I would be happy to check it out and provide feedback / commentary!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail