Jeff Kosciejew Jeff Kosciejew

Teams

So you’re staring a new Team. Or maybe you’ve had a new person (or new people) join… Or had some people leave.. Or maybe it’s just been a while since you’ve looked at yourselves, as a group of people, and aligned on what’s important to each of you, and how you want to work together.

In any of those cases, you really have a new Team. A Team isn’t just a group of people working on something. A Team, when truly working as a Team, is far more than the sum of its parts.

Working with others isn’t always easy. Interpersonal relationships, of any kind, require effort. We’ll have good days, and we’ll have bad days. It’s going to happen. And each of us have different values, experiences, expertise, skills, strengths, weaknesses, desires, goals… There’s a lot going on when we look at people, and the dynamics between multiple people.

Hopefully this document can help with some activities to promote healthy conversation and understanding of some of the ways we can set ourselves up for success in working with others.


Are you really a Team? Do you want to be a Team?

It might be important to first understand if you’re a Group or a Team. One isn’t better than the other. But the approach we take for each might be a little different, and applying the wrong approach is likely not going to help and is likely to cause undue stress or anxiety. Let’s quickly look at some of the differences…

Groups are often reflected in a connection to others in some way. People in a Group often have the same reporting manager, or the same job title as others in their Group. They tend to have individual goals, individual accountability, and are typically responsible for getting their work done as best as possible. They tend to take responsibility for the thing they’re good at doing, or the aspect of the work that’s associated with their job title. For example, a software developer might tend to focus on developing software by writing code, while a designer might focus on doing some design work ahead of that developer picking up the work. Makes sense.

Teams often take a slightly different approach. The may or may not report to the same manager, and typically different people will have different job titles from those that they’re working with. They typically have a shared goal that isn’t specific to their individual role or title – that is, no matter what their job title is, and no matter who they report to on an org chart, they share a common goal. They don’t have individual accountability for the work, but rather share the success, or failure, in achieving their goal. Individual members of a Team will often still have something they’re very strong at doing, but will contribute to all aspects of achieving their shared goal. For example, a designer and software developer on a Team will likely conduct user research together… They’ll design the look & feel of a product together… And they’re likely to code & test the system together.

We often don’t hear more about Teamwork because things like finance, strategy, technology, project plans, business cases, and roadmaps are much more tangible… And are much easier in many ways. Teamwork is really hard to measure. Anything related to people, and the interactions between people, can be difficult.

It can’t be bought, and it can’t be obtained by following a cookie-cutter approach where one-size-fits-all. It involves human interactions. Building an effective, cohesive Team can be extremely hard – it requires courage and persistence.

But as difficult as Teamwork is to measure & achieve, its power cannot be denied. When people come together and truly set aside their individual needs for the good of the whole, they can accomplish what might have looked impossible on paper, or what would have been impossible for an individual, or even a group of individuals.

Teams tend to get more done, will less time, with less cost, and usually in a better way. But we don’t get this for free. We have to invest time and effort in building – and then maintaining – our Team.

 

When we look at what makes a great Team, a few patterns emerge:

“Great Teams trust one another on a fundamental, emotional level, and they are comfortable being vulnerable with each other about their weaknesses, mistakes, fears, and behaviours. They get to a point where they can be completely open with one another, without filters. This is essential because…

Teams that trust one another are not afraid to engage in passionate dialogue around issues & decisions that are key to the organization’s success. They don’t hesitate to disagree with, challenge, and question one another, all in the spirit of finding the best answers, discovering the truth, and making great decisions. This is important because…

Teams that engage in unfiltered conflict are able to achieve genuine buy-in around important decisions, even when various members of the Team initially disagreed. That’s because they ensure that all opinions and ideas are put on the table and considered, giving confidence to Team members that no stone has been left unturned. This is critical because…

Teams that commit to decision and standards of performance don’t hesitate to hold one another accountable for adhering to those decisions and standards. What’s more, they don’t rely on a manager or Team leader as the primary source of accountability. They go directly to each other. And this matters because…

Teams that truly trust one another, engage in conflict, commit to decisions, and hold one another accountable are very likely to set aside their individual needs and agendas, and focus almost exclusively on what is best for the Team, and for their customers. They don’t give into the temptation to place their department, individual career aspirations, or ego-drive status ahead of the collective results that define Team success.”

It’s not uncommon for leaders, and Teams, to want to focus on results and accountability. But those are the last two steps in building a great Team, and without trust, conflict, and commitment in place, it’s unlikely the Team will find itself set up for long term success.

 

What about great Teams in the real world?

Google conducted a study that involved over 200 people, looking at over 250 attributes of Teams. They were very confident that great Teams would be comprised of a perfect blend of individual skills aligned to the work each Team was doing. Through their research, they found that they were dead wrong with that thinking. The found that “who” is on a Team matters less than “how” the people interact, structure their work, and view their contributions.

Through this research, they learned that there are five key dynamics that set great, successful Teams apart from other good, or average, Teams:

  1. Psychological safety: Can we take risks on this Team without feeling insecure or embarrassed?

  2. Dependability: Can we count on each other to do high quality work on time?

  3. Structure & clarity: Are goals, roles, and execution plans on our Team clear?

  4. Meaning of work: Are we working on something that is personally important for each of us?

  5. Impact of work: Do we fundamentally believe that the work we’re doing matters?

None of that is easy. And, just as was mentioned earlier, it’s not uncommon to focus on steps 4 and 5, without really nailing the foundational items. Those foundational items are hard, and often difficult to even acknowledge that work can be done to improve in those spaces. It’s not uncommon for a Team, and their leaders, to believe they have a psychologically safe environment. But how do you really know? If people don’t feel safe, are they really likely to speak up, and tell you they don’t feel safe?

 

Team Evolutions

In 1965, Bruce Tuckman proposed a model which outlines four stages Teams may go through as they work together. This model, while wrong, still contains some wonderful insights and patterns we should be aware of. The complete model itself is beyond the scope of this document, however I’ve provided a summary to help, and to gain an understanding of where your Team might be.

When a Team first comes together, members are often cordial with one another. People are getting to know one another and are on their "best" behavior. Productivity is reasonable, but not impressive. We tend to have very little conflict as people figure out how they fit in with this group of others, and begin to understand what’s expect of them, and how they’ll interact with others. To advance from this stage to the next stage, each member must relinquish the comfort zone of non-threatening topics and risk the possibility of conflict.

As a Team moves into the next stage, subtle differences in people's perceptions and expectations lead to opinions about the character and integrity of other Team members. Annoyances due of unresolved differences in expectations become impediments as members start to clash with one another. Productivity typically is lower in this stage, and many Teams won’t address the conflict, preventing them from moving them on to later stages – it can be very difficult. In order to progress to the next stage, group members must move from a "testing and proving" mentality to a problem-solving mentality. The most important trait in helping Teams move to the next stage is often the ability of Team members to listen to their Teammates - what are they trying to say?

If and when a spirit of cooperation emerges, the Team moves into this third stage. Here, differences are discussed and resolved through creation of new shared norms. The Team starts to come together as a cohesive unit and productivity increases with each new improvement. The flow of information between group members includes feelings and ideas; members solicit and give feedback to one another; they explore actions related to the task. Creativity tends to be high as different perspectives and opinions are truly considered. Conflict still exists but is typically focused on improving the Team and the product being developed, and less towards the people.

This fourth stage that was described does not happen for all Teams, in spite of what a Team may tell you. Many Teams believe they are a High Performing Team, or use some similar language, but may not really have achieved it, in spite of what they think! A Team who does make it to this stage has a shared set of norms and has learned how to work well together, capitalizing on individual strengths.

A fifth stage was identified and added to this model in 1977, just in case you happen to hear about the “adjourning” phase. But I’m not going to talk about it any more in this document.

It’s important to remember that since this model was introduced, we’ve learnt that it’s wrong. It’s not a linear flow that Teams go through. It’s much more common for elements of each of these stages to be present, in different amounts and between different members of the Team, all at the same time.

 

Setting Ourselves Up for Success

There are no guarantees when it comes to building a Team. But there are things we can do to help give ourselves a better chance of becoming a Team (if we’ve made the explicit decision that we want to be a Team). But it requires work, effort, time, and a continuous conversation to foster the positive relationships between Team members.

There are two things going on, and it’s important to be explicit about them both:

  1. First (this is all about what we’re building, and why):

    • What are we building, why is it important, why is it important now, what outcome are we hoping to achieve, what does success look like, how might we validate this is the right approach as soon as possible…

  2. Second (this is all about how we’re building it):

    • How are we going to work together to achieve the desired outcomes, how will we improve how we work together, and what might we do to continually improve how we work together…

Some key questions to consider addressing in a Team Liftoff:

  • Logistics & Planning

    • Why are we coming together?

    • Who needs to be there?

    • Who will kick it off?

    • What are the key points that need to be communicated?

    • When will we do it?

    • Where will we do it?

    • Who will facilitate it?

    • How much time will we allocate for this? What if we need more time? Or less time?

    • What will our success criteria be for our Liftoff? How will we know when we’re done?

  • People

    • Do we have everyone who will be a part of this Team in place?

    • Have we identified any SMEs that are outside the Team, who might be able to help us?

    • Can we identify anyone who is outside the Team that we think will be important to our success?

  • Purpose

    • Do we know the desired outcome of the work we’re being asked to do?

    • Do we know why this outcome is important now?

  • History / Organizational Assets

    • What did we learn from previous similar work, or previous projects in this domain?

    • What are our known unknowns?

    • Have we identified and documented our risks?

    • What assumptions have been made?

  • Project Outcomes

    • How will we learn about the problem we’re solving?

    • What might be a good starting point?

    • What training will be needed? How do we know?

    • What scares us about doing this work?

  • Team Attributes

    • Do we have a Team identity, or a Team name?

    • Who’s on our Team?

    • What skills do we have on our Team? Can we identify any gaps?

    • Are we going to do any team building, or activates to get to know each other?

    • What is it we value as individuals? What do we value as a Team?

    • Do we have any individual or personal goals?

    • Do we have any individual expectations about being a part of this Team?

    • What personal needs do each of us have?

    • What time will we work together?

    • How will we make decisions? What decisions will be made by whom?

    • What rules make sense for us to have in place?

    • How will we adjust those rules as we work together?

    • When conflict emerges, how will we discuss it?

    • How often will we revisit what we’ve come up with today?

That’s a lot of questions to consider, and you’re not likely going to get it all right when you start working with a group of people. If you invest in building your Team, it can make a huge difference – in time – to the performance and the satisfaction of the people on the Team. As was previously mentioned, it’s just hard to see, and almost impossible to quantify.

There are many resources available to help with this activity. One of them is a workbook that offers a complete solution to planning and executing an effective Team Liftoff… And I personally love the image of the cover of that book - it reminds us that we’re looking both at the Organizational Needs and the People Needs. Typically, we over indexed on the Organizational Needs. Both are important.

That workbook is a fantastic reference and resource tool to consider having available if you find yourself in the situation of leading a Liftoff. While you may not do everything in the book, and may not address all of the questions, it’ll likely be worth while for you to consider your current situation, and select the things that will be most important, and most impactful.

As you might imagine just based on the number of possible discussion points and topics above, building a Team isn’t a quick endeavour. A Team Liftoff can help set a positive foundation if done well. But it’s unlikely you’re going to get the value possible if you attempt to fit in into an hour or two.

This is one of the reasons many Agile Coaches advocate for long-standing Teams, where different work may go to an individual Team over time, but the Team itself stays together. It’s often faster and less expensive for a Team to learn a new skill or technology than it is to develop the strong, powerful interactions that can be built up between and amongst the people on a Team. There are a variety of techniques & approaches for a Team to develop that new skill, or learn that new thing. That’s beyond the scope of what I’m writing about here! When a group truly becomes a Team, it often leads to higher employee engagement, improved morale, better products, faster delivery, improved quality, and so many other amazing benefits. So while it’s not always possible to keep a Team together, it’s worth considering and thinking about, and being aware of the benefits it can offer.

Too often, I’ve seen leaders (and individuals on teams) want to label themselves as “high performing teams” as quickly as possible. One of the challenges with that, from what I’ve seen & experienced is that, as soon as teams declare that you’re high performing, they stop trying to improve. And that’s a shame. When I think about the best teams I’ve seen & worked on, it’s not that they’re delivering amazingly (although they usually are), it’s that they’re always finding ways to be better than they were previously. In my experience, teams that label themselves as “high performing”, often aren’t. And teams that think they’re not “high performing” because they’re always looking for ways to improve are, often, far higher performing teams than they give themselves credit for!

Just a note about a couple of words: Chartering and Liftoff. They’re connected, for sure. In my experience, a Team Charter is often focused on three things – Purpose (what problem we’re working on & why it’s important), Alignment (ensuring we’re all heading in the same direction), and Context (how what we’re being asked to do fits in with the large ecosystem). That’s all part of a Liftoff, too. A Liftoff really should cover all of these elements, for sure, and will often go a little deeper with the focus on the people, and building a solid foundation for a great Team to emerge. They’re very similar in many ways. Both are about setting the conditions and environment for great outcomes. And, if you want to call it a Charter as opposed to a Liftoff, that’s just fine… Whatever works for you!

 

There really isn’t a single approach that’s going to be right for every group that wants to become a Team. It’s not something we can buy from a store… There’s no way that I know of to build a team, except with time in continually focusing on those we get to work with. By building a solid foundation early, we may be able to foster an environment where a great Team can emerge. With an understanding of what makes a great Team, the dynamics and evolutionary phases a Team may go through, and some of the questions we’re trying to address as we start to build the foundation of a great Team, we can set ourselves up for a greater chance of success – not only in the desired outcomes of our work, but in creating a more satisfying and engaging place for our people to work.

 

What about some Resources?

That seems like a really good idea. All of these might be helpful in certain contexts. I’ve used pretty much all of them at some point. And many of them were leveraged in writing this post. There are a lot of links here, and I’m sure I’ve missed some. But hopefully you find them helpful.

Read More
Jeff Kosciejew Jeff Kosciejew

PBI Workflow for POs

Recently, I was speaking with a team trying to work in a more agile way. They’re really trying to focus on the delivery of great work that adds value to their customers & users. And, they happen to have recently been assigned a new manager, who is also playing the role of Product Owner. The team is early on in their journey, and their new manager is even newer to this way of working. The manager happens to have 30ish years working a certain way and so, is finding some of the ideas that the team is trying to follow a little challenging.

This team is trying to follow the Scrum framework. We can argue if they should or not, but for the moment, they are. At least, they’re mostly trying to follow it. They’ve found that adding a Refinement meeting once a week is helping them get work ready for the upcoming Sprint, but are still having lots of issues with work not being completed during a Sprint, and a real lack of understanding for what it means for a piece of work to be ‘done’.

So today, I helped the team try to come up with Acceptance Criteria for a couple of their work items. As you can imagine, it took a while, but we got a few done. And yet, for every item, the manager wanted to sign-off that each item was complete, to his satisfaction.

It got me thinking about the value of Acceptance Criteria, and our desire for that to be what we hold ourselves accountable for delivering when we pick up a piece of work. We can’t be building to unknown criteria that might be unarticulated in someone’s head! So to help illustrate this, I drew a little workflow diagram, with the intention of helping this team, and mostly this manager, understand that when following Scrum, we need to remember that our work is incremental and iterative… And we often forget that iterative part. Iterative means we might go over the same thing more than once… We iterate on what we’ve build because we find a better way to do whatever it is we’ve built. And I really think that gets missed with teams on a regular basis.

In any case, here’s the picture I drew. I’m sure there are steps missing. I’ve wished away all of the details of how we prioritize or sequence our work. I’ve not tried to show lots of aspects of this. I’m sure it’s not perfect. But, it was really built to remind this manager, and this team, that once we’ve agreed to the Acceptance Criteria, we build to that (and then stop building). Then, we can inspect what we’ve built, and incorporate new ideas from the PO, customers, users, and stakeholders into a future Sprint, and prioritizing that new idea against any other ideas in our backlog, making sure we’re working on the most valuable, highest impactful work. Maybe you’ll find it useful?

If the image isn’t clear, you can download a PDF version of it here: https://www.dropbox.com/sh/bt05io6zbwks6ug/AACNhlFnoAkmR5_RMy_86QRwa?dl=0


Read More
Jeff Kosciejew Jeff Kosciejew

Agile Certifications

I’ve lost count of the number of people who have asked for my advice or recommendation about getting certified. They’re often looking to understand what options are available. And while I have zero affiliation with any of these groups, I figured it might be worth outlining some of the options for someone newer on their journey. To be clear, none of these will make you an agile expert. I think they all have something to offer, depending on what you’re looking for.

I’m going to answer this in four parts:

  1. Scrum

  2. Kanban

  3. Agile

  4. Scaling

Part 1 – Scrum:

There are two Scrum organizations – Scrum was created by two people (Jeff Sutherland & Ken Schwaber), and they have very different philosophies regarding training & certifications:

  • Jeff created the Scrum Alliance:

    • They offer certifications where you have to take a course and then write a test to get the certification.

    • Then, every year or two, you have to pay to renew that certification & prove that you’ve done some learning (PDUs) in that time.

    • https://www.scrumalliance.org/get-certified

  • Ken created Scrum.org:

    • They also offer certifications, but you don’t have to take a course to get the certs from them. You just need to pass a test.

    • The tests are online, and cost $150-$250 per certification. But they can be difficult. You really need to know your stuff to pass them, so many people do take a course to help them prepare for the online test. There are online practice tests you can take (as many times as you want) to help you prepare, but in my experience, the real test is more difficult than the practice tests.

    • You then have that certification for life. Nothing more to pay, ever.

    • https://www.scrum.org/professional-scrum-certifications

Both Scrum Alliance and Scrum.org offer courses & certifications for Scrum Masters, Product Owners, Developers, Leaders… And both are considered equal from most folks in the agile community, and by HR recruiters. I have certifications from both.

Part 2 – Kanban:

While Scrum is, by far, the most widely known framework (they’ve done a great job of marketing it), another popular approach to working in an Agile way is with the Kanban Method. There are two flavours of this, too:

  • Lean Kanban University (LKU)

    • Likely the better-known option in the Kanban space.

    • They offer a few certifications. With LKU, you need to attend a class, or multiple classes, in order to get the certifications they offer.

    • https://kanban.university/kanban-development-path/

  • ProKanban

    • For a number of reasons, a large number of folks in the Agile community wanted an alternative to LKU. Two years ago (might have been three), ProKanban was formed with a focus on providing an inclusive and harassment free environment. As well, they took a less structured approach to Kanban, many would advocate is closer to the origins of Kanban.

    • For these certifications, there is a class followed by a test.

    • https://prokanban.org/certifications-overview/

My personal bias is to support ProKanban for a couple of reasons. But there’s good material from both, and I’m connected with trainers of both LKU and ProKanban material. For a couple of reasons, I only have certifications from ProKanban.

Scrum.org also offers a hybrid course called “Scrum with Kanban”.

Part 3 – Agile:

Depending on what you’re looking for, there’s another certification body, the International Consortium for Agile (ICAgile). And, there’s the Project Management Institute, too. Let me talk about ICAgile first…

ICAgile’s material is all framework/methodology agnostic. They don’t care if you choose to bring the Agile Values & Principles to life using Scrum, Kanban, or any other approach.

They offer several “tracks”, with several courses in each track, depending on where you want to focus, and how deep you want to go in a certain track. Each course offers its own certification. Some examples:

  • Agility in Leadership Track

    • Courses/Certifications under “Agility in Leadership”:

      • Business Agility Foundations

      • Leading with Agility

      • People Development

  • Delivery Management Track

    • Courses/Certifications under “Delivery Management Track”:

      • Agile Fundamentals

      • Agile Project & Delivery Management

      • Delivery at Scale

  • Enterprise Coaching Track

  • Agile Team Coaching Track

  • DevOps Track

  • …

ICAgile creates Learning Objectives, which private instructors use to build their own course material. ICAgile then certifies the course material meets the LOs. And then, ICAgile separately certifies the instructor/teacher, making sure they are qualified/capable to deliver the material in that specific course.

In case it’s not obvious, I’m a big fan of ICAgile. I’ve received tremendous value when I’ve taken a course that’s connected to ICAgile. The quality of instructor has significantly contributed to that, I believe – I try to take these courses with folks I know have the experience and expertise in the material they’re delivering.

These are a couple foundational certification courses you may want to start with, depending on your own comfort level:

  • https://www.icagile.com/certification/agile-fundamentals

  • https://www.icagile.com/certification/agile-project-and-delivery-management

  • https://www.icagile.com/certification/business-agility-foundations

The full list of certifications available can be found here: https://www.icagile.com/agile-certification

I have a couple of certifications through ICAgile.

I think it’s also worth knowing about the Project Management Institute (PMI) Agile Certified Professional (PMI-ACP) certification. It requires knowledge from a vareity of common frameworks & methods (like Scrum, Kanban, XP, Lean, and others). There are a few prerequisites required to get this certification, and while you can just pay to write the exam (in person or online), there are prep courses to help you get ready for the exam, and to hopefully set you up for success. Oh, there’s also a requirement to earn a bunch of Professional Development Units (PDUs) related to agile things every three years. The full details can be found here: https://www.pmi.org/certifications/agile-acp

Part 4 – Scaling Options:

There are so many in this space, I’m not going to try and describe them all. Most of these offerings focus on how teams can work when multiple teams need to work together. Many of the certifications in this space love to take your money, but very rarely do they really make an impact. Enterprises love most of these options because they allow us to use new words to describe how we currently work, and get to claim “we’re agile”, without actually making any meaningful changes. That’s not to say there isn’t great information contained in the material they have to offer. It’s just very few of them really focus on improving the way work gets done, and really bringing the value that working in an agile way has to offer to life. At least, that’s been my experience. If you’re interested, here are some of them:

  • SAFe: https://www.scaledagileframework.com/

  • Nexus: https://www.scrum.org/resources/scaling-scrum

  • Disciplined Agile (or DA - formerly DAD, and now owned by the PMI): https://www.pmi.org/disciplined-agile

  • Scrum@Scale: https://www.scrumatscale.com/

  • LeSS: https://less.works/

  • Enterprise Kanban: https://kanbanize.com/blog/enterprise-kanban/ (this one is worth reading, IMHO, but not a certification)

While I do have one of these certifications, it was possibly the worst course I’ve ever taken, taught by people who had no experience, teaching material they didn’t really understand. The course I took required annual recertification (in the form of paying more money), which I never did.

Part 5 – One Final Thought:

As I was typing this up, I noticed two things missing as they don’t really fit into any of the above headings (although the leanchange.org course does offer IC-Agile certifications). These, I think, tend to be a little less expensive than many of the others, and were (at least for me), money really, really well spent. These are a couple of options that offer some great material. I’ve taken courses from both, and do highly recommend them for the content (and less so from an ‘adding to your resume to get past the HR Recruiter’ perspective):

  • https://leanchange.org/courses

  • https://management30.com/certifications/

Final Thought

As with anything, your mileage may vary. This is just my opinion based on my own experiences and my own relationships with the trainers and certification bodies overall. You may have a very different experience or opinion. There’s lots more I could write - hopefully my experiences will help you with your own, if you’re looking for a course like the ones I’ve listed here.

Read More