What are strengths?

Maybe you have heard of talents, strengths, StrengthsFinder, CliftonStrengths.  Maybe you have even taken the assessment.  But, what does it all mean, really?

CliftonStrengths, formerly StrengthFinder, is an assessment that takes about 30 minutes or so to complete.  The results of that assessment produce a report that is unique to you.  This report gives you either your top 5 talent themes, or your full 34, depending upon which report you choose.  I recommend the full 34 report as it is much more powerful to know where all of the talent themes land for you.  

You might say, why is it called CliftonSTRENGTHS, when you said the report measures your TALENTS…what’s the difference?  A talent is a naturally recurring pattern of thought, feeling, or behavior that CAN be productively applied.  A strength on the other hand, is the ability to CONSISTENTLY produce a positive outcome through near perfect performance in a specific task. 

In other words, a talent is about potential and strengths are about actualization.  The assessment can’t measure your ability to consistently produce a positive outcome, but it can measure your naturally recurring patterns of thought and behavior.  It is up to you to spend time learning and practicing your talents for them to become strengths.  

For example, I have a talent in communication.  When I was working as an attorney and writing every day, writing came as naturally as breathing.  But here I sit, 2 hours into writing this blog and I continue to work at it, because it’s not quite what I want.  I have not been practicing my communication through the written word in quite some time, so it is not a strength right now.  It is, however, still a talent, and if I keep writing these blogs for you, I will hone that talent and develop it back into a strength.

So, by now hopefully you’re thinking about how you learn more about your talents.  Well, there is a lot of information in the full 34 report about your top 10 talent themes.  To get even more information, you can go to the link sent from your assessment results to read more reports or watch videos on each talent theme.  Then you can work to utilize these talents intentionally on a daily basis to turn them into strengths.   If this interest you, be on the lookout for my next blog on what to do once you know your talents.

If you don’t understand or want a guide through this process, you can seek out a Gallup Certified Strengths Coach to help you. To find out about our Gallup Certified Strengths Coach and our services, please visit collaborativeleadershipteam.com or email info@coleadteam.com. 

Collaborative Leadership Team’s Teri Bylander-Pinke attains Gallup-Certified Strengths Coach Credential

For Immediate Release    

Dateline – Minneapolis, MN August 18, 2020  

Collaborative Leadership Team (CoLeadTeam) is a Midwest-based firm focused on guiding business agility.  We believe in a different approach to work. Individuals, teams and leaders who use this approach will learn faster, adapt quicker to reach outcomes while lowering cost of change.   

"We are committed to helping individuals and organizations in the Twin Cities and all throughout the Midwest deal with the challenges of change” said Angela Johnson, Founder and President of CLT. “Change is the only constant. The individuals and organizations that can learn and adapt the fastest, will be the ones that succeed, and coaching is critical to that success.”   

CliftonStrengths is an assessment to uncover the true you.  Strengths coaching provides teams and individuals a deeper understanding of their assessment and how to manage their strengths and weaknesses effectively to achieve their goals and manage through change. These skills can be applied daily to enhance engagement and productivity.  COO Teri Bylander-Pinke shared, “According to Gallup, people that utilize their strengths daily are six times more likely to be engaged in their jobs and three times more likely to report having an excellent quality of life.  I have seen this to be true in my own life and have strived to achieve this coaching credential so I can help other see and apply it as well.”   

To learn more about Teri or Strengths Coaching, please visit www.collaborativeleadershipteam.com or email Info@CoLeadTeam.com. 

About Collaborative Leadership Team:  

Practicing Agile since 2010, CoLeadTeam has learned from experience how to guide people and organizations through their Agile learning maturation.  We bring knowledge in Software, Hardware, and Services delivery.  We have experience to help guide clients through their learning how to work differently.   

Contact  Collaborative Leadership Team:  

Angela Johnson 

Chief Executive Officer  

Collaborative Leadership Team 

952-232-6422  

Are You a Credible Agile Leader? Not if you think it means paying license fees for an “Agile” tool.

This is a condition we like to call Toolitis.

Once again it involves someone in a leadership position not knowing what “Agile” means. The very first value in the Agile Manifesto is “Individuals and Interactions over Processes and Tools”.  If you think paying money for a piece of software makes you agile, guess again. It doesn’t make the company agile, nimble or able to pivot at all. It also does not show any trust or empowerment of the people doing the work. In fact, other software the company already uses can do the same things . Most Agile approaches such as Scrum, eXtreme Programming and others are about empowering the people *doing* the work to come up with the best possible process to deliver that work.

When Toolitis sets in, the people doing the work are not empowered. Quite the opposite. The “Agile” software tools dictate processes to people. They start using phrases such as “This is the way [insert tool name here] makes us do things. That's the opposite of individuals and interactions, the opposite of empowering and the opposite of a team of people owning their own process.

Because they use someone else’s idea of an agile process, it’s no wonder people in organizations don’t buy in or even say “I hate Agile” or “I hate Scrum”. The reality is that what the organization is imposing on them is anything but Agile and isn’t Scrum.

Tools try to be all things to all people.

They often misuse vocabulary terms from frameworks considered Agile. Besides confusing people, they lead to various anti-patterns that don't enable the organization to deliver to customers any faster or cheaper than Waterfall or Project Management did.

One example of this is the term Backlog. The Backlog is a generic term in the Scrum framework. A Product Backlog owned by the Product Owner represents items that deliver business value. There is a Sprint Backlog owned by the Development Team. Both have very different functions. What’s intended at Sprint Planning is for the Development Team to pull items agreed to with the Product Owner off of the Product Backlog and to break those items down into “how” to do the technical solution in units of 1 day or less. Why units of 1 day or less?  Scrum is about Daily transparency with an opportunity Daily to adapt. The Development Team is intended to work together in a “rugby-like” approach on the highest valued Product Backlog Item and get it to done. Then move to the next one and so on. The company has an opportunity to realize more value and an opportunity to course correct sooner when Scrum is used as intended.

When there’s one generic “backlog” things start to go off the rails . People think there is only 1 list that’s all technical from the Development Team perspective. Because the tool requires one “assigned” person, people believe it’s only 1 person 1 item. There’s no breakdown into the one day or less units. As a result, there’s no Daily transparency. The Daily Scrum is now useless because each person lists “ticket numbers” from the tool and says “no blockers”. Who knows if there are impediments because there’s no way to see that in the tool. People are being conditioned by the software to not articulate what got to done on a daily basis.

The end of the Sprint arrives with no business value delivered and no Product Backlog Items done. Because the tool allows people to split the work retroactively and take “credit” for what they started, it gives a false appearance of productivity when Scrum is all about done or not done. There’s no credit for work not done. And for the big finale, work gets carried over in the next Sprint. When people talk about carry over work and how Scrum isn’t delivering working increments in their Sprint we can always pinpoint exactly which tool is used at the company. It's not Scrum's fault. 

Understand why your credibility as an “Agile Leader” is pretty low and wondering how to fix it? Let the people closest to the work own their own process for managing that work. 

Allowing your team to own their own process results in more accountability and buy-in. If you believe that “Agile” is the best way to do this, it’s a good idea as their leader to read the Agile Manifesto. It’s a good idea to find out what problem you think a new piece of software will solve. Unless you have unlimited amounts of money that you need to spend, chances are there are already things you have for the people doing work to use. 

And hey, if you want to be the most credible of all Agile Leaders, you’d ask the people doing the work for how they want to manage the work that they are doing.  Not only are they more likely to support a process they had a hand in defining, there’s a far better chance that some work will get to Done instead of Not Done.

If you are looking for ways to recover from Toolitis, contact us HERE.

Are You a Credible Agile Leader? Not if you declare “We’re Going Agile”.

People ask you where that is or why are we doing that or what we gain by changing the way we do work? “Just start sprinting…” you reply. You've heard the old definition of insanity; doing the same thing over and over and expecting a different result. Agile approaches mean doing work differently. 

There also is no such thing as the Agile Methodology. 

When people use the word “Agile” in reference to doing work differently, it generally refers to the 2001 Agile Manifesto. There were several frameworks represented at that meeting, such as Scrum and eXtreme Programming. The Manifesto spells out 4 values and 12 principles.

So, what do you mean “Agile”? Do you mean Scrum? Do you mean eXtreme Programming?  Something else? Without clear goals and objectives, the people in your organization will struggle. There is no way for them to meet those goals and objectives without knowing what those are. If the way work is done to meet those goals and objectives is a cherry-picked set of practices from disparate ways of working it’s also unlikely those goals will be met. 

“Going Agile” isn’t a goal. The goals and objectives Agile Leaders must identify for the organization pertain to the business the organization is in. Who are the Customers you serve? What do they see as the Product or Service? Why are you in business? Those goals need to be defined or the organization is in trouble already…Agile or no agile. Once you have those identified and you have the data for how those have been achieved before changing the way work is done to an Agile approach, there is something to measure. Something to compare. In the absence of that, there’s no possible way to determine if the new way of doing work is more effective or less effective than the old way.

Identifying a particular “Agile” approach is crucial. Although the various approaches represented at Snowbird in 2001 agreed upon the 4 Values and 12 Principles in the Agile Manifesto, they have nuances and noted differences depending on which approach is chosen. There are bodies of knowledge for people to reference to answer questions they have in making the change such as the Scrum Guide in the case of Scrum. With no defined approach, people will struggle. They won’t have a guideline or a playbook to follow which will lead to confusion, delay as well as missed goals and objectives.

Think of the rules of the road. What would happen if you get on the road and decide to drive on a different side of the road or you determine stop light colors mean different things. Are you likely to meet your goal of getting to your destination on time and safely? Or do you risk accidents, injuries and traffic?

How credible are you feeling knowing that your employees have attended training classes to learn those framework rules and the Agile Manifesto values and principles but as their leader, you are unable to articulate what "Agile" means to the organization or which approach will be used?

Perhaps you are one of the leaders who not only declares “We’re Going Agile” and also “We will be making up our own approach!”. Now what? Where are those guidelines or rules captured? Your employees learn that regardless of the Agile approach a sustainable pace is necessary – sponsors, users and developers must be able to maintain this pace as outlined in principle #8. That means no nights and weekends or asking people to maintain an unsustainable pace. Yet that’s exactly what people do on this “agile project” that’s part of "going Agile." 

Principle #11 notes the best architectures, requirements and designs emerge from self-organizing teams. Yet the organization structure is exactly the same as it was in project management: segregating those activities by singular roles such as the architecture department, the business analyst department, etc. 

If you now understand why your credibility as an “Agile Leader” is pretty low and you’d like to fix it, the good news is it boils down to what leaders of organizations are responsible for doing even without “Going Agile”: define goals and objectives and define the approach to doing work.

That’s it. Even if you never want to use the words “Agile” or “Scrum” again but you want less confusion, delays or unintended results, as a leader do 2 simple things. 

Define goals and objectives. 

Define a consistent way to approach work. 

We ask every student if they can articulate the reason they have been told to go agile by their leadership. Approximately 70% of them are unable to say why. We hear “We were told to”. In one case, a very expensive Agile Implementation has been underway for 6 years with an expensive group of Agile Coaches at the helm. Not one could answer the question and admitted that they had not been given a reason or goal but rather, they were being asked by the leaders to somehow produce metrics about the Agile Implementation. 

How does that work? 

A group of people with no clear goal or objective is now asked to report on how they are doing at meeting it? Seems like a circular conversation and a waste of time and money. Time to stop going Agile and start being agile.

If you’re wanting coaching to become a credible Agile Leader, contact us at: info@coleadteam.com

More with LeSS: Who's on the Scrum Development Team?

In the first two posts in this series, we explored how to identify the product and how to identify the Product Owner. If you missed these tips, check them out HERE.

Now let’s say you have effectively identified both the Product and the Product Owner. How do you identify the Development Team? Or in the case of BIG products, which this series is focused on, how do you identify multiple Development Teams?

Regardless of the development type - Product Development, Internal Product Development or Project Development - with Scrum, the Development Team characteristics as described in the Scrum Guide remain the same:

• Are self-organizing. No one (not even the Scrum Master) tells the Development Team hot to turn a Product Backlog into increments of potentially releasable functionality

• Are cross-functional, with all the skills as a team necessary to create a product increment

• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole

If Identifying Product was Skipped:

Scrum adoptions are rarely effective if identifying the Product was skipped and what is happening is an attempt to make Scrum fit into existing structure or the status quo.  Scrum is about changing the status quo. It potentially requires structure change in order to effectively optimize for delivery of working product.

As an example, if the structure of the organization has people segregated by specialized, singular activities such as analysis, building, testing, architecture, etc. those are component teams. The component team structure not only requires hand offs, late integration which increases risk, it structurally does not enable delivery of value to the customer the way a cross-functional feature team can. If the organization is still using project management with component teams, it’s rare that any members of component teams are 100% dedicated to one project. Typically, people are assigned to multiple projects to execute the one, specialized skill so that instead, they appear to be 100% “utilized”. This divides their attention, is less productive due to context-switching between projects and is a cost drain.

Like Scrum, Large Scale Scrum or LeSS, requires the teams to be cross-functional possessing all of the necessary skills to deliver a customer-centric feature or features in any given sprint (analysis, programming, testing, database work, etc.). Team members are 100% dedicated so there is focus on value and no loss of productivity due to time-slicing. Although people may initially have a special skill, Scrum and LeSS teams are multi-learning teams. People are willing to learn other skills and work together to deliver value.  An illustration from https://less.works/ comparing component teams to feature teams:

Because there’s always new features, maintenance or items that come back to the team via feedback loops, these teams are also long-lived. Customer centric features from the Product Backlog are broken down into items on the Sprint Backlog that the cross-functional, self-organizing feature team delivers in a sprint. Identifying Product at the beginning of the adoption makes it pretty simple to identify all of the skills that will be needed in order to achieve this. Each of these feature teams is made up of a minimum of 3 people with a maximum of 9 people per team.

How many cross functional feature teams are needed may be determined based on the needs of the Product itself or budget. In a LeSS adoption, the upper limit for the number of teams is 8. In really BIG product scenarios, LeSS Huge may be adopted which involved more than 8 teams. For more information on LeSS Huge teams please visit:  https://less.works/

To learn more from Large Scale Scrum (LeSS) co-creator, Craig Larman, and to earn a Certified LeSS Practitioner credential register HERE.