What are strengths?

What are strengths?

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.

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 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. 

markus-spiske-QozzJpFZ2lg-unsplash.jpg

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?

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?