The Retro Game

The Hunt for Better Retrospectives

The rumours had started to spread, retrospectives at our organization were flat, stale and stuck in a rut. The prevailing thought was that this was stalling the pace of continuous improvement across our teams. In truth, I wasn’t sure if this was at all true, it’s a complex problem that has many possible contributing factors. Here are just some possible alternative or co-contributing causes: how the teams are organized, the level of safety, mechanisms to deal with impediments across the organization, cultural issues, levels of autonomy and engagement, competence & ability and so on…

Despite this, it didn’t hurt to have a look for some inspiration on good retrospectives. I really liked Gitte Klitgaard’s talk called Retrospectives are Boring and Useless – Or are They? In particular the parts around preparing and establishing safety.

On the theme of safety, I thought we could try to go as far as having fun; we’d already had lots of success with the getKanban game (oh Carlos you devil!). Where it all tied together for me, was being inspired by the great question-based approach from cultureqs.com that I’d had a chance to preview at Spark.

If I could create a game with the right prepared questions, we could establish safety, the right dialogue and maybe even have some fun.

The Retro Game

This is a question-based game that I created that you could use to conduct your next retro for teams of up to 10 people. The rules of the game are fairly simple and you could play through a round or two in about 1 to 2 hours depending on team size and sprint duration. Prep time for the facilitator is about 2-4 hours.

theretrogame

Prepping to play the game

You, as facilitator, will need to prepare for 3 types of questions that are thought of ahead of time and printed (or written) on the back of card-stock paper cards.

One question per card. Each question type has its unique colour card. About 8 questions per category is more than enough to play this game.

The 3 types of questions are:

In the Moment – These are questions that are currently on the mind of the team. These could be generated by simply connecting with each team member ahead of time and asking, “if you could only talk about one or two things this retro, what would it be?” If for example they responded “I want to talk about keeping our momentum”, you could create a question like “what would it take to keep our momentum going?”

Pulse Check – These are questions that are focused on people and engagement. Sometimes you would see similar questions on employee satisfaction surveys. An example question in this category could be “What tools and resources do we need to continue to be successful?”

Dreams and Worries – This is a longer-term view of the goals of the team. If the team has had any type of Lift Off or chartering exercise in the past, these would be questions connected to any goals and potential risks that have been previously identified. For example if one of a team’s goal is to ship product updates every 2 weeks, a question could be “What should we do next to get closer to shipping every 2 weeks?”

On the face-up side of the card it should indicate the question type as well as have room to write down any insights and actions.

You will also need:

  • To print out the game board
  • To print out the rule card
  • Bring a 6-sided dice

Playing the Game

Players sit on the floor or at a table around the game board. The cards are in 3 piles, grouped by type, with the questions face down.

therules

  • The person with the furthest birthday goes first.
  • It is their turn and they get to roll the dice.
  • They then choose a card from the pile based on the dice roll. A roll of 1 through 3 is an “In the Moment” card, 4 is a “Pulse Check” and 5 to 6 “Dreams & Worries”
  • They then read the card question on the card out loud and then pass the card to the person on the right.
    • The person on your right is the scribe, they will capture notes in the Insight and Actions boxes of the card for this round.
  • Once they have read the question, they have a chance to think and then answer the question out loud to the group. Nobody else gets to talk.
  • Once they’ve answered the question, others can provide their thoughts on the subject.
  • After 3 minutes, you may wish to move on to the next round.
  • At the end of each round the person whose turn it was chooses the person who listened and contributed to the discussion best. That person is given the card to keep.
  • The person to the left is given the dice and goes next.

Winning the Game

  • The game ends at 10 minutes prior to the end of the meeting.
  • At the end of the game, the person with the most cards wins!
  • The winner gets the bragging rights (and certificate) indicating they are the retrospective champion!
  • You should spend the last 10 minutes reflecting on the experience and organizing on the action items identified.

Concepts at Play

players-playing

Context & Reflection – Preparation is key, particularly for the “In the Moment” section. The topics will be relevant and connect with what the team wants to talk about. Also when presented in the form of a question they will likely trigger reflection for all those present.

Sharing the Voice – Everyone gets a chance to speak and be heard without interruptions. The game element also incentivises quality participation.

Coverage of topic areas – The 3 question categories spread the coverage across multiple areas, not just the items in the moment. The probabilities are not however equal, for example there is a 50% chance of “In the Moment” being chosen in each turn.

Fun & Safety – The game element encourages play and friendlier exchanges. You are likely to have dialogue over debate.

Want to play the game?

I’d love to hear how this game worked out for you. I’ve included everything you need here to setup your own game. Let me know how it went and how it could be improved!

Resources:
Retro Game – Game Board
Retro Game – Rules
Retro Game – Card Template
Retro Game – Champion Certificate

Martin aziz

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

Business vector designed by Freepik

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Sometimes Waterfall is Needed to Become Agile, Scott Granieri

I like reading success stories. In fact, I wish there were more of them in the agile literature because a success story is “evidence” of doing something that works and it is not just an abstract idea or concept with potential. That’s one of the reasons I like Scott Granieri’s article featured on scrumalliance.org entitled, “Sometimes it just may take a waterfall to go agile.” In this article, Granieri describes a situation occurring at a corporate level to create software for a federal customer. He presents the background, the problem, the solution, the results and the lessons learned. I find this article to be well-written, thorough and engaging.

Here is an excerpt from his conclusion:

“The solution for creating a successful environment for Agile adoption lies within one of the principal tenets of the methodology itself: Inspect and adapt.” He also quotes Ken Schwaber, co-founder of Scrum, who Mishkin Berteig trained with more than a decade ago. But that can be something for you to discover when you read the article.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Craig Larman – Less Agile or LeSS Agile?

Certified Less Practitioner Badge

Craig Larman, co-creator of LeSS, recently wrote a riveting article about agility now featured on Scrum Alliance Spotlight. The article, entitled “Less Agile or LeSS Agile?” reminds readers of the beginning moments of agile and how this word was selected because it fundamentally described a condition of being able to adapt quickly to change.

About that founding meeting, he quotes Martin Fowler as saying, “We considered a bunch of names, and agreed eventually on “agile” as we felt that captured the adaptiveness and response to change which we felt was so important to our approach.” Larman continues to elaborate on how this agility is not meant to be a practice solely for the purpose of “creating more efficient teams who deliver high-quality faster,” although of course this is a natural outcome when teams are agile.

But he takes the concept to a deeper level. He writes, “I like to say that the goal of agile approaches, including Scrum, is to discover successful solutions by being able to … turn on a dime for a dime.”

Therein lies the beauty of being agile. When we are discovering successful solutions and implementing them quickly, even with very little planning, then we are embracing the fundamental essence of agility.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Breaks Between Sprints Indicate a Problem

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

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

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

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


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Splitting User Stories

A common challenge faced by inexperienced Scrum teams is related to splitting user Stories (in Scrum, Product Backlog Items or PBIs) so that they are granular enough for development. The INVEST model is a good way to test whether user stories are well-written.

  • I – Independent
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

Independent – Each user story must be independent of each other. This prevents any overlap between the items; moreover, it allows the team to implement them in any order.

Negotiable – The details of the work must be negotiable, both among the stakeholders and the team. Specific requirements and design decisions will be fleshed out during development. Many agile practitioners recommended writing user stories on a note card — this is intentional so that a limited amount of detail can be prescribed.

Valuable – Each user story must add business value to the product, the customer and/or the users’ experience.

Estimable ¬– A good user story can be understood well-enough by the team that they can estimate it — not accurately — but at a high-level they perceive that it has size. It is helpful to understand the relative effort as compared to other user stories.

Small – A user story is not small if the team cannot get it done within a single Sprint. As large user stories are split into smaller items, greater clarity about the size and implementation is achieved, which improves the likelihood that the team will get it done within a Sprint.

Testable – Each user story should be testable; this is a common characteristic of well written requirements. If the team cannot determine how the user story may be tested, it is an indication that either desired functionality or the desired business value is not clear enough.

Vertical vs Horizontal Splitting

There are two common ways to split user stories: vertically or horizontally. Horizontal breakdown of user stories splits the item at an architectural component level. Example: front end UI, databases or backend services. Whereas, a vertical slice results in working, demonstrable, software which adds business value. Therefore, it is recommended to slice user stories vertically so as to reduce dependencies and improve the team’s ability to deliver a potentially shippable product increment each sprint.

