A Litmus Test for Agility

Being Agile seems to be the rage these days and everyone has an opinion on what Agility means and how to do it “right”.  This article doesn’t make process recommendations, but it does provide a quick, effective way to help your team and organization get on track with being Agile (primarily a mindset measurement) and not just doing Agile (primarily a practices measurement).  Presented below is a simple and lightweight test that can be applied by almost anyone; it provides clear steps for improvement, and it is geared for alignment with the core Agile Principles and Values.

The Need

CoachThere are lots of Agile practitioners, coaches and trainers out there claiming to be experts.  Some are genuinely skilled while others have a few key certification letters beside their name and yet little to no in depth, real-world experience.  Although most have a genuine intent to help and they might actually succeed at it, others might inadvertently do more damage and provide harmful guidance.  How can you help them help you?

FrameworkThere are also numerous frameworks, methodologies, and practices that claim they are well suited to help an organization become more Agile.  Some of them are simplistic, process-based approaches that may not account for your environment, culture, or specific business needs, while others are more complex and pragmatic.  Depending on your situation it can be tricky to know what will work best.  How can you find a suitable fit?

MeasurementThere are also many tools and approaches to measure a team’s Agility, the leadership’s alignment with Agile, or the organizational maturity.  Some of these simply measure the number of practices (i.e. are you doing Agile), others account for an in depth assessment of cultural factors (i.e are you being Agile), and some are based on scenarios that are idealistic given common real world business challenges.

Indeed there are a wide variety of indicators of varying complexity, so you might be challenged to determine if they are simply vanity measures, helpful health indicators, or suitable fitness criteria, and more specifically if they appropriately measure for the outcomes you are looking for.  How can you ensure they are providing valuable insights and actionable results so you may make data driven decisions?

Keep it Simple and Focused

Given all these complexities, how do you know what it really means to be Agile, how can you align the effort, and how do you know how successful you are?

The answer is keep it simple and focused, and be outcome driven. Specifically, start with the foundations of Agile and then evaluate Agility from your perspective, your organization’s business needs, your employee’s needs, and most importantly from your customer’s needs.  Then, use that information to measure and steer improvement towards your real desired outcomes of Agility.

In the spirit of keeping it simple and focused, I’m sharing a “quick” and lightweight Agility Litmus Test and Procedure below to measure how you are doing and to ensure you, your stakeholders and your approaches are all headed in the right direction.

A Straightforward Procedure

1) Align With The Agile Manifesto

Read the Agile Manifesto.  I don’t mean gloss over it on the train on the way to work, or over lunch, or during your kid’s sports game.  I mean READ it, focusing on the twelve guiding principles AND the four value statements.

If it helps, boil each of the twelve principles down to two or three key words to provide clarity.  Then, when reviewing each principle ask yourself what you think it really means, and why you think it was important enough for the signatories to explicitly call it out in the Manifesto (what the intent was).  To ensure everyone has a similar frame of reference you may find it useful to host a time boxed, focused discussion on each principle.

2) Choose Key Agile Measures

Of the twelve principles ask yourself which ones (pick 3 or 4 at most) are core, or most important to you and your stakeholders (your organization, your leadership, your customers and your team).  Don’t just speculate or guess what the answers are; you will likely need to facilitate several workshops with the appropriate people to get to the truth to those questions.

This activity in itself is a test.  If there is not close alignment on what the most important principles are then stop right here.  Do not proceed until you align on what those key principles are.  If you proceed without alignment you risk working against one another and not towards a common goal or outcome.  Note that getting alignment might prove contentious so you may need a series of facilitated sessions to hash it out.

Once you align on several core principles they become your key indicators for the Litmus Test for Agility.  These are also your defined Agile outcomes, because they encapsulate what it specifically means for you to be Agile (where you want to be).

3) Perform a Critical Assessment

Starting with your key indicators, honestly answer the question how close or how far away are we” for each one.  Use a scale of 1 to 7, where 1 means “not close at all” and 7 means “we are totally nailing it”.  I chose 1-7 because it gives just enough range to differentiate measures.  That, and it is exactly 1/2 of the pH range for a proper Litmus test!

Be sure to seek fair and equal participation in this evaluation, as it is important to help reduce bias and ensure perspectives are accounted for.  This means you should ensure you have adequate representation from as many groups as is practical.

Honesty and transparency are also extremely critical here so you may require a facilitated session.  You may also need to provide a safe environment to encourage honesty in responses, so anonymous scoring and evaluations would be an appropriate technique to use.

4) Determine Actions

Critically review the summary of evaluative responses for your key indicators.  If the average is less than 6 out of 7 then hold a strategic planning session to determine actions to get you closer to achieving those outcomes.  Note also if there is a wide dispersal of the individual responses for a key indicator that would strongly suggest there is a large misalignment amongst the respondents, and you need to address that gap.

One question to ask would simply be “what would it take…”, or “what would we need to do to get us to a 6 or higher?   When following this line of reasoning be sure to account for the coaches, practitioners and experts you are relying on by asking “What can or should they be doing to align with our key indicators and Agile outcomes?”

Also, look at the frameworks and approaches you are using and ask “How can we switch, change or improve our ways to improve Agility?”

Finally, look at the tools and measures you are leveraging and ask “Are these vanity measures or are they really meaningful?” and “How can we improve these measures (not just the values, but the metrics themselves) to provide more meaningful insights and help us better realize our defined Agile outcomes?”

As a group then choose at least one and no more than three specific actions that came out of the discussion above, implement them, hold one another accountable for them, and measure on the next round if your actions had the desired effect of improving the scores for your key indicators.

5) Learn and Refine

Repeat steps 3 and 4 of this procedure at frequent and regular intervals, being sure to not only measure but also define and take new action.

6) Reassess and Pivot as Needed

If time permits or if your key indicators all show consistent strength, consider switching to some of the other Agile Manifesto Guiding Principles.  If it seems logical you may even want to go back and repeat the entire process as your needs and outcomes may have changed.

Conclusion

The core value this Litmus Test for Agility provides is a) in its simplicity, b) in it’s inherent alignment with the Agile Values and Principles, and c) in its focus on what matters most for you and your stakeholders.  It uses the Manifesto as a foundation, and then allows you to focus on what is most important to you.

Like all tests and models this approach has some inherent strengths and weaknesses.  For example, it is lightweight, cheap, easy to implement, and aligned with core Agility, however it is not an extravagant or in depth test so it may not account for complexities.  As such it should never replace sound judgement.

Meanwhile, if you sense or feel there is something deeper going on that may be impeding your organization’s ability to become more Agile then be sure to investigate thoroughly, work with others to obtain nonpartisan assessment, and provide clarity along the way on intent, outcome, and learnings.

If you are practicing Scrum, using a more sophisticated tool such as Scrum Insight (a virtual “Coach-in-a-Box”) can provide much richer, deeper feedback and insights, including recommended actions.  Even the free version of the tool provides keen insight.

Depending on circumstance you might also find it advantageous to call in expert facilitation, advisors or coaches to either conduct an Agility test such as this or even help your team or organization get to the heart of their issues and challenges.  Organizations such as BERTEIG are not only Agile teachers but they are also hands-on practitioners that can coach your team and organization to reaching new levels of Agility, either with a lightweight touch or a fully immersive engagement.

Coincidentally, reflecting, collaborating, providing transparency, and adopting a continuous learning and improvement mindset are in and of themselves indicators of Agility.  So identifying core values such as these and then making them part of your Agile Litmus Test (i.e. making them your new Agility outcomes) shows how simple it can be to improve, adapt and grow even this lightweight approach!


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Art of Agile Learning Events 101: Thoughts on Good Teaching

Teaching is an art form. Good teaching requires the softer personal skills more than hard facts and knowledge. In fact, great teaching requires consistent learning on the part of the instructor. That’s part of being agile. Every class and every new group of students, whether you’re teaching Scrum, SAFe or Kanban, is an opportunity for a teacher to learn and perfect his/her art.

by valerie senyk

The points discussed here are not an exhaustive list; they are a starting point for anyone struggling with figuring out how to train/teach anything agile – or anything, for that matter!

First impressions go a long way, so be at your best. Smile and warmly welcome your participants. Smiling helps people feel more comfortable. Try to make eye contact with as many as possible. Your introduction should be energetic. It’s a lot like writing a short story or news article – the reader’s attention has to be captured in the opening lines, or the story goes unread. When you are teaching, it does not matter if you happen to be tired or had a fight with your spouse. Participants  have paid to be there, and no matter what your personal circumstances are, you are there to deliver.

It’s a given that you know your subject and you know what to cover in the class. Do your best to state important ideas and principles with clarity. The essence of teaching and learning is communication. Consider this statement:

One of the chief attributes of a great teacher is the ability to break down complex ideas and make them understandable.”https://www.fastcompany.com/44276/attention-class-16-ways-be-smarter-teacher

Recounting relevant stories is one way to illustrate complex ideas, and the more personal your story is, the more effective it will be with your listeners.

How do you respond to tough or challenging questions? The same web article continues with this thought: “Sometimes the best answer a teacher can give is, ‘I don’t know.’ Instead of losing credibility, she gains students’ trust, and that trust is the basis of a productive relationship.” Acknowledging what you don’t know shows that you’re still learning. No one is perfect or knows everything, and the more you can be yourself, the more relatable the students will find you. Remember, too, that teaching is a dialogue, so listen carefully to your students when they have a question or comment.

Since you don’t need to be worried about not knowing all the answers, that gives you more opportunity to use humour, even to laugh at yourself, if it’s warranted. The Canadian Humber Centre for Teaching and Learning places great emphasis on this aspect. Humour is ranked as one of the top five traits of effective teachers. Laughter helps everyone relax, even the instructor, and gives the learning experience a more agile feel. Laughter definitely enriches the learning experience.

Be passionate about what you are teaching. Expertise is not enough. Passion is infectious, like a fever that your students can catch. When you care about your subject, your students will also care. Your passion also helps you change up the rhythm of your speech, so that sometimes your speech will be more emphatic, and that helps create focus in certain areas of your content and greater interest overall.

Now for the gold: it’s not about you; it’s about them. Your focus should be almost 100% on your students (and you will improve as a teacher as a result). Certainly the material you’ve prepared is important, but your preparation should be such that your awareness need not remain there. Be aware of every response;  read body language constantly. Keep them with you every step of the way. If you  love what you’re doing, and make every effort to communicate, you will not be concerned whether you yourself are doing well; you will be concerned that THEY are doing well. This is the best secret to good teaching, and will enable you to learn so much from those that have come to learn from you.

 


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Grindstone of Agility Happens Here – A Positive View of the Future

Grindstone: a stone disk used for polishing, grinding or sharpening tools

What is it that makes the members of the Agile community so close? We come from different walks of life, yet at conferences and meet-ups, we greet each other with warmth, as friends. Perhaps it is because as trainers and coaches, we see the world through a lens that gives us a uniquely positive view of the future: in our work we are fostering collaborative and uplifting workplaces for humans, the individuals behind the shiny impenetrable face of corporations. We are working to help the humans of the workforce AND we believe that Agile actually has a wider potential reach than just the workforce.

Image result for grindstone image

The toil of corporate coaching has both marked our souls and produced an everlasting bond. We dare to imagine an Agile society, Agile schools, Agile governments: based on the Agile Manifesto’s principles. We believe in trust, respect, face-to-face interactions, people over process, motivation and self-organization. We are walking the talk: upholding these values and principles gives us a sense of purpose and a strong belief that the future will be a better place. Together we swim upstream daily (right into the waterfall you could even say).  In classrooms, corporate offices where we coach, and the blogosphere the environment is peppered with nay-sayers and pessimists. Instead one can have a more positive view of the future. This is where the learning and co-creating happen: the grindstone of Agility.

The pursuit of happiness is a fundamental human goal, and that goal applies the same in the workplace as it does everywhere else. Together we can make a huge impact on the world of work and society as a whole, with positive attitude as our vehicle. Considering many of us spend over 100,000 hours at work over a lifetime, why not improve that experience? As we all know, aiming high is a good character trait, and supporting each other, a valiant aim.

Let’s create more willingness to accept that lofty goal, and recognize that the grindstone is a long-term polishing process that requires positivity.

by Nima Honarmandan and Katie Weston

Check out the recent article by Valerie on the same topic: Build Positive Relationships with Trust in Your (Work) Life.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing the Launch of Scrum Insight – an Automated Online Scrum Coach

Scrum Insight is a tool for Scrum Masters and Scrum Coaches to help them improve their teams.  It leverages the accumulated experience of six expert coaches in an automated online tool.

Scrum Insight Logo - Online Scrum Coach

We have just launched version 1.0.  This version includes easy access  to a free report.  It also includes an optional paid Professional report that replaces the equivalent of 83 hours of on-site coaching.

For Scrum Masters this means access to Scrum coaches that may not otherwise be affordable.  For Scrum Coaches, this means leveraging your time to make progress on the hardest problems facing your Scrum teams.

Using Scrum Insight

Using Scrum Insight is a simple two-step process:

  1. Get all your team members to fill out the Scrum Insight survey (and remember to save everyone’s “survey codes”!!!).
    Taking the survey requires between 8 and 11 minutes.  It seems like a long survey, but is actually very quick to go through.
  2. Load your survey codes and generate your team’s report.
    The free report includes a single piece of advice optimized to your team, plus a score for how well you are doing Scrum and how well your organization is supporting your use of Scrum.
  3. (Optional) Upgrade your report to the Professional version for just $500.
    The Professional report gives you much more in-depth advice, more detailed score breakdowns, a permanent link to your report and much more.

So far, 102 teams have used the Professional Scrum Insight report, and many more the free report – let your team be the next to take advantage of Scrum Insight.

We have posted a more permanent description of Scrum Insight as a page here on Agile Advice.

Reminder: when you do the survey, keep your survey code(s) and print the report that is generated.  We don’t collect your email address to use the free report so there is no permanent way to access it other than using the survey code(s).


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Mind-bender: A Scrum team increases their velocity by doing less work!

Sub-title: Breaking the Iron Triangle

Sub-title #2: Jeff Sutherland’s book could have been called: “Scrum: Twice the decision-making in half the time leading to half the work and twice the output.”
But every smart publisher would throw out that title.

A discussion is raging at LinkedIn about the Iron Triangle because Jeff Sutherland, co-author of Scrum, often says that “Scrum breaks the Iron Triangle”. This, you can imagine, causes ripples through the Project Management community. Mr. Sutherland also speaks of “Velocity” and sometimes as a way to explain the breaking of the Iron Triangle, he’s known to say that a Scrum team can increase their velocity by employing various patterns of behaviour which reduce hand-offs, increase quality, et cetera — and this “breaks” the Iron Triangle.

I have captured some thoughts on the subject below.

In Product Development, the end state cannot be known in advance of starting — that is, the scope cannot be known in advance of starting. And even after starting, the product scope changes rapidly as market conditions and users’ needs change and/or are better understood.

Therefore, the iron triangle is a weak model to apply. The Iron Triangle is a useful model only if the conditions which define scope, time, and cost have low variability. If building a house, for example, the end state can be known before starting its construction; apart from the paint colours and some finishing touches, every part of a house can be modelled and codified before starting its construction. Thus, the Iron Triangle can be useful to inform discussion and decision making: would we like to speed up construction of the house? Maybe…so let’s spend more to hire more contractors.  Will cost change if we add another bedroom and detached garage?  Probably, unless we buy cheaper materials.  See, the variables have predictable outcomes.

If developing product, such as creating software wherein the future states of the source code are unknowable, the iron triangle causes weird discussion and isn’t likely to improve decision-making. Perhaps other theories of constraints can be more useful.

Theories of constraints share a common supposition: “a chain is no stronger than its weakest link”. In complex, adaptive problems, the weakest link is neither scope, nor quality, nor time, not cost, nor knowledge, nor technique — it is common understanding or coherence.  Note, those factors are missing from the Iron Triangle. The Iron Triangle quickly becomes an irrelevant model in the realm of Product Development or complex/adaptive problem-solving. The only way to force the Iron Triangle model in this realm is to consider ‘time’ to be, not just a variable, but a changeable dimension. That is, as a Scrum team increases cohesion and alignment, they make decisions faster — this has the effect of making ‘time’ slow down, they can make more decisions per unit of time as though the team is travelling faster through time.  Weird, right?  So it’s just easier to throw away the Iron Triangle.

About Velocity

Yes, Jeff Sutherland discusses velocity in depth. But I’d like to remind everyone his definition of velocity…

Velocity is a measure of distance travelled over time. In other words, the *distance travelled through the Product Backlog* over *Sprint Length*. To say that velocity, in Scrum, is the speed of the Scrum team is quite inappropriate. More appropriately, an increase in velocity means the team is travelling further through the Product Backlog per Sprint.  It helps to stop thinking of the Product Backlog as a bunch of items and a bunch of story points. It’s more helpful to think of the Product Backlog simply as ‘the work that needs doing’ — a Scrum team can increase their rate of travelling through ‘the work that needs doing’ by…well…by learning.

An increase in a team’s velocity does not mean (necessarily) they are going faster. It OFTEN means they are going smarter. A Sprint is a learning cycle. The team learns as they work together. (Where’s “learning” in the iron triangle!??) When Mr. Sutherland  says Scrum “breaks” the triangle, I believe he is thinking of this very notion of learning. As transparency increases, the team can make better decisions, meaning they can eliminate waste (doing LESS work!!) and cohere more rapidly and achieve high-quality decision-making, thus going increasing their output.

“One of the ways a team increases their velocity is BY DOING LESS WORK.”

As a Scrum team travels through the backlog, a learning team will discover ways to reduce work per Product Backlog Item: they’ll figure out ways to automate a bunch of repetitive stuff; they’ll produce modular designs which create opportunities for reuse and adaptation; they’ll learn from their mistakes, reduce risk, and increase quality. (These are the results of learning as a team and one of the key reasons for Scrum’s rules that a Scrum team is small and has stable membership for long periods — communication saturation enables cohesion and therefore enhances learning…as a team.)

In other words, the team finds ways to travel further through the backlog each Sprint while not working harder/more.

Hence, the iron triangle as weak model for understanding the constraints in complex problems.

Tip: Angela Montgomery has written extensively about Theory of Constraints in complex settings — her writings are waaaaay more helpful to us in the realm of Product Development than the limited Iron Triangle.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Finding Compassion – Lessons Learned From My Street

It may be a cliche to be talking about “Compassion” in the workplace, as it is a “concept” that has been addressed multiple times over many years.

Frankly, it is difficult to actually put into practice. And for me, it was something I explored, adopted, and then ignored, over the past number of decades as real-world priorities shifted.

But I want to share a very personal story that unfolded just today. Bear with me on this, as I will relate this personal situation to the workplace interactions we’ve all likely experienced.

My neighbour is a struggling single mother to whom I genuinely want to succeed, as she is a dedicated mother and a hard worker. However, she recently took a very base-level approach to an emotional situation that affects many people within my neighbourhood.

In short, her dog has behavioural issues which have lead to attacks and mock-attacks upon myself, my family, local contractors, and fellow neighbours. Latitude has been given to her in each instance as she has made earnest efforts to curb this behaviour, but for the most part, she has had marginal success. Most recently the dog actually attacked a local boy, who spent 3 days in hospital as a result.

Clearly, the issue with the “dog in the room” needed to be escalated and dealt with. The injured boy’s father rightly requested that a muzzle order be put in place: an order that has subsequently been appealed by the owner.

Think about this for a moment.

The position of the dog owner just changed, from “I am making earnest efforts” to “my dog is not the problem. You are the problem”.

Why?

Well, there’s been a trigger event and it’s because of a strong emotional connection to her dog. To justify this, she has created a “story” about all the people that are involved in this situation: the young boy in the hospital “provoked” the dog. The “dog doesn’t have the problem, everyone else does, and it’s all lies”. My personal situation in which I had to physically defend my family from the aggressiveness of this loose dog “never happened”. And of course the contractor who locked himself in a room until she came home……. well, you get the point.

It is very easy for me, as a professional who is accustomed to teams, and boardrooms, proper process, HR, and mature interactions that move business forward, to look at her position as an immature and flailing attempt to justify a deeper need. An  emotional need to protect the love she has for this dog and what the dog represents as part of her family.

Relating this to business, I’ve met people who have acted much like her in the workplace. The same story of innocence the dog owner positions, is often found in the boardroom! The questions are why, and secondly, do such people tend to remain in their position or do they get moved along?

They survive. While they may be unskilled and unready to address the actual deep personal issue driving their behaviour, they often position themselves in a very innocent light, and they tend to point out those “liars” around them.

The light went off for me when I found myself emotionally wrapped up in being called a liar by a person who was clearly to blame. How do you defend yourself with your “team skills” and “boardroom skills” against a person with “street skills”?

That is where I found Compassion.

As in situations with my co-workers, colleagues, clients and friends, I realized that this single mother is just trying to provide her son with a home, an education, a pet to call his own, and in between, cut the noise in her life, and find her own sense of happiness while shouldering 100% of the burden.

Moving this concept to the workplace, could it be that a percentage of your colleagues who sometimes leave you scratching your head, have some well-developed “street skills”?

After today I do believe it begins with you – not them – just as this personal revelation with the neighbour began with me.

In the end, the injured son’s father expertly resolved this emotional powder-keg: and I learned it’s not about defending against the accusations, it’s doing exactly what this father did.

He listened to all parties with genuine interest and curiosity. He asked neutral-based questions, keeping his emotions in check. He did not take the accusations personally. He sought answers and he sought consensus. He asked for timelines and process. He often asked for help, and sometimes he had to escalate (i.e. getting a muzzle order) where he needed. But he exercised Compassion at every step.

I learned that defending myself against accusations is not the name of the game: it’s about taking the father’s approach. His Compassion renewed Compassion in me.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What Kanban Is (And Isn’t)

The Kanban Method is a management method for…

  • Directly improving service delivery;
  • Catalyzing improvements;
  • Evolving a business to be fit for purpose.

The Kanban Method is also…

  • An evolving and flexible system of pragmatic, actionable, evidence-based guidance;
  • Adaptable to the unique needs of each context to which it is applied;
  • Inclusive of evidence-based guidance from a broad range of professional disciplines, including economics, psychology, sociology, process management and change management.

The Kanban Method is not…

  • A project management method;
  • A software development lifecycle process;
  • Completely defined in a “manifesto” or “guide”;
  • An immutable process framework with binding rules, extant only in its entirety—in other words, you don’t need to be doing all of Kanban for it to be Kanban, nor is it advisable to try.

You would likely benefit from exploring the applicability of Kanban to your business because…

Your organization is an ecosystem of interdependent services—a complex, adaptive system. You introduce a Kanban system into it such that the complex system is stimulated to improve. – Alexei Zheglov

This wikipedia entry provides a fairly accurate description of the Kanban Method:

https://en.wikipedia.org/wiki/Kanban_(development)

The Kanban Method has 3 Agendas:

  1. Survivability (of the business, for business executives);
  2. Service-orientation (for all levels of management);
  3. Sustainability (for professional services knowledge workers);

The Kanban Method could help you if one or more of the 3 agendas above applies to you.

The Kanban Method has 9 values:

  1. Customer focus
  2. Transparency
  3. Understanding
  4. Agreement
  5. Leadership
  6. Respect
  7. Collaboration
  8. Balance
  9. Flow

The Kanban Method has 6 principles; 3 change management principles and 3 service delivery principles.

Change Management Principles:

  1. Start with what you do now.
  2. Agree to pursue improvement through evolutionary change.
  3. Encourage acts of leadership at all levels.

Service Delivery Principles:

  1. Understand & focus on customer needs and expectations.
  2. Manage the work, let people self-organize around it.
  3. Policies govern service delivery.

The Kanban Method has 6 practices:

  1. Visualize
  2. Limit WIP
  3. Manage flow
  4. Make policies explicit
  5. Feedback loops
  6. Improve & evolve

You are “doing” Kanban if your intentions are that…

  • Management behaviour in your organization changes to enable Kanban;
  • The customer interface changes, in line with Kanban;
  • The customer contract changes, informed by Kanban;
  • Your service delivery business model changes to exploit Kanban.

LeanKanban Inc. is the authority on the Kanban Method. LeanKanban University is the accredited training organization of LeanKanban Inc.

David J. Anderson is the founder of the Kanban Method. Essential Kanban Condensed, co-authored by Anderson and Andy Carmichael, is available as a free download.

Travis Birch is an Accredited Kanban Trainer with LeanKanban University. You can sign up for his upcoming public Kanban courses in December 2017 at Berteig World Mindware.

 


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Sleep and Productivity – Sustainable Pace

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:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What if no one was forced to do Scrum?

I just commented on a LinkedIn thread about “Sprint Zero”. It occurred to me that Sprint Zero is often used as one of many coping mechanisms for people who are forced to do Scrum. It also occurred to me that in my 9 years or so working with a reliable sample size of Scrum teams, not one of those teams was populated entirely by people who were not coerced into doing Scrum.

Gut check: The percentage of people I know who are currently on Scrum teams and who would be doing Scrum if it wasn’t mandated by management could be lower than 50%. This begs the questions: What if Scrum was offered to teams as an optional way to manage their own work? Would there be less Scrum in the world?

With one exception, all of the Scrum teams I have worked with were mandated (forced) by management to implement Scrum. The exceptional team was exceptional in other ways. They were by far the happiest and most revolutionary (in terms of recognition for business success in their organization). Although one or two hesitant team members were roped in by their peers, the social climate of the team allowed the wary to adapt safely and gradually to their new reality.

For the overwhelming majority (in my experience), there is an irony, even a paradox at play. A lot has been said & written about how command and control management is antithetical to Scrum. Yet, many—if not most—Scrum adoptions are commanded by management with vanity metrics (i.e. velocity) installed to uphold the illusion of control.

What are some of the other coping mechanisms for people who are forced to do Scrum? What is driving this behaviour? How many of these behaviours have been labelled as “anti-patterns” and why?

Safety is an essential success factor for any organization. Is it safe for people to choose to not do Scrum, or express dissent about Scrum adoption in their organization? What does this tell us about Scrum itself? Does Scrum need to be reimagined or reframed in order to make Scrum adoption safer for more people? Is it safe to do so?


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Build Positive Relationships With Trust in Your (Work) Life

Trust is an exceptional quality that we humans can develop with each other. It goes a long way to building positive relationships. We hope and strive for trust in our families, and with our most intimate connections. Yet do we expect trust in our work lives?

Can you imagine the  relief you might feel entering your work space, knowing that you can do your work with confidence and focus? That encouragement rather than criticism underlies the culture of your workplace? That a manager or co-worker is not scheming behind your back to knock you or your efforts down in any way? That you’re not being gossiped about?

Trust is especially key in today’s work spaces. Teamwork is becoming an essential aspect of work across every kind of business and organization.

Here’s what one team development company writes about this subject:

The people in your organization need to work as a team to respond to internal and external challenges, achieve common objectives, solve problems collaboratively, and communicate openly and effectively. In successful teams, people work better together because they trust each other. Productivity improves and business prospers. http://beyondthebox.ca/workshops/team-trust-building/

It Starts With Me and You

As with so many qualities in life, the idea of trust, or being trustworthy, starts with me and you.

It is essential that we take a hard look at ourselves, and determine whether or not we display the attributes of trustworthiness.

To do this, I might ask myself some of these questions:

  • Do I tell the truth?
  • Do I avoid backbiting (talking about others behind their back)?
  • Do I do what I say I’m going to do?
  • Do I apply myself to my work and do my best?
  • Do I consciously build positive relationships with all levels of people in my workplace?
  • Do I encourage or help others when I can?

There are many more questions to ask oneself, but these offer a place to start.

One website proposes a template to assess employees in terms of their trustworthiness:

Trust develops from consistent actions that show colleagues you are reliable, cooperative and committed to team success. A sense of confidence in the workplace better allows employees to work together for a common goal. Trust does not always happen naturally, especially if previous actions make the employees question if you are reliable. Take stock of the current level of trust in the workplace, identifying potential roadblocks. An action plan to build positive relationships helps improve the overall work environment for all employees.

http://smallbusiness.chron.com/develop-maintain-trust-work-relationships-12065.html

This snippet comes from “Lou Holtz’s Three Rules of Life,” by Harvey MacKay:

“The first question: Can I trust you?”

“Without trust, there is no relationship,” Lou said. “Without trust, you don’t have a chance. People have to trust you. They have to trust your product. The only way you can ever get trust is if both sides do the right thing.”

http://www.uexpress.com/harvey-mackay/2012/5/7/lou-holtzs-3-rules-of-life

Asking questions helps me to be more aware and to learn. What might you change to help create greater trust with your colleagues or team?

As well, what actions can you take to help your team to experience greater trust altogether?

You can read more about Trust at http://www.agileadvice.com/2017/05/29/uncategorized/soft-skills-revolution-may-want-team-development/

Valerie Senyk is a Team Development Facilitator, Blogger, & Customer Service Rep at BERTEIG. You can learn about her Team Dev workshop at http://www.worldmindware.com/AgileTeamDevelopment


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leveraging Six Sigma Projects with Agile Techniques

Six Sigma is a methodology which has been used for more than 30 years to deliver great strategic and financial results. It has brought significant results for industries and companies from different industries.

I am a Master Black Belt in Six Sigma, and for the past 15 years I have trained over 5,000 people and conducted projects for many companies in South America, North America, and Europe.

Globalization has shortened the distance between customers and business, requiring more speed and adaptability from companies to sell their products and services.

Through a combination of training and consulting in Six Sigma, my team has been supporting organizations to embrace projects towards variability reduction as well as waste elimination to increase customer satisfaction. Millions of dollars have been saved, and we have satisfied our stakeholders.

The reward for our success was that project opportunities came flowing in, yet we were challenged to complete projects even faster and better than before. How could my team do that? We needed to figure out a way together. More and more frequently we were collaborating with our customers and stakeholders to understand exactly what was important. We were inviting the team, analyzing many possibilities, rethinking our approach and then implementing the new framework.

The business environment forced new techniques to achieve different results. I realized that if I challenged our team at the planning meeting stage, we would find new ways to reach the goal (most of the time utilizing a better approach than before). Even if, during the process, we encountered a roadblock, we were able to involve the team to find a creative solution. We found we could do almost anything because we had created an environment of trust.

All along, our stakeholders were aware of what was happening, and they were encouraging the team to keep using the ‘new strategy.’ We stopped wasting our time with delays, dropped the useless documentation, while always ensuring that people were seen as more important than the process. Because of this, we were already delivering results faster than expected and had started the process of becoming Agile.

David Vicentin, Director of Business Development, BERTEIG

Lean Six Sigma Master Black Belt, Coach, Trainer and Agile practitioner, has more than 15 years in management consultancy experience delivering operational excellence and Agile implementation across various businesses. His experience and capabilities have taken him to Spain, United States, Mexico, Brazil, UK and Canada. David’s enthusiasm and practical coaching experience have allowed him to mentor senior managers to achieve sustainable results. An Industrial Engineer with a Masters degree in Economics and Finance, David is able to create an environment of learning in various fields of work.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

IT Project Agility

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.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Equifax Data Breach: Lessons We Must Learn

I woke up this morning to the news that my personal data has been leaked by Equifax to…who knows!?  I was reminded of the following tweet:

So, what “awful circumstances” led to Equifax’s recent breach?

Let’s reflect:  News has surfaced (TechCrunch, Reuters) that hackers have scraped untold amounts of sensitive data from Equifax systems.  143+ million people are affected as hackers have amassed a huge database of names, addresses, credit records, license numbers, banking histories.  (That probably includes you too!)

I want to be clear though, the news broke yesterday but the problem started long ago.  The security vulnerability has existed for (probably) years and I have no doubt some Equifax staff have known about it.

Equifax!  We’re not talking about some high-school project with junior coders and tech newbs.  We’re talking about one of the world’s most trusted organizations.  We’re talking about a company whose very existence (their whole business!) is to protect our collateral.  This is supposed to be one of the best-funded, most secure, most technologically-advanced companies on the planet.

But I’m not surprised.   Here’s why…

I teach Scrum and my classrooms are filled regularly with people who work in companies exactly like Equifax.  I hear their stories every day:

“Our managers don’t provide the tools we need to do the job.”

“Our managers don’t understand the time required to deliver high-quality software.  We’re always pressured to cut corners to meet arbitrary and impossible deadlines.”

“Our systems are broken, everyone knows it, but managers continue to outsource and off-shore our QA.”

“We don’t have authority to decide the implementation, we’re often told what to implement by architects and supervisors, even if we know it to be rotten.”

“Our managers never ask us about quality…they ask us only ‘when will this be done’?”

And that’s the crux of the problem: people are hired by companies like Equifax to provide technical expertise, then their advice is ignored and their implementation decisions aren’t trusted.

Some important questions to consider…

1. Does Equifax lack the money to hire excellent technical staff?

No, their offices are filled with some of the best programmers in the world.  I meet them (or people like them) regularly in my classes and I have no doubt that the technical staff at Equifax have warned the managers for years of security holes and technical defects.  I have no doubt those managers have ignored the alarms and have pushed the staff to deliver deficient code.

2. Does Equifax lack the time to build high-quality systems?

No, last I checked they’ve been at it a long time and their existing contracts will carry their operation years into the future.  And as mentioned earlier, securing our data is the reason the company exists.  It’s  the one thing they’re supposed to get right – I’d think their time should be entirely devoted to building high-quality systems.

3. Does Equifax lack the financial resources to invest in proper tools and training for security/quality testing?

No, such techniques and tools are widely available and inexpensive (even hackers can afford them!)  Managers at Equifax have denied budgets for training, tools, and upgrades because “it’s too costly” – hmm…I wonder the cost of this data breach?

4. And my favourite question of the day: Are the hackers “smarter”?

Absolutely not.  But they’re more dedicated and have equipped themselves with good techniques and tools for penetration testing.  In my personal experience as a hacker (er, I use that term loosely) security holes are all around us if we look for them.  Equifax simply wasn’t looking!

What to do about it…

First, it’s clear to me the problem isn’t technical or financial.  It’s cultural.  I see it all the time.  Teams of good product developers are surrounded by bureaucracy instead of support.   Teams of good coders aren’t trusted to see the source code of the systems used by the company – yes, that’s as crazy as it sounds!  Teams of good coders are kept silent about the security vulnerabilities they see.  Solutions are ignored by management and the arguments are: “improving the security isn’t a priority right  now” or “we know there are some possible security concerns and we are in discussion with vendors or outside agencies to address it” or “we have a budget for security improvements scheduled for next quarter; let’s focus for now on new features instead”.  Managers are more concerned with deadlines than with quality.  Managers scrutinize the number of hours a developer works on a task, and outsource or off-shore the quality assurance and testing!  Managers conduct endless planning activities then compress the implementation into tight budgets and timelines – evidently, a lot of energy is spent getting the plan “right” but getting the software right is not a priority.  I could go on.

If you’re interested to know how things work at Equifax, just think of the Dilbert cartoons.  I mean it.  I am very serious.  Dilbert isn’t funny because it’s fiction; it’s funny because it’s NON-fiction.  Sadly. Typically, for enterprises like Equifax, their technical staff and customers take a back seat to management “theatre”.  This needs to be fixed and it starts by asking the technical staff a single, simple question:  “Who among you have raised concerns about technical debt with your managers/supervisors and were ignored?”  That question will unearth bugs which have been deprioritized by managers, budgets that have been denied for technical training and automated testing, projects which have been reported as “done” before they were actually ready for deployment – in other words, that question will reveal the many (fixable) ways managers get in the way of quality.

Second, executive staff at Equifax need a crash course in automated testing.  Yes, THE EXECUTIVE STAFF!  It’s is essential they understand and see with their own eyes that:

  1. Automated testing is cheaper and exponentially more effective than manual testing;
  2. ALL defects are discoverable and fixable before hitting production environments;
  3. Quality is not something one outsources
  4. and the techniques to achieve ZERO DEFECTS are well-known, teachable, repeatable, and proven.   I’m of course referring to techniques like Test-Driven Development, Continuous Integration, Refactoring, and Swarming.  For example, these technical topics form the bulk of our Certified Scrum Developer classes. (Shameless plug.)

And third, technical staff need to stop behaving like sheep.  So far in this article, I’ve been very critical of managers, sure, and anyone who knows me personally knows I have no time for inept management.  But too often I meet smart, well-meaning developers who deliver shoddy code – perhaps at under pressure and against their better judgement, but in the end whose code is it?  Developers! I understand you might feel trapped in a pattern of quantity-over-quality and you are frequently coerced by your management to cut corners.  I get it… I understand it… it’s easy to feel that deadlines are some sort of immutable truth and that managers wield all the power.  But the fact is, developers, YOU hold all the responsibility and therefore you need to be the professional.  You need to say “no” and demand the latitude you require to deliver high quality.  You’re the one closest to the code and therefore directly responsible for the safety and well-being of your users.

So, Equifax and enterprises everywhere, I’m speaking now as your user or stakeholder or customer…

Equifax has failed. Miserably. The company deserves all the class-action suits coming there way. From leaders to developers. Everyone.

Most members of society are unwilling participants in all this.  Most of us aren’t your direct customers.  Example: I’m not a direct customer of Equifax – nobody has chosen Equifax as their personal agent.  Instead, our banks and our governments have selected Equifax on our behalf.  This presents a problem: if I were a direct customer of Equifax I’d call them today and close my accounts; but I can’t do that.  Instead, the best I can do as an individual is contact my banks, lenders, and insurance agents to demand change.  (Yes, I likely will do that.  I’m that sort.)

However, the larger issue is that we are at the mercy of YOU who produce software.  I’m talking about the software in our vehicles, in our heart-monitors, in our subway systems, in our air-traffic-control centres, in our banks – this is serious stuff!  We must be able to trust those systems…with our lives, with our security.  We must be able to trust you even though we don’t and won’t ever know you.

A hacker friend of mine once said, “if self-driving cars are being produced without complete automated test coverage, then that’s a future I don’t want.”

In this day and age, low quality is intolerable.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Do You Want Love in Your (Work) Life?

Do you want love in your work life? Is it a possibility? Would love in your work life give you a happier step as you leave home each morning?

To be clear, romantic relationships with colleagues at your work place is not the topic. The love I’m proposing is love for your work, and loving affection from and for everyone you deal with in your workplace. So if your answer to the question is “yes,” then read on.

Personal History

I previously taught Theatre Arts and Drama at universities for over 20 years. I loved my subject. I loved watching students transform from insecure, self-conscious, wary creatures to confident, trusting and expressive actors. How did this happen?

In my approach to teaching, I made every effort to nurture students with care and affection, to create a safe and trusting space for them, to provide them with the best learning tools I could find to strengthen their capacities. I treated each one as an individual, trying to understand his or her particular needs. I truly cared that every student would advance.

My door was always open to them outside of classes. They could come to me with personal problems that ostensibly had nothing to do with their course work. I listened with empathy. I made sure that I was trustworthy in all my actions.

For example, I never asked anything of my students that I myself wasn’t willing to perform. I nudged them, sometimes gently, sometimes a bit aggressively (depending on their nature), to move outside their comfort zone. This often resulted in exhilarating experiences for the student.

In other words, I loved my students!

What Creates Safety?

When people are polled about which cultural attribute is most important to them in their workplaces, the highest percentage list “safety.” By safety, they usually mean things like “feeling safe to express my self;” “safe to have a difference of opinion;” “safe to sometimes fail without negative repercussions.”

If we look for the root of what helps us feel safe, I think we can trace it back to receiving human affection and loving care. This is what causes us to stay with a marriage partner over time. It creates lasting bonds with our children, family members, and long-time friends.

How often have you asked yourself the question: “Do I stay in this job that I intrinsically like, but have the urge to flee because its culture is unsafe and unloving?”

Imagine when you were a kid in school and had a favourite teacher. Who was s/he? Why was s/he your favourite? Was s/he especially kind or affectionate? Encouraging? Generous with her time? Think of the way s/he managed her class of several children.

Now think about a person in your workplace with whom you do not feel safe, and imagine that this person is actually like the teacher who was your favourite. How does that change how you feel about that colleague? How differently might you react to him/her?

Giving Love

It may sound flakey, but it has been proven that one of the ways to receive love is to give it. It can start with your thoughts toward a difficult manager or colleague. Reflect on this statement:

When a thought of war comes, oppose it by a stronger thought of peace. A thought of hatred must be destroyed by a more powerful thought of love. Thoughts of war bring destruction to all harmony, well-being, restfulness and content. Thoughts of love are constructive of brotherhood, peace, friendship and happiness.

http://www.bahai.org/library/authoritative-texts/abdul-baha/paris-talks

A wonderful article by Sigal Barsade and Olivia A.O’Neill in the Harvard Business Review discusses this subject of love in the workplace. Here’s a snippet from their article (which is worth reading in its entirety):

We conducted a follow-up study, surveying 3,201 employees in seven different industries from financial services to real estate and the results were the same. People who worked in a culture where they felt free to express affection, tenderness, caring, and compassion for one another were more satisfied with their jobs, committed to the organization, and accountable for their performance.

https://hbr.org/2014/01/employees-who-feel-love-perform-better

Love in the Business World?

I first encountered love as a conscious factor in the business world when I joined BERTEIG. Its founder, Mishkin, spoke often about the importance of expressing love in his training, consulting and coaching events. I found this fascinating, because my impression of big business was that of cool efficiency.

On the BERTEIG website, you can find this Vision Statement:

We co-create sustainable, high-performance organizations where continuous improvement is deeply embedded in the culture. We believe truthfulness is the foundation of improvement, and love is the strongest driver of change.

http://www.berteig.com/about-us/

For the past four years, I have seen the benefits of that vision of love being a strong driver of change in the BERTEIG team. Thus, despite being a very diverse group of people, we have a great deal of affection for each other. This affection enables us to grow, to continuously develop our capacities, and to offer our best. Clients who attend our training courses sometimes gush (yes, gush) about their trainer. Affection not only helps our own internal collaboration but our external as well. When we commit to a project/ job/ event, we follow through because we care.

And, too, one of the beautiful things about love is that it will radiate out to whomever we work with, and to whatever social spaces we participate in.

Now – You!

Do you want love in your work life? Do you believe love can be the strongest driver of change? If so, how can you action this in your own workplace?

Valerie Senyk is a Team Development Facilitator, Blogger, & Customer Service Rep at BERTEIG. You can learn about her Team Dev workshop at http://www.worldmindware.com/AgileTeamDevelopment


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Unpacking the Fifth Principle of the Agile Manifesto

The Agile Manifesto was signed and made public in 2001. It begins with short, pithy statements regarding what should be the priorities of software developers, followed by Twelve Principles. In this article I want to call attention to the fifth principle in the Agile Manifesto, which is:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Although it appears to be a very simple statement, I suggest that it is jam-packed with profitable guidance, and is essential to, and at the heart of, real Agility. Human qualities must be considered.

Motivation

The first part of the principle urges us to build projects around motivated individuals.  What does this imply?

The idea of “building a project” makes it a process, not necessarily a fait accompli. It can change and be altered as one works toward it. There may be a structural roadmap, but many details and aspects can change in the “building.”

The second part of the statement describes motivated individuals. The verb “motivate” is an action word, meaning to actuate, propel, move or incite. Thus, in this line, is the “project” the thing which will “move or incite” those being asked to carry it out?

Or do we understand this to imply that the individuals are already “motivated” in themselves, which is an emotional condition of individuals? Is this motivation already there prior to starting a project?

The topic of motivation is rich. How does motivation occur? Is it the culture and environment of the company, lived and exemplified by it’s leaders, which motivates? Or is motivation an intrinsic quality of the individual? It may be both. (Daniel Pink, author of “Drive,” uses science to demonstrate that the best motivators are autonomy, mastery and purposeful-ness – ideas which are inherent in the Agile Manifesto.)

In any case, the line itself suggests that the project may be a) interesting to pertinent (perhaps already motivated) individuals, b) do-able by those same individuals, and c) contains enough challenges to test the mastery and creativity of the individuals. In other words, it’s going to be a project that the individuals in your company care about for more than one reason.

Environment

The second line from the fifth Principle has two distinct parts to it. The first part, “Give them the environment and support they need” puts a great deal of responsibility on whoever is assigning the project. Let’s look at the idea of environment first.

In a simple way, we can understand environment as the physical place which influences a person or a group. It can be any space or room; it can refer to the lighting, the colours, the furniture, the vegetation, the walls, whether water or coffee is available – physical elements which will certainly affect the actions of people and teams. For example, creating face-to-face collaboration environments is also part of the Agile Manifesto.

But we must remember that environment also entails the non-physical ie, the intellectual, emotional, or even the spiritual. Is the environment friendly or not? Cheerful or not? Encouraging or not? Affirming or not? We can think of many non-physical attributes that make up an environment.

Support

These attributes allude to the second part of what’s to be given by an owner or manager: “…and support they need.” This idea of support pertains not just to helping someone out with tools and responding to needs, but that the environment is supportive in every way – physically, intellectually, emotionally and spiritually. This may be a more holistic way of considering this Agile principle.

The last part of the statement is of great importance as well: and trust them to get the job done.

If you as product owner, or manager have created motivation, environment and support, then the last crucial requirement of trust becomes easier to fulfill. There is nothing more off-putting than being micromanaged, supervised or controlled with excessive attention to small details. Trust means you have confidence in the capacity of your team and its individual members. It also implies that they will communicate with transparency and honesty with you, and you with them, about the project.

Context

The principles of Agile do not exist in a vacuum, because, of course, other principles such as the following, are relevant to this discussion:

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

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

This fifth principle has application far beyond IT projects. I wanted to reflect on it because it speaks to human qualities, which must be recognized as a key factor in happy work places, and in any high-performance team.

Valerie Senyk is a Customer Service agent and Agile Team Developer with BERTEIG.

For more information please go to http://www.worldmindware.com/AgileTeamDevelopmentWorkshopStage1

Also read about BERTEIG’s RealAgility Program: http://www.berteig.com/real-agility-enterprise-agility/


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail