Teams – Page 2 – Agile Bacon

If Your Title Rhymes with “leaf”, “erector”, or “resident” – You Should Learn About Agile and Lean

in Agile/Project Management/Teams by Matt Badgley

If you are reading this blog, then you are either part of an Agile transformation or you are someone considering an agile transformation. If you are someone that works in a management or simply a position of authority at your organization, if you don’t know much about Agile or Lean except that they are the latest buzzwords that don’t seem to go away — well, you should learn more about them. Because, the words might change a little, but the practices and principles have been around for a while and they are not going to go away anytime soon.

Agile and Lean are a set of ideas and principles that shape principles which guide our behaviors and foster the frameworks by which teams use to get things done. These have come about because there’s a recognition that trying to build things that are a result of complex cognitive thinking cannot be done well and in a timely manner to keep up with the demands of consumers. Couple these demands with an exponentially growing and aggressive competitive marketplace — the concepts of focusing on building the right thing and eliminating the waste that keeps us from delivering things right have naturally emerged. Agile and Lean are not old ideas, there’s been a ton of learning and shaping of these ideas and principles. New frameworks and or practices emerge daily as our products evolve and the people creating them do the same.

Why Should You Learn Agile and Lean?

Have you ever said, “Dolly is a great leader and worker, I wish we could just clone her and have ten Dolly’s.”

Or, how about, “I wish our team would just make a decision and get it done.”

Well, Agile and Lean values promote:
[list][list_item icon=”fa-star”]Empowerment[/list_item][list_item icon=”fa-star”]Trust[/list_item][list_item icon=”fa-star”]Commitment[/list_item][list_item icon=”fa-star”]Quality[/list_item][list_item icon=”fa-star”]Value[/list_item][list_item icon=”fa-star”]Team Work[/list_item][list_item icon=”fa-star”]Transparency[/list_item][/list] All of these things involve, giving teams information and the vision, and then getting out of the way to let them deliver.

Another thing to note about the values above are that they are generally practiced by all organizations and you’ll find aspects of each word above within the corporate mission statements. By learning more about Agile and Lean, you can learn how to help your teams or leadership leverage the organizations’ values and adapt those advocated throughout Agile and Lean adoptions.

The predominant reason organizations and teams adopt agile is to respond better to change — that is market changes. The other reasons are productivity and quality, all things that help us make products people want to buy, at the price they are willing to pay, and ultimately with the right level of quality that help mitigate long-term cost of supporting. A byproduct of agile adoptions is improved morale.

How You Learning Agile and Lean Can Help

Agile and Lean advocates shrinking the feedback loops which improve communications amongst departments and ultimately help your employees make better decisions. Well, you understanding when the feedback loops happen, your role in the feedback loops, and the types of information shared at the different levels of the organization can help you keep yourself out of the way from the team. What I mean by this is that when sometimes things are going right, we’ll go back to what we are comfortable with and understand — and generally this means metrics and reports that may be costly to gather and result in anti-patterns for good team work.

The other value of you learning about Agile and Lean is that you can help facilitate the adoption by being a good leader and facilitating change practices. Keeping a level head when things aren’t going right, and providing guidance as to how best support the teams.

What Should You Do to Learn?

There’s a ton of reading materials out there. Just keep in mind that there’s a lot of books, articles, and blogs that focus on the practices and not as much on the strategic and scaling aspects around agile. This spaces is growing as organizations have realized that not only is there the “build better software” value, but the planning and practices around Enterprise Agile give organizations a framework to make better investments and harness the short feedback loops to improve ROI.

To help get you started, here are a few resources that have been recommended to me and I can vouch for their value of learning:

The Agile Executive Whitepaper, Jim Magers, VersionOne. Nice quick read and primer / introduction to agile.

The Concise Executive Guide to Agile, Israel Gat. Nice quick read that provides a deeper dive than the Agile Executive whitepaper.

Scaling Software Agility: Best Practices for Large Enterprises, Dean Leffingwell. Foundations for the Scaled Agile Framework (SAFe) which is being advocated as a framework for leveraging Agile and Lean in the enterprise.

Principles of Product Development Flow, Donald Reinerstsen. Helps explain the way Agile and Lean works in Product Development.

Training – Agile for Executives Workshop, VersionOne. This is a workshop that I’ve performed as well as my colleagues and it’s aimed at being a concise four hour session aimed at ensuring Executives understand the history, underpinnings, and execution models surrounding of Agile and Lean.

Behaviors and Culture Can Impair Creating Good Product

in Agile/Agile Engineering/Product Management/Project Management/Teams by Matt Badgley

When we think culture, we often think about nationality and or regional cultures. Culture is often a dinner discussion with my wife and friends, it’s great to reflect upon how our upbringing, surroundings, and maybe even our genetics drive our work habits, how we work with others, and how we see and work with authority. Culture is a difficult thing to work with because it’s engrained in us.

A few weeks ago, VersionOne released the 7th Annual State of Agile Survey. Within the survey, it is obvious that culture is the leading challenge to all aspects of agile adoptions and transformations. There were two questions within the survey that really highlighted the cultural challenges (note, I plucked out the key responses that impact culture – be sure to check out the full survey):

Concerns about Adoption

Lack of Upfront Planning – 34%
Loss of Management Control – 31%
Management Opposition – 27%
Dev Team Opposed to Change – 18%

Specific Organizational Failures Behind Agile Failures

Failure to integrate people – 34%
Failure to teach team-based culture – 28%

Prior to the survey being released, I already started making a list of those human behaviors and or cultural behaviors that I’ve seen impact the ability of an organization to build good software, let alone those behaviors that negatively impact an organization’s agile initiatives. Here’s my list:

Fear of Losing Control. This is primarily an individual fear; however, it can also be engrained in the organization. I’ve heard, “if I don’t put these controls on how the team works and if I’m not making decisions, when they screw up — I’m the one that is going to hang.” Of course, the idea of control being lost ultimately becomes a myth, because we generally see everyone’s engagement raise up a notch or two. Thus, resulting in more people being involved in making the decisions at the proper levels — hence scaling the organization.
Gate Keeper Culture. Often a subset or product of Fear of Losing Control, this is the manager or director who acts the liaison between his or her direct reports and the rest of the organization. I’ve seen and even lived in environments where all communications have to go up and down the ladder. Or, where in order to talk to someone on the “protected” team, you have to walk past the Gatekeeper and they then take the message or grant permission as long as they are part of the discussion.
Measurement of Success is Based upon “On Budget and On Time”. Many organizations, especially IT organizations live in the world where they try only be concerned with what they can control — and that is generally, “we deliver what was signed off and will do it based on a budget and set schedule.” Well, we fail to recognize that we should be measured based on the success of the product either in the marketplace or the usage internally. The funny part is when we time box and quit focusing on the when and who, and instead focus on the what — everyone is happier including the development teams.
“What’s My Role” Fear. This is the protectionist behavior where managers and or team members don’t see a fit for themselves or don’t find a fit for themselves as an agile transformation takes place. These team members or managers generally start start creating barriers to deflect blame while at the same time climbing to the roof-tops to shout out about the failures of the team and process. If others are looking at the right thing (e.g. product moving out successfully
Victim Mentality. Have you ever heard, “it’s always been that way and it’ll never change”? Well, this is the typical response for the person who either doesn’t want to deal with change — or they’ve been told “NO” so much, they just give up. Personally I used to be one of these people, then I learned quickly — if you don’t ask, you don’t get. And, if it is something that could have really positive results — isn’t it worth the risk?
Super Hero Culture. Now don’t get me wrong, I appreciate hard work and stepping up your game to make sure we succeed as a team. But constantly over committing and being let to overcommit constantly is not a good thing. I’ve also seen that individual who loves to be on a pedestal, thus when we start working more as a team — they’ll often be the person making back room deals to do more work or take on the clandestine project that our Scrum Master isn’t supposed to know about. Again, hard work is great — but we have to respect the concepts of sustainable pace, transparency, and “The Team”. Remember we regularly deliver value.
Us/Them Culture. This one is obvious, but it takes on a few forms including department silos, role based silos, and Ivory Tower silos. Department silos exist when we have complex solutions that require the integration of products from multiple departments and a bad or no rapport between the teams. Role based silos will generally exist in early agile adoptions where the value of diversification and cross-functional teams have not been visible yet. And Ivory Tower silos are those “I’m a Director” or “I’m the Product Manager” and you just do what I say — this never results in team work, unless the team is conspiring together to take down the Tower. If people talk about the managers in the organization as “The Suits”, then you might have some Ivory Tower silos and possibly going in the opposite direction.

What challenges, either culturally or behavioral, have you’ve experienced? I’m interested to here about those that not only impacted your agile implementation, but those that impacted delivery good product.

Words Mean Things – Inspect & Adapt

in Agile/Project Management/Teams by Matt Badgley

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Agile Manifesto (agilemanifesto.org)

In case you weren’t aware, this is the 12th Principle of the Agile Manifesto and it is often translated into “inspect & adapt.” Of the twelve principles, this is definitely the one that everyone can easily relate to. The team should look at what they are doing, look at how they are doing, and adjust. This is primarily for the team and I would argue that it’s mostly about the process (and maybe people stuff), but it could be around the product and or project if we are doing this in respect to a specific release or even the outcome of the sprint.

With Scrum, there is a ceremony (a.k.a. meeting) that is called a Retrospective. Other frameworks and processes have adopted the spirit of this meeting and there are a bunch of creative ways to conduct the retrospective. If they are kept fairly informal, transparent, and candid — then they can be hugely valuable — especially when they are actionable.

But this blog is not about the retrospective, instead it’s about the terms and maybe even way we speak of the concept “inspect.”

inspect. v. To examine critically or carefully; especially, to search out problems or determine condition; to scrutinize.

If you’re development shop is worth its salt, then you are constantly inspecting. Let’s face it, the feedback loop with following iterative development, using continuous integration, employing automated testing, and on a cross-functional team is really tight. This means that we are constantly re-digesting information from our feedback loop — so inspection is constant.

I propose this, instead of “Inspect and Adapt”, shouldn’t we “Innovate and Adapt.” Now I cannot take credit for this change of terms, I was driving home one day from the office and I heard a post-season interview with the Atlanta Falcons’ head coach Mike Smith. He was talking about the fact that the team has reviewed all the tape from the year and now it’s time to innovate and adapt. He went on to say that seeing one’s issues and or challenges is not enough, they have to find ways to beat the competition and be better — that requires innovation.

innovate. v. To alter, to change into something new.

So instead of simply looking and digesting, let’s imagine and innovate. Once we innovate, we adapt the new ideas to our team, we continue inspecting our feedback loops, and we continue our innovation.

Sometimes when you innovate, you make mistakes. It is best to admit them quick, and get on with improving your other innovations.Steve Jobs

Put It On The Team

in Agile/Agile Engineering/Project Management/Teams by Matt Badgley

Do you want to have more effective daily stand-ups? Do you want to have the planning meetings flow better and increase the value of these meetings? Do you want to see continuous improvement flow from your retrospectives?

If your answer is yes, then put it on the Team.

I’ve written about trust, relying on strengths, and improving self-organization many times — and the message of these can all be summed up as putting it on the Team. Make the team responsible for solving problems, make the team responsible for defining how to deliver, and making the team accountable for delivery. Most of the times when we talk about the concept of the Team self-organizing, is it more focused on the “how” part of delivery, and not the process. However, remember that the meetings (or ceremonies as some call them) are primarily for the team. Specifically, the Iteration Planning, Daily Standup (or Daily Scrum), and the Retrospective meetings — these are for the team, not the stakeholders or managers. Do the stakeholders and managers gain value from these meetings — Yes, but the real value is the fact that the Team takes ownership of what they are going to deliver, they take ownership on holding each other accountable to deliver and working through problems themselves, and they take the on responsibility the responsibility of improvement.

A lot of times we (as in Managers, Scrum Masters, Team Leads, Type-A Team Members) want to install processes and templates around these meetings. This usually happens after a few weeks or several months of trying an agile framework and either not following the guidelines of the framework or the team not taking the initiative to make improvements. We’re not getting any value and the team is resisting and or blaming the whole concept — we want to fall back to more structure and being told what to do.

A great example of this is when a team’s stand ups start becoming mundane, over-run their time boxes, and team members don’t show up. So what happens is we come up with a template for the team to keep up with for daily stand ups as well as establish a set of metrics we answer to during the stand-up. And of course, this just becomes one more thing for a team member to keep track of as well as an unintentional mechanism of command-and-control.

As an ex-Director/Manager, I often wanted to step in and help — and I usually would come up with a template and or some hard-prescribed structure and tell the team to follow it. I wanted to help and that’s what managers genuinely want to do, but I was quickly put in my place when one of my team members said, “let us figure it out, it’s our problem.” I gave guidance and advice, but otherwise I got out of the way. I let the Team come up with how they were going to make their meetings more effective. And at the end of the day, they simply looked at the frameworks themselves and decided to more closely follow the existing framework guidelines — e.g. keep stand-ups at 15 minutes and stick to the script, then allow the time remaining to become open space troubleshooting time.

At the end of the day, remember that more process does not equal more better. Rely on the Team to solve problems, over instituting process and templates to solve problems. I think I’ve heard this before somewhere …

How can Scrum Masters help their teams to Self-Organize?

in Agile Engineering/Teams by Matt Badgley

Sometimes, teams need a little nudge to help to self-organize. Remember self-organize means the team takes ownership of not only how to produce the desired end results, but they are active participants in understanding the product/project and they work together to ensure they are operating as a team. It is not too uncommon for teams to sit back and wait to be told to self-organize. I usually see this with newly formed teams or teams that have historically worked under command and control environments.

A colleague of mine argues that most people operate this way — they want to be told what to do. Part of me agrees with this concept, I see this during training sessions all the time. But I don’t think this lack of self-starting self-organization stems from people not knowing how and needing to be told. Instead, I think it’s people waiting to be given permission. This behavior comes through loudly in training sessions with folks new to Agile. I’ll often use various interactive facilitative techniques during training and it usually takes at least one person to help get the interaction going. Some of the tricks and advice I’ve used and received not only works during training workshops, but I think the same things can be applied by Scrum Masters (as well as those folks in leadership positions) to help kick-start or trigger a team to self-organize. Here they are:

Practice the Pregnant Pause. The idea is that if you want to trigger conversation, create silence. Here’s how it works, state the problem or objective, or simply a broad statement that you want to trigger conversation about. Now, here’s where the fun begins – count to nine. Let the silence begin. In fact, if you have to count to 99 — I guarantee that someone will break the silence. A good friend of mine called it doing a Michael Cain, say something and throw a long pause in there and just let the team fill in. If they don’t, then maybe the meeting or discussion is over.

Storming. I’m not referring to Tuckman, instead I’m talking about brainstorming. There are some great techniques that you can leverage out there that will get team members involved, even those people that are normally quiet. All you need is a whiteboard, maybe some easel paper, post-it notes, and some markers. It is a amazing to see what starts happening when someone throws out a question or a problem statement, and then watching a team start brainstorming ideas.

Get Out. Yes that’s right, sometimes it’s best to just throw out an idea and instruct the team to come up with the solution, and then walk out of the room. I’ve done this myself, and I’ve never been let down — even with brand new teams.

Become a Facilitator Master. Above I mentioned brainstorming, to do it well you’ll need to practice and learn some techniques. There are many good books that can help, [amazon_link id=”0596804172″ target=”_blank” ]Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers[/amazon_link] by David Grey, Sunni Brown, and James Macanufo, [amazon_link id=”1591843197″ target=”_blank” ]Unfolding the Napkin: The Hands-On Method for Solving Complex Problems with Simple Pictures[/amazon_link] by Dan Roam, and [amazon_link id=”0470601787″ target=”_blank” ]Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity[/amazon_link] by David Sibbet. Taking a few hours to read the books and a couple hours practicing some of the facilitating techniques will carry you a long way and help the team out greatly.

Have Some Fun. It sounds easy, but it’s been shown time and time again that the team’s productivity is often related to their attitude and the general feeling around the project. When the team starts getting too busy or too tense — this is the time when the Scrum Master should step in, assist, slow-down, or just feed the team with encouragement and substance.

Teams - page 2

Why Should You Learn Agile and Lean?

How You Learning Agile and Lean Can Help

What Should You Do to Learn?

You might be interested in

Concerns about Adoption

Specific Organizational Failures Behind Agile Failures

You might be interested in

inspect. v. To examine critically or carefully; especially, to search out problems or determine condition; to scrutinize.

innovate. v. To alter, to change into something new.

You might be interested in

You might be interested in

You might be interested in