Splitting User Stories Example

As a customer I can pay for my order so that I receive the products

If the above user story was to be split in a vertical manner, it might be broken down into the various ways a customer can complete a payment. As follows…

As a customer I can make a credit card payment for my order so that I collect reward points on my credit card.

And/or

As a customer I can make a PayPal payment for my order so that I can securely complete my purchase without sharing credit card details with another retailer.

The key point to note in the vertically sliced user stories above is that each story passes the INVEST tests mentioned earlier and therefore a Product Owner can prioritize these user stories based on customer needs. However, if a horizontal approach was used to split the user story (i.e. split by architectural layers and components) then the implementation of such requirements would result in working functionality only when all horizontal components are eventually integrated.

Breaking down by Workflow

Another approach that is commonly used to breakdown user stories is focused on the individual steps a user may take in order to achieve their end goal — that is, a user story which describes a long narrative or “user flow” through a system may be sliced into steps which represent portions of the user’s flow. Continuing from the example above of a customer making a purchase online, the user story can be broken down into the following:

As a customer I can review the items being purchased for my order so that I can be confident I’m paying for the correct items.

As a customer I can provide my banking information for my order so that I can receive the products I ordered.

As a customer I can receive a confirmation ID for my purchase so that I can keep track and keep a record of my purchase.

Other Methods

There are many other methods that can be utilized to breakdown larger user stories such as:

  • Breaking down by business rules
  • Breaking down by happy / unhappy flow
  • Breaking down by input options / platform
  • Breaking down by data types or parameters
  • Breaking down by operations (CRUD)
  • Breaking down by test scenarios / test case
  • Breaking down by roles
  • Breaking down by ‘optimize now’ vs ‘optimize later’
  • Breaking down by browser compatibility

Kudos to this article for inspiring the list above: blog.agilistic.nl.

Other Helpful Resources

The Hamburger Method
User Stories and Story Splitting at AgileAdvice.com


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Succeeding with your Agile Coach

 

I recently said goodbye to one of my organization’s Agile Coaches and I felt that I needed to take a pause and reflect to consider my next move. The engagement had gone well, in fact one of the best we’ve had, but not without its share of successes and failures. But the successes had clearly outpaced any failures, and so there was a lot of good I wanted to build on.

The departing coach was part of a 3rd generation of Agile Coaches that I had worked with in the 3 years since we had begun our company’s transformation to Agile. And while he was a great coach, so were his predecessors and yet they had had fewer successes.

On reflection, what had really happened is that we had changed as a company; we had learned how to better execute our engagements with an Agile Coach.

Deciding to hire an Agile Coach.

Deciding to hire an Agile Coach can be a big step. A couple of things need to have happened, you’ve recognized that you need some help or at least another perspective. And given that Agile Coaches are typically not very cheap, you have decided to invest in your Agile transformation, however big or small. You’re clearly taking it seriously.

However, through my experiences I noticed that things can get a little tricky once that decision has been made. Many organizations can fall into a trap of externalizing transformation responsibilities to the Agile Coach.

In essence thinking along the lines of “as long as I hire a good coach, they should be able to make our teams Agile” can take you into an engagement model that is not very Agile in the first place.

Much like how Scrum and other Agile Practices connect customers with teams and establishes shared risk, an organization’s relationship with their Agile Coaches need to be a working partnership.

Figure1

Positive Patterns for Coaching Engagements

So it’s important for you to setup the right engagement approach to get value out of your Agile Coach and this goes beyond the hard costs of their services, but also the high cost of failure with not having the right coaching in the right areas.

Here are 5 positive patterns for coaching engagements that I’ve observed:

1. Identify the Customer

Usually it is management who will hire a coach, and they may do so to help one or more teams with their Agile adoption needs. So in this scenario who is the customer? Is it the person that hired the coach or the teams (the coachees) who will be receiving the services? In some cases, the coachees aren’t clear why the coach is there, they haven’t asked for their services and in some cases may even feel threatened by their presence.

For this reason, if management is hiring coaches you need to recognize that there is a 3-pronged relationship that needs to be clearly established and maintained.

