Category Archives: Uncategorized

Kanban: Real Scaled Agility for Your Enterprise

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

Your business is an ecosystem of interdependent services, a complex adaptive system.

A bunch of organizations I know started their journey of increasing their agility with Scrum. That didn’t solve all of their problems. Kanban enables organizations to evolve their service delivery systems towards mature business agility.

As addressed in How Kanban Saved Agile, pure Scrum is extremely rare. Scrumbut (the disparaging label that spawned from so many organizations reporting that they do Scrum, but…) on the other hand, is extremely common.

In order to not be Scrumbut, you need the following:
  • Cross-functional development team of 7 +/- 2 people—ALL skills needed to ship product is present on the team—there are no dependencies external to the team;
  • One source of demand with no capacity constraints—the Product Owner is the customer AND full-time member of the team;
  • Sprints are one month or less, begin with starting new demand from the Product Owner and end with the delivery of potentially shippable Product Increments, followed by a retrospective about how to do better next Sprint;
  • “Potentially Shippable” means that the decision about whether to actually ship is purely a business decision. All the technical work is done;
  • If all of the technical work required in order to ship isn’t done, then the Sprint is a failed Sprint;
  • The Scrum Master is a servant-leader and Scrum educator to the entire organization.

How many organizations do you know of with Scrum teams that meet all of the requirements above? I don’t know one.

So, what’s the solution? Give up on Scrum? Are we still getting benefits from Scrumbut? Alright, let’s stop it with the Scrumbut already. Let’s acknowledge what’s really going with real teams in the real world and call that Scrum. Let’s refer to the above  checklist as “Ideal Scrum”.

Agile scaling methods have become a popular risk hedging tactic for all the loose ends dangling around the real teams in the real world.

Here are some of the reasons for adding layers of scaling around Agile teams:

  • Teams are not fully cross-functional;
  • Teams have external and opaque depencies;
  • Many of these dependencies are shared services with multiple sources of demand and constrained capacity—often overburdened;
  • External dependencies can be other teams—demand from other teams shows up in their backlogs, prioritized by their own Product Owners;
  • Many dependencies don’t play by the same rules at all—some reside in a different part of the organization, with different structures and political forces;
  • The Product Owners are proxies for multiple stakeholders and customers and the Product Backlogs represent an array of multiple sources of demand, with different service level expectations, strategic origins, degrees of clarity, urgency and political forces pushing them into the deliver organization;
  • The Product Backlogs are made up primarily of solutions defined by stakeholders and translated by the pseudo-Product Owners as pseudo-user stories—how they get there is opaque, the “fuzzy front end”—and somewhere in here a fuzzy delivery commitment was already made;
  • The work of a Sprint includes all of the work that the non-cross-functional teams can get done—then whatever the teams get “done” is “delivered” (handed-off) to a subsequent set of teams or process steps (usually fairly well defined at an organizational level but outside of the teams’ influence);
  • Delivery decisions are made based on constraints imposed by legacy technology, systems and their gatekeepers (for historically good reasons);
  • The teams are “done” at the end of each Sprint, yet much work is still to be done before their “done” work is potentially shippable;
  • The Scrum Master’s are held collectively accountable for the collective deliverables of the teams and their ability to cross-team coordinate and integrate—accountability by committee translates into no one is actually responsible.
  • Middle managers are scrambling to pick up the pieces because they are actually accountable for delivered results.

Generally speaking, the aim of Agile scaling methods is to apply larger Agile wrappers around clusters of Agile teams in order to re-establish some kind of hierarchical structure needed to manage the interdependencies described above. Whether its a Release Train or a Nexus, or whatever else, the idea is that there is an “Agile Team of Teams” managing the interdependencies of multiple, smaller teams. As long as the total number of people doesn’t grow beyond the Dunbar number (~150), the Dunbar-sized group is dedicated and cross-functional, there is a team managing the interdependencies within the Dunbar, there are no dependencies outside of the Dunbar and there is some cadence (1-3 months) of integrated delivery—it’s still “Agile”. All of this scaling out as far as a Dunbar (and only that far) allows the enterprise to still “be Agile”—Scaled Agile.

This is all supposed to be somehow more realistic than Ideal Scrum (with perhaps am overlay of Scrum of Scrums and a Scrum of Scrum of Scrums). It’s not. How many organizations do you know of that can afford to have ~150 people 100% dedicated to a single product? Perhaps today there is enough cash lying around, but soon enough the  economic impact will be untenable, if not unsustainable.

How does Kanban address this problem? Your business is a complex adaptive system. You introduce a Kanban system into it such that it is likely that the complex adaptive system is stimulated to improve. The Systems Thinking Approach to Introducing Kanban—STATIK—is how you can make such a transition more successful (@az1):
  1. Understand the purpose of the system—explicitly identify the services you provide, to whom you provide them and why;
  2. Understand the things about the delivery of the service that people are not happy about today—both those whose needs are addressed by the service and those doing the work of delivering the service;
  3. Define the sources of demand—what your customers care about and why;
  4. Describe the capability of your system to satisfy these demands;
  5. Map the workflow of items of customer-recognizable value (@fer_cuenca), beginning with a known customer need and ending with the need being met through stages of primary knowledge discovery (Scrum teams somewhere in the middle, towards the end)—focus on activities, not looping value streams;
  6. Discover classes of service—there are patterns to how different kinds of work flow through your system (they are not arbitrarily decided by pseudo-Product Owners), what are they? Group them, they are classes of service and knowing them enables powerful risk management;
  7. With all of the above as an input, design the Kanban system for the service;
  8. Learn how to do steps 2-7 and start applying it directly to your own context in a Kanban System Design class;
  9. Socialize and rollout (learn how by participating in a Kanban Coaching Professional Masterclass);
  10. Implement feedback-loop Cadences for continuous evolution—learn the 7 Kanban Cadences and begin applying to your own context in a Kanban Management Professional class;
  11. Repeat with all of the interdependent services in your organization—every “dependency” is a service—Kanban all of them with STATIK and begin implementing the Cadences.

Don’t get hung up on teams, roles, your latest reorg, how people will
respond to another “change”, who’s in, who’s out, etc. These are all part of the service as it is now—your current capability. Initially, no changes are required at this level. The kanban system will operate at a higher level of scale. Through feedback-loop cadences, it will evolve to be fit for the purpose of your customers without a traumatic and expensive reorg.  Who is responsible for this? Identify this person. If you are the one thinking about this problem, there is a good chance that it’s you. Whoever it is, this is the manager of the service; take responsibility, do the work and make life better for everyone.

For more information about LeanKanban University Certified Kanban courses provided by Berteig, please go to www.worldmindware.com/kanban. Some spots are still available for our classes in Toronto, June 12-16.

For Agilists who have read this far and still don’t get it, start here:

14 Things Every Agilist Should Know About Kanban

The story below may be familiar to some:

Our IT group started with Scrum. Scores of people got trained. Most of our Project Managers became “Certified” Scrum Masters. Most of our Business Analysts became “Certified” Product Owners. We purged some people who we knew would never make the transition. We reorganized everyone else into cross-functional teams – mostly developers and testers. But now they are Scrum Developers. We tried to send them for “Certified” Scrum Developer training but hardly anyone of them signed up. So they are Just Scrum Developers. But we still call them developers and testers. Because that’s still how they mostly function—silos within “cross functional teams”, many tales of two cities rather than just one.

After the Scrum teams had been up and running for a while and we were able to establish some metrics to show the business how Agile we were (since they didn’t believe us based on business results), we had a really great dashboard showing us how many Scrum teams we had, how many Kanban teams, how many DevOps, how many people had been trained. We even knew the average story point velocity of each team.

The business didn’t get it. They were worried that Agile wasn’t going to solve their problem of making commitments to customers and looking bad because we still weren’t able to deliver “on time”.

As IT leadership, we were really in the hot seat. We started to talk about why the transformation wasn’t going as it should. We knew better than to bring the Agile coaches into the boardroom. They were part of the problem and needed to be kept at arms length from those of us who were making important decisions. Besides, their Zen talk about “why?” was really getting old fast. Some thought it was because we didn’t have the right technology. Others were convinced it was because we didn’t have the right people. After all, we didn’t go out and higher experienced (above-average) Scrum Masters and Product Owners, instead we just retrained our own people. Clearly that wasn’t working.

We started with improving the Scrum Masters. We went out and hired a few with impressive resumes. We developed some Scrum Master KPIs (HR jumped all over this one). Then one day we had a collective flash of brilliance—since the ScrumMasters are the servant leaders of teams, we will make them responsible for collecting and reporting team metrics and this will tell us how well the teams are doing and how they need to improve. This surely would be the key to improving the performance of IT and get us on a better footing with the business.

But we didn’t get the response we were hoping for. The ScrumMasters soon complained that the metrics of the teams were impacted by dependencies that they had no influence over. When we pushed harder and shamed them publicly for failing to produce meaningful metrics, they tried harder, but they weren’t able to do it. Some began disengage. “This is not the job I signed up for” became their new mantra. This was puzzling. We were empowering them and they were recoiling. Maybe we didn’t get the right Scrum Masters after all. Maybe we needed to go out and find people who could think and act effectively beyond the confines of their own teams. Or…


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Soft Skills Revolution: Why You May Want Team Development

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

If you go on line and type “soft skills” into your browser, you will come up with a plethora of sites. That’s because soft skills are being touted as the most important skill set for any individual in any career. Soft skills are becoming de rigeur in job applications and leadership training of every kind. One might say that there is, in fact, a soft skills revolution occurring in every sector of society.

What is motivating this revolution? Perhaps the more automated our world becomes, we see that our more human characteristics and relationships are needed to balance such a high degree of automation. Perhaps it’s become clear that human characteristics are what drive everything forward in either a positive or negative fashion.

Wikipedia describes soft skills in this way:

Soft skills are a combination of interpersonal people skills, social skills, communication skills, character traits, attitudes, career attributes, [1] social intelligence and emotional intelligence quotients among others that enable people to effectively navigate their environment, work well with others, perform well, and achieve their goals with complementing hard skills. [2]

By another definition, soft skills are those skills that are difficult to measure.

With the advent of the Agile Manifesto (www.agilemanifesto.com) and agile processes permeating business and organizational cultures more and more, people are abandoning the silo mentality and striving to create a more communal environment and team consciousness. Many organizations and businesses are learning that teams rather than individuals are more effective at accomplishing goals.

When a team of people have to work together, there is an expectation that they will all do their best to get a job done. On the other hand, it’s also normal for people on a team to encounter hiccups and even conflicts, whether it’s issues of personality, ego or disagreements of one kind or another. Then there are those team members who do not feel safe to offer their opinion, or those who harbor a prejudice against a certain type of person they may be required to work with.

By putting people together to work alongside each other day after day, we are creating a potent mix. Human beings are extremely complex and diverse after all. There are volumes written about both the need for and the difficulty of people working and achieving together.

From a recent Insight BTOES newsletter about hiring practices:

If they’re the best there is in their craft but would prefer to just do their job and be left alone, it isn’t likely they’ll engage in team improvement activities and become a contributing part of the new culture. It’s simply not worth taking on the resistance/non-engagement that you’ll have to deal with until your patience runs out and you’re right back where you started…”

http://insights.btoes.com/hard-skills-or-soft-skills-more-important-leadership-culture-transformation

Many corporations now claim that soft skills are the number one priority when hiring, Hard skills can be easily taught but soft skills make the difference whether a person is even teachable and flexible enough for a corporate environment.

This is just the tip of the iceberg, because soft skills have not been the focus of our education systems, and those who have them need continuous practice and improvement. But everyone has the potential to become more empathetic, cooperative, supportive, and respectful.

Whether it’s learning to communicate effectively, or to create a sense of cohesion in a team, there are many pieces that can be put in place to help any team (and its individual parts) be more powerful, effectual and happy.

One very basic ingredient that can make a world of difference to a team’s work is to feel safe. Safety comes with having clear and consistent goals. Team members feel safe to speak his or her mind without fear or judgement, even if their opinion is different from others. A team feels safe to experiment and to succeed or fail. Safety is built on the very essential idea of trust.

Psychologist, author and consultant Harvey Robbins has written extensively about the idea of trust as a key element of any team. He describes trust as follows:

· Trust means setting clear, consistent goals. If people don’t know exactly what they’re supposed to, they will feel set up to fail…

· Trust means being open, fair, and willing to listen. This requires more than making a thoughtful, considerate face. It means listening to the words other people are saying.

· Trust means being decisive… It’s a challenging thing to say, but sometimes it’s better to make any decision – good, bad, or indifferent – than it is to make no decision at all.

· Trust means supporting one another…Your team belong to you, and you belong to them.

· Trust means sharing credit with team members. You are there for them, not vice versa. If you are a glory hog, you are stealing from the team.

· Trust means being sensitive to team members’ needs. You should know what legitimate secondary agendas they may have, and be willing to help them achieve their personal goals.

· Trust means respecting the opinions of others. The worst thing a leader can do is denigrate or dismiss or ignore team members. If they’re no good, move them off the team. But even then you owe them your respect.

· Trust means empowering team members to act. It means trusting that they are up to the challenges that you trained them for…

· Finally, and ultimately, and most difficultly, trust means being willing to suffer… The ordinary leader exposes his people to all the risk. The trusted leader assumes risk himself.

Article Source: http://EzineArticles.com/716760

When a team has clearly articulated goals, it helps build a sense of cohesion, in that every member is aware of what they are working toward. When team members are allowed to work out an action plan toward achieving a goal, this gives everyone a stronger sense of purpose and ownership.

If you’re wondering whether a Team Development workshop would be of benefit to, or is necessary for your business or organization, here are some thoughts from MindTools that can help you decide:

  • Are there conflicts between certain people that are creating divisions within the team?
  • Do team members need to get to know one another?
  • Do some members focus on their own success, and harm the group as a result?
  • Does poor communication slow the group’s progress?
  • Do people need to learn how to work together, instead of individually?
  • Are some members resistant to change, and does this affect the group’s ability to move forward?
  • Do members of the group need a boost to their morale?”

https://www.mindtools.com/pages/article/newTMM_52.htm

Everyone has the potential to grow their soft skills. However, a company may not have the resources to help unlock this potential in its employees.

If team development is not part of a company’s culture there may be discomfort in dealing with friction arising from a lack of soft skills. In this case, an external facilitator or coach can be a very helpful resource to guide a work team, using thought-provoking activities and role-playing, to find greater connection and trust amongst themselves, and to address issues with a detached point of view.

Organizing such a workshop for your team does not mean they are not doing well or failing. It means you, the team lead/ manager/ CEO/ HR person, etc, care about your team’s best interests, highest achievements and happiness.

Valerie Senyk is a facilitator for Team Development with BERTEIG, and can be contacted by going to http://www.worldmindware.com/AgileTeamDevelopment


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Table of Contents:

Foreward – Jeff Sutherland

Foreword by Roman Pichler

DECISIVE 26

RUTHLESS 64

INFORMED 102

VERSATILE 144

EMPOWERING 180

NEGOTIABLE 222

Be DRIVEN to Be Great 264

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

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

by Geoff Watts and Jeff Sutherland

Kindle EditionCDN$ 41.94

PaperbackCDN$ 42.18

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Using “Status” in Agile Coaching & Training

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

Recently after attending a Scrum Alliance webinar on “Best Practices in Coaching,” I was reminded of my experiences teaching Acting students at university, and how I used changing status to help them achieve their best.

Status refers to the position or rank of someone within a particular group or community. I believe it was Canadian Keith Johnstone who introduced the idea of “playing status” to theatre improv teams. It is used to create relationships between characters onstage, and to change those relationships to move a story forward.

Status can be indicated through position, posture, facial expression, voice and clothing. It is a fascinating tool for any trainer or coach to use.

At the beginning of a semester with new students, I would invite them to sit on the stage floor in a circle with me. I would welcome them, discuss my expectations of their learning, and tell them what they could expect from me. We’d go over the course syllabus and I’d answer questions. I purposefully put myself in an equal status to them, as a way of earning their trust, because the processes of acting* requires huge amounts of trust. I also wanted to establish a degree of respect in them for the stage by all of us being in a “humble” position on the stage floor.

However, when I would introduce a new exercise to them that required them to go beyond their comfort zones, I would deliver instructions from a standing position while they were seated. By elevating my status, I conveyed the importance of the exercise, and it was a signal that it was not something they could opt out of. In this way, I could help them to exercise their creativity to a greater extent.

Another way I encouraged my students to take risks was to take risks myself. Sometimes I would illustrate an acting exercise by doing it myself first. For those few minutes I became a colleague with my students, one of them, equal in status. If I could “make a fool of myself” (which is how it may look to an outsider), then they could too.

I had one student who had great potential, but who took on the role of class clown and would not give it up. He fought against going deeper and getting real. One day in an exercise where they had to “own” a line of dialogue, I had him in a chair onstage, while I and the rest of the students were seated. He had to repeat the line of text until it resonated with him and became real. After some minutes, nothing was changing in him. In desperation had him turn his chair around so his back was to us. I then indicated to the other students to quietly leave the room. He could hear something happening but was confused about it. He was not able to turn around and look.

When I allowed him to turn around it was only him and me left in the theatre. I had him go through the repetition exercise again. Without an audience, and with me still seated, he finally broke through the wall he had erected and connected with the line of text from his inner self. It was a wonderful moment of truth and vulnerability. I then allowed the other students back in, and had him find that connection again with the students there. He was able to do it.

He is grateful to me to this day for helping him get beyond his comfortable role as clown to become a serious actor.

When training or coaching, it seems to me there can be huge value in playing with status. Sometimes taking a lower status, an equal status, or a higher status, can move a team or upper management into discovering whatever may have been blocking the process. Again, there are many ways to indicate status and even a status change to effect progress.

In his book, “Improv-ing Agile Teams,” Paul Goddard makes some important observations about using status. He writes: “Even though status is far less obvious than what is portrayed on stage, individuals still can take small steps to encourage status changes within their own team. For example, asking a team member who exhibits lower status behaviours to take ownership of a meeting or oversee a process not only boosts that person’s confidence but also increases status among peers…these subtle actions can help make lower-status team members feel more comfortable when expressing new ideas or exposing hidden problems.”

A colleague reminded me of a 1975 publication called “Power: How to Get It, How to Use It,” in which author Michael Korda gives advice about facial expression, stance, clothing and innumerable ways to express “power.” The idea of using status in the context I’m writing about is not about gaining power, but about finding ways through one’s own status changes to help unlock the capacity and potential of others.

How can a coach use status to help someone in management who is blocking change? Is someone on a team not accepting what others have to offer because s/he is keeping his/her status high? Is a Scrum Master necessarily a high-status team member, or rather a servant to the team (low status)?

I am curious if any coaches or trainers out there have used status in a way that created growth and change.

*Good acting is a matter of the actor finding the truth in oneself as it relates to the character he or she is playing. It requires vulnerability and courage to step out of one’s known persona and take on another as truthfully as possible. Inherent truthfulness also applies to work in any other endeavour.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Dejirafication: Free Your Process

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

Alexey Krivitsky recently posted a presentation on his blog, agiletrainings.eu, addressing the issue of so-called-agile tools, specifically Jira.

Here is a link to his presentation.

The movie images he chose gave me a chuckle and his points really hit home.

He offers 4 points to what he calls a “Jira Rehab Program” and I found the points interesting.

Take a look. See what you think.

Share your comments on your experience with agile tools here.

Have you had success with Jira or would you rather see it disposed of?

And check out Mishkin’s recent article on the ideal electronic Agile tool.

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Strong Teams Start With Trust

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

One of the positive outcomes of an agile team succeeding in its transformation is the establishment of a high-functioning team.

A high-functioning team works more effectively, efficiently and can innovate more appropriately for the corporate advantage of the business.

Ryan Yeoman has a lot to say on the topic. Although he doesn’t mention agile specifically, he’s right on in his approach.

In his article, “Strong Teams Start With Trust: 5 Ways To Build Trust in Your Teams,” he writes that:

All of them point to trust as a critical and fundamental piece to success – in business and in life.

Piggy-backing all these thoughts and making it personal to myself, trust enables me to be more.  It enables me to:

  • Accomplish more and do better work by getting feedback and synergizing
  • Grow and learn more by allowing myself to be “open” and receive information
  • Teach more and serve by letting me focus my attention on others
  • Care more and empathize because I’m not constantly worried about protecting myself
  • Be more human

Trust helps you accept deepening relationships and removes politics and silos from the work place, creating an organization within which people feel safe. At its simplest, trust is a catalyst for your organization to be more: more nimble, more efficient, more effective.  It’s like oxygen for a successful team – one simply can’t exist without it.

I found his comments insightful and his links appropriate.

This is an excellent article for those team members who are striving for excellence and learning to trust one another, and themselves, in the process.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Video: Managers Develop Delivery Teams

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

Real Agility managers help their delivery teams to progress through the stages of team development to reach a sustainable high-performance state. Real Agility is the merging of Agile, Lean, and Community Development. Find out how managers’ roles change in this short video by Mishkin Berteig.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quotable Quote: Transform Culture & Business Approach

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

Jerry Doucett 201601 white background - head - 275 squareAt the end of the day your goal should not be to become Agile or Scrum savvy.  Instead your real goals and outcomes should align with achieving the key benefits of Agility, and with what Scrum offers.  These should include (but are not limited to) increased customer satisfaction, faster delivery of value, improved feedback loops, adopting a continuous improvement mindset, improved employee morale and increased employee retention.  Scrum is just one of the many tools or approaches you may choose to get there, but it is certainly an important one to consider if these outcomes align with your goals.

For Scrum to be truly successful at your organization, you must dramatically transform your very culture and business approach.  To be clear, this is not easy to do but the rewards are well worth the effort.  By embracing such a transformation, the adopted change in behaviour, beliefs and practices should result in a more successful Scrum experience and a higher degree of satisfaction for both your customers and employees.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: 4 New Steams of SAFe courses offered

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

Jerry Doucett 201601 white background - large square

Jerry Doucett is now offering consulting in implementing SAFe 4.0,  as well as teaching the following courses and workshops:

1) “Leading SAFe 4.0” course for the SAFe Agilist (SA certification)

2) “SAFe Product Manager – Product Owner” workshop (SPMPO certification)

3) “SAFe 4.0 for Teams” course for the  SAFe Practitioner (SP certification).

Please reach out to Jerry by email or on LinkedIn if you have any questions about SAFe or about scaling Agility.

The next SAFe class is “Leading SAFe 4.0” on September 08 and 09.  Please see WorldMindware.com for more information including registration.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

ANNOUNCEMENT: New Upcoming SAFe Courses

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

Scaled Agile Framework - SAFe Agiilist Logo

Last week 23 new course offerings were posted at BERTEIG’s Training website.

These classes are offered by Senior Agile Coach Jerry Doucett who has worked in Agile transformation since 2008.

More information on SAFe can be found here and you can register for any upcoming class here.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Some Light Agile Humour Puts Things Into Perspective

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

Have you ever wanted to run an agile project?

Or maybe you are a leader in an organization who has had an agile coach approach you requesting to run an agile project?

This light & comical sketch depicts the often humorous interactions between agile coaches and corporate leaders in various departments.

At the end of this clip, the agile coach has spoken with a CEO, Human Resources, Financial Department, etc and when he goes back to the first CEO he’s had a lot of conversations about his project, but it has not yet started.

The concept of two operating models existing within the same space is so clearly illustrated here. The one framework is about upfront-planning, documentation, assessment and projection of a plan. The other framework (Agile) is about very little upfront planning with a “jump-in-and-get-started” attitude. Adjustments are made along the way with continuous reflection and learning. The product continues to improve and is ready to deliver sooner.

The most successful businesses in the world are the ones where Agile methods have been adopted in every level of an organization.

It is just changing everything.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Waterfall vs Agile

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

A Retrospective on the
History of Project Management

Changing my Brain from Agile to Waterfall

Several months ago I enrolled myself in a project management class. I wanted to learn about the “old way” of doing things–that is, more simply what we would refer to as the “Waterfall” methodology.

However after taking this course, i’m now apprehensive to call it “Waterfall” as there are so many other outlying elements apart from what defines it as “Waterfall” (Gantt Charts). Instead i’d refer to this practice of project management as being “traditional” and respectful towards a more old-style way of conducting business; or, operating business within a reactive environment.

Reactivity – a measure of the deviation from the condition at which a nuclear reactor is critical.

You see, i’m more of an Agile/Scrum guy (in case you were unaware). I attended this class with an open-mind, glass-empty, eyes-open and ears-listening perspective. However, every class I attended, I compared the methods to Agile/Scrum and thus i’d like to share my learnings from the class.

Before I continue, I would just like to mention that I loved taking this class, I learned new skills, I met talented people, and I would happily take this class under any other conditions.

Item #1 Reporting

I learned, there’s no reports in Agile. You reading this would disagree, but compare this to Waterfall–nope. The traditional project management system is designed with reporting in mind; in fact I would say that reporting is the first item on the “to do” list.

Before building anything! We need to make a report for it. (Let’s call it RDD – Report Driven Development)

One could argue that this is incredibly important when there are millions of dollars at stake, shareholders that need to know where their money is going, and of course good record keeping in the unlikely event of lawsuits. However, in all this documentation, when does the project actually yield some development? This is why I call it reactive–because to use this methodology is to focus on avoiding pitfalls, and attempt to foresee explosions.

Personally, I think reports are silly. I once saw a young mother have to stay two hours late for work on a beautiful spring Friday because she had to finish a report. She was the only one left in the office, and I asked her “Why do you have to send the client the report? Why not just schedule a meeting during office hours, and give them a presentation or conduct discussions containing the data within the report?”

“That’s a good idea, I never thought of that” she replied.

Possibly another case where a “nice to have” feature is causing stress to a worker just because a project manager is following an outdated methodology.

Item #2 Ubiquitous Language

One thing I love about the traditional project management suite, is its dictionary of terms and definitions. A lot of really smart people developed and documented the standards that are used within PMP/PMI, such as academics, engineers and scientists. There’s now mountains of documentation supporting all of the concepts within the waterfall world, and rigorous thought-out processes for (almost) every instance that may occur in a project. Also, sidenote: I’m not saying that all of these career paths tend to rely exclusively on documentation, but there’s certainly a lot of documentation involved.

When I was a chef, if you were to cook on the east coast, you’d refer to the small crustacean “shrimp” as “shrimp”, if you were to travel to the west coast, all of a sudden the same crustacean would be referred to as a “prawn”. I’m sure you’ve been in a project where the east coast team used a term that was different from the west coast team, and if you consider communication to be the backbone of Scrum–this could lead to a failure.

Because of that, there’s not a word i’ve encountered within Waterfall that doesn’t have a standard definition. The word “baseline” is used to define the starting position, and that’s why I refer to this education as a “history” class. It’s the sort of stuff you learn before you get into large projects.

There’s a proper place and time for documentation, and in Agile it’s a discouraged practice. Because why have documentation when you should be acquiring the information from talking to human beings. Verbal conversation and timed-planned meetings can introduce subjects with greater accuracy and less time than a well-documented word file.

In dealing with million-dollar projects, and teams of hundreds of people there’s no room for ambiguity within language. And please keep in mind, documentation creates standardization, and it’s the processes required to generate the ubiquitous language that i’ve noticed is a shortcoming within Agile in comparison to Waterfall.

I’d say that the majority of the process we use in Agile project management exist foundationally within Waterfall–but we don’t even realize we use them. A tad bit of studying, and learning the baselines will enable individuals to fortify the foundation in their next project.

Item #3 Actual History

Yes, I learned about historical concepts within the project management world. Such as process theories and their corresponding theorists. It’s truly fascinating to learn about how we got to where we are today in terms of project management.

In 1962 Everett Rogers was considered an early adopter and supporter of modern change controls and change requests.

Ultimately, the sad truth is that the majority of processes we follow today in project management are just to cover ones ass. As, historically, the project manager tended to be the focus of “blame” when failures occur within a project.. and the first person to be fired.

Keep in mind that this project management approach is over a century old, and the Agile manifesto was formulated in 2001. So I like to believe Agility is devised for a new world of empowering teams and building stuff, however it’s very important to know where you came from.

Item #4 Quoting

The biggest takeaway from my history class, was learning about all the tools that currently exist within the antiquated project management methodology and their gorgeous tools for creating estimates.

Creating estimates is tricky in Agile; mostly because to adhere to the iterative development that the Agile framework represents, you don’t ever look too far into the future. The reality is though is that most businesses need a longterm plan and a lot of us in the Agile world use duct tape and a series of levers and pulleys to make Agile work with estimates. If you’re struggling with estimates, I recommend reading the Project Management Body of Knowledge Version 5 (PMBOK).

These guys have literally been doing estimates for an obscene length of time. I believe if we can hybridize their approach while adhering to the Agile workflow, we’ll have something that can truly change the world.

Having said that, as an entrepreneur I create a budget for all my projects. I accomplish all the business goals early-on in a project so that I can work to pivot them later. Pivoting is what it is to be an entrepreneur, and something that doesn’t work well with Waterfall–which is very un-business-like.

Item #??? RFP (Request for Proposals – Procurement Management)

This is the most ridiculous thing i’ve ever seen. I’m familiar with the RFP process as i’ve worked for corporations that thrived from the activity, and during my history class we studied more about what makes the RFP “tick”. Every time I think of RFP’s, I think of how Walmart operates, have you heard this story before?

Walmart tells it’s toothbrush suppliers how much it’s willing to buy the product for, and if the toothbrush manufacturer is unable to accommodate that price, Walmart will choose to get toothbrushes elsewhere. Problem is, there’s always that factory in China who will do it for a third of the price of North America, and create miserable working conditions for the workers. Yes, that’s the world that the RFP creates.

I love the aerospace industry. And what’s the difference between NASA and SpaceX? Well that’s easily the argument of Waterfall vs Agile–as NASA is still using the RFP when they should be considering iterative in-house development. The James Webb Telescope announced in 2002, to cost $842 million and to launch in 2010 was awarded to (what is now) Northrop Grumman Space Technologies. Northrop Grumman then released separate RFP’s to build components of the spacecraft. It then became a global initiative as subcontractors from all over the world were bidding on the components. You can probably bet that those subcontractors put-out RFPs as well.. But that’s my assumption.

TLDR: As of 2013 it’s estimated to cost a total of $8.8 Billion, and launch in 2018. Oops.

Conclusion

If I could summarize Waterfall in one sentence, it would probably be something like: “Waterfall is an excellent tool to make stakeholders happy, and get money from venture capital”. Where Agile is like “Agile is an excellent tool to get shit done, and keep everybody involved in the project at a consistent level of satisfaction.”

Every time I hear about a project going over budget, extending deadlines, and ultimately creating failures within business–really breaks my heart. You know that all the troubles from such a project creates unnecessary headaches, and potentially unemployment. Be a responsible project manager and don’t focus on the happiness of stakeholders.

Learning more about Waterfall was great, and I learned a lot more about Kaizen (iterative development, or, Agile within the Waterfall world). It has also taught me more about what truly makes Agile unique, and not just a buzzword used within industry.

**subtext: if anybody wants to challenge me to building a spacecraft using Agile/Scrum — bring it on.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail