Skip to content

Blogs

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

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

The battle of the organizational change management approaches!

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

20170208 Agile Mississauga Meetup – Change Approach Characterization Model

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

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management appeared first on Agile Advice.

Categories: Blogs

Visualize Your Work So You Can Say No

Johanna Rothman - Thu, 02/09/2017 - 22:43

Most people I know—even the people supposedly using agile—have too much work to do. You have project work. You have support work, formal for customer support or sales, and informal for your colleagues. You have reports to write or file, time cards to fill out, or other periodic events.

You need a way to say no to more work.

I wrote an article for Better Software, which is now online. See Saying No to More Work. (You need to register for the site to see the article. No charge for registration.)

One person wanted to see the kanban boards I referred to in the article. I am happy to show them to you here.

These are two potential kanban boards. The one on the left is the basic personal kanban board. Note that there are no WIP (Work in Progress) limits (yet) on this board. I would add WIP limits. Especially if I wanted to convince my manager I was doing too much work.

On the right,  you can see a disaster of a personal kanban board. There are many items To Do, three in Progress and a total of six stuck in various Waiting states. Yes, I had a board that looked like this many years ago. Then, I made a picture on a piece of paper and explained to my boss I was just one person. What did he want me to do and not do?

Now, given what I know, I would add WIP limits to each column.

If you want to see the project portfolio images for how I start at the organization level: the calendar view and kanban view, see Manage Your Project Portfolio at the Prags. At the end of the blurb, there’s a link to the quick start guide, which has just two of the images in the book. (I included many possible ways to visualize the project portfolio in this edition of the book.)

Here’s the key idea: Don’t take on more work than you can complete in a reasonable amount of time. Don’t multitask. Instead, see what your work is and how you might discuss it with your manager.

Categories: Blogs

How HR Can Save or Destroy Agile

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

“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”

It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.

“Companies are running 21st century businesses with 20th century workplace practices & programs”

– Willis Towers Watson

It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:

  • “Can we team interview the candidate for attitude and fit?”
  • “I was an IT Development Manager. What’s my role now?”
  • “My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
  • “With no opportunity for promotions in sight, how can I advance my career?”
  • “Why do we recognize individuals when we’re supposed to be focused on team success?”
  • “Charlie’s not working out. Can we as the team fire him?”

As the volume increases, how will HR and HR professionals respond?

“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”

– HR Trend Institute

The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR  sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.

There are three significant change movements gaining momentum:

  1. Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
  2. Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
  3. Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux: http://www.reinventingorganizations.com/)

All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.

An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.

“How do we get HR started towards their destiny?”

If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.

If you’re an HR professional, here are some suggestions:

  • Learn about Agile
  • Visit with your Agile teams during sprint reviews or daily scrums
  • Talk to your friends and colleagues about their Agile experiences and challenges
  • Review in-progress HR process & tool changes through an Agile lens
  • Partner with IT and other Agile implementation stakeholders to guide the success of Agile

To help HR take the first step, here are some suggested Agile learning resources:

It’s time for HR to get off the sidelines and get in the game.  HR needs to be a “friend” to Agile, not perceived as a “foe”.

Borrowing from a Chinese proverb,

When the winds of change blow, some will build walls while others build windmills… the harnessing of your greatest natural resource, your people, into power.

Build windmills.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post How HR Can Save or Destroy Agile appeared first on Agile Advice.

Categories: Blogs

Certified ScrumMaster Training Workshop in Toronto—April 18-19

Notes from a Tool User - Mark Levison - Thu, 02/09/2017 - 01:01
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Toronto—April 18-19 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Certified ScrumMaster Training Workshop in Montreal—April 10-11

Notes from a Tool User - Mark Levison - Thu, 02/09/2017 - 00:51
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Montreal—April 10-11 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Predicting the Future (link)

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

I just read a great article Impressionism: Go ahead, try to predict life. You’ll fail

Enjoy!

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Predicting the Future (link) appeared first on Agile Advice.

Categories: Blogs

How a Non-Agile Big Corporation Lost Out

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

The Scenario

In a search for new vistas and growth, my husband had been scanning employment ads across the country and applied for a job he was well-suited for with a large corporation. He received two interviews by telephone and SKYPE. The new job would require us to move several provinces, leaving family, friends and a community we were attached to.

He received confirmation by telephone that the corporation wanted to hire him. We spent a few days agonizing over a decision, consulting with family and friends, praying about it, and decided my husband would accept the job. After his verbal acceptance, a contract followed a few days later, which he duly signed and sent back. He was told it had been signed at the other end and he could now announce the new job publicly.

He gave notice to his present employers, as did I mine, and we proceeded to take steps to put our house on the market, search for housing in the new city, and pack. We had begun to say good-bye.

Three days later a phone call came from the HR Department of the corporation saying they had to rescind the contract as someone “higher up” had not given approval for it.

We were stunned. There had been no hint in any part of the process that the job offer was in any way tentative or not thoroughly vetted. We had taken many steps forward, and now had to backtrack several steps.

My husband had to go, hat in hand, to his current employers to see if he could retain his job. After a painful good-bye session with my team I had to inform them that I was not leaving.

This whole experience has brought to mind the importance of what my employer, BERTEIG Inc, is attempting to do through agile training, consulting and coaching.

The “Agile Manifesto” proclaims:

“Individuals and interactions over processes and tools.”

And, further on: “Customer collaboration over contract negotiation.”

These are prime values to be lived by small and large businesses.

Admittedly, Agile was initially created for software developers, but more and more corporations and organizations are seeing the value in being agile, and are responding to this necessary change of culture in what is currently a time of deep disruption.

What If?

What if the corporation my husband was contracting with had honored the implications of “individuals and interactions over processes and tools” and “customer collaboration over contract negotiations?”

If some “higher up” had not actually given approval for this hiring, once the contract was signed at both ends (which it was), could this higher-up not have responded with more agility, more compassion, and more ethically?

What if he had acted in such a way that, even if he did not approve the contract, he acknowledged the good intentions of both sides and let it go? After all, his corporation was getting a highly-qualified, experienced employee.

What if he was transparent and acknowledged that the contract was not to his liking, and asked would my husband consider some other version of it? And then consulted directly with my husband and HR over certain changes to the contract? And made sure everyone was agreeable with the changes?

What if the “higher-up” just called my husband directly, apologizing that the contract was made without his say-so, that they were not in a position to hire him, and offered two-months salary for any damages – material and emotional – that had been incurred?

The above scenarios could have changed the situation from one of loss, to one of win-win for both sides. Agile frameworks are clearly proving to be of great benefit to employers and employees alike.

Hundreds of eager attendees take Certified Scrum Master and Certified Product Owner training from us. Many have taken our Certified Agile Leadership offering in cooperation with Agilitrix. Do the corporations they belong to welcome the changes these attendees are prepared to make? Are corporations taking steps to truly alter their culture?

The Losing End

My husband was almost employed in that organization, where hundreds of others are employed. I wonder how often their employees experience this type of trauma, since this neglectful handling of my husband’s contract is a likely sign of ongoing cultural problems within.

This rescinding of a contract was a losing situation on both ends. The corporation in question lost a highly-talented employee who would have been extremely loyal and hard-working (as was determined in the interviews). My husband lost professional credibility having to backtrack with his current employers. We lost the challenge of a new adventure.

We’re recovering, despite this having a huge emotional impact on our lives. We’ve been agile enough to say: we’re still here, we still have jobs, we can make the best of it all.

I just wish that Big Corp would get it. And soon. Before more is lost.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post How a Non-Agile Big Corporation Lost Out appeared first on Agile Advice.

Categories: Blogs

From Tasks to Stories with Value

Johanna Rothman - Wed, 02/08/2017 - 19:06

I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight.

I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur:

  • The technical people see the work they want to accomplish. They create a list of tasks to get there: design database, create infrastructure, fix these typos in the UI, and more.
  • Or, someone (such as an architect) is in charge of breaking down work, not team members. That person creates tasks.
  • Marketing or sales (or someone not in the product development team) says something like this: “I want a drop-down menu,” or a radio button or another report. They don’t remember to explain who the value is for, or why they want that value. Pretty soon, the idea of value is gone altogether, and only tasks remain.
  • Teams start to create stories, and the stories are so large, they create tasks to cover the stories. Pretty soon, they stop creating stories at all. They only create tasks.

Here’s a gotcha: When teams measure story points as opposed to features, they often feel pressure from management to do more points. (See Who’s Playing Agile Schedule Games?)

Your customers don’t buy points. They buy completed features.

Something clicked for the participant last week. He saw the feature chart, which explains how scope expands during the project and what the team(s) delivers.

This chart shows the features complete, added, and remaining to do. Because it measures features—what customers buy and use—there’s no confusion about work done or not done. Plenty of work might be done. But, if the work doesn’t add to a feature, the work is inventory (or possibly waste).

Here’s one value of this chart: Until tasks add up to features, you don’t count them.

My participant couldn’t articulate the problems before. The chart helped him see and discuss:

  • Tasks—by themselves—might not add up to a feature. He wants features.
  • When he counts features, he can describe what’s in a feature set—a collection of features that you might call an epic or a theme.
  • He can explain why he wants just this small feature, and not necessarily all of a feature set for now.

The chart helped him see how to separate stories and count them. He is moving from tasks and technical stories to features, real user stories.

I use this chart with cumulative flow diagrams and the product backlog burnup chart to see where our work is and how much progress we make over time for a given feature set.

I recommend you build and count features (stories). The smaller you can make a story, the faster you can get feedback and see the value in it.

If you’re interested in this workshop, I have just announced the May 2017 dates. See Practical Product Owner Workshop: Deliver What Your Customers Value and Need.

Categories: Blogs

The Canvas Strategy

I’m making my way through the Tim Ferris' book Tools of Titans. It’s well over 600 pages but it has a lot of useful, interesting advice, though I'll admit some of it is a bit out there. He breaks the book up into three areas; Healthy, Wealthy, and Wise. The book is really just a summary of podcasts done over the years with some other advice added in.
One piece of advice I appreciated is what he called the canvas strategy. The idea really came from Ryan Holiday. The name refers back to when apprenticeships were common; a budding  painter learns his craft by serving under a master and doing such things as preparing his canvas. 
In today’s terms it’s about serving the people you work for…sounds like servant-leadership! Some examples he gives includes ideas such as giving your boss an idea you came up with and not looking for credit or finding out the job no one else wants to do and taking it on yourself.

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Helvetica Neue'; color: #454545} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Helvetica Neue'; color: #454545; min-height: 14.0px}
This strategy will accomplish a number of things. It will keep your ego from getting to big.  As you make those around you successful, you will also become more successful; the adage "a rising tide lifts all boats." Finally, if you're feeding ideas to your boss, or coworkers, then you will start steering the direction they are going.
Categories: Blogs

Digging Into the “Works On My Machine” Problem

Derick Bailey - new ThoughtStream - Wed, 02/08/2017 - 18:12

Someone recently asked me why developers should care about the “Works On My Machine Problem”.

WOMM

While I can say that I implicitly know that this is bad, the question caught me off-guard.

I was able to provide a basic answer – needing to deploy applications to production, have coworkers be able to run our code in development, etc. – I realized I don’t have a strong answer for this question.

So I Did Some Research and I Found … Very Little.

It seems all the “Works On My Machine” blog posts and articles out there (at least, the ones I found after a few quick google searches) are focused entirely on the “how I solved <this WOMM instance> with <my favorite tool set>”.

There are few, if any, blog posts and articles that really hit the heart of why this statement is a problem, or the underlying issues that this statement is obscuring.

What I want, then, is a broad view of the situation.

  • What causes people to say “Works On My Machine”?
  • What are the problems that this statement hides or causes?
  • What kinds of solutions exist, to help fix or prevent this?
  • etc.

To that end, I put together a quick survey and I would love to get your input.

A Short Survey Of WOMM

If you’ve ever said “Works On My Machine!” to anyone, or had it said to you, take a few minutes and

Answer the Works On My Machine Survey

I’m planning to use the results as a blog post to start, but there will be other uses for the information. All of the questions are optional, as well.

The post Digging Into the “Works On My Machine” Problem appeared first on DerickBailey.com.

Categories: Blogs

Definition of Done

Leading Agile - Mike Cottmeyer - Wed, 02/08/2017 - 15:14

definition of done

Is it done, is it done done, or is it done done done?

I bet you’ve asked that question before, if you are in the business of application development.  When asking the questions, it is important to note who you are and your level in the organization. Delivery teams, program teams, and portfolio teams define done differently. For certain, we need is a clear definition of done at each level of the organization.

Definition of Done

The definition of done (DoD) is when all conditions (acceptance criteria) that a software product must satisfy are met, to be accepted by a user, customer, team, or consuming system.  We must meet the definition of done to ensure quality.  It lowers rework, by preventing user stories not meeting the definition from being promoted to higher level environments. It will prevent features not meeting the definition from being delivered to the customer or user.

User Stories

The most common use of Definition of Done is on the delivery team level.  Done on this level means the Product Owner reviewed and accepted the user story. Once accepted, the done user story will contributed to the team velocity.  Meet all of the defined criteria or the user story is not done.

The below examples might be included in the User Story DoD:

  • Unit tests passed
  • Code reviewed
  • Acceptance criteria met
  • Functional Tests passed
  • Non-Functional requirements met
  • Product Owner accepts the User Story
Features

Done on this level may mean it qualifies to add to a release.  Not all user stories need to be completed. Rather, it means the feature may be sufficient to satisfy the need. Once accepted, the done feature will contribute to the release velocity.  Meet all of the defined criteria or the feature is not done.

The below examples might be included in the Feature DoD:

  • Acceptance criteria met
  • Integrated into a clean build
  • Promoted to higher level environment
  • Automated regression tests pass
  • Feature level functional tests passed
  • Non-Functional requirements met
  • Meets compliance requirements
  • Functionality documented in necessary user user documentation
Epics

Done on this level may refer to a organizational strategic priority, portfolio plan item, or some other collection of features that satisfied a market need.  Not all user stories or features need to be completed. Rather, the epic may be sufficient to satisfy the need. Once accepted, the done epic will contribute to throughput calculations to see if the supply is in balance with demand.

The below examples might be included in the Epic DoD:

  • Non-Functional requirements met
  • End-to-end integration completed
  • Regression tests pass
  • Promoted to production environment
  • Meets defined market expectations
Summary

Just as the definition of ready is super important, so is the definition of done.  Never start work on something until you have agreed on the definition.  Be consistent. Be clear. Have a shared understanding.

The post Definition of Done appeared first on LeadingAgile.

Categories: Blogs

Impressions from Jfokus 2017: Internet of Things (IoT)

Dear Junior
The annual developer conference Jfokus is always an almost overwhelming source of impressions. There is always lots of interesting presentations, and today was no exception. It's impossible to cover all of them, but today I attended three presentations that together formed a nice whole as they covered different aspects of IoT - Internet of Things.
During the IoT keynote Kevin Hoyt went very down to earth. He covered the state of IoT devices today using different means of connectivity as his starting point. My main take-away was his very thorough coverage of each "typical" device for Bluetooth-, WiFi-, and GSM-connectivity. For each type he demoed the device, showed the development environment, and discussed programming concerns: for example the importance of entering deep sleep when working on a device using Bluetooth and powered by battery. Specifically I took away how the libraries have evolved to make connectivity and features like deep sleep and wake-up-on-connect.
The other presentation that fitted nicely into the topic was the presentation Shahid Raza of RI.SE (Research Institute of Sweden), formerly SICS (Swedish Institute of Computer Science) held under the title "Is IoT Security a Nightmare?". I simply assumed that the question was purely rhetorical, and had expected a "yes" with some elaborations on the subtler points. Boy, was I mistaken. The overarching message of the presentation was a resounding "no". In fact the current protocol stack for IoT has evolved a lot and now even support end-to-end security of communication, even when the data package has to make multi-hops from one device to another before ending up at its final destination. The protocols for doing this are essentially structured in the same way as we do with certificates and HTTPS over TLS. The largest surprise for me was that the computation power needed for cryptographic computation is not a problem. I was under the impression that the power needed for those computations would take too much of a toll from the batteries of battery-powered devices, but apparently not. The largest toll is apparently the radio-transmission of data packages. And, the protocol folks have worked hard to compress the protocol stack so that the overhead-parts of each package (delivery info and security) is compressed so that there is more room for the payload. In that way, fewer packages are needed for the same amount of payload, and that is where you conserve a lot of battery power.
The third presentation was on the just-released Bluetooth 5 standard and was held by Ioannis Glaropoulos. He presented how the new standard has increased throughput of Bluetooth to 2 Mbps, making it feasible for e g streaming audio, which makes the protocol useable for more use-cases. Counter to intuition this might actually decrease battery consumption because the same amount of data can be sent in a shorter amount of time, diminishing the risk of interferences and resending the data. So the amount of energy needed per byte sent might be lower. Bluetooth 5 also features a longer range. For indoor use the main advantage is simpler topologies: many devices can connect directly to a central node or gateway, instead of having to form a mesh where some devices need to route-forward messages from more distant devices. This also conserves energy for the intermediary devices that doesn't need to wake up to forward messages, but can stay in deep sleep until they have something they want to transmit.
Put together these three presentations definitely broadened and deepened my understanding of where Internet of Things stand today. Something that is a worth outcome of a day at a conference.
Yours
   Dan
Categories: Blogs

Influential Agile Leader, May 9-10, 2017

Johanna Rothman - Tue, 02/07/2017 - 18:41

Is your agile transition proceeding well? Or, is it stuck in places? Maybe the teams aren’t improving. Maybe no one knows “how to get it all done.” Maybe you’re tired and don’t know how you’ll find the energy to continue. Or,  you can’t understand how to engage your management or their management in creating an agile culture?

You are the kind of person who would benefit from the Influential Agile Leader event in Toronto, May 9-10, 2017.

Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your specific business challenges.

If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us.

We sold out of super early bird registration. Our early bird registration is still a steal.

If you have questions, please post a comment or email me. Hope to work with you at The Influential Agile Leader.

(See the servant leadership tag for the Pragmatic Manager  and the leadership tag on this blog to see relevant articles I’ve written before.)

Categories: Blogs

HBR:: Why Organizations Don't Learn

Agile Complexification Inverter - Tue, 02/07/2017 - 16:07
A nice article on HBR - "Why Organizations Don't Learn", by Francesca Gino and Bradley Staats; take a look.

They list these reasons:
  • Fear of failure
  • Fixed mindset
  • Over reliance on past performance
  • Attribution bias
The authors then give some strategies for overcoming these reasons for the lack of learning.  Many of these will be familiar to the agile community.

Who else has studied organization failure?  Well I've heard that many academics have studied the failure modes of organizations.  One was John Kotter's 8 Steps model developed by studying the failure modes of organizations trying to institute large scale changes.  Other's have studied how successful large mergers have been after the fact (some would suggest it's on the order of 20% successful).  Some have studied how successful large software development project have been (Chaos Report - it is not a good report).

So what does your leader do to encourage learning at the organizational level?  Is failure even allowed in your department?  If so then it will be discussed and talked about in formal settings and acknowledged by leaders, rather than only around the dark stairways and in hushed tones.

Leader's drive FEAR out of the room!


See Also:
Pitfalls of Agile Transformations by Mary Poppendieck
Knut Haanaes - Two reasons companies fail - TED Talk AND how to avoid them:  Exploration and Exploitation

4 Questions Smart Leaders Always Ask Employees to Improve Their Performance
They're also great for fostering open dialog and developing meaningful work relationships.

End of nations: Is there an alternative to countries?  Nation states cause some of our biggest problems, from civil war to climate inaction. Science suggests there are better ways to run a planet.
Categories: Blogs

Miyamoto Musashi on Lean and Agile

Leading Agile - Mike Cottmeyer - Mon, 02/06/2017 - 18:35

The legendary swordsman, Miyamoto Musashi, understood the Lean/Agile mindset perfectly 400 years ago.

Here is an excerpt from Musashi’s Book of Five Rings. Two translations are given, as each brings out different nuances of the original text.

Translation by Victor Harris. This translation is commonly available as a free download from many online sources, most of which do not credit the translator.

The gaze should be large and broad. This is the twofold gaze “Perception and Sight”. Perception is strong and sight weak. In strategy it is important to see distant things as if they were close and to take a distanced view of close things. It is important in strategy to know the enemy’s sword and not to be distracted by insignificant movements of his sword.

 
It is necessary in strategy to be able to look to both sides without moving the eyeballs. You cannot master this ability quickly. Learn what is written here; use this gaze in everyday life and do not vary it whatever happens.

Translation by Hidy Ochiai. I find this translation to be clearer, although in this case the translator does not explain the meaning of kan and ken (perception vs. sight). It’s published in the book, A Way to Victory: The Annotated Book of Five Rings.

Your eyes should be able to focus on a large and wide area. There are two kinds of seeing: kan and ken, the former being the most important and the latter less essential. In martial strategy it is crucial that you be able to keenly see objects at a great distance and that objects in close proximity be viewed with a broader perspective. In a combat situation, you must see your opponent’s sword in the context of his strategy as a whole rather than observing each physical movement.

 
It is important to be able to see on both sides of yourself without moving your eyes. You will not be able to do this suddenly in an emergency situation. You must try to cultivate this method of seeing in everyday life and maintain the same type of eye focus at all times.

The spirit of this advice is consistent with the saying, “Think globally and act locally.” We should apply craftsmanship and precision to each little thing we do, but without losing sight of the larger context in which the thing exists. This may be harder to do than it sounds. Most people I meet tend to be big picture thinkers or detail-oriented “do-ers,” and few are comfortable with both perspectives simultaneously.

In Ochiai’s analysis of Musashi, he notes:

Ordinarily one imagines that one’s mind-set when having a cup of tea is different from one’s mind-set in combat. Not according to Musashi. He feels that when one trains and disciplines the self physically and mentally according to the Way, the mind becomes calm and stable at all times, not preoccupied with any preconception or prejudice. This state of mind, which is attained after serious and hard training, Musashi calls heijo-shin. It is not the mental attitude of an ordinary person but of one who has gone through extraordinary training and self-discipline. The everyday mind of an ordinary person is not called heijo-shin, for it is not based on the true inner strength that can be attained only through a hard and authentic training.

 
I see many connections here. Connections with behaviors that I observe in the field. Connections with LeadingAgile’s pragmatic approach to organizational transformation. Connections to the mountain-climbing or “expedition” metaphor for driving organizational improvement.

The common element in these connections is expressed nicely by Musashi’s description of the warrior’s gaze. It comes down to a holistic perception of the small and the large, the near and the far, the immediate and the deferred, and the ability to maintain consistent focus on what is significant on all those axes.

Behaviors I observe in the field suggest this mindset is not so easy to cultivate. Tell-tale questions include:

  • “Whose job is it to refine the backlog?”
  • “As we combine technical job functions, who will test my code?”
  • “Why should I consider security issues in my design if they aren’t explicitly mentioned in the User Story?”
  • “How can we convince business stakeholders to give us permission to refactor our code?”
  • “If we’re tracking delivery performance by team, how do we assess individual performance?”

Questions such as these suggest the person sees but does not perceive; they see rules, and do not perceive meaning. They have not cultivated heijo-shin.

In all these cases, and countless others, people are considering one specific job-related task in isolation from its larger context, and they are hoping to find a recipe to dictate what they must do in every situation that may arise. The “task” may be of relatively large scope—something the CTO does, or something a Portfolio-level team does—or of relatively small scope—something an individual programmer or tester does—but there is always a single, overarching organizational context, and it is within that context that people make judgments about what to do from one minute to the next throughout the day. It isn’t a question of rules, although you might benefit from a few rules initially to help you find the path forward.

Such questions would not occur to a person who had cultivated heijo-shin. They would perceive the whole and do the right thing in context naturally, without strain. But cultivating heijo-shin is a challenge that requires mindful practice. Musashi is clear on this point: Reading isn’t enough; you must apply the ideas. Whatever you practice every day is what you will do when the heat is on. Therefore, it’s important to practice the right things. How does one know what to practice? With guidance and a compass, you can find the right path.

LeadingAgile’s approach takes into account three levels of abstraction in the organization, which we call Portfolio, Program, and Delivery Team. Each has its own broad set of responsibilities and scope of work, but all are part of a single cohesive whole. One can view this as an example of Musashi’s notion of perceiving the near and the far in a spatial sense. What we do at the Delivery Team level is part of what we are doing at the Program and Portfolio levels. What we do at the Portfolio or Program level must be done in a way that doesn’t impede Delivery Teams. Each task must be done with high quality but does not exist in isolation.

The LeadingAgile roadmap, which is based on the expedition metaphor, comprises five Basecamps. These represent milestones of improvement. One can view this as an example of Musashi’s notion of perceiving the near and the far in a temporal sense. What we do on the journey from Basecamp 1 to Basecamp 2 will set us up for reaching Basecamp 3 in the future, and Basecamp 4 after that. Each Basecamp is a milestone but not an end state. The real end state is that people no longer think in terms of an “end state” at all, and instead they practice continual improvement as a habit.

The post Miyamoto Musashi on Lean and Agile appeared first on LeadingAgile.

Categories: Blogs

The Critical Role of the SAFe Program Consultant (SPC)

Agile Product Owner - Mon, 02/06/2017 - 16:16

SPC_role

The success of any kind of social epidemic is heavily dependent on the involvement of people with a particular and rare set of social skills.
—Malcom Gladwell, The Tipping Point

Outside of an SPC class we probably don’t emphasize this enough, so let me state it here. SPCs are as essential to a successful SAFe implementation as your lungs are to breathing. They are that important when it comes to the transformation.

If you read this blog, you’ve probably noticed that we like to share our SAFe case studies which report some impressive results. On the surface, we’re showcasing improvement metrics. But what we’re actually demonstrating is what can be accomplished when some truly dedicated people work together toward a common vision, following the principles and practices of SAFe. Behind each case study is a coalition of SPCs—sometimes as few as one or two, sometimes many more—who are driving and communicating that vision. Even more importantly, they have the knowledge needed to actually implement the change.

If you’ve been reading our recent SAFe Implementation Roadmap article series, you’ll notice that we often refer to John P. Kotter’s “sufficiently powerful guiding coalition” as the force behind achieving meaningful and lasting change, and the role that the SPC plays in establishing that coalition.

To help you understand more about what it means to be an SPC, we’ve created a new guidance article that takes a deeper dive into their responsibilities in SAFe, a short discussion on how many SPCs are needed to drive and sustain an implementation, and what’s involved in training an SPC.

Read the SPC article here. You can also find out more about SPC certification, and the calendar of public classes here.

A personal thanks to the 4,000+ certified SPCs who are in the field, working hard to improve developers and end users lives, every day. You continue to be an inspiration to all of us at Scaled Agile, and drive us to do our best to relentlessly improve the Framework. After all, without you, SAFe is just a website.

Stay SAFe!
—Dean

Categories: Blogs

Agile Leadership Training

Notes from a Tool User - Mark Levison - Fri, 02/03/2017 - 04:52

cal_banner_960x260

-->

Agile Pain Relief Agile Leadership Training — Giving leadership and management the tools and techniques to enable Agile within their organization

With the growing adoption of Agile, there is a need for a holistic approach for organizations to employ Agile throughout all aspects of business, rather than within specific teams. Expanding Agile methods from their traditional applications as development or product management tools into all areas of the organization requires a new set of skills in the management suite: Agile Leadership. Agile Leaders and Agile Leadership empower their organization from the top down to:

  • Instill and practice Agile values, methods, and metrics at the organizational level
  • Enable teams to deliver more customer value
  • Remove barriers to team success
  • Foster creative solutions

This three-day, hands on course led by Certified Scrum Trainer (CST) Mark Levison is targeted towards leaders, influencers, and managers within organizations that employ — or are planning to employ — Agile. Participants will learn core Agile concepts, processes, and practices, and how Agile can be used as a tool for organizational change to increase productivity and improve employee and customer satisfaction.

The Agile Pain Relief Advantage Small Class Size in Your City Agile Pain Relief limits class sizes to ensure a high quality learning environment with more opportunities to address your questions and concerns. Local training classes mean you meet and network with other professionals near you. On-site, private training also available. In-person and Interactive Direct learning tailored to each class and student. No canned PowerPoint presentations or webinars. Live instruction from Certified Scrum Trainers (CST) and group exercises modelled on Agile methods. Hands-on Applications of Scrum Methods with Agile Theory Practical examples and exercises using Scrum and Agile principles teach you how to adapt and practice Agile methods in your projects. Online Course Materials and Support Course attendees receive electronic copies of all seminar materials (including free updates to course materials as they become available) and exclusive access to Mark through Agile Pain Relief’s LinkedIn group.

*Certification Pending
** Courses available Q1 2017

Categories: Blogs

LeanAgileUS 2017

AvailAgility - Karl Scotland - Thu, 02/02/2017 - 17:58

Lean Agile US

LeanAgileUS is taking place in Fort Lauderdale, Florida on February 27-28th. It has a real mix of great speakers and content, covering all aspects of Lean and Agile including Scrum, SAFe, Kanban, DevOps amongst other topics. I expect it to be an event where people come together for dialogue about different perspectives. I hope to hear more of “That’s interesting, tell me more” and less of “That’s wrong, and here’s why“.

My contribution will be twofold.

Firstly I have a talk on the Monday entitled “Good Agile / Bad Agile: The Difference and Why it Matters”, which you may recognise as the title of a recent post. I will be exploring some of those ideas in more detail. Here’s the abstract:

Stories of Bad Agile are common, where Agile is a local and tactical implementation, resulting in failed projects and initiatives. Businesses don’t get the results they had hoped for and Agile gets the blame for not working. Good Agile, however, is possible when it is directly and explicitly related to a business strategy. Thus Agile needs to be deployed strategically, with a clear diagnosis of the critical problem or opportunity faced, guiding policies on the approach to addressing the diagnosis, and coherent actions to implement the guiding policies. This talk will show how this approach can lead to Good Agile which is evolved through experimenting as opposed to Bad Agile being instantiated by copying.

Secondly I have a half day workshop on the Tuesday entitled “Enterprise Agility with Strategy Deployment”. This will be an opportunity to learn more about the X-Matrix, experience the process of creating one, and understand how to use it alongside other A3 templates. Here’s the abstract:

Strategy Deployment is a style of organisational improvement that engages the entire workforce in figuring out how the business can survive and thrive. This course will introduce Strategy Deployment using a framework called the X-Matrix – an A3 format which concisely visualises the alignment of results, strategy, indicators, and tactics on a single sheet of paper. With this approach, a transformation can be viewed as a form of Catchball, a Lean process where ideas are passed around an organisation as teams collaborate to experiment and discover solutions. In this way, solutions emerge from the people closest to the problem, rather than being defined and dictated by management.

The whole event is great value for money. Register soon as I’m sure it will sell out!

Categories: Blogs

Refactoring Towards Resilience: Evaluating SendGrid Options

Jimmy Bogard - Thu, 02/02/2017 - 17:26

Other posts in this series:

In the last post, we found we had the full gamut of options for coordinating our distributed activity:

Coordination Options

We could ignore the failure (and have money floating in the ether), retry using an idempotency key, undo via a refund, or coordinate using the auth/capture flow Stripe provides. That's quite helpful that we have so many options available, it lets us be flexible in our approach. Part of this is the design of the Stripe API, and part is just the nature of payments.

SendGrid, a service to send email, naturally won't have as many options. The purpose of SendGrid is to send emails when you call their API, and to send that email as quickly as possible. You shouldn't call their API unless you want an email sent. With this in mind, let's look at our coordination options.

Ignore

With Stripe, the Ignore option wasn't really viable. We need to charge customers, but we don't want to charge them twice. With an email notification, it's not necessarily as critical.

In our original code, any SendGrid failure caused my entire process to fail:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

But what if it doesn't have to be this way? Does a SendGrid failure really need to take my entire payment process down? Should I not take people's money because I can't send them an email? Maybe not! The simplest approach would be just to ignore (and log) failures:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    try {
        await sendGridService.SendPaymentSuccessEmailAsync(order);
    } catch (Exception e) {
        Logger.Exception(e, $"Failed to send payment email for order {order.Id}");
    }
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

We'd still want to send emails, but we can be notified of these exceptions and have some manual (or automated) process to retry emails.

Retry

Unlike Stripe, SendGrid does not support any sort of idempotency in requests. This is intentional on their part, they want to send emails as soon as possible and introducing any sort of idempotency check would introduce a delay in the send.

All this means that Retrying a SendGrid call would result in two emails sent. Is this acceptable? Probably not - if I received two "payment successful" emails, I would rightly freak out and assume my card was charged twice.

Fundamentally, my emails are SMTP, another messaging protocol, which just doesn't support something like idempotent Retry. If I wanted true retries, I would need to build a resiliency layer on top of sending emails, something that SendGrid (and most email service providers I can think of) do not do.

No retries.

Undo

Similar to Undo, there's really no such thing as "undoing" an email sent. Perhaps a follow-up email "ignore that last email", but that's about it.

SendGrid does however support scheduling emails in a batch with an ID, and cancelling a batch. However, there are limitations to batches sent, and batches are as the name implies a means to send a bunch of emails at a time in a batch.

I don't really want to be tied to scheduling a batch of emails together, as the customer expectation is to get an email relatively soon after send, and I can't create a batch for every single email.

No undos.

Coordinate

Similar to Retry, there's really no facility to coordinate an email send with some sort of two-phase commit process. I'd have to build something on top of calling the SendGrid API to coordinate this action.

No coordination.

So where does that leave us? In our current state, we can either Retry or Ignore. Neither are great solutions, but we'll come back soon on better ways to tackle this problem with messaging.

Next up, RabbitMQ failures!

Categories: Blogs