Figure2

With the customer in this case being someone in management, i.e. the person who hired the coach in the first place. The customer’s responsibility will be to not only identify the coachee but then work with the coach to establish and support that relationship.

2. Set the Mandate

Agile Coaches typically tend to be more effective when they have one or two specific mandates tied to an organization’s goals. Not only is the mandate important to establish why the coach is there, too many goals can significantly dilute the coach’s effectiveness. Put another way, Agile Coaches are not immune to exceeding their own Work in Progress limits.

The mandate establishes why the coach is there, and should be tied to some sort of organizational need. A good way of developing this is to articulate what is currently happening and the desired future state you want the coach to help with.

For example:

The teams on our new program are great at consistently delivering their features at the end of each sprint. However, we still experience significant delays merging and testing between teams in order for the program to ship a new release. We’d like to reduce that time significantly, hopefully by at least half.

Once the engagement is well underway you may find that the coach, through serendipity alone, is exposed to and gets involved with a wide variety of other areas. This is fine, but it’s best to just consider this to be a side show and not the main event. If other activities start to take on a life of their own, it’s probably a good time to go back to inspect and potentially adjust the mandate.

If you’re not sure how to establish or identify your Agile goals, this could be the first goal of any Agile coach you hire. In this scenario, the customer is also the coachee and the mandate is to get help establishing a mandate.

3. Hire the Coach that fits the need

Agile coaches are not a homogeneous group, with many degrees of specialty, perspective and experiences. Resist the desire to find a jack-of-all-trades, you’re as likely to find them as a unicorn.

Your now established mandate will be your biggest guide to what kind of coach you should be looking for. Is the need tied to technical practices, process engineering, team collaboration, executive buy-in, transforming your culture, etc?

The other part is connected with the identified coachee. Are the coachees team members, middle management or someone with a “C” in at the start of their title? Will mentoring be required or are you just here to teach something specific?

Using something like ACI’s Agile Coaching Competency Framework, would be a good model to match the competencies required of the perspective coach.

In my example earlier, in order for your team to get help with their merging & testing needs, you may have to look for a coach with the right skills within the Technical Mastery competence. And if you have technical leaders who are championing the change, potentially the ability to Mentor.

Figure3

4. Establish Feedback Loops

With the coach, customer and mandate clearly identified, you now need to be ready to devote your time to regularly connect and work with the coach. Formalizing some sort of cadence is necessary, if you leave it to ad hoc meetings you will typically not meet regularly enough and usually after some sort of failure has occurred.

The objective of these feedback loops is to tie together the communication lines between the 3 prongs established: the customer, the coach and the coachees. They should be framed in terms of reviewing progress against the goals established with the mandate. If the coachees ran any experiments or made any changes that were intended to get closer to the goals, this would be the time to reflect on them. If the coachees need something from the customer, this would be a good forum to review that need.

Figure4

Along with maintaining a cadence of communication, feedback loops if done regularly and consistently, could be used to replace deadlines, which in many cases are set simply a pressure mechanism to maintain urgency. So statements like “Merge & test time is to be reduced by half by Q2” now become “We need to reduce merge and test time by half and we will review our progress and adjust every 2 weeks.”

5. It doesn’t need to be Full Time

Resist the temptation to set the coach’s hours as a full-time embedded part of the organization or team. While you may want to have the coach spend a significant amount of time with you and your coachees when the engagement is starting, after this period you will likely get a lot more value from regular check-ins.

This could look like establishing some sort of rhythm with a coachee: reviewing challenges, then agreeing on changes and then coming back to review the results after sufficient time has passed.

This approach is more likely to keep the coach as a coach, and prevents the coach from becoming entangled in the delivery chain of the organization. The coach is there to help the coachees solve the problems, and not to become an active participant in their delivery.

Time to get to work

Bringing in an Agile Coach is an excellent and likely necessary part of unlocking your Agile transformation. However, a successful engagement with a coach will have you more connected and active with your transformation, not less. So consider these 5 positive coaching engagement patterns as I consider them moving into my 4th generation of Agile coaches. I expect it will be a lot of work, along with a steady stream of great results.

Martin aziz

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What do we Mean by Transformation?

IMG_8956

From the Scrum Alliance Orlando Conference ”Open Space” Discussion, April 2016, facilitated by Valerie Senyk

Transformation is a big word that Scrum/ Agilists use. It is what we promise our customers through training and coaching.

On the last day of the Scrum Alliance Conference during the Open Space forum, I posed the question: “What is transformation? What do we mean by it?” We had forty-five minutes to try and understand this issue.

Initially, discussion centered around the idea of change and some of the manifestations of change. However, it was pointed out that transformation requires more than a methodology we follow. In fact, it’s more of a way of thinking.

It is easy to say what transformation is NOT: it is not rigid, not prescriptive, not directive. It is about different ways of behaving, it is supportive, and requires a new mindset from being prescriptive to adaptive.

I asked if the participants saw themselves as agents of transformation. Almost everyone did. So, what do they do? And how do they do it?

Participants spoke of the need for greater knowledge and education around Agile, as well as the need to understand stakeholders. To be an agent of transformation is about enabling people, and to enable them we need to understand them.

One commented that when an organization experiences pain, that is an opportunity to go in as an agent of transformation and use that pain as a motivation and means to change.

Transformation is not a one-time event; it requires continuous learning. In order to have continuous learning, agents must create a safety net for innovation to occur. The mindset must be that failure is okay. Trust in the process and in the agent (agilist) is necessary for discovery.

It was understood we can achieve transformation at a surface level to begin with, but true transformation occurs at a personal level. How is it possible to achieve this deeper level?

One participant spoke about the need for love, for truthfulness and for transparency to be part of a personal-level transformation. As a member of the BERTEIG team, I know that love, truthfulness and transparency are integral to how we work, and how we deliver services.

Ultimately, there is a difference between change and transformation. Change means one can go forward but then step backward. Change is not necessarily permanent. But transformation is really about irreversible change! And small transformations are steps to larger ones.

Discussion then centered on what motivates transformation. Behavioural change needs to be felt/ desired at a visceral level. Organic analogies were suggested to help educate and motivate – that in the natural world we see constant development and change. Why would we be any different?

The question was posed: What do we transform to? People need to be shown the beauty of the next step…beauty in itself becomes a motivation.

Is it enough to help change an organization or corporation to run beautifully and smoothly within itself? Or is there a higher purpose to transformation?

One attendee spoke about how all the cells in the body work autonomously for a higher purpose, which is the functioning of a human being.

In business also, transformation can also be pursued for a higher purpose. Imagine a corporation transitioning from pursuing purely monetary rewards to its pursuit being about making a positive contribution to society. It was pointed out that studies show that companies with a higher purpose actually have higher revenue.

However, it was also expressed that everything that matters in life cannot be measured.

We concluded the session with the idea that transformation requires looking outward as well as inward. It’s not just about us and our customers – it’s ultimately about creating social good.

I have been grappling with the idea of transformation for many years, from the viewpoint of the spiritual as well as that of an artist. Hearing the ideas and understanding of the twenty-plus people who attended this session helped me see that transformation on a larger-scale requires patient but strongly-motivated steps toward an ideal that may seem intangible to some, but is worth every moment in pursuing. For it is in the pursuit of the best ways over the better that transformation is wrought.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What You Need To Know About Disruption

This information was presented by John Hagel in a Scrum Alliance webinar, April 12, 2016. These are my notes plus a few thoughts.DSC_0616.

The idea of Disruption in business was popularized in ‘97 in a book by Clayton Christensen. What is disruption? It occurs when most of the leading incumbents (in business, politics, technology, etc) are displaced by a new approach that is challenging to replicate. Disruption can usually be quickly seen in a change in economic factors or a change in mindsets.

There are 5 aspects of disruption to be aware of:

1. it’s happening across every industry

2. well-managed firms don’t make you safe from disruption

3. most firms/ businesses did not see it coming, i.e. newspaper industry

4. disrupting companies are not themselves immune from disruption

5. there are multiple-patterns or inter-related patterns of disruption

Most companies focus on their high-value estimates; their low-value customers don’t seem to be a threat. But as low-value items or services steadily improve, we see high-value customers shift to that. Firms must become Agile and be able to adjust on-the-fly to new technologies; they should not focus on adding improvement just to high-value things.

John Hagel clarified that disruption is a universal phenomenon – “the story of the century.” Many companies are not weathering the storm. The average life of a leading company in the ‘50’s was 62 years – now it is 18 years.

This is due to a fundamental shift in value creation, whereby consumers are gaining more power with more information and options, and knowledge workers are gaining more power in that talent has greater visibility, and higher wages can be continually demanded.

Hagel’s research shows that there are patterns that can act as lenses through which disruption can be viewed. The first pattern relates to the transformation of value and economics. For example, the digital camera became a huge disruption to the photography industry, but now itself has been disrupted by the ability to embed digital cameras in cellphones. The second pattern relates to “harnessing network effects;” the more participants that join, the more value is created. This pattern is more enduring and challenging to disrupt.

In your industry, what would you look for to understand market vulnerability? Would it be through product pricing, product modularity, demand characteristics, or supply constraints? If you assess your industry, which catalysts are the most important to understand to deal with disruption?

My personal thought is that, given the organic nature of the world’s systems, whatever disruptions are trending in the world around us, sooner or later they will have an effect on most businesses and organizations.

Disaster can be staved off by becoming more Agile in your organization. Agile will help everyone respond more quickly and with flexibility to disruptions. In fact, Agile itself has become a disruptive factor for outmoded ways of doing business.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

ProjectWorld Workshop: From Project to Product

This week we sponsored ProjectWorld in Toronto. Tons of people stopped by our booth and shared their experience with us.

As well as meeting many old friends and new potential clients/collaborators, Mishkin presented a symposium to dispel the myths of Agile work and Gerry, Travis, and I facilitated a workshop called “From Project to Product: Agile Delivery Models”.

Many people in our workshop asked that I share the slide deck so please download it here. Feel free to share with others!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Promotional: Video About our Agile Training

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

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

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


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

When Will Executives Step up to the Plate?

Hundreds of Canadian employees from corporations, businesses and organizations are attending training to become Certified ScrumMasters and Certified Product Owners under the aegis of the Agile umbrella. From testimonials received from almost all attendees, they are enthusiastic about this training. As many have written, the training is helping them think beyond the status quo, and they are excited!

They return to their workplaces, report to their managers, talk amongst themselves – and then what happens? Nothing. Nothing changes. Their learning, their positive motives to enact change, their hopes slowly dissipate in the face of ignorance and apathy.

Where’s the disconnect?

It seems the disconnect belongs to the executives. CEO’s, VP’s, upper management have been avoiding a work revolution happening right under their noses. The revolution began in 1998 with the creation of the Agile framework, resulting in the Agile Manifesto, http://agilemanifesto.org, written in February of 2001 by seventeen independent software practitioners.

Not only has Agile transformed software creation, but it has been proven to be of value for all areas of business enterprises and organizations beyond software and IT departments.

Are executives remaining willfully ignorant of a twenty-first century framework for creating more fulfilling workplaces and delivering greater value to their customers? Or will Executives learn what is happening at the grassroots and make changes to fulfill the hopes of employees?

This is a call to action. It is time for executives to step up to the plate.

Real testimonials about training can be found at http://www.worldmindware.com/CertifiedScrumMaster


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

ScrumMaster or Armchair Psychologist? – Notes from a Webinar by Angela Johnson

Valerie Senyk

March 9, 2016, I took advantage of a free webinar offered by the Scrum Alliance, with the above title. We were told 5,000 people were attending! Angela Johnson’s presentation was based on information from both the Scrum and psychology communities.

First, she reiterated many ideas that are commonly understood about the role of a ScrumMaster (SM): an internal coach, a servant leader, an active facilitator. The SM makes sure that the rules of Scrum are followed by a team, but focuses on interactions and outcomes. As in football, the SM is truly a coach.

She described how new SM’s often latch onto the mechanics of Scrum, but most important are the personal interactions of a team. When difficulties arise, it is important to ask: “Do we have a Scrum problem, or is it a people problem?”

Ms. Johnson cited two resources available to SM’s to understand people interactions and problems better. One is the previous publication by Dale Carnegie called “How to Win Friends and Influence People.” The other is a newer resource by Michael James available online as scrummasterchecklist.org. In it James covers ideas like “How is my team doing?…How is the product owner doing?…etc”

She also cited a fascinating book by Harvey Robbins and Michael Finley called “’The New’ Why Teams Don’t Work.” She spoke about the importance of goals and objectives for a team. Bad Teams have vague goals and objectives. Good Teams may have clearer goals and engage in barrier identification. But the Best Teams have clear, short-term goals with continuous high-priority goals and objectives in segments of 30 days or less; they also identify barriers to people and processes. Best Teams ultimately value differences among team members, and develop something she called “versatility plans in interpersonal relationships.” (I wanted to learn more about this idea and posed a question in the webinar which unfortunately went unanswered.)

She then turned to psychology to discuss behavioral style differences in people. Four distinct personality types were explored: the Analytical (asks how?), the Driver (asks what?), the Amiable (asks who?) and the Expressive (asks why?). She believes a SM might help team members identify which personality quadrant they belong in so as to better understand each other. As well, in knowing the type of people who are in his/her team, a SM could adjust his/her communication and behavior to better reach each type.

I think it would be an interesting exercise for a team to go through personality types at least once. The exercise itself, besides creating deeper understanding, could also lead to some “aha” moments and laughter.

Johnson went through a checklist of Harvey Robbins’ rules for building trust in a team or group of people, and I will list them here:

  • have clear, consistent goals

  • be open, fair, and willing to listen

  • be decisive (meet the definition of Done)

  • support all other team members

  • give credit to team members when due

  • be sensitive to the needs of members

  • respect others’ opinions

  • empower team members to act

  • adopt a “we” mentality

  • take responsibility for team actions

She then added tips about supporting versatility: a)  you can only create an environment that encourages self-motivation rather than motivate others directly; b) assist people  to interpret what you say, i.e. “What I’m about to say is to help…etc;” c)  don’t overlook a variety of orientations, whether they are cultural, or gender-based. She advised that we need to be aware that orientation is very important to consider as the teams we work with have a greater number of people whose first language is not English.

She spoke about Scrum teams working within larger organizations. If the goal of Scrum is to produce greater value more quickly, then a SM should never have his/her attention split between more than one team. The SM has to be a teacher inside of an organization, to help management understand best practices – the SM is really the coach for a team, the Product Owner and the organization. Old habits die hard, so educating takes time.

Don’t allow language to get in the way of this process. Don’t say: “That’s not Agile! That’s not Scrum! You’re doing it wrong!” Instead say, “When you say Agile, what do you mean?” or, “What is the problem we’re trying to solve?” A SM can always point out that we have a choice to work in the old way, or to try something new. We have an opportunity to improve the way we work.

Agile and Scrum, she emphasized, are not destinations – they are about continuous improvement.

This summarizes just some of the valuable ideas Angela Johnson presented.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Decluttering Photographs: A Scrum Mindset

A common Scrum myth is that Scrum teams don’t keep documents. The many sticky notes on the wall of a scrum room can be anxiety-provoking to traditional suit-and-tie folks. Formal documentation is considered to be the hard product of real work. But the truth is two-fold.

First, Scrum teams do keep documents: The product backlog and the sprint backlog, which are two of Scrum’s artifacts, are key documents for a Scrum project. Each has a precise role in moving the scrum team from product conception to shippable increments. Different teams or organizations keep these artifacts in formats that suit them, but the point is that they do.

Second, it is not true that all formal documents are a faithful (or useful) reflection of work. More often than not, it is not clear what they’re for. Team members typically keep documents in the hundreds, outdated files are seldom deleted and clean versions are often mixed up with drafts. As with all clutter, the 80-20 rule applies rather well here: 20% of documents supports 80% of the work effort. So, 80% of formal documentation is in fact clutter.

Adopting Scrum will challenge organizations to focus on nothing other than completing deliverables of highest value to customers. This focus is in fact reflected by the few but super-useful documents that Scrum teams keep. But to move into this state of razor-sharp focus, we need a clutter-free environment. And while there are many forms of clutter on the job, documents are a big one. Why? Because the documents we keep and the way we use them reflect how well we understand our role. Much like a divinatory tool, the collection of documents you keep are very telling of how you do your work. Is there an orderly process as would be reflected by an orderly and well-organized set of a few focused documents? Or is it a firefighting role as would be reflected by a random set of documents contrived into folders?

Decluttering work documents compares rather precisely with decluttering photographs. Both clutter categories bring up very similar levels of emotional and intellectual charge as well as frustration with the sheer volume that needs to be processed and purged. And unlike the ease of throwing out something bulky like a broken chair or a dulled out piece of clothing, decluttering documents and photographs are very daunting tasks whose detail will bring anyone to tears.

Office documents are very much like a typical photo collection by enthusiastic parents: Several hundred photos of Maxi kicking ball, three dozen photos of the tenth birthday cake, one whole album of Auntie over for dinner, and so on. Photos will range from the incognito-fuzzy to the acceptably crisp. All are equal, however, and are kept in bulging pounds of photo albums or hard drives ranging in the terabytes – or both.

You can see the similarity with documents: Several hundred versions of the scorecard, three dozen presentations on the same topic, a few thousand archive files, and so on. ‘Fuzzy’ documents surely make up the majority. They include the many versions with corrections, inputs and errors, and the older versions to name just a few. The ‘crisper’ documents are typically the most recent ones and likely the ones shared with the VP. But these soon become ‘fuzzy’ as new versions are produced. The main issue with documents is knowing exactly what they’re for and how they support value-adding processes; a problem that doesn’t exist in a Scrum framework.

The main thread of comparison between photos and work documents is the degree of psychic severance that must take place in the mind in order to be capable of throwing out the useless lot. In truth, decluttering photographs is one of the hardest categories to tackle and does not happen until one has built a strong decluttering muscle with simpler categories like clothes, shoes, pots, pans and the like. Because photographs fall under the ‘sentimental’ umbrella, it takes much more than simply assessing functionality. Instead, it requires:

  1. An assimilated understanding of how to declutter, which means having built the decluttering muscle with simpler categories of stuff and having the gut to make sharp decluttering decisions,
  2. A willingness to look squarely at the past and contrast it with today, which basically means grieving and all the complex steps that alone involves, and
  3. A decision about what will be taken into the future, which must be actively considered as opposed to simply assuming that it’s what remains after decluttering the unwanted.

Releasing the way we create, share and keep documents is tantamount to releasing the way we work. That’s why decluttering documents is loaded with anxiety about how the future modus operandi will look like. An additional consideration here is to do this before anything is archived because if all the old is just moved into an archive, no one will open it because everyone subconsciously knows of all the mold that’s growing in there. So better not postpone the pain and roll with the punches. Taking a sword at opening each and every single file and processing for keep-dump-or-change, takes a lot of gut and staying power. Our attachment to documents is quite entrenched but it must be severed for the sake of agility.

The result of genuinely decluttering photographs is astonishing. The grieving process can be very intense; not only are issues resolved and dropped but pieces of the past are recalled into the present and the spirit regains integrity. The past is forgiven and the remains of the day are a powerful collection of sharp moments that are very much alive. Photographs are no longer nostalgic snapshots of the past but evidence of an assimilated experience in effect today. And with that, something very special happens: Fewer and fewer photographs are taken as soaking up a moment becomes far more precious than clunking through photographing it. This vulnerability to the passing of time is a key ingredient for living life intelligently.

Can you draw the parallels with documents? We spend most of our days at work. So, let me invite you to start tackling your collection and see how your newfound awareness pours into every other area of your life.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Certified LeSS Practitioner with Craig Larman

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

Here are the details of this unique learning event:

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

Check out the full agenda and register here.

Here are some quotes from previous attendees:

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

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

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

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

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


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Refactoring: 4 Key Principles

I believe in refactoring.  The Agile Manifesto holds that

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

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

Refactor or Die

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

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

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

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

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

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

Technical Debt and Design Death

Technical Debt and Design Death: Part II

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

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

In his articles, Kane Mar describes this like so:

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

In other words, refactor or die.

Refactoring and Business

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

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

Refactoring Principle One: Keep It Small

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

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

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

Refactoring Principle Two: Business Catalysts

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

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

Refactoring Principle Three: Team Cohesion

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

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

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

Refactoring Principle Four: Transparency

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

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

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

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

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

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

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail